Protecting Attention in a Busy Team
A calm note on treating attention as a shared team resource, not an infinite personal budget that people can recover alone.
Writing
The human side of building software — reviews, feedback, mentorship, and teams that grow people instead of burning them out.
Practical, people-first writing on engineering culture: how to run code reviews that make code and people better, give and receive feedback well, write pull requests reviewers love, mentor engineers into seniors, and build kind, high-trust teams. Real scripts, examples, and lessons that scale from a two-person startup to a thousand-engineer org.
A calm note on treating attention as a shared team resource, not an infinite personal budget that people can recover alone.
A calm note on treating repeated team friction as useful signal before it hardens into personal blame.
A calm note on helping quieter teammates contribute thoughtful review feedback without forcing every useful signal into the loudest channel.
A grounded note on ownership as clear follow-through, explicit handoffs, and steady accountability without drama.
A calm note on why asking for help early is not weakness, but one of the small habits that keeps work honest and teams healthy.
A calm note on why healthy teams surface risk early: not to create fear, but to give the work more room to adjust.
A calm note on how engineering culture shows up in small reviews: the phrasing, patience, and care teams bring to ordinary feedback.
A calm note on how engineering trust grows through ordinary follow-through: small promises kept, visible updates, and repairs when reality changes.
A calm note on why healthy engineering teams sometimes say not yet: to protect quality, trust, and the people who will operate the release later.
A reflective note on code review culture: how treating the reviewer as a future reader can make pull requests clearer, kinder, and more useful for the people who will maintain the change later.
A calm look at team silence: how quiet rooms, missing replies, and low participation can reveal unclear ownership, unsafe disagreement, fatigue, or hidden context.
A calm look at asking for help in engineering teams: how to make context visible, protect dignity, and turn stuck moments into shared learning instead of silent pressure.
A practical guide to difficult feedback in engineering teams: how to prepare the facts, keep dignity in the room, name behavior clearly, and turn a tense conversation into a fair next step.
A grounded reflection on fostering innovation in engineering teams: how psychological safety, slack, user context, small experiments, technical quality, and honest prioritization help ideas become useful change.
A calm look at office politics in engineering teams: how to understand incentives, build trust, communicate context, disagree cleanly, and stay principled without becoming naive.
A calm explanation of mentorship and sponsorship in engineering careers: how advice, feedback, advocacy, visibility, trust, and opportunity work together without turning growth into politics.
A calm look at engineering onboarding that helps people become useful without feeling lost: context, small early wins, clear ownership, buddy support, documentation, feedback loops, and patient team habits.
A calm guide to async communication for remote teams: writing enough context, recording decisions, setting response expectations, improving handoffs, building trust, and protecting people from always-on pressure.
A calm look at high-output behavior that damages trust: why teams reward it, how feedback loops break, and how leaders can set boundaries while still offering a real repair path.
A calm reflection on balancing experience and potential in engineering hiring. The article focuses on evidence, learning pace, team needs, and the quiet conditions that help a person grow after they join.
Moving from Software Engineer to Technical Manager isn’t a bigger version of the same job — it’s a quiet rewrite of the very habits that made you good at the last one. Step back from the IDE to see architecture, people, and process, and three surprising truths come into focus: code is an asset and a liability at once, your value shifts from addition to multiplication, and delegation is simple to say but genuinely hard to let go of. A practical, honest reflection for senior engineers eyeing the lead role — and for new managers still reaching for the keyboard.
Code review is where team culture is made or broken. A practical guide to reviewing code so it ships better AND the author comes back stronger — concrete phrasing, a reviewer's checklist, and the habits that quietly turn reviews toxic.
Kindness isn’t niceness, and it isn’t soft. It’s a force multiplier — clearer feedback, safer incidents, faster-growing teammates. What ‘kind engineering’ really means, and how to practise it in code reviews, incidents, and everyday work.
A great pull request is a gift to your reviewer: small, well-described, easy to say yes to. The anatomy of a reviewable PR — size, title, description, commit hygiene, and self-review — with concrete before/after examples.
A trusted pull request does more than look tidy. It names the behavior being changed, shows the safer pattern, and gives reviewers enough evidence to approve with real confidence instead of guesswork.
Most engineers were never taught how to give feedback — or how to take it. A field guide to specific, kind, actionable feedback, and to staying open when you're on the receiving end, with ready-to-use scripts.
Great teams are grown, not just hired. From leading engineering teams: how to mentor so people level up fast — pairing, code review as teaching, the right-sized stretch, and the mindset shifts that turn a junior into someone you'd trust with anything.
A team can be carefully managed and still drift. Using John Kotter's distinction between coping with complexity and coping with change, here is how to spot when a team is over-managed and under-led — and small, repeatable ways to bring the direction back.
Warren Bennis said leaders do the right thing while managers do things right. Robert Sutton added the part that matters: to do the right thing, you must understand what it takes to do things right. On the trap of vision detached from craft — and the bounce between big picture and detail.
Abraham Zaleznik noticed that people uncomfortable with direct engagement communicate in signals rather than messages. On why vague communication feels safe to send and lands as anxiety, how it quietly breeds office politics, and why a clear message is a kindness — especially when it is hard.
Some people restore order the instant disorder appears; others can hold a problem open long enough to understand it. On tolerance for ambiguity as a learnable discipline, the cost of solving before understanding, the Einstellung trap, and why the maturity is in how long you can stay with a hard problem.
Bennis and Goldsmith described two ways to move people: push (deadlines, KPIs, position power) and pull (meaning and trust). On the unforgettable sign-language image of reins versus a cradle, why pull is slower but deeper, the honesty it requires, and when to reach for each. The closing piece of the series.
Culture fit sounds responsible, but it can reward sameness and hide vague concerns. This piece separates real values signals from comfort signals and argues for culture contribution.
A healthy 1-on-1 is a regular place for context, trust, feedback, and career direction, not a softer status meeting. The useful version catches small signals before they become expensive.
A grounded look at what teams should really mean by celebrating failure: not applauding damage, but making honest learning, early signal reporting, repair, and changed systems safer to practice.
A grounded reflection on building diverse engineering teams: moving beyond slogans into hiring, onboarding, meeting design, decision-making, feedback, and the daily habits that let different people contribute fully.
A calm guide to managing up with non-technical leadership: translating technical work into risk, options, impact, timing, and decisions without hiding complexity or talking down to people.
A calm reflection on performance reviews that actually help people grow: using evidence, expectations, calibration, feedback, and follow-through without turning the review into a surprise or a ritual.
A calm look at preventing burnout in engineering teams: early signals, workload visibility, recovery time, sustainable expectations, management responsibility, and the small habits that keep people from disappearing quietly.
A calm look at blameless engineering culture: how teams can study incidents without blame, separate accountability from punishment, improve systems, and make it safer for people to tell the truth early.
A calm reflection on constructive feedback: how specific observations, timing, care, accountability, and follow-up help people improve without turning feedback into blame or performance theater.