Symptoms of a Weak Development Team

This question came up last week.

I am hearing from my project management team a bit of distrust in the technical capacity of our web development team.  I  think we suffer because of the distance and culture but the project management team takes every late delivery or small bug as evidence that the development team may not be capable.

My quick response was that this was likely some combination of:

1. Weak development team
2. Poor communication, especially around requirements and expectation setting
3. Past failures (missed deadlines, bugs, downtime, etc.) that make it impossible to establish trust

The response I received was:

How do I know which it is?

Great question.  And the answer is that it likely takes some diving into the specific situation to understand what’s going on.  And there are always multiple things that can be improved to get a better result.  Still there are some common signals / symptoms that I hear about from Founders/CxOs in companies that are the reason they are calling me.  I thought it might be helpful to capture these symptoms so that in the future I can point people to this.  But please:

Just because your development team has these symptoms does not mean that you have a weak development team.  What it means is that you likely need to dive in to figure out what you are really dealing with.

Founder Developer Gap and A, B, C Players

By the way, this question is another example of issues around the Founder Developer Gap.  Developers operate at a level and in a language that others in the organization can’t necessarily interpret and understand.  So, it’s often hard to know if the developer is an A, B or C player.  And an “A” player is worth 10+ C players. 

Also, there are a lot of C players out there.  When we interview potential developers, it’s amazing to me how many can’t answer questions that every student in a sophomore level computer science course should be able to answer.  I used to teach this same stuff.  If a student couldn’t answer that, you normally would counsel them that they might want to think about changing majors.  How did they ever graduate not knowing this stuff?  And how do they have the resume they have?  I often wonder what’s going on, but I don’t have time to worry about it.  We try to move on to find the actual A players.

Symptoms

So what do I hear about on these calls?

• Frequently missed deadlines. 
• Last minute scope cutting to make deadlines.
• Delivery of code/product that clearly has not been tested.
• Marking bugs as fixed that aren’t fixed.
• Massive overtime.
• No communication between developers.
• No clear leader.
• No one owns architecture.
• Rogue developers with their own agenda.
• Private bits of code that are jealously protected.
• Finger pointing with no clear answer.
• Fixing one thing breaks something else.
• Source code control is only marginally being used.
• Bugs – no big deal.  The system keeps crashing – no problem.
• Annoyed at testers for finding bugs.
• No attention to detail.
• Same problems seem to occur all the time with no desire to look at what’s behind the problem.
• All new features seem to require significant rewrites and a ton of development time.
• Developers can’t explain why certain changes will require more or less development time.
• Developers are very quite when bugs, features, changes are being discussed and only come back with questions later.
• Not open to discussing all of these issues.
• One of your better developers leaves.
• No questions being asked (Startup Software Development – Do Your Homework Before You Develop Anything)
• Rest of team says - “I’m not sure where we stand.” “I’m not sure what’s in the next dev cycle or when it’s being delivered.”

And the #1 reason I get calls relates to an old software engineering adage:

The first 90% of a project takes half the time.  The last 10% takes the other half.

So the most common symptom is:

The team seemed to get a lot done early on, but now it just seems like it is taking forever to get it “done.”

Again, if you are seeing a few of these symptoms, then you may have a weak development team, but it might be other things going on that make it so the team is not as effective as it should be.  You need to dive in.  And, of course, if you have the Founder Developer Gap, then you might want to consider getting help.

Signs of a High Performing Team

Going at this another way … Christope Louvion, a fellow member of the Los Angeles CTO Forum, wrote a blog post on Signs of a high performing team

• a high service level and availability of their product/system
• a high throughput of effective change
• a low amount of unplanned work
• a culture of change management
• a culture of continual improvement
• a culture of root-cause analysis

This is a great list!

Recovery is Extremely Hard

Early failures by a development team make it really hard (next to impossible) to recover trust. 

Software development is challenging.  It’s often hard to know all the different questions you should have asked to get better requirements.  And it’s easy to not think of edge cases.  There’s pressure to get it done and get onto the next thing.  Lots of opportunity to introduce bugs.

Once you’ve been labeled as someone who doesn’t produce quality work or that you are slow, it’s hard to recover from that perception because everything you do is looked at through that lens.

But this is true of pretty much any kind of knowledge work.  Evaluating Performance of Concept Workers talks to how most managers lack the knowledge to be able to directly judge the performance of knowledge work.  Therefore they use signals.  But these are clouded by perceptions. 

If your manager thinks you are not doing a good job, it’s very hard to overcome that perception and reestablish trust.  A third party can help a lot in this situation.