DEV Community: Robert Stowe

What I think a one-on-one is for

Robert Stowe — Wed, 21 Oct 2026 13:20:01 +0000

The one-on-one is the meeting most likely to drift into a status update, and I think that is the one thing it should never be. Status has other places to live, such as the standup, the board, and the pull request. The one-on-one is the only half hour in the week that belongs to one person and their working life, and spending it on ticket numbers gives that away cheaply.

What I think it is for

Three things, in rough order of how often they come up. First, the thing that is bothering someone and has not been said anywhere else. A review that landed badly, a decision they did not understand, a worry about where the product is going. Second, growth. What they want to be good at in a year, and what in the next month moves toward that. Third, context from me that they would not otherwise get, such as why a priority changed or what a conversation two levels up actually meant.

None of these fit a status format, because none of them have a ticket.

Why I believe this

In fifteen years of running UI teams I have noticed that the problems that became expensive were almost always said out loud early, quietly, in a one-on-one, and then not heard because the meeting was busy with updates. The meeting that catches those is worth more than any report it could replace.

It also changes who owns the meeting. If it is a status update, the manager is asking and the engineer is answering. If it is about the person, the engineer brings the agenda and the manager mostly listens. I think the second shape is where trust gets built, and trust is what makes the hard conversation possible later.

The best argument against this

Some people genuinely want to talk through their work in that slot, and for them the work is the person. I think that is fine, as long as the conversation is about the work as they experience it, what is hard and what they are unsure of, rather than a readout for me. The difference is who the information is for.

Where it stops being true

A new hire needs more structure than this, and for the first month a one-on-one that walks through the week is a kindness, not a waste. A team in the middle of an incident or a release crunch will have status in every meeting whether anyone plans it or not. And a very senior engineer may want the meeting monthly and use the time between for the work. I would rather adjust the cadence than let the meeting become a form.

The question I keep asking myself afterwards is whether the person left with something they did not have before. When the answer is a list of tickets, I think the meeting went to the wrong thing.

Photo source: https://photos.robertstowe.com/tasmania

What I believe changes when you start managing managers

Robert Stowe — Wed, 14 Oct 2026 14:52:11 +0000

I think the move from managing engineers to managing managers is a bigger change than the move into management in the first place. The first move changes what you do. The second changes what you can see.

You stop seeing the work

A manager of engineers has direct access to the work, the pull request, the standup, the board. A manager of managers does not. Every signal arrives through another person's judgment, their summary, their sense of the week, what they chose to escalate. That distance is permanent.

The instinct is to close it. I think that is usually a mistake, because the time comes out of what you are now responsible for, the managers themselves. The distance is not a problem to solve. It is the shape of the job.

Your output is other people's decisions

The decisions that matter to a team, who works on what, what gets reviewed how, when something ships, are now made by someone else, in meetings you are not in. Your contribution is whatever shaped their judgment before they walked in.

I have come to think of that as the real output of the role. The time goes into what shapes judgment, being clear about what matters, explaining why, and talking through the hard calls afterward. A few decisions, usually about people, I still need to be part of.

Different is not wrong

Every manager runs their team a little differently than you would. At first every difference looks like something to correct. I think most are not. A team run differently from how I would run it, and healthy and delivering, is run well.

The exceptions have to be the same across teams, how people are treated, the standards the organization agreed to, and commitments to other teams. Those are not styles.

The feedback loop gets long

When you manage engineers, a change to how the team plans shows up next sprint. One level up, a change to how you support a manager might take a quarter to show. You can no longer trip over problems, so you have to decide on purpose what to look at, and how often. For me that means a few regular questions for every manager, and a few things I check even when nothing seems wrong.

What success looks like now

A good week as a manager of engineers was one where I did things. As a manager of managers, it is often one where I did little anyone could see and the teams did a great deal. I think the measure of the role is what happens without you, the decision made the way you would have made it by someone who did not need to ask.

Where this stops being true

On a small team, a manager of managers often still reviews code and makes many of the calls, and that is fine. Staying close enough to ask good questions is the job. Staying close enough to make the decisions is what to give up.

Photo source: https://photos.robertstowe.com/cumberland-island

What I think an estimate is for

Robert Stowe — Wed, 07 Oct 2026 13:59:45 +0000

I have sat through a lot of conversations about estimates. How to make them more accurate, which technique to use, points or hours or t-shirt sizes. I used to think the problem was accuracy. I no longer do. I think most of the trouble is confusion about what they are for.

An estimate is a planning input

An estimate is a guess about effort, made with incomplete information, by the people who will do the work. That is not a weakness. It is the definition. Nobody knows how long software takes until it is built, and an estimate is the best substitute when a decision has to be made.

It supports planning decisions. Is this worth starting? Which of these three goes first? Do we understand this well enough to begin, or does the wide range say we do not? Those need a rough size, which is what an estimate is good at. What it is not good at is being a date. It measures how much we do not yet know.

What goes wrong when it becomes a promise

The moment an estimate turns into a commitment, it stops carrying information and starts carrying consequences. The numbers go up, to leave room. Engineers stop saying the honest thing, usually some version of I am not sure, and say the safe thing. Nobody is behaving badly. They are responding to what the number now means.

I think the practical result is that estimates get less accurate as more weight is put on them, the opposite of what the weight was for.

What I ask for instead

A single number hides what I most want to know, how confident the person giving it is. So I ask for a range, and what would put it at either end. Two days if the API does what the documentation says, two weeks if it does not, tells me more than seven days ever could. It tells me where the risk is, and often what to find out first.

I also ask what the estimate assumes. Most surprises in a project were assumptions nobody said out loud. Saying them at the estimate is cheap. Discovering them in week three is not.

And I say which question I am asking. Is this sizing, so we can plan? Or a commitment, because a customer or a contract needs a date? A commitment should be made deliberately, with room built in, by someone who is allowed to say no. It should not be an estimate that got promoted when nobody was looking.

Where this stops being true

Some work has a real deadline. A regulation takes effect on a date, a contract names one, an event happens whether the software is ready or not. Then the team needs a commitment.

Even then, I think the honest path runs through the estimate rather than around it. Size the work, find the range, then decide what to cut or add so the commitment is one the team believes. The failure is not committing to dates. It is treating every estimate as one.

Photo source: https://photos.robertstowe.com/new-mexico

Writing technical standards people follow

Robert Stowe — Sun, 04 Oct 2026 03:09:13 +0000

Most technical standards I have met were written once, read twice, and ignored. The document was forty pages, it did not say why any rule existed, nothing enforced it, and the person who wrote it had moved to another team. The standard was true the day it was published and fiction a year later.

I have written a few that teams followed and more that they did not. Here is what separates them.

Brief enough to hold in your head

A standard is only useful if an engineer can remember it while working. A page or two of rules will be followed. Forty pages will be searched when someone is in trouble and otherwise forgotten.

So the discipline of writing a standard is mostly the discipline of leaving things out. If a rule does not prevent a problem the team has actually had, it does not belong. If two rules can be one, they should be.

Every rule says why

A rule without a reason is an order, and engineers are bad at following orders they do not understand, which is a feature, not a flaw. With a reason, the engineer can tell when a rule applies and when the author did not anticipate the situation. When the reason stops being true, the rule can be retired. A rule with no stated reason lives forever, because nobody can tell whether it is still needed.

Whatever can be enforced is

People should not have to remember a standard. Whatever a linter, a type, a template, or a pipeline step can check should be checked there, on every change. What is left is the part that needs judgment, the architectural decisions and trade-offs, and that part is short and worth reading.

Someone owns it

A standard without an owner decays. The platform moves, a rule turns out to be wrong, and nobody has the standing to change the document, so it drifts until it is ignored. Every standard needs a named owner with the authority to change it, and a date so readers know how stale it is.

The exception process

The last piece is a way to break the rule. Every standard will meet a case it did not anticipate, and if the only options are to follow it blindly or ignore it silently, the team will choose silence.

A good exception process is lightweight. Say what rule you are breaking, say why, get one other person to agree, and record it. The record matters more than the approval, because it is how the owner learns the standard has a gap, and a few exceptions of one kind mean the rule should change.

What a standard is for

I think a technical standard is a way of making decisions once so that nobody has to make them again. That only works if the decisions are few, reasoned, enforced where possible, and kept current by someone who cares. Everything else is documentation, and documentation is what people stop reading.

Photo source: https://photos.robertstowe.com/victoria