# Ann Diab - Built for People
> Field notes from 15+ years of building and scaling companies: the systems, decisions, relationships, and human work that shape how organizations grow.
Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts.
Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`).
## Pages
### About Me
URL: https://www.anndiab.com/about/
Last updated: 2026-07-10T03:50:35.000Z
**The best organizations aren't built around process. They're built around people.**

That idea has followed me for most of my career.

I've worked in startups, festivals, innovation programs, healthcare, and communities that looked completely unrelated from the outside. Underneath them, I've always found myself drawn to the same questions.

> Why do some teams keep getting better while others stall?

> Why do great ideas spread in one organization but disappear in another?

> What makes someone the person everyone trusts, even when it's not in their job description?

Those questions have led me into all kinds of work: building operating systems for growing companies, helping organizations navigate change, creating knowledge that outlives the people who first held it, and connecting people who end up building something together. The projects change. The curiosity doesn't.

This site is where I collect what I've learned.

Some of these essays were written this year. Others were written more than a decade ago and republished here because the lessons still hold. Together they tell the story of how my thinking has evolved, and just as importantly, the ideas that haven't changed at all.

You'll find reflections on leadership, organizational learning, AI, customer experience, community building, operations, and the invisible work that helps people do their best work. Some posts begin with something that happened to me. Others begin with something I noticed. Nearly all of them end with a question worth carrying into the next conversation.

If there's one belief that connects everything I've written, it's this:

> **People accomplish extraordinary things when they're trusted, connected, and given systems that help them succeed instead of getting in their way.**

That's what I try to build.

I'm glad you're here.

If you're trying to build something that actually works for the people inside it, I'd love to talk. [Find me on LinkedIn](https://www.linkedin.com/in/anndiab/?ref=anndiab.com).

###
## Posts
### Friction Is Information
URL: https://www.anndiab.com/friction-is-information/
Last updated: 2026-08-14T14:08:45.000Z
*What repeated failures, workarounds, and manual dependencies can teach us about the systems underneath our work* 

For years, before I had a name for it, this was my reflex. A leader would come to me with a performance problem - a missed handoff, a metric sliding the wrong way, a team that kept tripping over the same rock - and where most people wanted to talk about who dropped the ball, I wanted to talk about the floor. What is the thing underneath the behavior? What did we build, or fail to build, that made this outcome the likely one?

I never treated a single failure as a single failure. I treated it as evidence that a system was missing or working against us. And I've always believed in building the smallest possible thing to keep it from happening again; sometimes that's a one-line change to a form, and sometimes the small thing pulls a thread that unravels into a much larger question about what capability or enablement the whole function is missing. Both are worth chasing. You just have to be willing to follow the thread wherever it goes.

Once you start looking, the tells are everywhere. The real workflow or operating system may be happening in someone's DMs: the same three questions land on them every week, and they answer every time, because they're generous and because the answer lives nowhere else. Or it's taped to someone else's monitor: a hand-written list of steps, in order, because the tool doesn't carry them and getting the order wrong costs an afternoon. These are the blueprints of missing architecture, drawn for free by the person who feels the gap every day.

## Where the instinct came from

I've been quietly obsessed with hospitals for a long time. The drama, sure; but more so the rigor. I think it started with *ER* in the early aughts. I was committed to Thursday night Must See TV, and capping the lineup was a cozy late-night hour with Dr. Greene, Dr. Ross, Dr. Lewis, Dr. Carter, Dr. Benton, and faves Carol Hathaway and Jeannie Boulet.

Watch enough trauma bays and you notice the protocol never bends to the chaos. A patient comes in with a mangled, bleeding leg, every instinct in the room wants to chase the blood, and the team runs the primary survey anyway - in the same fixed order every single time: airway, breathing, circulation. You secure the thing that kills fastest first, even when it isn't the thing screaming loudest for attention. The sequence carries the priority so an adrenaline-flooded human doesn't have to reinvent it from scratch. And every drug order gets called out and repeated back before it's pushed - "one of epi," "pushing one of epi" - a closed loop so a mis-heard dose can't slip through. These rules can look rigid to the point of absurd up close, but standardizing what shouldn't vary is exactly what frees a clinician to spend judgment on what genuinely does. The system carries the safety so a tired human at 3 a.m. doesn't have to remember to.

Hospitals gave me that vocabulary I didn't know I was looking for: **forcing functions**. Oxygen and nitrous oxide outlets have physically different nozzles, so the wrong gas can't be plugged into the wrong port; feeding tubes use connectors that won't attach to an IV line; a nurse can't pull a medication until the barcode on the drug matches the one on the patient's wristband. None of it depends on anyone being careful. The care is designed into the shape of the thing. You've got to find the place where success depends on a human remembering, knowing, checking, or noticing - and build that dependency into the system instead of hoping for vigilance.

What I love just as much is the second half of that story. The best hospitals didn't stop at rigid protocols. They borrowed from aviation and gave the most junior person in the room the authority to stop the line. A nurse reading a central-line checklist out loud can halt a physician mid-procedure if a step gets skipped - no rank, no retaliation, no waiting. The mature version of a system isn't one that removes all judgment; it's one that knows exactly where judgment belongs and protects the right to use it. Rigid where the stakes are fixed, open where the situation is genuinely new. 

## The mantras I collected along the way

Two phrases have stuck with me, and those in my orbit appreciate and repeat them as mantras.

"Slow is smooth, smooth is fast." (Adapted by multiple productivity gurus since its first uses in the military.) I've watched more projects die from the rush than from the pause. Taking the time to understand the terrain before you move through it isn't the enemy of speed; it's the source of it.

And from James Clear's *Atomic Habits*: "You do not rise to the level of your goals. You fall to the level of your systems." I can't tell you how much this reframed things for me. Goals are wishes with good posture. When the pressure is on and everyone is tired, people don't perform at the height of their ambition; they settle to whatever the system makes easy. So if you want a different outcome, don't give a better speech. Build a better floor.

## Putting a name on it

The first time I saw my own thinking reflected back at me in print was in Donella Meadows' *Thinking in Systems: A Primer*. She writes:

> "You think that because you understand 'one' that you must therefore understand 'two' because one and one make two. But you forget that you must also understand 'and.'"

So much of what goes wrong in organizations lives in the "and" - the connective tissue between two things that each work fine on their own. Onboarding exists and the knowledge base exists, but nothing links the new hire's first week to the answers they'll need. Product ships a feature and Support is ready to help, but no reliable flow carries the change from one to the other, so it rides on someone remembering to mention it. The parts are rarely the problem. The relationships between the parts almost always are.

## Why I've hit the brakes on "good" projects

Understanding the "and" is also why I've stopped improvement projects that were already in motion - which does not always make you popular in the moment. More than once I've looked at a plan that would genuinely fix the thing in front of us and asked what it does three steps downstream. What new friction does this introduce for the team nobody in this room represents? What does the person at the end of this chain now have to absorb that they didn't before? A fix that solves one problem and seeds two others isn't a fix; it's a transfer.

The question I try hardest to get into the room before we ship anything that runs on its own is the least glamorous one: what happens the first time the input is wrong? Automations don't hesitate. They do the wrong thing exactly as fast and as confidently as the right thing, at scale, and they keep doing it until a human happens to notice - which is why the moment to ask is before it's live, not after the cleanup. A tenured engineer once told me he valued that I got things done - but what he really valued was that I asked the hard questions, the ones even he, deep in the system, hadn't thought to ask. I've held onto that, because it names the tension I try to live in: enough drive to actually ship, enough restraint to make sure what I ship makes the whole system healthier and not just this one corner of it.

But you don't always get to pull the brake. Sometimes the question doesn't get asked, or doesn't get heard, and you meet the automation on the other side instead - already live, running clean and confident and wrong.

## Fast and wrong at the same time

I've met that automation on the other side more than once, and the shape is always the same, so let's walk through it. A team is drowning in manual work - enrollments, payments, processed by hand, slowly, one at a time. It's tedious and expensive and everyone can see it, so the obvious move is to automate it. Reasonable. Overdue, even.

But here's what the manual slowness was doing that nobody wrote down: the person doing it by hand was also, without quite naming it, checking one thing against another - is what we're about to pay for what this member actually elected? The drudgery and the check were tangled together in the same pair of hands. Automate the task without the people who understood why it was slow, and you strip the check out along with the tedium. Now the process pulls whatever the carrier's records say is due and pays it - fast, clean, at scale - and never asks whether those records match what the member chose. The day the carrier's records are wrong, the automation does the wrong thing exactly as confidently as the right one, and keeps doing it until a human happens to notice.

The smallest fix is a read-back: put expected next to actual and flag every place they disagree - the same closed loop as "one of epi, pushing one of epi," just with dollars instead of doses. But the better fix is upstream of the code entirely: build the automation with the person who'd been doing it by hand in the room, because they're the only one who knows which part of the slowness was drag and which part was a control. 

The lesson isn't "automation is dangerous." It's the question nobody got to ask: what happens the first time the input is wrong? Because when the records are wrong and nothing's been built to catch it, the payment goes out before anything checks whether it's right. Smooth is not the same as correct; don't sand every bit of friction out of the process and, in the doing, sand off the one piece that is load-bearing.

## Not all friction is the same

A forcing function is friction too, deliberately installed. The mismatched gas nozzles, the barcode that won't scan, the dose read back out loud: every one of those is a small, engineered inconvenience, and every one is there on purpose.

So friction isn't uniformly a symptom. Emergent friction - the workaround, the repeated question, the downstream team absorbing extra work - is the system saying "under-built." Designed friction - the check, the read-back, the step you can’t skip - is the system saying "load-bearing." The whole skill is telling the two apart: pull the friction that's a symptom, and protect the friction that's a control. Get it backwards and you either leave people suffering around a gap, or you "streamline" away the exact step that was keeping someone safe.

So the word to the wise is simple: before you sand a piece of friction away, make sure you know what it was holding up. The step that feels like pure drag is often the one quietly keeping something from going wrong - and you don't find out what it was preventing until it's gone and the thing it prevented shows up.

## The through-line

Whatever the problem in front of me, my mind runs the same route to the floor. Whether I'm redesigning onboarding, building compliance evidence into the flow of ordinary work, moving knowledge off the one overloaded expert, or catching a payment automation that was fast and wrong at the same time - I'm looking for the un-designed dependency and asking whether the coordination can be built rather than remembered.

And I never stop at the moment of execution. A checklist being complete is not the same as a new hire being ready to work on their own. A ticket being closed is not the same as the customer's problem being gone. An automation running is not the same as the correct payment landing. The process executing tells you almost nothing; only the downstream state does. So I design for the outcome and close the loop back to the process, because a system that can't tell you whether it actually worked isn't finished; it's just running.

A customer implementations team once built a metric around onboarding meeting time - shorter was better. I asked why the speed of an onboarding call was the thing we'd want to optimize. They were really trying to find what could be automated when facing a large volume, which was a fair instinct aimed at the wrong target: a rep can win on meeting time by rushing past the very questions that make a customer ready, so the metric will reward the opposite of the outcome. Obviously the more customers we can onboard, the more we grow revenue. But the right question wasn't "Can we optimize on time?" It was "Which parts of onboarding genuinely don't require judgment?"

Which is really a way of saying I've learned to treat friction as information. A repeated question, a manual reminder, a workaround someone built just to survive the day, a downstream team quietly absorbing extra work - none of those are annoyances to route around. Each one is the system telling you where it's under-built. So when something goes wrong more than once, I try not to ask who needs to try harder. I start somewhere else: what does this outcome currently depend on a person remembering, noticing, knowing, translating, or checking? That's almost always where the design has something to tell you.

People are not the point of failure to be engineered out. They're the reason to build the system well. A trained organization teaches people what they're supposed to remember; an enabled one redesigns the environment so they don't have to carry the unnecessary complexity in their heads at all. Get that right and on the hard days, the tired days, the 3 a.m. days, the right thing is also the easy thing - and the humans are freed up for the judgment only they can bring.
### The "Why" Is the Job
URL: https://www.anndiab.com/the-why-is-the-job/
Last updated: 2026-08-13T18:55:02.000Z
### A plea for storytelling in People Operations

Somewhere in the last decade, we stopped asking People teams to explain *why*.

Not on purpose. Nobody voted on it. But go read the job descriptions - Coordinator, Generalist, Business Partner, Director, Head of People. HRIS administration. Benefits renewal. Multi-state compliance. Performance cycle management. Data and reporting. All real, all necessary, all work I've done and will do again.

And almost nowhere, in any of them, the thing that makes any of the rest of it land: **the responsibility to tell the story.**

I want to make the case that this is the most expensive omission in our field right now. Not because storytelling is a nice extra for companies with the budget for culture. Because it is load-bearing, and we have quietly stopped naming the person who carries it.

## Three parts of the job that are already storytelling

**Change management is storytelling.** Every reorg, every merger, every pivot, every layoff. You can send the most accurate memo ever written and still lose the room, because a clear directive is superficial when it lacks context. I've watched a two-hundred-person organization come through a merger, and the lesson was not subtle: people do not need to be told what changed. They need to understand their role in the plot. If you don't give them one, they will write themselves in as the victim - and you cannot blame them, because you left that part blank.

**Policy is storytelling.** A handbook is the document where a company says out loud who it thinks it is. Most of them read like they were drafted to protect the company from its own employees, and employees read them exactly that way. The policy that actually gets followed is never the strictest one; it's the one where the *why* was clear enough to survive the moment when following it is inconvenient.

**Recruiting is storytelling, and we all know it.** You are asking a person to leave something known for something unknown, on imperfect information, usually for comparable money. Nobody makes that trade off a bulleted list of benefits. And the story has to be true, because the candidate becomes an employee and the employee finds out.

Three of the biggest things on the People Operations list, and all three are storytelling problems wearing an administrative costume. We've written the costume into the job description and left the body out.

## What storytelling actually is

Here is where I think the confusion starts. "Storytelling" sounds like a writing skill, so it gets sorted into marketing, or into the soft-skills bin next to "strong communicator."

It isn't a writing skill. It's a finding skill.

I learned it in a tech and startup newsroom, running the same set of questions across a hundred stories a week - because the raw material is always there, and the job is knowing where to look:

- Look for patterns.
- Look for consequences.
- Look for lessons.
- Look for utility.
- Look for vulnerability.
- Look for the future experience.
- Look for the recollection - the thing a person already tells about themselves.

Those questions do not stop working when you leave media. Run them on an engagement survey. Run them on an exit interview, a benefits open-enrollment window, a resignation letter, a Slack channel that went quiet three weeks ago. They get *more* useful in this work, not less, because the stakes get more personal.

That's the craft. It's teachable. It's measurable, if you care to. And it is nowhere on the requirements list.

## Facts don't travel alone

Annette Simmons wrote that stories are "more true" than facts, because stories are multidimensional. An observable fact does not, on its own, communicate a truth. Offer facts without a story and the facts will not be believed.

Every People leader has lived this. You send the announcement. It is accurate. It is thorough. It is also, within about forty minutes, being retold in three DMs in a version you would not recognize.

That's not a failure of clarity. It's a failure of narrative. And here's the practical version, the reason I think this belongs in a job description rather than a values deck: story is the least invasive way to make sure your message gets replayed later, at the right time, along the lines you intended.

You cannot be in every room. You will never be in every room. What you can do is hand people something that holds up when you're not there.

## The part underneath

Storytelling is the visible skill. The one underneath it is empathy - specifically, the kind that supplies context.

A good storyteller stays in touch with, and on the side of, the listener. That's the entire discipline. Not spin. Not polish. Not internal comms as a laundering service for bad news. It's the ability to sit with what someone actually feels on a Tuesday when the roadmap changed for the third time this quarter, and connect them back to work that still means something to them.

I've onboarded seventy people into a fully remote company as the only HR person in it, which means seventy times I was the first real impression someone formed of a place they'd just gambled their career on. That is not an administrative transaction. Every one of those conversations was a person asking, underneath the logistics, *did I make a mistake?* You do not answer that with a checklist.

Ambiguity is the default condition now. It's not a phase companies are passing through on the way back to stability. And in ambiguity, motivation cannot come from certainty, because there isn't any. It comes from people being able to locate themselves in something larger than the week they're having.

Giving them that is the job. Whether or not anyone wrote it down.

## The ask

Put the line back in.

Something like: *owns the internal narrative - the why behind the what.* Six words in a job description, and suddenly the work is visible, ownable, resourced, and reviewable.

Because someone at your company is already doing it. That's the part I want to be clear about. This work does not go undone; it goes unnamed. It falls to whoever happens to be good at it, on top of everything else, uncompensated and unmeasured - and when that person leaves, nobody can quite say what left with them. They just notice that the all-hands stopped landing, and the handbook got a little more defensive, and offers started falling through at a rate no one can explain.

So if you're hiring in People right now, go read your job description and ask whether the thing you need most is written anywhere on it.

If you're a founder wondering why the message keeps arriving distorted, ask who you've made responsible for the why. Not for the announcement - for the why.

And if you've been the person quietly holding the narrative together while your title said something else entirely: you were doing real work. Name it. Ask to be paid for it. I'd love to hear how it's going.
### Great Glue People Make Themselves Unnecessary
URL: https://www.anndiab.com/great-glue-people-make-themselves-unnecessary/
Last updated: 2026-08-13T18:57:15.000Z
*Being the glue is a genuine strength. The most sophisticated thing you can do with it is turn it into something the company keeps after you're gone.*

Every scaling company has one: the person who holds up the walls and the ceiling, who makes sure the right thing happens whether or not it's in their job description. We call them the glue - and lately, rightly, we've started celebrating them. Molly Graham built a whole community around it; "glue person" has gone from a shrug to a title people are proud to claim. I've been that person, and I'll defend the label.

And there's still a version of this story that goes sideways - not because being glue is a weakness, but because it's such a strength that it's easy to get stuck there.

## **When one person becomes the operating system**

Here's what glue quietly becomes if no one is paying attention. The knowledge lives in your head. The decisions route through your inbox. The reason that odd workflow exists is a thing only you remember. Without anyone designing it this way, you've become the company's operating system - the thing everything else runs on.

That's a testament to how much you carry. It's also a fragile place for a company to be. An operating system made of a single human being has failure modes that have nothing to do with how good that human is: you can't take a real vacation because the questions don't stop, work stalls the day you're out, and the bus factor is one. The day the glue person leaves, everyone learns exactly how much of the company lived in their memory - almost always more than anyone guessed.

None of that is a knock on the glue person. It's what happens when an organization leans on a person instead of building the thing the person has been standing in for.

## **The most advanced form of glue is structure**

So the highest-leverage move isn't to hold everything together forever. It's to make the glue *set* \- to take what's trapped in your head and push it out into the organization, into documentation, training, defaults, and shared habits, until the company depends less on any single person, including you.

Molly Graham calls a version of this "giving away your Legos": as the company grows, you hand off the pieces of your job so the whole thing can scale past you. Same instinct here. The glue person's second act is turning glue into infrastructure.

It takes a specific kind of confidence, because indispensability is comfortable - it feels like job security. Building the thing that makes you dispensable feels, at first, like giving away your own value. It isn't. Anyone can become a bottleneck. Very few people can look at the chaos they're personally absorbing and calmly convert it into something the company owns. That second thing is the rare skill, and it's the one worth being known for.

## **Why companies don't see it until it's a crisis**

There's a reason this work stays invisible: it doesn't belong to any department.

Every scaling company generates a category of work that has no home. Onboarding that's suddenly too important to improvise. Knowledge that needs to outlive the conversation it happened in. Manager enablement, quality systems, internal communications, the change management of a company growing up. None of it is cleanly HR, or Operations, or Customer Success, or Product - so it never gets assigned. It accretes onto whoever is capable and nearby. Onto the glue.

I once tried to name this directly - I wrote a proposal for a role that gathered all these scattered responsibilities into a single, deliberate function. The company didn't take it. And that's the tell, not a footnote to it: an organization couldn't recognize a category of work it fully depended on, even with a written definition on the table. The work was load-bearing and unnamed at the same time. Underneath all of it is the same quiet problem - organizations forget. They forget why a process exists, what Legal already answered, what a manager did last time that worked. They forget because the knowledge lives in people instead of in the company itself. Which is exactly the gap a great glue person spends their days closing.

## **AI raises the stakes; it doesn't solve them**

It's tempting to think this is about to be automated away. AI can summarize the meeting, generate the doc, and search ten thousand pages of institutional knowledge in seconds. It can answer the questions that used to require finding the one person who "just knew."

But AI doesn't decide what's worth remembering. It doesn't notice where learning is breaking down. It doesn't build a culture where people share what they've learned instead of quietly reinventing it. Those are organizational design problems - glue-person problems - and they're getting more important, not less. A better search engine on top of a company that never learned how to remember just helps you retrieve the wrong institutional memory faster.

## **What to do with this**

If you lead a scaling company: go find your glue person - the one whose calendar makes no sense - and ask what breaks if they leave. Then treat the answer as a roadmap. Don't just thank them for holding it together; give the work a name, and fund the infrastructure that turns their heroics into something the company keeps. The tell you're looking for is the work you can't slot into an org chart. It's usually the work everything else rests on.

And if you're the glue: your value is real - everyone leaning on you is not in your imagination. Your next level isn't holding more; it's building what you hold into something that outlasts you. Make the glue set. That's not the end of your value; it's the most advanced version of it.

The best glue people don't hold the company together forever. They build a company that no longer needs holding - and then they go do it again somewhere new.
### A Thousand Compliance Boxes, One Individual Plan
URL: https://www.anndiab.com/a-thousand-compliance-boxes-one-individual-plan/
Last updated: 2026-10-14T18:06:25.000Z
*What it takes to help an early-stage company scale in one of the most regulated corners of American healthcare - and why, underneath a thousand federal requirements, the work was always about people.*

Picture the least romantic project you can: a small startup, more than a thousand federal requirements, a security audit, and a government certification program that was never designed for a company like ours. That was my 2024.

I spent it leading our pursuit of CMS Enhanced Direct Enrollment (EDE) certification - the credential that would let us connect directly to the federal health-insurance marketplace and finally scale. On paper, it's an acronym factory. In practice, it taught me the same thing every role I've ever held has taught me: even the most technical, regulated, buttoned-up work is, underneath, a people problem.

A quick orientation, because the domain matters. We administered [ICHRAs - Individual Coverage Health Reimbursement Arrangements](https://blog.healthsherpa.com/ichra/?ref=anndiab.com), where an employer funds a tax-advantaged allowance and each employee buys their own individual health plan. It's a genuinely better model for a lot of people, and it runs headfirst into the most complex machinery in American healthcare: the federally facilitated marketplace (FFM), the state-based exchanges (SBE) some states run instead, fifty states' worth of individual plans, and the alphabet of CMS rules governing all of it. To grow, we couldn't keep enrolling members by hand. We needed to connect to the marketplace directly - which is exactly what EDE unlocks, and exactly what those thousand-plus requirements stand in front of.

## **The build**

While still holding and executing on my official title of Director of People & Culture, I added the hat of Program Manager for our EDE project in early 2024\. This was after a first attempt had stalled - mostly, I think, because no one had grasped the true breadth of the thing. My job was to turn a mountain of federal requirements, security findings, and audit observations into work a small engineering team could actually execute.

That looked like the unglamorous fundamentals, done well. Daily standups across multiple fronts - identity proofing, the application build, the security layer, the consumer communication library. Writing acceptance criteria into every ticket, and researching the scenarios behind them so engineers weren't guessing: how do we handle multiple matches in a person search? When is a dropdown right, and when to use a single-select? Which questions should even appear at this step, and why? I unblocked PR reviews, helped assemble the required toolkits, and built a habit of incremental demos - not only to check the work, but to keep asking the question that actually governs a project like this: how will this be audited?

And there was a wrinkle that made all of it harder. The federal EDE program was built for consumers and agents shopping the marketplace directly. We were something new to it - an ICHRA administrator serving employer-sponsored members. Explaining that nuance to the CMS Direct Enrollment Help Desk, again and again through early 2024, was its own uphill climb; we were asking the government to recognize a use case its own program hadn't been designed for.

## **The regulatory depth**

If you've never lived inside a federal certification, here's the shape of it. To integrate with the Federally Facilitated Exchange, you build and prove out remote identity proofing (RIDP, through Experian), store and retrieve the federal Data Services Hub's reference numbers, verify agents and brokers against NIPR, check eligibility, submit and retrieve enrollments in real time, manage special enrollment periods and data-matching issues, and hand consumers off cleanly for payment - each of those a single line item with pages of requirements behind it.

Then you get audited, twice over: an Operational Readiness Review of the business, and a Security & Privacy Audit against CMS and NIST controls. I owned the documentation that carries all of it - the System Security Plan, the Security Assessment Plan and Report, the Plan of Action and Milestones, the Interconnection Security Agreement - plus the ongoing compliance operations underneath: penetration-test findings, vulnerability remediation, change-management evidence, POA&M submissions.

All of it during a genuine crisis in the market. In 2024, ACA marketplace fraud exploded - bad actors switching people's plans without consent to harvest broker commissions - and CMS responded, rightly, by tightening the rules and turning up scrutiny on every entity that touched enrollment. For legitimate ICHRA administrators, the compliance burden spiked overnight. Knowing that landscape cold - what changed, why, and what it meant for our members - wasn't optional. It was the job.

## **Where it became a people problem**

Here's what surprised me. Most of the conflicts on a program like this look like competing priorities, but they almost never are. They're understanding gaps between groups optimizing for different things. Engineering was focused on what's feasible and shippable. CMS was focused on regulatory and security controls. The auditors needed evidence and documentation. Leadership needed transparency into timeline, risk, and readiness. Four groups, four languages, one project.

So the highest-leverage thing I did wasn't tracking dependencies, though I did plenty of that. It was translation. I had the engineers complete REGTAP training - not to turn them into compliance experts, but so they could see the consumer-protection, privacy, and security intent behind the requirements they were implementing. Once an engineer understands that an identity-proofing step exists because a real person is about to be enrolled in a real health plan, and that fraud at that step can wreck someone's coverage, the requirement stops being bureaucratic friction and starts being the point. I did the same in reverse - helping reviewers and auditors understand the realities of what we were building. Close the misunderstanding, and most of the friction dissolves with it.

That's the thing a thousand federal requirements make easy to forget: every one of them traces back to a human being trying to get covered. Read the regulation for the person inside it, and it stops being an acronym.

## **Then everything scaled at once**

We didn't, in the end, get EDE across the line - we were a novel use case in a program that wasn't built for us, and our timing ran straight into the fraud crackdown. But the work moved CMS's understanding of ICHRA administrators forward, and it left us with a real compliance backbone. 

**And then the ground shifted under all of us: heading into open enrollment, our customer base grew 21x.**

So I changed hats again. From late 2024 into 2025, I stepped in as interim head of insurance operations to stabilize a company suddenly running at many times its previous scale. I started where I always do - a clear-eyed SWOT - then built the execution plan: named owners, real SLAs, and a daily cross-functional operating rhythm to keep product, engineering, operations, compliance, and member services aligned. We re-read the compliance landscape against new legislation, found the manual work engineering could automate away, tightened audit accuracy and the payments cadence against our customer invoicing, and I built the training and enablement that kept a fast-growing team - temporary hires included - consistent under real pressure. The result was a coordinated, high-accuracy operation that met our members' needs through the surge and produced a set of learnings that fed straight back into the product and our resourcing plans.

And - because this is a post on a blog called Built for People, and because it's simply true - I was doing all of that while also being the entire People Operations function. Payroll, benefits, recruiting, hiring, onboarding: one person, me. 

## **What it takes**

People ask what it takes to help an early company scale in an industry this complex. The honest answer isn't a single specialty. It's the willingness to hold a lot of roles at once - project manager, compliance lead, operator, people team, advisor - and the discipline to keep every one of them pointed at the same human outcome.

The rules are real, and you have to know them cold. But the rules are just the shape the care takes. Underneath every requirement, every audit, every late-night remediation ticket, there's a person trying to get themselves and their family covered. Build for them, and the rest is execution.
### Every Second Counts: "Forks," Psychological Safety, and a Culture Worth Preserving
URL: https://www.anndiab.com/every-second-counts-forks-psychological-safety-and-a-culture-worth-preserving/
Last updated: 2026-10-14T18:09:48.000Z
*Amy Edmondson spent years proving that people do their best work where a high bar meets real safety. One episode of The Bear puts that truth in a kitchen - ferocious standards, genuine dignity - and lets you watch it happen.*

There's a plaque on the wall of the restaurant where Richie gets sent in the "Forks" episode of The Bear. It reads EVERY SECOND COUNTS. He arrives convinced he's being punished - exiled to polish forks at a three-Michelin-star place for reasons no one will explain - and he leaves a different person. Not a better manager or host... A person who has found his purpose.

What changes him isn't the forks. It's the culture he's dropped into: a place where the standards are ferociously high and the people are treated with dignity at the same time. That combination has a name in the org world. We call it **psychological safety** \- the sense that you can be stretched, corrected, and held to a real bar without being made to feel small. I've spent years as a student and advocate of psychological safety and healthy culture, and I appreciated this episode for how cleanly the story lands on those ideas. It's the best illustration of them I've seen on television.

The whole restaurant runs on this idea that people don't change in isolation. They change when someone shifts their vantage point and then surrounds them with a culture safe enough to grow in. You see it in more than one character, so let me walk through a few.

## Marcus, and the gift of watching mastery up close

Marcus, the pastry cook, gets sent to Copenhagen to train in a world-class kitchen under a chef named Luca. He's nervous; he's out of his depth on purpose. What he finds there isn't a technique so much as a posture toward the work - patience, obsession, the willingness to make the same thing a hundred times to make it right.

There's a moment when Luca admits he'll never be as good as the best chef he knows, and that he's made peace with it, because the work itself is the point. Marcus comes home with something you can't put on a resume: a bigger sense of what excellence even is.

We rarely give people that. We're so protective of our best talent that we never let them leave the building; we never let them stand next to someone better and feel that productive smallness. A stretch assignment, a secondment, a week shadowing someone two levels up will do more than any training module - they let people recalibrate what "great" looks like, and then they raise their own floor. And notice the trust it takes to send your strongest person away and believe they'll come back more yours, not less. That confidence is a marker of a healthy culture; a fearful one hoards people in place.

## Tina, and the courage to be a beginner again

Tina is my favorite kind of transformation, because it's the hardest one. She's a veteran. She's been on that line for years, and she's earned the right to think she's got nothing left to learn. And the restaurant sends her to culinary school anyway.

Watching a proud, capable, mid-career person walk into a classroom and be a beginner again - striking. It's so easy to write off our tenured people as "set," to pour all our development budget into the new hires and the high-potentials and assume everyone else is who they're going to be. Tina reminds me that some of the biggest returns come from investing in the person who's been loyal for a decade and has never once been asked to grow.

None of that happens without safety. A veteran only agrees to be a beginner again if she trusts she won't be shamed for the things she doesn't yet know. That trust is the whole ballgame. She doesn't just learn knife skills; she gets her confidence back, and that's a retention story and a performance story in one.

## Sydney, and permission to look outside for the answer

Sydney is building the menu, carrying the anxiety of creating something that doesn't exist yet, and she finds part of her answer in a seemingly random book about an athletic coach. Not a cookbook. A book about how someone in a completely different field builds systems, builds trust, builds a team.

The book is *Leading with the Heart* by Mike Krzyzewski - Coach K, the Duke basketball legend - and the show is generous enough to let his ideas actually work on Sydney across the season, not as a throwaway prop but as a thread you can follow.

It starts as a spark when she’s eating at Kasama and a server quotes one of its lines: *“Courage and confidence lead to decision-making.”* Sydney is stuck at that point, half-paralyzed by the fear of repeating an earlier business that failed, second-guessing every plate before it exists. That one idea gives her permission to trust her own palate and stop litigating the past, and you can watch her start to build.

Then it becomes nerve - her turn to quote the book, to Marcus. She paraphrases Duke's 2001 "Miracle Minute" - the comeback where the team was down double digits with a minute left and kept their composure, kept drilling, made fast decisions under impossible pressure. This sets us up to watch Sydney call the shots in the traumatic season finale. 

But back to Forks. The episode opens on real archival footage of Coach K saying, *"Learn how to listen. You're not gonna learn with you just talking."* That's the real key to Sydney's whole arc. The kitchen she inherits is people talking over each other; the kitchen she builds is one where she listens first - to Tina, to Marcus, to the room - and the tone shifts from hostile to collaborative. Listening is a leadership act, and it's the one that makes psychological safety possible. People don't feel safe because you tell them they're safe; they feel safe because you actually hear them.

A healthy culture is what gives someone permission to work that way - to admit she doesn't have it all figured out, to bring in an idea from a world that has nothing to do with food, to experiment in front of people while the thing is still half-built. Where that permission is missing, people default to the safe and the expected, and the safe and the expected is exactly what you don't want from the person designing what's new. The best input for your strategy is often sitting in an adjacent world; you only reach for it when it feels safe to be caught reading outside the lines.

## Richie, and the plaque on the wall

And then there's Richie, which is where the episode lives.

He thinks he's being punished. He shows up at this elegant, intense restaurant convinced he's been exiled, and he's handed a task he finds beneath him: polishing forks. He's 45 years old, and he's polishing forks.

Two things turn him around. The first is purpose. He keeps asking why - why the obsessive care, why the surprise deep-dish pizza for a stranger who mentioned she'd never had one before leaving Chicago. And someone answers him plainly: "Every night, you make somebody's day." That's the mission, stated so a person can carry it in one hand. Not "we deliver exceptional dining experiences." Every night, you make somebody's day.

The second is a value made visible. There's a mantra in that kitchen - EVERY SECOND COUNTS - engraved on that plaque. In the heat of service, the expeditor calls it out while she's already drowning in tickets: "Every second counts!" And no one rolls their eyes. No one hears it as her talking down to them, or reminding them of something they don't know. Of course they know. They still say it, because saying it out loud is how it stays real.

Watch how the standards and the safety hold hands here. That expeditor is demanding; the pace is brutal; the bar never drops. And yet the people under that pressure aren't diminished by it, because respect is the floor everything else is built on. The executive chef peels mushrooms every morning as an act of respect for the work and the room. A member of the team pulls Richie aside not to scold him but to share his own story of falling apart and finding his footing through service. Richie, who walks in defensive and ashamed, keeps getting met with dignity instead of contempt - and that's the exact condition a person needs before they'll risk becoming someone new. He walks out having found his purpose, and it happens to be people; the very thing he was always best at, now pointed at something. He even sings in his car on the drive in, and you believe it.

## A high bar, and a safe floor

Strip away the kitchen and here's the argument the episode makes: high standards and human dignity are not a trade-off. The places that get the most out of people are the ones that ask the most of them and make them feel safest at the same time. Pressure without safety produces fear and turnover. Safety without standards produces drift. "Forks" shows us both, and that's why a man sent to polish silverware comes home reborn.

So I've been asking myself some direct questions, and I'd offer them to you too.

Do the people on your team know your core values well enough to say them out loud on a hard day - and mean it? Can someone on your team be a beginner again without fear of being shamed for it? Do you trust your best people enough to send them somewhere that will stretch them? And is the bar high because the culture is punishing, or high because the culture is safe enough to hold it? That last question is Edmondson's whole thesis in a sentence: the bar and the safety aren't in tension; the safety is what lets the bar stay high. *(If you haven’t ready it yet, let me recommend "The Fearless Organization" by Amy C Edmondson.)*

Every second counts. Every night, you make somebody's day. Those lines land because they name something worth doing and dare you to actually do it - inside a culture where it's safe to try.

Let it rip.
### Nothing About Us Without Us: Bringing ASL to the Festival
URL: https://www.anndiab.com/nothing-about-us-without-us-bringing-asl-to-the-festival/
Last updated: 2026-10-14T18:06:46.000Z
*Real inclusion isn't a form you fill out in advance; it's already there when you arrive.*

Picture this: you're deaf, and a friend texts you at noon - she's got an extra ticket, the headliner's on at nine, come. For most people that's an easy yes. For you it's a no, because the only way to actually experience that set with access was to have emailed the festival thirty days ago to request an interpreter. The spontaneity that makes live music magic - changing your mind, following a friend, discovering someone you've never heard of - was never offered to you.

That was the system I inherited in the summer of 2019 when I looked at how our festival served deaf and hard-of-hearing fans. The more I sat with it, the more it bothered me. So I built the case to change it. Here's the thinking, and the work it actually took.

## The illusion of access

The moment I put that thirty-days-notice rule next to how we handle other access needs, it fell apart. We don't ask a wheelchair user to email ahead and specify which sidewalks and doorways they intend to use so we can lay out ramps in advance. The ramp is just there, because access that has to be requested, justified, and scheduled weeks out isn't really access - it's the illusion of it.

The principle I kept coming back to is simple: clear is kind. True access means a deaf fan can buy a ticket whenever they want, with all the information in front of them, and decide in the moment which set to catch - exactly like everyone else in the crowd.

There's a deeper reason this particular community keeps getting left out: theirs is a nearly invisible disability, and they're often missing from the accessibility conversation entirely - when the ADA was written, the Deaf community largely wasn't at the table. There's a phrase from disability advocacy I couldn't stop thinking about: *nothing about us without us.* If we were going to do this, the plan itself had to be built with Deaf expertise at the center - not designed for the community from the outside.

## What real access actually takes

This is the part I care about most, because conviction without a plan is just a nice sentiment. I didn't bring leadership a feeling; I brought an operational plan with a budget.

The core insight is that performance interpreting is a craft, not a utility - nothing like the interpreter you'd get at a doctor's appointment. A performance interpreter studies the artist's catalog, learns the lyrics, absorbs the mood, and works with the Deaf community to understand how slang and brand-new terms get signed, so they can carry not just the words but the electricity of the show. That prep is exactly why festivals default to "request it 30 days ahead." It feels logical. It still fails the audience.

The fix was to staff for it on purpose. The plan hired an Interpretive Services Coordinator sixty days out - an interpreter themselves, connected to the Deaf community - to recruit and schedule a qualified team, coordinate with booking to get set lists early, and problem-solve the odd cases. Crucially, the team included a Certified Deaf Interpreter: a Deaf person, native in the language, serving as a linguistic mentor to the hearing interpreters. *Nothing about us without us*, built right into the staffing.

Then the details that separate real inclusion from a checkbox: placing interpreters where deaf fans could see the performer and the interpreter while standing in the crowd near the sound - not exiled to a far-off ADA platform; wiring interpreters with earpieces for live audio; offering assisted listening devices for hard-of-hearing fans; giving artists the option to meet their interpreter beforehand; and training security, staff, and emergency teams to communicate across the whole audience. It added up to a real number - roughly $38,000 - which I set next to a real business case: a conservative projection of incremental tickets from fans who'd finally been invited, plus the goodwill and press that come from leading instead of merely complying.

## Why it's worth it - and where the industry went

The objection I heard most was the money. But "that's a lot" only sounds decisive until you weigh it against what you're actually buying: not a legal box checked, but a community welcomed, a field full of other attendees watching you make belonging visible, and a reputation as the festival that did it right. Belonging creates joy, and joy is the entire product.

I am overwhelmingly proud and amazed at how fast the ground shifted from there. Since around 2019, this stopped being a bold ask and started becoming table stakes - most major festivals now build ASL interpretation into their headline sets as a matter of course, covering at least the top acts each day rather than leaving deaf fans to file requests and hope. The thing that once needed a whole persuasion deck is increasingly just how it's done.

That's usually how inclusion goes. It looks expensive and radical right up until it looks obvious. The organizations worth working for are the ones willing to be early - to design access in from the start instead of waiting to be asked.
### When the Festival Couldn't Happen, We Built Founders Instead
URL: https://www.anndiab.com/when-the-festival-couldnt-happen-we-built-founders-instead/
Last updated: 2026-08-13T19:12:03.000Z
*When the environment changes, the organizations that thrive aren't the ones waiting for normal to come back - they're the ones willing to learn, adapt, and build.*

In early 2020, the world - and our proud local Las Vegas community - faced new challenges. [Life is Beautiful](https://web.archive.org/web/20190630183932/https://lifeisbeautiful.com/about/) existed to inspire and transform communities, and the way we did that - a large-scale music and arts festival - was suddenly, painfully unlikely to happen. When your whole reason for being is gathering tens of thousands of people in one place, and gathering is the one thing you can't do, "wait and see" stops being a strategy.

So leadership put a challenge to the team: if live events stayed impossible, how else could we serve our community and create value? We'd already been exploring ways to grow beyond the annual festival; the disruption just turned that slow exploration into something urgent. This is the story of what we built in response - and the lesson it left me with.

## The challenge nobody wanted, and the opening inside it

There's a specific kind of fear that comes with watching your core product become unviable overnight. The honest thing is to name it: people were worried about their jobs, their industry, and whether the thing they were good at still mattered. But underneath the fear was a real opening. A community full of people who knew how to produce extraordinary experiences suddenly had time, talent, and a powerful reason to point those skills somewhere new.

I didn't want us to spend that moment waiting. I wanted us to spend it learning.

## So I built the system that could teach it

In response, I designed and launched **Innovation Hive**, a workforce reskilling and innovation program built on the principles of design thinking. And I made a deliberate choice early: this couldn't be a one-time workshop that evaporated the day it ended. It needed to be a living system people could actually move through. So I built one, end to end, in Notion - not a folder of links, but a structured resource library that worked like a real innovation pipeline.

Here's how it was designed to work.

**An idea funnel, in tiers.** Rather than dropping people straight into "go start a business," the Hive moved ideas through stages - a first tier focused on *clarifying* (understanding the customer, the problem, the assumptions) and a second tier focused on *validating* (modeling the business, testing against real success criteria). Each tier had its own curated toolkit, so people always knew what the next right step was instead of staring at a blank page.

**Roles, so everyone had a way in.** This was the part I'm proudest of, because it solved the real problem. Most participants came from hospitality, events, and production - not lean startups - so I built a set of roles people could step into based on strengths they already had: someone to own the objective, someone to chase down research, someone to translate strategy into a deliverable, someone to coach others' "innovation muscle," someone to keep communication flowing across teams. One person could move through several roles over time. It reframed the whole thing: you didn't have to become a different person to contribute; you had to recognize where your existing talent fit.

**A development guide sequenced like a curriculum.** The library walked people through the actual arc of building something - starting with mindset (adaptability, resilience, the honest question of whether an organization can even learn), then personal development, then how to give and take feedback and defend a new idea without getting defensive, then ideation (understanding a customer's real "job to be done," running "How Might We" exercises, making sure you're solving the right problem), and finally forming a hypothesis you could actually test.

**The best outside thinking, plus tools I built myself.** I curated the strongest external material I could find - design thinking from Harvard Business Review, Jobs-to-Be-Done, the Business Model Canvas, Value Proposition Design, the PRFAQ method - and then I built custom worksheets tailored to our people: idea-exploration guides, empathy-interview templates, a one-page business plan, brainstorming and audience-interview frameworks. Curation meets translation; the point wasn't to show people the canon, it was to make the canon usable by someone whose last job was running a stage.

To put all that into practice, I partnered with our Festival Director and with organizations including Zappos, and we ran a [Zappos-inspired event called **48 Hour Founders**](https://www.nienkebloem.nl/en/the-avocado-story-and-27-other-reasons-why-zappos-rocks-in-customer-experience-2/?ref=anndiab.com), inspired by Startup Weekend - teams formed, researched real opportunities, developed concepts, and pitched them, using the exact tools the library had been teaching.

## What came out of it

Several teams pushed past the workshop stage into something real. One became a venture called **Life is Beautiful Consulting** \- a group proposing to help hospitality organizations, event producers, and public-sector clients prepare to reopen under evolving health and safety requirements. Exactly the kind of expertise our people already had, aimed at exactly the problem the moment had created. They used the customer discovery, market research, and business development techniques the Hive had introduced to go after clients and investment.

I'm proud of this one because it turned a period of pure uncertainty into a period of experimentation. Instead of waiting for normal to return, we built a framework - and a real library behind it - that helped people explore opportunities, build new capabilities, and test their ideas while the ground was still shifting.

It reinforced something I've watched hold true across my whole career: when the environment changes, the organizations that thrive are the ones willing to learn, adapt, and build - and the fastest way to become one of those organizations is to give your people a real system and a place to start.
### The Year My Network Became a Strategy
URL: https://www.anndiab.com/the-year-my-network-became-a-strategy/
Last updated: 2026-08-13T18:51:49.000Z
*How I drew Revelry and the Startup of the Year community into the same rooms in 2018–2019 - and turned that overlap into stages for our people and a whole new New Orleans conference.*

In 2018 I was Head of Communications and Culture at Revelry, a New Orleans software company. Then some of my closest friends - former colleagues at a consultancy called Established - called with a problem I'd helped them solve before. They run Innovate Celebrate, a conference that does something unusual on purpose: it puts the corporate innovation world (executives from the Consumer Technology Association, the people behind CES) in the same room as the startup world (the founders, funders, and operators in their Startup of the Year community). Two audiences that rarely mix, deliberately mixed. I'd contributed to their programs before, and they needed me again.

The obvious problem: I already had a full-time job. The interesting move was refusing to treat that as a conflict.

## **Staff augmentation, pointed the other way**

One of Revelry's many innovation tools is staff augmentation - embedding its people inside other companies' teams to help them build. So I proposed the same model, aimed back at us: I'd run the mentorship program for Innovate Celebrate under a staff-augmentation arrangement, and in return Revelry would earn brand recognition and relationships inside two communities it very much wanted to be part of. Instead of choosing between my employer and my friends' event, I wired them together so that work for one created value for the other.

It worked. Innovate Celebrate in Boston, October 2018, was a genuine success - and Revelry's name traveled with it, into rooms full of exactly the corporate innovators and founders the company was built to serve.

## **Thought leadership isn't a company on a stage - it's a person**

That success changed how I thought about visibility. A logo on a sponsor banner does very little; a specific person saying something sharp to the right audience does a great deal. So I stopped thinking about "getting Revelry noticed" and started matching individual people on our team to the exact rooms where they'd be taken seriously.

It became a real practice. I helped one of our staff engineers, Emily A, shape and land a talk at JSGeo in Austin - taking a deep, specific skill and making it legible to a general web audience. I worked with our VP of Product, Josh F, to build a workshop with a point of view baked right into the title - "Design Thinking, not Design Doing" - and then hunted down the meetups and conferences where he could keep delivering it. When our CEO went to pitch a Startup Studio venture, *Incentivize*, at Slush in Helsinki, I built the script and the deck. And when one of our senior engineers, Bryan J, helped launch a whole new conference of his own - The Big Elixir - I was a sounding board through it.

Alongside the stages, I ran the quieter brand work that makes those stages land: editing every post on our blog for years, and placing the company and its founder where it counted - our CEO into the Forbes Technology Council, Revelry onto the Inc. 5000\. Thought leadership, it turns out, is less a broadcast than a casting process: the right person, the right room, the right idea, again and again.

## **Building our own room**

Meanwhile, Revelry's Startup Studio wanted a conference of its own - workshops for founders and engineers, an event that furthered the studio's business. We were sketching a modest open-innovation hackathon when the ground shifted. In early 2019, we learned from New Orleans' travel and tourism bureau that Collision - the major international tech conference that had called the city home for several years - was leaving the United States for Canada.

That was a gap, and gaps are opportunities. We scaled the idea up fast, into a full conference meant to fill the void Collision left behind. We called it [INNOConf](https://web.archive.org/web/20191119145309/https://revelry.co/innoconf-tech-conference/) \- a name that folded together *innovation* and *In NO*, as in New Orleans.

This is where "helped organize" stops being a modest phrase. I launched the framework hiring the conference director and staff, choosing the event platform, building the sponsor decks and communications plans, inviting speakers and structuring the content tracks - the major decisions and the thousand minute ones. I worked alongside our executive director, Sloan M, to shape the full agenda, and I designed and edited the web presence that told the world it was happening. Josh F's ["Design Thinking, not Design Doing"](https://innoconf.com/design-thinking-workshop-inno/?ref=anndiab.com) workshop - the one I'd helped him build for the road - became part of the program, which is the whole model in miniature: the thought leadership I'd been cultivating for our people turned into content for the conference we were building.

We brought the partnership full circle, too. Established's Startup of the Year showcase - the same community that started this entire thread - [joined INNO as a public pitch competition](https://innoconf.com/inno-startup-showcase/?ref=anndiab.com). The conference landed between the two weekends of Jazz Fest, with speakers drawn from Facebook, Uber, Twitch, Timehop, Trulia, and FanDuel. Only-in-New-Orleans, by design.

## **What I was actually doing**

On paper, that stretch looks like a pile of unrelated work: a communications role at a software company, a mentorship gig at someone else's conference, a habit of scouting stages, and a startup studio's event that mutated into a citywide tech conference.

In practice it was one job. I was the connective tissue between two innovation communities that were stronger together than apart - and I kept turning that connection into something concrete: the right stages for Revelry's people, partnerships for Established's community, and eventually a whole conference for a city that had just lost one. 

The most valuable thing I did across those two years wasn't picking a side. It was building the bridge - and then walking our people across it.
### Trust Is the Whole Job
URL: https://www.anndiab.com/trust-is-the-whole-job/
Last updated: 2026-08-13T19:12:24.000Z
Revelry is a New Orleans software company, and it has something a lot of "remote" companies don't: a real office, and a genuinely good in-person culture to go with it. What makes it interesting is that the culture is built to scale past any single room. People collaborate in writing, meet in shared "conference rooms" whether or not they're in the same building, and treat distance as a design problem to solve rather than a reason things quietly fall apart. And the work is broader than it looks - Revelry builds software, but it also embeds its own people inside other companies, from startups to enterprises, to help them launch, scale, and innovate.

Run a company that way - part in-person, part distributed, part inside other people's teams - and proximity can't be the thing that holds it together. Trust is. My work lives right there: taking a culture that could easily stay tacit and making it explicit, writing down how we operate so the next person can step straight into it instead of absorbing it by osmosis over months.

Here is how it actually works.

## **We start with trust**

At Revelry, trust is where we begin, not where you arrive once you've earned it. Distributed work exposes whatever your culture already is - if you didn't trust people in a room, distance only magnifies it - so we start from the assumption that people want to do good work and can be trusted to decide how. That single premise is load-bearing; everything else is built on top of it. It's why, when we talk about remote-work friction, our answer isn't more oversight - it's [a culture of trust](http://web.archive.org/web/20211124132520/https://revelry.co/resources/remote-work/remote-work-challenges-1/).

## **We decide what to build before we build it**

Being trusted to work doesn't mean racing to build the wrong thing. Before we commit, we get deliberate about the problem - who has it, what it actually is, and whether the thing we're tempted to build is the thing that needs building. That is the discipline of [design thinking](http://web.archive.org/web/20220126000000/https://revelry.co/process/design-thinking/): understand the problem before you fall in love with a solution.

## **We build in small, honest loops**

Then we build in a rhythm rather than a sprint to exhaustion. Small pieces, shipped, reviewed, adjusted - a [lean, agile process](https://revelry.co/lean-agile/?ref=anndiab.com) that keeps the work visible and the feedback constant. Progress you can see beats heroics you can't sustain.

## **We work in the open**

Distributed work only functions if communication is intentional, so we do ours in the open and mostly in writing - in Slack, including with our clients and partners. The channel is the shared memory; decisions live where everyone can see them instead of inside one person's inbox. It sounds simple and it isn't, which is why we're specific about [our how and why](https://revelry.co/insights/management/slack-communication/?ref=anndiab.com). Setting those norms and keeping them written down is a good deal of what I do here.

## **We're honest about what remote can't do**

We're believers, not romantics. Remote has real limits - the half-formed idea that never gets caught, the ambient sense of "how things are done here" that a new person can't pick up through a screen - and pretending otherwise is how teams quietly wear down. So we name the limits and design around them on purpose, [recognizing and adapting to them](http://web.archive.org/web/20220125225412/https://revelry.co/resources/remote-work/remote-work-challenges-2/) rather than wishing them away.

## **We protect the life outside the work**

And we guard the part of a person that doesn't belong to the company. On a distributed team the edges of the day blur, and "always reachable" becomes the unspoken default unless you push against it deliberately. We treat rest, boundaries, and a real life as inputs to good work rather than threats to it - a [strategy for work-life alliance](https://revelry.co/resources/remote-work/remote-work-challenges-3/?ref=anndiab.com), not a slogan about balance.

## **How it holds together**

Put it side by side and this is the company as it runs: trust first, the right problem before the fast solution, the work shipped in small loops and kept in the open, the limits of remote named out loud, the people protected from the job that could otherwise swallow them. None of it holds together on its own. 

Someone has to keep it written down, keep it teachable, and keep passing it to the next person who joins - and right now, that someone is me.
### My Best Work Is Other People's
URL: https://www.anndiab.com/my-best-work-is-other-peoples/
Last updated: 2026-08-13T19:18:48.000Z
*The most valuable thing I do usually isn't my own work - it's getting the people around me to believe theirs is worth sharing.*

## **The apology that comes with the draft**

An engineer sends me a blog post and apologizes for it before I've read a word. *"It's probably too in-the-weeds,"* they say. *"I'm not really a writer."*

What they've actually handed me is a hard-won lesson from building software - the kind of thing another engineer, three cities away and stuck on the same problem, would give a lot to read. The writing needs work. The insight doesn't; it never did.

I've spent my career on that gap: the distance between what someone is capable of and what they believe they're allowed to put their name on. Capable people count themselves out. My job is getting them to count back in.

## **Everyone had a story worth publishing**

At Revelry, I was the managing editor - which sounds like a job about words. It was really a job about permission.

I built the editorial engine so that every person on the team, not just leadership and not just the self-identified "writers," could document what they were learning as they built. We tracked ideas in the open. I kept the calendar. And mostly, I convinced engineers who were sure they had nothing to say that they were sitting on exactly what our audience needed.

Then I edited. A draft that arrived moderately useful went out as something that could genuinely change another builder's path. One of my teammates put it better than I could:

*"She is an amazing editor and many times turned my own blog posts from moderately useful to well thought out content pieces that had the ability to impact other people's journeys in building software. Her strong communication skills made her a joy to work with by making everyone around her better."*

**"Making everyone around her better."** That's the part I'm proudest of - not my byline, theirs.

## **The mic goes to the people who won't grab it**

As part of the senior leadership team, I owned the quieter version of the same work: internal communications, employee experience, and building real career pathways so people could see a future for themselves inside the company.

I paid particular attention to the people who don't raise their hands. I became a kind of voice for the team, especially our underrepresented engineers - rolling out one-on-ones and personal-development follow-ups so that being quiet never meant being overlooked.

And when there were stages to be had, I didn't reserve them for executives. I found conference talks for contributing engineers, wrote their speaker bios, shaped their scripts, and pointed them at the rooms where their specific expertise would land. The move was always the same: find a person who counts themselves out, and hand them the microphone.

## **The same move, at ecosystem scale**

Eventually I was doing this between whole organizations. I managed partnerships across open-source and innovation communities - the Open Source Summit, the Enterprise Ethereum Alliance, the Linux Foundation, GAN, regional economic-development groups - drawing people and institutions into the same rooms to create value none of them could build alone.

When Collision left New Orleans, I helped conceive and execute INNO to fill the void, convening a citywide conference out of a network of relationships. And by 2022, I was aiming the same move at small businesses and government innovation programs - convincing a manufacturer that the Air Force wanted their technology, or that a NASA solicitation was describing, almost exactly, the thing a founder had been building for years.

Different logos, different scales, one job underneath: closing the distance between a capable person and a room that was already theirs.

## **The real work is belonging**

The visible version of all this looks like editing, communications, events, and partnerships. The real version is belonging. An organization - or an ecosystem - isn't a stack of programs and outputs; it's a group of people who believe they're allowed in, and allowed to speak.

Most of what limits a team isn't a missing skill. It's a capable person who ruled themselves out before anyone got the chance to say yes. I've spent my career on that side of the ledger: not inventing the opportunities - those already existed - but handing people the microphone, and the permission to walk up and use it.

Make the people around you believe they belong, and they get better. So does everything they build.
### Giving Up Your LEGOS: Your Ever-Changing Role in a Growing Organization
URL: https://www.anndiab.com/giviyour-ever-changing-role-in-a-growing-organization/
Last updated: 2026-07-08T18:38:05.000Z
[Molly Graham](https://mollyg.substack.com/about) has spoken about how important it is to “[give away your job](http://web.archive.org/web/20211028014021/http://firstround.com/review/give-away-your-legos-and-other-commandments-for-scaling-startups/)” every couple of months in growing organizations.

She eventually turned this into one of the most amazing and life-changing talks I’ve ever experienced at a conference. I had an absolute Hallelujah moment when Molly presented [9 Things I Wish Someone Had Told Me About Working Inside A Scaling Organization](http://web.archive.org/web/20211028014021/https://www.youtube.com/watch?v=dT5qGrf-f34). 

I realized that rather than worrying about my job title, I knew the most important thing was this: *just be useful.*

[*Your Ever-Changing Role in a Growing Organization*](http://web.archive.org/web/20211028014021/https://revelry.co/resources/growth/role-growing-organization/)

[Your Ever-Changing Role in a Growing OrganizationHow do you establish your roles and responsibilities in a growing organization? It might be more helpful for you to develop these skills instead.![](https://static.ghost.org/v5.0.0/images/link-icon.svg)RevelryAnn Diab![](https://revelry.co/wp-content/uploads/2017/11/growing-organization.gif)](http://web.archive.org/web/20211028014021/https://revelry.co/resources/growth/role-growing-organization/)
### Building, Testing, and Marketing Your Side Project
URL: https://www.anndiab.com/building-testing-and-marketing-your-side-project/
Last updated: 2026-07-08T18:37:31.000Z
As a maker, you’re constantly working to build products and solutions that help realize other people’s ideas. It’s time to take your side project past the idea stage and into the process of validation. And you can do it, too: You don’t need a team (yet).

Entrepreneurs might have no shortage of ideas, but ideas require validation to get them to the point where it actually makes sense to build a product. This guide is aimed at helping you build, test, and market your side project without needing a team or a lot of capital.

[*Building, Testing, and Marketing Your Side Project*](http://web.archive.org/web/20211028022655/https://revelry.co/resources/product/validate-your-side-project/)

[Building, Testing, and Marketing Your Side ProjectIt’s time to take your side project past the idea stage and into the process of validation. And you can do it, too: You don’t need a team (yet).![](https://static.ghost.org/v5.0.0/images/link-icon.svg)RevelryAnn Diab![](https://storage.ghost.io/c/87/ce/87ce99ad-8207-47ff-a1bd-04d2b6723eb1/content/images/thumbnail/side-project-4f060d66-6e36-4e7e-bfbd-fe8cee5e5c60.jpg)](http://web.archive.org/web/20211028022655/https://revelry.co/resources/product/validate-your-side-project/)
### 9 Ways to Collaborate Without Scheduling Meetings
URL: https://www.anndiab.com/9-ways-to-collaborate-without-scheduling-meetings/
Last updated: 2026-07-08T18:23:33.000Z
Published on Piktochart - nine ways to collaborate without constantly scheduling meetings.

[https://piktochart.com/blog/collaborate-without-meetings/](https://piktochart.com/blog/collaborate-without-meetings/?ref=anndiab.com)
### 5 Flexible Work Strategies as the  Sandwich Generation Continues to Grow
URL: https://www.anndiab.com/5-flexible-work-strategies-as-the-sandwich-generation-continues-to-grow/
Last updated: 2026-07-08T18:19:40.000Z
They call us [“The Sandwich Generation”](https://en.wikipedia.org/wiki/Sandwich%5Fgeneration?ref=anndiab.com) —the group of workforce-aged adults who are not only caring for their aging parents, but also balancing the needs of their own children.

Published on Buffer's blog - [https://buffer.com/resources/flexible-work-strategies/](https://buffer.com/resources/flexible-work-strategies/?ref=anndiab.com)
### You Don't Need a Clock to Know You're a Badass
URL: https://www.anndiab.com/you-dont-need-a-clock-to-know-youre-a-badass/
Last updated: 2026-07-08T18:36:44.000Z
If you know the desired outcome, there can’t possibly be a correlation between hours spent and value added. The value is there, or it is not.

You can roll up all of the productivity advice from all of the masters, and I just don’t see time tracking as a functional part of a fruitful process.

Certainly, if you intend to only perform a task for the next 30 minutes, set that timer! My challenge is in the tracking of that time as if the rollup of hours is anything but distracting.

[*You Don’t Need a Clock to Know You’re a Badass*](https://medium.com/work-together/you-don-t-need-a-clock-to-know-you-re-a-badass-62df6822e16f?ref=anndiab.com)

[You Don’t Need a Clock to Know You’re a BadassWhat would happen if we focused more on the deliverable than on the time?![](https://storage.ghost.io/c/87/ce/87ce99ad-8207-47ff-a1bd-04d2b6723eb1/content/images/icon/5d8de952517e8160e40ef9841c781cdc14a5db313057fa3c3de41c6f5b494b19-d629f743-209e-4bb7-9d62-cb136df9f2cd)Work TogetherAnn Diab![](https://storage.ghost.io/c/87/ce/87ce99ad-8207-47ff-a1bd-04d2b6723eb1/content/images/thumbnail/1-53bQf1t9uEBCUrNWXW5qSw-99e38117-6033-4db1-8bf9-4daae44c70c8.jpeg)](https://medium.com/work-together/you-don-t-need-a-clock-to-know-you-re-a-badass-62df6822e16f?ref=anndiab.com)
### You Don’t Need Meetings to Collaborate with your Team
URL: https://www.anndiab.com/you-dont-need-meetings-to-collaborate-with-your-team/
Last updated: 2026-07-08T18:36:16.000Z
Interruptions and distractions are all around us. Even if no one is asking you for updates or springing requests on you, let’s admit it: you interrupt yourself every 10 minutes to check your email or refresh your social notifications. 

[*You Don’t Need Meetings to Collaborate with your Team*](https://medium.com/work-together/you-don-t-need-meetings-to-collaborate-with-your-team-4e1f6b0dc2da?ref=anndiab.com)

[You Don’t Need Meetings to Collaborate with your TeamPeople who enjoy meetings should not be in charge of anything. -Thomas Sowell![](https://storage.ghost.io/c/87/ce/87ce99ad-8207-47ff-a1bd-04d2b6723eb1/content/images/icon/5d8de952517e8160e40ef9841c781cdc14a5db313057fa3c3de41c6f5b494b19-e60ad260-2063-4b74-bef1-e4ad87d57234)Work TogetherAnn Diab![](https://storage.ghost.io/c/87/ce/87ce99ad-8207-47ff-a1bd-04d2b6723eb1/content/images/thumbnail/1-2PnYkEYo2HrLexp8rs62VQ-711eb527-ce35-41ff-b204-9896384e7df9.jpeg)](https://medium.com/work-together/you-don-t-need-meetings-to-collaborate-with-your-team-4e1f6b0dc2da?ref=anndiab.com)
### Why your Employees Will Never Tell you They're Unhappy
URL: https://www.anndiab.com/why-your-employees-will-never-tell-you-theyre-unhappy/
Last updated: 2026-07-08T18:35:21.000Z
You’re an open-minded, easy-to-approach manager. You get along well with your team, and no one seems to have any complaints. You’re pretty sure that your non-scary demeanor would invite confidential sharing of problems, and since you haven’t heard about any, then the team is probably sailing along pretty happily. *Right?*

I hate to be the one to tell you this, but if you’re not hearing about *any* problems, then there are definitely problems afoot. [*Why your Employees Will Never Tell you They’re Unhappy*](https://tech.co/news/why-employees-are-unhappy-at-work-2015-08?ref=anndiab.com)

[Why Employees Are Unhappy at Work and Won’t Tell YouIf you want your business to grow and succeed, it’s up to you to find out why your employees are unhappy at work.![](https://storage.ghost.io/c/87/ce/87ce99ad-8207-47ff-a1bd-04d2b6723eb1/content/images/icon/favicon-32x32-0bd40c59-0d13-4302-ace9-1a1961f69c63.png)Tech.coAnn Diab![](https://storage.ghost.io/c/87/ce/87ce99ad-8207-47ff-a1bd-04d2b6723eb1/content/images/thumbnail/employee-engagement-e1454618801646-640x362-47ccf0d5-109c-4452-9d08-860da138ebd2.jpg)](https://tech.co/news/why-employees-are-unhappy-at-work-2015-08?ref=anndiab.com)
### Working a 60 Hour Week Results in Negative Productivity
URL: https://www.anndiab.com/working-a-60-hour-week-results-in-negative-productivity/
Last updated: 2026-07-08T18:34:42.000Z
At [Future Insights Live](https://futureinsightslive.com/las-vegas-2015/?ref=anndiab.com) in Las Vegas, [Jason Lengstorf](https://jason.energy/?ref=anndiab.com) presented “Happy People Do It Better: A look at work-life balance and long-term productivity” to a packed room of developers and designers interested in striking a balance.

### The qualities we like most about ourselves are being turned against us

No one is meant to survive the cult of working harder to get ahead. Overwork kills passion and engagement. Overwork hurts companies with higher turnover. In order to change, the people at organizations must lead the shift. [*Working a 60 Hour Week Results in Negative Productivity*](https://tech.co/news/future-insights-jason-lengstorf-productivity-2015-06?ref=anndiab.com)

[Working a 60 Hour Week Results in Negative Productivity - Tech.coAt Future Insights Live, Jason Lengstorf presented “Happy People Do It Better: A look at work-life balance and long-term productivity” to achieve balance.![](https://storage.ghost.io/c/87/ce/87ce99ad-8207-47ff-a1bd-04d2b6723eb1/content/images/icon/favicon-32x32-bd71a902-96ee-4067-aba8-5cee0c7311a4.png)Tech.coAnn Diab![](https://storage.ghost.io/c/87/ce/87ce99ad-8207-47ff-a1bd-04d2b6723eb1/content/images/thumbnail/overwork-640x361-429e4e9b-2442-4500-a9c2-de9af78851e1.jpg)](https://tech.co/news/future-insights-jason-lengstorf-productivity-2015-06?ref=anndiab.com)