#39 On driving initiatives
The ability to drive new initiatives is a highly valued skill for engineering. Developing it requires time and patience, so engineers need to start leading initiatives with gradually increasing difficulty. Starting a first-time initiative with high impact can potentially damage your social capital with your peers and leadership. So in this post I’ll share a playbook for how to lead initiatives, starting with the mental model around the initiative lifecycle, and advice for getting started.
First, a quick word from Scalekit who is kindly sponsoring this email..
Scalekit
In less than 12 months, the Model Context Protocol has evolved from a novel experiment to a core part of organisational tooling stacks. Enterprises are now running MCP in production — not just as a proof of concept, but as a workflow infrastructure spanning both customer-facing and internal operations. Here’s a detailed look at how that adoption is playing out:
Intro
An initiative at its core is an opportunity to make something better collectively.
It could be a technical challenge like leading an application redesign, infrastructure migration, or new in-house tooling.
It could be a non-technical challenge like people management, handling customer support, improving cross-team communication, or starting a new product discovery.
A strong engineering team is one that recognises that projects and initiatives can come from either leadership (top-down) or engineers themselves (bottom-up).
Not only does leading initiatives demonstrate ownership, it also shows that engineers genuinely care about (1) the product, (2) the business, and (3) their tools. Focusing on tools alone can be a trap.
For leading initiatives successfully, there are five phases you should be aware of.
Initiative Lifecycle
(1) Identify a problem
Every initiative comes with a cost: engineering, time, and money. To justify the spending, there should be a clear problem statement you can communicate to others on what exactly you’re trying to solve.
The problem could be developer tooling, an architecture bottleneck, a cost savings problem, routing customer requests, etc.
A tangible problem that you can experience yourself will make it easier to understand the crux of the problem and the benefit of solving the problem. From there you can brainstorm possible solutions that you can propose before an initiative kick-off.
(2) Propose solution to a small group
Once you have the problem documented, it’s good to start the conversation with a viable solution that reviewers should consider.
Going into a meeting with a problem and a fix is better than nothing:
❌ Here’s a problem
✅ Here’s a problem and a candidate solution
This could be a 1-1 or a small meeting with close stakeholders like tech leads, managers, directors, or VPs.
The goal is to highlight a problem that impacts a valuable metric (customer success or developer experience) and propose a well-thought-out solution as a starting point. It could pivot to another solution, that’s fine. The goal is to not mandate a solution but to eliminate the problem with the best solution.
Depending on the scope and/or your organisation, you might need an additional “hop” to get buy-in for the initiative. If it requires support or involvement from a wider group (e.g., engineering org, backend guild, or platform team), it is important to go through that first before starting the initiative. You don’t want people to shoot down your solution mid-execution.
That’s where the flow is highlighted in the diagram: 1 → 2.a → 2.b → 3 → 4 → 5
(3) Define Strategy
Richard Rumelt defined a good strategy by its “kernel” in his book Good Strategy Bad Strategy. The kernel of a strategy contains three elements:
Diagnosis (the why)
Guiding policy (the what)
Coherent actions (the how)
He explained the “good strategy” neatly with a medical analogy:
Diagnosis: name the disease or pathology
Guiding policy: therapeutic approach decided by the doctor
Coherent actions: prescriptions for diet, therapy and medication
The same applies to driving initiatives. Write the diagnosis as a problem statement in a document (i.e., why this initiative exists), followed by the guiding policy (what we aim to achieve), and then a set of actions/tasks to be carried out throughout the initiative.
My favourite quote from his book summarises what makes an initiative successful:
A good strategy doesn’t just draw on existing strength; it creates strength through the coherence of its design.
(4) Execute
At this stage, it is clear what we’re doing, why we’re doing it, and roughly when we should finish. The focus here is on leveraging engineering skills for execution.
Every engineer involved should be focused on execution. You as the initiative leader, should be able to provide support when needed. If there is a repeatable pattern or knowledge to share, it’s more efficient to write it in a shareable document rather than re-explaining the method to every individual.
During execution, your participants should not be distracted as much as possible. You have the duty to protect their deep focus time (if possible) and make sure everyone is in-sync. This could be translated into daily, weekly, or bi-weekly catchups. It depends on the scope of the initiative.
The key thing here is efficiency. If setbacks happen, mitigate the risks, and discuss what happened after you finish execution.
(5) Retro and Celebrate
Once the work is done, take this opportunity to retrospect with your engineers and discuss the following:
What went well? What we should keep doing in future initiatives
What didn’t go well? What were the hiccups and why did it happen
What we learned? What lessons can we take away and apply next time
Retros help capitalise the value from a long-running initiative (days, weeks, or months) and allow engineers to share insights they might not have had time to share. This is an important meeting because it reinforces collaboration and inclusion. As a general rule, anyone who pitched in should have the opportunity to speak openly.
Celebrate and recognise the efforts of everyone involved. They will appreciate investing time and effort in your initiative. Even better, they might be inspired to start their own initiatives and introduce innovative solutions. This is an example of being a force multiplier.
Wrap up
Driving initiatives is an important skill for an engineer. It requires time, practice, and patience. I encourage all engineers to practice as early and as often as they can. It is a great return-on-investment later in their careers.
To wrap up, here are final tips on leading a successful initiative:
1. Explain the crux of the problem
Explain briefly why people should care about this problem. What’s the value of solving the problem? If you can present some quantitative metrics and highlight how “painful” the problem is, the more likely the team will buy into your initiative.
2. Don’t mandate a solution upfront
The goal is not to enforce a specific answer. It is to introduce the problem statement, why it is important to solve, and a candidate solution to discuss. This changes the narrative from (raise a problem with no solution) to (here’s a problem and a solution, what are your thoughts?).
The solution with the most “votes” is likely the one that the team is happy to support.
3. Document and ask for feedback
One sign of a strong engineering culture is where teams follow a document-driven approach for exchanging ideas. When discussing requirements or proposals, it’s best to articulate your thoughts and present your research in writing. This will allow reviewers to not miss any critical detail and be able to challenge any assumptions.
4. Choose the right timing
If the team’s bandwidth is already used for other projects and the initiative isn’t time-critical, it’d be better to park it for now and resurface when the time is right. People should trust your judgement on when a problem is worth solving.
If you enjoyed reading this newsletter, consider subscribing and sharing with a friend.