The Engineering Executive’s Primer

Will Larson impressed me with his previous book, A Beautiful Puzzle. He has deep experience as CTO at Uber, Calm, and Stripe, and here he focuses on the executive path, which I found useful to understand how my leaders think. Some parts are very, very interesting; the beginning is slow. Certainly a solid resource for an executive; I will return to it in the future.

Notes

🛑1. Getting the Job

• Very interesting: often the exec is picked from the outside to bring a different point of view, usually through the exec network or high-quality headhunters.
• There is also a long list of data to consider in the decision, from salary to IT situation, missing features, and criticalities. Worth rereading one day if in an interview.

🛑2. Your first 90 Days

• Gain trust, make at least a few decisions, but do not rush changes. You will need to understand as much context as possible. Learn.
• If the list of tasks feels overwhelming, pick one or two areas and go deep there first.

3. Writing Your Engineering Strategy

• This should be your Bible, your idea of how to help the business and guide the company, the big picture to apply in day-to-day decisions. You should write it yourself, discuss it, and so on. Examples include things like “keep a max team of 4” or “apply 30% of time to new tech, 70% to core business.”

🛑4. How to Plan

• Very useful part about the financial plan, how it is structured, and how to discuss it with Finance, the team, the vendors, and so on. This is strictly high-level so I will skip.

5. Useful Organizational Values

• How to set up values for the company. It is a long process and you need to set it in stone, make it clear, and ensure it is followed by the organization, starting from the hiring process.
• Some example values: default to vendors unless it is core; do reversible changes; reuse common technologies unless you see 10x improvement… and so on depending on your context.

6. Measuring Performances

• Difficult topic. The key is to know that it is very difficult to measure performance in our field. You can try with tickets done, projects delivered, lead time, delays, incidents, and other KPIs, but you need to keep a rationale and know that those are proxy measures.
• A key part is to deliver these measures to other execs who will not understand the nuance. For example, do not share ticket times and incident KPIs with the CEO, who sees the business involvement, not the day-to-day. Rather, set a goal and measure the progress toward that goal.
• It is an iterative process. Collect the metrics for the parties involved, tell your story, and go back again.

🛑7. M&A

• Not relevant for me; most of the time M&A does not go through and it is a very complex matter.

🎯8. Leadership Styles

1. Leading with policy: For recurring decisions that need to be made consistently by many individuals within your organization, set a general rule to be followed. Enhances productivity but should be clear and approved.
2. Leading from consensus: For infrequent decisions with context spread across a number of different stakeholders, let them decide; you coordinate the efforts.
3. Leading with conviction (Orders): For decisions without any clear proposal, where involved individuals are deeply at odds with one another, or that have outsized, long-term impact on your organization. The difficult ones.

• Handle the three strategies when needed, knowing that many execs are afraid to micromanage or, the opposite, go straight with 3. Policy scales well, consensus for complex matters, conviction when it is needed or the situation gets messy.

9. Manage priorities

• Several framework ideas suggested; those are highly subjective.
• “company, team, self”: prioritize company and team, not your promotion. Boring tech that helps deserves raises, and it has priority over fun activity for devs. However, it risks burnout.
• “eventual quid pro quo.” An evolution of Will’s approach: prioritize the company until you feel de-energized, then you can experiment with new tech. If this balance cannot be achieved for more than 1 year, change or quit.
• Do not exaggerate. Speaking at conferences twice a year helps the company; twice a month it is for you. I do not fully agree with that.

10. Meetings

• Meetings are not useless per se (if they are, skip them). They are often the best backup solution to ensure important information is communicated across the organization, but they are not enough. Make sure information spreads.
• Essential meetings:
  1. Weekly IT Leader meeting to share context and a common agenda
  2. Weekly tech spec and incident review (keep a clear document template)
  3. Monthly with Engineering Managers (1m to share something, 30m about a development topic, Q&A) and Monthly with Staff Engineers (same)
  4. Monthly Q&A (answer team questions; this is likely the opinion they will have about you)

🎯 11. Internal Communication

• Maintain the drip: Communicate on a regular basis, even if you do not have something novel to share. A weekly bullet list is ideal (something human, key deadlines, important topics, brief updates, Q&A offer).
• Test before broadcasting. Review your communication with a few people before sending it to improve clarity and avoid blind spots. It slows the message, but better than confusion.
• Build the packet and keep it short: see Smart Brevity.
• Use every channel: email, meetings, chat, especially if it has a big impact. Many will not read the mail but you will have some loyalists who will spread the message.

12. Prestige

• Prestige can be personal (mostly college and companies you worked with) and company level (to get the best programmers). It is something that someone can gather about you online or by asking, a passive characteristic.
• The majority of successful executives I have worked with do not write online. If you really want to write or enhance your network, better to keep infrequent, high-quality posts and do not stress too much about it.

13. Working with CEO and Peers

• To be effective, you have to be supported by the others. But it is not common. Supported, Tolerated, or Resented? If they support you, they will go out of their way to give you feedback; otherwise they will ignore or oppose.
• Often complex problems have a shared root, and you can find it. A good approach is to reach out to people after a meeting asking for specific feedback, which can give you more insights. You may rarely get something useful.
• It is simpler to help and support a struggling peer than replace them, so conflict is fine, but it should be resolved. Escalate together if needed.

14. Gelling Your Engineering Leadership Team

• Build your own team following your values and strategy; do not be afraid to select and make changes. It will be your first-line ally.
• A team gets messy, and you need to prioritize coordination between team members.
• 3 key causes of internal competition: they do not see other opportunities (so check how you can approach the problem), they are used to seeing a zero-sum game so they prefer taking from others, or they know you tolerate bad behavior. Stop this.

15. Building Your Network

• It is important to have other peers with your same Engineering vision outside the company. You can share tips, advice, and questions. People are glad to share almost anything privately.
• No cheat code. It is an exchange of mutual value; you cannot just take someone else’s network or buy your way in.
• Best way to grow it is to work together. Or cold approach with a specific question (no vagueness).
• Writing is a time-inefficient way to grow it, but if you like that, go on. Otherwise there are networks with VCs or ask your CEO. It is a slow process.

16. Onboarding Peer Executives

• It is important because in the long run you will only be exceptional if every part of the executive team functions well.
• When onboarding a peer executive, your goal is to help them understand the company’s landscape (business, team, project, and process), with a particular focus on the most critical, current issues. What is going to surprise them? What is the most urgent topic? What is your framework?
• Progress will be slow and a matter of faith, since you are different people in different roles. By helping them in the most difficult initial part you can already influence the trajectory.

17. Inspected Trust

• Managers should stop writing code and focus on managing teams. What they truly need is not unquestioning trust but inspected trust, which is a trust-but-verify approach (“trust first, then investigate before acting”). Once you independently validate the issue or idea, you decide.
• Trust is the baseline, but alone it does not solve the issue: it cannot differentiate between good errors (not your fault) and bad errors (you screwed up).
• To investigate, talk to as many people as possible and dig into the topic. Notice confusion. Focus on 1 or 2 critical problems.

18. Calibrating Your Standards

• It is important to match your standards with the standards that your organization upholds, rather than assuming that high standards are obviously right.
• The main problem is trying to do your job effectively but you cannot because of the low performance of a peer. This is seen as your problem and it is not fair, but that is life.
• Changing is difficult, but use a positive approach. Generate excitement.
• In the end, try to align your standards rather than generating noise.

🛑19. How to Run Engineering Processes

• A good process is a deliberate trade-off between quality and overhead. Depending on your stage, here are some common frameworks for managing them (skipped because they are for 500+ engineers types)
  1. Early Startup: for very small companies, either a founder does it, or not
  2. Baseline (50+ hires): Company processes run by HR, Engineering processes by Eng managers. Usually the default, simple and cheaper, and works
  3. Specialized Engineering Roles
  4. Company Embedded Roles
  5. Business Unit Local

20. Hiring

• You need to have an ATS; without it hiring is time-intensive with low return. Also templates, guides, and the usual structure. Simple.
• Be consistent with questions. There is a risk candidates cheat, but you can detect it easily.
• A good tip is to include the recruiter in the weekly team meeting so they can ask questions and learn more about the context.
• Do not rely entirely on your network; it is a risky strategy. Use the hiring process and welcome suggestions.

21. Engineering Onboarding

• Onboarding well and quickly is the key to get your staff productive before the common 3-6 months.
• Different stories, from a small startup (get laptop) to more advanced sessions with small beta projects to bootcamps. If you have more than 10 new hires a month, grouping them in camps is better.
• What a new hire needs is understanding the role, a sponsor to guide them, a manager, and if possible a wiki to get started.

🛑22. Performance and Compensation

• Pretty basic process. Ask managers for feedback, use policies, handle promotions. Twice a year is better.

🛑23. Using Cultural Survey Data

• It is normal to feel somewhat uncomfortable, and maybe even a bit defensive, when working through this sort of feedback. But listen to users.

24. Leaving the job

• When you cannot stop complaining at dinner about your job, it is time to leave.
• First step begins years earlier: set up a team that can work in your absence. Let them learn, go on vacation, delegate.
• Do not make ultimatums nor focus on money. That is not the important part.
• If you start a departure discussion, then you will leave. Maybe months later, but you will. You will ruin the trust.