Help that treats the symptom, turns into a dependency

The cost of helping a person or the project can hurt a developer if it becomes a long-term process of shifting the burden onto the developer.

We are told helping people is good but If it turns into a long-term arrangement; you don’t help the person improve and give yourself less time to do your job.

Helping treats the symptom, the root cause is a broken system.

In some scenarios, developers need to think long term, their own priorities and the whole system, e.g. help the person do their job instead of doing it for them.

Example — Give work to the willing

On a project, there was a developer who was great and got things done quickly. The developer ended up with tasks and responsibilities that were nothing to with the software project they were working on.

People kept asking him to do tasks and giving him tasks because he did them quickly. It was better to ask this developer than the person who should do it because they were slow.

As well as developing, he had the responsibility to create environments, deploy between environments and DevOps. He complained he couldn’t get to the bottom of his todo list.

We looked at his additional responsibilities

• Requesting access to AD groups for other projects
• Setting up certificates
• Renewing certificates
• Giving licences to users
• Answering all questions about environments and functionality from users
• Lots of other similar tasks

The developer has slowly gained responsibilities from other teams and was being crushed under the weight. The developer didn’t have time to do his work and these other activities..

People had taken advantage, gone to him as a shortcut, and it had turned into a habit. I staged an intervention and started giving the responsibility back to their rightful owners.

This accumulation of tasks is a common problem of helpful developers, it helps everyone else except themselves.

Software development is a system

Software development is a complex system with different people doing different roles with different responsibilities. (read more here — A Cautionary Tale of Parachuting Cats Helps Explain Why Adding More Developers to a Project Can Make It Later)

It doesn’t work individually but works when everyone combines to make a system.

• SME — business knowledge
• BA — create requirements
• Developers — create software
• Testers — test software
• Project manager — manages the project and plans

There are other roles but it needs everyone to do their job

What happens to the software development system?

Each role and team have different responsibilities. Different people have different levels of skills, knowledge, experience, desire and effectiveness.

Throw in different political goals and you can get problems. In the short term you see problems. Step back and you will notice these problems are symptoms of the system malfunctioning.

What the heck is a system's malfunction?

If all people and teams do their role as planned, the entire system works. Systems have multiple related entities and inputs, outputs, and feedback loops.

Changing parts of the system affects other parts of the system. A linear approach which reacts to symptoms won’t fix a system problem. System problems are unintended or problems that appear later (delay)

Example Symptoms

Development team are creating software slower than planned.

Slow development must be the developers' fault, shout at them and then add more developers to go faster.

The problem could be the quality of requirements, and they keep changing.

It could be caused by slow governance and decision making.

Addiction — doing someone else’s role

There are people who are not doing a good job for many reasons (inexperienced, not interested, unskilled, timid).

The short-term fix is the better members of the project take up the slack and start doing their role plus parts of other roles.

When you help someone repeatedly, it creates expectation and dependency on doing it again. The person become addicted to your help intervention.

The result is the person does many things at a lower level or they extend their working hours to accommodate doing extra work.

The long term negative effects is this can lead to frustration and burnout. It’s a short-term fix which ignores the real problem and never attempts to fix the real problem.

You need to fix the system problem. The person needs to get better at doing that role, move to another role, or be replaced.

Burnout

It’s important to look out for burnout in yourself and other developers.

Software development is a long term creative process. It needs people refreshed a d energised to create and collaborate. Overloading people and working too many hours eventually wears out the energy, enthusiasm and input of your best people.

Burnout often leads to people leaving the project and the company. It can be significant because if they are burnt out, they were usually playing a key role and take multiple people to replace them.

Solution — think long term

Like technical debt, the best way to avoid taking other people's roles or creating dependencies on your time is to not let it happen.

Helping people and doing other people's jobs will mean you have less time to do your tasks and priorities.

You need to understand what you should do and what other roles should be doing. This can be difficult because roles overlap and often it’s not clear who should do tasks.

1. Understand your role and responsibilities (e.g. what are you responsible for).
2. Understand other roles and responsibilities

Don’t choose the easy option of giving answers, instead coach people into looking in the right areas or pointing them towards the person who should do this role.

Say no

“The difference between successful people and really successful people is that really successful people say no to almost everything.” Warren Buffett

Don’t be afraid to say no if people ask you to do things you are not responsible for. You don’t need to be rude, but you want to stop them from dropping their problems onto you.

Question — Can you Test this code to see if it works

You — Jim is responsible for testing, please put the request to him

Question — How does this functionality work

You — There is documentation and videos available on the wiki, just search for case management.

You might think this sounds harsh, but doing the work for someone else doesn’t help them in the long term. When you do the work for someone else, they don’t fail and they don’t learn to do it themselves.

When you do something for someone, you rob them of the opportunity to do it and get better if they need to. There is a fine balance between helping and hurting people. If someone isn’t good at a role they need to improve.

In some situations, the solution is for the person to move to another role, which they are better suited for. Hiding the fact they aren’t good at a role, prolongs their pain of doing a role they can’t do.

When people are doing a really rotten job, it’s usually because they don’t like the job or aren’t suited. The best course of action is for them to fail, so they need to confront the situation. They either improve or the get replaced.

People can be grateful for being removed from a role they didn’t like. It was a relief. It’s difficult to admit you can’t make a role work and many people will hang on in there.

The Peter Principle contributes to people in a role they aren’t good at. In most cases people have patience when they can see someone is working hard to improve and getting better.

The bigger picture is the person is not performing well and they hindering everyone on the project. It’s an issue that needs to be acknowledged and handled.

The simple solution is for the quick fix of helping them, but this turns into long-term pain of some people being overworked and some under working.