More on this book
Community
Kindle Notes & Highlights
It’s easier to gain access to industry information than it is to retrain someone who doesn’t know how to work in your culture. Don’t compromise on culture fit, especially when hiring managers.
Any manager you hire should role-play a few 1-1s as part of the interview process.
You can take it a step further and actually role-play other types of difficult situations, like dealing with an employee who is underperforming, or delivering a negative performance review.
His observation is that most new hires act in self-interest until they get to know their colleagues, and then they move into group interest.
I believe that the best engineering managers are often great debuggers.
What does this have to do with management? Managing teams is a series of complex black boxes interacting with other complex black boxes. These black boxes have inputs and outputs that can be observed, but when the outputs aren’t as expected, figuring out why requires trying to open them up and see what’s going on inside.
Boring meetings are a sign. They may be a sign of inefficient planning on the part of the organizers. There may be too many meetings happening for the information covered.
Therefore, you must always be aggressive about sharing estimates and updates to estimates, even when people don’t ask, especially if you believe that the project is critical or likely to take longer than a few weeks.
This is really hard for engineering managers to deal with. Changes in strategy are where being stuck in “middle management” feels the most unpleasant.
Don’t promise your team exciting technical projects “later,” because the product roadmap for later hasn’t been written yet.
Dedicate 20% of your team’s schedule to “sustaining engineering.” This means allowing time for refactoring, fixing outstanding bugs, improving engineering processes, doing minor cleanup, and providing ongoing support.
The value of these questions is that you start to treat big technical projects the same way as product initiatives.
Take the time yourself to understand the reasons for the move, and even if you don’t totally agree, do your part to help make those reasons clear to your team and help them understand the new goals. The calmer you can be in the face of these changes, and the better you can show (or fake) enthusiasm for the new direction, the easier the transition will be for your whole team.
Managers who don’t stay technical enough sometimes find themselves in the bad habit of acting as a go-between for senior management and their teams. Instead of filtering requests, they relay them to the team and then relay the team’s response back up to management. This is not a value-add role.
You’re capable of making hard decisions without perfect information and willing to face the consequences of those decisions.
Reminding people of their commitments by asking questions instead of giving orders.
Often a great VP of Engineering is described as having a good “ground game.” This person is capable of dropping into the details and making things happen at a low level.
Let’s start by talking about what a CTO is not. CTO is not an engineering role. CTO is not the top of the technical ladder, and it is not the natural progression engineers should strive to achieve over the course of their careers.
The CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and its own ideas.
“Wanting to be a CTO (or VP of Engineering) is like wanting to be married. Remember that it’s not just the title, it’s also the company and the people that matter.”
Finally, never underestimate how many times and how many ways something needs to be said before it sinks in. Communication in a large organization is hard. In my experience, most people need to hear something at least three times before it really sinks in.
Ask for advice. It sounds contrary to my advice to bring solutions, but nothing shows respect like asking for someone’s advice.
I believe the struggle with respect is a side effect of the current tech culture, which tells us that engineers are the smartest people in the room.
As the senior-most person in an organization, you’ll be watched more closely than you’ve ever been watched in your life. Your presence causes people to focus all of their attention on you.
This role, played by the senior leader of a functional area (the CTO plays it for technology, the CFO plays it for finance, etc.), sets the baseline of what excellence looks like in this function. I call it “True North.”
True North leaders rely on the wisdom they’ve developed over time to make fast decisions when they don’t have time to delve into all the details. If you want to become this type of leader, you must spend enough time early in your career to hone these instincts in order to be comfortable making fast judgment calls.
A common failing of first-time CTOs is to underestimate the importance of being clear and thoughtful about the culture of the engineering team.
One of the greatest writings about organizational politics is a piece called “The Tyranny of Structurelessness” by Jo Freeman.
John Gall’s book Systemantics:1 A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
“Happiness and positivity is a choice” is actually one of the core values of Rent the Runway, and I would not say that I came from a work background of happiness. In fact, I came from a fairly professional and critical work culture. But I learned to appreciate the value of looking at things in a positive light.
Using the core values to coach people in areas where they are misaligned can help you articulate what otherwise may feel like just ambiguous friction.
Provide many early opportunities for advancement. Some people advise having a lot of levels toward the beginning of the ladder to account for the fact that early-career engineers expect frequent raises and promotions.
There’s a saying in politics that “a good political idea is one that works well in half-baked form,” and the same goes for engineering processes.
For the most part, code reviews don’t catch bugs; tests catch bugs.
Code review is largely a socialization exercise, so that multiple team members have seen and are aware of the changed code.
instead of calling the process a postmortem, many have started calling it a “learning review” to indicate that its purpose is not determining cause of death but learning from the incident.
The value of architecture review is in preparing for the review.
Great managers are masters of working through conflict. Getting good at working through conflict means getting good at taking your ego out of the conversation.
For me, having a meditation practice has been essential to developing self-management and self-awareness. Meditation isn’t a cure-all, but it can be a useful exercise to practice that awareness of your own reactions, and for that reason I recommend trying it for a while if you are interested. Some of my favorite resources include the podcasts on tarabrach.com and the writings of Pema Chödrön.
One other trick I use to get away from my ego is curiosity. I also have a daily habit of writing a page or two of free-flow thoughts every morning, to clear my mind and prepare for the day. I always end with the mantra “Get curious.”

