In my last post, I wrote about the choice between specialists and generalists on a team, using the metaphor of role-playing games to illustrate it. Now, I’m going to write a bit, over the next few posts, about my practical experience building and growing teams. This isn’t meant to be a guidebook on team development, or anything, but more of my approach and philosophy on team building.

Sure, I also happen to have another awesome picture for this post that I feel reinforces my credentials in Role Playing Games, but that’s a total coincidence, I swear. Yes, I do just have these books lying around my office.

 

At many jobs I’ve had leading teams, I’ve started with somewhat small teams. For illustration purposes, the team I’ll describe will be an example, and not really any particular team I’ve actually had.

What sort of party do you have

So you join a new company/project, and it’s very likely you inherit a team. Let’s describe it thus:

It’s a project team of 4 members, not including you, and your job is to develop a relatively small web application that is data entry-intensive and has a few complex calculations that are implemented on the database side.

The team you have is:

• One Database Developer (SQL)
• Three full-stack .Net developers

Much like our RPG party in the previous post, this is a team of specialists. The project is long-running, and it’s going well, but it’s not really shining. You have been asked by your manager to bring the project to the point of being indispensable to the client. For a contract, that’s winning an option year. For in-house, that’s keeping the project alive.

At this stage, the majority of the teams I’ve been on have been mixes of specialists. It’s very unusual to have a group of generalists.

So what do you do?

First Steps

My process when I join a team is pretty simple: it’s pretty much building an inventory of what you have.

So I like to take each member of my team out to lunch and find out about them, so I can get a detailed view of their abilities, then I do my one key analytic process.

I can’t recall who taught me the SWOT analysis. It must have been a consultant that I worked with a long time ago, but I owe them a debt of gratitude. It’s a very handy and quick way to engage a team in a non-judgmental way that allows you get a sense of the lay of the land.

A SWOT analysis is a brainstorming exercise to determine Strengths, Weaknesses, Opportunities, and Threats. You basically take an hour or two and work through each of the 4 areas and see what shakes out (there is more to it – consult the wikipedia page). You want to cover the tech stack, support system, resources and culture, and allow the team to suggest their own ideas and then ask questions to fill in the gaps.

I’ve seen these come out looking initially like:

Strengths	Weaknesses
Strong Developers Great Architecture	Not Enough Support Lots of time spent on support Difficult Customer
Opportunities	Threats
Next Version of Platform X	None

Then I ask questions:

• How are backups?
• How have deployments gone?
• Who provides requirements?
• How much downtime is there? Are you held to SLAs?
• Which parts of the system have been especially problematic?
• What do the developers like doing?

Then I work to re-frame the matrix with the team, working to explain why I see things this way:

Strengths	Weaknesses
Adaptable Developers Good knowledge of the business problem Good relationship with customer	Deployments take a lot of time, always have hiccups One particular ETL is always failing
Opportunities	Threats
SLA Fixing problematic parts of the System	Not Enough Support Lots of time spent on support Difficult Customer

I think that the things that are identified as strengths, outside of being good technicians, should all be soft skills. It doesn’t matter if you are the best developer on earth – it’s what makes that particular project delivery good that matters. I personally will rarely consider architecture to be a strength. I focus on the entirety of the project when I ask my questions, as usually the team members will focus on the technical.

Building a Platform for Success

All technical support work on a small team, such as deployments, and monitoring, is a weakness unless it’s automated. It is never worthwhile for developers to spend a lot of time on these tasks. That said, the project of automation and monitoring will enhance all developers’ skills, so it’s worth doing. Even if there is an outside group that does some of it, it’s unlikely that you’ll have this in your development and test environments.

Since most of the software for automating these things has free versions, automation is a project that can pay off immediately. You can dig into a full understanding of the components of a system, and the team can spend some time working together with you. Being a new team lead gives a good opportunity to do this, too, as you can often sneak in a break in development to do this sort of thing.

Once that is done, I will usually take on some one coding task that has been a longstanding problem. All too often these are data exchanges with external parties that are poorly understood and use arcane technology combinations. On some contracts I have worked on, it’s as if you were an unknowing subject in an experiment in data chaos. A data feed with an xml header and a base64 encoded body table, why not? Oh, an EBCDIC feed – maybe a mainframe? Nope – just a system written by a developer who likes EBCDIC.

Just a Start

These are good tasks for a new leader to take on. In your first few months, you can ease the pain for your clients and developers, and also gain an understanding into what makes the system work. You build valuable goodwill with the client and with your team. The most important thing to do is to dig in. As a leader, you need to rapidly learn the lore of the project, and then begin to improve the project. Knowing why the system is the way it is is important, but you also need to improve it.

Next: Some Economics