Software without anger: managing the development team

Isn’t that a great title for an article about software development? If you’ve ever been involved in a software development project this would ring bells!

This was the starting in the first article on this series - Software without anger: managing vendor relationship which goes over the distilled wisdom of 15 years or so that we’ve been around in this business of making software for our customers. That was all about how to manage the relationship with the software team that’s outside your company, say for an outsourced project, or for a team of yours that works offsite away from regular face to face interactions. Today’s blog is about managing your in-house team of software developers, designers and QA professionals. I can never decide if it’s easier if the team is in-house, but I think an entrepreneur is just faced with a different set of problems which require a different set of solutions. So here goes…as promised - a list of - “distilled wisdom” :)

1. Expect and accept anger as normal in software development.

Umm, this the same as with the vendor relationship. Since the situation is the same, so I’ll do the infamous ctrl+C and ctrl+V

In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big, anger is natural. Anger is actually sometimes a good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive, that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

The only thing to add to this for an in-house team is, since you see the anger first hand, as it starts to pick up steam you have to move quickly. You should never leave a conversation that started moving to anger without diffusing it in the direction of a creative conversation. Striking while the iron is hot is the name of the game for this.

2. Create a culture of celebrating a dissenting voice

A dissenting voice is a voice that checks assumptions, tests logic and make the overall process stronger. It is almost always good for a software development process. The only time you don’t want a good “fight” in software discussions is when ego is getting involved and the discussion becomes a war of words rather than a debate based on logic. So you should make it easier for people to voice their concerns, actually make it welcome and celebrated. That way people will speak out, and feel that it is accepted and is part of the healthy brainstorming that goes on in a team all the time. Taking the taboo out of the dissent makes it feel like professional skill and somehow takes away the purely negative “anger” component out from a discussion where two sides have opposing view.

It’s a delicate balance, but once you create that culture life becomes so much better and your software too!

3. Have a clear and readily available set of requirements at all times

When I say requirements, I don’t exactly mean like spec documents or a bunch of mock-ups. I mean at any point of time the team should have access to resources that make it crystal clear what they are supposed to be making at that point in time. So, to do that you’ll probably need a task management system (e.g. a Jira board), a set of mock-ups that have been scoped and discussed for the task in hand, a meeting or two beforehand that clearly goes over what you are trying to build over next few days/weeks, etc.

As soon as the team knows exactly what they should be making you’ll find that the destructive anger that comes from confusion and that always leads to a blame game goes away. That’s the type of anger you can never manage and resolve easily. Take that out and half of your job is done in anger management in a software project!

4. Always have a confident “supreme court” for final decisions

That’s probably the team lead or the founder or even the designer. It’s not very important who it is as long as there is only one at all time, whose decisions, people know, cannot be overturned and obviously someone who is just (most of the times).

Most tech debates (aka anger) have multiple possible resolutions. Usually more than one of the solutions being debated works great as long as everyone accepts it. But tech debates comes with people who are married to their ideas (“I’ve got a unique solution that no one has thought of”), philosophies (“Java is the best”), past (“It worked for the last project”) and the worst - latest fads (“micro-services is the future”). Many times the only way out of a prolonged discussion, that starts to loop over the same few arguments, is a judge making a call and putting an end to the debate. Not easy to find a judge who can instill that confidence but it’s not impossible.

5. A gelled team is the only way out

At the end, nothing is better than a team that trusts each other, considers each other as friends and are happy to work with each other - a gelled team. Just as in a family or a group of friends high emotions and anger fizzle out because of the strength of their relationships, a gelled team can absorb and diffuse any anger. We have written extensively about gelled teams. This is our big mantra, our grand unified theory, our secret sauce at Kaz Software. This is what makes us good at what we do over and over. Read some of our past blogs for some idea, Two ingredient recipe for a great software team or 5 Easy steps to kill the deadly PDI in your software team or Burn the cubicles - in the pursuit of happiness or the ever so famous Barbecued dog is good for software :)

Since I have the 3 stooges always fighting in this series, let me end with one where they are a happy gelled team which they actually are.