What I Got Wrong Building a Delivery System from Scratch

LYTT was a bp spinout building IoT monitoring infrastructure for energy customers. When I joined alongside the incoming CTO, almost everything still needed building - team, culture, process. The first PoC had shipped, but there were no practices to speak of.

The pressure was simple: take the product from PoC to production. What I remember most clearly from that period is work getting built and then rebuilt. The feature spec would land, people would move, and somewhere in the middle the picture in the designer's head and the picture in the engineer's head would turn out to be different ones. So things got revisited, reworked, sometimes started again. No single moment where everything broke down, just constant low-grade friction that quietly ate time and made progress feel harder than it should have been.

The obvious response to a team struggling to deliver is to add structure. Stand-ups, sprints, a Jira board with the right columns. I've seen that instinct play out enough times to know how it usually goes, the ceremonies arrive, the team gets busier, and the rework continues. At LYTT the rework was a communication problem. People were building without a shared picture of what they were building toward. Adding ceremonies to that environment would have just made the confusion more organised.

The first thing I did wasn't process

Before touching any ceremony or tooling, I needed to understand where the chaos was actually coming from.

Early on it was internal. We had the right functions in the room, product, design, engineering, but no shared language for how work moved between them. Nobody had drawn it out, and everyone had a slightly different mental model of where their responsibility ended and someone else's began.

But the deeper problem surfaced through a conversation with our PM. We were going through what we were building and why, and the "why" kept stopping at "because that's what they want." It felt thin even as we were saying it. When we got to design it became harder to ignore, because we realised we had little real understanding of what the customer actually needed underneath the request. We were building to a list, and nobody had really said that out loud yet.

That conversation changed what I focused on. The PM and I started talking more seriously about roadmaps and sequencing, about what we were actually committing to and on what basis. We made the case to the CTO for a UX researcher and got buy-in. We brought customers in for user interviews, which shifted the conversation from "here's what they asked for" to "here's what they're trying to do."

And It wasn't straightforward either. The person signing off on the customer side pushed back, and it took several lengthy conversations to get anywhere. His instinct was that he knew what he wanted, and he wasn't wrong, but what he wanted and what his users needed weren't always the same thing, and what he wanted didn't always point clearly at the outcome he was trying to achieve. We had to show that in results before he trusted it. We compromised, kept some deliverables more open, absorbed some harder "make this specific thing" requests, and gradually got him to participate in user research sessions rather than just receive the outputs. Over time the work got more defined, future deliverables became more open-ended, and the customer relationship grew stronger.

It didn't fully resolve the upstream problem, but it moved it enough that we could work with better information than a customer request list.

You can optimise how work moves through your team and still be moving the wrong work, just more efficiently.

Building the first version

About six months in, we ran our first retrospective as a full cross-functional team, five people around a laptop in the office, screen-sharing a Miro board. Four engineers, one PM, one designer. There was appetite for something better, and I'd been fostering an open culture from the start, so the room was honest.

What came out of it was a diagram. A simple left-to-right flow showing how work moved from idea to shipped, with swimlanes across the top marking where each function was involved. You could see at a glance where ownership overlapped and where it didn't. Each step had a box, arrows moved work forward, and where a cycle was needed, a review or a rework, the arrow looped back. The point wasn't to be comprehensive, it was to give everyone a shared language. Before the diagram, disagreements about process were really disagreements about assumptions, people were arguing from different mental models without knowing it. The diagram made those models visible and discussable.

I kept it deliberately thin inside the engineering stages, just high level like "developing" and "testing." No detailed ticket workflows, no estimation, nothing that looked like reporting upward. The focus was on handover and collaboration between functions, not on how work was tracked within them. Adding that detail would have shifted attention inward, onto engineering's process, and away from the thing that was actually breaking, which was how work moved between us.

The moment I knew it was working was more subtle than I expected. In the discovery phase I'd included placeholders for things like problem framing and UX research, what I assumed was standard practice. The designers started pointing at those stages and saying they'd skip straight to designing, that requirements gathering wasn't really part of their process. It wasn't a confrontation, it was a realisation. What felt obvious to me wasn't common knowledge across the team. The diagram gave that gap somewhere to land, and that's when I understood what it was actually for, surfacing the assumptions we didn't know we were making.

Design became noticeably faster. The lag between design, product, and engineering that had been quietly eating time started to close. Context going into the work was higher. The team was able to grow, more designers, another product person, engineers, eventually a QA hire, without the handover problems that had plagued the early months coming back.

What broke and why

Two things broke, and they broke for the same underlying reason.

The first was the diagram. As the team grew and product and design became more sophisticated, we tried to make the process more visible to reflect that. We went through a few attempts, one more detailed version that the person chairing the session pushed back on as too complex, then a simpler one that swung too far the other way. What we ended up with was something close to a generic UXD diagram with extra loops added in. People stopped referring to it in meetings, and when they did it was clear they couldn't quite find themselves in it anymore. The thing that made the original work, that each person could point to their part, was gone. We'd optimised for completeness and made it harder to navigate instead.

The second broke more slowly. We'd grown the team and introduced collaborative UX practices that were genuinely new for most of the engineers, which meant someone had to teach them. That part was fine. What didn't happen was the handover. The people introducing the practices stayed in the facilitator role, sitting above the work rather than in it, which meant the team never got to a point where they could run it themselves. The dependency stayed. Over time engineers started looking to me to understand who to collaborate with next. In ceremonies I'd ask a question and get silence, or a one word answer from whoever felt obliged to respond. The process was still running. It just wasn't doing anything anymore.

Both broke for the same reason. A process people can't navigate doesn't get followed, it gets tolerated.

How it evolved

The system that worked wasn't the one I designed upfront, it was the one we kept adjusting.

Retrospectives were the mechanism. Writing the process down meant we could actually discuss it rather than argue about what we each thought it was. Each change was a response to something real, a specific friction, a handover that kept breaking, a stage nobody understood. We didn't add process speculatively, we added it when the pain was obvious enough that the team wanted it.

The harder fix was ownership. When ceremonies had become something people sat through rather than contributed to, running better retrospectives wasn't enough. So we tried stepping back deliberately, myself and the facilitator sitting out of meetings to let the team self-govern. We needed to know if the team could run it without us.

What happened next told me more than any retrospective could. A junior developer, unprompted, stepped up to facilitate. Halfway through he stopped the room and pointed out that we were dot voting on ideas we hadn't properly grouped yet, which was exactly right, and something more senior people had been letting slide for weeks. That was ownership. He'd understood the process well enough to improve it in the moment.

The other signal came from a senior engineer who pulled me aside and told me directly he was lost. Not in the meeting, in the process itself. He didn't know where his part began anymore. That one landed harder, because if someone with his experience couldn't navigate it, the process had drifted too far from the people inside it. I sat down with him one to one and walked through it together. But what it told me was bigger than just one person being lost, if someone at his experience couldn't find himself in the process, the process had drifted too far. I simplified his part, but the real fix was stepping back and asking whether the whole thing was still legible at the individual level.

Ownership can't be forced. You create the conditions for it, respond to what you find, and accept that the process will keep changing because the team keeps changing. That's not a problem to solve, it's just the nature of the thing.

What I'd do on day 1 somewhere new

If I walked into a company tomorrow and had to build this from scratch, the first thing I'd do is nothing. No ceremonies, no tooling, no diagram. I'd spend the first few weeks understanding where the chaos was actually coming from, because that changes everything you do next.

If it's internal, unclear handovers, misaligned expectations between functions, I'd get the cross-functional team in a room and draw something together. The form it takes matters less than the act of drawing it, because the conversation it forces is the point. You're surfacing the assumptions people didn't know they were making.

If it's upstream, no product direction, too many priorities, PMs operating as silos, I'm getting those people in a room before touching any process. At LYTT that meant getting the PMs to align on priorities together rather than each pulling engineering in a different direction.

Both problems share the same shape. When the org doesn't know what it's building toward, the team is lost. When the process drifts too far from the people inside it, the individual is lost. A delivery system can't fix either on its own, but it's the thing that makes both visible early enough to do something about it.

Then I'd introduce one thing at a time, only when the pain is real enough that the team wants it. Not just ceremonies, but stages too. At LYTT we added a problem framing meeting before design started. Work kept arriving without enough shared understanding of what problem we were actually solving, the brief would be thin, the assumptions untested, and design would start filling in gaps that should have been resolved earlier. We added it because the pain was obvious, not because we'd planned for it.

What I'd resist is importing an entire process from a previous company. What worked at a team of twenty will bloat a team of six, and it's unlikely the team will own something if they had no hand in building it.

The honest caveat is that none of this fixes a direction problem. If the org is still trying to do everything at once, a good delivery system won't stabilise things, it'll just make the dysfunction visible faster. Sometimes that's useful. Sometimes it just amplifies the pressure landing on your team. You manage that tension. You don't eliminate it.

A delivery system is a communication tool first and a process tool second. The ceremonies, the diagram, the retrospectives — they only work if the team has a shared language underneath them. Building that is the actual job