14 things you need to be a successful software developer - Number 1 - Diverse and Empowered Teams
Each of the 14 points in this series is grouped into 3 broad categories, the first one being Modern Development. This is the category I feel encompasses the items that people like Jim McCarthy and Fred Brooks did not cover because they weren’t important at the time. The software development world has changed since their work—hell, it changed since I started working. When I began as a developer, the very first paying gig I got was in 1998, where I was asked to build a record management system. All I knew at the time was Turbo Pascal, so I built an amazing CLI tool with its own "database" (binary record types) to capture the data. It took me weeks of work, but it was feature-complete and amazing... except in 1998, who wanted a DOS CLI tool? A smart friend at IBM then used this fancy Microsoft Access to build out all the forms and use a "real database" in a few days. That met the need even better than I could. In both cases, though, we shipped a file on disk (literally—we burnt a CD to copy the files since flash drives weren’t a thing) and handed it over. Deployment was copy-paste, and updates... what were those again?
Not only did the tech and the ways of shipping change, but so did who I worked with. I didn’t work with a developer who wasn’t a white male until almost a decade later. Since then, I’ve worked on massively diverse teams, and what’s become clear is that there is no perfect model for a developer. Gender, age, education, work experience, sexual orientation, financial situation—none of it has been shown to have any benefit to the success of a developer on a project. Rather, it is the team as a whole that matters more.
I wish I could tell you an awesome story about how I learned this, or give data that validates it, but I can’t—not because I don’t know them, but because the amazing Claire Wood did just that in her talk Pink Hardhats and Other Anomalies, which, like the Jim McCarthy talks, is one I watch yearly. It’s amazing how powerful diverse teams truly are, and she can tell the story—and give the data—better than I ever could.
While I was languishing in monocultures in the early ’90s, a movement that would be called Scrum was starting to take shape, becoming a professional standard in 2009. Scrum wasn’t a revolutionary idea—in fact, the revolutionary idea came about in 1986, when two professors in Japan wrote a paper based on case studies about a new way of working that improved product development speed and flexibility.
Just a small aside: the fact that Scrum and later Kanban, both emerging from ways of working in Japanese business (with automotive businesses as a key part of it), just blows my mind. Maybe the next big way of working is happening there now, just waiting for you to go and write it up!
But back to Scrum: following that paper, multiple people were doing very similar things at the same time. I mentioned Jim McCarthy in the previous post, but also Ken Schwaber, Jeff Sutherland, John Scumniotales, Babatunde Ogunnaike, and Jeff McKenna—all were doing similar things (a case of Multiple Discovery). It wasn’t until 2009, when it was formalized, that it took off... and now, 15 years later, a lot of what Scrum said is still correct.
For me, this is about complexity. Scrum probably doesn’t matter if you’re building a DOS CLI record management system with a team of YOU, but when you have 150 developers building an eCommerce platform... you can’t run that like one team. You have to break it down into small, focused teams (8 to 10 people seems right, but smaller is better). That focus is vital—the more you ask them to do, the more (I’ve found) likely they will slow down, and ultimately fail.
This doesn’t mean locking that team in a room away from everyone else—they need broad context and to know how they fit into the grand plan... but their goal should be as tight as possible. I’ve seen teams of 3 developers running 1 service outperform a team of 9 running 3 services—even when those services overlap.
Now that you have this small team with a solid focus, GET OUT OF THEIR WAY! You have to trust them to ship code, so you need to let them figure out the best way to organize themselves to do that... and that may mean trying different methodologies or having different ways of working across different teams, as their goals differ.
All you can do is empower that team with the right support and authority to do what’s needed. What I’ve found helpful in this regard—and again, I steal from Scrum—is to drop titles. Titles are what consultants use to charge more or to help one’s CV look more impressive than it is. They don’t help ship software and just cause hierarchies and the ability to hide behind the title rather than dealing with issues. Everyone is a team member, and the team succeeds or fails—not individuals.
This also brings me to the final factor in the team: the team who builds the software also owns the software—this includes shipping and fixing it. This isn’t a new idea; in fact, Amazon was talking about "You Build It, You Run It" in 2006. When I worked at AWS, I saw firsthand the power of this. The teams I led all deeply cared about code quality and operational aspects. There was a huge focus not just on shipping but on keeping things working and delighting customers. These practices are simple to implement and add major value—but they start with ownership.
When I gave this talk, I wanted to have a practical action for each point too—just one thing that might help someone in the audience. Obviously, this post has a lot of advice on what to do, but the practical action I gave in my talk was about interviewing—a topic I haven’t discussed yet. Changing jobs is a natural part of your career, and one you’ll do multiple times. To help you succeed in being part of diverse and empowered teams, during an interview, ask to meet the team for a coffee before joining. This way, you can see if they meet your bar for what a great team is.