Maybe your team’s estimates are bang on, but they take twice as long to complete tasks as they should.

How To Identify Underdelivering

Give your team a performance review

You might have underperforming engineers. This is not pleasant to manage. There are books on people management. I will not dig into that here other than to say: you should be doing regular check-ins on individual performance regardless of how your team is performing.

Identify scope creep

Scope creep happens when an existing task changes requirements.

Changing requirements

• Are you constantly discovering new blocking problems mid-development?
• Are the requirements literally changing? Is the requirements doc changing? Is the text in the tickets your engineers are picking up changing? Are the design mock-ups changing? Are you constantly getting new information that requires changes to your implementation from your product partner?

Over-engineering

I identify this with a series of questions:

• What kind of solutions is your team delivering?
• How complex are the problems you are solving?
• Are you over-designing?
• Is your team writing a brand new service for every problem?
• Does your team adopt the latest and greatest technology for everything rather than using out-of-the-box solutions?
• Does a ten-day refactor accompany every API update?

I’m not saying that there are not totally valid reasons to do those things. Iteration on existing solutions is expected. Sometimes, there are technical requirements that demand the adoption of new technology. Sometimes, the team needs to keep the codebase better than they left it or risk being buried in horrible code no one will understand in a year. But the tradeoffs should be evaluated.

How To Address the Problem

If you are constantly discovering new and significant technical requirements, such as

• We need to build something new (a service, a component)
• We have dependencies on this other team or service first
• We forgot to account for security concerns, performance, latency, scale

Then your engineering team may need to adopt a more rigorous requirements-gathering phase.

• Adopt a prototyping phase
• Adopt a technical design and review process

If the product requirements are constantly changing under your feet, you need to work with your product manager (assuming you have one). As a manager, it is your responsibility to ensure your team has project requirements at the start. There’s a whole world of product management I don’t know about, and there are way better resources than me to explain how that works. Here are a few things to try:

• Align with your PM on requirements
• Adopt a more rigorous grooming process
• Adopt iterative development

Each of these are topics with a vast variety of ideas on executing. I recommend doing a lot of googling. Ask your fellow managers how they approach these.

Prototyping

Be scrappy. Be fast. Just try things. Proof of concept. Uncover things by doing.

Technical design

Again, there are books on this topic. Technical designs are a great place to evaluate tradeoffs. Engineers should own technical designs.

Requirement alignment

Questions I ask my product manager include the following:

• What are we building?
• Who is it for?
• What metric are we trying to move? (aka why does it matter)

Grooming

Google “how to groom stories for development.” You, the engineering team, and the product manager should have healthy discussions to clarify requirements and priorities.

Iterative development

Google “iterative development.” As a manager, if you and your PM align on what an MVP is and what you will save for a future iteration, recognize that changing business priorities may force you to set aside those iterations in favor of something else. It’s okay. But be intentional about the prioritization.