You are a Software Development Manager — or similar — that has been assigned the task to ramp up a software development team. You have a group of people with different backgrounds and technology expertise and are coming together to build software. Where to start?
A couple of years ago I was assigned that very same task. In this post I share a few things to consider doing during the forming phase of a new team with examples of what we did at Galvanize. The focus will be on the forming phase of Tuckman’s stages of group development.
As the leader of the team, you are very much a CEO of a very small company. Great CEOs set a clear mission/purpose for their organizations. All decisions are driven by that mission. Your software development team is not any different. The team’s mission defines its contribution to the software that the organization builds and sells.
You may ask, why define the mission? The answer is in the question itself, which is, why? Many thought leaders like Simon Sinek emphasize how great companies attract great people because they understand why they do what they do.
Our team was incepted to create a set of services that will allow other teams and applications to manage larger amounts of data and query that data efficiently. This was largely the same purpose of a project that the team will be leading, code-named Bigfoot. Before we decided what to name our team, we knew our purpose to the point that we called ourselves The Data Services Brigade (we use the term brigades for our software development teams) and here is our mission: This Brigade is responsible for managing data from different sources in Galvanize’s platform. Most notably, it will be a main driver for the Bigfoot initiative.
Why a team name in the first place? Culture and identity. Most organizations — especially software organizations — emphasize a lot on culture which is fundamental to attract and retain talent. Identifying teams by names rather than by function or a plain number/code makes a huge difference to the culture. It also gives the team a great sense of identity and belonging as a consequence, all qualities you want for a highly engaged team.
The team name is not something that you can do on your own as the manager. It is done with the entire team. Have the members brainstorm names. Ideally each suggestion comes with a rationale that is connected to the team’s purpose. It may or may not be an acronym. Acronyms as names are great as long as the name on its own makes sense. Do not force an acronym for a name. It will feel unnatural and creates more confusion than make things clear.
With all the options available, get the team to vote. You may be tempted to keep looking for a name until there is complete consensus. Don’t. It is very rare to have a complete agreement on a team name but you do want at least a majority and no one to “hate” the name. Consider that this could be a first test for the team to disagree and commit.
Here are some examples from our brainstorm session:
- Autobots: reshaping backends of services to come; creating new possibilities for data access across the platform; transform data into manageable formats.
- Bismuth: “pure” crystals kinda look like a hybrid of Adamantium and Prism (two other brigades the team interacts heavily with).
- Cerebro: locates X-Men and people the same way we locate data; it gets data from the surrounding environment and then shares it — it also learns from it.
- The Hobbits: we were not originally a team and with different backgrounds; we were pulled together and sent on this big adventure.
- Nova: can’t be seen with the naked eye at first but eventually bursts into light just like working on heavy backend development.
We chose Nova. Not everyone agreed and there were some advantages to other options. For example, The Hobbits would have made it easy to find team swag. Autobots was good but it was clear that a solid amount of team members had an affinity for space. In that respect, it was a nice side effect of this process to learn a bit more about the new team members.
This is one of the most fun exercises of a team’s formation. Just like with the name, it all starts with the team’s mission. Get your team in a room and provide them with post-its and sharpies. Pull up the team’s name and mission. Given those, what values are we embracing as a team that will help us accomplish our mission? Take some time with your team to write on post-its and stick them to a glass wall and/or white board. Here are a few guidelines to keep in mind when driving this exercise:
- Explain the importance of defining values. They influence the team’s attitude, guide decisions and keep the team members accountable towards the business and each other.
- Just like a company, a team has its own mini culture. The team’s values are a huge part of what makes up that culture.
- The team’s values are complementary to the company’s values, not an alternative.
- Keep the number of values in check. Three to five well-defined and memorable values is the sweet spot where you want to be. Too many values will make it hard to clearly define and for the team to refer to on a frequent basis.
- As the leader of the team, you probably already have a general idea of what the team values should be. Guide the team and do not dictate your ideas. It is a fine line to walk. Keep reminding the team about their mission. Be open to their ideas and know that the emerging values will not look exactly like what you envisioned. That’s ok.
We wrote values on post-its and stuck them to a whiteboard. Once done, we started grouping them together conceptually. For example, many were related to engineering quality software given we will be dealing with customer data where integrity is of absolute importance. Another group was related to being comfortable with the unknown as we would embark on new technologies and scaling a legacy application with requirements that are hidden in the code. The result of the process lead us to the following final three values:
- Adventure: embrace and uncover the unknown unknowns.
- Ownership: design, refine, communicate, deliver.
- Quality: maximum extensibility with minimum time to value.
There are only three values and all are very well defined. Sometimes we bring them up in our discussions, especially during decision making or one-on-ones. One example was when we were deciding about caching on one of the components. Caching brings higher extensibility from an engineering standpoint but the numbers showed it was not needed yet. We refrained from implementing it in the spirit of minimum time to value.
This post covers some of the first steps around forming a team of software developers, and in particular focusing on its identity. There are three aspects you’d want to line up: mission, name and values. All of these contribute to form the culture of the team as well as give the team members a sense of belonging. Ultimately, the goal is to create an environment where engineers build great software that other people can benefit from.