Organisation and operating model
An organisation chart says who reports to whom. An operating model also says who owns what, how leaders work together, and when each kind of decision gets made. This lesson shows you how to design both for about 120 engineers at Mangrove Market, how to hire the executives who run it, and how to change the structure without breaking trust.
By the end you can
- Draw a structure for about 120 engineers from the business streams, with platform and enabling teams where they earn their place
- Work out the managers and layers a given headcount needs at a given span of control, and remove the layers you don't need
- Write a charter for your leadership team, and place staff and principal engineers in the structure
- Set an operating cadence of annual plan, quarterly planning, monthly business reviews and a weekly operations review
- Hire an executive with a scorecard, structured interviews and real references, and reorganise with care
The everyday picture
A school of 1,200 pupils runs on two things. One is the structure: classes of about 30, a teacher for each, heads of department who look after ten teachers, a deputy head for each year group, and a few specialists (a librarian, a careers adviser) who serve every class. The other is the timetable: lessons every day, a staff meeting every week, a progress review every term, and a school plan once a year that sets the budget and the priorities.
A school with a good structure and no timetable has teachers who never meet and problems nobody hears about until the exam results. A school with a full timetable and a bad structure has one head of department looking after 25 teachers, who sees each of them twice a year. The head teacher's job is to design both, and to change them carefully, because every change moves a child's teacher, a timetable and a friendship group at the same time.
A structure for about 120 engineers
In Team design and delivery health you met Conway's law and the team types from Team Topologies. At department level you use the same ideas to draw the whole department, and the order in which you draw it matters. Start from the business, then the teams, then the managers. If you start from the managers ("Ken needs a bigger area"), the structure follows people instead of the work.
- List the business streams. Take the strategy themes from Technology strategy and the flows of work they need: running the stores and opening new ones, the partner business, customers ordering in the Mangrove app, delivery by riders.
- Draw stream-aligned teams around each stream. Teams of about five to nine people, each owning a part of the flow end to end. Most teams, often about three quarters of them, should be this type.
- Add platform teams only for what many teams need the same way. CI/CD and developer tooling, cloud and reliability, and core services such as login and the product catalogue. A platform team that serves one team is a stream-aligned team with a confusing name.
- Add enabling teams for skills you are short of. For example, a small test-automation team that spends a quarter with each team. Give it an end date or a rotation.
- Group teams into areas, each led by a director. Group by business stream, so that a director owns an outcome the executive team cares about, such as "partner orders placed in the app".
Now the managers. The span of control for an engineering manager is usually about 5 to 8 engineers. Below 5, the manager has too little management work and drifts into being the team's most senior engineer, and you pay for an extra layer. Above 8, 1:1s get shorter and rarer, and the manager stops knowing each person's work. Directors can usually lead about 4 to 7 managers, because managers of managers need less day-to-day help but more time on cross-team problems.
The span sets the number of layers. Divide the engineers by the span to get the number of managers, round up, then divide the managers by the span to get the directors, and so on, until one person is left. With about 120 engineers and a span of 7: 120 ÷ 7 gives 18 managers, 18 ÷ 7 gives 3 directors, and 3 ÷ 7 gives 1 CTO. That is three layers of management above the engineers, and nothing at Mangrove's size needs a fourth. A "senior director" or "group head" layer between the directors and you would add a step to every decision and a meeting to every week, for no gain in span.
The arithmetic gives the minimum. The business shape usually adds a little. Mangrove ends up with five engineering directors instead of three, because five business streams each need one accountable leader, and each director then has three or four managers. That is a fair trade: smaller spans at the top, in return for clear ownership of each stream. What you avoid is the opposite, layers added to give people titles.
Quick check
A director proposes adding a "senior engineering manager" layer between her four managers and herself, so that two of them can be promoted. Each manager leads about seven engineers. What does the span method say?
The span method adds a layer only when a leader has too many direct reports; a director with four managers is well within the 4 to 7 range. A layer created for titles slows every decision through it. Career growth is a real need, which you meet with bigger scope or a technical track. Removing the director would give you an unworkable span of direct reports.