Austin Gilliam

The Identity of a Team

Teamwork & Leadership

Two years ago I wrote a quick blog about the principles of collaborative storytelling and how you could take those principles to work with you (TL;DR: think about "we" not "me", leave room in your conversations to be collaborative). I had a lot of other ideas when writing that piece, but none that landed on the page — i.e. they were sent to polish in the rock tumbler of my brain, to be honed by experience and new stories.

In between now and then I was put into another leadership position at work, and completed a years-long leadership development course hosted by my company. For the third time in my career I found myself managing other developers while trying to be a developer myself, and through all of that I've learned a lot about myself, and my opinions on what makes a functioning team.

I also figured out why I didn't like some of my old ideas. I'd been trying to make a connection between the identity of different players at the table and the different roles within a team, but it seemed more like a self-help framework than something actually helpful. Now that I've sat with it a while, I've realized that while it might not be worthwhile to classify the people within a team, it can be helpful to define teams within a broader organization.

What Defines a Team's Identity?

A team is a group of two or more individuals working together towards a common goal, and thus the identity of a team is defined by the traits that all of its members have it common. That's a broad definition that fits a lot of situations, but in the context of a working environment — which is where I'm going to focus — I think most teams define their identity in three broad strokes:

Where does the team reside? This includes geographical location (and its associated culture), but also what company the team belongs to. Is the team co-located, or are they spread out across the world? What is the company's purpose? The larger the company, the more layers of organization we need to parse through, each of which could change the team's identity.

Who makes up the team? Is the team 4-6 people or in the dozens? What's the ratio of experienced professionals to early career? What do they want out of their careers? We're looking for commonality here, and that lens has a different focus depending on the diversity and scale of the team.

Who's in charge? People don't quit bad jobs, they quit bad managers. Does the team's manager (I'm purposefully not using the word "leader" here) have goals and behaviors that align with that of the company? Do they rule over the team, or do they serve it? As much as we might wish this wasn't true, who's in charge can change a lot about how a team operates or what they prioritize — for good or for ill.

It's probably redundant to say that an HR team in a global charity organization and a software delivery team at a small technology start-up are going to be different. I would argue in other ways they're probably going to be the same. But I think therein lies a trap — the point of the exercise isn't to compare teams, it's to help understand your team and the people in it. This is especially true for managers.

Of course, this got me thinking about my own team, which I've included below as both a record for myself, but also an example of going through this exercise.

The Identity of My Team

At the time of writing I work for a global financial institution — in other words, I can't tell you about my team or what it does in any great detail. However, we can examine my team broadly:

Where does the team reside? My team works out of the United States, and conforms to that culture. We are mostly co-located. We work in a heavily-regulated industry, so we're limited in what tools we can use and what we can build. We work for the technology organization, so we think like engineers and talk like engineers. Our project is complicated, so we operate in phases of development — cycling back and forth between multi-disciplinary concept work and software delivery.

Who makes up the team? My team is comprised of early career engineers (which is corporate speak for "relatively young"). While certainly a generalization, younger people tend to care more about salary and quick promotions over empire building or enhancing company culture. I would say this is true of my team — we're incentivized like a reputable mercenary company — we have integrity, we like working with each other, but at the end of the day we're all here for the money first, and everything else second.

Who's in charge? Oh no, it's me. At least, that's what it says in the company phone book. I think what's relevant here is that I support the mission of my broader organization, that I want the solution we make to last well beyond my tenure, and that I believe in the notion of corporate citizenship both top-down and bottom-up.

Why is all of this helpful for me to reflect on? It helps me determine team priorities, and where our gaps are. I've got a complicated project with early career teammates? I should probably make sure continuous learning is part of my team's culture, and encourage them to innovate. I want my team to be good corporate citizens, but I can't motivate them with corporate platitudes or my own personal ideals — they have families to take care of and lives to build, and that costs money.

This exercise also helps me vet potential newcomers to the team. In terms of the work, someone who needs clear direction and well-defined tasks is going to have a bad time on my team — there aren't clear answers and our process involves a lot of experimentation. In terms of culture, someone who wants their team to be a second family is going to struggle to fit in.

Of course, once I do hire someone I have to do this exercise all over again — the makeup of my team has changed. I think it's also worth reevaluating at least once a year. Even if my team has the same people in it, people change, projects change, global pandemics shake up the world.

You know how it goes.

Wrapping Up

All being said, I'll be the first to say that it's not the end-all-be-all to understanding your team. You still have to put the hours in, go to one-on-ones, handle factors external to your team. If the team is happy but your stakeholders aren't, the team won't have their project for long. But it's certainly been helpful for me to think about, and I hope it's helpful for you!

I hope all is well with you and yours, and I'll see you in the next one.