Tag: planning

Crafting a Technical Strategy That Actually Works

San Diego, USA – November 2025 – Photo by Kevin Goldsmith

It’s planning season for most companies. By the time November rolls around, the board decks are being assembled, the budgets are being scrutinized, and every technology leader, from the C-suite to frontline management, is being asked some version of the same question: Where are we headed next year?

Regardless of your scope, having a clear technical strategy is crucial. And not just a mental model you carry around in meetings; a documented strategy your team can reference, question, and ultimately internalize. The absence of that clarity is one of the fastest ways for an engineering organization to drift off course.

Why documenting a strategy matters

When there’s no shared strategy, every team ends up making decisions based on personal taste, excitement about a trend, or something they saw in a conference talk. Without a shared North Star, those decisions diverge quickly. I’ve seen it firsthand: people heading in different directions, not because they disagree, but because no one ever explained where the organization is trying to get to.

Misalignment shows up everywhere. Architectural choices start reflecting old org structures instead of future goals. Product partners become frustrated because engineering appears to be prioritizing strange work. The business begins to question why teams are focused on internal rewrites instead of delivering customer-facing value. From the outside, it can look like chaos.

The hard truth is that most of these problems aren’t technical; they’re leadership failures. They come from not taking the time to define, document, and communicate the strategy.

What a good strategy looks like

A technical strategy doesn’t need to be fancy, but it must align with the business. If the business wants to enter new markets, your strategy should account for internationalization, payments, compliance, and scale. If the company plans to grow revenue by 10×, your architecture needs to be able to handle a 10× load. If you’re betting on expanding into adjacent industries, you should know whether your current systems or your current talent can support that.

A useful strategy has a few characteristics:

It’s coherent. Not a bag of unrelated goals. All the pieces should pull in the same direction.

It’s understandable. Anyone in your org should be able to read it and explain it to someone else.

It’s written at the right altitude. Too detailed, and it becomes a roadmap. Too vague, and it becomes meaningless. The test is simple: can people use it to make better decisions without needing your permission?

It’s a living document. The world shifts—the business shifts. Your strategy should update when reality does, but not so often that no one can keep track of it.

And, this is important, you should ground it in both where you are and where you need to go. Strategy isn’t about predicting the future; it’s about preparing your team to meet it.

Start by working backwards

Amazon made “working backwards” famous, but the underlying idea is helpful in any organization: imagine the future state, then figure out what needs to be true to get there.

If everything were going well two years from now:

  • What would your architecture look like?
  • What pain points would be gone?
  • What capabilities would your team have?
  • What new markets or products would the business be ready for?
  • What skills would you need in the team that you don’t have today?

Once you can visualize that world, you can start mapping backwards to the key technical bets that move you in that direction. Those bets might look like:

1. Moving toward event-driven architecture

2. Eliminating or isolating legacy systems

3. Prioritizing observability

4. Making large structural changes like cloud migration

5. Reorganizing teams around more scalable patterns

6. Reskilling people as technology evolves

Each of those bets should be tied directly to a specific business outcome. Otherwise, it’s just engineering for engineering’s sake.

Don’t create strategy in a vacuum

If you’re in the C-suite, validate the strategy with your peers first. Make sure the rest of the executive team understands and agrees with it. They may have expectations you aren’t aware of, or strategic initiatives that need your support.

If you’re a VP, director, or EM, share your draft with your cross-functional partners. Product and design should understand how the strategy shapes what you will and won’t do. Their strategy should align with yours, and yours should align with theirs.

When strategies diverge, teams drift. When they align, the work feels almost frictionless.

Communicate relentlessly

Communication is where most leaders fail, myself included at times. Sharing the strategy once is meaningless. Most people won’t internalize it until they’ve heard it repeatedly, in different contexts, tied to real decisions.

Put it in your all-hands. Reference it during project kickoffs. Use it when explaining tradeoffs. Make it part of onboarding. Ask teams to explain how their proposals align with it.

The goal is to make the strategy the frame everyone uses to make decisions. When that happens, you suddenly spend far less time correcting teams and far more time accelerating them.

How you know the strategy is working

You shouldn’t need to police architectural choices. Teams will make decisions that generally align with your intent.

You should see less rework, fewer surprise escalations, and fewer “Why are we building this?” debates.

Product partners should understand why certain internal work matters.

Cross-team integrations should become easier because everyone is working towards the same future, not the one in their own heads.

Your platform should scale as the company scales, ideally without drama.

And, most importantly, people should feel like they understand the purpose behind their work. Purpose and autonomy are two-thirds of what drives intrinsic motivation. A good strategy gives people both.

Final thought

A technical strategy isn’t a crystal ball. It’s not about outsmarting the future. It’s about giving your team the clarity and context to face that future together, and build well along the way.

If you’ve been putting off writing your strategy document, now is a good time to make progress. Your team will thank you later, and honestly, your future self will too.

Originally published in my newsletter on November 16, 2025

The Personal Strategy Off-site

If your company is starting to plan for getting back into your office, now is a good time for you to schedule a personal strategy day.

The Whirlwind

In the whirlwind of the day-to-day work, it is often hard to carve out time for something that does not have a specific deliverable. Working from home can be even more challenging because of the additional pressures of helping your family. In the tech lead training program I am doing at Onfido, we are currently discussing how to be more strategic leaders. A familiar dictum of strategic thinking is the criticality of taking the time to think and plan.

The Personal Strategy Day

Liminal spaces are the transitionary spaces between things. In the liminal space between moving from working at home to being back fully in the office environment, you have an opportunity to try something new—a personal strategy day.

Block out a day in your calendar as people start moving back to the office. There will be some turbulence then as everyone is transitioning. It is the perfect time to start thinking about what you want to accomplish for yourself and your team before the whirlwind starts up again.

The Personal Off-site

Companies schedule off-sites to get away from the distractions of the office. If you can find a “third place” (a place that is not your office or your home) where you can focus, that is ideal. If not, book a secluded conference room in your office, or find an empty desk far from where you usually sit. If you are still at home, let your family know you are working, and need some blocks of focused time.

Focus

Don’t read your e-mail. Don’t take any meetings. Your job on that day is to think and plan. To help me focus, I will usually print out whatever supporting materials I think I need and work on paper to avoid the lure of notifications and other electronic distractions. Think of this as a gift of time and focus that you are giving yourself.

What to consider

Think of the time before the lockdowns began. You may have just been starting on your 2020 commitments and deliverables. What was going well then? What were your concerns? Now think through what you have learned about your team, the work, and yourself during the lockdown. What do you want to keep, and what do you want to discard as you go back to the office? What about the industry you are in, and the world at large has changed? What new pitfalls and opportunities are there? Now think ahead to the rest of the year. What new goals should you have for yourself and your team?

Take notes. Write things down. You will want to refer to them as you go through the year to revisit or remind yourself of your thinking.

Now make a plan. Not too detailed because the world is going to keep changing. Detailed enough that you feel as if you have something against which to execute. Write that down also. With milestones, if possible.

Finally, think about the process you just completed. Did it work for you? Would you do it again? If so, what would you change next time?

Retrospect and Revisit

This whole process may take anywhere from a couple of hours for you to an entire day. Don’t be too preoccupied with the length of time you spend. You are starting to build a practice of taking time for strategic thinking, so this is about taking more time than you have before.

If you found this valuable, you may want to plan your next strategy day for six or twelve months from now. Again, block it out in the calendar early and protect that time!

You may also find that it is good to schedule smaller blocks of time, weekly or monthly, to revisit your plan, track progress, and make adjustments. These blocks of time are strategic thinking too!

Conclusion

If you struggle to keep time for strategy, building a structured approach like a personal strategy day may help you create a practice. Using the liminal times like transitioning from lockdown back to whatever it is that comes after is an opportunity to block and protect time. The liminal times are also crucial for strategy because your past assumptions are likely no longer correct, and there may be some opportunities or challenges that weren’t visible before.

Some resources

I’ve spent the last several years building a structured personal strategy process for myself. Many people have inspired my practice. Their suggestions may inspire you as well.

moving to scrum: The First Planning Poker

That could have gone a lot better.

I had originally prepared the product backlog with stories that were way too large. I think that I was confusing the role of the Scrum Product Owner and the XP Customer a bit. I was worried about “being polluted.” After reviewing the Scrum planning process again, I realized that I really needed to break up the top priority stories. I took the top dozen and broke them up into around 40 smaller stories. Some I left for the team to break up as an exercise. I needed input from the team leads to break up a few of the stories, so I left them as epics. There were a few stories that defied division. These were large design tasks. We have to interface with a couple other teams and get some customer feedback, so we need to have some initial designs to present that are somewhat comprehensive. I knew that this would be difficult to incorporate in an Agile process, but it is a part of our work and I wanted to try and assimilate it. We also had some carry-over work from the previous release and some open-ended consulting that we needed to account for in our estimations. The carry-over work was interrupt-based, basically bugs found by other teams that we would need to turn around quickly. To incorporate this into the planning, I created a story at upmost priority to account for this possible work.

Given the distributed nature of the team, I decided to do the planning poker on-line. I booked some video conference rooms, but also a phone conference. Since physical cards would not work for us, we used Adobe Connect (‘natch) with a polling pod for each person to put in their card choice. I figured that most of the team would hang out in their offices and dial in to the meeting, but everyone came to the conference rooms and that actually worked really well.

I’d budgeted about 2 hours for Planning Poker. I figured that this would give us time to get into the process and go through a few sprints worth of stories. Turns out that my estimating skills on planning poker needs some work itself.

The hard-to-estimate high priority stories derailed us for a long time. Especially the open-ended consulting and bug fixing tasks. The team got stuck on estimating an unknown. It took a lot of time and a lot of frustration, but we finally reached a rough consensus and moved on to the difficult-to-split design tasks. We tried a zillion ways to split them up or come up with better estimates. In the end they got a high estimate and were tabled to the sprint planning meeting. In retrospect, even though these stories were the highest priority, I probably should have started us on the concrete tasks and come back to these later in the session. For a team’s first planning session these were some pretty tough tasks to work through.

Once we got past these tasks, it got a bit better, but it was still difficult. The team got too caught up in the details of each story, unable to make an estimate before digging deep. If there was uncertainty, we got really deep in the weeds. The 2 minute timer didn’t help. The more concrete stories that needed to be broken up took a lot more time than I expected too. Members of the team kept wanting to discuss details on each story. The scrum master and I kept trying to bring us back to the sprit of estimation, but it was a slog. After almost three hours, we had only gotten through a dozen stories, not even enough to get us through our first sprint. I’m going to look for better ways to explain the spirit and intent of Agile estimation to the team. It is difficult to grasp sometimes for detail-oriented folks.

Even though we were short of estimated stories, we went ahead with our first planning meetings anyway. One team was able to take on stories and create tasks and estimates from them. They may be a bit short of work, but they made some progress. The other team had difficulty pulling stories given the paucity of choices.

We learned some useful things today. We separated the teams to do the sprint planning, pulling from the backlog. The teams were in separate video conference rooms. I and the scrum master moved between them. We realized afterwards that we really need to have both teams together to figure out how the stories would be divided and then the teams should have separated to create their tasks and do their estimations. I was also too eager to jump into the poker session itself,  and I didn’t spend enough time going through the backlog with the team and discussing my priorities. We’ll fix these issues next time.

We’ll do a second planning poker session tomorrow. Before then, I’ll take in the new stories we created in the backlog, make sure that they are prioritized correctly, and try to break up some more of the stories so that we don’t have to spend time doing that in the poker session.

I knew the first planning poker session was going to be a bit rocky as we felt our way through the process, but for me it was brutal. I know that as we gain experience it will get progressively easier and so I’m more worried about the team’s morale right now than I am concerned about the process. We’ll see how it goes.

On one hand, our super short sprints play to our advantage as it lets us try stuff out in a sprint without a huge commitment. On the other hand, it makes breaking stories up into sprint-sized chunks really difficult. It feels a bit like we’ve jumped into the deep end because of this. We’re open to making a lot of changes, but we’re hoping to keep a consistent sprint length through the cycle since modifying the duration of our sprints will make it difficult to establish a rhythm. Again, we’ll see how it goes.