julian's response was so on point, i wrote a whole nother piece in response to him. the argument for why management really shouldn't be a promotion, how to sell it to your org, and why to try. charity.wtf/2020/09/06/if-…
i've seen a lot of people address this question from the perspective of the newly enmanagered person, who needs to learn a new set of skills; but never from the perspective of why this is better for the org as a whole, or dwelling on the emotional fallout of going back and forth.
i've also seen a lot of people chirp "management is not a promotion, it's a change of career" whilst merrily ensconced in organizations that clearly, unmistakably treat management as a promotion. which bugs me. 🙃
hey there's nothing wrong with a little hypocrisy. the difference between aspiration and reality is what it is.
what bugs me is that i'm not sure if they're aware of it? so i tried to write down the actions an org would take, if they were seriously trying to level the roles
you don't just get to say "management is not a promotion" but then pay your managers more, offer leadership training exclusively to managers, have managers responsible for technical decision-making, etc.
this would be a GREAT thing to anonymously ask engineering teams every year: "do you feel like you need to become a manager in order to have a seat at the table, a say in decisions that impact you, or the influence you would like to have?"
and to ask your managers -- "do you feel like going back to engineering would involve a serious loss of status, access to information, and influence on company decisions? would you be likely to return to engineering if you did not fear that loss of status?"
the other horrifying tweet that inspired this piece was this one:
what so many people seemingly fail to understand is this:
~ tech lead work is management work
~ being a tech lead is a management role
it's simply that you are ultimately responsible for the success of a technical initiative, not for people and their careers or team cohesion.
i've recently been wobbling on the verge of straight-up deciding that SRE is inherently 1) a senior role and 2) a management role as well, but let's throw down with that bomb another night
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I woke up this am, scanned Twitter from bed, and spent an hour debating whether I could stomach the energy to respond to the latest breathless fatwa from Paul Graham.
I fell asleep again before deciding; just as well, because @clairevo said it all more nicely than I would have.
(Is that all I have to say? No, dammit, I guess it is not.)
This is so everything about PG in a nutshell, and why I find him so heartbreakingly frustrating.
The guy is brilliant, and a genius communicator. He's seen more and done more than I ever will, times a thousand.
And he is so, so, so consistently blinkered in certain predictable ways. As a former fundamentalist, my reference point for this sort of conduct is mostly religious.
And YC has always struck me less like an investment vehicle, much more like a cult dedicated to founder worship.
Important context: that post was quote tweeting this one.
Because I have also seen designers come in saying lovely things about transformation and user centricity, and end up wasting unthinkable quantities of organizational energy and time.
If you're a manager, and you have a boot camp grad designer who comes in the door wanting to transform your org, and you let them, you are committing professional malpractice.
The way you earn the right to transform is by executing consistently, and transforming incrementally.
(by "futureproof" I mean "true 5y from now whether AI is writing 0% or 100% our lines of code)
And you know what's a great continuous e2e test of your team's prowess at learning and sensemaking?
1, regularly injecting fresh junior talent
2, composing teams of a range of levels
"Is it safe to ask questions" is a low fucking bar. Better: is it normal to ask questions, is it an expected contribution from every person at every level? Does everyone get a chance to explain and talk through their work?
The advance of LLMs and other AI tools is a rare opportunity to radically upend the way we talk and think about software development, and change our industry for the better.
The way we have traditionally talked about software centers on writing code, solving technical problems.
LLMs challenge this -- in a way that can feel scary and disorienting. If the robots are coming for our life's work, what crumbs will be left for you and me?
But I would argue that this has always been a misrepresentation of the work, one which confuses the trees for the forest.
Something I have been noodling on is, how to describe software development in a way that is both a) true today, and b) relatively futureproof, meaning still true 5 years from now if the optimists have won and most code is no longer written by humans.
A couple days back I went on a whole rant about lazy billionaires punching down and blaming wfh/"work life balance" for Google's long slide of loss dominance.
I actually want to take this up from the other side, and defend some of the much hated, much-maligned RTO initiatives.
I'm purposely not quote tweeting anyone or any company. This is not about any one example, it's a synthesis of conversations I have had with techies and seen on Twitter.
There seems to be a sweeping consensus amongst engineers that RTO is unjust, unwarranted and cruel. Period.
And like, I would never argue that RTO is being implemented well across the board. It's hard not to feel cynical when:
* you are being told to RTO despite your team not being there
* you are subject to arbitrary badge checks
* reasonable accommodations are not being made