Choose Your Weapon
How to Select Software Engineering Tools without Inciting Team Rebellion
My favorite documentary, “Jiro Dreams of Sushi,” explores the philosophy of Jiro Ono, a man many consider the top sushi chef in the world. In the film, Jiro explains that in order to serve the world’s best sushi, he must only work with vendors that provide the very best ingredients. His rice producer offers the highest quality rice available in Japan, and his tuna supplier selects only the finest fish. Relying on their expertise enables Jiro to specialize in the preparation and presentation of the perfect sushi meal.
We also must select several vendors when building software products. You probably wish that every tool in your technical arsenal was the very best one available on the market. But, unless you’re the technical co-founder of your company, many tech stack choices were probably made before you arrived (e.g. operating system, programming language, database, web server, web framework, JavaScript/CSS frameworks, etc.).
In addition to the technical ingredients, teams must choose the tools they use to build their product. That all adds up to a ton of choices! Just take a look at the list of tools and technologies used to build Stack Overflow and you get a sense of the total number of tool choices that we make. Here’s a quick list I made of tool categories and popular options available in each area:
I’m sure you can think of more categories and tool options. This is where things can get contentious. We all have favorite tools that we’re passionate about using for certain tasks, but our colleagues and members of other teams might feel just as strongly that another tool is much better. Who is right? How can we decide which tools to adopt, and which ones to abandon?
These are important decisions not to be taken lightly. Here’re are a few tips that can help navigate the process of selecting your tool set:
1. Do Your Homework
Doing your due diligence will pay dividends later when you start persuading others to adopt a new tool and are asked to justify your choice. Did you discover an awesome new messaging app, but aren’t sure if there are better options out there? Sites like AlternativeTo allow you search for a product and discover similar options. Quora is another good source where tech experts often answer questions about which tools are best for certain use cases, and share their own experiences. It’s also good to search the blogosphere to read reviews and find the other options available. While it can be fairly quick to find info online, there’s no substitute for a face-to-face chat with your peers. You can try soliciting opinions from folks in your company, community experts at tech meet-ups, fellow conference attendees, or on Twitter.
Keep in mind that our homework assignment doesn’t end once you select a tool. You’ll notice some tools on the list above didn’t exist five years ago. As new best practices emerge and competing vendors enter the market, you’ll need to spend some time reevaluating your current tool stack to ensure you’re always using the best options available.
2. Be Thrifty
You don’t want people to think you’re carelessly burning the company’s money. These days, there are free open-source software options for many, if not most, of the technology components you’ll need. Investigate the range of prices within each category, and if a vendor charges more than the competition, make sure they are providing enough value to backup that price tag. Most vendors offer 3-tier pricing, so the Free or Pro versions may do everything you need, while the Ultimate Edition is overkill. Does the whole team really need Visual Studio Enterprise licences at $5999 each? That costs more than my car is worth!
That said, sometimes tools are absolutely worth the price, and the value they produce in time savings is absolutely worth the money. Just remember that budgets are limited, and getting support for new tools is usually easier when they don’t break the bank.
3. Run a Small Experiment on One Team
Rolling out high-impact tool changes in a large organization can require a lot of buy-in and signatures. There are often training and time investments needed before transitioning to the new tool. Maybe you aren’t ready for all of that, because you’re not yet 100% convinced that this new tool will be as awesome as you hope once it’s in wide-spread use.
Instead of a big bang roll-out, try using it as an experiment on a single team. If the team hates it, the experimenters helped prevent the whole company from experiencing the pain. If they love the tool and are getting a ton of value, they’ll be a case study that you can point to later. When a tool trial ends up being a huge hit, these early adopters will be it’s biggest advocates, helping you explain the benefits to others.
4. Socialize the Proof of Concept
After you’ve experimented with a tool and verified that it’s amazing, either on your own laptop or on a trial team, it’s time to start showing it off. The more disruptive the tool is to a teams’ previous workflow, the more support you’ll need. Think about the various teams affected, and pitch them on the benefits. For example, if you’re a developer interested in using a new DevOps tool, show it to the System Administration team. Explain how it’ll make their live so much easier, allowing them to spend more time on other more interesting challenges. Then, show it to the QA folks, and discuss how it’ll add consistency to the deployment process and eliminate user error.
The more people that see your demo, the better. You can note any concerns they bring up, and do more homework to see if you can address them. If you take the time to get buy-in from people affected, they’ll appreciate the fact that you included them in the discussion. That can make a big difference if executive management asks around for opinions before approving your choice of tools.
5. Write up a Blog Post
In this age of distributed teams, it may not be possible to swing by everyone’s desk to chat about the awesome new tool you found. The teams impacted by a tool change might be in other cities or may not be people you meet with regularly. Sometimes it’s best to type up your thought process into a concise, informative blog post. You can then publish it on the company wiki, send it in an email, or share it on your personal blog. Be sure to explain the problem the tool is solving, the findings from your research, and why the product or technology you support is better than other options.
Your writing may gain supporters for your tool in unlikely places. It can also generate more general awareness of your goals, which can help speed up future discussions with folks who read your post.
6. Form a Committee
This is a last ditch option. Only use it for tool decisions that are very controversial, highly disruptive, or really expensive. In these cases, forming a committee ensures that multiple opinions will be considered, and allows the rationale behind the tool selection to be shared by documenting it in a summary report. After the dust settles, when people start asking why the committee chose Tool A instead of Tool Z, you can then point them to a wiki page that lists all the options considered and explains why the group thinks Tool A is definitely the best choice for our company.
7. Don’t Get Your Feelings Hurt
The larger your organization, the fewer tool choices you will probably make personally. Many choices will have been made before you joined, and switching to a new tool now may not be worth it. Some people might select tools you think are inferior, either because they have different needs, or maybe they are just more persuasive when it comes to communicating their personal preferences. You won’t win every hotly contested argument about which bug tracking system is obviously the “best ever.”
When your favorite tool isn’t selected, it’s a good time to practice Amazon’s 13th Leadership Principal: Disagree and Commit. The team will be using some other tool, much to your dismay, but presumably this tool still does a decent job of solving the problem. Become an expert in it, discover all it’s hidden features, and you’ll be seen not as a sore loser, but as both flexible and helpful. People will trust you more when it comes time to make the next big technology decision.
Conclusion
Wow, seven steps! Seems like a lot of effort, right? Yes it is, because choosing tools is hard work. It’s hard because it’s important. These aren’t easy decisions, as some emerging tools may not be ready for prime time. Adopting new technologies can be socially challenging, but it’s essential to staying relevant and ahead of the curve.
Also, getting stuck using outdated tools and sub-par services is a huge risk. You could be missing out on substantial cost and time savings, as well as powerful product-enhancing innovations. Are you able to tell potential hires honestly that you work with cutting edge technology? If your company is stuck in the dark ages, documenting requirements on stone tablets and communicating with carrier pigeons, it may be time to considering working somewhere that evolves along with the technology ecosystem.
Despite the risks and challenges, selecting superior tools is an important skill to practice and improve. Great tool choices can lead to major productivity gains. If you choose wisely, your team will feel empowered, and your customers will love the results.
