Technology that can adapt to the ever-changing needs of ESco. Technology = people, processes and tools
Programme context

Process Changes at ESco

How working practices, delivery processes, and ways of operating changed through the programme.

Alongside our technical evolution, we have modernised how we plan, prioritise, and execute work. We have introduced two significant process frameworks to keep our teams aligned, reduce bottlenecks, and ensure we are building the right things at the right time.

1. Our EOS Journey (The Strategy Framework)

To improve long-term vision and accountability, ESco adopted the foundational elements of the EOS (Entrepreneurial Operating System) framework. Rather than a rigid, dogmatic implementation, our approach has been an honest, evolving journey of structuring our leadership, our teams, and our milestones.

Key Pillars of Our Adoption

  • The Vision Component & The V/TO: We leverage a version of the Vision/Traction Organiser framework to map out our future, detailing our long-term 10-year targets, 3-year strategic pictures, and active 1-year numbers.
  • The People Component: We initially utilized this to restructure our Senior Leadership Team. Following this blueprint, we also restructured our technology division in October 2025, transitioning them from developers who were handed ad-hoc tasks into a collaborative Solutions Team focused on configuring scalable systems.
  • The Traction Component (Rocks & Quarterly Planning): Every three months, the team meets to look ahead and establish company Rocks (our highest-priority goals for the upcoming quarter).

Where We Stand: An Honest Assessment

EOS has successfully provided ESco with a clear frame and structure to channel our priorities directly into our technology roadmap and delivery pipeline. However, maintaining the framework alongside the intense day-to-day pressures of the business is incredibly hard work, and full, active adoption across the Senior Leadership Team remains a core aspiration rather than a finished project.

⚠️ The Current Bottlenecks & Future Goals:

  • Accountability: While we regularly set quarterly Rocks, we still have a way to go in consistently holding ourselves accountable to completing them.
  • The Missing Link: Crucially, the Process component of the EOS model was never completed. Documenting core processes is a fundamental requirement for the "Detangle" phase of our business strategy. Without standardizing these workflows, unlocking true AI automation, building efficient system integrations, and executing workflow improvements will remain a bottleneck.

Re-engaging the leadership team with these processes and building a consistent habit around them remains a vital goal for ESco's operational maturity.

2. The Delivery Process (The Execution Framework)

The Delivery Process, and the creation of the Delivery Board, was introduced to solve a fundamental problem: prioritisation in isolation.

Before this framework, projects were often kicked off by different teams without cross-company alignment, leaving everyone guessing what the true priority was. The goal of the board and our shared delivery sessions was to bring absolute alignment and transparency to ESco, ensuring we were collectively working on the right things.

The Evolution & Current Reality

While the process initially brought rapid alignment, over time our overall capacity to deliver on everything began to drop. This led to some disengagement with the routine meetings. However, the Delivery Board itself remains an essential structural framework. It serves as a vital shield for our technology resources, ensuring that a project goes through proper Discovery and Definition before any code is touched.

By forcing upfront clarity on requirements and acceptance criteria, we ensure our Solutions Team's time is never wasted on half-baked ideas.

🔍 Note on Testing: While we attempted to embed a highly structured, rigorous technical testing process into this workflow, it proved difficult to execute seamlessly and didn't work brilliantly across the board, though it remains an area we adapt on a case-by-case basis.

How Work Moves: The Workflow Stages

Review

New projects stay in this stage until they're reviewed and prioritised during weekly Delivery meetings.

If a project isn't suitable for the Delivery Board, the owner is notified and it's redirected. Approved and prioritised projects move to the Backlog and typically go through Discovery before work begins.

Backlog

Projects in this stage are approved but not yet started. They're reviewed during Quarterly Planning to determine next steps and require senior sign-off.

Key questions:

  • Is it aligned with our strategy?
  • Do we have capacity?
  • Have we done this before, and does it need Discovery, or can we move it straight to Define?

Discovery

The project becomes active and initial research begins, focusing on client needs. This includes:

  • Understanding client expectations and relevance
  • Ensuring alignment with Strategy and quarterly Rocks
  • Assessing available technology and resources

Define

This stage defines the technical scope, ensuring the project is feasible. It includes:

  • Documenting technical requirements and risks
  • Estimating costs
  • Securing client sign-off
  • Validating technical feasibility

Resolved

The project is fully completed and closed. Any related jobs can now be archived and Lessons Learned meetings to be scheduled where required.

Happy staff, happy clients, healthy profits!

Testing

The work is finished but undergoing final checks and being tested for anything unexpected.

Development (Scheduled In)

The Delivery phase marks the culmination of the project workflow (the work is actively being done). This stage encompasses:

  • Implementing the project as per the defined specifications.
  • Completing the project and delivering the final outcome.

Ready for Development

This phase marks the end of all the upfront analysis and means the work is waiting to be scheduled in for development.

What the Delivery Board Is (and Is Not)

  • IT IS: A single high-level view of large change projects, feature requests, and system integrations to maintain company-wide visibility.
  • IT IS NOT: A day-to-day capacity planning tool or a playground for routine BAU (Business As Usual) tasks.
  • The BAU Rule: Minor client updates, server maintenance, and small tweaks are logged for visibility but are strictly excluded from core delivery discussions to avoid dragging the focus into the weeds.