What does kill IT projects?
Management

What does kill IT projects?

What does kill IT projects? What you should avoid, at all costs, to ensure the success of your startup or software project
Bartosz Mikulski
Bartosz Mikulski – 5 min read

What does kill IT projects? Over-ambition? Sometimes. But not as often as a lack of ambition. Too small budget? Yes, but that’s easy to fix. Incompetence? No, unless you combine incompetence with two more things:

Apathy and indifference

“No kerosene today,” the storekeeper told her on her next trip to Woodstock. “It rained Thursday night, and when it rains, the trucks can’t get through Fairfield gorge, the road’s flooded, and the kerosene truck won’t be back this way till next month.” “If you know that the road gets flooded every time it rains, why don’t you people repair it?” The woman answered, “The road’s always been that way. “

“Atlas Shrugged” Ayn Rand

Apathy and indifference will kill all projects, not only in IT. It’s way worse than incompetence alone. What happens when you combine all three? You have a person (or an entire team) who doesn’t know what they are doing, doesn’t care, and doesn’t want to improve. Good luck building your software.

What does it look like? You may have a team member who always does everything the hard way. You tell them to write tests. They answer, “Yes, I could write tests for that.” And never do it. You show them how to write tests. You hear the same answer. You write some tests to get them started. They don’t look at them and continue doing what they did before.

To add an insult to injury, some will talk at length about all the effort they put into writing code. They wasted lots of time doing manual testing and debugging. Now, they waste your time during meetings because they have to tell everyone how difficult it is to debug. At the same time, they tell you they can write tests. But they never write any.

You don’t get an extra medal at the Olympics for being the most tired athlete. Do you get bonuses for spending a week on a 4-hour task or working on a weekend because you have to catch up with the work? Do they pay extra for being inefficient? Maybe I’m missing something.

A lack of skills alone isn’t a problem. I teach people all the time. I can deal with inexperience. Teaching people how to code is not a problem when they are willing to learn. I don’t know what to do with apathy and indifference.

What else may happen? You have a senior developer on your team who spends most of the day browsing the Internet, drinking coffee, planning where to go for lunch, going to lunch, etc. The senior developer does everything but work. One day, he estimates how much the company has spent on the project (the sum of developer salaries * project time in months) and announces that he could get it done alone in a month if they paid him 25% of his estimate. No, he can’t. Not in a month. Not in six months. Talk is cheap, but getting something done requires doing. Basically, wherever the work happens, the apathetic and indifferent ones aren’t there.

What can you do about apathy and indifference?

What can you do when you already have such people on your team? Motivate them? It won’t work. Those people are productive only at finding excuses and new less-efficient ways of working. You can’t do anything. It’s too late. You have made a mistake while hiring. You should have hired a person who has actual experience in doing something. Being on a team of people who get the job done doesn’t count as experience.

How to hire productive programmers?

How to filter out people with experience from people who spent time in the room where work happened? People who have done the job know the details. Ask specific questions about their projects.

If they deployed ML models, ask how they handled access control. The person with no clue will try to hide behind an NDA or answer a question you didn’t ask. For example, instead of saying how they implemented access control, they tell you why access control is essential or tell you a story about a problem with access control. If you hear a story, it’s not bad yet. The story may introduce an explanation of what they have done and why. But sometimes, the story is a coverup for lack of knowledge. They start a lengthy monologue to make you forget about your question. The worst offenders repeat the exact words when you ask your question again. I wish I were kidding.

Is it enough to hire someone who has done the work in the past to avoid problems with apathy and indifference? No. Past high performance doesn’t guarantee future results. But the opposite is true. Past low performance ensures a lack of results in the future.

Creating a high-performing team

What else? Don’t kill their motivation. If you hired a competent and motivated person, don’t put them on a team with “Dementors” who suck the will to live and work out of them. Don’t make them the only person who cares about quality or getting the work done. If you put an Olympic swimmer in the water and two people grab their legs, all three will drown. The easiest way to demotivate competent employees is to tolerate incompetence.

Most likely, you will be afraid to make the right decision. Nevertheless, if you have a useless team, get rid of them first. Hire a replacement later.

Older post

How to write a growth plan as a programmer?

How to write a growth plan that helps you get promoted and doesn't get in the way when you want to focus on your hobbies

Newer post

Using Abstraction Layers to Tackle Common Problems with Legacy Code

Are you struggling to manage and update your legacy codebase? In this article, I'll show you how to leverage the power of abstraction layers to overcome common challenges with legacy code.

Related Posts