There are two obvious problems with the omniscience expectation (and one non-obvious problem).

Obvious Problem 1: It’s an Asymmetrical Standard. It is always trivial to come up with a new question that hasn’t been anticipated. There is no amount of information you can know to avoid being asked a question you don’t know the answer to.

Obvious Problem 2: It Undermines Psychological Safety. The omniscience expectation breaks down psychological safety as it cascades a profound anxiety through your leaders. To know everything you must be conservative, things must be smaller and tightly scoped, able to be captured in exact detail. (this is also the PGM fallacy. If we could write down in exact language the problem we were trying to solve we would have a computer program)

Non-Obvious Problem: It Focuses Leaders on Trivia. The non-obvious problem with the omniscience expectation is it focuses your leaders on trivia. I don’t know the attach rate of our enterprise partnerships, and I don’t need to know the attach rate. The question isn’t “What’s the attach rate today?”—it’s “Has churn decreased thanks to our new partnership efforts?” If it hasn’t, we persist. If it has, we celebrate and double down. The strategy tells me the answer, not the trivia.

Two (of N) Possible Responses

Two possible approaches to disrupting the cycle that lead to the omniscience expectation and the subsequent anxiety it creates.

Approach 1: Embrace “I Don’t Know”

The first is the hardest: You say, “I don’t know. Here is what I do know ….”. This is a bit different than the standard advice (which also takes courage) on how to say I don’t know which is to say, “I don’t know, I’ll find out, and get back to you on this date.” (closed loop)

Approach 2: The “Mardenfeld” Maneuver

This is an approach to separate a true need for data from “anxiety-driven requests.” And the great thing is that it is plausibly deniable.

Steve Mardenfeld has gone on to have an illustrious career, but once upon a time he was an intern with a sociology degree and a talent for understanding data who ended up building critical aspects of the data and experimentation platform at Etsy. And he had a practice. If you asked him for data he’d share it with you, e.g. in a Google Sheet, and not give you access to read it. If you requested access, great, he would give you access. If you didn’t, then he knew you didn’t really need this information. This was just unmanaged anxiety cascading down the hierarchy. Because the reality is no one is closing the loop on those data requests. I can’t possibly know everything I’m asked, and neither can you, and neither can the person who asked you. So we ask, and then some other request comes in, and we ask about that, and we never loop back for those answers.

And who knows if you forgot to share the permissions because the Google Docs UI is obtuse, or if you shared the permissions, but Sharepoint just forgot like it does 50% of the time, or what.

Challenging the omniscience expectation is important as a leader. You hold space for yourself to be a strategic actor, while protecting the psychological safety of your team. Admitting uncertainity and filtering unneccessary requests aren’t the signs of weakness so many fear – they are leadership tools that allow real creativity, collaboration and growth.

The first, obviously, is to answer questions people have.

No matter how well we communicate (and let’s be honest, how well do we really communicate?) there will always be questions that haven’t been addressed. Often there are questions you never even imagined. Q+A is an escape hatch as a leader for not being perfect.

The second is to cultivate a culture of engagement.

People who feel like they can get their questions answered, get their needs met, understand how decisions are being made and impact the direction of their team and company are more engaged, creative, and motivated. And those are the people you want on your team always, but especially if your goal is innovation.

The third is accountability.

As leaders we are also humans (not something folks always remember). We have good days and bad days, good months and bad months. We get tired and want to take shortcuts like anyone else. More importantly, as I’ve said before, management breeds blindspots. It’s the nature of hierarchical relationships that your information flow is biased and becomes more so over time. Having a public venue to be asked hard questions is an important tool for helping you stay accountable and building trust with your team.

Anonymity serves an important function in any group of people.

It allows people with less power to dissent from leadership or from the collective safely.

Anonymous Questions

Where we get into trouble is when anonymous questions give folks a cheap and easy public venue to express dissatisfaction and dissent. As someone who has spent my fair share of time in jail for public dissent I am pro-dissent. But broadcasting anonymous questions creates an asymmetry where it is easier to disrupt communication than to create understanding. You can think of it as a parallel to spam where it is infinitely cheaper to send spam than to fight it and how that means certain venues of communication can’t exist because they have no defenses.

Anonymous questions don’t even have to be answered as many teams use tools or processes that show the questions, and so the act of asking the question is now primarily a message directed at the larger team with the question answerer’s role in the whole exchange being perfunctory.

A Quick Suggestion on Splitting the Difference

All of that was a long preamble for a quick suggestion on how to split the difference.

People need a forum for asking anonymous questions from time to time. They need a forum for asking questions publicly. They don’t have to be the same forum.

Instead for live anonymous questions what I like is:

• Use a trusted 3rd party tool like Google Forms that allows for anonymous submissions (and not like an engagement survey platform paid for by the company).

• Give people a time window to submit their questions.

• Let people know I’ll only be answering the questions that I deem to be in good faith.

Now I’m empowered with the tools to start building trust and clarity by choosing to answer the hard questions that come in. Folks asking questions for the purpose of broadcasting dissent are doing it, in part, because they don’t believe they have other options. (and in part because it’s easy)

If I choose not to answer a question, I can state that publicly, “Hey, I got a question about why this place sucks so much, which lacks specificity for me to be able to address it”, or “Hey, I received questions that touch on topics that are the private information of an individual and I won’t be addressing those.” Or I can just not. It’s a balancing act. When we think about our 3 goals for Q+A choosing which questions to answer, and which questions not to answer requires judgment. But it doesn’t require fast-on-your-feet judgement. Which makes it easier. And if I’m consistently not answering the hard questions that come in, people will know. Because people talk.

Nothing earth shattering here, but having seen teams blow themselves up one too many times on anonymous questions, please take this as my suggestion to split the difference, and take the performative nature out of the question asking and the fast footwork out of the question answering.

(And this was not written in response to any of the lovely questions my team asked me this week, I promise! Like so many of these blog posts I found myself giving the same advice I’d given dozens of times before and thought I’d write it down)

We’re all familiar with processes like “write a weekly status update” that start strong and eventually fade out to low participation, engineers automating their updates, and gibberish. When you ask people why participation faded you hear the same thing over and over, “It didn’t feel like anyone was reading it”. In this scenario, we’ve Pushed. We’ve told people they must do something, on a schedule, in a certain format. But we haven’t Pulled, we haven’t created a sense that the work is valuable, that there is a need it is filling. A low grade Pull is something like a practice of reading status updates at the weekly meeting. (It doesn’t create much Pull, unless there is regular meaningful discussion, but it’s something)

Most teams have Push and Pull locked in for submitting PRs. Push: this is how we submit PRs, here is a template for doing it, this is our expectation of how engineering happens. Pull: you can’t make any forward progress on getting your work deployed unless you do it. Interestingly most teams only have the Push figured out for reviewing PRs. You should review PRs, you should review them in a timely fashion. You should, you should, you should. That’s all Push. Any wonder that so many teams struggling with PR dwell time?

If we want a culture of dashboards and data we can make data part of the definition of done by asking people for that data at key points. You can’t launch a feature until you can tell us how you’re going to measure success. You need to be able to tell us about usage for this feature at regular review. We expect you to be the first person to know if something radically changes with the features you’ve built. That’s Pull. We have a standard approach to dashboards including the tools and how to configure them, we have this regularly scheduled training on how to create a good dashboard, etc, that’s the Push.

Sometimes you see systems working where there isn’t an explicit Push or Pull. Usually this means we’ve created an inherent value out of one of them. It’s just part of being a good engineer at our company that you: review PRs, or make dashboards, or write status updates. There’s still a Push and Pull there, it’s just a moral and implicit one. Like any other time you’re trying to create or change a cultural value of your team it can both be highly effective and often slow and challenging.

So if you’re thinking about rolling out a new system, process, tool, etc. I’d strongly suggest that you think about both what the Push and what the Pull is.

It was fun to be back roughly a decade after I gave a talk on the work Marc, myself and others had done to increase the gender diversity of Etsy Engineering (a talk that became the first article in the First Round Review series). I’ve always admired the First Round content, and I thought Brett asked great questions, and I occassionally even gave some good answers.

I talked a bit about what I think has changed about engineering leadership, and what’s changed about my approaches. Touched on leading with curiosity which is something I speak about a bunch, and also the balance of caring and detatchment which comes up a lot in my coaching work, but don’t know that I’ve spoken about publicly much in depth.

Touched on some of themes from my software and its discontents series, though I was glad we covered new material.

Brett got me to speculate about AI, which is a topic I’m not really qualified to talk about, but my hot take is that we’ll need less software in the future, we’ve got a bunch of custom solutions being built where in the future we’ll have a more generalized toolbox that we can use to solve a problem without custom development.

The trope of “wow that was an expensive meeting” is an old one, based on the idea of adding up the hourly salary of all people in the room (especially the HIPPOs) as a way to express opportunity cost. It can be a useful meme for emphasizing the cost of poorly run meetings: those without agendas, those allowed to run long, those allowed to conclude without action items, or those that tremble as if they were mad. But it isn’t meant to be taken literally and used to shame your employees. That’s just dumb. (though the fun fact coming out of Shopify’s endeavor is apparently Tobi’s hourly wage, for meeting purposes at least, is $310).

Meetings can be dreadful, draining, and distracting, and lead to deadlocks waiting for limited overlapping free time, or limited conference rooms.

Meetings can also be useful for a wide variety of purposes, including a few needful activities like:

1. Getting and clarifying information
2. Building shared understanding
3. Recognition and celebration
4. Reinforcing values
5. Building social bonds and trust

One reason we see so many senior leaders in particular drawn to the idea of cancelling meetings is we aren’t in danger of not getting the information, understanding, recognition, and trust to do our jobs, it will still flow upward to us, whether or not the weekly meeting happens.

A Couple of Alternatives

At Dropbox we had “Core Collaboration Hours”. As a company that went from a very HQ centric culture to pivoting hard in the early days of the pandemic to being a virtual first one, CCH created time block when you could count on being able to book times with a colleague, and times when you could count on getting in the flow. It was great.

At Frame.io we’re 6 weeks into “Huddle Days”. Huddle Days are built around the insight that collaboration on a distributed team is harmed when grabbing 3 people for a 15 minute chat becomes the work of hours of calendar Tetris. Twice weekly Huddle Days are days where no reoccurring meetings are scheduled, and people are encouraged to use the Slack Huddle feature over the booking a meeting with attached video conference. Think of it as the classic “No Meeting Day”, but iterated to address the honored-more-in-the-breach aspect of that practice.

Both work great. And neither of them require a Chrome plugin, or shame, to work.

First 3 parts:

• Software and its Discontents

• Software and its Discontents, Part 2: An Explosion of Complexity

• Software and its Discontents, Part 3: Rising Cost and Elusive Success

I was in a job interview the other day when I got asked about planning, and so I decided I’d turn the question into another “plucked from the interviews” blog post. (see also Interview Question: Why do leaders keep disempowering their teams?)  To be clear this is a significantly expanded answer than the one I rattled off from the top of my head on Zoom, but I think the themes are roughly the same.

And it’s worth noting that because there isn’t one true way to plan this post does not try to tackle that impossible topic. Instead these are some things to think about when addressing why planning is often so awful and so often useless.

(Also I’ll note that this blog post, like all my blog posts, is very much in draft, Early Access, etc, and feedback and even pull requests are always welcome)

Interview Question:

Have you been involved in annual planning? How did you handle it? Do you prefer top down or bottom up? Is thinking about trade-offs something you’ve done? Do you have a framework for that?

This interview was for one of those jobs leading product and engineering which are coming back into vogue, sometimes called a GM, or CPTO, or just a VP of something or other. As an industry we’ve gotten pretty clear on the downsides of matrix management and the pendulum has started to swing the other way.  Though to paraphrase Andy Grove, “When deciding between organizing functionally and organizing along business units the right answer is always the other one.” (post for another day)

Let’s also set aside the question of trade-offs for the moment, except to say, trade-offs are the very heart of engineering and engineering leadership. Software as a medium is so malleable that functionally anything can be made to work. Any language, architecture, approach, style, process, etc can be made to work given sufficient effort. Meaning we find ourselves not asked to choose between right and wrong answers, but between trade-offs. 

Planning is a bit like software in that with enough effort anything can be made to work. (Anything! I’ve done planning using left over Halloween candy spread over the floor of the CEO’s office, and planning where everything was mapped to an Ancient Greek Olympic sport) Consequently we aren’t looking for the Right Way to Plan, as much as trying to solve for a set of constraints and things we’ve learned (the hard way) about how humans work. (Also like software: planning is way easier the smaller your team is)

The first challenge we need to navigate about planning is we’re usually using a single process (or small set of processes) to serve a bunch of different goals.

Some of the Goals of Planning

• Communicate a shared goal and vision for everyone to pull towards. Our vast and endless sea to yearn for.
• List the projects that teams are going to work on, and the metrics they plan to move.
• Equip the business to estimate whether the projects and impacts are sufficient to meet the organization’s targets (growth, revenue, capabilities, etc)
• Solicit insights from the organization on what are the critical and high impact projects to undertake.
• Give leadership a venue to provide feedback, set direction and course correct.
• Choose what we aren’t going to do, and what projects we are going to wind down.
• Project plan, tile work, and evaluate our utilization.
• Identify and manage dependencies.
• Headcount planning and allocation. 
• And a dozen other goals in any given instance.

As you can see we’re a long way from Do One Thing Well.  

So here are a few rules of thumb for making planning suck less. 

0. Do fewer things.
1. Bottom up processes don't work.
2. Planning is the wrong time to introduce anything new.
3. You must provide frameworks and constraints.
4. Project planning has an inflection point.
5. Don't wait to kill bad ideas.
6. Minimize dependencies.
7. Headcount planning won't map to your plans.
8. What if money is no object?

Some rules of thumb for making planning suck less. 

0. Do fewer things.

A reoccuring theme in the suggestions below is that planning is so hard, because we’ve taken a bunch of really complex and stressful tasks that require a high degree of coordination across our company and tried to do them all at once. Nobody has the time to approach the work thoughtfully, nobody has the time to meet with you to give you feedback, and by the end of it no one has the spoons left to finish strong.  Find ways to decouple the goals of planning, and reduce the high stakes nature of it.

1. Bottom up processes don’t work. 

There are a ton of critical insights we need from the people on the frontlines doing the work, but bottom up planning isn’t how to get them. Bottom up planning starts at the squad/team level, the leaves of the hierarchy, and aggregates and synthesizes the plans at each level as they move up the hierarchy.  We see a few predictable failure modes with bottom up:

• Individual teams, almost definitionally, aren’t in possession of the information and perspective to understand what is most important for the whole organization, and perforce will make locally optimal choices based on the information they do have. 
• Individual teams during planning will answer the question of what it would take them to accomplish a given goal, without awareness of what other teams will accomplish.

The above two tendencies are a recipe for an organization that grows larger every year, but is largely maintaining the status quo.  Ben Horowitz has written about this in How to Ruin Your Company with One Bad Process. His take isn’t most charitable, but even people with the best intentions will walk into these traps.

Finally

• Bottom up processes fall victim to anchoring. In a bottom up process you ask people to spend time and energy advocating for what they think the right thing to do is, and what resources they need to do it. They naturally emotionally invest in that outcome.  This now becomes the floor for their expectations.

2. Planning is the wrong time to introduce anything new.

Most organizations have a formal period of time annually (or quarterly or every 13 weeks) when they “Do Planning’’.  This period is usually called Planning. 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.  

Look at that list of goals from earlier in the post that we are already trying to solve with Planning. Does this look like a good time to also get creative? Similarly leadership often feels like Planning is their opportunity to introduce the new direction they’d like to see the company move in. All this does is create a scramble, shallow thinking, and low quality plans.

In most companies and organizations doing something new and meaningful requires us to coordinate with people across the organization (certainly in companies that have outgrown the project planning phase we discuss below in “Project planning has an inflection point.”) To pick the canonical example, if we build and launch a new product without planning how it’s going to be sold and marketed, and what infrastructure will be needed to support it, and without doing the research to understand how many times previously our company tried to launch this exact product then we’ll fail. Which is something we see tech companies do over and over.  This kind of coordination is hard at the best of times. Planning is not the best of times. Planning is when everyone is too busy to have these conversations. (and too emotionally keyed up as they contemplate their budget for the coming year and what that means for their team.)

Instead, start working on new things when you aren’t Planning. Document what you want to do/build/etc. Share the proposal with people. Get their explicit buy-in to support the new thing.  Test your assumptions and estimates with people in your organization with expertise that are different from yours. Get feedback from leadership about whether your idea is aligned with the direction of the organization (or if they’re willing to change directions). Tell people how much it’s going to cost: in terms of people assigned to it, time to iterate on it, to break through the noise in the market and educate your target customers, etc. Solicit internal interest for people who would be interested to join the effort if it gets approved.  This is a Funding Proposal, and it’s a great process to run outside of Planning.

Funding Proposals can seem like a heavy process. It can take weeks or months. Weeks or months is what it takes to make a good plan to do something new and meaningful. It isn’t something you can do within the constraints of a company’s annual Planning process. 

The other option that also works well for a large class of ideas: just try them. Don’t ask for resources, don’t ask for support from other teams, do the quick and dirty test to validate or disprove your idea, build a thing knowing that you’ll probably fail and be ready to back out your changes and throw it away.  That’s a great alternative to doing a real plan. It’s the middle zone, where we pretend to plan, but do it badly, that gets us into trouble.

Not signing up to do new things during a hectic time of the year when everyone is running around crazy doesn’t just benefit cross functional and rarely exercised relationships. It is also a benefit for partners who usually do (or should) be working closely together, like engineering and product. Something like a funding proposal makes keeping these close relationships in sync simpler, and avoids the inevitable blows up that follow post planning.

Sometimes Planning is taking place against an inescapable backdrop of chaos. For example frequent executive changes, or other forms of executive chaos, can mean frequent radical changes in strategic direction and emphasis. We see teams react either by tearing up their plans and scrambling to create new ones, or by becoming rigid, waiting out the current regime. Having a regular practice that teams use to undertake important new work throughout the year can help to moderate consequences of either reaction, allowing change with resilience.

3. You must provide frameworks and constraints

Providing frameworks and constraints is how you do the top down planning without micromanaging. Ben’s post touches on the importance of telling teams what the budget they have to operate in is, and holding back a buffer (20%) to encourage teams to be creative and ambitious, and to preserve optionality. Those are useful constraints, but there are so many others that teams need. This approach is explicitly more work for leadership in return for better outcomes.

Metrics (and by extension OKRs) are perennially popular constraints. Revenue, churn, sign ups, availability, etc are the bread and butter of many companies’ planning processes. Consider pairing them with metrics that shape a narrative (storytelling metrics) about what you think is important: customers who used our product both on desktop and mobile, % of the company who adopts a product once it’s available, etc.

Frameworks are a useful way to introduce constraints. 

• “Even overs” can be a useful framework. Our goal is to be a multi-product company which means prefer net dollar retention even over new customers. Ship new features even over multi-platform consistency.

• An investment portfolio approach is a framework. 20% of our effort should be going to brand new efforts that are high risk and high reward. The number of people it takes to operate our mature products should decrease 20% YoY even as usage grows.

• Capabilities models are a framework. We need to be able to X so we can unlock Y opportunity.

For similar reasons to what we discussed in points 1 & 2, these constraints can’t be uncovered by the planning process, they need to be constraints people know going into Planning. 

As an example, a popular constraint is: we’d like to do a marketing event to celebrate our new features this year. It can be tempting to let the teams tell you when they’ll be ready and then plan the event, but that’s circular. They can only tell you what will be ready when they know when the event is. (and knowing when the event is informs if this is a quick and dirty or a thorough and thoughtful implementation we’ll be building)

The most important constraint that frequently gets lost in planning is: what is the cost of the work we’ve already committed to?

• What is our KTLO?
• What is needed to finish the migrations we have underway?
• What did we already promise customers?
• What is it going to cost to deprecate the pieces of the system that aren’t working?
• In general, what does it cost us to maintain the status quo?

These are things you should be tracking throughout the year, but if you aren’t, setting aside some time before planning to get these answers is important.

As a leader top down planning comes with not only real cost, but real risk. There’s a good chance that you’re wrong about at least a few things. You need to be comfortable finding that out, and you need people who are willing to tell you that.

4. Project planning has an inflection point.

There is a time in the life of many companies in which they are single threaded, or close to it. Either everyone is working towards The One Important Thing, or everyone is working either on The One Important Thing or they’re working on something unimportant.  At this stage most of the key coordination problems you’re trying to solve with Planning take care of themselves.  Instead Planning will focus on the steps necessary to achieve The One Important Thing: milestones, blockers, risks, launch plans, have we broken the big thing down into smaller things that deliver value incrementally, etc. This is Project Planning and it’s perfectly reasonable to do at this stage of a company’s life.

As the complexity of what you’re trying to accomplish increases and Planning becomes more about coordination and communication, Project Planning is no longer appropriate to do at the company level. It’s too fine grained. More importantly it leads you to make overly detailed commitments about how you solve a problem to people who are outside your team. You should be committing to the impact of solving the problem. Once you have people outside your team monitoring your approach to solving a problem it becomes much harder to change your plan as you learn new things. (Marty Cagan talks about this frequently, e.g. in this post on The Problem with Product Roadmaps) Also if you aren’t learning new things when you’re building software, and especially products, you’re doing something terribly wrong, but that is another post. 

Many organizations miss this critical inflection point and go sailing off into Strategic Planning with the expectations of Project Planning still firmly in place. Companies operating in this mode are the ones whose frustration with not getting the strategic results they were hoping for leads them to push for more and more fine grained planning as the antidote: an attempt to achieve greatness by optimizing for predictability.

5. Don’t wait to kill bad ideas.

Just about every planning process pairs the question, “What are we going to start doing?” with the question, “What are we going to stop doing? Focus! Put more wood behind fewer arrows!”. And yet somehow the plan for what we’re going to stop doing never gets as much time and attention as the plan for what we’re going to start doing. Which makes sense.

Stopping doing things is by default way less fun than starting things. Stopping means we tried something and it didn’t work. Something that in recent memory everyone agreed was the most important thing we could be doing. Something that was so important that maybe we stopped doing something else in order to do this. (and as a manager, stopping means that when I told you this was the most important thing for you to work on, I was probably wrong, and I might look kind of dumb).

Also, we’re in a hurry to start this new thing. It’s exciting, it’s important, we’ve already baked its success into next year’s financial plan. We gotta get going. Cleaning up and deprecating the old thing, is going to have to wait.

Run this cycle a few times and you’ll see your technical debt explode (there is no such thing as technical debt, but sufficient for the moment), and your team’s cynicism along with it.

Instead emphasize with each team that you believe that their plans are hypotheses, and that you see their job as testing those hypotheses.  Setup regular conversations to ask how that testing process is going. What have they learned? What have they disproven? Where have they changed their mind? I would like to say the goal is to “Make Killing Bad Ideas Easy”, but I’m afraid that isn’t possible. You see 50% of all of our ideas are going to fail, and the other 49.9% will require multiple iterations before they succeed, and telling the difference between those two conditions is hard work.  So make it easier to kill bad ideas, and make it easy to talk about killing bad ideas sooner.

6. Minimize dependencies

Dependencies are another area where Planning’s attempt to serve many goals leads to problems. In Planning, as we’ve said, we are often being asked to think big, take risks, make big impactful bets. We’re also being asked to contribute to a financial plan that needs to be reasonably accurate. These two conflicting desires meet at Dependencies..

I can make a reasonable case for launching a new multi-billion dollar business next year, and all I will need is for everyone in the company to stop what they’re doing, and work on my plan (aka agree to my dependencies), plus the additional thousand or so people I’ve put in my plan that we’ll hire (that reminds me, let’s write down a dependency on recruiting).  I may even be able to convince (bully?) some of those teams into agreeing to work on one of my dependencies. (or maybe I don’t even ask and just write it down in the plan?)  This all sounds ridiculous and yet you see it over and over again in Planning.

The problem with there being a significant number of dependencies between teams, especially those that are critical to strategic plans, is you are tightly coupling those teams to the point where they are functionally the same team. Either they should be the same team, at least for the span of this project/plan/intiative/etc or you should minimize the dependencies on the critical path. 

As the person designing Planning, encourage people to build their plans on the foundation of things that are already working and shipped. New capabilities, and building support and excitement for them should be done via Funding Proposals outside this process (see “Planning is the wrong time to introduce anything new.”)

7. Headcount planning won’t map to your plans

It seems logical that Planning would inform Headcount Planning and often they are tightly coupled. After all, once we know what the highest impact work is next year, we should align what is probably our most expensive resource, people, against delivering that work. This approach inevitably raises the stakes. People who want to grow their teams are often portrayed as empire builders, but growth and hiring are part of any healthy team. We are now motivated to navigate/game Planning to keep our team healthy.

We can start shifting the high stakes nature of Planning by moving towards off cycle funding proposals as discussed. Team growth, and growth projects for the people on the team have then already been handled, and we can engage in Planning with a shared goal of producing the best holistic plan for the company.

Additionally as mentioned in point 3 (Constraints and Frameworks) you should be quantifying the cost of the work we’re already committed to. This avoids the common pressure to generate new projects just to keep a team funded.  Similarly reducing dependencies simplifies the sometimes 3-card monte of who is asking for headcount to fund the dependency and how that will be allocated (and are those headcount of people currently working for the company, or the people we’ll hire in 6 months?)

Finally headcount is an area where you just need to be comfortable with ambiguity.

Planning processes that try to be precise will backfire creating thrash and anxiety. I was once at a company that was very concerned about in-year cash flow, and rolled out a headcount planning process that closely modeled in what weeks we could hire people (because if someone starts in week 26 of the year, only half the salary cost lands in year). There was a spreadsheet produced that showed you what percentage of a headcount had vested for your team, and allowed you to borrow against future headcount. The formula for calculating the cost of borrowing was sufficiently complex that it required a Windows version of Excel, and so all senior engineering leadership had to get a 2nd laptop just to hire. It is understandable to try to exert control through precision over this expensive resource, which is why comfort with ambiguity shows up over and over again in definitions of what it means to be a senior leader.

After you’ve removed as much of the headcount budgeting pressure from your planning process, your second goal should be to roll out something simple, knowing it will always be fuzzy and inexact. Why will the process be fuzzy and inexact? People. Most companies struggle to have an accurate view of how people map to teams, how many people have been hired but not yet started, interns, etc. A simple process might be something like give each team an end of year “Not to Exceed” number (i.e. have this many people on your team or less by the end of the year).  This gives in year flexibility to hire without stop-start interruptions as you try to hit some complex intra-year target with predicted attrition curves, etc. (stop-start hiring is problematic because a good hiring process requires a healthy pipeline of candidates, and a pipeline takes time to build, and dries up when you stop hiring).

But how do we solve for that need of healthy teams to grow separate from what they might have committed to during Planning and why do we care?

First we care, because new people joining a team creates potential for new ideas, new skills, new backgrounds, new opportunities for mentorship, fresh energy, and team continuity when someone (or a set of someones) leaves.  To enable a team to see growth without pressuring them to game Planning, it’s important to keep a significant percentage of your budget in reserve, say 20%, that teams can propose to use off cycle. Holding back a significant percentage can be painful if you’re looking at a sea of bottom up proposals that already add up to 200% of your allocated budget.  However if you’ve implemented some of the planning rules of thumb we’re discussing you now have options.  We might have as many as 3 different pathways to get funding for a team’s growth as appropriate for different types of work:  a funding proposal for net new work, a planning process for run of the mill growth, and an exceptions process to access the reserve for opportunistic and organic hiring that keeps a team healthy.

8. What if money is no object?

In tech there are companies for whom money is no object. The resources aren’t constrained (for the moment). There is no need to evaluate the plans for their odds of success. You talk to people at these companies and they say things like, “I was at (hypergrowth) for 14 months and my team grew by 100% every quarter” (until the layoffs).  Bottom up approaches are common in these companies.

My experience being at hypergrowth companies, and also being at companies that were trying to be successful post hypergrowth is that it is important to remember that all code, all products, all marketing material, every piece of work product comes with long term costs, even if it’s just the cost of deleting it (something most people find surprisingly difficult). Especially in a hypergrowth environment or when money and headcount are no object, you need to be better at planning, because the only constraints are the quality of your thinking.

So why do we even plan?

If we go into Planning already knowing many of the new projects we’ll be tackling, what we think the impact of that work will be, with a majority of our budgets already allocated, and with the goal of introducing nothing new, why do we plan at all?

Planning serves two key purposes in this model. 

The first is it acts as a point in time to synchronize our multi-threaded company.  All year we operate with different teams and functions loosely coupled. Having a moment in time when we all agree we want to collate as comprehensive a view of what we’re doing as possible is an important investment to keep us from drifting too far apart.  That’s what Planning is, a time to all get on the same page before we all start running fast again.

The second is, it’s a forcing function.  We’re all busy and sometimes things just don’t get done without a deadline and a person asking for them. 

Planning is important, and it doesn’t have to suck as much as it does. To get there you need to reduce the complexity of your planning process, try to do fewer things, and take into account the humans who are the hardware you’re running the process on top of.

Layoffs are hard

Layoffs are hard, but if you stay in tech you’ll experience them from both sides of the table, and if you stay in leadership you’ll eventually be in a position where your actions can make them better or worse for everyone involved.

Logistically they’re hard because, like any significant organizational change, you’ve got a bunch of people working on something complex in secret. Planning for these sorts of changes happens in secret for a couple of reasons, even while the secrecy makes them harder to execute thoughtfully. The first and most important motivation for secrecy is during the planning phase you don’t know the details sufficiently to answer anyone’s questions. In the absence of answers people will fill in the gaps with their fears. Those fears can make the process more difficult and also can cause permanent ruptures in some people’s equanimity in relationship to the company. The second related issues is these situations tend to be fluid (hence the absence of details). I’ve personally been asked to plan two layoffs that never happened, as well as layoffs that in the end left my organization untouched. Third, the company will want to control external messaging, either because they’re a public company and have legal obligations around disclosure, or just to reassure their customers.

Layoffs are also hard emotionally. They often feel arbitrary and unfair. They run counter to so much of what we spend our days doing as leads: building teams and helping them grow. It feels bad to be laid off, and sometimes is quite scary. There can be a rapid redrawing of in-group and out-group boundaries. It strikes at a lot of what makes us tick as humans.

Some things you can do in advance to make it go smoother

• Run a good business. Sustainability (aka managing our various risks be they financial, legal, technical etc) is the foundation of what allows us to employ people to do great work.

• Make sure your teams have a good understanding of how the business works. Besides being important to build a good product engineering culture, a team that understands how the business works (or what the hypothesis is about how the business will work) will find it easier to understand why layoffs may make sense for the business. If by contrast your culture is focused exclusively on a life of mind uncluttered by commercial concerns a layoff will feel like a betrayal.

• Know your numbers. Have an estimate of the “fully loaded” cost of an employee. Make sure that number includes recruiting and onboarding costs. Grounding your conversations, planning, ROI expectations, etc in dollars can significantly contribute to the kind of planning that makes layoffs less neccessary, as well as cut through a significant amount of politics and barganing (“how about we rescind the offers for Summer interns vs laying anyone off?”) when the time comes.

• Know your ratios. What is your target EPD ratio? EPD to Sales, Marketing and HR? What is your target manager to IC ratio? What is your target senior to early career ratios? Having opinions about these things before you’re in right in the middle of a layoff will make planning much smoother. It also means that you can examine whether your ratios are the right ones as part of the layoff planning.

• On the topic of ratios: having a healthy mix of seniority on your team means you’re less brittle as an org. Avoid the temptation to layoff your handful of rising stars to keep your one current star who is now a SPOF, not to mention a SPOF whose job satisfaction has likely declined without people to mentor.

• Have plans and practice making hard trade offs between them. If your company struggles with the “we’ve added a new project/goal/etc so which one are we going to stop doing” style conversations, layoffs will also be a challenge. Avoid doing layoffs as a universal “hair cut”. It’s just reinforces the impression that leadership screwed up and has no idea what they’re doing. Layoffs can not be designed bottoms up, for much the same reason that annual planning can’t be run bottoms up. Leadership needs a strong opinion about the shape and goals of the layoff, with the details of the larger framework filled in by the teams.

• It’s relatively common to lay someone off and then find out that you need to hire that person back, or someone else (or often several someones) to fill the critical role they were performing. That’s a clue that you aren’t managing to bridge the top down and bottoms up perspectives on the layoff, probably because information is being very tightly held.

• Layoffs in addition to lowering costs should reduce the complexity of operating the company. If efficiency is one of the goals of the layoff, e.g. we’ve been papering over a lack of tools or processes with people, then we need to be realistic that output will significantly decline in the short term. Efficiency requires investment distinct from the larger goals of the company.

• Calibration, career planning and performance management. It’s reasonable to expect your leads to know who is doing well and who isn’t in their orgs, as well as the career goals and growth interests of the people of their teams. This is about having clarity about what is and isn’t working, and who might be a good fit elsewhere in the company. Having these conversations in the middle of the layoff is way too late. Layoffs should not be used as a substitute for actively managing out folks who aren’t working out.

• Doing calibrations, career planning, etc is a good prelude to having a ranked list of people you wish you could keep in the company that you can shop to less impacted areas of the company. Layoffs are no place for local thinking.

• Layoffs often come with promotions and people receiving new responsibilities. It feels especially bad for everyone involved to be sending out celebratory emails in the middle of a layoff. Ideally get promotions out of the way weeks or months before layoffs. Alternately know that there will be time to celebrate people later.

• Relatedly make sure your most important folks know they’re important, feel appreciated and are excited about the future before you’re in the middle of navigating the delicate balance of being excited about the future while respectful of the people who are leaving.

• Normalize the idea that not all companies and not all people are a good match for each other, and that doesn’t necessarily reflect poorly on anyone. (though as a company you’ll want to work on being a good match for as many people as possible from both a pragmatic hiring standpoint as well as a being decent humans perspective)

• Practice having a discipline around confidential projects. Have a practice where everyone who has been informed about a topic (aka “read in”) is listed in a shared doc, or added to a shared Slack channel etc. Discussion needs to happen before to manage logistical issues and to process emotions. People need people to talk to. Expecting them to only have conversations in their hierarchical relationships just means they’ll wing who they talk to. Ideally don’t make a layoff the first time you’ve ever run this playbook as a company.

• Your everyday threat model should include the idea that someone may freak out and get angry. It should also include the idea that someone’s accounts and tools may get compromised. Layoffs are not the only time an employee may either be pissed at their employer or that a bad actor maybe using an employee’s credentials. If you have to terminate everyone’s account before informing them they’ve been laid off I’m concerned about your internal security controls. In which case please do some tabletop on crisis management and security response going into layoffs.

• Layoffs, like re-orgs, often end up with major systems unowned. This will be an additional stress on the people who are staying and creates cynicism about the quality of the planning. Have a playbook that you’ve run for what happens to a system when the team supporting it ceases to exist before you do layoffs.

• As a leader, take time off before the layoff is announced. You’ll need to be at your best once communication starts rolling out. One of the most common and serious mistakes for a leader is to put all their energy and emotions into planning the layoff, and then be emotionally unavailable and impatient for the days and weeks when most of the company is processing the surprise.

• Similarly clear your schedule. You may feel like the hard work is behind you and on to the next problem, but you need to be available to people who haven’t been part of the conversation until now and for whom this is all new and shocking.

• Everyone has a friend who is leaving, and everyone can imagine themselves being laid off. Treating people well is not just the severance agreement (though that is important!), but also respecting that the people leaving were part of this team. People who are staying and people who are leaving have different needs around information and logistics, but everyone deserves to be in the All Hands where we talk about why we’re doing this.

• Anonymous questions are often a major source of toxicity most of the time, but you need to have a system in place for taking anonymous questions in the nadir of psychological safety that follows a layoff. Best practice have the questions go to a private inbox (e.g. using a Google Form) vs some sort of public moderator. That keeps questions focused on being questions vs statements to the audience.

• In the immediate aftermath of layoffs attrition tends to accelerate and hiring will get harder. Not doing a deep enough cut and then having to do another round of layoffs is a well documented failure mode for layoffs. It is equally a mistake to not have a plan for staffing in the wake of the layoff. At a minimum don’t layoff your entire recruiting team in your layoff.

• Practice having difficult conversations and projecting empathy as leads. You want your managers to be able to participate in delivering the messages of the layoff as they have the relationships and, assuming they have the skills, are best positioned to make the process humane. This is not the right time for your manager to be having their first hard conversation. (Nor is it the right time for your head of HR to be experimenting with being authentic and empathic for the first time.)

• Ensure that your managers understand that while it is critical to maintain their integrity and authenticity, freelancing communication in a difficult situation makes it worse for everyone.

As a leader a key job is to ensure that your company is a well run system that is a healthy and productive place to work. Layoffs are a major stress to that system, violating many of our implicit social contracts, breaking relationships, highlighting historical mistakes and failures, and bringing us face to face with the underlying business imperatives of the company. For a company that isn’t ready for them they’re a major rupture in the functioning of the system. Getting ahead of that and laying a healthy foundation is how you improve outcomes for everyone.

Like I said at the top of the post, this is far from being a complete how to on layoffs, just some tips and frameworks that have helped me. What are yours?

Interviewing for a new job mostly sucks, but the fun part is you meet a whole lot of new, smart people, and also are called upon to reflect on what you’ve learned. Here’s a question I got asked recently in an interview and some thoughts on it. (adapted from the original Twitter thread)

Question (from memory, not verbatim):

I’m leading a team, I understand my goals, all I really need from my leadership is a budget and some time, but instead I’m constantly blocked waiting for decisions, and having executives swooping in at the last minute without context. It’s profoundly disempowering, why does this keep happening?

Great question, why is this such a common experience?

Especially given the fact that anyone who has been managing for a minute is aware of “swoop and poop”, and is actively trying to avoid it. So why are so many people experiencing the swoop: as senior managers we don’t think that’s what we’re doing.

Let’s take a look at how we might have ended up here.

As a senior leader, responsible for a large and important portfolio, it is critical that I ensure that my teams will be successful, because the success of the company (in part) depends on it. Additionally I’m often uniquely positioned to balance strategic tradeoffs between competing priorities, open new areas of investment, align my peers across the company, and report up to the leadership level above me. Under these circumstances, when I’m asked a question or to greenlight an initative, naturally I’m going to quickly educate myself on the topic, maybe check the status of a related questions or two, and briefly align with some key stakeholders. It is that kind of lightning turn around of a complex array of interrelated issues that can leave you feeling winded at the end of the day having never left your office chair. But we have a problem. As senior management our perception of time is different (a topic I touched on in my “Managing Up” talk, watch it here). What felt brisk to us, is an age to the person who is blocked, waiting in uncertainty about the future of their work. This is all they’re thinking about, but it’s 1 of dozens or hundreds of things we’re juggling.

It turns out there simply isn’t time for us, as a senior leader, to be the diligent, competent, thoughtful leader we aspire to be on all the topics that arise.

And that’s hard to accept.

As leaders, we’re being asked to be comfortable being accountable without knowing the details. Being okay with saying, “I don’t know” when our boss asks for those details. Being okay with not having had an opportunity to share our opinion with the team. Being okay not doing the things we’ve been asked to do our whole career. Because most of us got to where we are by sweating the details, being the expert, asking the hard questions, being persuasive in sharing our perspective, generally having everything on lock.

Does it help to understand what the systemic forces are that produce this problem? Maybe. I’m generally of the opinion that if you want to create real change you have to start with the systemic forces. I could give you some tactical tips for when you find yourself in this situation (and again, you might find the “Managing Up” talk interesting). But because this was a question I was asked in an interview, and I’m a senior engineering leader, I’m going to instead talk about what a senior leader can do.

As a leader you need to find a way to get comfortable with engaging on topics you’re not competent on. Share your early and unfiltered thoughts, but skillfully enough not to randomize your teams. Communicate your varying degrees of confidence on the topics being discussed (“this may happen or that may happen, but either way I’m not worried unless this happens”). Build a culture where when you show up with your half formed opinions gleaned from skimming a few critical documents people are comfortable pushing back.

Instead of control the move becomes having an org you trust. An org that understand your values, goals, thought processes, and decision making. An org that doesn’t have to ask you a question, because they can imagine the good you and bad you sitting on either of their shoulders, advising them, without the real you ever having got looped in.

Find that path to being okay with being accountable, without being in control.

A leaders inability to find that path, because of their anxiety, or past experiences, or whatnot isn’t the only explanation of disempowering behavior. There are lots of other possible explanations, including just bad leadership. But it explains a surprisingly large number of unsatisfying interactions even with people who are good, or just competent leaders.

Very few things are as uncomfortable as being accountable for something you have no direct control over or knowledge of, but that’s the name of the game if you want a high functioning team that takes ownership in their work.

(thanks to Silvia Botros and Sarah Milstein, who both saw an earlier draft of this post and gave great feedback, they didn’t see this draft, and all the bad parts that remain aren’t their fault)

1. At small scale, and with reasonable numbers of people, literally almost anything works.

Software is an incredibly forgiving medium. Computers are ridiculously powerful. The scope, breadth, and quality of open source software in the world is a foundation unlike any profession in history has ever built on. On demand SaaS closes the gap. Survivor bias dominates at this stage. Probably the closest thing to a universal piece of advice is: don’t run out of money.

2. At large scale, and large numbers of people, basically nothing works.

Groups of computers and groups of humans are both complex systems and the interaction of them is definitionally unpredictable. Even the most banal advice can frequently be wrong, and if somehow you end up with the right advice for you particular situation, it still needs to be applied skillfully. Best advice for this stage is: be a good person. No guarantees it will improve your engineering outcomes, but at least at the end of the day you’re a good person.

3. Proximal causes of success are often not obvious.

Many people have experienced successful engineering organizations. These experiences are normal places to draw upon when trying to come up with advice on how to make engineering organizations successful. However the causes of success are often not obvious, because they occurred somewhere else in the organization, or in the past, or were never recognized as the source of success. This phenomena is familiar to anyone who has worked with someone straight out of one of the large powerhouse engineering companies who has shown up with a long list of things that work, and no working knowledge of how or why.

4. Writing is hard.

Writing is actually an incredibly relevant skill for engineering leadership (and engineering in general), but it’s still hard. You can have all the insights in the world, and still struggle to convey your message or find the right audience.