Hacker News new | ask | show | jobs
by nucleardog 619 days ago
> 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.

2 comments

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.
> 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.

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.