Building strong teams

My thinking about building strong teams

My work goal is:

• work with smart people,
• on interesting problems,
• that improve our lives.

So I started thinking about how I like to guide teams.

No single contributors

I’ve had smart people on teams that I’ve run. I mean really smart, equipped with deep subject knowledge. These developers that were leagues ahead of others on the team. They wrote close to perfect code. They were also great at working directly with me and terrible at working with the rest of the team.

In one particular case, the individual contributor wasn’t able to, even after my working directly with him and my working with the rest of the team, to integrate.  And even though he was a star contributor, I had to let him go.

Teams are greater than the sum of their parts. It was sad to see him go. But also relieving for other members on the team who felt uncomfortable with the situation. Development work is the antithesis of working on a production like: we crave the interaction, the learning from other experts sitting next to us (and everyone is an expert in something). But someone unable to share their knowledge with others can only last so long in a team, and in this case was risking a team rift and the future of the project.

Developing a craft

None of this development stuff is rocket science. As technologists, we’re excited by the exotic, the new, the big “I deployed 1000 servers in 5 minutes” chest beating. But when you peer behind the curtain and stick around for long enough you notice the same patterns repeating again and again. The exotic was Java, then Ruby, Node, and now it’s Go. All great languages. All accompanied by the familiar aura of newness-hype.

Hype cycles come and go: it’s too easy to jump onto trends. Now it’s micro-services. Next week there will be a new hype rocket leaving earth. We like the hype because it’s something to learn and the best people in IT are self-learners. The hyped-newness takes us deeper into our craft. The hype touches our curiosity-gland and new phrases make it sound exotic.

I’m not dissing container technology or a micro-service approach, I am pointing out that there are always new trends on the technology event-horizon. We flirt with them (full disclaimer: I’m a huge new technology flirt). We kick the tires, try out a deployment or project with them.

A good team solves problems with great code and suns a smooth service. But our attraction to the new can blinker our vision: we serve our users not our tools and technology. Our users want solutions to their problems: “excite my ears with your streaming music” and “keep me happy with a mobile app that starts quickly”. That mobile app starts quickly because we were careful choosing our technology: sifting the value from the hype.

In the business world we see a similar things happening: in-sourcing is the new near-sourcing that once was outsourcing. Trends come and go.

When thinking about which trends to ride I imagine the selection to be somewhat similar to a hobo hopping trains to reach a destination. Hop the wrong train and your next stop is 80 miles down the track in the wrong direction. The observant hobo will discern which trains head out in the right direction and ride them until they veer off course.

So when we start feeling that our work is rocket science, it’s usually a sign to refocus and remember that even rocket scientists are practising a craft. And while we aren’t returning astronauts safely back to the earth, we are solving problems for our users who frankly don’t give a damn about tech hype.

I’m very much in favour of experimenting with the hyped-newness: it’s how we learn our craft, it’s how we experiment with new tools, and how we decide which technology trains to hop.

Summary:

• admire people who ask genuine questions about non-hyped technology stacks.
• avoid people who claim their work is rocket science (unless they work at SpaceX) and therefore none of the existing tools will work.

Don’t make decisions, Then dive in.

I have a decision making system “gut-data-gut”:

• What does my gut say about this?
• What does my analytical/numerical side say (think: pro/con lists)?
• What does my gut say after putting the gut and the data lists together?

Sometimes it takes a while to get a good/bad feeling about a decision. For example, imagine we’re a team thinking about what container system to use. This is a big decision that will impact the entire team. And yet, unless someone on the team has extensive experience, we need to hold off committing to something big until we can build up a strong team consensus.

But not making a decision will also slow us down. Or will it? Usually there’s another way: delay the decision until you really have all the gut-data, and the data-data. This sounds like a cop-out but if I can explain: In our example, not knowing what container format to use we can’t progress.

It turns out that this decision can be delayed while we look at some of the tooling options available for orchestrating the containers. And the decision can be delayed even further while we start building our new tooling (assuming that the orchestration system supports the different container types). All these other tasks touch on our container format decision and help to indirectly inform us.

Now we have our data-data and our gut-data and can make a strong decision and progress.

Humans: no API included

There’s a thousand books about running teams and setting goals each explaining a different way to work with people.

Mine’s pretty simple: be nice to each other and good things will happen. Be nice means listening, questioning and treating each other’s egos with care / remembering that we all have insecurities. Shifting slightly to the right of the Kumbaya campfire, teams need to get stuff done: solving problems.

And that’s precisely how I like to run a team: frame the problem. When we know what the problem to be solved is, our engineering minds naturally start working toward a solution. The trick is asking the right question to discover the real problem. Using the previous example: is the real problem which container solution to use or is the real problem how to run a smooth service?

Without getting too meta, good teams come from hiring people smarter than myself. Usually much more so! Some of my best teams have been where I’ve felt like the stupidest person in the room. And yet I’ve felt valued because I had other skills to contribute. I wouldn’t be the deepest in the tech stack. I would feel comfortable that others knew what they were doing there. But I was able to clear the path so that the team could get stuff done without the organisation getting in the way. Some might call this managing up the organisation. And since the team knows what the problem is, they can now solve it without the weight of an organisation slowing them down.

This example of being the stupidest on the team (sure there’s a nicer way to say this but let’s press on), also illustrates the need for diversity in a team. There’s always going to be stronger candidates. And weaker candidates. But each has their role: I’ve seen strong candidates mentoring newer candidates. And I’ve seen newer candidates digging into documentation and meticulously fixing examples that would be missed by our flag-waving strong candidate. The trick is to develop a mutual respect in the team for everyone’s skills.