My rails for engineering leadership.

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.

Leadership tools

1. Migrations: the sole scalable fix to tech debt
2. Running an engineering reorg
3. Tools for operating a growing organization
4. Goals and baselines
5. Guiding broad change with metrics

Organizational design

1. Productivity in the age of hypergrowth
2. Managing in the growth plates
3. Staying on the path to high performing teams
4. A case against top-down global optimization
5. Where to stash your organizational risk?
6. Setting organizational direction

Culture

1. Inclusion in the first shift
2. Your philosophy of management
3. Consider the team you have for senior positions
4. Company culture and managing freedoms
5. Kill your heroes, stop doing it harder

Leadership styles

1. Model, document and share
2. Ways engineering managers get stuck
3. Close out, solve or delegate
4. Partnering with your manager
5. Finding managerial scope

Interviewing, hiring and evaluations

1. Roles over rocket ships, and why hypergrowth is a weak predictor of personal growth
2. Cold sourcing: hire someone you don't know
3. Running a humane interview process
4. Acing your architecture interview

Architecture

1. Introduction to architecting systems for scale
2. You can't reason about big balls of mud
3. Fail open and layer policy
4. Developing software oriented architectures
5. Providing pierceable abstractions

Infrastructure

1. Product management in infrastructure engineering
2. The physics of Cloud expansion
3. Infrastructure between cost center and ego trip
4. QoS, cost & quotas
5. From lambda to kappa and dataflow paradigms
6. Building technical leverage
7. Building a software deployment pipeline
8. Technology inheritance

Tidbits

1. Some of my favorite technical papers
2. The briefest of media trainings
3. Notes from "Good Strategy, Bad Strategy"
4. Hosting a paper reading group

---

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.