> "Discuss before shipping" sounds reasonable. In practice, when you're discussing with people who resist the category of change you're proposing, the outcome is predetermined. The discussion isn't evaluation, it's a veto dressed as process.
I literally had this discussion with my boss yesterday. I spent time writing up what I already knew to be true (we have systemic issues which are unsolved, because we only ever fix symptoms, not root causes), replete with 10+ incidents all pointing to the same patterns, and was told I need to get the opinions of others on my team before proceeding with the fixes I recommended. “I can do that, but I also already know the outcome.”
> Responsibility Without Authority
This. So much this. Every time I hear someone excitedly explain that their dev teams “own their full stack,” I die a little inside. Do they fix their [self-inflicted] DB problems, or do they start an incident, ask for help, and then refuse to make the necessary structural changes afterwards? Thought so.
Ouch I don't want to work there! It seems extreme. A decent place to work let's you do your thing. There will be guardrails. But my current job my boss has never told me not to do something. Getting the time to do it is another story and there are solutions. Sometimes picking the battle and lettung it go. Sometimes driving a decision and agreement. But if you do that people like it. And I work somewhere pretty well mocked on HN and Reddit etc. But they are good.
Other places I worked it is usually another engineer throwing a spanner in the works. Smaller companies have a lot of pets in the code and architecture. But if you avoid the pets you can change things.
The world is a big place with all kinds of organizations and people that fit in different ways on those organizations.
Some organizations do in fact optimize for correctedness, and some people are good at it.
Some people are good in everything (totally possible, universe doesn't care about keeping dichotomies). Maybe that technical guy was only technical up until now because it was what added more value. People often don't consider that.
Right now, we're seeing some small changes in value dynamics. It makes us foster those (mostly pointless) meta-conversations about what organizations are and how people fit in them. But the truth stays the same, both are incredibly diverse.
I worked for 7 years in a place where my technical insight slowly turned into questioning my decisions and expertise (this was after being 3 years in tech lead and 2 years in staff engineer role). Sometimes the solution is just to walk away
I've seen this pattern play out, and been frustrated by it many times over.
> Authority matching responsibility. That's the only fix I've seen work. Either you get decision-making power that matches the decisions you're already making, or you find a place that treats your judgment as an asset instead of something to manage.
I don't think the solution is to become some kind of dictator. And I don't think it's about not valuing your judgement.
The key issue is a fundamental misalignment of core values. In the examples given, the culture is such that quality is not the highest priority. A system based on consensus only really works if core values are shared, or there will always be discontent. Consensus won't work under these circumstances. You'll never be able to 'trust' your colleagues to 'do the right thing'.
If you care about quality, you have to look for another organisation and have a lot of questions about how they assure quality.
Technical excellence is often overlooked by the MBA groups. They will simply walk into a project, pick something perfectly functional and ask you to tear it down for no fucking reason other than to demonstrate "they add value" to the company. They will be really good with the slides and graphs and that's what is visible to management anyway.
Not the framework you developed. Not the fact that your work powers millions of users. To them, you're just a replaceable worker bee. You are only needed when something breaks. Architectural decisions are made by anecdotal experiences by them and it's just stone, paper, scissors all over again.
And when shit blows up right in their faces, it will not be about their judgement or lack thereof - it will be about how you didn't communicate about the issue properly. It will always be you who will be under the bus. And then the bunch of these clowns go and vibe code some stupid-ass product and sell it to gullible investors "wHo NeEds EnGiNeErs?"
And then you read about how 1000s of users' information went public all over the internet post their launch...the very next day.
>If you're in this position (relied upon, validated, powerless), you're not imagining it. And it's not a communication problem. "Just communicate better" is the advice equivalent of "have you tried not being depressed?"
How about "have you tried unionizing?" Because the common theme here is lack of respect which is ultimately limited by your own bargaining power. That means it's only your individual value against the collective will of the company, and the individual is going to lose that fight more often than not (with very rare exceptions for extremely talented and smart people who won the life lottery who are smarter than everyone at a company).
>Ignoring it costs more later, but later is someone else's problem
Given the standard advice to job hop every 1-3 years, and the intern/coop work pattern of semester long stints, is this not just a structural consequence?
Do you gain competitive advantage as a company with longer tenures? Or shorter, even?
Or is it an attitude problem, compare with old people planting shade trees:
“Codebases flourish when senior devs write easily maintainable modules in whose extensions they will never work”
It’s a trust issue. There’s no one more of a PITA than a new team member who joins and starts questioning every little thing and demanding it be changed (the initial questioning is fine, so long as you accept “because” as a reason). OF COURSE any team that’s shipping software will have things that don’t make sense prima facie, because they’re accumulated tech debt or historical accident.
Go beyond identifying all these problems towards solving them. Choose a small problem, where you won’t have to fight and argue, just a little dust bunny you can sweep out of the way. Do it again, and again, and again. This is how you build trust. As you build trust, it becomes easier to seek change.
Additionally, you may also find that not all the little problems are worth solving, and what’s more interesting are the bigger problems around product-market fit, usability, and revenue.
I find OP's communication style abrasive and off-putting, which tracks with them saying they've been coached on this, and found that advice lacking.
Maybe it's still insufficient advice, but it hasn't worked for them at least in part because they haven't figured out how to apply it.
From the post, I see low empathy and an air of superiority, (perhaps earned by genuinely being smarter than their peers-- doesn't make it more attractive).
That's going to cause friction because a team is a _social_ construct.
> Ignoring it costs more later, but later is someone else's problem.
and then the blame could be shifted to the future generations, it's their incompetence after all.
> Correctness wins when the cost of ignoring it becomes impossible to miss: an outage, a customer complaint, data loss. Until then, comfort wins every time.
Those who tolerate comfort-winning aren't engineers and shouldn't be admitted to stand close to engineering systems overall, especially outside the software industry.
That is why I think technical excellent people should be in charge. They are the ones able to see the trade offs. They can see who is actually doing great work. Think Linus, Guido, Larry Wall, or Carmack.
> Authority matching responsibility. That's the only fix I've seen work.
So, if I understood correctly, complaining that his architectural advice for other teams/people was constantly ignored, and his solution is the same thing he was complaining about.
ie The teams he was advising also thought authority should match responsibility - and they did want they wanted and ignored him?
I suspect the author has little to no experience running a commercial organisation.
Business outcome comes first, and it is only rarely aligned with technical excellence. Closing a deal might involve making an unreasonable promise, and implementing it might not require more than an ugly hack, so you go with the ugly hack and make the money.
Comfort could be important but many people don't perform well when comfortable, so the organisation has to add some degree of confusion and pressure to keep them at a productive equilibrium where they don't fall into either apathy or burst into flames.
And yes, the boss decides, not because they are especially accountable or responsible, but because the power comes from ownership. In some organisations this is veiled and workers get a say most of the time, but in a pinch it'll be the higher-ups that actually have that power.
That's exactly what happens in some organizations. I couldn't believe it the first time I saw it, but it is what it is. And the reason is some bosses are addict to consensus. Infuriating but there's really no other option than shrugging off the problems, waiting for staff changes or looking for another job.
OP's dismissiveness of soft skills is a big red flag. Unless you're a solo dev, software development is a social activity, and understanding the social dynamics is key to effecting change.
Your efforts to improve quality could be vetoed by your coworkers for a variety of reasons: they don't care, they don't trust your judgement, they see other things as a higher priority... the list goes on and on. Some of these things can't be changed by you, but some can, and that's where the soft skills come into play.
That's a very strong foundational claim right at the start. And in my experience, a completely false one. Which makes the whole argument that follows it completely unsound.
Also, the author seems to treat the terms "consensus" and "buy-in" as synonymous. They're not, and this distinction can make a huge difference in terms of healthy teams can operate. Patrick Lencioni covers this well in his classic book, "Five Dysfunctions of a Team".
28 comments
[ 3.4 ms ] story [ 49.6 ms ] threadI literally had this discussion with my boss yesterday. I spent time writing up what I already knew to be true (we have systemic issues which are unsolved, because we only ever fix symptoms, not root causes), replete with 10+ incidents all pointing to the same patterns, and was told I need to get the opinions of others on my team before proceeding with the fixes I recommended. “I can do that, but I also already know the outcome.”
> Responsibility Without Authority
This. So much this. Every time I hear someone excitedly explain that their dev teams “own their full stack,” I die a little inside. Do they fix their [self-inflicted] DB problems, or do they start an incident, ask for help, and then refuse to make the necessary structural changes afterwards? Thought so.
Other places I worked it is usually another engineer throwing a spanner in the works. Smaller companies have a lot of pets in the code and architecture. But if you avoid the pets you can change things.
Some organizations do in fact optimize for correctedness, and some people are good at it.
Some people are good in everything (totally possible, universe doesn't care about keeping dichotomies). Maybe that technical guy was only technical up until now because it was what added more value. People often don't consider that.
Right now, we're seeing some small changes in value dynamics. It makes us foster those (mostly pointless) meta-conversations about what organizations are and how people fit in them. But the truth stays the same, both are incredibly diverse.
> Authority matching responsibility. That's the only fix I've seen work. Either you get decision-making power that matches the decisions you're already making, or you find a place that treats your judgment as an asset instead of something to manage.
I don't think the solution is to become some kind of dictator. And I don't think it's about not valuing your judgement.
The key issue is a fundamental misalignment of core values. In the examples given, the culture is such that quality is not the highest priority. A system based on consensus only really works if core values are shared, or there will always be discontent. Consensus won't work under these circumstances. You'll never be able to 'trust' your colleagues to 'do the right thing'.
If you care about quality, you have to look for another organisation and have a lot of questions about how they assure quality.
Not the framework you developed. Not the fact that your work powers millions of users. To them, you're just a replaceable worker bee. You are only needed when something breaks. Architectural decisions are made by anecdotal experiences by them and it's just stone, paper, scissors all over again.
And when shit blows up right in their faces, it will not be about their judgement or lack thereof - it will be about how you didn't communicate about the issue properly. It will always be you who will be under the bus. And then the bunch of these clowns go and vibe code some stupid-ass product and sell it to gullible investors "wHo NeEds EnGiNeErs?"
And then you read about how 1000s of users' information went public all over the internet post their launch...the very next day.
/endrant
How about "have you tried unionizing?" Because the common theme here is lack of respect which is ultimately limited by your own bargaining power. That means it's only your individual value against the collective will of the company, and the individual is going to lose that fight more often than not (with very rare exceptions for extremely talented and smart people who won the life lottery who are smarter than everyone at a company).
Given the standard advice to job hop every 1-3 years, and the intern/coop work pattern of semester long stints, is this not just a structural consequence?
Do you gain competitive advantage as a company with longer tenures? Or shorter, even?
Or is it an attitude problem, compare with old people planting shade trees:
“Codebases flourish when senior devs write easily maintainable modules in whose extensions they will never work”
Go beyond identifying all these problems towards solving them. Choose a small problem, where you won’t have to fight and argue, just a little dust bunny you can sweep out of the way. Do it again, and again, and again. This is how you build trust. As you build trust, it becomes easier to seek change.
Additionally, you may also find that not all the little problems are worth solving, and what’s more interesting are the bigger problems around product-market fit, usability, and revenue.
Maybe it's still insufficient advice, but it hasn't worked for them at least in part because they haven't figured out how to apply it.
From the post, I see low empathy and an air of superiority, (perhaps earned by genuinely being smarter than their peers-- doesn't make it more attractive).
That's going to cause friction because a team is a _social_ construct.
and then the blame could be shifted to the future generations, it's their incompetence after all.
> Correctness wins when the cost of ignoring it becomes impossible to miss: an outage, a customer complaint, data loss. Until then, comfort wins every time.
Those who tolerate comfort-winning aren't engineers and shouldn't be admitted to stand close to engineering systems overall, especially outside the software industry.
So, if I understood correctly, complaining that his architectural advice for other teams/people was constantly ignored, and his solution is the same thing he was complaining about.
ie The teams he was advising also thought authority should match responsibility - and they did want they wanted and ignored him?
Insert fire writing gif here.
Business outcome comes first, and it is only rarely aligned with technical excellence. Closing a deal might involve making an unreasonable promise, and implementing it might not require more than an ugly hack, so you go with the ugly hack and make the money.
Comfort could be important but many people don't perform well when comfortable, so the organisation has to add some degree of confusion and pressure to keep them at a productive equilibrium where they don't fall into either apathy or burst into flames.
And yes, the boss decides, not because they are especially accountable or responsible, but because the power comes from ownership. In some organisations this is veiled and workers get a say most of the time, but in a pinch it'll be the higher-ups that actually have that power.
Your efforts to improve quality could be vetoed by your coworkers for a variety of reasons: they don't care, they don't trust your judgement, they see other things as a higher priority... the list goes on and on. Some of these things can't be changed by you, but some can, and that's where the soft skills come into play.
That's a very strong foundational claim right at the start. And in my experience, a completely false one. Which makes the whole argument that follows it completely unsound.
Also, the author seems to treat the terms "consensus" and "buy-in" as synonymous. They're not, and this distinction can make a huge difference in terms of healthy teams can operate. Patrick Lencioni covers this well in his classic book, "Five Dysfunctions of a Team".