Software development team management: 8 best practices

Good software team management is mostly about what you remove. Fewer priority changes. Fewer meetings. Fewer interruptions, including the one where you ask what’s going on. Teams that ship steadily tend to have less process, not more.

This guide is for the person who runs the company or the product and can’t read the code. You don’t need to. Every practice here is something a non-technical founder or PM can put in place, and each one links to the research it rests on.

The eight practices:

1. Hold priorities steady
2. Set an appetite, not a deadline
3. Protect focus time
4. Keep teams small
5. Budget for maintenance
6. Make bad news cheap to deliver
7. Write decisions down
8. Know what shipped without asking

1. Hold priorities steady

The most expensive thing you can do to an engineering team is change its priorities mid-work. The meeting itself is cheap. The cost is the half-built work that gets thrown away, plus the days everyone spends getting up to speed on the new thing.

Google’s DORA research group put it bluntly in its 2024 State of DevOps report: “Unstable organizational priorities cause meaningful decreases in productivity and substantial increases in burnout.” The report found this held even for teams with strong leaders and good documentation. Good management doesn’t cancel out constant change.

The practice: pick a cycle length, two weeks or six. Whatever the team commits to at the start stays fixed until the end. New requests wait for the next cycle. If something truly can’t wait, something else has to drop, and you say which one out loud.

One emergency is fine. An emergency every week means the planning is broken.

2. Set an appetite, not a deadline

Ask an engineer “how long will this take?” and you get a guess. Repeat that guess to your board and it becomes a promise.

Basecamp’s Shape Up flips the question. Decide first how much time the work is worth. They call that an appetite: “the amount of time we want to spend on a project, as opposed to an estimate.” The time is fixed. The scope shrinks to fit.

This is a business decision, so you can make it without understanding the code. “This is worth two weeks of one engineer” is a sentence a founder can say with confidence. “This will take two weeks” is a sentence nobody can say with confidence, including the engineer.

3. Protect focus time

Engineers don’t do their work in one-hour blocks. Paul Graham’s Maker’s Schedule, Manager’s Schedule is still the clearest explanation of why: “A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.”

GitHub measured it. In its Good Day Project, 40 engineers logged their days for two weeks. Going from two meetings a day to three dropped their chance of making progress on their goals from 74% to 14%. Small study, one company, but every engineer you ask will recognize it.

The practice:

• Put meetings at the start or end of the day, never the middle.
• Keep at least two afternoons a week meeting-free for the whole team.
• Move status updates into writing.

The worst offender is the status question. It interrupts the work in order to ask about the work. Practice 8 replaces it.

4. Keep teams small

Amazon’s rule is the one most people know. Two-pizza teams: no team bigger than two pizzas can feed. AWS’s own guidance explains why. A small team can own one piece of the product end to end, and ownership is what lets it move without waiting on anyone.

The mistake to avoid is splitting teams by technical layer. A frontend team and a backend team means every feature needs both to agree, and the handoffs eat the calendar. Split by what a customer touches instead, like checkout or onboarding, so one team can ship it alone.

If you have four engineers, you have one team. Don’t split it.

5. Budget for maintenance

Some share of every engineering week goes to work that ships nothing visible. Fixing what broke. Updating the tools the code depends on. Paying down shortcuts taken last quarter.

Stripe’s Developer Coefficient survey put the average at 17.3 hours a week on maintenance, back in 2018. The number is old and the mix has shifted since. No team has reported it reaching zero.

The mistake is treating that time as slack you can claw back. It’s the cost of owning software. Squeeze it and you get the outages that cost more.

Google’s SRE organization sets an explicit ceiling. It aims to keep routine operational work, which it calls toil, under 50% of each engineer’s time, and it tracks the figure. You don’t need their number. You need a number. Agree on a share (20% is a common starting point) and stop arguing about it every sprint.

6. Make bad news cheap to deliver

Google studied its own teams to find out what separated the effective ones. The answer from Project Aristotle: “what really mattered was less about who is on the team, and more about how the team worked together.”

The factor it ranked first was psychological safety. In Google’s words, people on the team feel “confident that no one on the team will embarrass or punish anyone else for admitting a mistake, asking a question, or offering a new idea.”

For a manager, that comes down to one habit. When an engineer tells you in week two that the project will slip, thank them. The alternative is finding out in week six. That’s what happens on teams where the week-two conversation went badly once.

When something breaks, review what happened without naming who caused it. The useful question is what allowed the mistake to reach customers. The answer is nearly always a gap in the process, not a person.

7. Write decisions down

Stack Overflow’s 2024 Developer Survey found 61% of professional developers spend more than 30 minutes a day searching for answers. Most also said waiting on a colleague’s answer disrupts their work, even when they know who to ask. Every one of those questions is an interruption for whoever answers it, which brings us back to practice 3.

You don’t need a full wiki. One place where decisions and their reasons go, plus the habit of putting them there, covers most of it. Why we chose this vendor. Why we delayed that feature. A decision log the founder keeps is worth more than documentation nobody owns.

8. Know what shipped without asking

Atlassian’s 2025 State of Developer Experience survey of 3,500 developers and managers found that 63% of developers believe leaders don’t understand their pain points. The gap runs both ways. Leaders can’t see what the team is doing, so they ask. The asking is one of the pain points.

The fix is a written update that arrives on a schedule and doesn’t depend on anyone remembering to write it. Weekly works for most teams. Lead with what changed for customers. Name the risk early. Skip the numbers that measure activity. We covered the format in how to report engineering progress to non-technical stakeholders.

The raw material already exists in your repository. Every change the team made is recorded there, with who made it and when. The work is translating it into a paragraph a board member can read. Done by hand, that costs a senior engineer half a day a week, which is the focus time practice 3 was protecting. DevSummary does the translation from your GitHub history on a schedule, scoped to a project or a team, so the update arrives without anyone being asked.

What to leave out

• Commit counts, lines of code, story points per engineer. They measure movement, not whether the movement went anywhere. They also get gamed the moment they’re used as a report card. DORA says the same about its own metrics, and those are the good ones.
• Daily standups past about eight people. They stop being coordination and turn into a status meeting, which practice 8 replaces.
• Individual performance dashboards. If you want to know whether the team is working well, there are four checks that need none of this.

Common questions

Can a non-technical founder manage a development team directly?

Yes, up to roughly eight engineers. The technical decisions belong to a senior engineer on the team. You own priorities and communication. Past that size you need an engineering manager or a CTO, because coordination becomes a full-time job.

How do I know these practices are working?

Fewer surprises. Projects that slip say so early. The written update arrives without chasing. Engineers stop asking what the priority is, because it hasn’t changed since they last asked. If your delivery metrics improve too, good. The surprises are the signal.