Chapter 4. How to Plan
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.
James Carse’s Finite and Infinite Games (Free Press) 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 and specific ways to win. The second is seeing life as an infinite game, with rules that are evolved over time by its players, and where the goal is continuing to play. Although planning is often viewed as a finite, rules-heavy process, I find it much more useful to approach planning as an ongoing game with dynamic rules. It was only when I was able to look past the stated rules that I was able to become an effective planner.
Guiding your company through the dynamics of planning is uniquely impactful executive work and is an area where effective executives can greatly distinguish themselves. In this chapter, we’ll walk through:
Discussing the default planning process at most companies
Dividing planning into three discrete phases: financial plan, functional portfolio allocation, and roadmap
Establishing a shared timeline across the three phases
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.
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—such as 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—such as a business review—to track progress against company goals.
This process isn’t entirely uniform across companies—details about when the process happens, what document you need to deliver to whom, or how budgeting works could vary. What will be particularly different across companies is how planning actually works. While the executive team will nominally follow the planning pattern outlined here, there is always another layer of emergent rules based on their behavior. For example, some companies have a stated financial planning process in which 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 may 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 Phases
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:
- 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 such as the relative investment into Research & Development (R&D) versus Sales & Marketing (S&M) or General & Administrative (G&A), as well as among the company’s products or business units.
- 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 to be in Engineering’s functional scope—for example, Security might or might not be included.
- 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.
Each of these phases depends on the preceding phase as an input, so they must be done in sequence. Sometimes as you proceed to later phases you’ll learn something that requires changing a previous phase, which is entirely expected. Get comfortable with the reality that planning is dynamic!
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 into 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 because constraints drive innovation; 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.
From here, we’re going to drill into each of the three phases, covering both the general approach and the particular challenges that come up when pristine theory meets messy reality.
Phase 1: 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 into the details as discussed in Appendix C, “Reading a Profit & Loss Statement”. 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.
Figure 4-1 shows an example of a 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.
Figure 4-1. Sample financial plan
For example, Figure 4-1 shows the Consumer business line is growing 31% year-over-year, with only $133 million in expenses on $625 million of revenue in Q1. Conversely, the Enterprise business line is growing much faster at 95% year-over-year growth but has $96 million in expenses for only $52 million of revenue in Q1. Referring only to those two rows, you can have a very interesting set of discussions about the two business lines.
The executive team will need to pull together an updated financial plan every year, which comes down to generating three specific documents:
A profit & loss statement showing revenue and costs, broken down by business line and function.
A budget showing more detailed expenses by function, including vendors, contractors, and headcount.
A 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 being 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 the accuracy of these plans is inherently low 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.
The Reasoning Behind Engineering’s Role in the Financial Plan
When you switch 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 business line, into 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—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:
Adjusting your financial plan too frequently makes it impossible to grade execution, because your targets will keep moving.
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 phases.
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 an 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 based on their growth rate for Engineering. This creates accountability to operate an efficient company, even when it’s painful to do so. It also avoids the difficult scenario in which 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 them 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 the 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 a 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 the 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.
Phase 2: Determining Your Functional Portfolio Allocation
The second phase in your planning is your functional portfolio allocation. Remember from Chapter 3, that your functional portfolio allocation is part of your Engineering strategy and describes 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 determining your functional portfolio 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—for example, 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.
Figure 4-2 shows one potential answer to that question, showing a fixed Infrastructure investment, expanding Developer Experience investment, and a temporary inwards shift in Product Engineering.
Figure 4-2. Functional allocation to Engineering priorities
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 that 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, such as 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 that are not obviously returning much impact. These are the places where 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 Chapter 3) 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 toward 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 for creative problem solving, which has potentially infinite returns without promoting cross-team competition.
Be Mindful of Allocation Granularity
There’s an inherent trade-off 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 couple of illustrative examples:
- Example 1
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.
- Example 2
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 deliver significant 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 downward, 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.
Phase 3: 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—for example, showing 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:
Coupling roadmapping with changes in budget or functional portfolio allocation
Tension between Product, Engineering, and their stakeholders
Roadmapping a mix of concrete and unscoped projects
Disempowering teams by planning too deeply
We’ve already spent time on the coupling problem, so let’s dig a bit into the others.
Roadmapping with Disconnected Planners
Effective roadmapping requires Product, Engineering, and Design to 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 Concrete and Unscoped Work
In Kellan Elliott-McCrea’s excellent post “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 the 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:
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.
Have a long-running allocation toward 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 toward separating 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 (O’Reilly), which describes how roadmapping that is focused too narrowly on project to-do items rather than on 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.
Instead, the goal should be to emphasize the target outcome first at a high level of confidence, and then 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. Digging into the specific project will surface a much richer discussion around execution than any abstract discussion about goals.
Pitfalls to Avoid
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, are:
- 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 incentivizes 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. The executive provides direction and makes trade-offs, but it’s the planning implementor who designs the templates, finalizes the schedule, manages exceptions, checks to make sure initial drafts are useful, and generally keeps the process on track.
Planning as Inefficient Resource Allocator
Signs that the executive team is optimizing for their function, rather than working together to optimize for the company’s overall outcomes, are:
- 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 the 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 toward 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 and whose knowledge of how the function operates makes them appear less strategic than headcount-oriented peers.
An executive team can put 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, as discussed in Chapter 18.
Planning as Rewarding Shiny Projects
Signs that your planning process is more focused on energizing the executive team than solving the inherent resource allocation and functional alignment problems at hand are:
- 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 also being planned so that the executive team can discuss critical work that happens to be considered a single function’s responsibility. For example, 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 the executive team is important, but distracting planning toward this goal comes with an unreasonably high cost.
Planning as Diminishing Ownership
Signs that the executive team is approaching planning in a way that is reducing autonomy and ownership within your broader team are:
- 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. It’s more effective for executives to prioritize outcomes, which leave sufficient flexibility in their execution, than to steer projects toward those outcomes that heavily constrain non-executive leadership.
- 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 be exceptions, not the norm.
Summary
Working through this chapter, 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 trade-offs of running a shadow planning process.
As you take these ideas into your next planning process, my biggest hope is that you remember that 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!
Get The Engineering Executive's Primer now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
