On Execution

Thanks to Ben Liebald, Lily Zhang, and Maher Saba for ideas and feedback.

“Our customers love our product and are hungry for more. We have a solid strategy. But we seem to be moving very slowly. Our team is great, but we can’t seem to execute.”

If this struck a chord, I have good news. First, you’re not alone. Most leaders I talk to ask for “execution” help. Second, execution can be improved through hard work and persistent, directed effort. However, execution is a discipline, and there are no silver bullets, despite what the internet will tell you. Improvement will take time and effort, but if you’re committed, read on.

Building A Race Car

— Photo by Tim Carey on Unsplash

Racing cars is a fascinating sport: it requires skilled drivers, but the world’s best driver cannot win with a poorly designed car. Take Formula One racing as an example. Formula One, also called F1, is a series of races around the world, with the world’s best drivers in custom-built cars. F1 cars are built for extremely high cornering speeds: hitting peak forces of 6.5g, while maxing out speeds of 350km/h (215 mph). F1 is highly regulated - accidents can be hazardous, sometimes claiming lives, such as the tragic death of Ayrton Senna at the Imola Grand Prix in Italy in 1994. The regulatory authority, F1A, changes rules often, sometimes minor changes, but the occasional major change that requires a substantial redesign of the car. Car design and development is such an essential part of F1 that there are actually two prizes: the Driver’s prize and the Constructor’s prize. Building F1 cars is as much an artistic endeavor, as it is a feat of ultimate engineering. It requires concerted hard work, year over year, improving cars, fixing existing problems, adjusting to rules changes, adapting to different drivers, stretching for varying road and weather conditions.

I think of high performing teams as a custom-built race car. The car comes together as a whole — engine design matters, but there is more to it. Similarly, any process a team employs matters, but there is much more to execution than process. The internet discussions on execution often point to a change in process, from waterfall to scrum, or having daily standup meetings, or weekly retrospectives. These things matter, but like the car’s engine, do not capture the complete picture. I believe that you exact processes must be tuned for the team; there are broad rules of what everyone must do (all cars have 4 wheels, are under a certain weight, and have an engine), but within the general framework, there are a lot of choices to be made.

This post is divided into three broad sections:

1. Defining execution and making the case to treat it as a discipline, rather than a process.
2. The Five pillars of execution.
3. A toolbox of things that have worked: practical ideas for you to copy-paste and edit.

What Is Execution?

The words “strategy” and “execution” are insufficiently understood by product development teams. My post, “Strategy and Tactics,” attempts to explain the difference. Here’s the short version:

• Vision is what the future looks like if you’re successful.
• Strategies are possible paths that allow you to attain your vision. A strategic choice or decision is the act of choosing which particular way to follow.
• Execution is walking that path.

Success depends on all three; which one matters more is highly dependent on the nature of the work, the company, the team, and a variety of other factors.

At a company level, the vision is typically to change the world in some meaningful way by making some problems go away. Google seeks to understand the world’s information and make it available. Facebook aims to connect the world.

Strategy is how you get there. Exceptional strategic thinking is hard to come by because it involves so many leaps of faith. Strategies are forward-looking and often hard to test on any meaningfully short timescale. Amazon’s strategy is three-pronged: decrease prices, increase product selection and increase customer convenience. Amazon could have chosen a variety of other approaches — build bricks and mortar stores, or purely match buyers to sellers, or designing and selling only their own products, or making a white-label e-commerce site. Notably, each of these strategies has a company built around it: Barnes and Noble, eBay, Everlane, and Shopify.

Execution is about the nitty-gritty. Designing experiences. Shipping hardware or code. Nimbly iterating to get through or around new roadblocks. Similar to other disciplines, excellent execution takes sustained effort over a long time. It is not a Thing to be achieved and checked off. The principles of Deliberate Practice apply here at the team level. Having a clear goal, focus and hard work, feedback, accountability, and deadlines — these are the pillars of a high achieving team.

Pillars of Execution (OSPAD)

1. One Clear Goal
2. Sustained Focus
3. Progress Indicators
4. Accountability
5. Deadlines

1. One Clear Goal 🏁

To execute well, teams must know what they are executing toward. It all begins with a clear and concrete goal, one that everyone can understand and rally behind.

One of the biggest challenges that organizations face is not the lack of goals, but having too many. When you have multiple goals, priorities get muddled. Given a choice, teams will follow the path of least resistance and focus on goals that are achievable over goals that are important. It is paramount, for a leader, at any level, to identify and set a small number of concrete goals for their organization, ideally one.

The second challenge is communication. Ask 5 people at different levels in the organization what their goals are. If you hear different goals depending on who you ask, or worse, “I’m not sure what our goals are,” you have a problem. After picking a goal, you must communicate it as clearly and as often as you can. The test comes at goal evaluation time, at the end of the quarter. If the team hits a secondary, unimportant goal, but misses the primary one, and they believe they did well and deserve commendation, then you have failed at clear goal-setting and communication.

A note on measurability: we in tech are obsessed with measurement. “What we cannot measure, we cannot improve.” Sometimes things are just not measurable, or worse, the only thing you can measure is a misleading proxy of the actual thing. Don’t let the lack of easy measures stop you from setting goals. For example, shipping is a perfectly good goal — especially when a team is building a new product with no priors.

Your job as a leader is to do the following:

1. Pick a clear goal. This is the goal that you consider critical to the success of the team or organization. It is the goal that everyone should rally behind. If you have a dozen goals, prioritized into big and small goals, whittle the list down to one or two. This exercise is challenging, but worthwhile.
2. Talk about your goal as often as possible. If your priorities are clear to you, and perhaps your executive team, but not to every engineer, PM, designer, and analyst - you haven’t talked about them loudly or often enough.

2. Sustained Focus 🧘🏽‍♀️

YouTube in 2011 was primarily known as the site for cat videos that people forwarded and shared on Facebook. There was a blossoming creator ecosystem, but creators were incentivized to make small, bite-sized content. The reason was simple: YouTube algorithms valued views as the primary metric and overwhelmingly recommended short videos. Sometime in 2012, leadership made the decision to switch to watch-time as the primary metric. The central idea was that as long as people were watching content on YouTube, we didn’t care whether it was short or long, just that they were entertained (or informed) by the things that they watched. The analytics team came up with a chart that showed a growth curve to 1 billion hours of watch-time. We all thought that a billion hours was impossible, but the chart served as strong motivation to hit a clear goal. When did YouTube hit the billion-hour goal? 2017.

Large bets take time to build. We, in Silicon Valley, are obsessed with instant feedback, numbers moving up and to the right instantly, trying to get to product-market fit as quickly as possible. If it doesn’t work in 3 months, it must be a terrible idea and should be abandoned because of opportunity cost.

I believe many organizations are afflicted with organizational attention deficit disorder. We do lots of annual and quarterly roadmap planning, and the minute we see something shiny, internally or externally, we collectively go “Squirrel!” and chase after it.

Execution requires focus. Goals are the setup. Focused effort is the follow-through. As a leader, you should keep your team focused on the goals, for months to years, based on your conviction about your strategy.

3. Progress Indicators 📈

A game without a scoreboard does not inspire players to do their best. The mere presence of a score is not enough, the score must be visibly present, so everyone sees it, every day.

Picking a good progress indicator is an art. These are operational metrics, not business metrics. As a result, the number you select to keep tabs on progress can be different from the overall goal chosen in section one. Rules of thumb for operational metrics:

1. Indicators should be fast. The point of a visible indicator is to motivate the team. A rapidly moving number helps build momentum.
2. Use leading indicators instead of lagging ones. When I was trying to lose weight (a perpetual goal), I made the mistake of using my weight as the indicator. It is a lagging indicator, and will move down after strenuous effort along other fronts, is subject to a lot of intra-week variation, and is mostly demotivating. Better markers like activity-minutes, or calorie counts, or standing or walking time possess the dual properties of being on the leading edge and moving quickly.
3. Use indicators connected to the eventual goal. Measuring the wrong thing is akin to going really fast around the wrong race track. Things will feel good, but nobody will make progress.

Examples of good indicators:

1. Kanban boards. I love these for projects where the primary goal is to ship something. They publicly and visibly capture the set of things that are in flight, and who is responsible for what. They get updated in real-time. Kanban boards are supported by most task management software; putting up a large TV with a display of your team’s kanban board is a great way to check off the Visible Indicators pillar.
2. Real-time dashboards. When working on projects to improve performance, improve efficiency, reduce bugs, I like dashboards that reflect the current state of the world (latency measurements, bug counts, etc.) I get inspired by seeing steady progress toward the horizontal goal line.
3. To-do list. Low tech solutions are on occasion, even better than the high tech ones. A whiteboard chart showing deals closed and progress toward the ARR goal can be more inspiring than a fancy screen with a soulless number.

4. Accountability 💪🏽

In 2018, the Facebook app was slow, and bugs were out of control. Most of Facebook’s mobile users are on Android; device and OS fragmentation make Android development particularly painful and error-prone. We knew we weren’t doing a good job serving our users but were stuck in the constant pull between new feature work and stability. Leadership eventually decided that enough was enough, and something had to be done. We had clear goals: fixing bugs and faster startup. The progress indicators were natural (bug count and startup latency). Leadership all the way through Mark was committed. Things still didn’t move.

The solution was a weekly meeting with all the engineering leaders and the head of the Facebook app. When some team wasn’t doing well (I was a frequent offender), people would ask questions about why and what they could do to help. The social pressure, my word as a leader, made me feel very accountable to deliver on my commitments.

As humans working cooperatively toward a higher goal, our word stands for something. I try my best to deliver on public promises. Holding a mirror up to my face when I fail is enough of a stick to keep me motivated.

The word “accountability” has frequent connotations of negative performance management, or of letting people go. I believe this is far too extreme; accountability is simply about a feeling of responsibility. Every parent knows they can’t control their young children but have a sense of responsibility for their actions.

I have two simple techniques for driving accountability:

1. Write detailed weekly status updates, publicly visible to the whole company. The leader must write these updates themself, rather than delegating them to an assistant. The process of writing forces the leader to read the constituent material and stay on top of execution issues in their team. Much more on this in the Execution Toolbox section below.
2. Weekly check-ins for the most critical projects. There is nothing that beats face to face (or video) interaction for driving accountability. These meetings are large and can get expensive really fast, so preparation and a concerted effort toward efficiency pays dividends quickly. Balance is essential — a status update meeting for every project in the organization is an egregious waste of time and unnecessary.

5. Deadlines ⏱

Confession: I am a serial procrastinator. Why do something today that I could push off until tomorrow? The harder something is, the more likely I am to procrastinate. I know I am not alone. And teams procrastinate just as much as individual humans do.

Deadlines are an effective deterrent for a few reasons:

1. They create pressure to get things done. Creative work is not steady; it happens in bursts. Fixed periods provide a way to channel that bursty energy in a coordinated way.
2. Deadlines serve as a focusing function. When people have a deadline to get something done, other priorities get downgraded.
3. They provide opportunities to change directions. We all make incorrect decisions at times, bite off more than we can chew, or underestimate the complexity of a project. Changing decisions midway kills productivity and focus. However, changing direction at a particular deadline is a reasonable way of re-evaluating decisions and correcting course.

Deadlines go hand in hand with the curse of estimation. No sufficiently complex software project I have been on has been estimated correctly at the start. Are estimates even worth the work? I don’t believe in long term estimates — these are mostly garbage and serve to create artificial pressure by committing teams to death marches that are months long. Short term estimates - in the order of 2-6 weeks - are reasonably accurate and should be done. Call it a sprint, call it a milestone, call it whatever you want. Software engineering teams should be able to predict, with a small margin of error, what they can accomplish in 2-6 weeks and then reliably deliver on this estimate.

Execution Toolbox

The toolbox is a set of things that have worked. I’ve included three ideas from leaders that I have worked with and respect greatly.

1. Weekly updates: perfect communication.
2. Daily office hour blocks: faster decision making.
3. Who-What-When: world’s most straightforward project tracking.
4. Recognition: positive reinforcement.
5. Retrospectives: feedback about how we work.

1. Weekly Updates

Teams and leaders often write weekly updates, but without care and effort, these can feel like a lot of make-work. Weekly updates are one of the most powerful tools a leader has. They can keep tabs everything, as well as tell the company what’s on their mind.

Tricks to writing regular weekly updates:

1. Build a process that works for your team. In my case, PMs wrote an update for every major work-stream, with a deadline of Friday evening. I spent 2-3 hours over the weekend, understanding and pulling updates together. I would tune it on Monday and send it out Monday evening.
2. Avoid unanchored metrics — “Participation moved up by 0.5% last week because of 3D photos.” Is this good or bad? What is the baseline? What is the goal? Vague numbers engender more questions. Instead, try: “We rolled out 3D photos to 100%. As expected, participation rate increased to 3% (incremental 0.5%), bringing us close to our goal of 3.2%. We expect some follow on increases, as the rollouts continue.” Longer, but provides way more context and understanding than the former.
3. Remember the audience: exec leadership and the rest of the company. Stick to what is essential. It is okay for a week to be quiet and not much to report. If there are many weeks of quiet, leaders should check-in.

Getting to meaningful weekly updates took months. My most effective technique was rewriting individual PM updates as feedback. It helped everyone on the team write in one voice and significantly reduced the burden on me when writing the full update.

2. Daily Office Hour Blocks

Most teams schedule leadership or exec reviews at a regular cadence of weeks. These reviews fall into two broad categories: decision making and information dissemination. When a team is deep in execution mode, slow decision making can break a team’s flow. Rebuilding that flow could take days.

In mid-2017, my team at Facebook was charged with building an AR-enabled camera feature for the Facebook family of apps. Our teams were running as hard as they could, but would get stuck when decisions needed to be made. Groups disagreed with one another and, on occasion, disagreed with themselves. At times, they just needed advice or someone to say, “go ahead.”

We would typically have reviews once a week. Due to packed schedules, any given team could get review time perhaps once a month. This was too long to wait on a decision, especially in the middle of an intense sprint.

Our solution was to devise a 2 hours block of office hours, every day, broken into 30-minute slots. The entire leadership team committed to being present. We decreased the level of homework needed to get into office hours — pre-reads were still ideal, but a two-paragraph email was a sufficient pre-read, instead of a ten slide deck.

The net result of this was that teams rarely sat on decisions for more than 48 hours. They could come in, talk about their problem, get help, advice, or a decision. Everyone on the leadership team would be aware and aligned. Teams would still have to communicate the decision out to the broader organization. However, thanks to liberal audience management, key team members were instantly in sync.

I found this incredibly useful but extremely taxing on time. There is some risk that you train teams to come to you for every small decision that they should be making or to break every minor disagreement that they had. This did happen, and we did ask teams to go back and sort it out on their own. However, in most cases, the issues were legitimate, and teams were able to move significantly faster.

3. Who-What-When

Thanks to Maher Saba, Facebook Engineering VP, and leader extraordinaire.

Modern startups are drowning in project management tools. Asana, Jira, Monday, Notion, Coda, Google Sheets. These tools are flexible and sophisticated because they try to model an inherently messy, complex system. They can also be overkill — imposing concepts of owners or timelines or points or whatever ideas were built into the system.

Saba’s technique was to have the most straightforward tool possible: a doc tracking 3 things:

1. Who is accountable/responsible?
2. What is the item being delivered or shipped?
3. When will it be shipped by?

Below the table, there is a log to keep track of everything that is happening every week. This sounds ridiculously simple compared to all the powerful tools out there. Because it is. But it works well to run projects of small to medium size and complexity.

The goal of the process is to have an ongoing, credible plan where the dependencies and workload are well understood and balanced.

Here is a sample coda doc to duplicate if you’d like to implement this system.

4. Recognition

Thanks to Ben Liebald, Head of Engineering at Branch.co

Execution grinds can take a toll on team health and morale. Good leaders find ways to keep spirits up. Celebrating wins along the way, or even milestones with significant progress, can do wonders. Here are some ideas to create opportunities for people (not just the leader) to recognize good work:

1. Friday Demos and Beer. At the end of the day on Friday, the team would gather, and anyone could present things they had been working on. The bar for demos was low — this was a safe space for showing off work in progress, not a polished presentation for the CEO.
2. Recognition rituals. One of my teams at Facebook would award a giant stuffed pusheen cat to the person who went above and beyond their job to help the team. This person would then pass the award on to the next person at the team’s weekly meeting. It was a great way to recognize work that would otherwise go unacknowledged publicly.
3. Gratitude emails. I love receiving emails that say something like, “I appreciate your hard work on feature X. I know this was challenging, and we were under a lot of pressure. You really stepped up and delivered. I’m so glad to have you on the team.” Sending these emails is effortless for the sender, but carries a lot of meaning for the recipient.

5. Retrospectives

Thanks to Lily Zhang, Director of Engineering at Instacart.

Teams, like people, need time to reflect on what they have done, and where they could have done better. It is hard to find time for this reflection during regular business since everyone is chugging away at their task and moving as quickly as possible.

To improve, we need feedback loops. Immediate product feedback loops are rare, or the signals are often weak. Leaders can ease people into a habit of seeking feedback and improving, by providing a safe space to collectively reflect, give each other feedback, and figure out how to work better. There are two natural points for retrospectives:

1. Incident level. When there is a significant outage (“SEVs” in Facebook parlance), the first order of business is to deal with the outage. Facebook has this down to a science: the tooling and coordination needed for crisis management has been tuned to the point of near perfection. Once the team is past the crisis, there is a meeting called the “SEV Review,” where the person causing the SEV presents an analysis of what happened, why, what could have been done to prevent it, and the next steps to minimize chances of a similar future incident. Senior engineering leaders are in attendance — giving feedback by pattern matching against other SEVs. This is not a blame meeting; it is strictly a learning meeting where everyone in the company learns as a result.
2. Project level. One benefit of having deadlines (pillar #5) is that the end of a particular milestone presents an opportunity for reflection and improvement. I am a fan of using sticky notes to individually write what is working and what isn’t, before opening up the discussion to the entire room. We are human and biased, writing before presenting helps reduce availability bias.

#executionishard

This post is not meant to be read once, understood, and put on the side. I hope you scanned it once, and return to it, when you have specific problems that these techniques can help with.

Remember, execution is really hard. It takes a long time to build execution muscle. If you’re a leader: be patient and keep improving with your teams. If you’re an individual contributor, and you see some key pillar missing, ask your leadership to fill in the gap.

Onward!