Engineering Operations Maturity Model: 3 main steps in Engineering Operations maturity journey

Engineering operations is a critical function in startup software companies. They play a key role in scaling the engineering team as the company grows as they work hand in hand with the Engineering Management.

Engineering operations responsiblities varies and changes throughout the growth of the Engineering Department. When the engineering department is small (but big enough) one engineering operations is suffice, covering by themselves the end to end responsiblities. As the Engineering Department grows in size and maturity, the need for more Engineering Operations members covering wider responsibilities.

In this article, we suggest a model for the Engineering Operations team maturity evolution. The model provides 3 steps of maturity. For each of the steps, there is a short description of the Engineering aproximate size (just a thumbrule, offcourse companies vary significantly in their maturity regardless of their size) and the relevant subjects that the Engineering Operations should cover.

The pioneer: Alignment

Engineering Department size: Starting at 30–50 Developers and QA

How do we know we are in this stage: It’s starting to feel more chaos than managed, we know we’re coming toward a scale in our size and enterprise readiness. It feels like we’re starting to slow down. There’s an inconvinient feeling of internal dicomfort and mess. People feel it and usually start saying “we need processes”. Managment feels like the growth in team size doesn’t provide the expected product outcome. This is how we know it’s a good time to have Engineering Ops onbaord with us.

Engineering Operations size and structure: Starting with one Engineering Operations who sees most of the end to end processes. As the company grows 2–3 Engineering Operations / TPM will join the team.

Engineering Operations main role: Alignment of the teams on key processes and providing basic visibility to the management.

Main Topics to be addressed:

1. Main Agile ceremonies — Sprint Planning/Daily/Review, Sprint Length, sprint teams.
2. Managing bugs and production incidents— how does QA/ Support teams pass bugs to developers and back in an aligned way that allows tracking and visibility to the quality.
3. SDLC- how do epics go from an idea to installed at the customer? adding the basic ceremonies and tracking metrics.
4. Quality — inserting a more structured way to improve quality, during development and in production
5. Basic Status and tracking — the projects matrix becomes too complicated to be remembered, how do we reflect status and provide basic predictability to the senior management.

The Builder: Building the machine

Engineering Department size: Starting at 80–100 Developers and QA

How do we know we are in this stage: We’re feeling like bigger questions are starting to nag us — why did we double ourselves and get half the delivery? How can we improve our velocity signficantly? we start to feel that the processes don’t scale, some processes are still managed by slack but now happen much more and need to change the format, there’s not enough learning from the past, sense of urgency to better, faster delivery and higher standard of QA. Welcome to the building to scale phase!

Engineering Operations main role: Becoming a machine on all basic processes and starting the more advanced Engineering Operations Topics such as improving velocity, managing more efficiently the scrum of scrums etc.

Engineering Operations size and structure: Usually a big(ger) team. Sometimes a core centralized team of cross engineering view such as Jira Admin, Data Analysis / Dashboard owner and centralized or decentralized TPM that own specific projects and team’s development. All the same there’s a core and centralized function that oversees the Engineering Overview Status.

A note: this phase is very long.. It’s ends at around 300 or 400 developers and QA

Main Topics to be addressed:

1. Improving SDLC Gates and Metrics
2. Improving Quality and inserting better quality measurement and post incidents learning.
3. Improving efficiency by working on Velocity & Time to market (but not only), managing dependencies and structure to best support the business goals.
4. Improving Visiblity and predictability for managers and for stakeholders with dasbhoards and metrics and better quarter planning
5. Communication and clear alignement becomes key.

The Spreader: Keeping the core, De Centralizing the power

Engineering Department size: Starting at 300–400 Developers and QA

How do we know we are in this stage: Our engineering department is divided into small tribes / companies / sections, each working individually and autonmously. This allows the alignment to be loosened a bit and each group to work more on their own style, allowing the minimum needed alignemt for a clear cross company status.

Engineering Operations main role: At this size, the Core Engineering Operations team is transferring into a professional guild and /or overseeing mainly the cross company projects, the Engineering Operations that are spread across the different groups become Engineering Operations’s and the owners for the effectiveness of the teams. In a way, they’re more like the Engineering Operations at the builder stage — but for their group only.

Engineering Operations size and structure: At this size the Engineering Operations team and its core functionality has to be decentralized to the differnt groups and products. Thus, usually there are Engineering Operations spread across the engineering, each leading their own product/ engineering group and a core team that functions more of a Professional Guild and cross company (huge) projects.

Main Topics to be addressed:

In the core / guild Engineering Operations:

1. Communication and buy in for the big cross engineering projects that need to happen across the company.
2. Clear E2E management for cross engineering projects, such as quarter planning, progress on key projects and overall engineering status.
3. Providing the technological tools that will allow flexibility for the teams but alignment in data for the core team. Also providing the best add ons, and tools support to allow best usage on each team.
4. Being the guild — Providing the methodology, standard, culture, onboarding for the new guild members to join.
5. Knowledge Management- as the core team is the only team that sees simultanously multiple teams and manage projects that should be done in all teams, the knowledge becomes a key element that can provide better experience and efficiency and faster results for the differnt teams.

In the different groups, the engineering operations teams own the roles as described in the builder’s phase.

To summarize, our 3 step Engineering Operations Maturity Model allows us to see from the maturity and size of our engineering teams to the expected relevant model and role of the Engineering Operations teams.

Enjoyed this article? Stay updated with the latest insights by following us on our channel in Medium and visiting the Engineering Operations website.