fkr

For a while I had a topic in my backlog that I titled “Why I don’t like complaining about tools” - in which I wanted to elaborate, well actually rant, on why I dislike how often people complain about tools instead of fixing the real cause. I pondered about it for a while and when I was describing to someone else the other day how I work, I realised: the post should not be ranting about people complaining about tools but instead outline why I think, people complain about tools.

I work with people in order build awesome things. I do that with the aid of processes and tools. However: it’s people at the core that matter.

The credo “People over processes over tools” is probably familiar. Basically without a fitting set of people most processes are bound to fail and without this foundation no tools will do do much good. This shall not imply that good tools are not important.

If I look at the system I’m part of (the modern buzzword would probably “the bubble”), it is mostly made out of engineers - so to no surprise tools and the “proper tool for the job”-mentality make up a fair share of the mindset.

If I visualise the People > Processes > Tools paradigm, it could be like this:

People are the foundation on which the processed and then the tools build upon. I made a small experiment and applied what I call the iceberg effect to this:

Surprise - the most prominent and visible part are the tools. No wonder we’re inclined to constantly tweak the tools, complain about the tools, look for new tools without ever even considering looking beyond that.

Another thought that I’d like to throw in:

The further we go down the pyramid, the more controversial it becomes. After all we’re engineers - arguing about the perfect tool is easy for us. Yes, it can be very controversial (github vs. gitlab), but it sticks to technicality. Processes affect our work environment more and are harder to grasp than a tool - once we enter the area where we talk people stuff: well, we all know how are hard it can be to look at oneself and see room for improvement there.

Tackling items I usually try to stay away from “the tool discussion” long enough to assure, that the other parts build the needed foundation. A good example of that is the whole topic of Team Topologies.