Engineering-Management

If people can make catastrophic mistakes on your team, the process is broken. Real-World Example: Git Branch Protections An example is branch protections in a Git repository. These are rules that prevent engineers from deleting or altering history in shared branches, such as main, which on most teams would lead to a major problem. Engineers don’t intend to delete or alter main, but it can happen when rifling through terminal commands. We’re moving fast, and occasionally we press enter on the wrong command. As a contributor, I expect policies to catch me when I make this mistake. ...

I’ve been participating in fully-remote software standups every day for over a decade, and over the past two years, leading them, too. Here’s how I run the best standup meetings that I can. Guiding Principle: Physically Stand Standups got their name because people physically stood up during them; use that as a guiding principle. I don’t stand up, nor do people on my team, and not everyone can. But, the idea is to keep the meeting tight. Standups shouldn’t be long. They should not be something you can step away from for ten minutes to flip the laundry. ...

This year I’ve run over 25 Scrum refinement meetings; here’s what I’ve learned. This post will cover: What is refinement, and why does it matter? Two counterarguments, refuted! My step-by-step approach Notes on pointing bugs Let’s dive in. What is Refinement? (Backlog) Refinement is a process of improving tickets so they are understood by the whole team and ready for work. Refinement turns chaff like this: “Design for error on download screen” ...

I was the third engineer hired by my company, not counting our technical co-founder. I like that position, and it seems to play to my strengths. Who Is the Third Engineer? Who is the third engineer? Looking at the startup hiring process, I’ve noticed a pattern. The first engineer is usually a trusted senior that the founders know. The second engineer is the same, or a referral from the first engineer. ...

Retrospectives are one of my favorite engineering team practices. In this post, I’ll explain why and how I run retros. I’ll be covering: What is a retro? Why should we retro? Retro setup Running the retro Let’s get started! What is a Retro? What is a retro? From a dictionary: Retro, short for retrospective: ‘a surveying of the past.’ Retros are a Scrum/Agile ‘ceremony’, a collection of best practices for software engineering teams. ...

“What did you do this week?” I’ve written a weekly summary for myself and my teams for years. It helps me think through my work and shows people what I’m working on. In this post, I’ll explain how to use this tool. Why write a summary Why write a weekly summary? Two reasons: it helps me think through my work, and shows people what I’m working on. Taking thirty minutes to pause, reflect, and plan helps me sharpen my thinking and transition from week-to-week. Many developers keep a rubber duck on their desk for this reason. Rubber-ducking lets you talk through your problem at the speed of speech, and is excellent at exposing shaky assumptions. Weekly summaries codify this into a predictable, public routine. ...