Six cities. Fifty-five people. The culture work is settling. The acquisition integration is holding. And the technology that Tom and Priya built for three cities is coming apart at the seams.
Tom knows it’s bad when the Adelaide squad lead messages him at 7:14am on a Monday: “Deploy queue has five PRs in it. We’ve been waiting since Thursday. When’s our slot?”
He knows it’s really bad when the Brisbane squad lead messages him at 7:22am: “Same question. Also, three tests failed randomly on our branch. We re-ran and they passed. Nobody trusts the build any more.”
He knows it’s a crisis when Sam messages him at 7:31am: “Adelaide’s Thursday boxes went out with last week’s substitutions. Nobody noticed until a subscriber called. We had the data; it didn’t reach the delivery system. Four hours of wrong boxes.”
Tom puts down his coffee. It’s Monday morning. The kids are at school. Sarah has left for work. The house is quiet. His three monitors show: the deploy queue (five PRs, estimated time to clear: 4 hours), the test dashboard (three flaky tests, red for the third time this week), and the production monitoring (such as it is) which doesn’t cover Adelaide at all.
He opens the document he started eight months ago, in the management gap week. The one he saved in a folder called “Engineering Lead.” The note reads: Deploy pipeline: three squads, one staging, review bottleneck. Fix before it breaks something.
It broke something. Four hours of wrong boxes in Adelaide. Subscribers getting last week’s substitutions: the wrong produce for the wrong preferences. Nobody noticed because the monitoring only covers Perth, Melbourne, and Brisbane. Adelaide was added to the platform three months ago and nobody extended the alerting.
Patricia’s question from the board room echoes in Tom’s head: “If a system is healthy, the system should tell you. Not a person checking; the system itself.”
The system didn’t tell them. A subscriber did. Four hours later.
The problems compound
Tom spends Monday cataloguing the failures. Not for blame, but for understanding. The problems aren’t new. They’ve been accumulating for eighteen months, seeded in small decisions that made sense at the time and compound into crisis at scale.
The deploy queue. Greenbox has six environments, one per city, each with its own configuration for farm partners, delivery routes, courier APIs, and regional settings. A full deployment touches all six environments sequentially. Each environment takes approximately forty-five minutes: build, test, deploy, smoke test, verify. A complete release takes four and a half hours on a good day. On a bad day, when a test fails in environment three and the developer has to fix it and restart from environment three, it takes all day.
Developers wait in line. The Perth squad finished a feature on Wednesday. It’s Monday and the feature isn’t deployed because Brisbane and Sydney had priority releases on Thursday and Friday. The bottleneck isn’t writing code; it’s shipping it.
Tom recognises the pattern. It’s the Theory of Constraints, which Charlotte introduced during the Wardley Mapping work: the throughput of a system is limited by its single biggest bottleneck. In year one, the bottleneck was understanding: the team didn’t know what to build. They fixed that with Event Storming, JTBD, Example Mapping. In year two, the bottleneck was coordination: two squads building on the same codebase. They fixed that with bounded contexts and contract testing. In year three, the bottleneck has moved again. Now it’s delivery infrastructure. The constraint isn’t understanding or coordination; it’s the pipeline itself.
The flaky tests. The test suite runs for ninety minutes. At three cities, it ran for forty-five. The additional city-specific tests, integration tests, and end-to-end scenarios have doubled the runtime. Three tests fail randomly, not consistently, not predictably. One is a timing issue in the substitution engine’s async processing. One is a database connection pool exhaustion under load. One is a mystery that nobody has had time to diagnose.
The team has developed a coping mechanism: re-run and hope. If the build fails, trigger it again. If it passes on the second run, ship it. Nobody trusts the green build any more. A green build means “probably fine” rather than “definitely working.” The psychological impact is corrosive: developers stop caring about test failures because test failures have stopped meaning anything.
Priya, from Melbourne, articulates the danger in an engineering channel message: “When the test suite becomes a lottery, developers stop writing tests. When developers stop writing tests, we stop catching bugs before production. When we stop catching bugs before production, we become the company that ships wrong boxes to Adelaide for four hours.”
The monitoring gap. Greenbox’s monitoring was built for Perth. When Melbourne launched, Tom extended it to cover Melbourne. When Brisbane launched, he extended it again. Each extension was a manual process: adding dashboards, configuring alerts, setting thresholds. It worked because Tom was personally responsible and Tom paid attention.
Adelaide was added to the platform three months ago. Nobody extended the monitoring. Not because of negligence; because the process was manual and the person who knew how to do it (Tom) was occupied with the Harvest Box acquisition integration. The Sydney monitoring is a patchwork: half Harvest Box’s Heroku metrics, half Greenbox’s custom dashboards, none of it connected.
Patricia Osei’s golden signals question (latency, traffic, errors, saturation) has been answered for Perth, Melbourne, and Brisbane. For Adelaide and Sydney, the answer is “we don’t know.” For Hobart, which launches next month, the answer will also be “we don’t know” unless something changes.
Conway’s Law. The architecture mirrors the three-city organisation it was built for. The core platform has code paths for Perth, Melbourne, and Brisbane baked into the logic: if city == "perth" conditionals that Tom wrote in the early days and never refactored. Adding Adelaide meant adding a fourth conditional. Adding Sydney (via the API boundary) meant adding a fifth, different pattern. Adding Hobart will mean a sixth.
The bounded contexts from the DDD work saved the architecture from being a complete monolith. The supply matching, customer profiles, delivery logistics, and payment systems are separate services with defined interfaces. But the delivery infrastructure (the pipeline, the monitoring, the deployment process) was designed when Greenbox had three cities, two squads, and Tom personally overseeing every release. The architecture of the business logic scales. The architecture of the delivery system doesn’t.
Jess
Tom hires Greenbox’s first Site Reliability Engineer in early February. Her name is Jess Okonjo, she’s 30, and she arrives from Atlassian’s Sydney office with a systems engineering degree from UNSW and the particular calm of someone who has been on-call for production systems serving millions of users and finds a thirty-thousand-subscriber produce box company refreshingly manageable.
Jess is direct. Not Charlotte-direct: Charlotte is direct with purpose and precision. Jess is direct with data and indifference to hierarchy. She says what the numbers say, regardless of who’s in the room.
Tom interviews her on a video call. She’s sitting in her apartment in Newtown, Sydney, with a whiteboard behind her that has a half-finished system diagram and a sticky note that reads “ALL SYSTEMS FAIL.”
“Why Greenbox?” Tom asks.
“Because you’re about to break.” She says it matter-of-factly, without malice. “I read the job listing. You’re hiring your first SRE at six cities. That means your infrastructure was built for fewer cities than you have, your deploy process is manual, your monitoring has gaps, and your test suite is either too slow or too unreliable. Probably both.”
Tom is quiet for a moment. “How do you know all that?”
“Because every company that hires their first SRE at this stage has exactly those problems. The specifics vary, but the pattern doesn’t.”
Tom hires her. She starts two weeks later.
Jess spends her first week doing what Diane did when she first arrived at Greenbox: watching. She sits in on the Monday engineering standup. She reads the deploy logs. She traces the test suite failures. She maps the monitoring coverage. She talks to every squad’s lead developer. She reads the ADRs from the architecture decision records work.
On Friday afternoon, she presents her findings. Present: Tom, Priya (video), Charlotte (video), Maya (listening from the doorway because she wants to understand but doesn’t want to intimidate). The assessment is two pages. The summary is brutal.
“Your deploy pipeline is your biggest bottleneck. Your monitoring is a patchwork. Your test suite is a lottery. And your architecture assumes you’ll never have more than three cities.”
Tom doesn’t flinch. He’s been saying this for months. Hearing it from someone with fresh eyes and an Atlassian pedigree makes it real in a way that his own internal warnings didn’t.
“The good news,” Jess continues, “is that the foundation is solid. The bounded contexts are well-designed. The service interfaces are clean. The domain logic (the substitution engine, the customer matching, the farm availability system) is genuinely good. The problem isn’t the architecture; it’s the infrastructure around the architecture. You built a house with excellent rooms and no plumbing.”
Priya laughs. It’s the first time anyone has laughed in an engineering meeting in weeks.
Measuring the damage
Jess introduces a framework that Tom has heard of but never applied: DORA metrics. Four measures of software delivery performance, developed by the DevOps Research and Assessment team over a decade of industry research.
Deploy frequency. How often does the team deploy to production? Industry benchmark for high performers: on demand, multiple times per day. Greenbox: once a week, sometimes less. Each deployment is a planned event that requires coordination, a deployment slot, and Tom’s personal attention.
Lead time for changes. How long does it take from code committed to code running in production? High performers: less than one day. Greenbox: five days. A developer finishes a feature on Monday. The PR is reviewed by Wednesday. The deploy queue is reached by Thursday. The deployment completes on Friday. If the deploy queue is backed up, it slips to the following week.
Change failure rate. What percentage of deployments cause a failure in production? High performers: less than 5%. Greenbox: approximately 20%. One in five deployments causes something to break: a test environment mismatch, a configuration error, a city-specific conditional that wasn’t updated. The four hours of wrong Adelaide boxes was one such failure.
Time to restore service. When a failure occurs, how long does it take to recover? High performers: less than one hour. Greenbox: varies wildly. Perth failures are caught quickly because the monitoring is comprehensive. Adelaide failures take four hours because there’s no monitoring. Sydney failures are unpredictable because the Harvest Box integration adds complexity.
Jess puts the numbers on a whiteboard in the Perth office. She doesn’t annotate them with “good” or “bad.” She lets the numbers speak.
Tom stares at the whiteboard. He’s a developer who takes pride in his craft. These numbers say the code is good, but the system for delivering the code is broken. It’s the engineering equivalent of a chef who makes excellent food but can’t get it to the table while it’s still hot.
“These are embarrassing,” Tom says.
“They’re honest,” Jess says. “And they’re fixable. The question is: what do you want them to be in six months?”
Tom thinks about the Cerulean Ventures pitch. He told the tech partner: “Six months to get deployment automation and golden signals in place. Twelve months to full platform maturity.” That was eight months ago. He’s behind. The acquisition consumed two months. The national expansion consumed three more. The platform work kept getting deferred because there was always something more urgent.
“Deploy frequency: daily. Lead time: less than one day. Change failure rate: under 5%. Time to restore: under one hour.”
“Good,” Jess says. “Now let me tell you what that requires.”
The golden signals
Before Jess can fix the deploy pipeline, she needs to see the systems. She sets up monitoring dashboards using the golden signals framework Patricia mentioned in the board room: latency, traffic, errors, saturation. Four signals, measured for every service across every city.
The results are sobering. Adelaide and Sydney respond three times slower than Perth. Sydney’s error rate is four times the national average; the Harvest Box API boundary intermittently fails when the Heroku dyno sleeps. The message queue backs up every Thursday during peak delivery and doesn’t drain until Friday. The build server runs at 95% during deployments.
For the first time, the engineering team sees their systems properly. Not through Tom’s instinct, not through subscriber complaints, but through data that updates in real time.
Tom stands in front of the dashboards for a long time. “I’ve been running this on instinct. Personal knowledge. Mental models.”
Jess nods. “That works at three cities. It doesn’t work at eight.”
The platform team
The monitoring reveals the problems. Fixing them requires a structural change that Tom has been avoiding.
Greenbox’s engineering team is organised by city. Perth squad, Melbourne squad, Brisbane squad, and so on. Each squad builds features for its city: customer-facing improvements, farm portal updates, delivery route optimisations. This structure worked well when each city was relatively independent. But the platform (the deploy pipeline, the monitoring, the shared infrastructure, the API boundary) belongs to no squad. It belongs to Tom, personally, and to whoever he can borrow for a few days when something breaks.
Jess names the problem using language from Team Topologies, a book she gives Tom to read.
“You have stream-aligned teams,” Jess says. “Each squad is aligned to a stream of work: a city, a set of customers, a product area. That’s good. Stream-aligned teams are fast because they own their domain end to end.”
“But you have no platform team. The shared infrastructure (deploys, monitoring, CI/CD, the build server, the database, the API boundary) is nobody’s primary responsibility. It’s maintained by interrupt. Someone notices it’s broken, someone fixes it, everyone goes back to their feature work. The platform is maintained by goodwill, not by ownership.”
Tom has read about Team Topologies. Charlotte mentioned it during the Two Squads work. But at two squads, a dedicated platform team felt like overhead. At six squads, it’s a necessity.
“I need to restructure the engineering team,” Tom says.
Charlotte, on the video call, leans forward. “Tell me what you’re thinking.”
Tom draws on the whiteboard. It’s the first architectural diagram he’s drawn in months that isn’t about the product; it’s about the organisation.
Stream-aligned teams (product squads): Three squads, each responsible for a cluster of cities. Perth/Adelaide/Hobart. Melbourne/Regional Victoria. Brisbane/Sydney. Each squad owns the customer-facing features, the local delivery logic, and the farm partnerships for their cities. They ship features. They talk to customers. They run the discovery cadence.
Platform team: Jess’s team. Four people initially: Jess, one developer pulled from the Perth squad, one from Melbourne, and a new hire (infrastructure specialist). They own the deploy pipeline, the monitoring, the CI/CD system, the shared databases, the build infrastructure, and the API boundary to the Harvest Box system. They don’t build features. They build the system that lets the feature teams ship.
Charlotte sees what Tom is doing. “You’re applying Conway’s Law deliberately.”
“Yes. Right now the architecture mirrors the old three-city org, because that’s the org that built it. The deploy pipeline is manual because one person (me) did the deploys. The monitoring covers three cities because three cities was the scope. I need the architecture to mirror the org I want, not the org I had.”
“And the org you want has a platform team.”
“The org I want has a platform team that makes the stream-aligned teams faster. Not a team that gates the stream-aligned teams. Not a team that controls deploys. A team that makes deploys so easy that any developer can ship to any city without waiting.”
Jess nods. “That’s the right framing. The platform team’s success metric isn’t uptime; it’s developer velocity. If the stream-aligned teams are shipping faster and more reliably, we’re doing our job.”
Building the pipeline
The platform team begins work in the second week of February. Jess runs it like a startup within a startup: small team, tight scope, weekly demos to the engineering team.
Week one: Automated deploys. Jess and the platform team replace the manual deployment process with an automated CI/CD pipeline. Every pull request triggers a build. Every merged PR triggers a deployment to a staging environment. Every approved staging deployment triggers a production rollout.
The key innovation: parallel deployments. Instead of deploying to six cities sequentially (four and a half hours), the pipeline deploys to all six cities simultaneously (forty-five minutes). Each city’s deployment is independent; if Adelaide fails, Perth continues. The failure is caught, reported, and fixed without blocking the entire release.
Tom watches the first automated deploy from his desk. The pipeline runs. Eight cities, simultaneously. Green across the board. Forty-three minutes.
He messages Sarah: Remember when I said I’d spend my Sunday doing the deploy? I don’t have to do that any more.
Sarah: Good. You were insufferable on deploy Sundays.
Week two: Test suite. Jess attacks the flaky tests with the pragmatism of someone who has fixed test suites at Atlassian scale. She quarantines the three flaky tests, moving them out of the main suite into a separate “known issues” suite that runs in parallel but doesn’t block the build. The three tests are tagged with owners and deadlines for fixing the root cause. The main suite drops from ninety minutes to fifty-five.
Then she parallelises the test suite. Instead of running all tests sequentially on one machine, the tests run across four machines simultaneously. Fifty-five minutes becomes fourteen.
A green build now means something again. Developers start trusting the pipeline. When a test fails, it means something broke, not that the universe was feeling capricious.
Priya, from Melbourne, sends a message to the engineering channel: “I just deployed a feature at 2pm and it was in production at 2:20pm. Last month that would have taken until Friday. I could cry.”
Week three: Monitoring. The golden signals dashboards are live, but they’re passive: they show data, they don’t alert. Jess builds alerting for all six cities. Latency above 500ms: alert. Error rate above 1%: alert. Queue saturation above 85%: alert. Database approaching capacity: alert.
The alerts go to a shared channel: #platform-alerts. The platform team responds during business hours. After hours, the on-call rotates between platform team members. No more Tom-as-single-point-of-failure.
The first week of alerting produces forty-seven alerts. Most are threshold calibration issues: the alerts are too sensitive and fire on normal traffic spikes. Jess tunes them. By week two, the alerts are down to three per day, each one meaningful.
The Adelaide substitution failure (four hours of wrong boxes) would now be caught in under five minutes. The monitoring would detect the stale data, alert the platform team, and the fix would be deployed through the automated pipeline. Five minutes instead of four hours. That’s the difference between “a system that works” and “a system that knows when it’s broken.”
Week four: Feature flags and canary deployments. Jess introduces two practices that change how Greenbox ships software.
Feature flags allow the team to deploy code to production without activating it for users. A new substitution algorithm can be in the production codebase, tested against real data, but invisible to subscribers until the flag is turned on. This decouples deployment from release: the code ships continuously, the features activate when the team is confident.
Canary deployments roll out changes to a small percentage of users first. A new delivery route optimisation deploys to 5% of Perth subscribers. If the error rate stays below the threshold, it rolls out to 25%, then 50%, then 100%. If the error rate spikes, the deployment automatically rolls back.
Tom, who once spent a weekend manually rolling back a botched delivery tracking release, watches the first canary deployment with something close to awe. The system deploys to 5% of subscribers. The monitoring watches. The latency is flat. The error rate is zero. The deployment expands to 25%. Still flat. 50%. Still flat. 100%. Done.
“That’s what it’s supposed to feel like,” Jess says. “Boring. Reliable. Nobody heroic.”
Infrastructure as code
The final piece: Jess writes the entire infrastructure as code. Terraform and AWS CDK definitions describing every server, database, queue, monitoring dashboard, and alerting threshold. Versioned, reviewed, deployed through the same pipeline as application code.
Adding a new city no longer means Tom spending a weekend manually configuring servers. It means adding a city configuration file and running the pipeline. Hobart, launching next month, will be the first city deployed entirely through infrastructure as code. Setup time: two hours. Adelaide took three weeks.
Charlotte watches Jess deploy a complete staging environment for a hypothetical ninth city in four minutes. “This is what I meant when I said Greenbox needed platform maturity. The ability to deploy confidently, monitor continuously, and scale without manual heroics.”
Tom’s full leadership moment
The platform work takes a month. By the end of February, the numbers tell the story.
| Metric | Before | After | Target |
|---|---|---|---|
| Deploy frequency | Weekly | Daily (often multiple) | Daily |
| Lead time | 5 days | 4 hours | < 1 day |
| Change failure rate | 20% | 6% | < 5% |
| Time to restore | 4 hours (Adelaide) | 12 minutes (average) | < 1 hour |
| Test suite duration | 90 minutes | 14 minutes | < 15 minutes |
| Deploy duration | 6 hours (sequential) | 43 minutes (parallel) | < 1 hour |
Tom presents these numbers at the quarterly engineering review. Charlotte, Diane, Maya, Patricia (video), and all six squad leads are present.
He doesn’t present them as a triumph. He presents them as a lesson.
“Eight months ago, I told the Cerulean investors we’d have deployment automation and golden signals in six months. It took eight months. The acquisition delayed us. The national expansion delayed us. And, honestly, I delayed us, because I kept thinking the platform work could wait while we shipped features.”
He pauses. “The Adelaide incident taught me that the platform isn’t separate from the features. When the platform breaks, the features break. When the deploy pipeline is slow, the features are slow. When the monitoring has gaps, the failures are invisible. The platform is the foundation; everything else sits on top of it.”
Charlotte, who has been waiting three years for Tom to say this, doesn’t say “I told you so.” She says: “What would you have done differently?”
Tom considers the question. He’s standing in front of a room of people he leads, not just manages, leads. He’s responsible for the technical decisions of a company with fifty-five people and twenty-two thousand subscribers. The weekend prototype builder from Series 5 (the one Charlotte called “week one vibes”) is still in there. But the person standing in this room is different.
“I would have hired Jess six months earlier. I would have started the platform team when we hit five cities, not eight. I would have measured the DORA metrics from the start, not after the crisis. And I would have listened to Priya, who told me two years ago that the architecture mirrors the org structure, and if we wanted a different architecture, we needed a different org structure.”
Priya, on the Melbourne video feed, doesn’t say anything. She doesn’t need to.
Charlotte asks the harder question. “What did you learn about your own role?”
Tom looks at the whiteboard. The DORA metrics. The golden signals. The platform team structure. The infrastructure as code. None of this is code he wrote. Jess designed the pipeline. Priya reviewed the architecture. The platform team implemented it. Tom’s contribution was recognising the problem, hiring the right person, restructuring the team to address it, and getting out of the way.
“I learned that the engineering lead’s job isn’t to build the platform; it’s to make sure the platform gets built.” He pauses. “In year one, I was the builder. In year two, I was the architect. In year three, I’m the, I don’t know what the word is.”
“Leader,” Charlotte says.
Tom doesn’t argue.
That evening, he’s at home. Sarah is marking student papers at the kitchen table. Leo is building something elaborate with LEGO on the living room floor. Ava is reading, as always.
“How was work?” Sarah asks, not looking up from the papers.
“I presented to the leadership team. The platform numbers.”
“Did they go well?”
“Yeah. Charlotte asked what I learned about my role. I said something about not building things myself any more.”
Sarah puts her pen down. “Is that hard?”
“It used to be. Today it wasn’t.” He pauses. “Jess designed the deploy pipeline. Priya reviewed the architecture. The platform team built it. I just held the space for it to happen.”
“That sounds like something Charlotte would say.”
“It’s something Priya said. Two years ago. I didn’t listen.”
Sarah picks up her pen. “You listened eventually. That counts.”
Tom opens his laptop. He has a message from Jess: The Hobart infrastructure deployed in 1 hour 47 minutes. Fully automated. Zero manual steps. First city launched entirely through the platform.
He types back: Show me the dashboard.
Jess sends a screenshot. Eight cities. Green across the board. Latency nominal. Error rates below threshold. Deploy pipeline clear. The system is healthy, and the system is telling them so.
The 2 AM fix nobody noticed
Three days after the Hobart launch, at 2:14 AM AWST on a Tuesday, the canary system flags an elevated error rate in the Melbourne delivery scheduler. The on-call dev’s phone doesn’t buzz. Not yet.
The monitoring pipeline catches the spike: error rate at 2.3%, up from the 0.1% baseline. The automated triage system feeds the error logs, the stack trace, and the relevant ADRs into an LLMA neural network trained to predict the next token in a sequence, large enough that it generalises to tasks it wasn’t explicitly trained for. session with a standing PromptThe input you hand to an LLM – system instructions, user message, examples, retrieved documents, tool descriptions, the lot. : Analyse this error spike. Identify the root cause. If you can produce a fix with high confidence, open a PR. If not, page the on-call.
The LLM reads the traces. The error is a nil pointer in the Melbourne delivery scheduler: a timezone edge case where the AEDT-to-AEST transition creates a one-hour window where a scheduled delivery time resolves to nil. It’s the kind of bug that only manifests twice a year, at 3 AM, during the daylight saving changeover. The LLM has seen this pattern before, not because it remembers, but because the ADR for the delivery scheduler (ADR-017: “Delivery times stored as UTC, converted to local at display”) explains exactly why timezone transitions are dangerous for this module.
The LLM writes a fix: a nil guard with a fallback to the previous valid delivery time. It writes a test that simulates the AEDT-to-AEST transition. It opens a PR with a title (“Fix nil pointer in Melbourne scheduler during DST transition”), a description that includes the error trace, the root cause analysis, and the ADR reference, and tags the on-call dev.
Ravi wakes up at 6:45 AM. He checks his phone. One notification: a PR from the automated triage system, tagged for his review. He reads it over coffee. The description is clear. The fix is correct. The test covers the edge case. He approves it. The canary deploys to 5% of Melbourne traffic. Error rates stay flat. Fifteen minutes later, it auto-promotes to 100%.
At 8:30 AM, a message posts to #incidents in Slack:
Incident auto-resolved: Melbourne delivery scheduler nil pointer Detected: 02:14 AWST. Root cause: nil pointer during AEDT→AEST transition in delivery time resolution. Fix applied via PR #847 (auto-generated, reviewed by @ravi). Canary deployed 06:52, promoted 07:07. No subscriber impact. ADR-017 updated with DST edge case note.
Sam reads it over her morning coffee. She doesn’t need to do anything. No angry emails. No apology calls. No weekend ruined. The system caught the bug, diagnosed it, fixed it, tested the fix, deployed it safely, documented it, and told the team, all before anyone was awake.
Charlotte sees the Slack message and sends one of her own: “This is why we built the pipeline. This is why we wrote the ADRs. This is why the canary system exists. None of this is the LLM being clever; it’s the LLM standing on top of eighteen months of engineering discipline. Take away the ADRs and it wouldn’t have understood the timezone design. Take away the canary and the fix would have gone straight to production untested. Take away the structured logging and it wouldn’t have found the root cause. The LLM is the capstone; everything underneath it is what makes it work.”
Tom, reading from home while Ava eats breakfast: “The best incident is the one where nobody’s morning is interrupted.”
Priya: “The best incident is the one where the system is smarter at 2 AM than any of us would be.”
Charlotte and Diane and Tom
Late Friday, the three of them are the last people in the Perth office. Charlotte is updating her spreadsheet: Row 47, Greenbox, platform maturity: 8 out of 10. Two months ago it was a 3.
“When I scaled Sunridge,” Diane says, “I was the bottleneck until the day I sold. I never hired my Jess. I just ran faster until I couldn’t any more.”
Tom deflects with humour. “Jess would be insulted. I could do it. I just couldn’t do it and also lead six squads and also parent two children.”
“That’s the point,” Charlotte says. “Nobody can. That’s why you build teams.”
Tom looks at the golden signals dashboard. Eight cities. All green.
Charlotte: “For now.”
Diane: “That’s all ‘for now’ ever means.”
The hook
Eight cities. Eighty people. A platform that deploys in forty-three minutes, monitors itself across every region, and fixes timezone bugs at 2 AM without waking anyone up. A pipeline that any developer can ship through. A test suite that means something again.
Tom started as the person who built everything. Then the person who designed the architecture. Now the person who builds the team that builds the platform. The infrastructure works. The organisation matches the architecture. The system is healthy, and the system tells them so.
It’s the strongest the technology has ever been.
And then Hartland Group calls.
Not about Freshly. Not about a competitive move. Not about the market.
About Greenbox.
The next series, The Big Table, follows Greenbox into the conversations that will define its future.
The Greenbox story continues in The Big Table. I'll be writing about a few other things in the meantime -- the next chapter lands around 20 April.