Welcome to the bloggy home of Noah Brier. I'm the co-founder of Percolate and general internet tinkerer. This site is about media, culture, technology, and randomness. It's been around since 2004 (I'm pretty sure). Feel free to get in touch. Get in touch.

You can subscribe to this site via RSS (the humanity!) or .

Tools over Process

I spend a lot of time thinking about building products (and, more specifically, building teams to build products). With that in mind I really enjoyed this rc3.org post about the seven signs of a dysfunctional engineering team, especially this bit about building tools instead of process:

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?

One of the thing I try to communicate to the whole company is that it’s everyone’s responsibility to build products. Products are reusable and scalable assets. While process is a product, tools are (almost always) better. I am working on a long and sprawling explanation of all my product thinking stuff, but that will have to wait for another day.

July 30, 2013 // This post is about: , , , ,