The Adelaide playbook works. The process is repeatable. The next constraint isn’t cities or farms or logistics – it’s people. GreenBox needs to hire forty-five people in eighteen months. One person every two weeks, for a company that has never hired faster than one person a month.
GreenBox’s hiring history is a story told in referrals and happy accidents.
Tom was Maya’s university friend’s husband. She met him at a barbecue and spent two hours talking about subscription systems. Priya was recruited from a Meetup talk she gave about event-driven architectures – Tom approached her afterward and said “we need someone like you.” Sam was a friend of a friend who happened to be looking for something different after three years in corporate operations. Jas came through a recruiter, but Maya hired her because of a sketch she did on a napkin during the interview. Kai was a referral from a former colleague of Tom’s.
Every early hire had a personal connection to someone already at GreenBox. Every interview was unstructured – Maya or Tom talking to someone for an hour and deciding whether they felt right. Every salary was negotiated individually, based on what the candidate asked for and what Maya thought the company could afford.
This worked at twenty-five people. At eighty, it’s a recipe for disaster.
The Marcus problem
Marcus was GreenBox’s first “real” hire – the first person recruited through a job listing, interviewed by a panel, and offered a market-rate salary. Maya hired him as sales lead during the management gap restructure. The process took three months.
Three months. From job listing to signed offer. Maya interviewed eleven candidates. She agonised over two finalists. She called Charlotte for advice, called Diane for advice, called Lee for advice. She made Marcus an offer that was slightly below market rate because she felt awkward offering a salary higher than her own.
Marcus accepted because he believed in the mission. But the process taught Maya something she hadn’t articulated: hiring one person at GreenBox takes the entire leadership team’s bandwidth for weeks.
“If we hire forty-five people the way we hired Marcus,” Sam says at a Monday leadership meeting, “it will take us six years.”
“We need a process,” Charlotte says.
“We need an actual hiring pipeline,” Diane says. “Not a process. A pipeline. Like the sales pipeline Marcus built. Candidates in, evaluated, filtered, offered, onboarded. With stages, with timelines, with criteria.”
Tom shifts in his chair. “We’re not a factory.”
“No,” Diane says. “But you’re also not five people at a barbecue anymore. You need to be able to evaluate someone without Maya in the room. Without Tom in the room. Without any single person being the bottleneck for every hire.”
The authority bottleneck again. The same pattern Charlotte identified when she first arrived – Maya holding the decision rights because letting go feels like letting down. Except now it’s not just Maya. Tom wants to interview every engineer. Sam wants to onboard every operations hire personally. Jas wants to review every designer’s portfolio. The management layer that solved the company-level bottleneck has created four person-level bottlenecks.
Structured hiring
Charlotte introduces structured interviewing. She doesn’t call it Topgrading – she’s seen that label put people off. She calls it “knowing what you’re looking for before you start looking.”
The principle is straightforward. Before you interview anyone, you define:
What the role does. Not a job description full of adjectives – a list of five to seven specific outcomes the person will achieve in their first six months. For a developer joining the Adelaide squad: ship the hub-and-spoke logistics feature, contribute to two sprint retrospectives, pair with at least three team members, and write decision table rules for one new farm partner.
What good looks like. Not “strong communicator” or “team player” – observable behaviours. A developer who asks questions about the business domain during sprint planning. An operations coordinator who notices a delivery failure before the customer reports it. A farm partnership manager who visits a farm and can assess viability in two hours.
How you evaluate it. A structured interview with the same core questions for every candidate at the same level. A work sample that tests the actual skills the role requires. A reference check that asks specific questions about the defined criteria, not “would you recommend this person?”
Tom resists this. Not because he disagrees with the principle – he can see the logic. He resists because the evaluation criteria for developers feel reductive. “You can’t measure whether someone will be a good engineer from a structured interview. You know it when you see it.”
“That’s how we got burned before,” Charlotte says. “The ‘know it when you see it’ approach means every interviewer is testing for a different thing. Tom tests for technical depth. Priya tests for systems thinking. Kai tests for speed. The candidate who impresses all three is rare. The candidate who impresses none might be perfect for a role that none of you are evaluating.”
She pauses. “And it introduces bias. If you’re testing for ‘feels right,’ you’re testing for ‘feels like me.’ The best engineers I’ve worked with felt wrong at first. They thought differently. That was the point.”
Tom goes quiet. He’s thinking about Kai – how Kai’s 47-file PR in the first week felt wrong, how the friction with Kai’s speed-over-structure approach produced the best security thinking on the team after the ensemble programming and threat modelling work. Kai didn’t feel like Tom. Kai felt like a problem. And then Kai became indispensable.
“Fine,” Tom says. “But I want to design the technical evaluation.”
“Design it with Priya,” Charlotte says. “Not alone.”
Priya’s interview
Priya takes the technical interview design seriously. She’s been thinking about it since Adelaide, when two contractors were hired for the soft launch and both struggled with the business domain. They could write code. They could pass a technical test. But they couldn’t translate a business rule into software without someone explaining it to them twice.
“The problem with most technical interviews,” Priya tells Tom, “is that they test whether someone can solve a problem they’ll never see at work. Algorithm puzzles, whiteboard coding, system design questions about Twitter or Netflix. Our developers don’t build Twitter. They build a substitution engine that needs to know that Adelaide doesn’t have tomatoes in July.”
“So what do you want to test?”
“Whether they can think about a business problem and turn it into code.”
Priya designs the interview around Example Mapping. The candidate is given a real GreenBox business rule – simplified, anonymised, but real. Something like: “A subscriber has marked ‘no beetroot’ in their preferences. This week, every farm partner is sending beetroot in their mixed boxes. What should the system do?”
The candidate doesn’t write code. They map the examples. What are the inputs? What are the expected outcomes? What are the edge cases? What questions would they ask the product team?
Then they write a test. Not for the full system – for the business rule. Given these inputs, expect this output. Given this edge case, expect this behaviour.
Candidates who can think about the business rule, ask clarifying questions, and write a clean test pass. Candidates who jump straight to coding without understanding the problem fail. Candidates who write elegant code but can’t engage with the domain fail.
“You’re testing for DDD thinking,” Tom says, reading Priya’s design.
“I’m testing for the thing that actually matters here. Whether they can understand why the code exists, not just how to write it.”
Tom looks at the interview spec. It’s thorough. It’s structured. It’s better than anything he would have designed alone, because Priya is thinking about what GreenBox needs from a developer, not what Tom values in a developer.
“Run it,” he says.
Over the next three months, thirty-seven developer candidates go through Priya’s interview. Twelve pass. The ones who pass come from unexpected backgrounds – a former teacher who learned to code at thirty-two, a data analyst from a logistics company, a junior developer from a government department who asked better questions about the business rule than anyone else. The ones who fail include two senior engineers from big tech companies who couldn’t engage with the domain and one candidate who wrote flawless code for the wrong problem because they didn’t ask a single clarifying question.
Priya’s interview becomes the standard. Not just for developers – Jas adapts it for designers (map the user’s journey through a GreenBox substitution notification) and Marcus adapts it for sales hires (given this customer objection, what questions would you ask before responding?).
It’s Priya’s methodology becoming institutional. The quiet developer who once flagged problems gently and moved on when nobody responded is now shaping how the entire company evaluates talent.
Her mum calls on Sunday. “How is work?”
“I designed the hiring process for the whole company.”
“That’s nice, dear. Are you eating properly?”
Compensation frameworks
The first bad hire teaches GreenBox about compensation the hard way.
A developer – call him Nathan – is hired for the Sydney expansion team in March. He’s experienced, available immediately, and asks for a salary $25,000 above what Tom and Priya have been paying other developers at his level. Tom, under pressure to fill the role before the Sydney launch, agrees.
Three weeks later, a Melbourne developer finds out. Nathan mentions it casually in a team chat, assuming everyone at his level earns the same. The Melbourne developer – one of the best hires from the Brisbane expansion – walks into Anika’s office: “I’ve been here for a year. He’s been here for three weeks. He earns twenty-five thousand dollars more than me. Can you explain that?”
Anika can’t explain it. There is no explanation. Nathan asked for more. Tom said yes. The Melbourne developer asked for less because she didn’t know the market rate. Just negotiation outcomes masquerading as compensation decisions.
Charlotte’s response is immediate: “You need compensation bands. Yesterday.”
Maya resists – bands feel corporate. But she reads the Melbourne developer’s message to Anika: I thought this place was different. I thought the values were real.
Charlotte walks them through it. Four levels per discipline (Associate, Mid, Senior, Lead), each with a salary range based on market data. A developer at the Mid level in Perth: $95,000 to $115,000. New hires come in between the minimum and midpoint. Equity grants above Senior level. The framework takes the negotiation out of it – consistency instead of haggling.
“What about Nathan?” Maya asks.
“Nathan is above the band. Acknowledge it honestly. Don’t reduce his salary. At his next review, it stays flat until the band catches up.”
Maya speaks to Nathan directly. He’s unhappy. He’s the first person to be unhappy with Maya in a way that doesn’t resolve over coffee. He stays for four months and then leaves for a company that pays more. Tom is relieved. Charlotte says: “That’s what bands are for. They attract people who are here for the work, not just the money.”
The first firing
The compensation problem is uncomfortable. The first firing is devastating.
A developer – hired through the structured process, passed Priya’s interview, showed genuine enthusiasm for the domain – starts in the Adelaide team in late February. He ships code without tests. Not occasionally, not under time pressure. Consistently. Every pull request is code without tests.
Tom notices on day three. He mentions it in a code review. “We write tests at GreenBox. The test suite is how we know the decision tables work. If you ship without tests, we’re flying blind on the substitution logic.”
The developer – his name is Liam – pushes back. “Tests slow me down. I can write the feature in two hours with tests or forty minutes without. You want speed, right? You’re opening five cities this year.”
Tom doesn’t respond immediately. He takes a walk around the block. He calls Priya.
“He’s good,” Tom says. “Fast. Clean code. Understands the architecture. But he won’t write tests. He thinks they’re optional.”
“They’re not optional.”
“I know. How do I make him understand?”
Priya is quiet for a moment. “Show him the Brisbane incident.” The Two Squads incident from Series 5 – when Mrs Patterson received a box containing an allergen because the cross-squad integration tests caught a change in the Melbourne squad but not in Perth. The incident that nearly cost GreenBox its most loyal subscriber.
“The tests aren’t about speed,” Priya says. “They’re about trust. Mrs Patterson trusts the box. The tests are how we keep that trust.”
Tom shares the incident with Liam. He explains the context. He shows the post-mortem. He’s patient and thorough in a way that Sarah would be proud of.
Liam listens. Then he says: “That’s a process problem, not a testing problem. If your integration was better, you wouldn’t need the tests.”
Tom stares at him. He’s heard this argument before. He’s made this argument before – early in the GreenBox journey, when he believed he could solve anything with enough code and dismissed workshops because admitting they were valuable threatened his identity as a pure technician. He recognises the posture. He recognises it because it used to be his.
He gives Liam two weeks. He pairs with him. He shows him how to write tests that are fast, how the test suite runs in under four minutes, how the CI pipeline catches failures before they reach production. Liam writes tests during the pairing sessions. When Tom isn’t watching, he stops.
At the end of two weeks, Tom has a conversation with Liam that he’s been dreading.
“This isn’t working. You’re talented. Your code is clean. But you won’t write tests, and at GreenBox, testing isn’t optional. It’s how we build.”
Liam argues. Tom listens. Then Tom says the hardest sentence of his management career: “Your last day is Friday.”
It’s Tuesday. Liam goes quiet. He packs up his laptop and leaves the Adelaide co-working space without saying goodbye to anyone.
Tom calls Sarah that evening. He doesn’t talk about the code or the tests or the conversation. He talks about the look on Liam’s face.
“Managing people isn’t like managing code,” Sarah says. “Code doesn’t have feelings when you tell it it’s wrong.”
“I know.”
“Are you okay?”
“No. But I think I did the right thing.”
“You did. Come home. The kids are watching a movie.”
Tom flies back to Perth the next morning. He sits next to Priya in the office and says: “We need to add something to the interview. A question about testing culture. Not ‘do you write tests’ – everyone says yes. Something that reveals whether they believe in it.”
Priya nods. She adds a step to the interview: after the Example Mapping exercise and the test-writing exercise, the interviewer asks: “Imagine your team is under pressure to ship a feature by Friday. You’ve written the feature but not the tests. The PM says ship it now, write the tests next week. What do you do?”
There’s no right answer. But there are answers that tell you whether the person will write tests when nobody is watching.
The Dunbar problem
By April, GreenBox has forty-eight people. The hiring pipeline is working. Onboarding has been structured – new hires get a buddy, a 30/60/90 day plan, and a meeting with Maya in their first week.
The meeting with Maya is the problem. At forty-eight people, she’s spending two hours a week on introductions. The meetings are getting shorter. The first one lasted an hour. Now they’re thirty minutes, and Maya is looking at her phone twice during each one.
“You’re hitting Dunbar’s limit,” Diane says. Robin Dunbar proposed that humans can maintain about 150 meaningful social relationships. But for close working relationships – where you know someone’s name, their role, what they’re working on, whether they’re having a good week – the number is closer to 15 or 50.
Maya has always known everyone at GreenBox. When Sam was overwhelmed during the Wardley Mapping sprint, Maya noticed because she knew Sam’s patterns. When Priya found her voice during ensemble programming, Maya was in the room. At forty-eight people, she’s losing this. There are people in Melbourne she’s met once. A developer in Brisbane she’s never met in person. The Adelaide team knows Maya’s name from a Slack message, not a conversation.
“I can’t know everyone,” Maya says. She’s sitting with Nadia on the couch on a Sunday evening. The sentence feels like an admission of failure.
“You don’t have to know everyone,” Nadia says. “You have to trust the people who know everyone.”
It’s the management gap again, in a new shape. Maya can’t hold every relationship. She can hold the relationships with the people who hold the other relationships. That’s what a management layer is. Not a hierarchy of power. A hierarchy of trust.
Sam’s delegation crisis
Sam is drowning. She’s Operations Lead now – it’s on her email signature, her LinkedIn profile, and the org chart Charlotte designed during the management restructure. But she’s also still doing operations.
Every Thursday, Sam checks the Perth delivery dashboard. She reviews the packing lists. She calls the courier if something looks wrong. She replies to customer complaints that come in before 9am, because she wakes up before the support team and she can’t stand seeing unanswered messages.
Every Friday, she does the same for Adelaide. Plus the weekly operations report for the board pack. Plus the logistics cost analysis that Diane requested for the Sydney expansion planning. Plus the hiring pipeline reviews for three operations roles she’s trying to fill.
Charlotte notices first. Not because Sam complains – Sam never complains. Charlotte notices because Sam’s reports are late. Sam’s reports have never been late. The weekly operations summary, which used to arrive on Friday afternoon, started arriving on Saturday morning. Then Sunday. Then Monday. Charlotte has worked with enough operators to recognise the pattern: the most reliable person stops being reliable because they’re carrying more than one person can carry.
Charlotte doesn’t bring it up in a meeting. She takes Sam for a coffee on a Wednesday afternoon. Sam orders a flat white and puts her phone face down on the table – the phone that hasn’t stopped buzzing since they sat down.
“What’s your average working day?” Charlotte asks.
“Eight to six. Sometimes seven.”
Charlotte knows this means seven to seven. She’s checked the Slack timestamps. Sam’s last message is rarely before 9pm. Her first message is often before 7am.
“What are you doing that only you can do?”
Sam thinks about it. “The operations report. The logistics cost analysis. The hiring reviews. Setting up the Adelaide and Sydney operations infrastructure.”
“What are you doing that someone else could do?”
The silence is longer than it should be.
“The delivery dashboard checks. The courier calls. The customer complaints.”
“Why are you still doing those?”
“Because if something goes wrong and I haven’t checked–”
“Sam.”
Sam puts her hands flat on the table. “Because I’m scared that if I stop doing them, nobody will do them as well as I do.”
“They won’t.”
Sam looks up. She expected Charlotte to argue, to say “of course they will” or “you have to trust people.”
“They won’t do it as well as you,” Charlotte says. “They’ll do it differently. Some things will be worse. Some things will be better. The delivery dashboard check that you do by instinct – looking at the numbers and knowing that something feels off because Melbourne’s dispatch time is fourteen minutes slower than usual – someone else won’t see that. Not at first. They’ll learn it. But they won’t be you.”
“So why should I let go?”
“Because you can’t be Operations Lead and the operations team at the same time. You were hired for the first job and you’re still doing the second job. That means the first job – strategy, planning, scaling the operations across eight cities – isn’t getting done. And nobody else can do that job. Plenty of people can check the delivery dashboard.”
Sam’s phone buzzes. She doesn’t pick it up.
Diane says the same thing differently, when Sam raises it at the leadership meeting later that week. “You’ve been promoted but you haven’t let go of the old job. You need to hire your replacement, not do both roles.”
Sam: “What if they’re not as good as me?”
Diane: “They won’t be. They’ll be different. And you need to be okay with that.”
Sam hires an operations coordinator the following week. Her name is Leah. She’s from a logistics company, she’s organised, she’s direct, and she’s never checked a produce delivery dashboard in her life. Sam spends a week training her. On the first Thursday that Leah checks the Perth delivery dashboard alone, Sam sits in the meeting room and stares at her phone, resisting the urge to check over Leah’s shoulder.
Leah finds something Sam wouldn’t have found. A courier route that’s been adding twelve minutes per delivery because of a road closure that ended two weeks ago but nobody updated the route. Sam has been seeing the slightly slow deliveries and attributing them to traffic. Leah, with fresh eyes, looked at the route itself.
Sam texts Charlotte: Leah found a routing error I’d been looking at for three weeks and didn’t see.
Charlotte: Fresh eyes. That’s why delegation isn’t just about your workload. It’s about having more than one way of seeing.
Sam doesn’t reply. She’s busy not checking the Adelaide dashboard. It’s the hardest thing she’s done at GreenBox, and that includes the eleven-hour Tuesday during Wardley Mapping and catching the credit card logging bug during threat modelling.
The onboarding system
By May, the hiring pipeline is producing a new person every ten days. The onboarding system has to keep up.
Charlotte designs it based on the buddy system and the 30/60/90 structure that’s become standard in scaling companies. But she adds something specific to GreenBox: every new hire, in their first week, reads the decision tables for their city. Not the code. The business rules. The substitution logic. The reason GreenBox exists, expressed as “if this, then that.”
“I want every person at GreenBox to know why we send capsicum instead of tomatoes when tomatoes are out of season in Adelaide,” Charlotte says. “Not because they’ll ever need to make that decision. Because understanding the business rules is how you understand the business.”
It’s the discovery work from Series 1 through 5 – the Event Storms, the Example Maps, the decision tables, the JTBD insights – becoming the onboarding curriculum. New hires don’t learn GreenBox from a slide deck. They learn it from the artefacts of three years of discovery.
A developer in the Sydney team, on her second day, reads the Perth substitution rules and sends Priya a message: “Why does the decision table have a specific rule for Mrs Patterson’s beetroot allergy? Don’t the general allergen rules cover it?”
Priya smiles. “That’s a good question. Ask Tom to tell you the story.”
Tom tells the story. The week-two subscriber. The beetroot. The allergen incident in Two Squads. The reason the test suite includes a specific test case called test_mrs_patterson_no_beetroot. The developer listens. She understands. She’s been at GreenBox for two days and she already knows why the tests matter.
That’s onboarding. Not a presentation. A story.
GreenBox is hiring well now. The structured interviews, compensation bands, buddy system, and onboarding programme have turned a chaotic process into a pipeline. Priya’s Example Mapping interview has become the template for every discipline. Sam is learning to let go – slowly, painfully, but learning. Tom has fired someone and survived it. The management layer is holding.
But forty-eight people and growing means forty-eight people who need to be fed. Not metaphorically – literally. The farm network that supported three cities needs to support eight. And the next city on the list, Adelaide, has already revealed that not every market looks like Perth.
The supply chain problem (coming 12 January) is about to get much bigger. And it starts with a promise Maya made in a cottage in Fremantle three years ago: everything in the box comes from within fifty kilometres.