Six developers, no process: how I built a Tech & Product department
In short
- Problem: six developers, no defined process, no product or design function. Delivery depended on who happened to be available and how well they remembered the last conversation.
- Decision: build the missing functions before adding headcount — Product Owners first, then design, then team structure under leads — and write the way of working down before scaling it.
- Result: a 25-person department across three countries, four development teams under their own leads, and a written operating model every team works to.
- Timeframe: the first eighteen months.
Context
A group operating sports and iGaming portals, four casino brands, a subscription platform and the services behind them. Real traffic, real revenue, and a codebase that had been shipped continuously for years. The engineering function was six developers.
They were good. That is worth saying, because the story people expect here is one about replacing people, and it is not that story. The problem was not the developers. The problem was that everything the department knew lived in six heads.
The problem
If you asked when something would be ready, you got an honest guess. If you asked what “ready” meant, you got six defensible answers. Requirements arrived as conversations, so what got built depended on who was in the room and what they remembered afterwards. Support work and new features competed for the same hours with no rule for who won, which meant urgency won — always.
None of this shows up as a crisis. It shows up as commercial teams gradually stopping asking for dates, because the dates were not useful. That is a much worse symptom than a missed deadline, and it is nearly invisible from the inside.
Constraints
Delivery could not pause. There was no window in which to rebuild the way of working while nothing shipped, so every change had to be introduced alongside live work that had already been promised.
The team had learned that process meant overhead. Any framework I introduced had to visibly remove work from someone in its first two weeks or it would be quietly ignored, and rightly so.
Hiring was staged over quarters, not granted upfront. And engineering would end up distributed across Athens, Cyprus and Georgia — which meant anything depending on hallway conversations was going to fail.
What I did
I wrote the lifecycle down before I changed anything else. Ten Jira statuses with explicit transition rules, and a written condition for each transition. Not because ten statuses are inherently correct, but because a shared vocabulary has to exist before you can have a useful argument about anything else. “In code review” now meant one thing.
Then Definition of Ready, which was the first thing that gave time back. A ticket cannot enter a sprint without acceptance criteria, resolved dependencies, a size, and a design if one is needed. Developers stopped receiving work they had to decode. That was the two-week payoff the team needed in order to believe the rest.
Then the Product Owner function, from scratch. This was the decision I would defend hardest. Developers were absorbing product thinking in the margins between implementation tasks, which produces exactly the results you would expect: technically sound work aimed slightly wrong. The fix was not to ask them to try harder. It was to make it someone’s job.
Then Product Design, for the same reason. And only then team structure: development teams under their own tech leads, so that decisions had a home that was not me.
Then capacity, written as a rule. Each developer’s sprint is split explicitly: most to planned work, a reserved share to support, a reserved share to technical improvement. A sprint planned at one hundred per cent features does not eliminate the support work — it hides it until it becomes an incident, and it makes technical debt permanent because it never gets a slot.
Then criticality with response times. C1 through C4, from production-down to cosmetic, each with a written response window and a written definition. This is what made “urgent” a defined word rather than a tone of voice, and it is what makes protecting the sprint boundary possible without a negotiation every Tuesday.
What did not work first time: estimation. We tried to make story points precise, argued about whether something was a three or a five, and lost time to a discussion with no answer. The fix was to agree on reference tickets — this is what a three looks like here — and a rule that when you are torn, you take the higher number and move on.
Result
Twenty-five people: four development teams under their own leads, an in-house DevOps team, IT support, QA, Product Management and Product Design. Engineering across three countries.
More importantly, the operating model is written down and teams work to it without me in the room. New joiners read a document instead of absorbing folklore for a month. And commercial teams ask for dates again, which is the outcome I actually care about.
I had no baseline for most of this — no historical velocity, no defect data, nothing to measure against. So I will not claim a percentage. The honest signal is that the questions I get from management changed: from “when will this be done” to “what should we do next”.
What I would change
I introduced ceremonies too early relative to the documentation. For a few weeks we had meetings whose purpose was clearer to me than to anyone attending, which spends credibility I needed later.
And I underestimated how long the Product Owner function would take to become real. Hiring a Product Owner creates a job title in a week. It takes considerably longer before developers stop routing product questions past that person out of habit.