What 'People Come First' looks like in practice

Every firm's website says people come first. The sentence costs nothing, which is why it's everywhere. So rather than argue that we mean it, I'd rather explain what the commitment is actually for, because it has a job, and the job isn't decoration.

A value earns its keep in the moments when two good things collide and one of them has to lose. Speed or dignity. Margin or trust. This quarter's revenue or this engineer's health. When that happens, someone has to make a call, usually quickly, usually without me in the room. "People come first" is the tie-breaker. It means nobody at Sigao has to guess which way the firm wants them to lean.

The research caught up to the intuition

For a long time, "take care of people and the work takes care of itself" sounded like something you'd cross-stitch on a pillow. Then the data started piling up.

When Google went looking for what separated its best teams from the rest, in a multi-year study that became known as Project Aristotle, the answer embarrassed everyone's predictions. It wasn't the seniority of the people, the pedigree of the individuals, or the structure of the team. The strongest predictor of team effectiveness was psychological safety: whether people believed they could ask a question, flag a risk, or admit a mistake without paying for it.

Amy Edmondson, the Harvard researcher who gave that idea its name, found the sharp edge of it in hospitals back in 1996. The best-performing medical teams in her study appeared to make more medication errors than the worst ones. They didn't. They reported more, because reporting was safe. The weaker teams had the same errors and buried them.

Software runs on the same physics. A codebase is a running record of decisions made by people operating at some level of fear, and fear produces a specific kind of bad software: the kind where nobody flagged the risk, nobody admitted the misunderstanding, and the truth arrived as an outage instead of a question. Tom DeMarco and Tim Lister wrote in Peopleware, almost forty years ago, that the major problems of our work are not so much technological as sociological. Two decades of building enterprise software have not produced a single counterexample for me.

Burnout is a delivery risk, so we track it like one

W. Edwards Deming said a bad system will beat a good person every time. Burnout is the clearest case I know. We like to talk about it as a personal failing: resilience, boundaries, self-care. But Gallup's ongoing workplace research consistently finds that roughly three-quarters of employees experience burnout at least sometimes, and the driving causes are system-level: unreasonable load, unclear expectations, and the sense that effort is invisible. That's not a character problem. That's a management output.

So we put burnout on the risk register, next to the third-party dependency and the ambiguous requirement. It gets discussed in delivery reviews with the same vocabulary: likelihood, impact, mitigation. If that sounds cold-blooded, notice what it actually does: it makes a person's overload a legitimate reason to change the plan, instead of a private struggle they're supposed to absorb. The plan changes before the person breaks. That's the whole trick.

The same reasoning is why we've turned down engagements that would have been profitable and corrosive. A client relationship that requires grinding our team down is a loan taken out against people, and those loans come due with interest.

Dignity and agency are operational choices

Two more practices follow from this commitment, and both are unglamorous.

First: our engineers sit in client meetings. Not just leads, not just account managers. The people doing the work hear the problem in the client's own words and answer for their own decisions. That's partly about quality; every relay in a game of telephone costs you fidelity. But it's mostly about agency. Professionals defend work they own. They quietly stop defending work that's handed to them through two layers of interpretation.

Second: knowledge transfer runs through the whole engagement, not the last two weeks. A final-week handoff scramble is what it looks like when a vendor treated your team as an audience instead of participants. If your people have been in the work the entire time, the handoff is mostly a formality. They already own it.

What this buys you

I want to be clear that none of this is altruism. It's the most commercially serious commitment we have. Teams that aren't afraid tell you the truth about your project while the truth is still cheap. People who are treated with dignity stay, and continuity is where delivery speed actually comes from. The standard vendor failure mode, a burned-out team too checked-out or too nervous to tell the client what's really happening, is precisely the thing you can't afford, whatever the rate card says.

Our values page ends with a sentence I'll stand behind in any room: if an engagement leaves your team less capable, more anxious, or more confused than we found it, we've failed, regardless of what shipped. This essay is the reasoning underneath that sentence. The company, the software, and the process all exist to serve people. Get that ordering wrong and it doesn't matter how good the code is.

Sources

• Google re:Work, "Understand team effectiveness": the published guide to Project Aristotle.
• Amy Edmondson, "Learning from Mistakes Is Easier Said Than Done: Group and Organizational Influences on the Detection and Correction of Human Error", Journal of Applied Behavioral Science, 1996.
• Gallup, "Employee Burnout: The Biggest Myth", 2020.
• Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams, Addison-Wesley (first edition 1987).