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
The question is, how can you interview and screen for engineers who care about the business and want to help build it, engineers who respect sales, marketing and other functions as their peers and equals?
It's a great question!! I have ideas, but would love to hear from others.
I said "question", but there are actually two: 1) how to hire engineers who are motivated by solving business problems and 2) aren't engineering supremacists.
Pro tip: any time you see someone confidently opining on what all good CTOs know or do, it is ✨bullshit✨
There is no stock template for CTO, or default set of expectations or responsibilities. It stands alone among the C-levels in that good ones are all over the freaking map.
This may not hold true for publicly traded companies. But in my experience, a good CTO can be:
* over all of R&D
* over engineering, like a VP eng
* like a principal eng or architect
* team lead for special projects
* a great senior programmer
(continued... 👉)
A CTO can also be:
* a great communicator and popularizer
* on the road as a devrel
* a field CTO, whose authority opens doors to big customers
* a product visionary who sweats the details
* more of a cofounder than technical contributor, sharing "company-running" duties w/CEO
Yeah, this is a fair caveat. If you're already a decent senior engineer and manager, it's kind of possible to split your attention between managing a small team and writing code.
But you aren't going to improve at either skill set. Those cycles get devoured by context switching.
Tech lead managers ("TLMs") are a mistake we make over and over in this industry. I've written about this a bit, but the definitive post was written by @Lethain.
My coworker @suchwinston wrote a terrific piece on burnout before the break:
There's a reason why burnout and work/life balance are such evergreen topics, and it's not actually because the world is so terribly harsh and everyone is criminally overworked.honeycomb.io/blog/product-m…
Just to be clear: some places *are* awful, and some people *are* criminally overworked. But burnout and work/life balance are an issue for everyone, not just those people.
I think this is bc there is no real "solution". Each of us has to find and maintain our own equilibrium.
It takes a lot of hard work to become good at technology, and a lot more hard work to maintain your edge in a fast-changing industry.
I don't know of anyone for whom this is _easy_. None of this is remotely natural, from an evolutionary perspective. 🐒
This is an astute point. For all the ink that has been spilled about what observability is or is not, or how generation 2.0 differs from 1.0, it's actually quite simple.
"Observability" was coined to denote the emergence of ✨high cardinality✨ support in telemetry and tooling.
Cardinality, for those new to my feed 🤣 refers to the number of unique items in a set. Gender drop-down with three options? Low cardinality. Gender field you can write to? Much, much higher cardinality.
Metrics can't do high cardinality data. A metric can only be a number.
Logs *can* handle high cardinality data, which is why logs have always been so much more powerful than metrics.
The most useful debugging data is always the high cardinality shit. Request IDs, uncommon strings, whatever. It reduces the search space fast.