Tools conceal or reveal, depending

Two stray posts caught my eye today, and each offers a key insight, which when juxtaposed may seem to be in conflict, but they aren’t, really.

The first is from Nick Grossman, who is sharing tasks with his wife, Cescalouise, in the new version of Wunderlist:

Cescalouise and I have started using Wunderlist to keep track of shared to-dos (bills to pay, stuff to buy, etc).  I’ve been a user of Wunderlist for a number of years now and have written about it before.

The shared lists in Wunderlist actually seem to be working for us.   Whenever she adds or updates an item, I get a notification, and vice versa.  This is helpful, for me at least, and can hopefully help her get less annoyed at me for forgetting things 🙂

I mentioned yesterday that I thought it was working pretty well, and her response was: “We’ll see. Systems cover up symptoms.”  Which is a fair point, I think.  It’s easy for me to waste time fiddling around with a perfect system and feel like I’m making a lot of progress, while not actually changing the underlying thing (in this case, not paying attention to things as much as I should).

So, tools can conceal, because you’ll naturally pay attention to what they display, not what’s going on behind the blinking lights.

The second piece was from Noah Brier, who quoted Rafe Colburn, who said this about about dysfunctional engineering teams:

Preference for process over tools. As engineering teams grow, there are many approaches to coordinating people’s work. Most of them are some combination of process and tools. Git is a tool that enables multiple people to work on the same code base efficiently (most of the time). A team may also design a process around Git — avoiding the use of remote branches, only pushing code that’s ready to deploy to the master branch, or requiring people to use local branches for all of their development. Healthy teams generally try to address their scaling problems with tools, not additional process. Processes are hard to turn into habits, hard to teach to new team members, and often evolve too slowly to keep pace with changing circumstances. Ask your interviewers what their release cycle is like. Ask them how many standing meetings they attend. Look at the company’s job listings, are they hiring a scrum master?

So, Tools > Process, as Noah styled his piece, in which is elaborates on the concept, and then introduces some tools that he and his colleagues at Percolate are building for their own coordination, internally. (I hope to revisit those tools in a later post, because I am going to get a peek at them soon.) Tools trump process, because, as Noah says,

Products, after all, are far more scalable than process, which requires constant training and reminding (as new people come on board you need to train them on your process).

I have argued long and loudly that transitioning to social business means moving away from role-based, flat jobs, and where the decisions are baked into processes. Instead, coordination of work happens when individuals decide they want to ask for guidance or advice, or to task someone with part of an activity, and instead of blindly following the workflow wired into some workflow diagram, the “rules” are just another sort of information.

So tools can reveal, providing great insight into the dynamics of cowork, for example, or they can conceal, because what is being displayed isn’t what is truly important. This is why social tools user experience is so critical.