[dajonker]

In my experience/opinion, if you are mature enough as an engineer(ing team), you should be able to make and implement most technical decisions on your own. Discussing technical changes with non-technical people is usually a giant waste of time. They often don't understand what you want to do in the first place and think it's optional, because why else would you bring it up for discussion?

Similarly, don't plan refactoring or architecture changes on the same board as your feature requests. Product managers will think they can change the priorities of this type of work and then they will.

The only thing that is useful to discuss in advance is scheduling when you can take the system down for maintenance.

For the rest, it's better to ask for forgiveness than to ask for permission: just do the changes that you think are technically necessary to keep everything running smoothly. Measure the outcomes and present them professionally.

Of course, with maturity as an engineer, I mean that you will not decide to do crazy, hype driven things like rewriting everything in Rust and then not doing any new features for a year. You have to be able to make trade offs and compromises to keep both sides happy.

[nucleardog]

> Discussing technical changes with non-technical people is usually a giant waste of time. They often don't understand what you want to do in the first place and think it's optional, because why else would you bring it up for discussion?

This bears some—well, all of, the emphasis.

I’d come at it even stronger I think. Asking people in non-technical roles to make technical decisions is a complete abdication of the responsibilities of your role.

You were hired into engineering to take care of the engineering. That is your role. When’s the last time someone in sales showed up and asked you “This guy wants a 25% discount. Do you want me to give it to him?”.

They _may_ show up and say “This guy wants a 25% discount and I’m trying to get a better understanding of our costs. Would we be taking a loss on that? Can you help me understand the costs of delivering service X?”

And that’s exactly how engineers should be approaching this. The technical decision is yours, however you probably don’t have the same context everyone else has. You _should_ discuss your decisions with others and consult with them, but that discussion is best had in terms of the impact the decision will have on their area of responsibility… which is not technical decision making.

In the situations where engineers are going to product to ask whether we should move to microservices or if this UML diagram makes sense, I’ve always seen engineering looking to pass off the decision so they can pass off the responsibility. I’ve run across this in multiple organizations and it was completely dysfunctional every time. And in every case simply replacing the engineering manager with someone that wasn’t afraid of decisions or responsibility quickly resolved the issue. (Which is probably you if you’re in this situation… if there was engineering above you, you’d be asking them instead.)

The discussion to be had should be more along the lines of “FYI, we’re looking to fit in three weeks of additional engineering work this quarter to substantially lower the costs of working on service X going forward.”. Product can discuss their priorities, or even share some information you don’t have yet like “We’ve been discussing axing that service entirely. Our tentative offboarding plan is having everyone off by Q3. Do you think the investment’s worth it?”.

If you continually ask someone else to do your job… well, be careful what you wish for.

[wfjackson3]

This is a great response. I would add that this is how any larger project gets evaluated and prioritized. In smaller companies, especially startups, I have seen the friction show up when the company is too small to have any staff dedicated to working architecture and engineering facing engineering systems, but big enough that their past choices are creating friction. At that unique point in time, it's really an organizational issue more than anything.

[nucleardog]

> I have seen the friction show up when the company is too small to have any staff dedicated to working architecture and engineering facing engineering systems, but big enough that their past choices are creating friction.

It's funny you say that. My career hasn't been as wide and varied as many. My roles have been across wildly different industries, but I only have one person's life to live and my average tenure has been around 5 years. I've had a lot of time to reflect on these sorts of issues in depth, but not to see how they apply across as many situations.

That _exactly_ describes the organizations I had in mind when I was writing that. I have no extra useful insight to add or anything, just that you've definitely given me something to chew on there.

[dajonker]

You hit the nail on the head, it's about responsibility and trust, and this is often lacking in various ways when tech feels like they need permission from product to spend time on anything.

[binary132]

This is it, right here, but the problem is that in the modern corporate agile model, they want to plan ALL work done through optimizing the backlog with product, and they want ALL of the available hours to go to that work. That causes these teams to have a very difficult time negotiating the right things into their workload, and if you do it by fiat other things necessarily get pushed out.