Culture is how we treat each other when no process says what to do. Most companies get it wrong by chasing output. We build trust first, and the output follows.
Why it matters
Many companies try to get results by pushing harder: tighter deadlines, more hours, closer supervision. In the short run it can look like it works. Over time people spend their energy working around the system instead of improving it, shortcuts pile up, and the best people stop taking risks or leave.
We take the opposite bet. When people are trusted, supported and accountable, they move faster and build better software than any amount of pressure could get out of them. DORA's research points the same way: teams with a generative culture, one built on trust and shared responsibility, deliver better and burn out less.
This page is the why. Our principles are the what: the specific behaviors that make this culture real day to day.
Signs our culture is healthy
People help without being asked
Someone stuck gets help quickly, from whoever can give it.
People pick up work instead of waiting
New requests, issues and projects get an owner fast, rather than sitting until someone has to assign them.
Bad news travels early
Risks, slipping dates and mistakes come up while there's still time to act on them.
Incidents end in learning
Reviews look at the system and produce follow-up work, not blame.
Feedback flows both ways
Engineers disagree in reviews and design discussions, and leaders change their minds when they hear a better idea.
Leads don't need babysitting
Projects run without daily check-ins, and releases are verified by the people who shipped them.
People grow
Engineers move to the next level, and they credit the people who helped them get there.
Signs it needs attention
None of these makes the culture bad on its own. They're early warnings, and each one tells us what to do next.
What we notice
What we do
People hesitate to help, or avoid unfamiliar work, in case a mistake gets pinned on them.
Look at how recent mistakes were handled, and make the next incident review visibly blameless.
Work sits unowned until someone assigns it.
Ask why. It's usually unclear priorities, or people who are overloaded or afraid to get it wrong.
Problems surface late, or first appear in a customer complaint.
Make it easier and safer to raise risks early, and thank people who do.
Engineers regularly work long hours to hit dates.
Revisit scope, staffing and how expectations are set. Heroics are a planning failure, not a culture win.
Shortcuts pile up and post-live cleanup keeps getting skipped.
Protect the post-live milestone, and look at what's pushing people to cut corners.
Decisions happen in private messages, and people find out after the fact.
Move the decision into Linear, and include the people it affects. See Communication.
Disagreement disappears: reviews are all approvals and meetings all nods.
Ask directly for concerns, and show that raising one changes the outcome.
Leaders feel they need to check every detail.
Ask whether it's the people or the support we've given them, and fix whichever it is.
Trust is the starting point
When an engineer leads a project, nobody needs to check on them every day. They shape the work, plan it, release it and check it in production themselves, and they ask for help when they need it. That trust is earned and kept by the people doing the work, and it's given freely by the people leading them.
If leaders don't trust their people to grow, something is wrong. Sometimes it's a hiring problem. If it keeps happening with different people, it's a leadership problem, and we own that too.
Mistakes are how we learn
When something goes wrong, we ask what about the system let it happen, not who to blame. Nobody is yelled at for a production issue. That's what makes it safe to help a teammate, take on an unfamiliar problem or raise a risk early.
Blameless doesn't mean unaccountable. The person who made the change, or the project lead, coordinates the fix and the follow-through, and we all learn from it.
Ego has no place here
Being good at the work doesn't earn an exemption from how we treat people or from how we work. We don't accept talking down to teammates, skipping review or process because you think you're above it, or pulling in a direction nobody agreed to. The stronger someone's skills, the more we expect them to lead by example.
We listen before we speak. We share ideas openly, and when the team picks a different idea, we commit to it and move on.
Everyone keeps it
Culture starts with leadership. We hire for it deliberately, coach it every quarter, and act when someone's behavior consistently works against it, whatever their performance.
But leadership can't hold it alone. Every engineer, at every level, keeps it by caring about their teammates and the people who use our software, being quick to listen and slow to speak, sharing ideas, and moving on as a team when a different idea wins.
