Every team has people whose work is visible and people whose work is invisible. The visible work (code, architecture, product features) gets celebrated in demos, sprint reviews, and conference talks. The invisible work (operations, design, support, documentation) gets noticed only when it fails.
The Greenbox story demonstrates this pattern clearly. Here are two characters whose contributions hold the company together, and whose work rarely makes it into the narrative.
Sam
Sam Okafor is the operations person. She was employee number three, after Maya and Tom, and she’s been the person who makes things physically happen since the company was five people in a room above a cafe.
Her work doesn’t appear in the codebase. It appears in spreadsheets, phone calls, courier contracts, the van schedule on the whiteboard, the supplier relationship she’s maintained with a driver named Steve who does the Thursday deliveries and calls her if traffic is bad on the freeway. When Tom ships a new feature, that feature generates orders. Sam is the person who turns those orders into boxes on doorsteps.
The logistics of a produce-box delivery company are unglamorous and relentless. Every week, produce comes in from farms. It has to be sorted, inspected, packed, and dispatched within a window so tight that a single delay cascades into a day of missed deliveries. The cold chain has to hold: produce that leaves the warehouse at 4 degrees and arrives at a doorstep at 12 degrees is a quality failure, even if the customer doesn’t notice. The routing has to account for traffic, driver availability, and the geography of three cities with different road patterns and different peak-hour nightmares.
Sam handles all of this. She handles it with a combination of spreadsheets, phone calls, the courier management system she helped Dani Stavros integrate during the Melbourne logistics partnership, and a whiteboard in the Perth warehouse that Tom once called “the most critical infrastructure in the company.”
He was joking. He was also right.
Sam’s Thursday
A typical Thursday for Sam starts at 5:30am. She drives to the Perth warehouse in the dark, checking the overnight delivery exceptions on her phone at every red light. The warehouse crew has been packing since 4am: produce sorted, inspected, assembled into box tiers, sealed, labelled, stacked on pallets by delivery route. Sam walks the floor with a clipboard (actual clipboard, not a tablet, she tried a tablet and the screen got wet from condensation near the cold room, so she went back to paper).
She checks the cold chain logs. Produce received from Dave’s farm at 3:47am, recorded at 3.2 degrees. Produce from the Pemberton supplier at 4:12am, recorded at 4.1 degrees. A delivery from the Mundijong farm flagged at 6.8 degrees, above the threshold. Sam pulls two crates of lettuce, inspects them, decides they’re fine but notes the exception. She’ll call the courier company about the van’s refrigeration unit. She knows the conversation by heart: “It’s the older van, the one with the compressor issue. Can you rotate it out on Thursdays?”
By 7am, the vans are loaded. Steve, the Thursday driver, taps the side of his van and gives Sam a thumbs up. He’s been driving the northern suburbs route since month four. He knows which customers have dogs that block the front path, which apartment buildings have faulty intercoms, and which elderly subscriber (a woman named Gloria in Morley) likes it when the driver places the box on her kitchen bench rather than the doorstep, because her hip makes bending difficult.
Steve knows this because Sam told him. Sam knows this because Gloria mentioned it on a phone call eighteen months ago, and Sam wrote it in the delivery notes and remembered.
By 8am, Sam is at the Greenbox office. She switches from warehouse mode to coordination mode: answering emails, updating the delivery dashboard, liaising with the Brisbane courier company about next week’s routing. Between 8 and 10, she handles whatever breaks. Something always breaks. A driver calls in sick. A supplier’s delivery is late. A customer emails to say they’ve moved house and their box went to the old address.
Each problem is small. Each requires a decision. Each decision has a consequence that affects a real person’s Thursday evening. Sam makes dozens of these decisions every day, quickly, with the quiet competence of someone who’s been doing it long enough that the complexity is invisible even to her.
The call Sam doesn’t talk about
Sam was the first person to hear about the allergen incident.
Not Tom. Not Maya. Not the engineering team that would eventually trace the root cause to a cross-squad API change that scrambled customer preference flags. Sam.
Her phone rang at 9:03am on a Wednesday. A customer (Mrs Patterson, subscribed since week three) had opened her box and found capsicum. Mrs Patterson has a nightshade allergy. She’d flagged it in her profile. She’d been promised, by email and by the card inside her box and by the implicit contract of a subscription service that knows your name, that her box would never contain nightshades.
Sam answered the phone. Mrs Patterson wasn’t angry. She was quiet, which was worse. She said, “I’ve trusted you with this.”
Sam apologised. She took down the details. She promised a replacement box by the end of the day. She asked whether Mrs Patterson was okay, genuinely, not as a customer service script, because Sam knew Mrs Patterson’s name and address and preferences and the fact that she’d been loyal since the beginning. Then she hung up and called the warehouse to pull together a replacement box by hand, checking every item against Mrs Patterson’s profile. Then she called the two other affected customers. Then she called Maya.
Nobody celebrated Sam that week. The engineering post-mortem identified the API contract violation and the lack of cross-squad coordination. Tom and Priya built the fix. Charlotte redesigned the cross-squad communication protocol. The technical response was thorough and correct and it got discussed in sprint reviews and written up in an incident response post.
Sam’s response (the phone calls, the replacement boxes, the personal apology to a woman who had trusted the company with her health) didn’t make it into any write-up. It was invisible. It was also the thing that kept Mrs Patterson as a subscriber.
The weight Sam carries
Every delivery failure lands on Sam first. Every courier who doesn’t show up. Every cold chain breach. Every wrong address, every missed time window, every customer who opens their box and finds something they didn’t expect. The engineering team sees these as edge cases in a system. Sam sees them as people whose Wednesday evening was worse because something she’s responsible for went wrong.
She carries this. She carries it in the way she checks her phone before she’s fully awake, scanning for overnight delivery exceptions. She carries it in the way she knows Steve the driver’s daughter’s name (Lily) and the Dandenong depot manager’s coffee order (long black, no sugar). She carries it in the 99% delivery success rate that the team celebrates at sprint reviews without asking what the other 1% looks like from inside Sam’s inbox.
The Customer Support at Scale post tells part of this story: the scaling challenge, the inbox that became a wall of fire, the systems they built to handle volume. But the emotional cost isn’t a scaling problem; it’s a Sam problem. The systems handle the volume. Sam handles the people.
Sam at the retro
Sam attends every retrospective. She sits in the circle with the engineers and the squad leads and Charlotte, and she listens while people talk about deployment frequency and test coverage and CI/CD pipeline improvements. She contributes when it’s relevant: “the courier integration flag is causing delivery exceptions on Wednesdays” or “the new packaging system is adding three minutes per box to the packing time.”
But the retro format isn’t built for Sam’s work. The questions are: what went well? What could improve? What did we learn? The answers are almost always about code, architecture, and process. Sam’s work (the van schedule, the cold chain, the driver relationships, the 4am warehouse checks) doesn’t fit the vocabulary.
She mentioned this to Charlotte once, after a retro where the team spent forty minutes discussing a caching strategy and zero minutes discussing the fact that delivery reliability had improved from 97.2% to 99.1% over the previous quarter. Charlotte heard it. She didn’t fix it immediately. But the next retro included a section called “operational wins,” and Sam presented the delivery data. Tom said, “That’s more impressive than anything we shipped this sprint.” He meant it. It was the first time Sam’s work had been named in a team meeting.
One retro doesn’t fix a structural pattern. But it’s a start.
Jas
Jas Kowalski is the design person. She started as a two-day-a-week contractor in the third week; Sam had seen her portfolio at a coworking space event and pushed Maya to bring her on. Maya’s line was “we don’t need a designer yet,” which lasted until she tried doing the customer experience work herself. Jas went full-time after the Event Storming session. She never looked back.
Jas designed the landing page. The subscription management flow. The box preview emails that go out on Tuesday mornings with a photo of what’s coming and a note about which farm grew it. She designed the physical box: the sticker on the lid, the card inside with recipe suggestions, the “what’s in your box this week” email that customers tell their friends about. She designed the brand.
When customers say “I love Greenbox,” they’re responding to Jas’s work as much as Tom’s code. The subscription engine is invisible to customers. The substitution logic is invisible. The bounded contexts, the decision tables, the event-driven architecture: all invisible. What customers see is a box with a sticker, a card with a recipe, an email with a photo, and a landing page that made them want to subscribe in the first place.
Jas’s work is the experience. Tom’s work is the infrastructure that makes the experience possible. Both are essential. One is celebrated in architecture reviews. The other is celebrated by customers who never know Jas’s name.
The card inside the box
Jas spends two hours every Tuesday writing the recipe card. Not designing it; she designed the template once, months ago. Writing it. She reads the farm availability for the coming week, looks at what’s in each box tier, and writes three recipe suggestions that use the actual produce the customer will receive.
She tests every recipe. Not professionally; Jas isn’t a chef. She cooks them in her apartment in Northbridge on Sunday evenings, adjusting the instructions until they work for someone who has thirty minutes and a reasonable kitchen. The recipes are simple because Jas believes that the produce should be the point, not the technique. “If you need a sous vide machine, the recipe is wrong,” she said once, to nobody in particular, while chopping a sweet potato.
The recipe card is one of Greenbox’s highest-rated features in customer surveys. It’s the thing new subscribers mention most often. It’s also, in every sprint review and product discussion, categorised as “content,” a word that makes Jas’s jaw tighten slightly. Content is what you fill a slot with. What Jas produces is the thing that turns a box of vegetables into a week of meals.
The email that nobody sees
Jas also designed the “what’s in your box this week” email. It goes out on Tuesday mornings to every active subscriber. It contains a photo of the week’s produce, the farm it came from, and a one-line description of each item. It’s the first contact subscribers have with their box before it arrives on Thursday.
The photo is real. Not stock. Jas drives to the Perth warehouse on Monday afternoons and photographs the actual produce for that week. She’s taught herself food photography, not perfectly but well enough that the tomatoes look like tomatoes and the light catches the skin of a stone fruit in a way that makes you want to bite it. She does this in the corner of the warehouse, using a fold-out table and a piece of white card as a backdrop, while warehouse staff move crates around her.
Nobody in engineering knows about the Monday afternoon photo sessions. The email template is in the codebase. The content that fills it (the photography, the descriptions, the careful matching of image to actual produce) is Jas’s invisible work.
The sticker on the lid
There’s a sticker on the lid of every Greenbox. Green circle, white text, the Greenbox wordmark and a line underneath that changes every week. “This week: stone fruit from the Morrison farm, Margaret River.” Or: “Tomatoes from Dave. Third-generation farmer. Same soil since 1962.” Or, in winter: “Root vegetables. Hearty, warm, grown in the dark and ready for your table.”
Jas writes that line. Every week. She writes it in the context of the farm availability data, the seasonal produce calendar, and a personal philosophy about what a sticker on a box should do. “It’s the first thing you see,” she told Maya once. “Before you open the lid. Before you see what’s inside. The sticker sets the tone. If the sticker says ‘produce box delivery service,’ you’re a logistics company. If the sticker says ‘tomatoes from Dave,’ you’re a relationship.”
The sticker costs $0.04 per unit to print. At current volumes, that’s $380 a week. It’s the most cost-effective brand investment Greenbox makes. It’s also the thing that makes subscribers photograph their boxes and post them on social media, which is how 30% of new subscribers find Greenbox. Sam tracks the referral data. Jas sees the photos. Neither of them is credited for the organic growth those photos generate.
The sticker is Jas’s work. The referral tracking is Sam’s data. The engineering team built the subscription pipeline. Nobody connects the three.
What Jas does that nobody notices
Jas also designed the subscription management portal, the page where customers update their address, pause their subscription, adjust their preferences, and manage their billing. She designed it three times. The first version was functional and ugly. The second version was beautiful and confusing. The third version was simple in the way that only comes from understanding what people actually do when they’re standing in their kitchen at 9pm trying to add a delivery note.
The third version reduced support tickets about subscription management by 40%. Sam noticed the drop immediately; it was the first quiet month in her inbox since Melbourne launched. She mentioned it to Maya. Maya mentioned it at a team meeting. Nobody mentioned Jas. The feature was described as “the new subscription portal.” Passive voice, no author.
Jas was in the room. She didn’t say anything. She’s learned that design work is credited to the system, not the designer. The subscription portal works. That’s the recognition. That it works is Jas. That it exists is a product decision. The gap between those two things is the invisible work.
The invisible work pattern
This pattern isn’t unique to Greenbox. Every team has it.
In software, the visible work is code. Pull requests, feature branches, deploy pipelines, architecture diagrams. The work that gets reviewed, merged, and celebrated. The invisible work is everything else. The design that makes the feature usable. The operations that make the feature deliverable. The support that handles the people for whom the feature didn’t quite work. The documentation that explains the feature to the next developer.
The visible work tends to be celebrated with systems. Code reviews. Sprint demos. DORA metrics. Architecture decision records. The work is tracked, measured, and discussed. People know when a feature ships.
The invisible work tends to be celebrated only when it fails. Nobody talks about the 99% delivery success rate until the 1% becomes an incident. Nobody talks about the recipe card until a customer writes in to say the kumara recipe was wrong. Nobody talks about the support inbox until it overflows and a customer gets an angry reply at 2am from someone who’s been answering emails for twelve hours.
This asymmetry creates a distortion. The people who do the visible work feel valued because their contributions are named, measured, and discussed. The people who do the invisible work feel like infrastructure: essential but taken for granted, noticed only in their absence.
The distortion has a compounding effect. Over time, the people who do visible work get promoted, get public recognition, get asked to speak at sprint reviews and team meetings. The people who do invisible work get thanked in private (“thanks for handling that, Sam”) and bypassed in public. The private thanks feel genuine. They are genuine. But they don’t build the same sense of professional identity as a sprint demo where your work is shown to the whole team.
Sam has never been mentioned in a sprint review. Jas has never been asked to present at a product demo. Their work is discussed in the passive voice: “the boxes were delivered,” “the email went out,” “the landing page was updated.” The active voice (Sam delivered the boxes, Jas wrote the email, Jas designed the page) rarely appears.
Making invisible work visible
This is fixable. Not with a grand gesture or a cultural transformation. With small structural changes that make the invisible work as nameable as the visible work.
Sprint reviews that include ops and design. When the Perth squad demos a new feature, Sam demonstrates the operational change that makes the feature deliverable. When Jas redesigns the subscription flow, she walks through the design decisions in the same review where Tom walks through the technical architecture. Same stage. Same audience. Same level of attention.
Metrics that measure customer experience, not just features shipped. Delivery success rate. Customer satisfaction with box contents. Email open rates. Recipe card engagement. These are Sam’s metrics and Jas’s metrics, and they belong on the same dashboard as deployment frequency and lead time.
Celebrating the maintenance, not just the launch. The team celebrates when a new city goes live. It should also celebrate when the delivery success rate hits 99.5% for a quarter. That number represents thousands of boxes arriving on time, at the right temperature, to the right address, week after week. It represents Sam’s work, Steve’s work, the warehouse team’s work, the drivers’ work. It represents the operational backbone that makes every feature launch possible.
Naming the work in retrospectives. The Event Storming session worked because it gave everyone, including Dave and Rachel from the farm side, a way to put their knowledge on the wall. The same principle applies to retrospectives. When the team asks “what went well?” and “what could improve?”, the answers should include operations, design, support, and documentation alongside code and architecture.
Crediting in active voice. A small language change with outsized effect. Not “the boxes were delivered” but “Sam’s team delivered 4,200 boxes this week with zero cold-chain failures.” Not “the landing page was updated” but “Jas redesigned the landing page and conversion improved by 12%.” Active voice names the person. Passive voice erases them. Teams that consistently use active voice for all work, not just code, create a culture where contribution is visible regardless of type.
The craft lesson
The allergen incident is remembered as a technical failure. A cross-squad API contract violation. An architecture problem solved by contract tests and cross-squad coordination protocols. And it was all of those things.
It was also a Sam problem. She was the person who answered the phone. She was the person who heard Mrs Patterson say “I’ve trusted you with this.” She was the person who made the replacement boxes and called the affected customers personally. The technical fix prevented the next incident. Sam’s response preserved the relationship with the customer who experienced this one.
Both responses were necessary. One was celebrated. One was invisible.
What changes when you see it
Something shifts when a team starts seeing the invisible work.
At Greenbox, the shift started small. Charlotte added the “operational wins” section to the retro. Tom started mentioning Sam’s delivery metrics in his sprint review alongside deployment frequency. Jas was invited to present her subscription portal redesign at the same meeting where Priya presented the substitution engine refactor.
The effect wasn’t dramatic. Nobody hugged. Nobody cried. But Sam stood in front of the team and showed the delivery reliability data, a chart with a line climbing from 97% to 99.1% over twelve months, and the room was quiet in the way rooms are quiet when people are seeing something for the first time that’s been there all along.
“That’s 27,000 boxes a month,” Sam said. “Every one of them left the warehouse between 4 and 6am, travelled the cold chain, arrived within the delivery window, at the right address, at the right temperature. Every Thursday. Every week. For a year.”
Tom looked at the chart. “We celebrated when we hit 99% test coverage on the substitution engine. We should have celebrated this.”
“You should have,” Sam said, without edge. Just fact.
Jas presented the subscription portal data the following week. Support ticket reduction, user flow completion rates, the A/B test results from the preference management redesign. She showed the before and after screenshots. She showed the heatmap data: where people clicked, where they got lost, where they abandoned the flow.
“The old portal had a 34% completion rate for preference changes,” Jas said. “The new one has 78%. That’s 44% fewer customers giving up and calling Sam instead.”
Sam raised her coffee cup from the back of the room.
These moments don’t fix the structural pattern. They don’t change the fact that code is tracked in version control and operations is tracked in spreadsheets that nobody reads. They don’t change the fact that architecture decisions are recorded in ADRs and design decisions are recorded nowhere. But they change the story the team tells about itself. And the story a team tells about itself shapes what it values, which shapes who stays.
Sam stayed. She stayed through the inbox wall of fire, through the scaling pain, through every 5:30am warehouse walk and every Thursday evening phone call from a subscriber whose box didn’t arrive. She stayed because the work mattered to her: not the startup equity, not the career trajectory, but the actual work of getting food from farms to families. She stayed because she cared about Steve’s daughter and Gloria’s hip and Mrs Patterson’s nightshade allergy. She stayed because the invisible work was, to Sam, the only work that mattered.
Jas stayed too. She stayed through the third subscription portal redesign, through the Monday afternoon photo sessions in the warehouse corner, through every Tuesday morning spent writing recipe cards that would be read once and recycled. She stayed because design, to Jas, isn’t a deliverable; it’s a relationship between a company and the people it serves. The sticker on the lid, the card inside the box, the email with the farm photo: these are promises. Jas takes promises seriously.
The question every team should ask is: who are the Sams and Jas’s on your team? Whose work holds everything together without appearing in any dashboard? And what would it cost (not in dollars, but in reliability, in brand, in customer trust) if they left?
The answer, usually, is more than anyone expects. Because invisible work is only invisible until it stops. And when it stops, the whole team discovers what was holding them up: not the architecture, not the deployment pipeline, not the sprint velocity.
The person who answered the phone. The person who wrote the recipe card. The person who drove to the warehouse on a Monday afternoon with a fold-out table and a piece of white card.
The Event Storming session where Dave and Rachel brought the farm perspective that nobody else could bring, that was a moment when invisible work became visible. The farmers’ knowledge, their seasonal understanding, their relationships with the land: none of that appears in a codebase. All of it appears on a wall of sticky notes, if someone thinks to invite the people who hold it.
The lesson is simple and difficult. In every team, some work is visible and some is invisible. The visible work shapes the story people tell about the company. The invisible work shapes whether the company deserves that story.
Sam and Jas don’t write code. They don’t appear in architecture diagrams. They don’t feature in technical post-mortems.
They’re the reason the boxes arrive, the brand exists, and the customers stay.
That’s not a footnote. That’s the whole point.