The premium — the amount of money coming out of your paycheck automatically — for an HDHP will be lower than an PPO or HMO. How much lower will depend on your employer’s contribution, but it could be a low as a $500 a year. By itself, this is probably not motivating enough to switch. The main benefit is the pre-tax savings. In 2023, the limit on HSA contributions is $7,750 for a family. That comes off of your taxable income for the year. If you are paying close to the marginal tax rate of 37%, that would save you about $2,800 in taxes. Many employers will make their own contribution to the HSA, which could be thousands of dollars. This is extra free money.
The real incentive is investing that money. If you invested the whole $7,750 in an index fund that returns 7% a year for 15 years, you would contribute $116,000 and it would grow to $194,000 in those 15 years. That return gets larger over long time horizons. If you did the same thing for 30 years, you would contribute $232,000 and it would grow to $731,000. This is the primary attraction to an HSA for people already maxing out their other pre-tax investment vehicles.
Note: leaving contributions to grow requires that you don’t use the HSA money to pay for in-year medical expenses. This means that your post-tax expenses in the current year would increase up to your HDHP deductible, typically something like $6,000 for a family. On paper, the pre-tax benefit of the HSA is still worth it.
When you’re on an Health Medical Organization (HMO) medical insurance plan, you do not get billed directly for most medical expenses. You may receive a statement in the mail that says “this is not a bill”, as a cost transparency mechanism. But, you only have to pay the premium — deducted from your paycheck — and small per-visit copays. When you’re on an HDHP, you get billed for medical expenses from the service provider, and you need to pay those bills until you hit the deductible limit on your plan. After that, you will mostly not get billed and the insurance covers the additional expenses, with the exception of copays and potentially a small percentage-based co-insurance payment. You should keep receipts for any medical expenses you want to get reimbursed for.
The HSA is designed for you to tap into your pre-tax HSA contributions to pay for these expenses before you hit your deductible. For small expenses, you can use a debit card they issue you. For larger expenses you do this by logging in to their website and telling them how much of the funds to send back to you. This can be either a check in the mail or a direct deposit. The HSA provider will not ask you for a receipt for your expenses. When you file your taxes for the year, you will declare how much you contributed to your HSA and how much you were reimbursed from your HSA. You will not need to submit receipts, but you should keep them for seven years in case you are audited.
You invest HSA funds through the HSA provider’s website. Similar to a 401k provider, you select contributions amounts and which funds you want to invest it. With an HSA, you are selecting one contribution amount for how much additional money you want to deduct from your paycheck to put into the HSA, plus a second amount that you want to be moved from your HSA cash balance to your investments.
The downside of an HDHP + HSA that everyone knows about is the contribution amount. There is more money coming out of your paycheck. Assuming you contribute pre-tax to the HSA, that will more than offset the savings in premiums. People who are already maxing out their other pre-tax savings vehicles see this as a benefit; it’s reducing their taxable income and increasing pre-tax investments. But, the short-term negative cash impact is nonetheless a downside — and the most well-known one.
Increased paperwork and exposure to medical bureaucracy are less well-known downsides. When you’re on an HDHP you need to keep track of and pay medical bills. When you’re on an HSA, you need to keep receipts for medical expenses. If you’re on an HMO you may never have looked closely at a medical statement. It’s common for various doctors and specialists involved in something like a visit to the emergency room to all send you different bills. There are often mistakes on the bills, such as being double-billed for something. There is not a lot of clarity on exactly what an item on the bill represents. If you’re on an HMO you don’t really care. If you’re on an HDHP, you may very well find yourself calling your insurance company to figure this stuff out. They will often need to bring someone from the service provider (hospital) into the loop to sort it out. All this takes time, and is frustrating.
Exposure to absolutely insane, detached-from-all-reality, inside-baseball itemized medical costs are the next downside. On an HDHP, you are incentivized to spend less on medical expenses, until you hit your deductible. Did you know that something like a 1-hour speech therapy session for a child can cost $700? You will get bills like this from the provider. You may very well not be able to find out how much it costs until after the service. It doesn’t matter that the going rate for this service outside of insurance is $150. When they bill you this amount, it’s not negotiable. If you’re on an HMO, you don’t care what inflated price the provider is changing themselves.
The next downside is tax complexity and audit risk. When you file your taxes, you will submit a form 8889 for your HSA. You report contributions and distributions. This is not a big deal, it’s just one more thing to keep track of. HSA providers do not send this form to you, like 401k providers do. You need to fill it out manually. You don’t need receipts for medical expenses either when you request a distribution from the HSA provider, or when you file your taxes. You will need your receipts if you even get audited, however.
You are locked in to the HSA provider that your company chooses. Like 401k providers, there is a wide range of quality here. The company has an incentive to pick the lowest cost provider, not the one with the best website or customer support. In short, there is a good chance the only provider you can use will be terrible. Websites may be poorly implemented. There may be no phone number of call for customer support — instead you may be directed to your internal benefits team. There may be limitations on the number of transactions you can make. There may be annual fees.
Your company may also change providers. Your cash funds may or may not be rolled over to the new provider automatically. Even if cash funds are moved, investment funds may not be. There is the added complexity of special “in-kind” transfers that are necessary for avoiding tax implications of moving to a new HSA provider. You may or may not be able to do an in-plan (i.e. without leaving the company) transfer to your own third-party HSA provider. But, you will not be able to use a third-party provider for automatic contributions from your paycheck and your employer. Over the course of a long career, you may end up with many different HSA accounts at many different providers, unless you spend time to consolidate them.
Don’t underestimate the added element of decision making on top of all medical decisions, especially when there are family members and spouses involved. Even if the cost of medical treatment up to your deductible is a negligible expense in your overall budget, you may be surprised to find yourself in protracted conversations about whether it’s “worth” getting various medical treatments. Maybe your knee is bothering you, but it’s not a show stopper. Do you get an MRI, even if that might cost you $1500 dollars out of pocket? This is one of the points of a HDHP, from the perspective of the insurance company — to make consumers more aware of medical expenses. They know that this will reduce unnecessary medical expenses. But, it will also reduce necessary preventative expenses.
One of the primary use cases for an HSA is paying for medical expenses. You will get a debit card sent to you for this purpose, whether you want one or not. You will be required to create a username and password for the website of the HSA provider. This website is like small bank account, where anyone with your password can make a deduction. Both the debit card and the website are vectors for identity theft and potential financial loss. Neither of these are purely theoretical threats — there are news articles about fraud happening in the wild.
Enrolling in an HSA is not a one-way door. You can typically make a different election once a year, or when you change employers or at certain qualifying life events. If you save a large amount of money in an HSA and then switch back to an HMO, you may have trouble spending that money. It’s not clear what expenses are eligible when you’re no longer on an HDHP. It’s difficult to research, but you are probably fine to expense copays and any services or medications purchased outside your insurance. Plus, you can still save the money for medical expenses in retirement.
What would it take to “fix” these risks to HSA programs? Medical costs would need to become both understandable and reasonable. You would need to be allowed to choose your own HSA provider. Neither of these are likely to happen.
In the meantime — as with many aspects of finances — you can’t go wrong with keeping it simple. For medical insurance, it doesn’t get any simpler than an HMO.
]]>Burnout is a state of poor professional mental health, where the feeling of being overwhelmed or a lack of enthusiasm impacts your effectiveness. It can be caused by a mixture of mental or physical exhaustion, lack of belief in the work, and lack of belief in yourself. Each individual has a personal expectation about an ideal work environment on these dimensions. When reality becomes too far detached from this ideal, the result is burnout.
If you are currently burned out, you probably already know it. It feels like a crippling inability to get things done or to even care. It’s hard to ignore. But it’s also common to slowly be trending towards burnout without realizing it until it’s too late. If you think you might be at risk of burnout, ask yourself the questions in the Burnout Risk Checklist.
Burnout can severely impact your attitude, professionalism and performance at work. It’s also one of the leading causes of attrition.
Personal well-being is the best leading indicator of professional success. Think about all the people in your career that have left a company, whether it was their individual choice or they were actively managed out. If that person chose to leave, they were likely unhappy in their work situation. If they were managed out, they were likely unhappy in their work situation, and that resulted in poor performance. It’s relatively rare for someone happy and engaged to have severe performance issues.
Now think about high performers you have seen over your career. They were likely universally enthusiastic, and engaged in their work. They were happy in their work situation.
This is especially true for a leader. Your well-being is highly visible. It also directly informs the well-being of others and the performance of the larger organization.
The more senior you get, the more you will need to manage yourself. It’s true for career growth, but also for well-being. You won’t always be maximizing growth, impact, and well-being at the same time. You may have periods where you are trading off one for another. There will be well-being fallow periods. Part of your role as a leader is navigating yourself — and others — through those periods.
Everyone is responsible for their personal expectations about an ideal work environment. But leaders have a greater effect on both the expectations and reality of the work environment for others. Part of your role is taking ownership of the well-being of everyone.
You can do this by providing a narrative that ties short-term goals to long-term strategy and impact. That’s critical for your well-being too, as more senior roles have longer cycles for impact. By owning your well-being, you are taking control of your performance, longevity in the role, and ultimately the impact of the organization. Doing what’s necessary for your well-being is doing the best thing for the company.
To be alert for personal burnout, you need to learn to identify the warning signs. You need to be able to diagnose burnout signals in yourself and others.
Lack of action is the number one leading indicator of burnout. If you notice in yourself a distinct lack of activity relative to your baseline norm, it’s worth digging in to see if you may be on the path to burning out. If you manifest any of the overt warning signs of burnout, then move on to trying to figure out which flavors of burnout you are experiencing.
You may be experiencing poor mental well-being due to a mix of exhaustion, depersonalization, or ineffectiveness.
Exhaustion means that you feel mentally or physically tired, consistently, over a period of weeks.
Taking an extended vacation may help. Utilize general stress management techniques. That means sleeping well, exercising, focusing on a healthy diet, seeing family, and engaging in hobbies.
Making lists can also help. What things in your personal life do you find the most engaging? What things are you grateful for? Try tracking your mood over time with a journal or app.
If you get energy from spending time with other people, make room for that in your work week. Traveling to a shared working space or social event can be time well spent if it’s combating mental fatigue and re-igniting well-being.
Depersonalization is a lack of belief in the impact of your projects or the lack of alignment with your values and well-being.
Actively connecting the reality of your work to your ideals is the general mechanism for addressing depersonalization. Make and update lists of your accomplishments. Think of it as preparation for your next self review. This will serve as a forcing function to articulate what you are doing, and what the impact is.
You might find that work that you previously thought was not valuable did deliver impact. Format your notes to briefly describe the situation you were in, the behavior you demonstrated, and the impact on the business. If you feel stuck, you may need to force yourself to document even the smallest impact. After doing this, you may find that some projects did not have impact. Use that to inform what you choose to work on in the future.
Make a list of all the places you have worked. For each one, write down four or five projects that stick out as the most memorable. These are likely to be the projects that align most closely with your values. What did you enjoy about them? Translate these into generic themes like “mentorship”, or “hiring”. Brainstorm some side projects that you could be doing now for each theme.
It’s OK to take on new projects, if it’s something you are going to be excited about, or you feel confident it will have an impact. If needed, make space for this by punting — or delegating — items that you are not as enthusiastic about. Just make sure to inform any stakeholders that may be counting on you to complete a project. A good source of project ideas are items that you have heard other folks propose and own, but which are stalled out. Ask them if you can take it off their plate!
Start small, and pile up quick wins. Making forward progress on items that naturally engage you is the more surefire way to build back up your sense of making a difference.
Ineffectiveness is burnout stemming from a belief that a project cannot be completed, either because they are generally infeasible, or because of your lack of ability.
Remind yourself of projects that are being completed, no matter how small. Try tracking and celebrating wins that are happening. As a manager, it’s common to focus your conversations with others on things that are not going well. Try to intentionally do the opposite. Talk to folks in 1:1s about what projects are succeeding. Compile and send an update on recent successes. Intentionally spend extra time giving others public kudos or otherwise show your appreciation.
You also need to keep in mind that your ability can change over time. Focus on what you are learning. This is known as a growth mindset. Try keeping a list of things that didn’t go well, and what you learned from them.
You should talk about burnout with significant others, family, and friends. You should talk about it with your boss and other coworkers, provided that you have the necessary psychological safety. If your boss has already proactively raised the topic with you, talk about your plan to reestablish well-being.
Like a midlife crisis, burnout at work is ultimately caused by the gap between your ideals and reality. Both are likely to be most accurate after major changes. If that’s the case, give yourself time; this isn’t something that will be fixed quickly. Self-reflection will be important. If talking to friends and family is not enough, then seek professional therapy.
Acceptance is the other half of the equation. Increasing self-engagement will be very helpful. Take the opportunity to reexamine your ideals about your work environment. Whether your self-worth is too tied to your engagement in your professional life is a question only you can answer.
Especially when you are digging out of a burnout hole — but anytime — it’s OK to spend time on some things just because they boost your well-being. Sometimes senior leaders delegate too many things, including their favorite work. You may have gotten the advice to stop coding altogether. But, if you find it engaging, and the code will have an impact, give yourself permission to continue doing it. Everything is in moderation. Just don’t neglect your core responsibilities.
Never sit around with nothing to do. You can always invent impactful work. If all else fails, read an article or a book for professional development. Take ideas from that and implement them.
Don’t wait for an exciting project to come down the pipe before you re-engage. You need to proactively be fixing your engagement, first. You are ultimately accountable for staying engaged and managing your own burnout risk.
Calibrations are primarily about reducing the bias of ratings from individual managers, and increasing equity between managers. Secondarily, they are a great way to train managers on how the company thinks about performance. They also give senior managers data on the highest potential folks in a large organization, for strategic organization design.
In most companies, there is a fixed budget in dollars for things like compensation changes and promotions. Calibrations distribute this budget as fairly as possible. This post will not explicitly cover compensation, but know that most companies will want to link compensation to some combination of company, business unit and individual performance.
In a “pay for performance” system, you want to have outsized rewards for outsized impact. But the budget is still fixed. If you put twice as many people in the exceeding expectations category, then those people will get half the compensation increase they would have otherwise gotten. In order to maximize the impact of rewards, you do need to make decisions between cases.
Stack ranking means that you create an ordered list of individuals, according to their performance. It’s a mechanism to force the discussion about how to allocate rewards for greatest impact. The version that most people object to is if you are forced to label some people as low performers. Don’t do that.
If you have a large organization, it’s reasonable for there to be a bell curve of performance. In practice, I have seen that for cohorts of 50 people or more — at both large companies and start-ups — performance will roughly fit a curve. This comports with the central limit theorem, which says that a sample size of at least 30 will approach a normal distribution. But that does not mean that the low end of the curve are necessarily low performers. I do not think it’s acceptable to mandate a fixed percentage here.
You can keep yourselves honest by pressure testing people in the “meeting expectations” bucket. This is less of a budget issue, and more about holding managers and individuals accountable for real performance problems. While it’s not fair to absolutely require a fixed number of people to be labeled underperforming, there is a definite tendency for managers to avoid these difficult conversations by giving someone an unwarranted “pass”.
Stack ranking gets a bad name from being forced on too-small cohorts, and for forcing low performance ratings. Companies that had a bad reputation for doing this in the past commonly still do have ratings and curves, but have substantially changed their process for how the ratings are generated and reconciled. Some do away with ratings, but still have differentiated compensation changes that could be reverse engineered into ratings. Some move the reconciliation to the Director level, and give them more discretion on fitting the curve.
I’m going to outline a process that works well for cohorts of about 50 individuals, and can scale up to any size by layering on multiple calibration rounds. The goal of calibrations is to have fair and consistent performance ratings across organizations, roles, and levels. You want to reward high performance, and make sure that appropriate poor performance conversations are happening.
This process can also be scaled up and down, in terms of how much time it takes. You can cap write-ups in length. You could potentially do the entire thing asynchronous ,with no meeting. Reducing the size of the cohort will also save time. There are all trade-offs against how much to want ratings to be equitable across teams.
Before you can calibrate, you need initial ratings and write ups. You need to gather data. This is where self reviews and 360 reviews come in.
Self reviews should use the same format as the eventual manager review. You should have a defined template for this up front. They should reference your existing framework for expectations per role and level. You should ask people to provide a rating for themselves. Any training you can do here to help folks write good self reviews will pay off.
Individuals and their manager should determine a set of three to five 360 reviewers per person. The format of a 360 should be short. Ask reviewers to timebox their effort, skip pleasantries and platitudes, and focus on situation, behavior, and impact. 360s can be anonymous or not, as long as it’s clear to the reviewer.
Managers should draft their reviews in parallel with self reviews and 360s, and then incorporate any new information prior to calibrations. It’s at this point that managers should document initial ratings and promotion candidates. You are going to want to gather these in some central system, even if it’s just a spreadsheet.
For the actual calibrations, you should pick one facilitator. It’s this person’s responsibility to set an agenda, set a timebox for each individual, and manage time during the meeting. The facilitator will need to have access to the preliminary ratings and promotions for every person to be discussed. They should create an agenda that has the name of each individual, the order they will be discussed, and a link to the manager write-up. It may help to give the attendees basic guidance about how many people would need to receive each rating in order to hit the budget.
Calibration meetings have a reputation of taking forever. A six or more hour meeting to decide the ratings for 50 individuals is not uncommon. It’s also common for certain managers to dominate the airtime, which can result in bias. How can these be run more efficiently, and result in equitable outcomes?
After several iterations, I’ve arrived at a format that I love. It’s pretty simple:
The confidence voting is the real secret sauce here. The idea is that every person present at calibrations submits a “blind” score for how confident they are in this individual being “at the bar” for the proposed rating or promotion. Blind means that scores are submitted without seeing anyone else’s score, to avoid bias. You can use any scale, but I like a star system with options for:
You can also include a free-text field for comments. If not, encourage folks to leave any comments about why this case was not a “Slam Dunk” in the Q&A notes.
The confidence voting system can also be used to pressure test low performers. Typically, managers are somewhat reluctant to put individuals up for discussion as potential low performers. Assuming you do not have time to calibrate on every single individual in the organization, it helps if you have some proxy data you can use to identify people to talk about here. For example, you could identify individuals who have missed delivery milestones, or who have not done the expected volume of candidate interviews. Group these folks together, and vote on confidence at a “meeting expectations” rating. This is how the group can come up with calibrated ratings for potential low performers.
The confidence votes are tallied and revealed after calibrations. Scores are averaged together per case, and the results are made available for all calibration attendees. It’s at this point that the overall decision maker for the organization can make final decisions by defining a “cut line” in the graph. It’s up to them to figure out how closely to hew to any distribution guidance.
Calibrations need one decision maker. Typically this would be the manager that all of the calibration attendees report into, with the same being true for the individuals whose performance is being calibrated on. Alternatively, you could randomize cohorts across an organization to further mitigate bias, and the cost of the calibrators having less context.
With the voting system, the decision maker does not need to make the final decisions live during the meeting. Instead, they can look at the results after the fact, and decide. Just because an average score is under the “Solid Case” line, does not mean that the rating or promotion does not get approved. It may, but much more important is the scores relative to other individuals up for the same rating or promotion.
I’ve been surprised in that decision making role just how close the ranges of scores on any given individual are in practice, and also how much differentiation there is between cases. When this happens, it’s a sign that the managers in those calibrations are indeed thinking about performance and expectations in a way that is aligned. In that case, the decision maker knows that they are not unilaterally making decisions that may be biased.
A single calibration session can only scale up to cover 50 individuals. Assume that you only discuss people who are not solidly “meeting expectations”, and that those folks will be roughly 50% of the total. If you need a minimum of eight minutes per person, this would mean a three hour meeting. The total number of managers, or meeting attendees, would be between 6 and 12.
You will most likely have multiple calibrations, due to visibility issues. It’s typical for managers at level N to only sit in on calibrations discussing individual contributors at N-1 and below, or similar. That means that higher level individuals are likely to be discussed by managers that control more scope, which means managing larger orgs, which means that there are probably hundreds of individuals under those managers, way too many for a single session.
There should be one overall facilitator to create the timeline and define the cohorts for how these multiple calibrations will be scheduled, so that no cohort is over about 50 individuals, and individuals are not discussed multiple times.
Sometimes, you may choose to intentionally discuss individuals multiple times. This can be when you want to give managers practice writing their cases, and provide feedback in time to affect the final decisions. It can also be when you want to gather data from managers who work with a high-level individual regularly, before presenting the case in a higher level calibration.
In all these calibrations, you should strive (or require) cohorts to individually meet their budget guidance. This is how you scale to any organization size without having to directly compare every individual with every other individual. It will not be possible to draw cut lines across cohorts later, because the relative confidence scoring between cohorts is not directly comparable.
The confidence voting system in particular delivers some key benefits that most calibrations struggle to achieve. The meeting time and conversations about individuals can be timeboxed. You can choose to not discuss up to 50% of people who are solidly in the “meeting expectations” camp, if time does not allow. The final results can be justified with data, and we can reason about exactly how “calibrated” the group was. We can choose how closely to follow any given budget guidance. We can also pressure test low performers.
]]>Not needing dependencies is a luxury afforded to teams in small companies, or those running very high priority projects. I once ran a tiger team that was both. We moved experts from across the company onto the team so that we could own every piece of the execution. In large companies where a single product spans many teams, most projects will require one or more dependencies. You need to have a playbook for managing dependency risk.
First, you need to know what the dependencies are. One of your core competencies as an engineering manager is “asking the right questions”. Hold a brainstorm and help the team see dependencies that they might not know exist. Cross-functional dependencies like security, legal and compliance can be particular blind spots for engineers. For actual software engineering, the team can almost certainly identify the big dependencies off the top of their heads. Doing a pre-mortem exercise can be one way to enumerate them and quantify the risk for each. You want to do this early in the project, as part of project estimation.
Create a list of all the dependencies for the team, for the year. Each one should have a project name, a short description of the dependency, the risk or priority of the dependency, the name of the remote team that you are dependent on, and a specific team member who owns it. Try stack ranking them, with the highest risk/impact dependencies first. Share this list with your manager.
Having a prioritized list of dependencies is useful for more than just your team. Suggest that your manager ask all their teams for this, and that they create a combined list. How they prioritize the list across teams will tell you a lot about how well aligned you are, how they are going to present these priorities to their own peers and stakeholders, and may also give you early signals on when a dependency is a non-starter.
Show your list to the engineering managers you are asking for dependencies from. Ask them to share their full roadmap, and share yours. Include not just the engineering managers, but tech leads and product managers on both sides, as well. Make sure you have a solid business case for your project. These stakeholders, artifacts, and visibility are how dependency problems are turned into creative solutions.
For any given dependency, you should first try to remove it, and then you should secondarily try to push it back. Removing a dependency typically looks like changing scope, so that the dependency is not required. Pushing it back looks like structuring milestones – provided that early milestones deliver user value – so that it is not required until later. This is basic execution management that should happen for all your projects, and should be old hat for yourself, your tech lead, and your product manager.
If the dependency cannot be resolved with a creative solution, the next step is to get the right people to bring the right expertise to bear on the problem, and to get work started right away. A dependency that is not being actively worked on by engineers is an at-risk dependency. As an engineering manager, allocating these resources appropriately for the business is another core competency. That’s not to say that it will be easy! Managers sometimes confuse accountability for allocating resources with having authority to dictate those decisions. Given that we know that we will mostly not be unilaterally allocating people across disparate teams, what staffing levers do we have at our disposal?
Use your knowledge about the organization and other teams to identify the correct team for the dependency, and also the most likely points of contact on that team — the experts — who can help the most. Start by asking for a consultation with that expert. This could start as one-time, and then you can collectively evaluate if consultation alone can satisfy the dependency. Identify your own experts, and get them involved. If you respect the remote team’s time, create a pre-read, and get aligned ahead of time with their manager, this should be a slam dunk. Even if the work turns out to be too large for a consult, you will have cemented a clear point of contact on the remote team.
Next, create a dialog with the right points of contact on both sides. This could be a simple Slack channel dedicated to the consultation. Eventually, this may be the rally point for a full on roadmap dependency. Your goal is to create and nurture a relationship between the teams, to facilitate a conversation. If you make it transactional, that is how it will feel to the other team. Try to set ground rule expectations. Can the other team agree to provide support for things like technical spec reviews, and code reviews?
Another staffing mechanism available to all managers is embedding, also known as tours of duty. This means offering to loan one of your engineers to another team for a specific period of time. Alternatively, they could loan you an engineer. It’s easier than a roadmap commitment, because it’s timeboxed. The receiving team agrees to return the engineer on a specific date, based on the initiating team’s estimates of the work. The engineer(s) exclusively work on the dependency. If it’s not resolved in time, that is the responsibility of the initiating team. The embedding should end on time regardless. Managers should write down expectations for things like how specs and code get reviewed, what needs to happen to merge a code change, and whether the person is expected to improve the state of the surrounding code. If folks are willing to cross-train, this can work even if there is a skills or domain knowledge gap in the person being embedded.
Other staffing solutions may or may not be available to you. Most dependencies that get to this stage require domain knowledge. If the dependency is primarily about raw staffing, you can of course hire. Even if this is not the case, if you are in charge of a headcount budget, reserving some budget for dependencies like this can be effective, to facilitate potential internal transfers, both to be able to receive an internal transfer, or to offer as compensation to another team for a transfer.
Depending on your scope, other options like moving people between teams, or moving entire teams, may be available. During a regular reorganization of teams, you should be actively managing your dependency risk.
Once you know what your dependencies are, and the right people are working on them, the next step is to structure the work. How you structure the work greatly affects how much risk you are taking on. Your goals are to shorten the window before work begins, bring forward the first increment that delivers user value, and shorten the cycle time between further iterations.
Creating a prototype is a critical early milestone. This should be a quick and dirty development environment only implementation of just the very core of the product. This gives you some real code to discuss, some real experience to demo, and will also uncover some of the primary unknowns and decisions that need to be resolved. Concurrently, you can also do “spike” sprints to try to resolve specific unknown and technical risks.
After that, you want to move to an in-production implementation, behind a feature flag, as soon as possible. This is Milestone 0, a foothold that you can continue to expand, refine, and polish for the rest of the project lifecycle. After that, milestones should be “theoretically shippable”, i.e. a user could get some value out of this, no matter how small. Don’t break things down into milestones like backend, front-end, release testing, etc. Instead, think of thin vertical slices. Each slice should deliver some user value, end to end. The slice itself should accomplish part of the overall job to be done. It should be just polished enough that you could release to wider and wider audiences, such as team-only, internal-only, early access customers, etc.
When planning the scope of the milestones, think about whether certain dependencies are only required for some of the scope. Pushing that scope back into future milestones will reduce the risk associated with delivering earlier milestones, at the cost of non resolving unknown technical risk inside those dependencies early. If possible, try to de-risk those separately with their own prototypes, potentially on another team’s roadmap.
For any cross-team dependencies, agree on a code interface for the dependency. This can greatly clarify what each team needs. You may also want to create failing unit tests for those code interfaces. You could go as far as to mock the dependency with basic behavior, which will be useful in your own development and testing. Any performance or scalability requirements can also be part of your interface definition.
Finally, come up with a Plan B for each dependency. This will not always be possible. Examples include planning to build and ship a heuristic solution to a machine learning model dependency, or hard-coding something that will eventually be configurable. Other examples could be shipping a mock implementation of a back-end system, or further dropping scope so that it’s not necessary.
If dependencies cannot be eliminated or committed to such that they are beginning work soon, you should escalate. This is a last resort, only because you need to attempt other methods first. But don’t let dependency conversations linger too long without making forward progress. If progress has plateaued for two or three weeks, it’s time to start the escalation process. Much of the time, you will not end up having to escalate at all, but that’s part of the magic!
Often the mere act of sitting down and trying to write up a proposal will lead to Frank and Faythe to come to a compromise. Partially this is because writing down details forces clarity on the situation. It also reveals options that neither party had thought of independently. A big part of last-minute compromises is that everyone is reluctant to involve their manager, asking for a decision. This makes it more likely that each side will accept a compromise that they would not otherwise have accepted, simply to avoid escalating. — How to Escalate
The short version of how to escalate is:
If the escalation results in a roadmap commitment, you should have a record in the above email. If not, create one. This is critical for clarity and accountability.
Done correctly, most escalations will be resolved by a compromise before your leads are included. This is what healthy cross-team collaboration looks like; identifying problems and finding solutions. Don’t treat an escalation as a threat, your goal is to share context and exercise empathy, and iterate to a solution that is best for the entire company. The biggest failure mode in escalations is not doing them, or not doing them early enough.
How high risk is your dependency? If you cannot answer “Yes” to three or more of these, your dependency is at high risk.
An organization is a set of teams with one name. Your company is one organization. A large company includes many nested sets of organizations. How you group sets of teams together, and what type of shared mission you give them, is the result of trade-offs you make between competing factors like coordination and dependencies.
Organization design is how you choose to group the teams together, and what name you give them. Mission scope, coordination cost, and dependency management are the primary factors in any organization design.
Mission scope simple means the job of the team. What is their primary goal, and what problem are they trying to solve? The mission should be compelling, distinct from the missions of other organizations, and meaty enough to have impact commensurate with the expectations of the larger company.
Coordination cost is incurred in the form of communication overhead for any two teams that have a dependency between them. If possible, you want to remove the dependency altogether. If you cannot remove it, you want two teams involved in the same work to share the shallowest common “branches”. As the distance increases, so does the risk of misalignment and prioritization conflict, which can lead to the dependency blocking the project.
The reporting structure of the organization, literally who reports to whom, determines the distance and number of people in the decision-making loop. In terms of risk, there is a natural incentive to make sets of teams in an organization as small as possible. But there is a competing factor called the “span of control”—giving teams a sufficient number of people to realize impact—that incentivizes larger sets of teams. For any given manager, most companies ideally want somewhere between five and eight direct reports, for cost efficiency and to give each direct report the right amount of attention and support for their personal development.
Making trade-offs between these factors are the primary driving force informing organization structure.
My first job was in a start-up with one and a half other software engineers, and no product managers or designers. There were no teams, or rather we were one big team of 12 including sales, finance, and customer support. There was a reporting structure, where sales people reported to the head of sales, etc. But there wasn’t an organization structure. We didn’t need one.
In a small company, communication and coordination overhead is negligible. When you’re coding a feature, there are probably no dependencies. If there are, you can literally turn to the person next to you to resolve it with a quick conversation. Engineers are able to deliver almost all their work by themselves.
As a company gets larger, there will be many teams. You’re all working on one product, but no matter how you organize, you will start to see more and more dependencies.
Teams can be grouped by technology, feature, business goal, or customer. We are going to ignore grouping by customer, because it tends not to scale past a few types of customer.
Codebases are broken up into repositories, services, modules, and files. They are naturally categorized by theme, i.e. what can I include in this set that’s cohesive as a unit, and has minimal dependencies on other things?
Engineers have a tendency to first think of organizational structures that match these themes. This makes sense! You know this will minimize dependencies, and you know that assigning code ownership will be straightforward. Using an organization structure like this for a set of teams will tend to incentivize quality, which is also a classic engineering value.
Organizations structured this way will excel at keeping things running, and running well. They will maximize uptime, performance, and correctness. They will tend to be more stable over time, as the basic thematic groupings of code do not change often. They are great for knowledge sharing across engineering teams. This structure is often used in Platform organizations.
On the other hand, these organizations will bias towards investment in existing use cases vs new use cases. Innovation will often look like rewriting an existing component. Engineers may gravitate towards this work, even when the business thinks it’s low value. It may be difficult to get engineers to work on higher impact stuff. Work on new initiatives may be diffused across more teams, increasing overhead and risk, and reducing accountability.
If you need to make significant progress on a relatively well-known new or existing feature, consider grouping all the teams who need to deliver work for that feature together. This may make sense, especially for a handful of top priority initiatives. By having every skillset the teams need to deliver their roadmap, you are minimizing coordination cost and dependency risk.
This could look like front-end, back-end, mobile, database, and devops engineers all working directly together on cross-functional teams, separate from other engineers of the same horizontal discipline. One manager may have direct reports from each discipline, and together with their peer managers report to one organization manager, who can easily resolve prioritization issues.
This organization structure maximizes execution, assuming that the solution is relatively well known. It may be ideal for large cannot-fail mega-projects. Of course, projects can always fail, but this structure greatly decreases execution risk.
With this organization design, you are incurring maximum churn on team missions and superstructure, as missions revolving around features will naturally change more often as the features ship. When that churn happens, more people will change managers, and it will take time to reestablish processes on affected teams. Plus, there is a high likelihood that this churn will be incurred again, as the project is completed and teams align to the next feature.
In the initial move to feature organization, there may be resistance to decoupling teams from their previous groupings, especially if they have formed a sense of identity around being a “platform”, or “mobile” organization.
These organizations are sometimes over-staffed. It’s a fine balance on the continuum between creating an organization for a solution that’s fairly well known, versus creating the organization in order to define the solution. Too much of the latter, and you run the risk of having people and teams roped in without a lot of actual work to do. Worst case scenario, this can lead to scope creep and unneeded complexity as teams “invent” work to do.
As the company gets even larger, you are likely to be working on many more totally different things, even multiple different products. The number of dependencies grows exponentially. You cannot truly minimize dependencies, instead you need to pick which ones to derisk.
Large companies contain many organizations. Each organization may be responsible for one product, or one sub-goal. Inside each organization, you can mix and match grouping sets of teams by technology, features, or customer.
Like the feature grouping, grouping by business goal puts a sufficient number of people under one overall accountable person to achieve the goal self-sufficiently. Unlike feature grouping, the solution is often undefined. Instead of being about estimates to build a specific feature, the number of people allocated to this type of organization is based on how much of a “bet” the company is willing to make on this goal. Sub organizations can be created for sub goals, which should have their own single accountable person.
This type of structure prioritizes innovation. Doing this well requires clear goals and metrics. The strategic vision must be compelling. With unknown solutions, there is a tendency to give each product leader similar resources. This option is often used for product-led organizations, i.e. organizations where everyone ultimate reports to a head of product.
Teams and individuals in this model may need to exercise more of their cross-functional skills, versus organizing by technology or feature. You may need to repurpose an engineer for something that does not 100% match their skillset, or you may discover that you need a new skillset as you uncover solutions in the space. You may also need to unblock dependencies by changing the working agreement so that teams inside your organization can do work in codebases that other teams own. These both have real costs. Swim lanes inside the organization may be unclear, especially as you uncover new solutions that don’t match the initial structure.
You don’t have to choose just one organizational strategy for your entire company. A mature product may be organized by goal, while a new product has no organization, and a shared platform organization is structured by technology. Structures will also change over time, as the situation changes. Knowing when to use which structure is important, even if there is no “right” answer.
A common tool when mixing structures is the “matrixed organization”. This means that the reporting structure does not match the sets of teams structure. For example, an engineering manager may have direct reports in various squads, working on different things, and working with different product managers. This increases coordination cost. It also reduces the context between a manager and their direct reports, which can make performance evaluation more difficult. Watch out for negative impact on cross-functional alignment.
Inertia is a force that is actively fighting your organizational design. All else being equal, change is hard, and people will be naturally resistant to it. Assuming you overcome that, enacting change is a lot of work. You need to communicate the changes, move people around, and change the names of teams in hundreds of places. Teams with personnel or mission changes will be starting further back on the forming/norming/storming curve.
Changes in code ownership have their own cost. There should be a very good reason for moving ownership between teams. “Keep the Lights On” (KTLO) type work should be as uniform as possible across teams, which may involve additional ownership changes.
Teams and organization names are a powerful tool for autonomy, i.e. “You’re the Activation team, you’re empowered to own anything that involves user activation across the entire company”. But names can also be burdens, as in “every team with something they can squint at and call activation work is going to try to get you to own that”.
You should also consider whether to group specialized skill sets together (i.e. Mobile, Devops, etc). You may also want to think about giving teams the largest possible “swim lane” to an organization, where they can have autonomy, cohesion, and separation of concerns from others.
There is no perfect solution that will solve all factors. The best you can do is pick a set of dimensions to optimize for, and be aware of the trade-offs you’re making.
As an organizational design changes over time, you will make different trade-offs. This is fine, because there is no perfect organization structure. If you stay at a company long enough, you may see a particular pendulum swing back and forth more than once. Each time is a response to a current problem.
Organizational design is not something you can solve permanently. It will need to be solved again as strategies change, and projects come and go. You can only design an organization for about 12 months, the typical macrocycle where both company and team roadmaps are most stable.
Remember to not create dependencies if you don’t have to. Definitely don’t architect in more dependencies than absolutely necessary. Make the best trade-offs you can, for today. You can always make different trade-offs in the next reorg!
]]>These are probably not controversial. If they are, let’s talk about it!
You should have weekly, regularly scheduled 1:1s with your direct reports. For most roles, this will be somewhere between five and eight 1:1s a week. For product teams, you should also have weekly 1:1s with your direct product manager and design partner. Let people reschedule as needed, but don’t skip too often.
You can expect the same from me. You can also expect that I will have monthly skip level 1:1s with your more senior individual contributors, and any managers that report to you. These are mostly for feedback, which I will share with you as appropriate. I also use them to develop bench talent.
How you run the 1:1s is up to you. You will find that I tend to run mine with written agendas, and lots of transparency.
If we’re in a meeting together, it should be well run! As an engineering manager, either you, me, or my manager will probably run 80% of the meetings we’re in together. Even if it’s a meeting hosted by a cross-functional partner, you should take responsibility for making sure it’s well run.
You can expect that if I invite you to a meeting, that it will have an agenda ahead of time. I will make sure that we stay on topic, take notes, and end on time.
If I take an action item in a meeting, I will resolve those 100% of the time (or get back to you and say I won’t be doing it after all).
When you commit to a deliverable on a quarterly roadmap, those should be delivered on time 90% of the time. If a team has four or five main items on their roadmap, that means that one item might slip every two quarters. The expectation that 9/10 items ship on time can surprise people; that is a higher bar than industry average for not slipping commitments.
I hold myself to the same bar for the roadmap delivery across all my teams, collectively. That doesn’t mean that I expect teams to kill themselves to hit unrealistic timelines. What I expect is that after a period of forming/storming/norming, a team gets proficient at estimates that include an appropriate risk buffer.
The real secret sauce is when a team develops a working relationship with their product owner such that they can seamlessly trade off scope, time, and quality. In my experience, these teams can deliver on any timeline; because the scope is fluid.
At the end of the day, I expect the engineering manager and the product owner to agree on whether something was delivered on time, and that it satisfies the deliverable. As long as you agree, I’m happy on execution.
You can expect me to jump in and help identify and mitigate large risks that could derail us.
Also related to execution:
You and your product manager should be in sync. I expect the 360 feedback for each other to be excellent. It’s unusual for there to be a dysfunctional relationship between an engineering manager and their product partner. When it happens, you can expect that I will dive in and try to debug that as a top priority. In this state, the team has a very low chance of success.
For a deep dive, see What are Healthy Relationships?.
You should have one major piece of impact a year, outside the scope of your team and mission. This could look like shipping an internal tool, revamping an interview question, or updating the company career framework. I can help you identify opportunities. If you sign up to take on something like this, I expect you to proactively drive it forward.
You should also come up with one major product or foundational initiative a year. These will mostly be in the scope of the team mission, but could be anything related to the overall product, or internal processes. As you get more senior, this means understanding the business context almost as well as a product manager, and understanding the technical context almost as well as a senior engineer. Trust your own insights, and put a stake in the ground about something you would like to see happen.
This doesn’t mean that it’s always going to get onto the roadmap. An ideal outcome is that it influences the product org, and helps set strategy going forward. If this exact idea ships, it’s a bonus. That will probably happen about 25% of the time.
You can expect ideas from me, as well. These are never directives, but I do expect you and your product partner to follow up and either validate or invalidate the idea.
Dealing with uncertainty and ambiguity is part of the job. This will only become more important, the more senior you get. You should never let uncertainty become a blocker for the team, or an impediment to healthy relationships.
You can expect a reasonable level of transparency from me about any given situation. I won’t necessarily commit to pushing to resolve any given uncertainty as soon as possible. That’s often a premature optimization. But, I will tell you when I plan to sit with the uncertainty, and when I intend to resolve it.
It’s not always possible, but you should try to have a succession plan for both yourself, and the primary technical lead on your team. Pick one person, and create a growth plan for them. Document where you think they are already ready for a next level opportunity, and where they still have to grow. This will come in handy, often on short notice, when an opportunity opens up. Ideally, we’ve already talked about this person, and have the beginnings of a transition plan in place.
You’re primarily going to be judged on your track record of delivering business impact. This should not be a surprise; it’s the cornerstone of most written company expectations for any role.
As an engineering manager, we are going to primarily deliver impact through excellent execution. What if something is delivered on time, but does not result in the impact that we hoped for? I expect this to happen on individual projects maybe 50% of the time. I do hold engineering managers accountable for their portfolio of projects, and the total impact. Part of our job is to influence the roadmap towards high impact work, refine the scope so that it actually does have impact, and deliver quickly so that we can fail and learn fast.
Anything in the realm of execution is also fair game. Common blockers like cross-organization dependencies, alignment with leadership, and even a project being de-prioritized before shipping are things we are ultimately accountable for resolving.
When in doubt, do the best thing for the company. I expect this from anyone in a leadership position. Often there is temptation to optimize for the local team. As you get more senior, I expect you to optimize for the company more.
]]>I wasn’t sure how to process the feedback at first, but eventually I realized that the biggest thing limiting my impact was my relationships with other people. This was a formative piece of feedback in my career, and marked the first time I started thinking about my “soft skills”.
Healthy relationships at work are not just about the people on your team, or even the people you interact with. They are also the way you interact over email, in a large Slack channel, or in a document. It’s OK to occasionally cross into curmudgeon territory, but don’t make a steady diet of it. If it’s too frequent, too visible, or inappropriate for the audience, it can cross the line. You can’t go wrong if you consistently take ownership, assume good intent, and radiate positivity.
You always want 360 feedback from your relationships to be excellent. In terms of having healthy relationships, this looks like consistent positive comments about your professionalism, tone, and collaboration. Feedback that is specifically about you or your relationship should not be negative, even if there are challenging projects, or circumstances. You want feedback from others to be critical of outcomes, not of you personally.
For engineering managers, this means feedback from your direct reports as well as your peer product managers, designers, and engineering managers. Your manager probably gets feedback from these folks in one on ones, and from anonymous surveys. Feedback can also come from exit surveys when people leave the team.
As you get more senior, the pool of people who have visibility on you grows. At some point, you can reasonably expect feedback to potentially come from anywhere in the company. It starts to reflect not just on you, but also your whole team, and your leads.
Model the relationship that you want in your own interactions with folks. Demonstrate trust, always keep things professional, and criticize the work, not the person. Also, keep an eye out for common work stressors.
Having healthy relationships does not mean that nothing will ever go wrong. But when things do go wrong, your relationships are not the cause, and your relationships are not burned resolving the issue.
Whatever the issue is, you want to talk about it with your team, peers, and your boss. This happens in one on ones, and team check-ins. To some extent, it’s OK to vent or be frustrated in a one one one with your manager. That’s part of what they are there for. But in a team meeting, you want to quickly move forward constructively. You can do this by taking a lens of extreme ownership, where you take responsibility to solve the issue together.
If you have an idea for a solution, use your manager as a sounding board to help you work through it. It’s OK to come to them without a solution, but be prepared for ideas from them. You should expect that 80% of the time, your manager will propose a solution you can act on yourself, versus having them act.
What if the blocker is another person? Remind yourself that you need to assume good intent, ask open-ended questions, and frame things in a positive light. Don’t turn a non-people problem into a relationship problem.
The level of uncertainty and ambiguity you deal with on a regular basis is only going to increase as your seniority and scope increases. At a certain level, no amount of uncertainty is anomalous or outside the range of expectations for your role. Uncertainty itself should not be an excuse for unhealthy relationships or interactions.
Sometimes, you need to live with the uncertainty for a bit. You may catch yourself making the mistake of trying to resolve uncertainty too quickly, versus not quickly enough. Sometimes what is required is just to sit patiently with the uncertainty. In general, your best tools here are going to be perspective, curiosity, and reaching out to the right people.
If you need to escalate to resolve the uncertainty, be sure to follow healthy escalation best practices.
What if you think that a peer is not performing in their role? First, you should give them feedback. Then, try coaching them. Finally, give their manager feedback, either directly, or though your manager. Your working relationship with the person should never suffer. Even if the person is under-performing, you don’t want your relationship itself to become a contributor to blocking the team.
Be mindful that it’s not your decision whether a cross-functional peer, or anyone outside your org, is performing well in their role. You cannot make that determination unilaterally with the information you have. Don’t assume you know what is expected of them outside the context of your roles and responsibilities with each other. What you can do is make your respective roles and responsibilities clear, in writing.
Never balk at performing your own role based on a sense that someone else is not performing well. A specific case that you may see is when you are not happy with the level of detail in product specs. Do not refuse to estimate work, or put items on the roadmap. This can put your relationship with the product manager at risk. Instead, work with the whole team to refine and scope the work together.
The larger the audience, the more potential risk there is to damage relationships. One of the larger forums that you may be a part of in your work is an All Hands Q&A session. You never want someone to be able to interpret a question you’re asking as having bad intent. Even if a question is anonymous, make sure it comes across in a healthy way. Avoid making unvalidated assumptions, and keep the tone positive. Ask yourself, how would you feel if this question was on the front page of the New York Times?
Asking provocative questions is valuable, but not if they negatively affect morale, or reflect poorly on your team. It doesn’t matter if you’re 100% right, if you don’t find an effective way to ask the question. The ratio also matters, you don’t want to be the person always throwing bombs.
It’s up to you to radiate the positivity that you would want to see in anyone. Relentlessly assume good intent. Psychological safety is a two-way street; in your interactions with peers and your manager, given them space to feel safe. Tailor your communication to leave the door open for constructive discussion. Take accountability for how you communicate, how it’s perceived by others, and it makes them feel.
If you find yourself communicating with a sense of frustration or entitlement, take a step back. If you can’t find a way to say something that does not pose a risk to healthy relationships, save it for a one on one with your manager. You might try explicitly labeling it as a “rant”. As always, praise in public, and criticize in private.
How and whether you show up for people affects the relationship. You should make time for regular one on ones with your team, as well as key peer relationships. Communicate that the relationship is important to you by keeping the time on the calendar, and coming engaged with topics to discuss.
Get to know people on a personal level. Spend the first part of one on ones and smaller meetings asking folks what is going on outside of work. What are they excited about, right now? Smile and laugh with them. Make it genuine. Strong relationships built in the small moments will be what you lean on to get through tough times.
Don’t underestimate the concentrated power of sharing a meal with someone, in person.
Much later in my career, I was fired from a role due to unhealthy relationships. My results were great. My peer, team and direct lead relationships were great. But, I had pissed off my great grand boss, and I didn’t last long after that. There was no warning, and no feedback. I’m not even 100% sure what happened, but I can guess.
It came down to a refusal to engage my team, when I balked at moving forward with a project that didn’t have a product manager. I had given direct feedback, but my tone was “this is crazy”, “this is unreasonable”, and “YOU need to solve this”. That interaction put me on a knife’s edge. Later, there was a simple misunderstanding, but my credibility with this person was shot. I had burned the relationship, and it was unrecoverable.
Outside of layoffs, I have more often seen attitude and unhealthy relationships result in termination than actual performance issues. Sometimes you can do enough damage to your internal reputation that it’s impossible to recover. There is no PIP for that.
]]>It’s true. In a leadership role, we’re asked over and over again to produce clarity from ambiguity. At every level of an organization, leaders are synthesizing the all the information they have, and outputting new information. Neither the inputs nor the outputs resolve all or even most of the ambiguity. As leaders, we need to be comfortable with both receiving and emitting ambiguity — it’s never going to be perfect.
In many different situations, both large and small, I practice familiarity and comfort with ambiguity by striving to synthesize information, in writing, aiming to get to 80% fidelity in 20% of the time.
This is a form of the Pareto Principle, also known as the 80/20 rule.
The Pareto principle states that for many outcomes, roughly 80% of consequences come from 20% of causes (the “vital few”). Other names for this principle are the 80/20 rule, the law of the vital few, or the principle of factor sparsity. — Wikipedia
The principle applies in many contexts. 80% of land is owned by 20% of the people. 80% of sales come from 20% of clients. 80% of bugs come from 20% of the code. My corollary is that 80% of impact for anything comes from the first 20% of the work.
In my experience, this is true of all kinds of different work. In the first 20% of a software project’s lifespan, you will get a prototype that is 80% indistinguishable from any form of that product that will ever exist. Maybe this corresponds to the initial MVP of the product, which required one quarter of work.
For pure information processing, i.e. reading and writing, the first 20% of the time can be as little as one hour.
Assuming you’re with me so far, a couple of insights follow naturally.
Together, these ideas are a powerful way to break through personal procrastination and paralyzation.
Learn to think like a consultant. Companies pay consultants to synthesize information, and come up with recommendations. They have very little context in the actual business, maybe 20% of any leader on the inside. They have “business” training and experience — but this is not their primary value. Leaders use consultants to outsource creating clarity from ambiguity. In practice, very often their recommendation is something that the leader has already proposed, but which is now made into a compelling written artifact.
The 80/20 rule is your permission to resolve this ambiguity yourself. You can create the written artifact, even without all the information you would like to have. It will be 80% as good as anything anyone could come up with, regardless of time. It’s faster than engaging any consultant.
This applies no matter what the context is. In my career, I can think of times when I did not trust my own instincts about things like the valuation of a start-up I was thinking of joining, or the fundamental product flaws in something we were building. In all cases, my first take was 80% correct. I’ve learned to not dismiss my own analysis, just because I’m “not an expert”.
When faced with ambiguity (i.e. in every situation, ever), it’s tempting to wait to get all the information you think you need. Even in the best case, you’re making a sub-20% optimization at the cost of time. It’s not worth it. In the worst case, your conclusion will arrive too late to matter.
There is opportunity cost to waiting for more information, both in terms of other things you could be working to synthesize, and in terms of downstream leaders that you’re depriving of information. In these cases, do the 80% version and then send it out. Done is better than perfect.
As an added bonus, you often capture some outsized value for getting it done quickly, or being the one to get it done first. In a sea of potential ideas, the ones that take form first will invariably have outsized influence in the formation of the final, coalesced proposal. “Getting there first” is not-too-subtly anchoring the group’s thinking.
When does it make sense to continue to put effort into something past 80%? Maybe never. But, sometimes the goal posts move significantly. What was an 80% solution in a fixed space is now just part of a solution in a much, much larger space. What you can do is sprint to an 80% solution in the new problem space. It may take as little as an hour.
This may all sound like half-assing your way through everything. But, it’s actually very hard to send partially baked ideas out to your colleagues. It’s hard to take many different signals and synthesize them down into something coherent. Writing well is hard. Don’t confuse the number of minutes something takes with difficulty.
In high school and college, I used to feel guilty about doing this. If I wasn’t always pushing to 100% effort, was I wasting my potential? Eventually, I came to two realizations. First, I never fully stopped thinking about any problem that was still in progress. Even if the 20% effort had not started yet, I was invariably thinking about the problem in the background, whether it was while walking to class, eating, or taking a shower. That effort count too — especially in salaried employment, we’re never really not working.
Secondly, sprinting to 80% of the impact means you can then get started on the next thing. Now, I relish the prospect of checking off an item on my list at 80%, and looking down to see what I get started next.
]]>In this post, I’m going to use the rough outline of a case study, to root the conversation. Because this is such a well know case study, the strategy may seem obvious in retrospect. Having been alive and following this company during this period, I can attest to the fact that it was not obvious what the strategy should be, or that it would be successful.
In 1997, Apple was on the brink of bankruptcy – in fact they had about 90 days of runway left. Expenses were high, revenue was flagging, and market share was down. These trailing indicators were not the reason the company was under-performing, though. Steve Jobs came back, and had to decide how to turn the company around, starting with diagnosing why the company was under-performing.
Jobs’ diagnosis was that the company had stopped innovating:
When I left Apple ten years ago, we were ten years ahead of anybody else. It took Microsoft ten years to copy Windows. The problem was that Apple stood still. Even though it invested cumulatively billions in R&D, the output has not been there. People have caught up with it, and its differentiation has eroded, in particular with respect to Microsoft. And so the way out for Apple – and I think Apple still has a future; there are some awfully good people there and there is tremendous brand loyalty to that company – I think the way out is not to slash and burn, it’s to innovate. That’s how Apple got to its glory, and that’s how Apple could return to it.
This seems obvious, in retrospect. It’s also deceptively simple – who does not want to be innovative? It is simple, but it’s not easy. How did Apple under Jobs (again) turn this diagnosis into a strategy, and how did they execute on it?
I’m going to borrow a strategy format from Good Strategy Bad Strategy: The Difference and Why It Matters by Richard Rumelt, to illustrate.
Apple Strategy 1997
Our primary business challenge is that was are failing to
innovate. Microsoft has caught up with MacOS, while we have
been standing still. We need to leverage our excellent people,
and our brand loyalty, and innovate our way back to
differentiated products.
Our current market share in personal computing is 3.8%, down
from 10% just 5 years ago.
Guiding Principles:
1. Focus our efforts on fewer things
2. Exploit our design and engineer excellence by creating
delightful products
3. Exploit our brand loyalty by focusing on high margins
Actions:
1. Cut our workforce by 30% to increase cashflow
2. Cut current product roadmap by 70% to focus resources
on a few innovative investments
3. Buy NeXT to be the foundation of an innovating
next-generation operating system
In the following years, Apple released the G3 Mac (1998), which had a radically delightful design aesthetic. It was a hit with the market. It released the iPod (2001), which was the first product in the category to be successful, due to a combination of excellent design and brand loyalty. Apple also released Mac OSX (2001), a technically innovative and aesthetically beautiful operating system. None of these product decisions were obvious at the time, but together they comprised a series of market hits that continued though the iPhone (2007), and turned the company around. Apple was successful because they focused, and they executed.
Let’s break down this strategy, using the format in the Rumelt book. The hypothetical Apple strategy is a short, written document that diagnosis the problem, defines how the company will focus efforts, and contains specific actions. This matches Rumelt’s definition of a good strategy:
The kernel of a strategy contains three elements: a diagnosis, a guiding policy, and coherent action. – Good Strategy Bad Strategy: The Difference and Why It Matters
The hard parts are making the correct diagnosis, making the difficult decisions to focus and then actually executing successfully. I love this format because it’s prescriptive about what a good strategy looks like. It allows you to get to the heart of the actual strategy work immediately.
Steve Jobs’ diagnosis was that the company has failed to innovate. That did prove to be a decisive challenge to the business, that once solved, did lead to success. That’s not to say that it was the only strategy that would have been successful. This diagnosis is a good example of what Rumelt calls a key insight.
The first step of making strategy real is figuring out the big ‘aha’ to gain sustainable competitive advantage—in other words, a significant, meaningful insight about how to win.
The book tackles strategy at the company level. The diagnosis should identify the most decisive challenge to the business, and also the cause of the challenge. It’s OK if the challenge is written in terms of the business, and not as a user problem. The diagnosis simplifies the problem space down to one critical factor.
There is no silver bullet to coming up with the right diagnosis. You might start by asking “five whys” about a few important business problems. Perhaps they will lead back to the same root issue. But in the end, picking correctly requires an intuitive leap.
At the core, strategy is about focus, and most complex organizations don’t focus their resources. Instead, they pursue multiple goals at once, not concentrating enough resources to achieve a breakthrough in any of them.
At the company level, there should be one diagnosis, not many. The ideal strategy focuses resources on a small set of actions, and those actions exploit a strength, or take advantage of a weakness.
Many bad strategies are just statements of desire rather than plans for overcoming obstacles.
You should gather data and see if it backs up the diagnosis. What is a single piece of data that makes the most compelling case for the diagnosis?
Don’t be tempted to use the data to set a goal at this stage; a goal itself is not a strategy. The diagnosis should not read like a wish, or a hope.
Finally, the diagnosis needs to tell how the challenge will be overcome.
Apple decided to focus on fewer things, and leverage some key strengths versus the competition. Focus itself may not need to be stated – focus is assumed as part of Rumelt’s definition of a good strategy.
Good strategy requires leaders who are willing and able to say no to a wide variety of actions and interests. Strategy is at least as much about what an organization does not do as it is about what it does.
Guiding principles inform how the business will make trade-offs. How will you choose between different actions? This helps make sure that the actions are coherent, together. It also allows the decision making to scale across the organization. Guiding principles are a good opportunity to maximize existing strengths.
Apple took concrete action, some of them, like layoffs, being quite difficult. The actions were coherent with each other; they all followed a theme, and were mutually reinforcing.
A good strategy includes a set of coherent actions. They are not “implementation” details; they are the punch in the strategy. A strategy that fails to define a variety of plausible and feasible immediate actions is missing a critical component.
Actions need to be both specific and achievable. It’s notable that the actions were not building the G3, the iPod, and OSX. That would be far too specific. These specific products were likely not envisioned for a year or two after the strategy was defined. However, you can imagine individual teams at Apple, like the desktop Mac hardware team, coming out of layoffs with a mandate to create innovative desktop computers, leveraging Apple’s design aesthetic strengths. This is how strategy flows down across the company.
The book is short on this topic. By focusing on company level strategy, it fails to address how strategy is distributed. Indeed, one of the main points is that company strategy should have a singular focus. At the same time, a large company will in fact do many things at once. It doesn’t actually make sense to focus 100% of a company on one thing. In the best case, this looks like local strategies that align to the company strategy, and being prescriptive without being specific about what bets the teams in the company should make.
Strategies focus resources, energy, and attention on some objectives rather than others. Unless collective ruin is imminent, a change in strategy will make some people worse off. Hence, there will be powerful forces opposed to almost any change in strategy. This is the fate of many strategy initiatives in large organizations.
Depending on whether the customer of the sub organization is internal or external, it starts to make more sense to phrase the local diagnosis in terms of the customer. In this way, each organization and sub-organization can have their own strategy that aligns to the company strategy. At the team level, the actions are going to be much more concrete than at the company level.
There are times of year that are naturally more strategy focused. But setting strategy is something you should be doing all the time, as a leader of an organization. Instead of thinking about it like a once-a-year waterfall process, think about it more like cyclical continuous refinement.
There is a lot of stuff that comes after the strategy. It’s common to refresh strategy yearly, and then do headcount planning and potentially reorganize teams. That’s a complex topic, on its own. Strategy is sometimes conflated with vision and mission, although they are actually separate. Roadmap planning in another common follow-on from strategy work.
Despite the roar of voices wanting to equate strategy with ambition, leadership, “vision,” planning, or the economic logic of competition, strategy is none of these. The core of strategy work is always the same: discovering the critical factors in a situation and designing a way of coordinating and focusing actions to deal with those factors.
Strategy is upwards facing. It’s about making a compelling case to your leadership that you have a plan which will lead to business success. For an executive, the leadership audience is the board of directors. For a director, it’s the executives, etc. Strategy also encompasses work from many teams, either an entire company, or an entire sub organization.
Vision is downwards facing. It’s about making a compelling case to the teams and individuals that they should be excited about the work. It’s about inspiring builders and creative workers. It’s about connecting the work to the user. The audience can be a single team.
Defining a vision should be done after creating a strategy, for the simple reason that strategy informs what to focus on. It’s true that you can’t make sure a strategy is achievable without concrete actions, and eventually estimates. But, the greater risk is defining a vision and roadmap that do not address the critical business challenge. After creating a strategy and defining a vision, the next step is to start building a roadmap with high level estimates.
A hallmark of true expertise and insight is making a complex subject understandable. A hallmark of mediocrity and bad strategy is unnecessary complexity—a flurry of fluff masking an absence of substance.
[NAME] Strategy [YEAR]
[LINK TO PARENT STRATEGY]
Out primary business challenge is [THREE SENTENCES]
[BACK IT UP WITH DATA]
Guiding Principles:
1. Exploit our [STRENGTH] by [DOING X] instead of [DOING Y]
2. Exploit our [STRENGTH] by [DOING X] instead of [DOING Y]
3. Exploit our [STRENGTH] by [DOING X] instead of [DOING Y]
Actions:
1. [THREE SENTENCES] [ACHIEVABLE GOAL]
2. [THREE SENTENCES] [ACHIEVABLE GOAL]
3. [THREE SENTENCES] [ACHIEVABLE GOAL]
The key stages in drafting a strategy are all around feedback. First, get feedback from your peers. You all need to be on the same page about the primary business challenge, and the most important actions. At every review, you want to answer the question, “would I fund this initiative”?
Then, get feedback from your leadership team. Ask the to be brutal. Get feedback both 1:1 ahead of time, and in a group setting. Plan to do multiple rounds of edits. Ask how this relates to other strategies.
Finally, incorporate feedback from your organization itself. This often looks like the addition of actions that line up to the strategy. There is a danger in both communicating the strategy before you have upwards alignment, and also waiting until the strategy is locked to ask for additional actions. You need to find a balance. Give teams permission to go off and create their own strategies that line up to this.
]]>Send out these pre-reads ahead of time:
(1 minute)
In this workshop, we are going to learn how to estimate Epic level roadmap items. For example, these could be the primary projects for a team of engineers for an entire year.
Note: This is designed to teach the fundamentals of Epic estimation in a hands-on way, using analogies to real-world events that everyone is likely to be familiar with. We’re not going to actually estimate any actual software engineering Epics.
(5 minutes)
We’re going to practice basic blind-voting using story points in a few minutes. First, let’s quickly recap Getting Started Estimating with Story Points.
Story points allow for quickly crowdsourcing low-granularity estimates, by leveraging:
Note: plan to table any extended discussion of the merits of story points; that’s not the point of this training
(15 minutes)
Let’s recap Estimating Epic Stories in Three Steps
Note: If you’ve been estimating User Stories with points, there is a JIRA report for the actual historical story point values of your past completed Epics. This isn’t the same as the initial estimate of those Epics; it’s the sum of the story points for all the completed User Stories, once you were actually “Done” with the Epic.
Note: the “DRI” (Directly Responsible Individual) should be a specific engineer who will lead the work, and who is primarily responsible for the commitment.
Let’s say we have the following actual Story Point counts for completed Epics. These are not strictly Fibonacci numbers because it’s a sum of the actual story points delivered, not the original estimates.
Previous Party | Description | Actual Story Points |
---|---|---|
Casual Halloween Party | - 3 friends - kids dressed up - wine - handing out candy - walking around neighborhood |
8 points |
Easter Sunday | - 6 friends - Ham and Scalloped Potatoes - ice bucket drinks |
23 points |
Christmas Day | - research, bought and wrapped all the gifts - holiday cards for 200 people, addressed them manually - dinner Roast Beef and popovers with a chocolate tart |
85 points |
Let’s estimate a new Epic for a Thanksgiving Dinner. First, we need to make sure we’re all on the same page about the scope. We need a product owner to answer questions. To facilitate doing this quickly, you can use post-it notes (either physical or virtual).
If the conversation is not surfacing some key criteria, the facilitator can ask questions like:
(15 minutes)
Now, we are going to break the overall Epic into Epic Milestones. In real planning, these Epic Milestones would be your actual quarter-level roadmap items (assuming the overall Epic is too large for one quarter).
(5 minutes)