
Ask HN: How do you convince your bosses to use the right tools? - codereview
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?<p>What has worked?
======
tobiasu
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.

------
darkxanthos
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.

~~~
michaelochurch
In my experience, the best tools are usually free.

~~~
GoodIntentions
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.

~~~
mcrider
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.

------
griffordson
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.

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

------
bmelton
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.

------
steveonthefly
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.

~~~
caw
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.

------
csears
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.

------
edw519
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.

------
pasbesoin
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.)

------
amoore
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.

------
rezrovs
* 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

------
ing33k
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.

~~~
michaelochurch
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.

~~~
objectatrest
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...](http://objectatrest.wordpress.com/2012/03/27/one-process-two-process-
red-tape-duct-tape/)

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.

------
trusko
Become one of them and you make calls then.

------
sxsde
Nothing.

