Tuesday, October 2, 2012

Too Many Software Chefs?

When we started Gnip (a social media company) nearly five years ago, it was a blank slate. I vowed to only hire the best, most experienced, software builders & artists. Sure "best" is subjective, but we'd define it ourselves and nail it. "Most experienced" proved to be a vector that added an odd twist that ultimately caused unexpected trouble. With intense focus I set out to find these people, hire them, and change the world of broken public API data access models! We had some early missteps, but we sorted things quickly and iterated on the team fast. We held true to the mission however.

After about a year, the core was in place; about a half dozen on the engineering team. You'd walk in the room and you could feel it vibrate with brilliance, intelligence, creativity, strength, and power. You were walking into the nexus of Agile development, TDD brainpower, lean execution, pragmatism, powerful iteration rates, and some of the sexiest code you'd ever see.

We couldn't be stopped. If a piece of software off the shelf started melting, the team would aim the guns at it, and write our own. Didn't like the order/pattern that bits were being written to disk given our particular access pattern... re-write the i/o driver that was interfacing w/ Berkeley DB. Concerned about the Endianess of bits over the wire; consider flipping it around. We would write our way out of any jam!

On one hand it was totally awesome. On the other, we fell apart as a team. By the book, we were doing everything right, however, even though it was relatively subdued, we had too much ego in the room. It came out in subtle ways, but everyone always wanted to drive... everything. No-one wanted to sit in the back seat and help navigate, or look out the side window and see what the weather was like outside to potentially adjust course. Implicitly everyone wanted to one-up the next person with solutions to awesome challenges. "No" was never part of our implementation vocabulary, and it should've been.

If your team is one or two people I suspect you're fine if you're both chefs. More than that however and you need balance. You need execution support. The tip of the spear is crucial, but there's a whole lot behind it that makes propel effectively. It's tempting to only hire the best and most experienced, proven, developers, but it takes a village of folks with a variety of experience levels in order to succeed. You need different, quite often _in-experienced_, perspectives in order to get the right code laid down. You also need folks that aren't 110% set in their ways. Generally people earlier in their careers are more maleable and flexible in their ways.

About two years in Gnip went through a big staffing change/pivot and changed our development team composition perspective going forward. We are now basking in the glory of variety on the team, and have a wide range of skill sets, experience levels, ego levels, to help write software that matters.