Over Six Years at Freddie's Flowers: What I Built, What I Learned and Why I Stayed

Leaving a company you have given over six years to is strange. On paper it is a handover document, a few farewell messages and returning a laptop. In practice it is closing a chapter that shaped how I think about engineering, leadership and business more than anything else in my career.

This post is not a victory lap. It is an honest account of what I set out to do at Freddie's Flowers, what I think we achieved, what was hard, and why I stayed longer than I originally planned. I am writing it partly for myself, and partly because I wish more CTOs wrote these things down when they leave, instead of only when they arrive.

Where It Started

I joined Freddie's Flowers in 2020, in the middle of the pandemic, as my four years at TouchNote were ending with me as Head of Technology. I had just led one engineering team through the overnight shift to remote, and now I was joining a new business remotely. Consumer businesses were operating in a different world, and nobody knew how long it would last.

The technology I inherited had served the business well to get where it was, but it was creaking. The platform was a monolith built around a single product: one subscription, one kind of box, one way of buying. That simplicity had been a strength in the early years. By the time I arrived it had become a ceiling. Every new commercial idea ran into the same wall: the system assumed there was only one thing to sell.

The harder problem was not technical, though. It was the relationship between engineering and the rest of the business.

Engineering vs Everyone Else

When I joined, there was a clear "engineering versus the business" mindset, on both sides. The business saw engineering as slow and expensive. Engineering saw the business as a source of changing priorities and unrealistic deadlines. Neither view was entirely wrong, and neither was helping.

I have seen this pattern in other companies, and I have come to believe it is the single most expensive problem a technology team can have. It is more expensive than technical debt, because it makes technical debt impossible to discuss honestly.

So the first thing I worked on was not code. It was trust. In practice that meant:

• Being predictable before being fast. Saying what we would deliver, and then delivering it, mattered more in the first year than delivering more.
• Explaining trade-offs in business language. Not "we need to refactor the subscription service", but "this change makes every future pricing experiment cheaper, and here is what we defer to do it".
• Being in the room. Sitting with operations, customer service, marketing and finance, understanding their pain directly instead of through tickets.
• Owning the bad news. When something broke, engineering said so first, explained it plainly and fixed it. Credibility is built far more in incidents than in launches.

The goal I kept repeating was simple: one business, one team, one set of goals. Not engineering's roadmap and the business's roadmap, but one plan we all owned. It took longer than I expected, and it was never "finished", but it changed how decisions were made. By the end, conversations started with "what is the problem we are solving for the business?" rather than "who is to blame for the delay?".

Building the Team

Establishing the engineering team was the achievement I am proudest of, and the one that is hardest to show in a screenshot.

Building a team is not hiring. It is creating the conditions in which good people do their best work and want to stay: clear ownership, sensible processes, honest feedback, room to learn and a leader who protects them from chaos rather than passing it down.

Later, we established an offshore engineering team alongside the UK team. I have written about the mechanics in One Team, Two Countries, but the emotional truth is simpler: it only works when nobody is "the offshore team". The same standards, the same context, the same respect, the same career paths. Every time we slipped from that, it showed in the work within weeks.

I made hiring mistakes. Everyone does. The ones I regret most are the times I waited too long to address a problem because I hoped it would resolve itself. It almost never does, and the cost lands on the rest of the team, not on the manager who delayed.

From One Box to a Real Commerce Platform

The defining technical programme of my time there was moving from a creaking, single-SKU monolith to a fully flexible platform that supported multiple products, multiple subscription types and one-off e-commerce purchases.

That sounds like a feature. It was not. It touched almost everything: the product catalogue, pricing, the subscription lifecycle, checkout, payments, delivery scheduling, fulfilment and reporting. A single assumption ("a customer has one subscription to one product") was buried in hundreds of places.

We did it incrementally, using a strangler fig approach rather than a big-bang rewrite, and moved the stack from PHP to TypeScript along the way. The details are in Platform Replatforming at Freddie's Flowers and PHP to TypeScript. What those posts say less about is how it felt:

• It was long. Replatforming programmes always take longer than the plan, and the business has to keep trading the whole time. Valentine's Day and Mother's Day do not move for your migration.
• It was invisible when it went well. The best migration weeks were the ones where nobody outside engineering noticed anything at all.
• It required patience from the business. Some quarters, the most valuable thing engineering delivered was not a feature but the removal of a constraint. Defending that work was a constant part of the job.

When the flexible platform landed, the conversations changed. Instead of "the system can't do that", the question became "should we do that?". That shift, from technology deciding what the business could try to the business deciding what it wanted to try, is the whole point of a replatforming.

The Unglamorous Work: Operations and Internal Tools

Some of the work I am most quietly satisfied with will never appear in a case study: the internal tools and processes we built for operations and customer service.

Manual, repetitive processes in a subscription business are everywhere: adjusting deliveries, handling failed payments, managing exceptions with fulfilment partners, reconciling data across systems. Each one looks small. Together they consume a surprising amount of a team's week, and they are where errors creep in.

We built tooling and processes to take that load off people: better internal admin tools, automation for routine operational tasks, clearer workflows between teams, and better visibility of what was happening in the business. None of this is exciting engineering. All of it made people's working days better, and that matters.

It also helped with the trust problem. Nothing builds goodwill with an operations team like making their hardest Monday morning disappear.

The Cost Centre Problem

If there is one challenge I would warn every new CTO about, it is this: in many businesses, technology is seen as a cost centre.

On the profit and loss account, engineering is salaries, cloud bills and software licences. Revenue shows up under marketing, sales and product. So every budget conversation starts with technology on the defensive, explaining why it costs what it costs, rather than what it makes possible.

I never fully solved this, and I am not sure anyone does. What helped was:

• Tying work to business outcomes, not output. Not "we shipped twelve features", but "checkout is faster, failed payments recover more often, and operations spends less time on manual fixes".
• Being cost-conscious without being asked. Taking ownership of cloud and tooling spend, and cutting waste before finance found it, earned the right to argue for investment elsewhere. I wrote about where the money actually goes in AWS Cost Optimisation for a Mid-Size Business.
• Making the cost of not investing visible. Technical debt is invisible until it causes an outage or blocks a launch. Naming that risk early, in plain language, is part of the job.

Even so, there were periods when engineering was asked to do more with less, and conversations that were genuinely hard. That is the reality of running technology in a consumer business with real margins and real pressure, especially through the economic swings of the last few years. I do not resent it. But I would tell any engineer who wants to become a CTO: a big part of the role is making the case, again and again, that technology is how the business makes money, not just where it spends it.

A Short Time on the Board

For a short period I also served as a board member. It was one of the most educational experiences of my career.

Seeing the business from the board's perspective changes how you think about technology. Every decision competes with every other use of capital. Risk is discussed in terms of the whole company, not one system. And the questions are different: not "is this the right architecture?" but "what does this mean for the business in two years, and what happens if we are wrong?".

It made me a better CTO. I became more concise, more focused on outcomes and more comfortable saying "we should not do this" when the numbers did not support it. I would encourage any technology leader who gets the opportunity to take it.

Why I Stayed Longer Than I Planned

Here is the part I have not said publicly before. I first thought seriously about leaving about two years ago.

There was no single reason. By then I had been in the role for four years, which is a long time in technology, and I could feel that I wanted new problems. But leaving at that point would have left the team and the platform in a fragile place. The replatforming had changed so much that a lot of context lived in a few heads, mine included.

So I stayed. Not out of obligation, but because I believe a leader's last job is to leave things in a state where they do not need you. That meant finding the right replacement, making sure the team was stable, writing down the decisions and context that had only ever been spoken, and choosing a moment where a change of leadership would not disrupt the business.

Those last two years were some of the most valuable I spent there. Planning a handover properly forces you to see which parts of the organisation depend on you personally, and to fix them. If I could give one piece of advice to anyone planning to leave a senior role, it would be this: start making yourself unnecessary long before you announce it.

What I'm Proud Of, and What I'd Do Differently

What I am proudest of:

• A team that works as one team, across two countries, and that trusts the business it works for.
• A platform that lets the business sell what it wants, how it wants, instead of what the old system allowed.
• Operational tools and processes that gave people back time every week.
• Helping to bring the Pennies micro-donation integration to life, which meant something to me personally.
• Leaving at a time, and in a way, that did not leave anyone in a difficult position.

What I would do differently:

• Address people problems faster. Kindness is not the same as delay.
• Write things down earlier. Many decisions only got documented during the handover. They should have been written down when they were made.
• Push harder, earlier, on the cost-centre narrative. I got better at framing technology as an investment over time. I wish I had started on day one.

Thank You

To the engineers in the UK and offshore, who trusted me, challenged me and built things I could never have built alone: thank you. To colleagues across operations, customer service, marketing, finance and leadership, who met engineering halfway and sometimes further: thank you. And to the customers who never knew any of this was happening behind the flowers on their doorstep, which is exactly how it should be.

What's Next

I am now working as a consultant through Krigo Ltd, currently with an investment and fintech platform. It is a very different world from flowers: regulated, high-trust and built around people's money, and a good reminder of how much there is still to learn. Alongside that, I help companies with the kinds of problems I have spent most of the last decade on as the senior technology leader on a leadership team, first at TouchNote and then at Freddie's Flowers: architecture and replatforming decisions, AI-assisted engineering, building teams that trust the business, and making the case for technology as an investment rather than a cost. If any of that sounds familiar, I'd be glad to talk.

The Takeaway

The technology was the easier part. Moving from a single-product monolith to a flexible commerce platform was hard engineering, but it was a solvable problem. The harder, more important work was building a team, earning the trust of the business and turning "engineering versus everyone else" into one company with one set of goals. If I had to sum up over six years in one sentence: build the trust first, because everything else, including the platform, depends on it.