(The only?) fascinating learning in auditing for GDRP / SOC2 audits or budget keeping is the overview over the 3rd party tools used by the team to create its outputs.
We left a golden era for SaaS tools. Every startup building software uses a lot of SaaS to build its own SaaS.1 Oh well, these times are on hold now 🤷 - but I digress.
Tool galore
I wanted to share this fun anecdote: At Yara, 80 people used 171 paid SaaS tools to build half a dozen mostly free tools.
Reading the list of paid tools was like reading a list of synonyms - every reputable CI/CD service, every feature flagging service, every monitoring tool, every issue tracker, every roadmap planning tool was to be found.
Asking people why a specific tool was added to the list instead of using the alternative already widely used by other teams yielded little more than personal preferences of a single person. The “solution” was equally comical2: Month-long enterprise sales cycles followed by year long contract negotiations from central procurement.
Few of the tools were heavily used. Even fewer to their full potential.
Many tools are sold with the very argument that they will replace a lot of existing tools - a promise that is never fulfilled.3 The more powerful and flexible a tool, the less utilized its theoretical capabilities will remain in practical usage.
“Tool galore” creates new problems like information silos. People start to be confused where to put information, and where to find it. Data starts to be in places where they are not found by everyone - creating knowledge inconsistencies that are harmful, as aligning a group is a costly constant struggle in knowlege work.
Tool minimalism
My appeal:
Learn your tools before you add new ones.
Be a master of a few crucial ones. Here’s why: Sufficient knowledge of the existing tools in the tool belt can spare having to add another one with overlapping capabilities.
I’m guilty not following my own advice. I’m no master of the command line. I under-utilize the capabilities of my text editor. Rarely do I use browser dev tools for more than simple inspections. Sure, when I need to solve a specific problem, I try to find ways my existing tools might solve them. But I don’t know all the ways I could do things better if I knew most things the tools can do.4
When I can’t even follow “tool hygiene” myself, establishing it in a team must be close to impossible.
Tool literacy
What I’d love to exist, is a sane set of basic, non-overlapping SaaS / start up / knowledge work / product team work tools. The Microsoft Word of our guild.
What I’d love to exist is a way to spin up this tool chain with reasonable configuration, where the tools are integrated in non-annoying ways.
With little abiguity, when to use which tool for what, and simple behavioral rules where clarity is impossible.
A stupid consulting company (or a boot-camp?) just to think this through, once and for all, and to teach it to the world.
I bet that companies knowing about such a school would pay stupid money to have their stuff thaught. The challenge is of course that people need to be motivated and interested to spend time learning these tools. And teaching is friggin hard!
The “school of tools” would create high-perfoming teams
I suspect, a team of people who intimately know such a tool chain would easily be twice as productive as today’s average team where most of us only possess basic literacy of 80% of the used tools.
Anyone know about such a school? Want to build it with me?
Footnotes
-
Jacky, one of Bird’s co-founders once wondered whether all these payments to each other aren’t a zero-sum game. My opinion is that that’s the case to a limited degree: Some SaaS start-ups purchase and hence create revenue for a lot of SaaS without earning revenue themselves. Some VCs win at other VC’s costs. ↩
-
And didn’t manage to solve the original problem. ↩
-
Notion, Airtable,… ↩
-
Which is why watching colleagues use tools is such a fascinating way to spend time. There’s lots to learn there. ↩