Early Warning Signs for Engineering Teams

Software projects are hard and there are so many things that can get off track. How your engineering team is functioning is an important part of being successful. We’d all love to have a crystal ball to predict how things will turn out. Sadly this technology/magic does not exist. But there are some common early warning signs that things are not going well.

Blown estimates

Though not all teams estimate their work, it’s a common and useful practice to get a sense of the complexity and expected level of effort a feature will take to complete. Initially on a project, the team won’t have a sense for how fast development will move. Over the course of several weeks, that will change and estimates should be able to provide a baseline for how much work future features represent.

If the team starts to exceed their estimates consistently after a baseline has been established it should prompt examination. If they were accurate with estimates up to this point, what has changed? Is it one particularly challenging feature with hidden complexity or is the issue common among all features? Are teams making estimates without enough knowledge about the feature? Are product owners shifting requirements after estimation?

What I am looking for is a trend that suggests the team is consistently taking longer to complete features than they were in the past. If you notice a trend, you need to figure out why and whether this is a warning sign of larger potential issues.

Increased technical debt

Technical debt is a concept that teams use to describe when short-cuts are taken that compromise the quality and robustness of their software for short-term gains. It gives you faster progress today at a higher cost in the future.

Deliberately taking on technical debt for the right reasons can be fine, but I get concerned if a team is taking on too much technical debt. This may suggest that they are trying to ship software faster because they feel a pressure to do so. If the technical debt is inadvertent or subconscious then that is a problem. Many teams will use code quality metrics to keep tabs on this.

At some point, this increased technical debt will become an issue and it can be a great early warning sign that you need to examine how the team is going about their work.

Strained communication

When I start to see either strained communication or avoidance of communicating on projects, I know things are unhealthy. It is an immediate red flag that something is amiss and is typically an early indicator of rising stress. Why is communication strained? Is morale low? Are team members in disagreement about some aspect of the project? Are their concerns being listened to? It could be that trust has been lost. So many potential reasons that communication is no longer flowing and almost all of them are bad. If you don’t address the root concerns, it’s only going to get worse.

Slipped deadlines

Any time a team misses a deadline, you should take note. They happen to be a perfect canary in the coal mine. Are expectations unrealistic? Are the deadlines being imposed on the team by external factors? They may have been arrived at by arbitrary or haphazard ways and thus aren’t based on sound data? In all of these cases, we have root causes outside of the engineering team that are worthy of examination.

What I want to focus on here is the use of the internal deadline. This is where the engineering team has estimated the effort for a release and picked a realistic deadline. When these deadlines start to slip, I want to know why. Does the team understand the work? Is the scope expanding or requirements changing out from under them? Are they simply bad at estimates or is the project’s complexity shooting up? There can be any number of reasons contributing to the slipping of dates. You find those and you’ll find candidates for making your engineering team better.

Taking action

Each of these warning signs are opportunities for your engineering leaders to take a closer look at what’s happening and determine the sources. Often times these issues can be quickly addressed by adjusting process or communication patterns. They may be simple misunderstandings that a focused meeting can resolve. They may stem from dysfunctions outside of the engineering team. You may find some patterns as described in our rescue patterns post. No matter the source, if you have any of these warning signs, take the time to look into them. Finding solutions to make it better today is better than waiting for them to fester into a crisis.