On Tools, Processes and Guitar Pedals 🎸
How to choose tools for your team, and use them with profit
Hey 👋 this is Luca! Welcome to a ✨ monthly free edition✨ of Refactoring.
Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.
You can learn more about Refactoring here.
To receive all the full articles and support Refactoring, consider subscribing 👇
I have been playing guitar for almost 20 years, studying in a music school since I was 13 until my last years of university.
During my high-school years, once I attended a seminar by Scott Henderson. He was (and is) one of my favourite players, an absolute legend. He spent a couple of hours with us and shared several insights about his playing.
At some point he was asked about his guitar pedals. He started listing and describing them, but soon added:
You know, in my life I have spent way too much time turning knobs. Had I spent half of that time improving my playing instead, I would be crazy good now.
If you ask most guitar players, they will say pedals are crucial: they change and improve your sound, and your sound inspires the way you play.
However, as Scott implied, they don't actually make you a better player. Your playing comes from you, from your skills and taste. Pedals only make it more effective.
👟 Pedals for your processes
If you are a manager, processes are your playing, and tools are your pedals.
Processes include how work is planned, reviewed, how you deal with stakeholders, which meetings you run, and how. These all contribute to your playbook as a manager.
Then, such processes should be supported by tools. Tools make your work easier and better, by creating structure and automation in support of your playbook.
💭 Tools have opinions
Tools are not neutral though — they provide abstractions about how they believe things should work.
In order to be effective, these abstractions should fit your process, or better, the part of the process the tool is assigned to. This happens in two cases:
The tool has strong opinions — and these happen to be the same as yours.
The tool is flexible — and can be adapted to recreate your own process on top of it.
You most often end up with a blend of the two, because opinionatedness is not binary and is more of a continuous spectrum.
Examples of modern tools that can be used for product and engineering management 👆
🥇 Process comes first
Whether the tool has strong opinions or not, it's very important that you have strong opinions in the first place. This means making sure your process is clear, so that your team could follow it even on pen and paper.
This is crucial for establishing a healthy relationship with any tool you decide to adopt. Having a crystal clear process enables you to:
🔍 Choose precisely — you can ask: what is the best tool to support my process? And choose the right one.
🃏 Preserve optionality — you are less likely to become dependant on a specific tool, and you can always migrate with confidence.
🧩 Divide et impera — you are able to clearly delimit the tool's responsibilities, and possibly use multiple ones with profit and without confusion.
Failing to do this, on the contrary, leads to...
🔥 Tools hell
Tools hell is when you blindly adopt the tool's opinions as yours, making them rule your processes. This in turn leads to bad things:
You become hostage of your tools, because you cannot separate their workflow from that of your team, making it hard to migrate to others, or use multiple ones.
The overall process becomes an incomprehensible mix of what the tools support, and how the team really works (the shadow process).
Process should always come first. Tools can (and should) improve it indeed, but the ratio between the "top-down" and "bottom-up" influence is about 80-20.
The ultimate red flag for this is when you ask someone: "how do you work in your team?" — and the reply is something along the lines of "we use Jira". That usually means the formal process is almost non-existent, so the person could not find a better answer than name-dropping the tool.
🏃 A real life example
Here is a simple example of how tools are mapped over our processes from The Four Types of Work 🍀 — if you are doing it for the first time, it doesn't have to be precise, just create a mental model of how things flow 👇
Also, it doesn't really matter how many tools you use, as long as responsibilities and boundaries are clear.
📋 A simple checklist
As you read this, you may try to reflect on how your team works, and ask yourself the following questions:
✍️ Are you able to describe your work process with simple steps, on pen and paper?
🗺️ Are you able to map each tool precisely to such steps?
🔀 Take one of the tools you use the most within your team: would you be comfortable in switching to a different one? Why?
If you are able to answer yes to all of three, congratulations! You are probably already ahead of me 😄
What's the best tool you use in your company? And why? Is there any of them that has completely changed the way you work? Let me know in the comments 👇
Hey, I am Luca 👋 thank you for reading through this post!
Every week I write something about making software, working with people and personal growth. If you haven’t already, you can subscribe below to receive new posts in your inbox!