The Things That Don't Change
Technology changes fast. The fundamentals of building good engineering teams have barely changed in 22 years.
Trust is the foundation. Teams that trust each other ship software. Teams that don't, don't. Trust between engineers, trust between engineering and product, trust between the team and leadership. All of it matters. You build trust slowly through consistency, honesty, and following through on what you say.
Hiring for attitude is not a cliché. I've hired brilliant engineers who were destructive to team culture. I've hired engineers who looked weak on paper who became cornerstones of the team. Technical skills are assessable and learnable. Intellectual honesty, curiosity, and collaborative instincts are harder to develop.
Psychological safety enables performance. Environments where people are afraid to be wrong produce individuals who avoid taking risks and hide mistakes. Teams need to feel safe raising concerns, admitting errors, and proposing unconventional ideas. Your job as an engineering leader is to model this — be visibly wrong occasionally, attribute good ideas to their originators, take blame and distribute credit.
The Things I Got Wrong
Over-indexing on technical brilliance. Early in my career, I valued deep technical skill above almost everything else. I've learned to value it in balance with communication, reliability, and collaborative orientation. A team of 10/10 technical engineers with poor collaboration skills will be outperformed by a team of 8/10 engineers who communicate well and trust each other.
Undervaluing documentation. I've watched knowledge walk out the door with departing engineers too many times. Documentation isn't a nice-to-have — it's the team's memory. Runbooks, architecture decision records (ADRs), system diagrams, onboarding guides. Invest in them.
Confusing activity with progress. Busy engineering teams aren't necessarily effective engineering teams. The healthiest engineering metrics I've tracked are outcome-based: deployment frequency, lead time for changes, mean time to restore, change failure rate. These reflect real capability, not activity.
On Being Hands-On as a CTO
People sometimes imply that a CTO writing code is a sign of strategic failure — that if you're technical, you're not strategic enough. I disagree.
Staying technical keeps me honest. I know what the codebase looks like. I feel the friction in our deployment process. I understand the pain in our observability setup. I can evaluate AI tooling because I use it, not because I've read about it.
This doesn't mean CTOs should be in the critical path of feature delivery. But maintaining technical depth — reading PRs, occasionally writing code, pairing with engineers on complex problems — makes better strategy possible, not worse.
The One Thing I'd Tell My 2006 Self
The technical problems are the easy part. The human problems — building trust, communicating clearly, creating environments where people do their best work — are the hard part. And they're the part that determines whether great technology actually gets built.
Start there.