5 Whys is a blog about technical leadership in the software world.

Joining Forces with other leaders to make change happen

Let's say you're trying to make some real change happen. Maybe you've just finished doing a course on unit testing, and your development department devs are all excited about making this a reality.

But some devs are very sceptic that this can happen. They've been burnt before with some of the same people who just did the course. They've heard some promises that weren't kept before, form the same leaders that made this course happen. So they don't think something else will.

You're the team leader in one of the teams that took the course, and you think it might happen this time, about 50% chance. But how do you help make this effort a success?

Your manager is the one who promised that dev time will be increased by at least 100% for a few months until unit testing gets into the blood of the company, and you might be a bit sceptical.

In this very scenario it's impotant to gather the other leaders that lead the dev group : other team leaders, architects and heads of other departments like QA. It's important to display a united front about wanting to make this a success.

It's important to not show any different of opinion on weather it will or won't work, and discuss skepticism towards any of the other leaders, in private, face to face conversation.

Your teams need to see a unitited effort to do this. Seeing mommy and daddy fight only creates more stress and disbelief. If people are already cynical, you don't need to add to that fire.

By displaying true and honest wanting to become better, by being humble and saying you might not know everything there is to know about this subject, you are letting others see that you really care enough, even if you're changing your own skin to do so.

It's also important to focus on one thing that gets better every time. If you're learning unit testing, don't stress design and styling too much in your code review. make the effort to let some things go and choose your battles to be on the quality and rightness of the tests.

Dont' disrespect any of your team members or other leaders in public. or in private. not even in humor. Everything is taken into account when people need to make a decision of how commited they are to do change. if they get pissed off at you within 10 seconds of the start of a code review, you lose hope of them playing ball and making real changes. Not for you, anyway.

The architect as a leader, and other specialists

Contribute a note to my upcoming book - Notes to a software team leader