Behavioural traps in software teams.

In my experience of software teams, there are a few behavioural traps that leaders (senior stakeholders, managers, product owners, etc.) fall into repeatedly, and that developers aren’t good at handling. Whether a leader or developer yourself, see if you can relate to any of these.

So were your developers. In fact, they’re probably feeling the pain of not delivering on time a lot more than you are.

It takes guts to look a leader in the eyes and deliver them news you know is going to be disappointing. If you only ever hear that deadlines are going to be missed at the last minute, it’s because your developers have incorrectly delayed having that conversation until it was an absolute certainty it would be needed. Ask yourself why that might be.

Leaders — When you‘re told a deadline won’t be met, express thanks — for the hard work, for being direct about it, and for any early warning you’re getting. You’ll rewarded with honest estimates, more frequent updates, and happier developers in future.

Developers — Always be open and honest with your confidence on estimates. When deadlines are going to slip, make sure you speak up, articulate why, and have an adjusted estimate in mind. It’s often useful to think about ways scope could be reduced to keep things on track too.

These are fine questions to ask if you’re actually interested in spending time on getting an answer, but they’re usually asked rhetorically with a hint of anger. While nobody is messing things up on purpose, it’s also very easy for developers to sweep major bugs and security issues under the carpet if they’re afraid of the reaction they’ll get by raising them.

Leaders — Again, thanking your developers is your best course of action. You can then ask them to find out the impact on customers and get an honest, useful answer. From there, you can shield your developers from the rest of the business so they can concentrate on fixing things.

Developers — When reporting an issue, do your best to come prepared with a human explanation, an idea of the impact on customers, and a suggested plan of action (with timescales). This is much more useful than just letting people know everything is broken. Once the problem is resolved, figure out what can be done better next time and make adjustments where necessary.

Repeatedly asking for status updates harms your team in a few ways. First, it forces them to context switch away from tasks that require focus to do well. Second, it often comes across as pressure to finish, meaning quality gets sacrificed for speed. Third, it doesn’t recognise or address the underlying gap in communication.

Leaders — If you’re repeatedly chasing status updates, you need to make them part of the development workflow so a single written update is linkable and accessible to all stakeholders. This way, your developers can update at a time that doesn’t force a context switch, and if you check the status of everything going on in one place without bothering people or making them feel hurried.

Developers — You’re responsible for keeping stakeholders up to date. If you’re asked for an update, either link your most recent, or add one in the agreed system and then link to it. This will encourage people to go check the proper channels for themselves, and get you into the habit of writing them.

When presented with a problem, your subconscious will often do the work of finding solutions for you. This is helpful, but as a leader remember to resist the urge to prescribe solutions; they can rob your developers of the opportunity to think for themselves.

The end result of this behaviour is that you end up frustrated at the lack of apparent common sense in your team, and your developers lose any sense of autonomy in their work, or feeling of respect for their ideas.

Leaders — Share problems, and your thoughts around potential solutions, but encourage your developers to think of alternative solutions and always get their feedback. You’ll be surprised at the ingenuity of even your most junior team members when they’re left to figure things out for themselves.

Developers — Don’t blindly accept technical solutions given to you. Always make sure you deeply understand the problem that’s trying to be solved and the constraints around it, and see if you can think of a better way forward.