Don’t Blame the Tools Link to heading

I’m sitting in another long running meeting that I colloquially call “Engineer Therapy” sessions. They are important; I mean it is critical that we have opportunities to discuss our feelings and frustrations when it comes to work. But a theme I often see, from my time as a consultant and across the variety of organizations that I have had the privilege to work within, that tools are often discussed critically as the reason things are going wrong. But I want to drop a hard truth here: You need to learn how to use your tools, and your organization isn’t having leadership or engineering failures because of the tools you are on. It’s the organization and leadership that is the problem.

I don’t want to say that tools are perfect. Tools have a lot of limitations, as they are “boxes” after all. They do only what their developers have programmed them to do.

But something I see often in Organizations is rapid fire tool change. I have seen companies have one complaint and seek a solution by adding new tools. MS Teams, Slack, Zoom, GoTo Meeting, BlueJeans, and other collaboration tools are a good examples. I’ve worked at companies that use multiple at the same time because of some minor feature they prefer. And then no one is happy or can find anything. So they complain about the tool.

This is something across all tools. Mac, Windows, Linux? Yep, strong opinions. Jet Brains vs Visual Studio? Yep, opinions on that too! We better keep switching…

Or, there is another way.

Standardize the Tools Link to heading

Tools are created for a purpose. Go to the hammer section of the hardware store and tell me about how many hammers there are. Framing, Ball Pin, 4 lb, Sledge, etc. All have a purpose. No one who is framing wants to be swinging a 4 lb landscaping hammer around. Someone sinking stakes or posts wants to be using a light weight ball pin hammer. So the first thing is to observe and collect requirements for the tool you are hoping to use, and then look at the primary features of the tools you are looking at.

Once you have found a tool, set a minimum time frame for reconsideration – to help you embrace the tool selection, and the give the team time to learn it.

As an SRE, one of the areas we focus on is the reliability of people. When we think about how we make people reliable, one of the key elements is speaking the same language. Standard tools allow us to speak a standard language.

A small example. If you have multiple collaboration tools, email accounts, and a ticketing system – or 2, “I messaged that to you.” Can be a confusing conversation. Or a miss of a breaking change. Tool standardization can limit the breadth of confusing statements like this.

Embrace the box Link to heading

Embrace the tool. Train on it. Learn the shortcuts.

I felt that this needed its own header, it is so important. Embrace the limitations of the tool and focus on why it was chosen. Teams collaboration spaces differ from Slack Channel? AWESOME! What can the collaboration spaces do? Slack Channels not as robust at collaboration? Great! Focus on the disposable nature of channels.

Tools are limited by their nature, but they are solving the problem they set out to solve. Just in different ways. Almost all of the complaints I have seen are related to people not knowing, embracing, or understanding the solution because it doesn’t work how they assume. Tools are a box…

And you should embrace that box.

Process is king Link to heading

If you are in a leadership position and find yourself reading this, good job! You are the only one that can fix this.

And the solution is simple: Process creation, refinement, and streamlining is the key here. Choose a tool to start, then codify the process of using this. It can be informal, or formal documentation, but the key is setting expectations. Here are some examples:

  1. Have an issue? Submit a ticket
  2. Need to collaberate? message on teams before visiting someone’s desk.
  3. Send emails.
  4. We check all of our code into branches, and then merge those branches into a stage branch before PR into main

etc etc

But process limits people to use the tools provided rather than an orphanage of applications. Everyone guessing over what is the right tool and no formal ownership or control.

Conclusion Link to heading

I thought I would write up a quick post of this because I see this at every place I work. Frustration, and honestly, and overall lack of empathy when it comes to tool selection and usage. There is also a lack of standardization to keep the language the same and people not sure where is best to collaborate.

And there is also a lack of accountability when it comes to tool expertise, and a lack of expectation of expertise.

That is all. Cheers, -Mike