I spent the first ten years of my career working for interactive marketing agencies, building websites with small development teams. I learned a lot in that environment about teamwork. In particular, I’m proud to have gotten fairly good at explaining technical issues to my non-technical colleagues and working with those colleagues to figure out how to use technology to solve business problems. A project team would generally involve a fair number of people in different roles: salespeople, creative folks and graphic designers, project managers, testers, etc, and I had to learn to collaborate closely with all of them.
But, perhaps surprisingly, I never had to spend much time working closely with my technical colleagues. At least not in situations where the relationship was one of peers. The dev team for a project would rarely exceed one or two, usually an “architect” and a “developer”. There was always a clear authority with respect to the software design. Early in my career, I was the developer, taking my marching orders from the architect. Later on, I was the architect, which meant that I would make decisions about the design and make sure the developer understood and executed them.
For the last year or so, though, I’ve been on a larger team. (Really, it’s a medium team, or even a medium-small team. We have six developers. There are much, much larger teams out there.) It’s also a “self-organizing” team. There’s no established leader. Or, rather, the actual leader lets the team really take the reins, acting more as a coach than a manager. This has all been a big change for me and has brought new challenges. Or, as I like to frame it to myself sometimes, new things to learn.
Lately, my metric for success is less about what I’ve accomplished over time period x, and more about what the team has accomplished. The code the team produces is the product. I might be happy with the code I write for a component, but that component is not my code. It’s the team’s code. That means another team member is going to add features to it or refactor it, and he may not do so exactly how I would like.
The end product, what matters, is that which the team produces, and so it’s my responsibility now not only to write code I think is good (in all the ways code can be good, hopefully specific to the needs of the project or component at hand), but to help ensure that the team writes code that’s good, according to the team. And that’s not just my responsibility. It’s the responsibility of everyone on the team.
You can have the most elegant/efficient/whatever solution in the world to problem x, but on a team of peers, everyone has to understand it and buy into it. I find myself, now, presenting bigger design ideas and tools to the team and rooting for us to try them out. I find myself thinking harder about my design decisions, because I have to explain them to somebody else who might know better. I ask myself better questions, because I’ve learned to expect good questions from my teammates.
I don’t know if this is a good thing. It often feels like things are harder. Having an explicit leader would eliminate a lot of conflict and (what I hesitate to call) overhead. I have a set of ideas about what makes for well-designed software. Everyone on my team does. And they don’t always fit together. They’re also constantly changing. So we have to work through how to work together while also trying to deliver features and value to the business. But our ideas are stronger for having been tested against each other’s. The ones that survive are, anyway. We’re getting better. And we’re getting better at getting better.
