Your Team Needs a Strategy — Here’s How to Write One
Team leaders — If I walk up to you today and ask to see your team strategy document, can you show it to me? Answer: Probably not. You don’t see a strategy document as a great investment in time. You’re also too busy.
I’m here to tell you you might be wrong.
Spending the time and the effort building a plan to execute against that everyone (team members, partner teams, internal customers) can view, read, and comment on helps set your team(s) up for success better than any other activity, including architecture or technical direction. The strategy document also helps the team articulate their existence and how they fit into the business.
You must write a strategy document for your team today if you don’t have one.
The Why Your Team Needs a Strategy (Document)
We often refer to humans on the team or the tools they work with as resources. But only one resource matters, the one we never get back— time.
Time is all that matters. (I often say, “Time is the enemy.”) You do not have infinite time to ship product out the door. Eventually, you come up against limits: release dates, compliance dates, a raise date, and even some arbitrary performance review date. If you’re in a startup and do not ship, your cash flow might dry up, and you’re all out on the street looking for a new gig.
But, are you working on the right work? Yes? No? How do you know you’re not wasting time? What measure can you point and say, yes, that is the right work?
The way you know is:
- You have a clearly stated end-state vision of the current iteration of the product/platform/system;
- You have an articulated measurement framework to measure progress;
- You have goals that are beyond “ship” goals — you can measure change;
- You can make smart time tradeoffs between your measurable goals and the inevitable interrupts;
- And you know where you are along the line of progress between now and the end-state vision.
Understanding how and where you spend the team’s time and how you measure progress and success is crucial to setting the team up for success. Accounting for it all — from tech debt to the build system friction to focusing on the right work — allows you to allocate your resources against your highest priority problems and burn them down while making the right tradeoffs.
The strategy document provides these answers. The strategy provides the why, the how, and the what for the team. The resulting document:
- Provides the team direction,
- Allows the team the freedom to come up with solutions to well-articulated problems without micro-management;
- Highlights engineer system ownership and possible promotion paths,
- Enables teams to set effective OKRs,
- Allows teams to be clear-eyed around their time investments,
- Builds alignment with stakeholders,
- Helps teams hire,
- And helps retain great talent.
But you cannot allocate your resources effectively against the highest priorities and make smart tradeoffs if you don’t know what those priorities are. You can guess, and you may be mostly right, but you’ll still burn time around the edges. The more time lost, the less the team is set up for success.
The Enemy: Headless Sprints
Here’s what happens if you do not build an effective strategy.
Agile’s most pernicious and time-sucking anti-pattern is the Headless Sprint. (Sometimes called ‘headless chicken sprints.’) Headless sprints are where we mistake progress with motion. This pattern happens all the time.
In Headless sprints, we populate engineering team sprints with work that:
- Does not align with overall business goals,
- Supports the wrong tradeoffs,
- Builds the wrong features,
- Works contrary to business goals (i.e., duplicative work, wrong scope)
- Or (most of the time) has low-to-marginal value.
With the best of intentions, you can fill up sprints with work that looks like progress for a year or more but doesn’t ladder up to any team-, departmental-, org- or company priority and ends up as tech debt. It’s trivial to do because there is always more work for the team.
This activity is motion. Motion makes the team look very busy. From the outside, the team looks like it’s providing value. Maybe it is, but most likely, it isn’t — or not coming close to the value it could contribute. You cannot tell because you’re not executing against a more comprehensive strategy, and you are not measuring yourself. Without an end-state vision, goals, a strategy to get there, or measurement, you have no way to validate your progress. You’re just guessing. You’re probably running headless.
The point of an engineering team is to build something that generates business value. You waste time building headlessly with no plan. You will never get that time back. It’s gone, and your team, with motion but very little actual business value, is at risk of dissolution should someone ever notice.
Anatomy of a Strategy Document
Saddle up. We’re going to… write a document.
Writing down the strategy is both simpler and more complicated than it seems. We use this document to quantify the problems to solve, who we’re solving it for, how we’re going to solve it, and how we know if we’re doing a good job. It’s a blueprint that describes team priorities from a very high level and firms up the team’s direction.
The strategy document is immensely useful in bringing internal customers along so they understand what the team is doing, as an onboarding document, for costing and planning for more headcount, in pitch and raise decks, to guide a planning process and innumerable other uses. Once you write it, you’ll refer to it again and again. It will be hot linked in your bookmark bar.
This template is a sample. Sometimes you need more sections than presented here. Sometimes you need fewer. And, since I spent so much time working in business travel, I’ll use travel as an example.
Here we go.
What problem are we solving?
Write down, as concretely as possible, the overarching business problem your team is solving, why this is a problem, and how the team’s solution will solve this problem. Sometimes this is the same as the mission statement, but not always. Understanding the problem is the best way to determine what to build and why.
In a multi-team setup, where multiple teams work on the same problem, the problem statement and mission differ.
Example: Business travel is complicated, and business systems are antiquated, so we will simplify, modernize, close gaps, and integrate new capabilities.
What do we do today?
Write down the team mission statement. This statement is why the team exists today. Stick to a single sentence, if possible.
Example: We deliver to the customer the UI/UX front end for searching air, hotel, and train. We also integrate the packaging system into checkout for an end-to-end funnel experience.
Where do we want to end up?
Write down our vision statement. This statement is where we’d like to be in 2–3 years. It does not need to be perfect but should provide a guiding light. A high-level diagram helps to buoy the vision statement.
Example: State-of-the-art and performant end-to-end customer-focused business travel booking funnel that provides the customer with the best information presented in the most understandable way in the industry!
Who is this system for?
Write down the customer personas — those customers who will use the product. Understanding customer personas and their problems helps to hone in on the right features, metrics, and priorities to define the big boulders of work.
(If you’re lucky enough to have a user experience researcher… you are lucky indeed. Show your appreciation!)
Example: Individual bookers within a known company need to book for themselves through an easy-to-use funnel. Sometimes they have admins booking for them, or for entire teams. Customer service needs to support customers if they encounter an issue.
What do we want to make true?
What are the 4–6 big box steps we want to achieve to make the vision true? What are the most significant features we need to deliver to customers? And why do we need these features?
(These steps later turn into Objectives in OKRs.)
Example: We will integrate with ML services that provide personalized ML-based air, hotel, and train sorted searches for the best possible combination of stays, integrate with the package recommender that will auto-pick the best trip, and the purchasing system to allow easy purchase with integrate into trip management services like our own, TripIt, etc.
How do we know we’re on the right track?
Here’s a controversial statement: figure out your first 3–5 measurement priorities before writing a code line. What you measure defines your product because you will drive feature priority around driving up those metrics. Measurement is like a compass in the dark: it tells you if you’re getting closer to your destination. You’ll refer back to your metrics often.
Defining your metrics upfront also helps drive your data science strategy, business analytics strategy, logging/ETL strategy, and overall data storage strategy.
Some ideas of measurement:
- TAM (total addressable market) if known or % of TAM based on user signups
- User counts and user adoption.
- CAC — Cost of acquisition of a customer.
- Acquisition and activation — site visits, site stays, time in funnel, visit/purchase ratios.
- Retention percentages — return site visit ratios.
- Revenue — Amount of pure $$ generated.
- Any other up-front metrics you want to measure — actions taken/second, certain activities, etc.
Example: We will initially measure site visits, time through the funnel and on each page, frustration matrixes, visit/purchase ratios, and return site visit ratios. We aim to minimize time through the funnel from original search to purchase. We also capture all the search data for feature engineering purposes.
What stuff do we need to deliver and/or make better?
Big boulder goals are the most crucial part of your strategy. These lay out the team’s expectations and the team’s priorities. Understanding the over-arching goals allows the team to determine the tactics and the execution. These boulders should connect meaningfully to your metrics.
Your goals should combine ‘ship’ goals (We will ship 1.0 of X feature) and measurement goals, with a preference for measurement over ship as product development matures.
If you identify your first set of core metrics, you’ll have a much easier time defining the levers you want to move during the project. Later, you will build a measurement framework, but something is much better than nothing for now.
(These later turn into Key Results in OKRs.)
Example: We need to provide a frictionless experience that lowers the time-in-funnel by 15% and increases purchases by the same 15%. We need to optimize our ML sorts through data capture so we can offer both high value personalized recommendations and increase margin on air by 10%. Purchasing must have a 5–9’s up time.
What must we build to get from here to there?
At the very end, detail broad-brush technical decisions. Are we developing a platform where we will build services and APIs? Are we going to consolidate platforms together to make one coherent product? Refactor from a monolith to microservices as part of the lifecycle? Are we going to build mobile apps?
Leave the deep technical, operational, and infrastructure decisions to the architecture design documents.
Example: We will build a React/Typescript web app because business users prefer to book online (see personas!) and mobile apps for check-in, gate, ticket, and alert information. We will integrate into a platform of booking APIs that will manage the search, sort, and payment processes. This platform will, in turn, integrate with a combination of new (NDC, Hotel systems, Southwest), traditional GDS, and custom AI/ML algorithms.
Aside: isn’t this the Product Manager’s Job?
I believe firmly in two facts:
- The team leadership, including the engineering manager and the technical lead, must align themselves with the Product Manager on the team’s business strategy. For the team to work, the engineering manager, the technical lead, and the product manager must work together as a unit. While the PM will drive the business side of the strategy, the EM and TL are responsible for the execution.
- You are never guaranteed your team will have a product manager. Ever. Full stop. And, if you are sitting around a conference table wondering who will be the PM when you don’t have one… guess what? It’s you. Learning to think in business terms is a good life skill, even if all you want to do is design massive eventing systems.
Refreshing the Strategy
Yay, you have a strategy document, and I bet it took you a month to write. So you relax and say it was hard, but now it’s done. Now, you can roll into planning.
You leverage the strategy to plan! Fantastic! And then you finish a bunch of work, and you plan again! Except you’ve eaten through a bunch of your strategy and learned some is right, some is wrong, and you want to change all your metrics! No plan survives contact with the enemy — and you’ve just met the enemy.
A strategy document is a living document. Like any other document, it ages over time. So before any quarterly or half team planning, you must refresh your strategy document. Walk through the entire document from top to bottom. Is the vision still solid? Are any major boulders complete and delivered? Have we learned new essential facts about how our customers work? Maybe we had a pivot, or our initial metrics were wrong, and we needed a new metrics framework.
Build the refresh into your planning cadence. Writing the 3rd, 4th, or 10th time through doesn’t take as long. But keep your strategy current so it remains your guiding light document.
Aside: OKRs and Metrics
A quick aside on OKRs and Metrics without getting into the mechanics of either: it’s much easier to set objectives — key results for the team when you’re already driving against… objectives and key results (metrics).
Setting the strategy and periodically refreshing it is how the OKR magic happens. If you have a mission, a vision, sets of customers, clearly articulated problems, the big “boulders,” and a technical strategy, OKRs are much simpler to derive. Of course, developing good, clear objectives sometimes is still challenging, especially as a product matures, but having a written strategy brings clarity to the planning process.
Go Forth and Conquer
In my career, I’ve led teams and organizations with strategies clearly articulated and without. The ones with a clearly articulated strategy have always been more successful than those without. Even if the strategy is buried in a giant GANTT chart, having one is much better than not.
The best part of executing against a written strategy is that it often highlights interesting opportunities — areas a team can go invest which will have a much bigger bang for the buck than simply executing sprint after sprint. These opportunities are much easier to see when they’re written down and shared instead of stored in someone’s head.
Hopefully, some of this is useful to someone! Go forth and conquer!
