Tuesday, March 16, 2010

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.

8 comments:

Unknown said...

"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"

Actually, there's been multiple instances during an interview where I've thought "If they had asked me that when I was a freshman, I could have answered easily." I forget the things I don't use.

Tony Karrer said...

G - were you not able to answer it in the interview?

The questions I'm talking about are data structures / coding type questions. This should be something that is ingrained in a professional developer.

Adam Kaufman said...

Tony - great post and quite insightful.

Upon reflecting I would add a new consideration in working through the development / analysis relationship.

It is possible that expectations on both sides are not aligned and clear metrics (agreed upon by both teams) are not in place to measure success. It is very hard to assess capacities and delivery if the metrics are not consistent and are not consistently compiled.

Tony Karrer said...

Adam - great comment. It's all about expectations. What will get built, what stages will it go through, what types of bugs can be expected, how will they be handled.

Metrics is an interesting term. Not sure I buy that they have as much influence as the answers to the expectations above (which aren't normally treated as metrics).

Unknown said...

@Tony
Ah, I guess in my case the questions were language specific (C++)

Steve Howard said...

Seems like for most of these issues, a good project manager would be on top of them and have them addressed as soon as they emerge.

Therefor, what might look like a week team can simply be the result of poor project management,.

Tony Karrer said...

A good PM can surface and potentially mask some of the symptoms of a weak development team, but they won't really fix them.

Unknown said...

When recruting developers I and my team like to ask them to present an example or two of their own code that addressed a particularly interesting problem, explain how they approached solution. You find out both about their communication abilities they have to explain the problem/solution, but they are talking about their own work which lowers the stress. Of course, if they can't provide any examples, or the problems/solutions are not that interesting, it tells you quite a bit.