It is time to work through our division operating plan for 2025. We’ve had many hours of discussions around which customers to focus on, volatility in the market, where we should build trust with customers and what kind of initiatives will amount to strong growth. I find it energising to spend time thinking about these. It can really enable us make impactful decisions to help customers.
Most debates that happen during these discussions go in a similar way to what I’ve observed in other places I’ve worked in. Every team within an organisation is trying to grow. But they have their own path: ideas and metrics to influence within their localised areas. When it comes to picking a direction, everyone acknowledges the need for a strong focus, yet resist the idea of having to make a tradeoff to get there. This ultimately result in goals and documents being written with the widest view, enabling teams to do anything. That means, nothing ever changes. This is a bad idea.
This takes me a back to the days of being a principal engineer…
When I was at Expedia, there was a program created to transform all of our edge services to GraphQL. This was a massive task, given the traffic, business logic and challenges of running something new. The business never wanted to slow down to have a platform shift so we were switching engines mid-flight. It was an uphill battle. The migration team continued to fall behind as other side of the team continued to run experiments and push features through the REST API. I arrived on scene with lodging search query taking 1.5y (there was a Java to Kotlin rewrite in the midst of it too… of course!) and lodging details taken 1y and not being close to completion. After doing a deep dive for 2-3 weeks, I created a plan and we managed to get the program done in ~4 months (excluding clean up time, which took longer). Looking back, the key things I helped with then, can apply to larger strategic shifts we were discussing for the whole division.
- We limited our scope to purely an outcome that everyone can easily identify and move towards. It was also something that would disqualify certain ideas quickly to align the team.
Our goal: all web and mobile clients shifting traffic to the same GraphQL service. No code improvement goals, no performance improvement goals, nothing else.
- I spent a few weeks to dive deep into understanding the systems and validating ideas. This allowed me to come up with an execution plan that was realistic and addressed current challenges.
Our plan: We decided to create a single (marked deprecated) field that can be a proxy to the REST service. This meant that every call collected logic from each application, reducing the problem to “adding another engine mid-flight” instead of removing an existing one. Then we cleverly created a series of code freeze rules in the REST API that caused teams to migrate few fields at a time to the GraphQL service (and delete the logic from the REST service). As fields were added, proxy field would be thinned out. All fields were moved within 4 months! > (What I want to illustrate here is how specific this solution was.)
Of course, at the time, I was given accountability to make it work. I decided to delete 10s of thousands of freshly written, beautifully crafted Kotlin code in favor of shitty copy pastes. It was that or spend 2-3x more on catchups and even more time on discovering and fixing bugs. Some decisions arrive with tradeoffs, disappointment and randomization. The focus did help us move much faster towards our original goal. We completed our migration in about half the time it would have.
These 2 insights from my experience still holds: create limited scope and dive deep into what you have to create a realistic plan.
With recent discussions, I’ve gained a few more nuances in these learnings. Few extra things to consider if you are planning a big project or the year ahead:
Scoping goals
- Needs of teams at the top layers (or top of funnel) are not the same as needs of the bottom layers in an organisation. Experience and Go-To-Market teams want to cast a wide net to experiment. Wide scope will be the demies of platform.
- Use a mechanism for limiting scope. It could be focusing on a specific customer or a strength that can be built upon. Some specific lens into the problem goes a long way.
- Make sure your goals point towards a meaningful outcome or real growth towards the organisation. As an example, are the selected customers a real opportunity with a large enough total addressable market (TAM)?
Deep dives into the system
- Understanding maturity of different parts of a product is equally important. Maturity affects how much can be taken on at what velocity.
- Scoping becomes incredibly hard when there is not enough data. In fact, if there is a lot of debate, you lack data in the conversation. Part of the deep dive is to discover data, not just how systems work.
Of course, all of this has to do with creating a plan for success. Executing is much more challenging. It would probably require you to learn quickly and adjust the plan many times. Don’t be afraid to do that.
Leave a Reply