The code is the same. Everything around it is different.
Tom’s first Hartland meeting is an Architecture Review Committee. Ten people on a video call. Two of them are architects he’s never met, from a division that processes frozen meals. One is reading from a slide deck with thirty-seven pages. Tom’s contribution is a five-minute summary of Greenbox’s bounded context model, which he presents from memory because he built it.
The frozen-meals architect asks whether Greenbox’s event-driven pipeline complies with Hartland’s Enterprise Integration Standard v4.2. Tom has never heard of Enterprise Integration Standard v4.2. He asks what it covers. The architect shares a PDF. It is ninety-one pages long.
Tom reads it that evening, after Ava and Leo are in bed, with a glass of wine and the particular resignation of a person who is about to learn what “enterprise governance” means in practice.
What he gains
The resources are real. Not theoretical, not promised-for-next-quarter, real. A dedicated security team reviews Greenbox’s authentication flow and finds three vulnerabilities that Tom suspected but never had time to address. A compliance analyst handles the privacy audit that used to eat two weeks of Priya’s time every year. The infrastructure budget doubles overnight.
Jess gets a proper platform team. Four engineers, dedicated. No more borrowing developers from the feature squads to fix pipeline issues. She builds a deployment system that handles fifteen microservices across eight cities with the calm efficiency of someone who used to manage systems at Atlassian scale and finds a produce-box company refreshingly contained.
“I have a budget line,” Jess tells Tom, with the expression of a person who has discovered indoor plumbing. “An actual budget line. I don’t have to justify every EC2 instance in a spreadsheet anymore.”
Tom laughs. He remembers the spreadsheet. He does not miss the spreadsheet.
And the security reviews catch something real, a session management flaw that could have exposed subscriber payment details under specific conditions. The kind of thing that keeps you up at 2am when you’re a startup CTO with no security team. Tom sleeps better now. That counts for something.
What he loses
Speed.
At Greenbox, a bug fix went from discovery to production in minutes. Tom would see the error, write the patch, run the tests, deploy. The CI/CD pipeline Jess built was fast because it was designed for a team that moved fast.
At Hartland, the same bug fix requires a change request. The change request requires a description, an impact assessment, a rollback plan, and an approver from outside the team. The Change Advisory Board meets on Tuesdays. If the bug is found on Wednesday, the earliest it ships is the following Wednesday. Seven days for twelve lines of code.
Tom raises this at his first quarterly business review. He explains DORA metrics, the same framework Jess introduced, and shows that Greenbox’s lead time has tripled since the partnership.
The Hartland COO nods sympathetically. “We’re aware of the trade-off. But we also haven’t had a production incident affect a customer in eighteen months.”
“Neither had we,” Tom says, “and we deployed four times a day.”
The COO moves to the next slide. Tom makes a note in his notebook. Not on his laptop, his notebook. He’s picked up the habit from Maya, though he’d never admit it.
There’s something else he loses, harder to name. At Greenbox, when a subscriber messaged about a missing box or a bruised avocado, the complaint landed in a Slack channel that Tom could see. He could trace the issue from the customer’s message to the delivery log to the packing manifest to the farm availability data. The whole chain, visible. The person at the end of the chain was real, a name, a suburb, a preference profile.
At Hartland, the subscriber is a row in a dashboard. Aggregate satisfaction: 87%. Net Promoter Score: +42. Churn rate: 3.2% monthly. The numbers are good. Tom helped build the systems that generate them. But the numbers are not people. The numbers are an abstraction of people, and the abstraction is necessary at scale, and the necessity does not make it feel any less like a loss.
He misses the feeling that what he builds matters immediately to someone he could name. That’s the thing about startups that nobody warns you about: the intimacy scales down before the problems scale up.
The team
Some of the original Greenbox developers stay. Kai, who built the farm availability system with Priya in those early ensemble sessions, is now a senior engineer managing the Melbourne squad. He still writes the best Gherkin on the team. He still argues about naming in code reviews. Some things survive a corporate acquisition.
Others leave. Jas, who designed the original Greenbox interface and hand-painted the market banner, takes a job at a design studio in Fremantle. She texts Tom on her last day: Thanks for always trusting the weird ideas. Tom stares at the message for a long time before replying.
The new hires come through Hartland’s corporate pipeline. They’re competent. Many of them are very good. They’ve worked at scale, they understand enterprise systems, they know how to navigate organisational complexity.
They’ve never Event Stormed.
They’ve never sat in a room with sticky notes and farmers and surfboard-carrying mentors and discovered, collectively, that they were building the wrong thing. They’ve never pair-programmed with someone who sees the domain differently. They’ve never done a blameless post-mortem where the question is “what did the system allow?” instead of “who did this?”
They’ve never worked in a team where the culture was built on purpose, over years, by people who cared about craft.
Tom notices the gap the way you notice a missing ingredient in a familiar recipe. Everything looks right. Something tastes different.
Priya notices it too. She’s still leading the platform team, but her relationship with the codebase has changed. She used to own the substitution pipeline the way a craftsperson owns a tool they’ve shaped by hand. Now the pipeline is “Hartland IP” in a “technology portfolio,” and there are discussions about “rationalising” it with Hartland’s existing logistics engine. Priya attends these discussions with the contained patience of someone who built four hundred substitution rules for a reason and is not interested in explaining that reason for the fifth time.
She messages Tom after one such meeting: They want to reduce the rule set to sixty. Sixty. Mrs Patterson would receive beetroot within a fortnight.
Tom: Write an ADR. Context, decision, consequences. Put the customer impact in the consequences section. Make it impossible to ignore.
Priya writes the ADR. The rationalisation discussion goes quiet. The four hundred rules survive. For now.
The quiet rebellion
Tom keeps running ensemble programming sessions. Thursdays, 2pm, the Perth office. Open to anyone. He doesn’t call it training, he calls it “building together.” The Hartland developers are sceptical at first. Mob programming? Sounds slow. Sounds inefficient. Sounds like a meeting where someone types.
By the third session, two of them are hooked. By the sixth, one of them, a senior backend developer named Wei who transferred from Hartland’s logistics division, tells Tom it’s the best engineering practice she’s encountered in twelve years.
“Why doesn’t everyone do this?” she asks.
“Because it looks slow,” Tom says. “And it is slow, at the keyboard. But the understanding spreads faster than any documentation I’ve ever written.”
He keeps writing ADRs. Not because Hartland requires them. Hartland has its own documentation standards, which involve Confluence pages and architecture diagrams and a template with fourteen mandatory sections. Tom writes ADRs anyway. Context, decision, consequences, status. The format Charlotte introduced four years ago. He stores them in the code repository, next to the code they describe, where developers will actually read them.
He teaches the new developers the practices that made Greenbox work. Not with a presentation or a training module. With work. He sits in the room and does the thing, the same way Charlotte sat in the room and did the thing, years ago, when Greenbox was young and everything was being learned for the first time.
The practices outlive the startup. That was always the point.
Wei starts running her own ensemble sessions in the logistics division. She doesn’t ask permission. She just books a meeting room on Wednesday afternoons and invites anyone who wants to come. Tom hears about it from Jess, who heard about it from the logistics team’s Slack channel.
“You’ve got a disciple,” Jess says.
“She’s not a disciple. She’s a developer who found a practice that works.”
“Same thing, in a corporate. Be careful. Hartland’s L&D team will want to turn it into a mandatory training module with a competency framework and a certificate.”
Tom winces. “Don’t even joke about that.”
But the spread is real. By month four, three teams across Hartland are running some version of the practices Tom introduced. Not because anyone mandated them. Because the developers who experienced them told other developers, and those developers tried them, and some of them stuck. The same way it happened at Greenbox, except slower and messier and more resilient for being both.
Home
It’s a Tuesday evening. Tom is in the kitchen, unloading the dishwasher. Sarah is marking papers at the table. Year 10 English, from the stack of exercise books that migrates between her school bag and the kitchen in a weekly cycle.
Ava is in her room. She’s eleven now, and her room is her territory. She reads in there, draws in there, has conversations with friends that Tom is no longer privy to. This is normal. This is growth. It still feels like loss.
Leo is at the kitchen table, building something with LEGO. He’s eight and builds with the focused intensity of someone who believes that the structural integrity of a spaceship depends on the precise placement of every single brick. Tom recognises the impulse. It’s his.
“Did you make something today, Daddy?” Leo asks.
The question used to come from Ava, years ago, when Tom would come home from the Greenbox office buzzing with the energy of having built something real. She’d ask, and he’d tell her, a new feature, a fixed bug, a system that worked. She stopped asking around the time the meetings started outnumbering the coding sessions. Tom noticed. He didn’t say anything.
Now Leo asks. And the honest answer, today, is: no. Tom spent the morning in a quarterly business review. He spent the afternoon reviewing a change request. He approved two pull requests. He attended a thirty-minute call about enterprise integration standards. He did not make anything.
“Not today, mate,” Tom says.
Leo nods, accepting this with the uncomplicated grace of an eight-year-old, and goes back to his spaceship.
Sarah looks up from her marking. She doesn’t say anything. She doesn’t need to. Fifteen years of marriage have given them a private language of glances that carries more information than most conversations.
Tom finishes the dishwasher.
After bedtime
It’s 9:30pm. The house is quiet. Sarah is reading in bed. Tom is in his study, the small room at the back of the house that used to be a storage room and is now the place where he processes the world.
Sarah’s voice comes from the bedroom. “Are you coming to bed?”
“In a minute.”
“The last time you said ‘in a minute’ it was two hours.”
“That was a deploy. This is different.”
“It’s always different.”
She’s not wrong. Tom smiles in the dark hallway and goes into his study.
He opens his laptop. Not work. A side project.
It’s a small thing, a tool for visualising seasonal produce availability across regions. Nobody asked him to build it. There’s no ticket, no change request, no architecture review. Just an idea that arrived during a conversation with Ben about winter supply forecasts, and a quiet evening, and the familiar hum of a code editor waiting for input.
Tom writes a function. Tests it. Refactors it. Writes another. The LLM suggests an approach he hadn’t considered, an elegant data structure for overlapping growing seasons. He reshapes it, tightens the types, adds constraints. The old rhythm. The rhythm that existed before titles and governance and enterprise integration standards.
He works for an hour. Then he stops, not because he’s finished but because the itch has been scratched. The thing doesn’t need to ship. It doesn’t need to be reviewed. It doesn’t need to comply with anything.
He closes the laptop. The house is dark. Sarah has turned off her reading light.
Tom sits in the quiet study. Outside, the Perth suburbs are still. A possum crosses the power line with the indifference of an animal that has never attended a Change Advisory Board.
Making things is how Tom processes the world. That hasn’t changed. The title changed. The calendar changed. The meetings changed. But the thing underneath, the need to understand something by building it, to hold a problem in his hands and shape it into code, that’s the same thing it was when he sat in Maya’s living room with a laptop and an idea and said yeah, all right, I’m in.
Some things survive a corporate acquisition.