Camille Fournier, an engineering leader and author of The Manager's Path, writes about senior engineering skills and engineering management.
HN commenters cite her work on manager READMEs and The Manager's Path as useful reading, including its point about changing relationships with former peers.
Some people are inherently unhappy but also keep an eye out for unhappiness caused by misalignment, misunderstanding, or disengagement relating to feelings of disempowerment.
Compensation is important up to a point but nobody likes feeling like they are wasting their time and powerless to make positive change.
> No one likes to do Oncall or operational or migration work or deal with mess left by earlier group.
No one likes doing these things if they don't see the point, if there's no buy-in and the work is just a directive from above, if everybody feels like they are treading water and not making any progress, etc...
There are too many possible contributing factors to list them all but most solutions involve listening, communicating, and making small changes that compound over time.
Build teams that: make progress, understand why their work is important, have meaningful feedback loops.
Some good starting points:
[1] The Management Flywheel - https://skamille.medium.com/the-management-flywheel-c076f398969b
[2] Work is Work (In which returns diminish) - https://codahale.com/work-is-work/
[3] Model, document and share - https://lethain.com/model-document-share/
[4] Why limiting work-in-progress works - https://lethain.com/limiting-wip/
Camille Fournier: the manager's path
Eye-opener (worst take away / for me - you can't be friends with devs-under-you anymore. Or with anyone techie it seems. Probably depends on company-founders' culture - if small and new - or politics - if older and/or bigger)
some more of hers here: https://skamille.medium.com/an-incomplete-list-of-skills-senior-engineers-need-beyond-coding-8ed4a521b29f
Also.. you can't be everything. Choose your poison (or if it has been pre-chosen, find out what it is sooner than later), hire other people for other stuff:
https://www.allthingsdistributed.com/2007/07/the_different_cto_roles.html
more on the topic:
https://news.ycombinator.com/item?id=20642423
And... think/assess very-very well - all-the-time - How much trust you have got.. and for what. YMMV. Sometimes "CTO" is only a parrotizing label for investors to flock on. Sometimes it's for real.
have fun
So many - I'm going to share a few that come to mind quickly, rather than agonizing over picking the best possible results.
Tim Bray: https://www.tbray.org/ongoing/
Julia Evans: https://jvns.ca/
Tom MacWright: https://macwright.com/
Jacob Kaplan-Moss: https://jacobian.org/
Lea Verou: https://lea.verou.me/
Will Larson: https://lethain.com/featured/
Camille Fournier: https://skamille.medium.com/
Haki Benita: https://hakibenita.com/
Brandur Leach: https://brandur.org/articles
Thanks for sharing this! I'm sure your team will benefit from the clarity with which you outlined your values and working style. Camille Fournier wrote a piece on "manager READMEs" that, if nothing else, is worth considering. I'm less opinionated about the practice, but I definitely am glad I read her article:
https://skamille.medium.com/i-hate-manager-readmes-20a0dd9a70d0