On Mindset, Behavior and Tools – Non-Obvious Causalities & Rippling Back Pressure

Top down or bottom up? Behavior and emergence. Hard to cut corners. Fixing fools with tools.

I used to have this rough model about how people and groups function: mindset (or whatever is in your head) influences the behavior you need or want, which itself will influence the tools you’ll chose for a given job or task. Just get the right thing into someone’s head and their behavior will adapt to what you want.

This is likely wrong on multiple levels, but I’d like to focus on one particular aspect in which I know how wrong this view is. It turns out that always picking the right (or your favorite) tool is hard to impossible, except maybe when you are at the very beginning of an endeavor.

You can’t always use the perfect product, service, language, framework or library for a particular problem at hands, meaning that once you’ve made a few choices, the following ones are more constrained¹.

Think of it as passing through a trap-door. This causes a form of backpressure, as from now on, mindset changes that intend to shape behavior run into resistance: if they go against the thinking of pre-established tools, change becomes harder.

Rippling Blowback

This backpressure can have unforeseen consequences and ripple back right up to the mindset.

For example, if you’ve setup your CI and review pipelines in such a way that by-passing tests is easy and pushing broken changes to your main branch can be done at anytime without review (possibly with the justification that everyone is to be trusted so they can do as they please: it’s fine!), guess what will start
happening.

By the way, this is not necessarily an indictment of anyone’s capabilities: for example, you can end up in such situations when the build times get so slow that you stop waiting for the build feedback, lest your productivty will crater. Yes that’s bad too, I just want to cut down the smug we’re too good for this
smart asses.

The above is very likely to happen even if every one on the team is imparted with a strong we write tests, wait for their results and review our code spirit: a few hard deadlines and the corners that are easy to cut will be cut, and if no one corrects course, complacency might well take hold.

Correlation?

Although the overall basic principles of sound software development are well known by almost everyone, in practice, the many behaviors of developers I’ve witnessed varied a lot. It is hard to say that they correlated with the knowledge or not of good practices alone: mindset on its own was a weak predictor.

But do you know with what these behaviors correlated? Tools & toolchains! When asked why they did something a certain way, a great many people answer because that’s how the tooling works.

I made this observation myself, when moving from a team that worked on a mono-repo managed via Phabricator² to one that had a very-many-repo setup on github: none of the teams had a real why being articulated. What was allowed within the toolchains simply happened.

At this point I started understanding that you can shape how people think and behave by giving them particular tools and avoiding others.

Tools & Fools: Just Do!

I remember the phrase a fool with a tool is still a fool uttered here and there to encourage us to focus on getting the mindset right and educating users first, before looking into tools, because pending this there was no way we could affect anyone’s deeper inner thinking.

But if you think of it, given someone with a mind open enough to try out something new, as long as they trust that there can be some benefits to it, shifting directly to the introduction and practice of a particular tool can be the best way to affect how we reason. Especially so for larger teams. That does not dispense us from explaining as much as we can, but the value of doing must not be neglected.

The right tool might fix a fool

Hence, I’m now convinced that when you seek to apply and implement some principles at an organisational level, focusing only on what’s in peoples heads is doomed to fail. You need to look at the whole stack because it represents a system where causality is not as obvious as we would like to think.

You want to get the best out of all the possible mutual influences across the three domains, just like so:

Here are some examples to illustrate my point:

Companies that don’t want Slack to become a long term repository for knowledge set the message retention to a few weeks. Everyone knows that if they don’t make the effort to take relevant information to somewhere else, it will be gone.

Don’t want people to write e-mails on the week-end or after hours? Disable Outlook during these times.

Tired by developpers not setting up and running linters properly? Add a CI step that checks for it.

Annoyed by PR authors that don’t correctly format and comment their change sets? Set up an auto-reject rule. Even better: insert a template or format as much as you can automatically – it’s does not have to always be about forbidding things!

You can go on and on.

Constructive Constraint

So remember: tools, systems and processes are the hard bottom on top of which every other part of an organisation is built: they won’t be enough on their own, but it is still smart to exploit their effect to your advantage.

Set the constraints just right, and things might well happen by themselves!