Ways of Working

Collaboration & Teamwork

Foundational

Software is built by teams over years. The quality of what we ship depends less on individual brilliance than on how well we work together. That means how we share context, hand off work, disagree, and cover for each other. Aim for the team's output over the long run, not your own output this week.

Most friction in software is not technical. It comes from people lacking the context they need, decisions made in private, or work that only one person understands. Good collaboration is the deliberate work of reducing that friction. You make your work visible, your reasoning easy to share, and your knowledge held by more than one person.

These are not just nice manners. In a regulated business, having only one person who understands the AML decision logic or the deployment pipeline is an operational risk. Working openly and spreading knowledge is how we stay reliable as a team, not just how we stay polite.

Work in the open

DoMake work visible early. Share work in progress, draft PRs, and rough designs, instead of disappearing and then presenting a finished surprise.
DoWrite down decisions and the reasons for them where the team can find them, so the context lasts longer than the conversation and the person who had it.
DoSpread knowledge on purpose. Pair, review, and document so that no critical system depends on one person being available.
AlwaysReport blockers and delays as soon as you see them, not at the deadline. Early bad news is helpful; late bad news is a crisis.
ConsiderLeaving the codebase, the docs, and the next person a little better off than you found them on every task.
Do notKeep context to yourself or build a private area of code only you understand. Being the only one who can do something is a risk, not job security.

Disagree and commit

DoAssume good intent and respond to the strongest version of a colleague's argument, not the weakest.
DoDisagree openly and respectfully on the facts. Once a decision is made, commit to it fully, even if it was not your preference.
DoGive credit generously and share ownership of both successes and failures. The team wins and loses together.
ConsiderChoosing the option that helps the next person (the reviewer, the on-call engineer, the future maintainer), not the one that is fastest for you now.
Do notReopen a settled decision again and again, or quietly work against it after agreeing to it.
Do notLet a disagreement become personal. Criticise the idea, never the person.

Self-review checklist

AskIf I were unavailable tomorrow, could someone else continue this work from what I have shared?
AskHave I made my reasoning visible, or is it only in my head?
AskAm I raising this blocker early enough for the team to react?
AskDid I respond to the best version of the other view before pushing my own?

Why it matters: Teams that share context, raise problems early, and disagree well ship better software with fewer crises. They also recover faster when something breaks. The biggest long-run risks to delivery are rarely hard technical problems. They are knowledge held by one person, late surprises, and decisions no one can reconstruct.