You have 1 article left to read this month before you need to register a free LeadDev.com account.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
Estimated reading time: 7 minutes
Lead high-stakes, ambiguous projects by breaking uncertainty into clear, actionable technical plans.
The further along you go in your career, the more complicated your projects start to become. At a certain point, you will likely find yourself faced with problems that you’ve never solved before. You may even be tasked with leading a complex problem with no clear solution, where everyone looks to you to find the answer.
Leading a project filled with ambiguity is exciting, but also incredibly intimidating. They are usually high impact, and oftentimes, very high visibility, which can feel like a lot of pressure. Yet these kinds of projects also present a unique opportunity to deliver immense value to an organization or product.
I was recently entrusted with a multi-year project that had a vast and unclear scope. Not only did I need to build an entirely new team to execute on this initiative, but I also needed to come up with some semblance of a technical plan for us to get started with. Along the way, I learned how to effectively kickstart and stay true to technical plans for large projects.
Carve out focus time
Before you can even attempt to plan a long-term project, you must first understand the scope of the problem. If the project you are leading involves a new domain or system, you will need to learn more about it. This means that you must give yourself the time and space to thoroughly explore the problem.
For my project, I needed to understand a new system in a similar domain that was built using entirely different technologies. However, when I first joined the project, I continually made the mistake of juggling unrelated tasks alongside the research and planning required. As can be expected, I made little progress, which, in turn, made it all the more intimidating.
To make real headway, I scaled back my involvement elsewhere and solely focused on the project. I sliced my day into two parts: the mornings were dedicated to making technical decisions and identifying people across the organization who could help me answer questions that I couldn’t answer. The afternoons were my focus time to document new ideas, spend time learning about the new system and domain, and draft and refine my technical plan.
Understand the long-term goal
When kick-starting a project, it’s challenging to simply know where to begin. Further, if you’re planning a product roadmap that stretches out across years, it can be daunting to pick apart the possibilities or predict the state of your system at that point.
Luckily, no one is expecting you to plan for three years from now, but that doesn’t mean that you want to lose sight of the three-year vision when you’re strategizing. Try to internalize the long-term goals of the project without focusing too much on delivering them at the start. If you are leading the planning of an ambiguous project, you likely have a product requirements document (PRD) that outlines the fundamental tenets of what you want to release; focus on figuring out the path to those requirements first.
When planning a long-running project, it’s essential to have a thorough understanding of the project’s vision and intent. What are the desired outcomes of the project? Who are the consumers and customers of your project, and what will this unlock for them? How will this work benefit both the business and its customers? How would you explain the value of this project to someone in the organization who is hearing about it for the first time? Why is this work even worth doing?
These are all questions you want to try to answer for yourself in the early days; eventually, you will need to not only socialize the answers but also use them to help you drive a technical strategy. When you can understand the value that your project provides, you can begin breaking down the technical pieces of work that need to be built in order to deliver value early and often. Ultimately, you want to keep that long-term vision as your North Star so that, as you take steps towards it, you can make sure that you are walking in the right direction.
Break the problem down
Once you’ve understood the broader goals of your project, you now need to take the first steps towards achieving it. For me, this is the hardest part of the planning process. Once you can identify the discrete pieces of value that you want to deliver, you must consider how to execute on delivering that value to your customers.
In the process, you will likely find that there are problems you need to solve first in order to unlock the features that come later. The process of breaking the problem down allows you to see the various dependencies of your project, which then makes the actual planning work a lot easier to visualize and think about.
For our project, this process involved identifying all the problems I knew we would need to solve, as well as the technical and cross-team dependencies associated with each. The process of identifying the individual chunks of work and how they relied on one another started to reveal possible phases for the project and resolved some of the ambiguity around the core blockers. This, in turn, created clarity around what problems were absolutely crucial to figure out first, and which ones actually didn’t matter until much later.
Once I had that clarity, it became to feel like a bunch of smaller projects that were serving one single vision. Even though we wouldn’t achieve that vision immediately, each of those projects was incrementally and iteratively working towards that end goal.
More like this
Identify the simplest solution first
Once you have broken down your project into smaller assignments, it’s time to start thinking about how to execute on them so that you and your team can move forward. My advice here is not to let perfection become the enemy of the good.
When I first began exploring my problem space, I became very fixated on trying to find the most perfect solution, one without any downsides, which became debilitating.
However, the reality is that when you’re so early in the planning process, your goal should be to start somewhere, solicit feedback, develop a robust mental model, and then continue to refine that solution multiple times. It’s okay if your initial solution is mediocre – it’s a starting point. By soliciting feedback and building relationships with others, you will arrive at a better solution. Or, you may find that the solution that you thought was mediocre may actually be worth the tradeoffs compared to other ideas.
Your goal should be to start somewhere and then build upward, leaning on the expertise and insights of others to help you, or even redirect you towards a completely different strategy.
Socialize your plan
Once you’ve identified an execution path, it’s time to start socializing your plan. Technical stakeholders are an easy place to start; if you are leveraging tools that another team built or making changes to a domain that a specific team owns, those technical counterparts will be the most interested in the changes you are proposing, and will be the most impacted by your work.
When I did this with my own project, I noticed that people began directing me to other teams who could either help answer questions, were working on similar projects, or had cross-project dependencies that I wasn’t even aware of. It’s okay if you don’t know who to share your plans with initially; the more feedback you get, the more likely you are to encounter other stakeholders with vested interests in your project. Even when your technical plan isn’t quite solidified or super detailed, sharing it is crucial to kickstarting your project.
London • June 16 & 17, 2025
Speakers Gergely Orosz, Camille Fournier and Lara Hogan confirmed.
Final thoughts
Kickstarting the planning of a project with no clear answer is an interesting challenge. While my project is still in its early stages and will be a multi-year endeavor, the groundwork I laid in the initial planning process is still paying dividends, and the project is in a much better position for it.
Regardless of whether you’re deep in the planning process or just about to get started, if you can manage to internalize your project vision, break down that vision into manageable milestones, and find allies in your organization who can help you find refine the solutions to achieving those milestones, you’ll be well on your way to executing on your big ideas.
