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: , , , ,


  • Ian Greenleigh says:

    I think some of this has to do with tangibility and utility. Even virtual tools *feel* tangible in that there’s an interface, an input, an output, etc. Things that are tangible are habit-forming. Things that seem more theoretical–I’d put process in this category–tend to stay that way.

  • Justin Baum says:

    Noah I have arrived at a similar sentiment and am excited to read more about what you have uncovered building Percolate’s product development process.

    “You can’t ship process.” – Ethan Kaplan, VP of Product at Live Nation

    Thats a quote I pulled from a post by Joe Stump who has pretty succinctly captured my favorite explanation of what post-agile product development looks like. It echos much of what your quote is getting at. Joe has two posts well worth a read…

    Visions of a post agile world

    Agile Anti Patterns in Non Blocking Development

    In the visions post he introduces the concept of treating your makers as asynchronous threads. In the agile anti patterns post he expands on the concept by proposing that as much communication as possible should be asynchronous. Asynchronous communication puts an extraordinary amount of focus on tools over process and it’s no surprise he is building my favorite tool for managing backlogs. Lately I have been thinking a lot about the topics and concepts in Joe’s post as it applies to design’s role and toolset in a post-agile product development culture. Excited for the 37 Signals Remote book to come out as I think a lot of the evolution of product development process since agile has stemmed from remote collaboration.

    I have always enjoyed collaboration facilitated by the written word and tools more than face to face, with the exception brainstorming and sketching.

    PS – Yes, I squirm a bit every time I type “post-agile”.

  • Leave a Comment

    Your email address will not be published. Don't sweat it.