Should anyone ask, on 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 run 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 microservices. 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 microservice 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: insourcing is the new nearsourcing 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 eachother 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 a flag-waving strong candidate. The trick is to develop a mutual respect in the team for everyone’s skills.

Should anyone ask, hiring a virtual assistant.

A few weeks ago I was hitting the admin wall: many small tasks that needed doing. Many small tasks that were turning into mountains. Many small tasks that were taking up space in my brain.

I admitted to myself:

  • I’m not good at this. 
  • I don’t need to be good at this. 
  • I don’t aspire to be good at this.
  • This has to be done.
  • I can hire someone to help me who will be excellent at this!

To solve this problem I started looking for a virtual assistant on Upwork.

image

I needed someone that could also help me while working both in English and in German. I received 5 applications from as far afield as Vancouver and Australia. One Applicant was Elisabeth. From Berlin too!

image

I dislike personnel administration: time zone differences from working with far off places would mean I’d be also sacrificing my nights to the beast. Vancouver and Australia were out and I hired Elisabeth. Having someone in Berlin with the option to potentially meetup seemed like a good option. I went ahead and arranged an initial Google Hangout call with Elisabeth. 

While I was waiting for the hangout call, I setup a Trello board and started dumping all my admin tasks onto a to-do list. And basked in the warm GTD feeling of getting things out of my head and onto a list.

This week started with my first session with Elisabeth. 9am and a strong coffee and knowing that I had support were powerful motivators for getting into the office! We powered through the tasks together: she doing some of them, me the rest: it was so much easier working this way. Yes, it took two hours, but that was a lot of build-up. I expect the next session to be about 30 minutes.

Without thinking too much about where this fear/hate/loathing of admin tasks comes from, I feel much better for knowing that a bunch of them are done. 

Perhaps not perfectly. But done!

Steps to slaying your own personal admin monster

Wanna do the same? Here’s the “I hate admin” summary plan if you want to setup a system like mine:

  • Create a task: Sign up to Upwork, create a task and estimate about how much time you will need from your assistant. On Upwork you can elect to pay hourly or by task. It seems only fair that for such a variable task to use hourly.
  • Find an applicant: Post your task and wait. I waited about 24 hours to get some applications. I also chatted with the applicants to find a good fit.
  • Hire your applicant: Simply hit the Hire button. This will let the other applicants know that, as nice as they are, you don’t need their services.
  • Setup an initial call: I wanted to get to know Elisabeth before working with her. Before setting up recurring events see if you can work well during one session.
  • Create a Trello Board: You could also use a shared email inbox. You could use an issue track. But both of you need to be able to action tasks: Trello works well for this.
  • Out of the brain-onto Trello: Create a Trello mail-in-email address so that you can forward tasks/bills/scary-emails from your inbox directly to the Trello board (and forget about them until the call).
  • Add the address to your contacts. I have a new contact called “Orga”. New tasks are emailed to Orga and land on my Trello board. 
  • The initial call: During the initial call talk about what you want to achieve.
  • Invite your applicant to the Trello board. We looked through the tasks and started nailing them.
  • Setup a recurring calendar event:  I waited until after the first session to decide on whether the new assistant was someone I felt comfortable committing to. Elisabeth was great and so we setup a call for every two weeks and dropped a reminder into the calendar.
  • Rinse-repeat: Keep dropping tasks onto Trello. Keep forgetting about Admin tasks until once a fortnight when you get a reminder for a call.

Do great things without admin hanging over you!

search

Powered by Blogger.

Follow by Email

Should anyone ask, on 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 start...