July 1, 2018.
I first started managing in a vacuum, quickly becoming the only engineering manager in a struggling startup, and making it up as I went. I was a terrible manager, and I'm grateful for the folks who put up with me during that period. I didn't have a structured approach to management, career growth, or coaching; I tried to make it one day at a time.
The depth of my gaps only became apparent to me as I began to support other managers. I distinctly remember one asking me for advice on how to handle a situation, and I told them this was an opportunity to develop their own style of management, and there wasn't any one way to do it: do what feels natural and it'll work out. That isn't the worst advice I've ever given someone, but it was pretty unhelpful.
Software engineering management, particularly in Silicon Valley, is exceptional for how inexperienced the typical manager is, and how little training we provide for this critical role. As we gain mastery, we should indeed be developing our own styles that mesh with our personal strengths, but there is so much more we can do a lot more to support new managers in the transition from novice to journeyman, and from journeyman to master.
My experiences working with new managers, combined with my own flailing, have lead me to develop a somewhat unusual approach to management, centered on providing strong standard rails to raise the floor for performance and outcomes. Early on I erred in making these mandates. Over time I've learned to frame them as norms, and that time spent explaining the rationale is far more important than on the expectations.
Much of what I've been trying to do in my blog over the past few years is to document these rails and the thinking behind them, with the hope that they can be useful beyond the teams I work with directly. In particular, I hope they can be useful to folks who are starting to design and operate entire organizations, those mythological beasts cobbled together from people, precedent and policy.
This collection captures the rails that've helped me and the leaders I've partnered with succeed in the growing, unstable and sometimes absurd field of engineering leadership.
I've written a lot, although in another sense I've only just begun to write what can be and what needs to be written about developing and operating as a leader in engineering. I'll keep writing.