Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do you convince your bosses to use the right tools?
31 points by codereview on March 27, 2012 | hide | past | favorite | 26 comments
How do you convince your bosses to cough it up for the right toolset (whatever that is on your team)? Whether it's an IDE, refactoring, unit testing framework, build server, or whatever else?

What has worked?

I find the "saves money" routine a bit transparent. It deprives your boss of the satisfaction to have contributed something important. Let your boss save the money, get the tools you want or need.

How? Simple, compare two solutions, write up advantages and disadvantages and present them. Since you have already made up your mind, you're biased to the thing you want anyway. Your boss will usually see your point and make the right decision.

I don't work at places that aren't already coughing up for the right tools. Literally. I have declined jobs because of this and would leave my current employer if this happened.

In my experience, the best tools are usually free.

It depends on your level of expertise and the type of tool. For instance, Sphinx to write documentation is free, but you need to have at least a desire to write in markup to create it, and I'm assuming that single-sourcing multiple user manuals with conditional text and variables is not exactly trivial. Plus, sharing the writing of such a user manual between more than one person requires the use of a third-party solution, a version control system, which also requires some training & expertise to use properly.

Where as, on the other hand, if you can convince your boss to dish out $200 a month per user for something like Author-It, you get an extremely powerful system that does everything an authoring tool is supposed to. That's what I'm trying to do right now with my boss, convince him to switch (not from Sphinx, but from another cheaper software solution called Flare), and it's not an easy task.

I've found a great deal of resistance in using free tools.

Tools that cost 4 figures seem to sit "just about right" in the managerial mindset where I come from.

Some managerial cultures seem to really ( _really_ ) want to see cash laid out for anything before they will believe it holds any virtue.

I'm in the opposite situation -- I work for an Open Source project and using anything but open source software is pretty much a last resort, even though there are some (cheap) paid solutions that are better. Even free SaaS products are seen as bad as we don't 'own' the code (even moving to Github was a tough transition -- and we were using CVS!). The only way to move to one of these products is to use it on my own (as someone else has mentioned) and continually make the case for others on the team to use it.

It's true that sometimes the best tools are free, but there are a lot of organizations where you are not allowed to use even those free tools as they are not approved by some legal or IT department. The fact that those tools are free doesn't make a big difference for BigCo types of organizations.

Big companies don't usually go for free, because of the risk involved.

To answer op: Nothing. Been trying for a long time, but no luck.

Considering I am working in a construction company I couldn't disagree more.

The best tools are the ones that cost less than they make you save.

30" monitors....

Become the boss. But you may find that your arguments aren't as persuasive as you thought they were once when you are the boss.

Didn't see your comment and wrote pretty much the same. That's what I did.

Things that have worked for me in the past and present:

1) Just use them. When you're demoing the product after a certain amount of work, explain how this new tool you've incorporated has benefitted the project in some major way.

I got Django accepted into the federal government doing this in what I believe was its first deployment (agencies don't generally talk, so there's no way to confirm that.)

Python was an accepted language, so I just wrote code in Django, explained how its use 'as a library' would expedite future releases, enable RAPIDER development and keep a clean, structured codebase, which was something they were having troubles with.

2) Choose products that actually DO provide benefit to the project. Sometimes it's hard, as a developer, to know the difference between "I want to use the Play Framework for this" and "The Play Framework is the right tool for this job." I often struggle with this myself, as I want to learn new things, and it's easy to get caught up in a new toy's feature list, and directly apply that to pain points you're having currently. When I was learning Ruby, I saw it as the tool to fix a lot of problems. Then, when I was learning Python, I saw the flaws in Ruby, and laughed at how I ever thought Ruby was the right idea. This isn't meant to be a slight on Ruby, as I'm guessing if I'd learned them in reverse order, I'd have had the reverse opinion.

It wasn't until well later that I got a good baseline for what each was actually better at (aside from the marketing points), and how to determine which one might fit a project better. It was even longer that I could make an emotionless decision to determine which actually made more sense _for a given project_.

If you have a real, valid reason to select a new language/framework/tool, and can both express the pain point to your boss, and illustrate how this new solution can reliably resolve that pain point without introducing equally sized, but different pain points, then it should be an easy sell. If you can't illustrate that, you might be a victim of your own personal bias. Don't feel bad, it happens.

Arguing that they'll get a decent return on investment. If your boss can't see that a £x outlay now will mean n * £x savings in improved efficiencies during a given period, you'll probably end up leaving to work for somebody who does! I know I have.

This is right. You always have to argue the business case to management. If you can turn X into a factor of cost, you can sell a lot of things. Even if you think the benefits are obvious to every party involved, you'll still need to stick a dollar value on there. I just recently joined a strategic team to make an improvement that literally everyone knows is a problem, but one of our first things to do is quantify so we can determine the ROI for our efforts.

Put yourself in your boss' position and imagine he had to turn around and pitch your idea to a VP. What ammo can you give your boss to make that next-level conversation go smoothly? How does this new tool solve some problem the VP has been on your boss to solve?

Mention a competitor or partner company already using this tool successfully. Tell him what business metric will be positively affected by adopting the tool.

Timing can be critical so watch for the perfect moment to pitch your idea -- like ahead of a management meeting where your boss needs to talk up what your group is working doing.

But above all, be honest about the costs, benefits and alternatives. Good luck.

The answer to any question starting with "How do you convince your boss..." is always the same:

Give them an easy way to present it to their boss as their idea.

I've worked in more than one organization/department where management insisted upon "using the wrong tools".

In retrospect, the answer was / would have been always to leave.

Not only does it reduce your productivity while increasing your frustration. It marginalizes you in your career.

Get out, and look for some place interested in helping you maximize your potential.

(Note: This assumes you really do know what the best tools are, for a given circumstance. Inform yourself -- don't just assume.)

Don't forget that you may have to spring for some things yourself. If you worked with physical tools, like hammers, hard-hats, or calculators, you may have to provide some or all of them yourself. So, don't be afraid to bite the bullet and buy a license for a piece of software that will help you do your job better.

* Tell them how much money and how much time it saves.

* Where possible convert time into money.

* If it costs a lot of money, tell them how long it will take to recoup the investment.

* Give numbers.

* It is possible that your boss does not control the purse strings - so when you give your numbers make sure it's in a format that they can forward to their boss with few changes

Depends on your position . I will just tell that my productivity will be decreased if I don't use the one which I believe is best.

Dangerous move. Not to say it isn't worth doing, but I've seen it get highly competent people fired. You need to understand that managerial training and experience turns nice people into suspicious, cynical assholes and that you're in danger of being interpreted as threatening, "I'm going to intentionally slow down if I don't get what I want". It's not what you mean, but it's how it will be read.

Now, career stagnation, which is what you get if you never speak up, is a lot worse than getting fired, which is surprisingly easy to recover from as long as you have the savings. You just have to be aware of the risks of each avenue.

Managers also tend to underappreciate the importance of proper tooling in developer productivity (the commodity developer fallacy) and they tend to view such discussions as "distracting". From their perspective, Java's popularity is a vindication of its value. So many languages and methodologies have been oversold for decades and managers don't know which of these are real (e.g. functional programming, which provides a long-term 2-4x improvement in programmer productivity) and which are bullshit hawked by overpriced consultants.

What I've learned is that it's better to use the best tools anyway, deliver software using them, and use existing accomplishments to make your case. Results talk. It's better to ask forgiveness than permission. If you deliver something awesome that helps the company, people are going to overlook what language you used.

I agree that the best approach is to use a tool and deliver well built software. For every pragmatic tool you recommend some highly paid consultant or senior dev has tried to pad their resume by getting them to buy $100k of unneeded infrastructure and tools that failed miserably.

Also, some companies will not budge no matter how you present it you are better off working around the heavy process that is slowing you down. Or switch companies. Or voice you frustrations into the void of the internet like I did. http://objectatrest.wordpress.com/2012/03/27/one-process-two...

Each company is different and there is no silver bullet. You need to find out what the managers value (money, productivity, looking good to their superiors) and build a case on that.

Become one of them and you make calls then.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact