The New Tool Nobody Asked For🤔

It’s Monday morning.

I look at my calendar and there is a meeting with a third-party “Introducing Our Developer Tool”.

What could possibly go wrong?

Isn’t it obvious. “synergy”, “efficiency”, “scalability” and a programming demo from a salesperson who thinks SOLID is a property of an object that cannot easily be changed. When asked for a copy of the code they said “I’ll get back to you on that one”. 

The whole thing was a sales pitch. This keeps happening. I guess this is my life now.

The Disconnect

The problem with new tools isn’t the tools themselves, as new tools and new ways of doing things is exciting and stimulating for developers. 

The problem is how they’re selected and implemented. Development tools are often chosen by people who never have to use them, and have chosen them on the basis of a salesperson who doesn’t understand the problem that needs to be solved. So decisions are based on flashy demos and promises made by a charismatic sales team, not on the actual needs of the people in the trenches who are seldom asked.

So developers find themselves required to integrate these tools into their workflows whether they make sense or not, and if they don’t go along with the flow risk getting called a laggard (or worse) and put themselves in the firing line of the next wave of layoffs.

Could the money have been better spent hiring another engineer to actually solve problems that are in the codebase? This is also not helped by tutorial sessions that are simply sales pitches, to the wrong audience.

My Experience

Once a senior developer without any management responsibility wanted me to log in during a personal day to learn about a third-party software solution for our onboarding process. My response? “The reservation for my Mother’s birthday lunch can’t be moved, genuinely”. I’m still annoyed that someone tried to make me give up my personal day for a sales pitch though.

I remember that this session was followed up by more (that I attended). The subsequent sessions wasted my time, and I can’t imagine how angry I would be if I lost personal time to the same sales pitch.

Why This Happens

The root of the problem is simple: tools are seen as a shortcut to fixing systemic issues. A development team struggling with communication doesn’t need a new Slack alternative — they need better communication practices. A team that can’t meet deadlines doesn’t need a fancy project management tool — they need realistic timelines and proper resourcing.

But tools are an easy sell. They’re shiny, tangible, and come with the allure of instant improvement. The hard work of fixing workflows, fostering collaboration, and building trust doesn’t come in a neat little SaaS package.

What Developers Should Do

We should communicate that instead of throwing money at new tools, try this:

Push Involving the Team

Let us developers evaluate the tools. They’re the ones using them, after all. What looks good on paper might not work in practice.

Solve Real Problems

Don’t let your business adopt a tool because it’s trendy. We should adopt one because it addresses a specific challenge your team faces.

Ask for Proper Training

Don’t link to a sales video and call it onboarding, and fight anyone who dresses up a session in this way. Call out issues as soon as possible to address any issues.

Iterate and Adapt

Understand that no tool will be perfect out of the box. As developers we need a tool that can be customized and refined as it is used.

Conclusions

Developers don’t hate new tools. They hate new tools that are chosen without their input, solve problems they don’t have, and come with expectations that they’ll somehow make up for poor planning or bad workflows. Tools are supposed to make life easier, not add to the chaos.

If you want your team to adopt a new tool, make sure it’s the right one. Otherwise, save everyone the time and effort. It might be better to just splash the cash to buy us pizza instead.