Bringing Calm to the Storm

I was recently asked by a friend how one manages a team. I haven’t considered it before; honestly, I just do what I do almost out of habit. So I gave them what I felt was an unsatisfactory response. Thinking more on it though I realize that there is a method that I do follow, so I will attempt to share that here.

Forming, Storming, Norming, Performing

All teams go through four main phases of development. These phases are unbounded and fluid and teams can progress or regress to any phase at any time, depending on the environment or circumstances surrounding them.

The first phase is forming — the team is initially created and everything is new, raw, and uncertain. There are no ground rules and few expectations. This will lead to conflict as team members offend, disappoint, or step on each other. The storming phase beings.

Storming is the second phase of team development. The newly formed team’s members are behaving as they had before they entered the new team. Each member has their own sense of how work should be done. Social contracts are assumed and they maintain expectations that may or may not align with other team members — or worse clash.

The third phase of team development is norming. Norming happens when the team begins to mature and realizes that each member has unique expectations and values. They start to agree on social contracts, what should be expected of team members, and being to align around a mission and set of values. It is here everyone is “getting on the same page,” and its at this point the team can start to really optimize.

Performing is the last phase of team development. Team members understand their purpose, why the team exists and their own role within the team, and the team’s role in the wider organization. The team shares a common set of values and expectations on how work is done. They are able to keep each other accountable. Team members trust each other and through self-organization can capitalize on individuals’ strengths lending to a greater whole.

Mission

It is important that a team develop its mission. These are sometimes handed to them from upper management, but regardless — a team needs to understand and believe in its purpose.

I will not go into detail in how to create a mission statement, plenty of blog posts and articles are already written on the subject. In short, a mission statement should, in a sentence or two, describe what it is the team does and how it does it. An example (from the Mailchimp’s engineering team):

We give marketers production-ready software designed to help them grow. We succeed through togetherness, momentum, and pragmatism.

You can argue if this is a good statement or not, again not going into that here, but defining and writing down the team’s purpose for existing and how it delivers on that promise is really important.

Values

The things that the team finds valuable are oddly enough called values! Values in practice make up the culture of the team, it becomes expressed in the behaviors and processes of a team. Some managers like to push values onto the team, this is usually a big mistake.

Values should help team members understand how to make better decisions around the work they do or how they interact with others (both inside and outside the team). Below are some examples of values from an engineering team I worked on:

• Collaboration, knowledge sharing, soliciting feedback
• Having strong convictions, but holding onto them loosely
• Long-term benefits over short-term gains
• Assuming best intentions and giving the benefit of doubt
• Quality / Writing specs and pragmatic testing
• Frequent releases
• Everyone writing code and reviewing code
• Leaving code better than you found it

Having values in written format help new team members quickly understand what is expected of them. It also helps serve as a reminder for current team members and in resolving disputes. When hiring it makes it easy to plainly explain to a candidate what your values are and some teams even include them on the job description!

Changing Culture

Values expressed are behaviors and behaviors become your culture. Some inexperienced managers make the mistake of mandating culture. They will publish a document and put posters up around the office of some aspirational set of values that don’t currently align with the team; however, culture is what you do today, right now. It isn’t what you hope the future is.

If you want to change your culture, hire more people who fit the culture you want to move towards. Also promote those who are exemplary, it will not go unnoticed, and sends a message to what is valued. Be ready for team members who are not willing to compromise to leave the team (or the company). This is okay — in the long run individuals not aligned on values will cause a continuous storm and prevent the team from becoming performing.

We tell people to accept their romantic partners how they are, because trying to change people is a futile effort, so why do we expect anything different in the work place? Individuals have to want to change themselves, you cannot force them to. It is why hiring the right people is so important.

Working Agreement

Once your team has established a mission and set of values you can focus on creating a working agreement. A working agreement is as simple as it sounds: an agreement by team members defining how work is done.

A working agreement can cover any aspect of the team’s variety of processes. A good working agreement will set the standard for how the team conducts itself in regards to communication, core-hours, rules during meetings, when work is “done, done,” etc. Below is an example of some items you might see on a working agreement:

• Core hours between 10am and 3pm
• No laptops or cell phones during meetings
• Pull requests are reviewed within 24 hours
• If you broke the build, you fix the build (ask for help if you need it)
• Meeting invites need to have agendas
• Don’t use Slack as a permanent record
• Documentation goes into Confluence
• Work is done when: reviewed, merged, tested, and deployed to prod

Having a written working agreement helps the team hold themselves accountable. If someone is breaking away from the norm it empowers another team member to be able to point to a specific working agreement and call it out. There’s no fuzziness, no one can say “I don’t remember us talking about that.”

Collaboration

A performing team needs efficient ways to work together. This can be a challenge in some environments. If you have individuals working remote but your culture isn’t supportive of remote workers, for example, it can make the remote worker feel alienated. Likewise a colocated culture that is overly burdened with meetings and disruptions can be equally bad.

Information needs to be transparent and readily shareable. All the things we’ve discussed so far (mission, values, working agreement) should be easily discovered. Beyond these the upcoming projects (backlog), design documents, current status of work, etc. should all be convenient to access.

Communication

Teams need to have a way to communicate among one another. For colocated teams this is easy — but for teams with remote workers (even just one) it means introducing a chat application of some kind. Even fully colocated teams will adopt chat applications to support build automation updates, pull requests and other workflow notices.

Norms can be placed around what should be discussed in chat. Some teams will create several rooms (channels) with different rules of engagement depending on the context. Recognize that we are human beings, and social creatures, so make sure to include rooms that serve as relaxed water-cooler type places.

Online chat can be abused. When communication needs to be more official e-mail is usually a good go-to. And when knowledge needs to be preserved a wiki or issue tracker might be the better route.

You should have processes where information is actively communicated rather than passively. Communication is a two-step process, sending and receiving: if your intended audience did not receive the information you did not communicate successfully.

Remote Work

In order for a team to have a remote friendly culture they need to be on their game in terms of communication. If your team does not have easy access to shared workspaces: chat, ticket tracking, code review, project management, etc. it is not going to be welcoming for a remote worker.

The more asynchronous you can make your processes the better you can support remote work. Keep in mind remote work isn’t just about someone occasionally working from home (although it can be that). Working from home one day a week usually doesn’t require a huge change in process — not in the terms of workflows being asynchronous.

Consider that truly remote workers might be in different time zones, in different countries, or even speak different languages! As a manager you have to be keenly aware of these challenges and make sure that tools are provided to best support the team (whether technology, processes, policies).

Technology choices can make a difference here. Make sure you choose modern applications that offer first-class mobile experiences. Not all work happens on a laptop.

Being able to support remote workers gives your team huge advantages in flexibility. Your pool of talent is not limited to geography. Also today’s modern workforce values being able to work anywhere, inside or outside the office, on any schedule.

One on Ones

This is the single most important meeting you will have as a manager, and it is essential you get good at it.

As a manager you should be meeting one on one with your team’s members at a minimum once a month. Personally I feel this is too long and it is better to meet every week or every other week.

The format I practice is loosely as follows:

• Icebreaker; ask about personal stuff, things outside work, hobbies, weekend events, family, etc.
• Focus in on current projects; how is it going, concerns to raise, anything to celebrate and acknowledge? Any way you can help?
• Relay your vision of what’s upcoming and see what feedback they give in return.
• Inquire about team interactions; how do they feel about other team members? Ask about progress of new members. Any concerns about folks (on or off the team) not pulling their weight or contributing? Anyone who should be specially recognized for going above and beyond?
• Give them the floor; let them talk about what is on their mind, what is important to them, career aspirations, etc.
• Close with action items and schedule any follow-ups.

It is important to not just jump straight into business. Sometimes team members have things going on in their personal lives that affects their work life, and this can give context to the last week or two. It also helps everyone relax a little.

This time should be where just the two of you can speak candidly. If you do not have their trust then you’ll only ever hear superficial responses.

Keep discussions in confidence. I don’t use the word confidential, because that shouldn’t be the expectation. Rather, assure them any information you do share will be done so anonymously. You may need to follow-up with with action based on information given during the one on one; and they should expect you to, but they should also trust that you will not “out” them as the purveyor of the information (even indirectly).

Lastly — listen. Do not tell team members how they should feel. You aren’t expected to solve every problem presented to you. You don’t need to immediately have an answer to every question. It is important to make sure you give your team members chances to talk about what’s on their mind. Don’t dominate the agenda, but share it. Make a mini action plan and commit to following up either between or at the next meeting.

Document

Keep notes on what you talk about in your one on one meetings. Just as you probably take notes at other meetings (hopefully), you should not treat your one on ones with any less rigor.

I keep a running document that I share with each team member, so it is totally transparent. I will update the document sometimes with agenda items prior to the meeting to remind myself what I want to discuss, but also to let them know what to expect. They are also free to add items to the agenda so I can come prepared.

Having notes from the meetings helps the running dialogue. It literally becomes a time series of all the discussions you both have had in your one on ones. It makes doing performance reviews a lot easier too and keeps you both honest. Because the performance review shouldn’t be a surprise to anyone — it should just be an HR formality.

Being an manager requires a different set of skills than being an engineer. Not all engineers make good engineering managers, just in that not all engineering managers make for brilliant lead engineers. This blog post just represents a little of what I’ve learned on my journey so far.