|
|
|
|
|
by geoduck14
1688 days ago
|
|
>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. I NEED you to help me make things better. |
|
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.