Designing and launching a 350-person product & engineering org in three weeks
SumUp had outgrown its operating model. The product and engineering function needed structure, clear ownership, and a way to operate at unicorn scale — without the wheels coming off mid-quarter. We had three weeks before the next planning cycle.
The situation
SumUp is one of Europe's most successful fintechs — a payments business with a unicorn valuation, millions of merchants, and a product surface that touches everything from card readers in coffee shops to lending decisions in spreadsheets. Like most companies that scale fast, the operating model was lagging behind the headcount.
The product and engineering organisation in particular had grown to the point where nobody owned the boring-but-critical work — platform stability, internal tooling, the unglamorous reliability that compounds. Everything new and shiny had a team. The runway underneath those teams did not.
The approach
The temptation in a problem like this is to spend three months on the perfect org chart. We didn't have three months. We had three weeks before quarterly planning, and an organisation that needed clarity more than it needed elegance.
So I did this in three loops, each one tighter than the last:
- Week 1 — Map the actual work. Forget the org chart. What are the things this org does, every day, that don't have a clean owner? Platform health, internal developer experience, ways-of-working, performance management at scale. I sat with team leads, support eng, and a few end-of-year retrospectives. The list was longer than anyone expected.
- Week 2 — Design two structures, kill one. Wrote up two possible operating models — one centralised, one federated. Walked the CEO and CTO through both. Picked the one that matched how SumUp actually operates: federated with a strong core. Wrote the document, named the function ("Run & Grow"), and aligned the leadership team in a 90-minute working session.
- Week 3 — Stand it up live. Wrote the comms. Built the leadership slate. Set the first 90-day priorities. Held an all-hands. Function existed by Monday.
What was actually hard
The structural design is the easy bit. The hard bit is everything that comes with it: which people move, what stays in their old reporting line, how to communicate it without spooking the org, and how to make sure the new function isn't just a re-org on a slide.
Three calls in particular took most of the energy:
- Where does platform engineering live? (Federated, with a strong reporting line into Run & Grow's core.)
- How do we measure if it's working? (A small KPI tree — five top-level metrics, owned by the function head, reviewed monthly by the executive.)
- How do we keep "Grow" teams accountable for "Run" outcomes? (Tied platform health to product-team OKRs. Painful but essential.)
The result
Run & Grow went live on schedule. As of writing, it owns: platform health and reliability, internal developer experience, hiring excellence (including the AI-agent automation we're rolling out), engineering performance frameworks, and the company-wide KPI tree. The function has a permanent leadership slate and is running its own quarterly cadence.
The wider performance system — KPI tree, performance review redesign, talent acquisition revamp — has lifted hiring efficiency target from 1.3 hires per recruiter per month to 2–3, with AI agents now handling first-pass screening across the funnel.
"Three weeks felt absurd at the start. By week two it was just the deadline that made the decisions actually get made."
What I'd take to the next one
- Constraint is a design tool. Three weeks forced ruthless prioritisation. A three-month timeline would have produced a worse outcome — more committees, more debate, less delivery.
- Name it well. "Run & Grow" did more work than any slide. People immediately understood what the function was for.
- The KPI tree is the thing that lasts. The org chart will change. The shared definition of what "good" means won't, if you build it right.