Embrace HRT for Collabrative Nirvana
Team Geek: A Software Developer’s Guide to Working Well with Others by Brian W. Fitzpatrick and Ben Collins-Sussman.
With decades of collective experience, these two authors distill the essential philosophy required to be part of a healthy development team: HRT — humility, respect, and trust. These values are covered in the first chapter and the remainder of the book describes how to best use them as an engineer and as a manager. Some techniques particularly resonated with my world view.
Fail early. Fail fast. Fail often
It is easy to pay lip-service to this philosophy, but it is impossible to adopt without a culture of HRT. From my own limited experience I can add — Communicate early. Communicate fast. Communicate often. — as another mantra of healthy team dynamics. Failure is always an option, but without HRT and open lines of communication it can take much more time to discover.
Make time vs manager time
Fitzpatrick and Collins-Sussman drew on a lot of great resources, and there is as much gold in the footnotes as there is in the text. They referenced Paul Graham’s essay, Maker’s Schedule, in which he contrasts the different working styles of managers and makers (writers or programmers). The manager’s schedule can be divided into hour-long chunks that may be apportioned to meetings, appointments, or tasks.: the essence of David Allen’s GTD (Getting Things Done). Makers, on the other hand, cannot be effective in one hour intervals. Graham writes that a single meeting in the afternoon can affect the productivity for a whole day. First it breaks up the afternoon into two pieces that are not long enough to really get into the zone, then it psychologically leaks into the morning where you are “less likely to start something ambitious”. I can definitely identify with this propensity. The cost of task switching around meetings often results in a lost day.
HRT is the heart of high-functioning teams of any ilk. When I was interviewing for my first job in software development (all those weeks ago) the most difficult question an interviewer could pose to me was “where do you see yourself in 5 years”? It was difficult because I had just spent the last five years dreaming about writing code for a living. I couldn’t even verbalize what I was looking for in a company, only that I would know it when I met it. Now I can identify the traits I was looking for: teams that value writing code and shipping product, consensus based team decision making, asynchronous communication (I am not room-meat), and of course, they’ve got to have HeaRT.