This week’s piece was originally published as a subscribers-only guest post over at Gergely Orosz’s The Pragmatic Engineer on March 22. It is reprinted here, free and in full, with Gergely’s permission.

While this targets primarily VPs of Engineering in a scale-up context, the principles and practices I share are entirely applicable at all levels of the organization. In particular, they will help you develop solid working relationships with any non-technical stakeholders.

It’s much longer than usual for the Hagakure, but I hope it’s worth your precious time and attention. And I would love to hear of your own experiences. Comments are very welcome!

Q: “I joined as a VP of Engineering at a scaleup with aggressive growth plans. My CEO is not technical. How can I set myself up for success?”

Buckle up because it’s going to be bumpy, painful, often frustrating, and potentially wonderful. At this point, you are no longer “just” building a product. Now, you’re building a company, too. The choices you make at this particular stage will have an outsized impact upon the future of the business. No pressure, right?

Through the lens of my own experience as a VP of Engineering (both as an operator and now coaching many who are knee-deep in it), I will attempt to boil down this key role to its essence. When things get crazy – and they will get crazy – this will help keep you grounded, principled in the decisions you make, and confident in the actions you take. It won’t tell you what to think, but it will help you in how to think.

We will cover:

1. Start with the end in mind. The importance of this approach.

2. Your role as a leader. What is it, really?

3. The mindset of an effective VP of Engineering. Approaches to have more good days than bad.

4. Learn, adapt and improve. And how to do this all the time.

1. Start with the end in mind

“If one does not know to which port one is sailing, no wind is favorable.”

— Seneca

“What is your goal?” is perhaps the question I most often ask the engineering leaders whom I coach. Too often we fall into the trap of doing things for no good reason. Because the people and budget you have will always be scarce, it’s critical to be picky about how you deploy what you have. And without clear objectives, how can you possibly know what you and your team need to become?

Where are you going?

While the nitty-gritty of the business might not be what gets you up in the morning, you must develop a solid high-level understanding of it. You should be able to explain to anyone what the main business metrics are and what tends to drive them. As the VP of Engineering, you are a translator between the engineering organization and everyone else.

A financing round is a means to an end. What is this end, in the case of your company? Consider asking your CEO questions like:

• What growth are we expected to deliver based on this round?

• What needs to be true for us to raise again?

• Which major constraints do you currently see?

• What are you most pessimistic and most optimistic about?

• What is our current business strategy to achieve our goals?

This last question is particularly important, because your engineering strategy will hang on it.

Who do you need to become?

With a good idea of the next destination, which habits, practices and principles will get you and your team there? When Colin Breck, a senior staff engineer at Tesla, became a team lead back in 2016, he was very intentional about the standards of performance he expected from his organization. In a classic blog post, he wrote:

“I want our team to have a reputation for delivering very high quality software systems and, at the same time, being very aggressive in evolving the systems to deliver valuable innovations to the business. This can’t happen without the right investments in the technical practices that lead to good software development: intentional design, code reviews, pair programming, static analysis, automated testing, automated deployments, monitoring of production systems, and so on.”

In my case, some of my values are a belief in self-organizing teams, putting teams above individuals, and creating leaders not followers. It is my conviction that these drive an engaged, productive and ever-improving engineering organization. Which values will matter for you?

Remember that as a leader, whether you like it or not, you lead by example – good or bad. The responsibility of upholding standards rests on your shoulders more than anybody else’s. Take the time to think about what is non-negotiable for you, articulate it to your team, and don’t compromise on it.

With that backbone in place, what should you then be paying attention to?

2. Your role as a leader

One of my mistakes as a first-time VP of Engineering was focusing almost entirely on my engineering team at the expense of other constituencies and stakeholders. This was akin to trying to run with my shoelaces tied together, as I was missing out on creating the necessary shared context with all involved.

The Jobs To Be Done framework starts from the premise that as a business, your customers are “hiring” you to do a job for them. This framing helps you to uncover their needs and work toward meeting them. Same applies to your VP of Engineering role:

• What job is my CEO hiring me to do?

• What job are my peers (e.g. others “heads of”) hiring me to do?

• What job is my team hiring me to do?

These three questions help you frame what I call directions of concern that you must keep in mind at all times.

What job is my CEO hiring me to do?

Many VPEs simply don’t have this conversation, assume everything, and then wonder why the CEO “doesn’t get it.” It is your role to help them understand it. The challenge with a non-technical boss is that they will likely not have a good grasp of how engineering works ‘under the hood.’ Many CEOs had traumatizing experiences which tainted their perception of engineering.

Help your CEO understand how engineering works. Walk them through the end-to-end software development lifecycle, where you see the existing pain points and constraints, what your plans for alleviating them are, and what the business gains from it.

A non-technical CEO will still frequently question why a specific feature or project isn’t easier, faster or cheaper to build. It’s easy to get frustrated when this happens. Catch yourself – and become curious instead. What might explain your CEO’s perspective?

Instead of trying to justify why your plan is the correct one, ask questions. Aim to clarify their position and what they are comparing this against. Clarifying not only helps refine your argument; it also makes the CEO feel heard.

As the gaps in understanding between you and your CEO are filled, the whole thing frequently becomes a non-issue. As author Stephen Covey writes in the classic book The 7 Habits of Highly Effective People:

“Seek first to understand then to be understood.”

A typical failure between CEOs and their VPs is a misalignment on what success looks like. Without alignment, it’s unlikely the relationship will be productive. In extreme cases, the CEO becomes a micromanager, meddling with the internals of your team. You don’t want to be in that hell and if you take extreme ownership of your role (which you should), you won’t be.

Think of it as defining an interface between you both: what does the CEO care about coming from engineering and how will you agree to measure it? Typically this will be some delivery metrics, but some CEOs are also interested in the engagement and happiness of teams, too. Whatever it is, work together on defining this interface, keep it as a backdrop in 1:1s, and refine it as you go along. Rule of thumb: minimize surprises.

What job are my peers hiring me to do?

Tech is everywhere in startups these days which means almost every department essentially has engineering needs. A classic example is the marketing team wanting to spin up their own engineering team because product engineering isn’t giving them any bandwidth. Sound familiar?

It doesn’t have to be this way. You will never have enough resources to cover everything everyone wants. But the good news is that not everything is truly necessary. You (hopefully) don’t just go and build whatever your customers tell you they want. Instead, you understand their pain points and then decide how to address the most critical ones in your product. Likewise, you should treat your peers with the same curiosity and interest:

• What are their goals?

• What are their priorities?

• What is constraining them?

• What are they hoping your team can help with, and when?

• What is their understanding of how engineering works?

Your goal should be getting to the core of what matters to them, and then speaking to that. In my experience, people are fine being told what they want is not possible. What they hate is false promises, or being ignored.

The collaboration with your Product counterpart is especially critical. Spend a lot of time together building shared mental models of how you’ll tackle the why, what, and how between your teams, and how they’ll work effectively together.

What job is my team hiring me to do?

At its most essential, the VP of Engineering role is to enable a framework and create discipline around it. Some say you are the ‘gardener who tends the soil in which beautiful flowers can bloom.’ Or that you ‘provide the canvas for your team to paint great works of art.’ Or the classic ‘provider of guardrails’ between which productive work happens. All of these have a kernel of truth.

Why a framework, you ask? In a nutshell: decentralized decision-making. You must bias towards providing context over control. The reasons are plenty:

• It’s the core of agility. Velocity matters, and if shifting direction depends on a bunch of sign-offs and “alignment,” you’re dead in the water. A nimble organization is quick to sense and respond only once everyone has that ability.

• It drives innovation. Centralized processes imply that some elite group knows what should be done, and everyone else executes. That’s poisonous to creativity. Centralization may help execution, but it’s a killer of innovation.

• It’s motivating. Autonomy is a necessary condition for humans to thrive. True autonomy implies having choice. If I have no choice in what I do or how I do it, I’m not in charge of my own destiny. How exciting is it to be a cog in the machine?

• It enables delegation. The more decisions every individual contributor is able to make, the fewer meetings you feel compelled to be in. Good news for you and your managers. Are you starting to see a way out of your Tetris-like calendar?

• It’s the fuel for learning. We learn by trial and error. But we don’t learn much (if anything) from decisions we didn’t make. Let folks make their own decisions – and hold them accountable for learning from what happens. Learning compounds; the more you learn, the better you get at learning.

As the leader, you have to continuously ask yourself, what will enable each of my team members to make the best possible decisions within their scope? This is where having a clear strategy is key.

Engineering Strategy

Speed alone isn’t enough. Going really fast where you shouldn’t go, is a recipe for disaster. I prefer to think of velocity; speed coupled with direction. That’s what engineering strategies, in part, enable. When everyone is a vector pointing in the right direction, we can more confidently accelerate.

Perhaps no word has been more abused in the business world than “strategy”. But it doesn’t have to be that way. As Richard Rumelt writes in his seminal book Good Strategy Bad Strategy (emphasis mine):

Rather, the term “strategy” should mean a cohesive response to an important challenge. Unlike a stand-alone decision or a goal, a strategy is a coherent set of analyses, concepts, policies, arguments, and actions that respond to a high-stakes challenge.

I want to rehabilitate the idea of strategy by focusing on two key aspects of a good strategy:

• It’s a cohesive response to an important challenge. This means it must be a one-stop shop for clearly understanding the situation at hand, why it matters, and how it will be tackled.

• It includes action. Most strategies forget the most important detail: what will we do? Rumelt reminds us that “execution problems” typically mean strategy got confused with goal setting. That’s just hope, and hope is not a strategy.

How to write a great engineering strategy is beyond the scope of this piece, but fortunately there’s plenty of good resources about it. I recommend the writings of Will Larson, Mathias Meyer and Pete Hodgson.

Note that these strategies can be nested. A top-level engineering org strategy which is necessarily focused on the big picture, can then include “sub-strategies” that serve as finer-grained guidance across multiple domains:

• Engineering Strategy

  • Technical architecture

    • Microservices

    • CI/CD

    • …

  • Software Development Lifecycle

    • Coding standards

    • Code review

    • …

  • Recruiting

    • Hiring process

    • Onboarding new teammates

  • Build vs. Buy decisions

  • Specific projects (i.e. a technical migration)

While it may take longer to build these documents collaboratively, it’s an investment that pays dividends every single day – including when onboarding new joiners. A good set of engineering strategy documents is a wonderful mechanism for creating clarity, leading to better decisions consistently.

The “Top of Mind” Email

Strategy is not a one-and-done thing. It must be repeated, often. One of my favorite tools for this is something I learned from Patrick Kua which I call the “weekly top of mind.” If a set of engineering strategies is a mechanism for clarity, this is a mechanism for discipline.

Every Friday morning, I would send an email to my entire team (cc’ing my peers in the leadership team) in which I shared my current thinking. While this might sound borderline narcissistic, the idea is that if I’m doing my job right, the most important things should be what’s on my mind. This allowed me to check a few boxes every week:

• Reinforce priorities. When there’s abundance (of people, money, etc.) we start sucking at prioritization. Everything goes. I tried hard to keep the team centered on what was most important for us at that particular moment.

• Maintain shared context. As a member of the leadership team, there was often context or news I learned from leadership team meetings that I felt would be important for the team.

• Showcase what ‘good’ looks like. When a team member would do a great job on something meaningful in our culture (e.g. a really well written RFC document), I would showcase it for all to see. This helped set our standards of performance, and doubled as appreciation and gratitude.

• Share learning resources. I would disseminate links to resources on whatever we were trying to improve on (e.g. something about Theory of Constraints when improving our development flow, or how to conduct great technical interviews.)

Having a structure for this email and then collecting notes and ideas throughout the week made the writing less painful and more efficient. At some point, I could crank one of these out in under an hour – and considered it one of highest-leverage activities I could do.

3. The mindset of an effective VP of Engineering

I have no problem saying that I got quite burnt out towards the end of my first VP of Engineering gig. That was largely because I put myself last. But I can also confidently say I learned to do better. The following five ideas helped me have increasingly more good days than bad:

1. The Dichotomy of Control. There is so much in startups that you simply cannot control – and a lot of the stress comes from trying to. The dichotomy of control in Stoicism reminds you to focus your energy on what you can control (e.g. what you do, how you react) and to leave the rest to fate. As the late football coach Bill Walsh used to say, “the score takes care of itself.”

2. Pay attention to what has your attention. Your attention directs where your time and energy goes. Everyone’s time is precious, but yours as VP of Engineering is particularly so, given you have by definition the largest scope. You have to pay attention to what you’re paying attention to. Is it serving your goals? As Naval Ravikant put it, “run your mind in debugging mode.”

3. Pareto is your friend. The Pareto Principle states that roughly 80% of consequences come from 20% of causes, a nearly universal law. What are the vital few activities (as opposed to the trivial many) you should be engaged in that will create 80% of the positive impact for your team? For example, time spent on improving the hiring process itself yields better hires, which makes everything else easier. That’s leverage.

4. Mind the Rider and the Elephant. As engineers, we usually default to appealing to the mind – the rider. But as the Heath brothers tell us in their book Switch: How to Change Things When Change Is Hard, you also have to appeal to the elephant – the heart. Once I learned that the rider is hopeless if the elephant refuses to move, I understood you need to appeal to the heart, first. Game changer.

5. Reject zero-sum thinking. When things heat up, it’s easy to slip into an “us vs. them” mindset. That’s when zero-sum thinking takes over. Approaching problems as challenges that you intend to solve collaboratively elicits the best from others, too. Less “either/or” and more “Yes, and…” is the gateway to better collaboration.

Share

4. Learn, adapt, improve – all the time

Customers are the only real judges of the value of whatever you build. Hence, you have to put your best guesses in their hands quickly, and learn from what they do with it – what Eric Ries calls the “Build-Measure-Learn” loop.

Likewise, if you look at your engineering organization as a product to be continuously improved, the same exact model applies. Every change in structure, process, or even people, should have a hypothesis attached implying a key question; what will be true if this change is successful? For example, “if we implement work-in-progress limits, we should see a decrease in overall cycle time.”

Learning is not optional

Learning, adapting and improving is way more important than racking our brains trying to get everything right, off the bat. No matter what your starting point is, if you learn fast, inevitably you’ll figure things out and get really good. This has an interesting and desirable side-effect; it relieves you (and everyone else) from the pressure of having to know everything upfront, or making the perfect decision. In an uncertain world, adaptability eats predictability for breakfast.

The infamous sprint retrospectives are a good example. While this is technically a Scrum artifact, self-reflection writ large certainly isn’t. Whatever the mechanism, each team must come together regularly and engage in real talk towards its own self-improvement. Too many teams blindly follow the retrospective format du jour and lose sight of what matters, which is finding out what’s the next small step team members can take together to become a better team.

As the VP of Engineering, your job is not to run the retrospectives yourself, but rather to make sure these not only happen, but are themselves increasingly more effective. Create the discipline of constant learning by whatever means necessary and at some point you won’t have to – it becomes part of the lifeblood of the organization.

Feedback Loops

As an engineer, you run your tests and it’s either green or red. That’s a very short feedback loop right there. When it comes to engineering management, the feedback loops aren’t so obvious anymore, yet they’re critical. Without them, learning and improvement can’t happen.

Here are a few examples of metrics and associated feedback loops:

• Cycle time. How long does it take on average between development starting on a piece of work and it being in production? This is a quantitative metric of flow. Better flow is good for the “build-measure-learn” cycle we talked about earlier. So if a team makes a change in its process, how is cycle time being affected?

• Team health. What is a healthy team? This is a subjective concept, and can be a compound of qualitative (e.g. ease of release, learning, sense of autonomy) and quantitative (e.g. the DORA metrics). If a team changes one of its processes, what are we expecting to see in these metrics?

• Engagement surveys. Employee engagement tools are often just tokens of good intentions. But they can be golden in helping you and your managers keep an ear to the ground; after all this is the ‘voice of the people.’ What are they saying? Think of it as the compound reaction to all your efforts as a whole in leading the engineering organization.

In Closing

In engineering management, it’s easy to miss the forest for the trees – there is always so much going on. You must consciously and regularly take a step back and reassess where you stand. The key ideas in this article will hopefully help you do so:

• Start with the end in mind. Always be clear – to yourself and others – where you intend to go and why it matters. Only then can you envision who you need to become to get there, and take the necessary steps together.

• Live up to your full role. Consciously building great working relationships with your CEO and peers is the grease that makes everything easier. Lead through context, not control – the more good decisions are made by those close to the work, the more scalable your organization.

• Obsess about learning. No matter where you start, it’s the capacity to learn and evolve that will get you where you want to be. Make learning a cultural non-negotiable. No change for the sake of it – feedback loops are essential to actually learn from change.

• Lead yourself first. It’s a hard job. Self-care is (largely) about being honest with yourself on what you can and cannot control – and acting accordingly. Avoid either/or absolutism, seek synergies, and be a storyteller who appeals to both hearts and minds. That’s 80% of the way to success.

Whatever your specific framework ends up looking like, no matter how difficult things get, you must never forget that your team does not serve you – you serve them. They’re the ones making it all real. Hence, the question always nagging at you must be: what the hell can I do to make all these people more and more successful?

Remember: a rising tide lifts all boats.