Plan the work, work the plan

Maybe it’s something to do with being British. I love a good queue, and if I’m honest I’ve often found myself sympathising with the villain in most Hollywood films. Just joking, of course. But seriously, I do love a well-thought-out plan.

A former teacher once said to me: “Plan the work, work the plan”, it stuck. Over the years, I’ve seen just how valuable that mindset is, especially in software delivery.

When I step into a new area of work, the first thing I look for is a plan. For me, a plan serves as a single point of alignment for multiple people. It should have both a visual and a written component. Personally, I prefer visual, as I find it easier to take in both the big picture and the finer details at a glance.

A good plan prompts the right questions and helps surface things that might otherwise go unnoticed.

That said, I’m still regularly surprised by how many software teams lack a shared plan, or even an appreciation of just how important one is.

Most software has a customer. And most customers like to know when to expect new features. In B2B or B2E contexts, software delivery is often just one part of a broader delivery plan in the organisation. Without a shared plan, we risk becoming the bottleneck, or worse, an unpredictable dependency in someone else’s timeline.

Notice I haven’t used the word “dates”. That word alone can provoke long responses. Many of us have been shaped by agile thinking that tells us to ship when a feature is ready. And while there's truth in that, the reality is: coordination, communication, and confidence in delivery matter too.

So, why is a plan so important?

• It aligns the team on a shared understanding of goals and priorities
• It ensures we’re building the right things, not just building things right
• It connects day-to-day work with the broader product and technology vision
• It provides the scaffolding for making and managing architectural change
• It highlights dependencies and risks early
• It sets clear expectations and delivery windows (with or without hard dates)
• It provides a baseline for accountability and measurement
• It fosters confidence among stakeholders by showing a path forward
• It helps focus attention when trade-offs inevitably need to be made

What makes a good plan in software engineering?

• Clear articulation of the problem being solved
• Alignment with the long-term vision of the product and platform
• Defined scope, milestones, and deliverables
• Consideration of architectural decisions and necessary technical debt repayment
• Inclusion of key assumptions and constraints
• Visibility of risks and mitigation strategies
• Assigning ownership to key work streams
• Space for iteration and change as learning occurs
• Accessible format, ideally a mix of visual and written content

At OneTwo, we take this seriously. Our planning practices are supported by a combination of technical frameworks and accessible tools:

• We use RFCs (Request for Comments) to shape ideas, and ADRs (Architecture Decision Records) to document key decisions
• Our architecture is communicated using the C4 Model, giving teams and stakeholders a clear visual representation at multiple levels
• For tooling, we rely on Confluence for written plans, Draw.io for C4 diagrams, and Figjam for collaborative planning and workshops

These practices ensure we’re not only building software, but also evolving our architecture and working in sync with the long-term vision of the platform.

Why should business outcomes be tied to the plan?

• It ensures technical work contributes to meaningful progress
• It prevents teams from drifting into work that “feels productive” but delivers little value
• It creates a shared language between product, engineering, and business stakeholders
• It helps prioritise when resourcing or timelines need to shift
• It enables impact measurement after delivery

How often should we check back in on the plan to see how we are progressing?

• Weekly, for tactical progress updates and course corrections
• Fortnightly or monthly, to reassess timelines and scope against emerging risks
• At every major milestone, to validate if the plan still serves its purpose
• After delivery, to reflect and improve future planning practices

A plan isn’t just a Gantt chart or a list of tickets. It’s a living artefact that connects architecture, technology, and delivery with the business and customer vision. It’s not about promising dates. It’s about creating shared clarity, reducing risk, and moving forward together.

Plan the work, work the plan.

And no, I don’t actually sympathise with the villain in every Hollywood film, unless they’re the one with the plan.

What practices or tools have helped your teams build shared, adaptable plans?

#SoftwareEngineering #Architecture #Planning #TechLeadership #ProductDelivery #BusinessAlignment #DeliveryExcellence #PlatformVision #C4Model #RFC #ADR