This hit so close to home for me. At my last two jobs, I've simply burnt out from hitting this sort of wall over and over.
Everything I suggested was just flatly
denied as impossible
[...]
I feel strange because I've seen this same thing
for my whole career and I still try fight for
what's right when others appear to moan and carry on.
For anybody (100% rightfully!) wondering if it's my fault: (1) I've been consistently praised in reviews as a good communicator (2) I always operate by the maxim "don't just complain -- instead, offer solutions" and I see that you do too. (edit: That's not to say that I couldn't be communicating things better. Certainly, I don't believe I've reached some level of perfection there)
I think the reality is that this kind of change can't originate from the in-the-trenches folks at the bottom of totem pole. Management will never let individuals waver from their short term goals.
The only times I've seen developer pain-points successfully addressed in a sustainable way, it's because there was a dedicated team allocated to that sort of thing: a "developer experience" team, or some equivalent.
(Although, the issues you ran into are kind of an org issue in addition to a developer experience issue)
>The only times I've seen developer pain-points successfully addressed in a sustainable way, it's because there was a dedicated team allocated to that sort of thing: a "developer experience" team, or some equivalent.
I came to this conclusion after watching the place I work at for 2 and a half years fail to implement any of the grand ambitions management had in their heads. We wanted code review, pull requests, build pipelines, automated releases, updated OS's, logging, disaster recovery, you name it. No one had the experience, time, or energy to implement it, so it falls on one or two juniors (me) to quickly learn and implement while learning. No one is hired with experience in any of these topics, only fresh-grads that will replicate the garbage you're trying to get away from are hired, because they will on paper be producing more features for less financial cost.
I think they key is to find people who have put effort into figuring out what good is, and are frustrated and care enough to enact change.
Similarly to your org not having a dedicated DX team being the reason, dedicated teams will happily dissapear into a void of non-delivery as their purist vision, unconnected with reality, will simply never apply to your stack, and thus you'll never use it.
End of the day, different things work and fail. The key is almost always the quality of people, their motivation and how many road blocks you put in front of them.
dedicated teams will happily dissapear
into a void of non-delivery as their purist vision
I've sort of seen that happen, but of all the issues being discussed, that seems the easiest to avoid.
1. Rotate team members onto and off of the DX team, so they don't lose touch with reality.
and/or
2. Have the rest of developers vote (or otherwise have direct input on) on the DX team's priorities and products. The other developers are the stakeholders here.
> because they will on paper be producing more features for less financial cost.
And from a business perspective, that is the correct choice.
So make a better business case. Inform them that after investing Y hours on refactoring X, future development is expected to happen M% faster with N% less bugs. New features can be expected to be developed, tested, and shipped to production in S% less time.
But be realistic. Don't make promises that you won't actually meet when the time comes.
You're making this sound simpler than it is, I think. For the following discussion assume we're talking about management that is smart and wants the dev team(s) to succeed but is racing hard to hit various external deadlines and does not have a technical background.
Inform them that after investing Y hours on
refactoring X, future development is expected
to happen M% faster with N% less bugs.
I've tried variations of this to sporadic effect. My elevator pitch is/was essentially, "let's devote 10% of our developer resources to making the other 90% more productive, rather than having 100% of our developers suffer these slowdowns and problems."
(I chose 10% because we had 30 developers at the time and generally had teams of 3 developers. So, one dedicated DX team...)
Do you have any articles, case studies, etc of how to express this to management that is generally oblivious to the day-to-day, in-the-trenches, experiences and pain points of developers?
What you're saying sounds great to me, who is a developer, but how would you come up with halfway realistic numbers for Y and X?
The best thing I could think to do is have the team minutely log all lost minutes productivity caused by delays and inefficiencies that the proposed fixes could address.
But even that's tricky. For example, at one of my previous positions, the build pipeline could take hours and could randomly fail.
The only way to maintain any semblance of productivity would be to juggle 3-4 tickets at once. This was incredibly challenging, and productivity took a massive hit due to the frustration and context switching.
However, even if I had logged those experiences down to the minute, there weren't any literal downtime minutes. It was more a matter of juggling five tickets at once that should have taken one hour each, but instead they took five hours each because I was context switching faster than the Linux kernel itself.
New features can be expected to be developed,
tested, and shipped to production in S% less time.
This sounds good to me, a developer but again, I'm not sure how to express this to management. It's not like "one feature" is some standard unit of measurement - the time to shipping "one feature" varies by orders of magnitude.
Scrum and its much-maligned "story points" are a possible solution here, as far as management is concerned, assuming both developers and management have bought into that concept and are using it correctly.
> Do you have any articles, case studies, etc of how to express this to management that is
> generally oblivious to the day-to-day, in-the-trenches, experiences and pain points of developers?
It is the "generally oblivious" that is the problem. Log holdups whenever a ticket takes significantly longer than the estimate. And be specific as to what the holdup was.
> What you're saying sounds great to me, who is a developer, but how would you come up with halfway realistic numbers for Y and X?
The same way that I come up with halfway realistic numbers for any other dev work. I pull it out of my donkey. Then double it.
> The best thing I could think to do is have the team minutely log all lost minutes productivity
> caused by delays and inefficiencies that the proposed fixes could address.
Yes, log it! It does not have to be by the minute. Honestly, if the holdups are only causing minutes of delays, then they're not so bad unless your ticket take only minutes to complete anyway. My general rule is to log any holdup of more than half an hour, or more than 10% of the time estimated to develop a feature/bugfix. Very loosely, of course.
>I think the reality is that this kind of change can't originate from the in-the-trenches folks at the bottom of totem pole.
I'm a manager. Please. PLEASE don't believe this. In-the-trenches folks ARE powerful. Really. I promise. I can't implement change if YOU don't do it. I don't know what sucks if YOU don't tell me.
Seriously, though: I firmly believe that most managers do think and act like you do.
(I've been in lead and/or management-lite roles myself; I don't view management as some weird or evil "other")
But, I think it only works if that sort of change is valued all the way up the org chart and folks at each level are empowered, incentivized, and motivated to address the pain points of the folks below.
If the org chart is more than N levels deep, then I think this becomes practically impossible. Managers feel the pain of their direct reports deeply and acutely and absolutely want to make things better: after all, it is in their best interests as well. But a manager won't feel or even understand the challenges of folks N levels below; it's probably not even practical to expect this.
(I'll let others argue over the exact value of N above)
That's why I don't think the situation can be resolved without some sort of dedicated resources allocated to developer experience. The most obvious answer (for engineering orgs big enough to support it) would be dedicated developer experience teams. For teams that lack the headcount to dedicate engineers to it full time, an alternate solution could be dedicated chunks of time -- "hackathon Fridays", etc.
I‘m working in a strongly hierarchical org, whit very high N number. What shocking me and blocked good ideas or solutions is that: The persons in charge, empowered to make decisions are so far from reality. And the outcome of their decisions has no effect on their lives… And not because they are evil, just unable to understand the problem. (Once some guy asked, why we put bugs in the code…) Now I fight to change this doing a half management half coder job. But thats hard, I am close to total burnout…
I‘m working in a strongly hierarchical org,
whit very high N number
The persons in charge, empowered to make
decisions are so far from reality
Yeah. I've seen it happen when managers are literally just a level or two up and don't come from an engineering background.
I think it's inevitable, honestly. I think it's fundamentally impossible for management to really understand or respond to in-the-trenches stuff. That's like tasking the mayor of a large city with sweeping the streets or physically fighting crime themselves, in person. They literally cannot spend enough hours in the shoes of the folks under them to understand that stuff.
And, that's fine. Management just needs to have the humility to understand that, and has to empower people/groups that do have their boots on the ground to fix those problems.
It's not unique to this industry, although I do think the newness and explosive growth of our industry may make it particularly prone to this kind of thing.
I see your point. In my BigCo I don’t see real empowering. I agree with you this is a key factor.
My dilemma should I leave or not? Is it better or worse in other place? My helplessness is, I reached limits where I know I can‘t improve the situation anymore. But I see a general pattern and so I am pessimistic to find a better place…
I think the reality is that this kind of change can't originate from the in-the-trenches folks at the bottom of totem pole. Management will never let individuals waver from their short term goals.
The only times I've seen developer pain-points successfully addressed in a sustainable way, it's because there was a dedicated team allocated to that sort of thing: a "developer experience" team, or some equivalent.
(Although, the issues you ran into are kind of an org issue in addition to a developer experience issue)