How to plan as an engineering executive. @ Irrational Exuberance

Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- How to plan as an engineering executive.

How to plan as an engineering executive.

Some years back, I interviewed a senior leader for an engineering role, and asked them a question about planning. I enjoyed their response, “Ah yes, the ‘P’ word, planning.” That answer captured an oft heard perspective that planning is some sort of business curse word. Even when it goes well, planning is an objectively difficult task. When it goes poorly, the business loses months or years of potential progress. Despite those challenges, guiding your company’s plans towards the right work is uniquely impactful executive work, and is an area where effective executives can greatly distinguish themselves.

In this essay, we’ll walk through:

• Approaching planning as an infinite process rather than a finite one
• Discussing the default planning process at most companies
• Decomposing planning into three discrete components: financial plan, functional portfolio allocation, and roadmap
• Setting the company’s annual financial plan
• Defining Engineering’s functional portfolio allocation
• Agreeing on the 3 to 12 month roadmap
• Establishing a shared timeline across these three processes
• Exploring planning’s frequent failure modes

By the end, you’ll be prepared to operate effectively within an existing planning process, balance functional and cross-functional demands, and diagnose how your current planning process may be holding Engineering and your company back.

Planning is an infinite game

James Carse’s Finite and Infinite Games proposes that you can view most things in life from two different perspectives. The first is seeing life as a series of finite games, with clear rules, a way to win, and many ways to lose. The second is seeing life as an infinite game, whose rules are evolved over time by its players, and where the goal is continuing to play. I’ve found this simple distinction life changing in general, and particularly applicable to planning.

Although planning is often presented as a finite, rules heavy process, I believe that planning is actually an infinite, ongoing game with dynamic rules. Before my realization, I would rigidly follow each planning rule, and then get frustrated when the resulting plan wasn’t very good. Worse, the plans I spent so much time on would routinely get thrown away a month or two after the process finished. It was only when I was able to look past the stated rules that I was able to become an effective planner.

The default planning process

By the time companies reach a couple hundred employees, they mostly reach the same documented planning process:

• Every year, the executive team agrees on an annual financial plan, including a headcount plan
• Every quarter (or half) the executive team will create a planning artifact that describes the plan for the upcoming quarter, e.g. Objectives and Key Results (OKRs) for each team, target business outcomes, or a list of projects to deliver
• Teams are responsible for managing their own execution against the quarter or half plan, using the process of their choice, e.g. Scrum, Agile
• There may be a monthly execution review to track progress against company goals, e.g. a Business Review

This process isn’t entirely uniform across companies, things do vary a bit in the details. There are company-specific details about when the process happens, what document you need to deliver to who, how budgeting works and so on. What will be particularly different across companies is how planning actually works. While the executive team will nominally follow the planning pattern above, there is always another layer of emergent rules based on their behavior. For example, some companies have a stated financial planning process where the executive team creates a shared annual financial plan, but in practice individual executives privately advocate to the CEO to increase their function’s headcount. If the CEO rewards those private escalations, then that becomes the real process, and the jointly created financial plan will become a polite fiction.

Even in companies where the executive team works together in good faith, new information will emerge that invalidates the current plan: \

• A country where you do business might pass an unexpected privacy regulation
• A financial partner might go out of business
• You might settle an accessibility lawsuit with a discrete timeline to make improvements

From the finite game perspective, updating your plan to address these new concerns is a failure, but from the perspective of operating a well-run business, you obviously want to operate against a plan that addresses today’s reality rather than last month’s.

Planning’s three discrete components

Without shared goals for the planning process, planning often becomes a bloated, overloaded system that poorly solves many problems. You will encounter planning processes that spend the majority of their time on whether you’ve completed security reviews, ensured you’re staffing cross-functional projects, or verified that headcount planning is aligned with recruiting capacity. Those are all valuable, but they’re solvable outside of the planning process, and distract from where planning can be most valuable.

Your planning process will be effective to the extent that it can do three things well:

1. Set your company’s resource allocation across functions, as documented in an annual financial plan. This plan sets targets for revenue and expenses, broken down by function and business line. From this you can answer questions like the relative investment into Research & Development (R&D) versus Sales & Marketing (S&M) or General & Administrative (G&A), as well as between the company’s products or business units.
2. Refresh your Engineering strategy’s resource allocation, with a particular focus on Engineering’s functional portfolio allocation between functional priorities and business priorities. There’s some nuance here because there’s little consistency in what companies consider in Engineering’s functional scope, e.g. Security might or might not be included.
3. Partner with your closest cross-functional partners, particularly Product and Sales (or whatever the leading Go-To-Market function is within your company), to establish a high-level quarter or half roadmap. This is the cross-functional agreement on the scope and timing of work to be done.

Planning in these three distinct phases reduces the number of dependencies in each step. Fewer dependencies lead to a simpler, more focused process. Although you might assume the opposite, I’ve found that artificially unbundling planning this way increases decision quality. For example, the financial plan focuses on revenue, expenses and headcount, while holding the roadmap and functional portfolio allocation constant. This means that you can focus on getting the financial plan reasonably correct without getting in a debate about the specific product releases. Once you start down the path of juggling the financial plan’s details with the product releases and the mix of functional and cross-functional priorities, things get more complex but are rarely more accurate.

These constraints create better decisions both because constraints drive innovation, and because removing constraints drives overly simplistic magical thinking such as spreadsheets that show tripling Engineering this quarter will triple Product velocity. Planning with sequenced constraints feels unnatural at first, but it’s worth the initial discomfort.

I’m not arguing that you should never change your financial plan or never change your roadmap outside of this sequence. If you complete your planning roadmap and still believe that a headcount adjustment is necessary, it’s reasonable to have that discussion. However, I am a strong believer in sequencing these discussions rather than having them in tandem to allow more focused, rigorous decisions.

Establishing your financial plan

In your non-executive career as an engineer at a private company, you may never see your company’s financial plan. If you do see it, you may only get a brief flash without the time to dig in and understand what the numbers mean. That makes it easy to get surprised in executive roles when you finally realize that your company’s financial plan is the foundation of all company planning.

The below table shows an example financial plan, with targets for every business line’s revenue, and each function’s expenses within that business line. These are dense documents that contain a great deal of data.

For example, this chart shows the Consumer business line is growing 31% year-over-year, with only $133m in expenses on $625m of revenue. Conversely, the Enterprise business line is growing much faster at 95% year-over-year growth, but has $96m in expenses for only $52m of revenue. With only those two rows, you can have a very interesting set of discussions about the two business lines.

Your executive team will need to pull together an updated financial plan every year, which comes down to generating three specific documents:

• Your profit and loss statement showing revenue and costs, broken down by business line and function.
• Your budget showing more detailed expenses by function, including vendors, contractors, and headcount.
• Your headcount plan showing the specific roles in the organization, with an emphasis on the new roles to be hired.

With these three documents, there are enough constraints to begin the rest of your planning process. That’s not to say that these documents are easy to pull together, they can be rather difficult.

The good news, from an Engineering perspective, is that you’re a stakeholder in creating the financial plan rather than directly responsible for it. Every Finance leader will have their own variation on the details, but expect the executive team and business line leaders to iterate on a series of proposals until you finish with something that no one’s quite happy with but seems plausible.

This process is significantly different depending on your company’s stage (e.g. Series B versus Series G), and whether you’re public or private. Look to peer companies for their processes rather than emulating much larger companies you’ve worked at previously. But keep in mind that these plans are inherently low accuracy because they depend on projecting financial outcomes without having a defined product roadmap or knowing what chaos the year may bring. Push a bit on the details, but don’t exhaust yourself.

Reasoning about Engineering’s role in the financial plan

Switching from the executive team perspective to the Engineering executive perspective, the problem gets a bit simpler. Engineering is rarely directly accountable for revenue (although almost always indirectly accountable to either Product or Sales for that revenue), so your primary contribution to the financial plan is managing Engineering’s expenses.

I recommend segmenting Engineering expenses by both business line and three specific buckets:

• Headcount expenses within Engineering
• Production operating costs (most cloud costs, vendor costs related to production, etc)
• Development costs (vendor and hosting costs related to CI/CD, running test, development environments, etc).

Within those segments, you should spend minimal time on business lines where revenue is accelerating faster than expenses (the business’ quality is already improving), and a great deal of time on all other business lines.

For any business line where expenses accelerate faster than revenue, you and the entire executive team should have a clear, documented hypothesis for when and how you’ll reverse the setup. It’s not always a problem, e.g. it’s expected for new business lines to spend a while in that phase, but it’s essential that the overall executive team is marching to the same orders on each given business line.

Why should financial planning be an annual process?

Your company’s financial plan is the foundational constraint for every function. Most companies adjust their plan over the course of the year, which is appropriate, but I’d argue that you’ll be more effective as an executive team and as an Engineering function if you operate as if the plan is fixed.

There are three core reasons for this:

1. Adjusting your financial plan too frequently makes it impossible to grade execution, because your targets will keep moving.
2. Making significant adjustments to your financial plan is a planning intensive activity that requires a great deal of time across many functions. As such, changing the plan creates a great deal of churn, and often requires the reworking of other planning components.
3. Like all good constraints, if you make the plan durable, then it will focus teams on executing effectively within it. If you make it flexible, then teams will instead focus on moving the constraint (e.g. asking for more headcount). The former is much preferable to the latter.

Certainly, if you must, then you must, but it’s much easier to run an effective company with a stable financial plan.

Attributing costs to business units

Early companies have a single business, which makes things simple. All Engineering costs are tied directly to running that one business. As companies grow, they’ll eventually expand to multiple lines of business, where things get a bit trickier.

Even the simplest attributions get messy as you dig in. For example, consider a company like Figma which has one core product, but likely segments its business into two business units: Enterprise and everything else. The core product is the same in both cases, but many Enterprise features aren’t valuable to non-Enterprise buyers. In that case, it’s easy to attribute Enterprise-focused Product engineers to the Enterprise business unit, but less clear how you should attribute Product engineers building the core product. Attribute according to revenue? Attribute all costs to the non-Enterprise segment and show artificially good margins in Enterprise? Do something else?

The answer to all of these questions is always, “It depends.” My experience is that there’s relatively little precision on this topic. Focus on finding a defensible methodology that Finance is comfortable with, and try to avoid reopening the dispute too frequently.

Why can financial planning be so contentious?

Financial planning is not inherently contentious in well-run management teams. However, when executives are focused on their function rather than the executive team’s shared success, allocating expenses is a zero sum game. Combined with the tendency for struggling executives to point at insufficient budget as the rationale behind their underperformance, it’s easy to end up with either broken executive relationships or out of control spending.

If your financial planning process is contentious, I’d recommend pushing a bit on the topic with your CEO. It’s most likely a sign of an executive team struggling to partner, or a particular struggling executive, rather than an issue that you can solve directly.

Should Engineering headcount growth limit company headcount growth?

In general, I do believe that most companies should constrain overall headcount growth on their growth rate for Engineering growth. This creates accountability to operate an efficient company, even when it’s painful to do so. It also avoids the difficult scenario where other organizations scale more rapidly than Engineering, and end up starving Engineering’s bandwidth to make progress on the company’s highest priorities.

There are, of course, always exceptions in the details. Uber did a good job of rapidly scaling city-specific operational teams with flexible tools that empowered the city-teams without letting them overload Engineering with requests. Uber may well have lost significant market share during their chaotic stretch of hypergrowth if they had constrained operational growth on Engineering headcount.

Informing organizational structure

Whenever you request additional headcount, you should have a documented organizational design to incorporate that headcount. The easiest way to do this is using some rough organizational math:

• Divide your total headcount into teams of eight. Each of these should have a manager and a mission
• Group those teams into clusters of four to six. Each cluster should have an experienced manager and a focus area (e.g. Consumer Products, Enterprise Products, or Infrastructure)
• Continue recursively grouping until you get down to five to seven groups, which will be your direct reports. In a company of ~40 engineers, you only need to form one tier of groups, but at company of ~200 engineers will require multiple tiers

Although this will feel a bit superficial, I wouldn’t recommend thinking about this in more detail during the financial planning process. There’s a final phase of real organizational design that has to account for the strengths and experiences of the individuals at hand, but that degree of specificity isn’t helpful during the financial planning process.

Aligning hiring plan and recruiting bandwidth

The last financial planning topic I’ll mention is that it’s common for executive teams and leaders at the next layer to spend time arguing about headcount that’s unlikely to get filled. I find it extremely helpful to compare historical recruiting capacity against the current hiring plan. If it’s unlikely that you’ll be able to make the planned hires based on the historical numbers, then I wouldn’t spend too much time arguing about it.

This is particularly common in hyper growth companies, where the executive team is not overly focused on R&D expenses, and may greenlight most headcount requests. In practice that scenario leads to teams within R&D acquiring headcount by capturing recruiter bandwidth (e.g. getting specific recruiters assigned to their team’s hiring pipeline) rather than through headcount approval. If you do find yourself in this situation, my recommendation is to align yourself with recruiting by being a strong hiring partner: recruiters are graded on their hiring outcomes, and everyone likes being successful.

Determining your functional portfolio allocation

One of the three core components of your Engineering strategy is how you allocate Engineering resources against your current priorities. This functional portfolio allocation applies to your entire Engineering budget across vendors, contractors, and full-time headcount. This allocation directly impacts planning.

The fundamental question to answer in your functional allocation is how much Engineering capacity do you want to focus on stakeholder requests versus investing into internal priorities each month over the next year? This is just a series of percentages, e.g. 63% of Engineering time in June will be focused on cross-functional projects, 75% in July, and 60% in August. However, deciding on these numbers can be difficult, and they have a significant impact on the company roadmapping.

The following diagram shows one potential answer to that question, showing a fixed Infrastructure investment, expanding Developer Experience investment, and a temporary inwards shift in Product Engineering.

Despite being a simple percentage, determining the correct percentage allocation is inevitably a bit trickier. The approach I recommend is:

• Once a year or so, review your full set of Engineering investments, their impact, and the potential investments that you haven’t made yet. Build the list of potential impacts from broad sources: your developer productivity survey, explicit brainstorming, and so on.
• Update this list on a real-time basis as work completes and new ideas are suggested.
• As the list is updated, revise your target steady-state allocation to functional priorities. Concretely, this is your investment into Platform and Infrastructure Engineering teams who exclusively work on functional priorities.
• Aim to solve all functional priorities within your steady-state allocation, but be willing to discuss whether teams that generally do cross-functional work, e.g. Product Engineering, should temporarily assist for particularly high impact or context-dependent projects.
• Invest leadership time, including your own, into spot fixing the large allocations which are not obviously returning much impact. These are the places you can learn the most about your organization, and also make the most meaningful adjustments.

If you’re debating how much energy to invest into this process, remember that it doesn’t need to be perfect, it needs to be useful. If your cross-functional partners are happy and engineers are happy, then you can get away with something very lightweight.

Why do we need a functional portfolio allocation?

If setting the company’s budget and roadmapping is a joint exercise, it’s worth asking why setting the functional portfolio allocation isn’t also done by the executive team as a whole. The simple answer is that functional planning is best done by the responsible executive and team. Functional allocation relies so deeply on function-specific expertise that doing it in a larger, cross-functional group leads to worse outcomes.

That’s not to say that functional leaders should allocate in isolation. I would strongly recommend doing it in partnership with your Engineering leadership team and other senior members of Engineering as described in Writing an engineering strategy, and then verifying your proposal with peer executives. However, including peer executives too deeply is unlikely to help them or you: something has gone very wrong if you’re trying to prioritize your CFO’s opinion about monorepos over your Staff Engineers’ perspectives.

Over time, address the root of this problem by slimming your allocation to functional priorities by converting them into cross-functional priorities. Things like compliance, security, reliability and so-on should really be fundamental company work, not invisible Engineering functional work. Bringing Engineering work out of functional allocation is much more effective than trying to bring non-Engineering executives in.

Keep the allocation fairly steady

The most common allocation challenge for executives is adjusting their allocation too frequently. You should prefer continuity and narrow changes over continually pursuing a theoretically ideal allocation. Changing your allocation feels like progress, but each change is fairly disruptive, so there’s a significant penalty to making frequent changes. As such, I recommend a strong bias towards the resource allocation status quo, even when your current allocation is slightly suboptimal.

Another reason to make infrequent allocation changes is that teams can become overly focused on competing for allocation, which results in a zero-sum competition with their peers. That’s a bad place to be culturally, and distracts from the more valuable opportunity of creative problem solving, which has potentially infinite returns without cross-team competition.

Be mindful of allocation granularity

There’s an inherent tradeoff between allocating at large (e.g. Infrastructure and Product) and small (e.g. Frontend Platform team and North America Growth team) granularities. The larger the granularity that you allocate, the more you empower your team to lead their teams. For example, if you allocate to Infrastructure Engineering, then Infrastructure’s leader is empowered to make shifts within Infrastructure. If you make explicit allocations to teams within Infrastructure, then Infrastructure’s leader would be obligated to work with you on changing their own allocations.

Don’t over index on early results

The most frequent concrete error I see in Engineering portfolio allocation is overestimating impact, or underestimating cost, based on early results. A few illustrative examples:

• Two engineers work on improving build performance, and speed up build times by 50% in two months. They argue that this shows you should theoretically invest 50% of Engineering capacity into developer productivity, and if not 50%, you should at least triple the size of the team. It’s easy to invest more here, but they may (or may not) have already captured the early returns, meaning future results will be much lower,
• Two engineers are working to migrate all frontend code into a shared frontend monorepo. After three months of work, you have a proof of concept, four annoyed frontend engineering teams, and no metrics showing an improvement. It’s easy to cancel this project, but it may (or may not) be about to consolidate these gains, meaning future results will be much higher,

To prevent these mistakes, I recommend establishing a fixed investment into projects until there is at least one inflection in their impact curve. For example, keep the two engineers working on build performance until you see their impact shift downwards, and only then estimate the correct long-term level of investment. If this feels too slow, then spend some time designing projects to show inflection earlier.

Agreeing on the roadmap

There are many areas where I’ve found a definitive solution that I strongly believe in. Roadmapping is not one of them. You can get there with a four-column spreadsheet (e.g. project, opportunity, implementation cost, and the owning team). There are innumerable other ways to create a roadmap that can work as well, and it’s rarely the format that causes roadmapping to fail. I recommend using whatever is already being proposed rather than spending time arguing about the format.

Instead, roadmapping fails because of

1. coupling roadmapping with changes in budget or functional portfolio allocation
2. tension between Product, Engineering, and their stakeholders
3. roadmapping a mix of concrete and unscoped projects
4. disempowering teams by planning too deeply

We’ve already spent time on the coupling problem, so let’s dig a bit into the others.

Disconnected planners

Effective roadmapping requires Product, Engineering and Design work together collaboratively. While one function often leads planning, the other two should be active partners. Whenever that isn’t the case, you will generate a roadmap that seems reasonable but fails to account for the real underlying topography of the planned work.

Similarly, I’ve often seen roadmaps where Product, Engineering and Design are closely aligned with each other, but the proposed work doesn’t account for stakeholder requests (generally from Sales or Marketing). In these cases, a properly scoped roadmap will come together, but it won’t generally be a set of work that optimally solves the company’s challenges.

You can quickly determine if this is happening by checking with folks in other functions to see if they generally agree with the proposed plans. If not, pull the different functional planners into a room and hash it out. The frequent mistake I see here is executives trying to solve this through a series of one-on-one discussions. Debugging the situation one-on-one works well, but resolving it requires an open, group discussion. I’ve had particularly good success with structured group discussions where each person has one to two minutes to share their perspective, without interruption, before the group starts the discussion.

Roadmapping unscoped work

In Kellan Elliot-McCrea’s excellent post on How to plan?, he makes an important observation that planning processes often proactively invite new ideas,

The implicit or explicit ask of Planning is often, “Tell us about all your exciting new ideas. We need your creativity to achieve our goals. Swing for the fences! Throw big rocks!” This is a mistake.

The challenge is that new ideas are unscoped and unproven, and you end up comparing the raw potential of an unscoped idea against the proven potential of an existing idea. How you discount the unproven idea is usually a reflection of your executive team’s psychology rather than its actual potential, which makes planning feel capricious. It also means, in the case that new ideas are quickly disproven, that your planning process will generate short-lived plans.

Two effective techniques for avoiding this scenario are:

1. Agree on an allocation between scoped and unscoped initiatives, and then prioritize like-against-like within those allocations. For example, you might say that 20% of product engineering time should go against validating new projects. Then you can debate which unvalidated projects should staff that 20%, followed by a separate discussion around investing the 80% of time in validated projects
2. Have a long-running allocation towards validating projects, say 10% of product engineering time, which provides enough validation that you can reasonably prioritize those projects against existing projects

Even if you’re not able to formally adopt either of these approaches, you can often informally steer the discussion towards separately discussing scoped and unscoped projects.

Roadmapping in too much detail

The final roadmapping challenge I’ll note is that if you get too specific, you can accidentally disempower the team responsible for the actual work. Melissa Perri captures this idea eloquently in Escaping the Build Trap, which describes how roadmapping focused too narrowly on project to do rather than your desired outcomes can constrain teams’ thinking.

Sometimes new leaders will take this concern a bit too literally, and argue that executives should not be allowed to discuss specific projects, because it strips their team’s autonomy. That’s a bad outcome for everyone, because it turns the executive team into a pure resource allocation decider, which is a bit too abstract a way to run a business until it gets exceptionally large. (As much as teams hate an executive team that micromanages, they’ll hate an executive who only does resource allocation even more.)

Instead, the goal should be to emphasize the target outcome first at a high level of confidence, and discuss the specific project second with a lower degree of confidence. As long as they remain aligned with the target outcome, the team should feel empowered to change the project, but digging into the specific project will surface a much richer discussion around execution than any abstract discussion about goals.

Timeline for planning processes

Mapping the above planning process to a calendar usually looks like:

• Annual budget should be prepared at the end of the prior year
• Functional planning should occur on a rolling basis throughout the year
• Quarterly planning should occur in the several weeks preceding each quarter. If you’re in halves instead of quarters, you’d prepare in the weeks preceding each half

This typical implementation is shown in the following figure.

The particular details here will reasonably vary across companies, and I have not found the details to matter too much one way or another. The biggest thing I recommend remaining vigilant against is something that Claire Hughes Johnson would often remark about when we began planning at Stripe: planning efforts always expand to fill the allocated time. If you set aside one week for planning, it will take one week. If you schedule one month for planning, it will take one month. Because planning is an infinite game, it’s best to avoid spending too much time on any given finite step.

Running a shadow planning process

At some point in time, you may find yourself in a planning process run by someone who is unwilling to independently solve for the budget, functional priorities and roadmaps. Similarly, you may find yourself working with a planning process that insists on solving every company problem, despite the fact that it’s clear that it’s solving all those problems poorly.

As an executive, you should work with the owner to improve the planning process, but you may also need to run a shadow planning process within your function. This is straightforward to do for both the budget and the functional resource allocation. For example, you can usually establish a conservative annual headcount plan for Engineering and run Engineering towards that headcount plan, even if other functions jockey for more headcount over the course of the year.

On the other hand, it’s pretty well impossible to run a shadow roadmapping process, even if the roadmapping process is difficult to work with. I’ve never seen a shadow roadmapping process work well except in the case of teams with exclusively Engineering customers such as Platform Engineering, Developer Productivity, or Infrastructure Engineering.

Ways that planning processes fail

Even talented executive teams often run planning processes that go awry. The causes are a mix of incompatible goals, subtle defections from team goals to individual goals, and a long list of small, tactical errors with outsized consequences. To help you in diagnosing your planning challenges, I’ve pulled together the most frequent planning challenges I’ve encountered as well as the symptoms that you can use to identify which challenge is impacting your planning process.

Planning as ticking checkboxes

Signs that you’ve delegated planning to someone who is process oriented rather than outcome oriented, or someone who is unable to push back on others demanding process oriented changes:

• Planning is a ritual rather than part of doing work: teams put together dozens of planning artifacts to support the planning process, and the executives celebrate the depth of work necessary. After planning ends, the plans are rarely if ever referenced again until the next planning cycle begins. This incentives individuals to focus on optically valuable work rather than genuinely valuable work.
• Planning is focused on format rather than quality: executives feel obligated to provide input on plans, to show that they value the planning process. If they don’t have valuable feedback, they will still find feedback, often related to correctly following the planning documents’ format or planning process. This distracts from assessing the quality of the planning decisions themselves

An effective planning process must have an empowered executive sponsor who can keep it focused on its core goals, as well as a planning implementor who is at least as passionate about generating useful plans as running a clear process.

Planning as inefficient resource allocator

Signs that your executive team is optimizing for their function rather than working together to optimize for the company’s overall outcomes:

• Planning creates a budget then ignores it: many executive teams will establish a resource allocation across functions in their budgeting process, but will then make headcount requests that violate that allocation. This leads to requests that are assessed by secondary factors, often individual’s interests or demands, rather than by their alignment with company goals
• Planning rewards least efficient organizations: often leaders will sandbag their organization’s capabilities, arguing that they need significantly more headcount to even continue operating at their current level. This culminates in a business where most resources are directed towards your least efficient leaders and organizations.
  
  A variant of this pattern is one where executives imply they can’t be accountable for their function’s output unless their full headcount request is met. This, combined with consistently high headcount requests, results in a toxic cycle of executives missing their obligations and claiming they can’t be held accountable
• Planning treats headcount as a universal cure: in headcount oriented executive teams, it’s easy for planning to become focused on rationalizing headcount requests rather than deciding on the most important work to be done. It’s clear this is happening when prioritization and planning discussions assume velocity is fixed and that work must happen, and instead anchor on headcount. This penalizes creative leaders who understand how their function works whose knowledge of how the function operations makes them appear less strategic than headcount oriented peers

An executive team can create social pressure on its members to optimize for the greater good, but ultimately only the CEO can hold executives accountable for their behavior. It is valuable to politely raise these issues, but only the CEO can address them. Pushing hard to resolve them will only backfire.

Planning as rewarding shiny projects

Signs that your planning process is more focused on energizing your executive team than solving the inherent resource allocation and functional alignment problem at hand:

• **Planning is anchored on work the executive team finds most interesting: **certain projects will always be more energizing for any given executive team to discuss. For example, most executive teams are excited to discuss sales numbers or new product development, but fewer are thrilled to discuss compliance. If planning processes are driven by work that executives find fun, then they will frequently lead to poor planning outcomes
• Planning only accounts for cross-functional requests: many planning processes are focused on meeting cross-functional commitments rather than planning the entirety of work to be done. It’s reasonable for roadmapping to only deeply consider cross-functional requests, but it’s essential that the functional allocation is being planned as well, such that the executive team is able to discuss critical work that happens to be considered a single function’s responsibility (e.g. some companies view customer satisfaction, security, compliance, and stability as the responsibility of a single function)

Creating impactful planning outcomes depends on solving the business and functional problems at hand. Energizing your executive team is important, but distracting planning towards this goal comes with an unreasonably high cost.

Planning as diminishing ownership

Signs that your executive team is approaching planning in a way that is reducing autonomy and ownership within your broader team:

• Planning is narrowly focused on project prioritization: an effective planning process serves as guidance for teams within the company to accomplish their work. Executive teams sometimes focus too narrowly on prioritizing specific projects rather than on the necessary outcomes or areas of investment. This often results in the teams with the most context, those implementing the project themselves, being unable to tune their approach to be more effective. This leads to disengaged teams and executives who are frustrated by the lack of urgency in the company’s execution
• Planning generates new projects: in some planning processes, it’s the only time that some executives think about a given area. For example, your Chief Finance Officer may not spend much time thinking about the Customer Success organization’s roadmap outside of planning. This is not inherently a problem, but sometimes those distant executives will use planning as an opportunity to suggest significant new, unscoped work. This will almost always result in a delayed or failed planning process, as it leads to attempting to prioritize well-scoped work against unscoped work, which is very challenging

Executives should prioritize coaching the broader team through planning. At times you will identify a leader who is not able to plan in their area, and at times you may need to make top-down changes to the plan, but these should not be exceptions rather than the routine.

Summary

Working through this post, you’ve dealt with the executive team’s annual budgeting process, maintaining Engineering’s target functional allocation, and combining the two to establish a concrete roadmap. You’ve also worked through a number of smaller topics like whether Engineering growth should be the limiter on your company’s overall growth, considering the granularity within your functional allocation, and the tradeoffs of running a shadow planning process.

As you take these ideas into your next planning process, my biggest hope is that you remember the first section: planning is an infinite game, and there’s always a bit of mess at every stage. The key thing is to continue improving bit by bit!

That's all for now! Hope to hear your thoughts on Twitter at @lethain!

This email was sent to you why did I get this?    unsubscribe from this list    update subscription preferences Will Larson · 77 Geary St · co Calm 3rd Floor · San Francisco, CA 94108-5723 · USA