Why Building the Best Team Requires Both Code and Charter

When “I just want to do good work” meets reality: why being a relentless individual contributor only scales so far.

I used to think job titles were like the fine print in contracts: technically important, but not something you pay much attention to unless there’s a problem. What mattered to me was solving issues, improving processes, and helping the team work better together. Titles? Irrelevant. I wanted to be the kind of person who made things run smoother, not the kind of person who enforced lines on an org chart.

Honestly that worked, for a very long time. It works when people across teams are curious, when they treat “someone from another team suggesting a change” as a gift-wrapped pull request rather than an intrusion. It works when psychological safety exists and when teammates are genuinely motivated to improve things for the collective. Maybe I was spoiled working in such an environment for many years.

But I discovered a hard reality: when people stop being open to cross-team change — when the default answer is “not my remit” or “we’ve always done it this way” — the gentle, title-agnostic approach stalls. At that point you can either become very good at persuasion and coalition-building, or you need the authority to make the call and change the defaults.

The team failure modes that eat goodwill (and why your polite suggestions die)

Patrick Lencioni’s Five Dysfunctions of a Team lays out a tidy pyramid of what kills team performance:

1. absence of trust,
2. fear of conflict,
3. lack of commitment,
4. avoidance of accountability,
5. inattention to results.

When any of these are present, cross-team improvements fail not because the idea is bad, but because the social plumbing is clogged. If people can’t be vulnerable, they won’t accept critique from a stranger; if they fear conflict, meetings become polite non-events; if nobody holds peers accountable, standards decay.

That maps directly to the “I’ll just show up with code / a spreadsheet / a patch” problem: technical correctness is necessary but not sufficient. A great PR can sit unmerged indefinitely if trust, conflict, commitment, accountability, or result-focus aren’t solved first.

Psychological safety: the magic ingredient that makes “someone else’s suggestion” not toxic

Amy Edmondson’s research introduced the term psychological safety — the shared belief that it’s safe to take interpersonal risks, speak up, or admit mistakes. Teams with high psychological safety are the ones where cross-cutting ideas get tried, feedback travels freely, and people are willing to be slightly embarrassed in the short term for long-term wins. That climate is the opposite of the environment where “not my team” becomes an impenetrable firewall.

If your team has it, you can be the wandering maintainer who seeds improvements everywhere and people will accept them. If it doesn’t, you’ll either need to sponsor cultural change or secure the authority to change defaults.

Two strategies when you can’t rely on voluntary buy-in

Option A — Become a master of influence and coalition-building

You can push a lot without a title if you do three things well:

• Build a guiding coalition. Recruit influential people across units who can vouch for the change. Social proof matters.
• Create a compact, data-driven pilot. Show the cost of not changing (MTTR, false-positive rates, toil hours) and a quick proof that your change lowers that cost. Small wins reduce resistance.
• Make it low-friction. Ship a migration script, a configuration toggle, or a one-click rollback. The less cognitive and operational work you ask of others, the more likely they are to try it.

These are essentially the practical, grassroots parts of change management that John Kotter describes in his approach to leading change: you either build a coalition and urgency or you fail fast. If you can do these, title-free change is still possible.

Option B — Get a mandate (role, remit, or process authority)

If the cultural and motivational preconditions are missing and coalition-building is taking months, the system will continue accumulating technical debt. At that point the correct engineering move is the same as the correct organizational move: escalate the decision boundary. That means either getting a formal remit (a role, a charter, a policy-writing slot), getting executive sponsorship, or convincing leadership to fold cross-cutting responsibilities into a team with the authority to enforce standards. In security work this is brutally practical: you can evangelize password hygiene forever, but you need gating (policy + automation) to actually stop weak passwords from being accepted.

Practical toolbox — what to try tomorrow

Measure first. Collect baseline metrics (alerts-per-analyst, false positive ratio, time-to-detect, time-to-remediate). Data is the language that crosses team siloes.

Pilot with rollback. Ship a one-team experiment and document the win/loss. Share artifacts as a reproducible repo.

Design a “least surprise” migration. Provide migration scripts, ops runbooks, and one-week support windows.

Use RACI for cross-team ownership. Make responsibilities explicit (who’s Responsible, Accountable, Consulted, Informed). Ambiguity is stealth entropy.

Invest in rituals that create psychological safety. Blameless postmortems, rotating chair for incident calls, and explicit “we’re solving the problem, not pointing fingers” language.

When all grassroots efforts stall, seek mandate. Draft a one-page charter for the change, identify a sponsor (CISO, Head of Engineering), and propose an enforcement mechanism (policy + measurement + quarterly review).

A tiny manifesto for people who prefer code over org charts

Do the work, and make it easy for others to adopt it.

Measure relentlessly — a good metric is more persuasive than a PowerPoint.

Use influence first; use authority when influence runs out. Authority isn’t moral failure — it’s a tool to remove systemic friction.

Treat culture as architecture: if the environment doesn’t allow changes to flow, add a rule (or an owner) that routes around the bottleneck.

Final note — about titles (and sudo)

Titles are not badges of ego; they’re knobs in the socio-technical system. When the team is healthy and curious, the knobs can mostly stay in the cabinet. When the team is stuck behind tribal borders and legacy processes, turning the knob is the pragmatic move. Think of it like access control: sometimes you need sudo to apply a fix that prevents the whole system from burning.

If your goal is to create the best cyber team possible, learn both sets of skills: the artisan craft of shipping improvements and the political craft of building coalitions or securing the mandate to standardize. The best leaders in security are those who can be both the humble contributor and the person who signs the policy when the room needs one.