Picking the Right Tools

Could you survive out in the wilderness on your own? No food provided. In the middle of nowhere. Just yourself and a few sets of tools. Would you make it?

It’s the premise of the aptly named show Alone. You might have heard of it.

I’ve only recently discovered the show, but I must say: it’s thrilling.

And as I’ve watched the show, I’ve thought a lot about the tools each contestant brings. Did they make a list of possible items and compare their utility with an algorithm, or did they copy other contestants’ lists from prior seasons? Did they wing it?

We find ourselves in similar, but not life-threatening situations in software. Tools, frameworks, vendors, etc., abound in our quest to build great products for our customers.
​
Many questions emerge around this topic: How do you pick these tools on a budget? When does it make sense to buy vs. build? What do you do when you find yourself “stuck” with the tools you’ve chosen so far (dreaded vendor lock-in)?

Today, I'm sharing a handful of first principles I've been considering to help you answer those questions.

Team Building Exercise

This week's Team-Building exercise is to answer a simple question as a team:
​
What tool are we missing?
​
While it's a simple question, the answer is likely hard to come up with. You must know your current pain points, your available toolset (and the gaps they have), and what needs you anticipate in the coming weeks/months. Some engineers are thinking about better collaborative tooling; some might see a gap in observability, while others might think about missing platform capabilities. Whatever answer people give, seek to understand why they see it as a need.

After everyone has answered, try picking one or two tools to make headway one. Assign action items to research and formally propose a new tool to the team or organization. Even if it's a long shot, it is worth it if the whole team sees the need.

As I mentioned in the article, you don't want to spend too much time doing this. Timebox these efforts to a week or so (if that) to avoid wasting time. Of course, if you do find a really incredible tool that fits your needs, don't be afraid to make a great pitch when it counts.
​
Aside from getting to research the tool landscape and possibly get something stood up to use, I bet you'll discover new ways to leverage your existing tech to accomplish some use cases you didn't think about before. Sometimes, seeing what other people are doing can inspire you to do something interesting or similar yourself.
​
Happy coding!

Here are some more resources from me to help you build better teams!​

Other Creators I Recommend

Build It Better Newsletter by Jonas Fleur-Aime Creating great software is not just about completing new features faster, submitting more pull requests, or fixing bugs. Every Wednesday I publish tips and tactics to help you meet tough deadlines, tackle tech debt, handle scope creep, manage stakeholders, make sure you're building what customers actually want, and more. I'll draw on what I've learned after spending 15 yrs as a software developer, Engineering Manager, CTO, and startup advisor. Subscribe​

​

113 Cherry St #92768, Seattle, WA 98104
​Unsubscribe · Preferences​

​

​