Being a software developer isn’t just about building things; it’s building things that deliver value. For all but the most trivial problems, building these systems means collaborating with other people on a team; it’s hard to focus on coding “your part” when the team isn’t collaborating well. While I’ve built some interesting systems, of the projects I’ve worked on, the ones that I remember most are the ones where I was also involved in helping to build a team, including the processes and culture that went along with the team.
One example that comes to mind is my experience joining Fitbit and building the eCommerce team and platform. In 2013, Fitbit was gaining market share and needed to grow and needed a better way to sell its devices. My manager and I worked to form the Boston office and build an adaptable, scalable Commerce platform that enabled the company to expand to support new markets and service providers for payment, tax, and fulfillment. In my role as a technical leader, I contributed significantly to the technology platform, but the role I played in hiring, defining our processes, and helping the team build a shared culture played a more significant part in enabling us to build a critical business system in a relatively short amount of time.
One of the first questions we had to address as the Boston office grew was how our office related to the larger corporate culture. We wanted to ensure that the Boston team wasn’t an “outpost” and was integrated into the larger culture, but since we were different people building different applications in physically different places, it felt that it should be okay for us to identify with multiple work-related subgroups, so we did a few things, including:
Defining team and office working agreements that covered collaboration, coding style, etc, that worked for us while still allowing us to be effective members of the larger organization
Establishing and experimenting with an agile planning process that helped us figure out what to do (and subsequently sharing what we learned with other offices)
Staring a Lego MiniFigure Tradition.
The last item seems out of place, and arose spontaneously, but it was one of those small, ad-hoc things that had an outsize impact. When the team was around five people, I found myself in the Lego Store one weekend and thought buying MiniFigures for the team would be fun. It got some strange looks from some, but I continued this as we grew, and eventually, the company subsidized it. (That the Lego Movie was a topic of discussion might have also inspired the Teamwork theme.)
Each new employee on the team got a MiniFigure on their first day as part of their welcome. We extended the tradition to include visitors from other offices. If you aren’t into Lego, the fun part of MiniFigures is that you’re not sure which one you’ll get until you open the bag and build it, so people had an excuse to visit new team members to see which one they got. Small connections make the larger ones possible.
When I connected with some ex-Fitbit folks (from various offices) years later, I was surprised to learn that they still had their MiniFigures. That even a few people still have them, or at least remember the tradition, got me thinking that what started out as a small impulsive gesture to buy mini figures grew into something that played a small role in connecting the people in our office.
People, especially in interview contexts, justifiably want to know about individual technical accomplishments, but we should remember that complex technological problems are usually solved by teams, and how team members relate and collaborate has a huge impact on how the teams deliver value; people matter. The things we do to help connections also help us to build software.