Talking about how to design better processes to get things done

Check out the full episode transcript here: NeverFriday.com - designing better processes to get things done

(From 2016, bringing it up into the new podcast!)

Hi I'm Rudolf Olah, and welcome to the NeverFriday Software Leadership podcast. On this podcast I talk about leadership in software development.

--

Today we're taking a look at cause and effect diagrams.

Cause and effect diagrams are one of 7 basic tools of quality. You won’t see them used very often in software development or IT projects. In other industries such as manufacturing, marketing and services, you will see cause and effect diagrams used everywhere. I've been on many development teams working on all sorts of projects from green-field to maintenance projects and not once has the team used a cause and effect diagram.

As a team lead or project manager or CTO, you will be the one to introduce cause and effect diagrams to your team. They won't go off and learn how to create these diagrams on their own.

Let's go over the advantages of the cause and effect diagram and why you should teach your team how to use cause and effect diagrams.

The first advantage is that you improve quality. You find specific causes and you can minimize or prevent the whole chain of events that caused the problem. You pinpoint and investigate the exact cause of a problem. Instead of a band-aid solution, you may be able to figure out a more comprehensive solution and have your team implement it.

The second advantage is that your whole team can be involved. Each member of your team has different perspectives and insights and can list causes that most of the team never even thought of. For example, the customer support team may suggest that the user manual isn't clear, or the QA team will suggest there wasn't enough testing done, or your developers could suggest that poor equipment was the cause of the problem.

By involving more team members, you reduce the biases that could prevent your team from solving the problem. By involving other departments, you involve stakeholders who will need to be on-board to implement preventative methods and measures for broader issues.

The third advantage is that you and your team gain a high level overview of the potential causes of a problem. This reduces wasted time. There's always going to be a developer on your team that just wants to rush right in to fix what they perceive is the root cause. More experienced developers are more likely to be correct but that doesn't mean your team should rush to try and fix things. Stepping back to a high level overview gives you and your team a sense of perspective and keeps priorities clear for your team.

So one more time. There are three advantages to cause and effect diagrams. First, they improve quality by finding the true root cause of a problem. Second, they can involve more of your team in brainstorming and collaboration and reduce biases in finding the root cause. Third, they give you and your team a chance to step back, keep priorities clear and gain a sense of perspective of the problem.

The next time you have a problem, try creating a cause and effect diagram and asking your team for their input. You may find it helps you get to a solution a lot sooner than you think.

--

Thanks for listening to the NeverFriday Software Leadership podcast. Check out neverfriday.com for more podcasts and articles on leadership in software development.

Brought from Neverfriday.com: THE TEAM LEAD AS COACH

Today I wanted to address coaching for team leads. What I'm going to cover today applies in other management and leadership positions, but the example I'm using is one specifically for team leads of software development teams.

Let's set up the scenario. You're a team lead on a web development team and one of the junior developers has been working on some code. It's time to check their progress in more depth. The code they have written after a few days is okay but could use some improvements, such as adding more tests or matching the code style or there could be a major architectural improvement. The junior developer is waiting on you to see how much rework they have to do.

If your first reaction is to jump in and just fix their code, then you might be a fixer. A fixer is a manager or leader who has the urge to fix things to meet their own high standards.

Jill Geisler discusses this in her article, “Are you a coach or a fixer?” and says, “Fixing is a temporary solution to an ongoing issue. Your employee or staff isn't really learning when you fix. If anything, they are learning to rely on you to upgrade things to your satisfaction, while not growing their own skills.”

For example, in our scenario, the junior developer keeps forgetting to follow the naming conventions of the project. When you're a fixer, you'll fix their code to match the naming conventions. The junior developer will have learned nothing from this and will not develop the right habits. They will come to rely on you to fix their naming convention problems in the future.

As team leader you need to move away from the fixer mentality and move into a coaching mentality. When coaching, you are developing someone's skills and knowledge so that they can become more developed as a person and as a team member. On a software development team, you are training your team to become better programmers. You are training your team to rely less on you by internalizing the right things to do.

Let's return to our scenario.

You choose not to be a fixer, you step away from your keyboard and walk over to the junior developer. You get into the coaching mindset and sit beside the junior developer and pull up the code on the screen. You walk through a few spots that you think need work and you ask them questions about the code.

Your goal is to lead them to find the better solutions for themselves and to figure out what improvements can be made. You lead them with a question such as, “have you considered an alternative approach?” Another good question is, “what was your thought process when writing this part of the code?”

And just like that, the junior developer has started to gain the skills needed to become a more mature and capable developer.

The best teams, whether they're sports teams or software development teams, have coaches. Coaching your team is far more effective than simply fixing their problems. One of the bonuses of coaching is that you'll feel less frustrated and less stressed. Team leaders can apply coaching every single day and see their teams grow as developers and as people.

--

Thanks for listening to the NeverFriday Software Leadership podcast. Check out neverfriday.com for more podcasts and articles on leadership in software development.

--

Links:

Are you a coach or a fixer: http://whatgreatbossesknow.com/?p=2052