10 Behaviors to Make Your Team Great

Is your team greater than the sum of its parts?

Image for post
Photo by Michael Ankes on Unsplash

My team was in a bit of a rut. There was no trust and poor communication. People weren’t collaborating, and there was no transparency into anyone’s days. Updates in our daily standup meetings were vague and non-committal. Morale was low. Things just weren’t getting done.

I knew it wasn’t a people problem. I’d been with most of the team for years, and everybody was smart and talented. No — this was definitely a behaviors problem.

But, while I could feel the problems, I didn’t know how to articulate them. Before I could address the issues, I needed a better understanding of what they were, and I needed to establish a vocabulary with the team to facilitate a discussion. Only then, with awareness and buy-in, could we begin to implement change to improve our effectiveness.

Good Behaviors, Bad Behaviors

I was discussing the team’s underperformance and collaboration problems with a colleague, and they joking-not-jokingly proposed doing a Five Dysfunctions of a Team exercise. (Disclosure: as an Amazon Associate I earn from qualifying purchases.)

Image for post
The Five Dysfunctions of a Team: A Leadership Fable

It had been a while since the five dysfunctions had been front of mind, and I had to look them up for a refresher. “Let’s see what we’ve got here,” I thought as I clicked through some search results.

  1. Absence of trust — check.
  2. Fear of conflict — yup.
  3. Lack of commitment — oh yea.
  4. Avoidance of accountability — definitely.
  5. Inattention to results — mhmm.

Wow. We had ’em all. People on the team didn’t trust each other to complete assignments. Rather than confront the lack of trust, they preferred to work alone on whatever they felt was most important. Updates in standups would be, “I worked on some things and will figure out what’s next,” and people would leave for a coffee and disappear for the rest of the afternoon. Meanwhile, user stories would drag on for days and weeks with no sense of urgency. Yikes!

The five dysfunctions also reminded me of Project Aristotle. This Google Research project attempts to answer the question, “What makes a team great?” One of their key findings was that effectiveness depended more on how the team worked together than who was on the team. In other words, team dynamics and behaviors matter more than people and individual performance.

…what really mattered was less about who is on the team, and more about how the team worked together

Google’s “five effectiveness pillars” go with the five dysfunctions like peanut butter goes with jelly, combining to create a gooey smattering of team efficiency — and they gave me exactly what I was missing most: a vocabulary for talking about the areas we needed to improve and ways to communicate the importance & impact.

The Actions in Action

Image for post
Photo by Trym Nilsen on Unsplash

I had the concepts. Now I needed to deliver the message. I decided to put together two hypothetical situations based on our very real problems to illustrate the impact of these behavioral patterns & anti-patterns.

Example One. In standup, a dev says, “I’m going to work on implementing the Thingamabob. I’m going to try to complete tasks A, B, & C today, then we can test and close it out tomorrow.” In the afternoon, they say, “Something came up and I need to leave for a few hours, but I’ll be back to finish up. I completed task A and am almost done with B.” They come back later when everyone else is offline, complete task B, and leave a note before signing off: “Completing task B took longer than expected, but I got it done. I wasn’t able to get to task C. I’ll pick it up first thing in the morning.”

Example Two. In standup, a dev says, “Not sure what I’m doing today. I might start working on implementing the Thingamabob.” They start working on the story to implement the Thingamabob and complete task A plus part of task B. They need to leave for a few hours, but they don’t say anything. They come back later when everyone else is offline and complete task B.

In both examples, the person might’ve been equally productive, written brilliant code, and completed the same tasks. In both cases, the person had to leave for several hours, and in both cases they didn’t complete the (stated or unstated) goal of finishing task C.

However, the first example demonstrates all of Google’s dynamics of great teams.

  • Psychological safety. The dev wasn’t afraid to share status or go away because of other responsibilities; they felt safe to let the team know they didn’t complete their stated goal.
  • Dependability: The developer made commitments in standup and was transparent about progress and effort.
  • Structure and clarity: They communicated status so the team had awareness, which allows the team to adjust its actions and priorities. (For example, this could allow someone else to jump in on completing task B while the developer was away, and upon returning they could complete task C versus only completing task B.)
  • Meaning: The developer appreciates having a job that allows them the flexibility to take care of other responsibilities during the day.
  • Impact: Ensuring progress and helping the team achieve its goals feels good.

Conversely, the second example exhibits symptoms of all five dysfunctions.

  • Absence of trust: Low visibility and poor communication lead the team to wonder what the developer is working on.
  • Fear of conflict: Sporadic availability makes it hard to collaborate; team members become exasperated and prefer to work alone.
  • Lack of commitment: The developer was non-committal in standup, and the team has no expectations or ability to coordinate.
  • Avoidance of accountability: No commitments and poor visibility & availability; the dev does nothing to demonstrate their effort.
  • Inattention to results: Individual behavior prevents the team from achieving its goals.

All this is to say that, in order to be an effective team, individuals must focus on their behavior and interactions with teammates more than just being productive themselves.

Staging the Intervention

Image for post
Photo by Todd Quackenbush on Unsplash

Okay, I had my ideas to share, and I had my plan of how I wanted to roll my message out to the team — it was time to put the wheels into motion.

The first thing I did was to send an email using the examples above. My messaging (paraphrasing) was, “Hey, team — I’ve been thinking that we haven’t been as productive lately as we’ve been in the past. I think we’re exhibiting some of the Five Dysfunctions of a Team, and we’ve lost some of Google’s pillars of effectiveness that we had previously. Consider these examples.” I also shared my analysis about how the examples were illustrative of the five dysfunctions and effectiveness pillars.

I didn’t really get feedback on the email, but there was a mention here & there in standups and retrospectives. I feel like the email did a fine job of planting the seed and helping to establish a vocabulary for the conversation. Mission accomplished there, I’d say.

Step two was to solicit feedback in one-on-ones. I’d ask people what they thought about the email and how they felt about the team in that context. These conversations were helpful because it confirmed my feelings and demonstrated that others were experiencing similar frustrations. This also helped to establish that we were all on the same page and had similar perceptions of our team strengths and weaknesses.

Finally, I decided to bring it up in the team’s sprint retrospective. I was blunt with them. I said, “I don’t think the team is doing enough to demonstrate commitment & accountability.” It took some courage, but I had to trust the team and not fear conflict — to practice what I was about to preach. The groundwork I’d laid proved valuable. People referenced the email I’d sent, and we’d all had miniature versions of the discussion in one-on-ones. It was a really productive conversation and a catalyst for positive change.

Image for post
Photo by Danielle MacInnes on Unsplash

Things didn’t fix themselves overnight, but we began trending positively in just a week or two. People started giving updates like, “My goal for today is …” and leaving messages at the end of the day to highlight what they did and didn’t accomplish.

If your team can buy-in on the importance of these dynamics and be self-reflective & honest, it can lead to some pretty incredible growth — even on a team that’s already high-performing and seemingly happy. Awareness of these dynamics can turn things around on an underperforming team or protect a happy, productive team from growing pains and evolution.

My team isn’t perfect, but we’re getting better every day. The next step was to continue the momentum. We planned a recurring team meeting to focus on these behaviors and team growth to increase introspection and awareness, but the best way to keep improving is by walking the walk. Psychological safety, trust, commitment, accountability, and no fear of conflict allow us to continue having productive conversations and ensure that we stay on track to accomplish great things together.

Resources:


Originally published at The Innovation on November 20, 2020.

What RPGs Have Taught Me About Effective Software Development Teams

Image for post
Photo by Jason Leung on Unsplash

I grew up as a computer kid in the 80s and 90s and, consequently, spent a lot of time in video games. Now I manage two software engineering teams, and it’s time to prove to Mom that all those hours spent in Final Fantasy were actually valuable career development.

I’m primarily thinking about two video game genres: party-based RPGs and MMORPGs. The formula for these is pretty simple. You have a cast of characters with various capabilities, and they work together to accomplish amazing things. In order to succeed, you must be aware of your characters’ strengths & weaknesses, understand what skills are required to complete a challenge, and combine characters in a way that allows them to achieve the goal.

Well, that doesn’t sound so different from a software development team, does it? You’ve got a group of people with different abilities and aptitudes; you have a backlog of stories to complete; and the team must collaborate to achieve goals and accomplish amazing things. It’s, like, the same thing!

Given these undeniable parallels, what lessons from RPGs can be applied to software development teams?

It’s Dangerous To Go Alone

When you adventure alone in a video game, bad things don’t happen most of the time — but there’s risk. The same is true in software development, especially if individuals on your team are all working on separate things. The primary risks of soloing a software development project are consistency, quality, and knowledge-sharing.

Image for post
Source

Working alone on projects offers short-term risk due to the fact that quality and completion time are largely dependent on who does the work. Someone who’s very experienced and understands the subject area well will probably get by fine, but a developer with less familiarity will take longer and be more likely to make mistakes that require re-work. Peer code reviews are slower and less effective because reviewers need to context-switch and focus deeply to understand decision-making and what’s been done. Individual stories are completed less efficiently because everyone has their own assignments and agenda, and other people’s work becomes a secondary objective.

Knowledge-sharing and information silos are the long-term threat. It’s easy for people to become specialized as certain types of work gravitate toward them. If an individual is the only one that worked on a specific project, guess who gets tapped when it needs attention later? Future work can also be bottlenecked when the person with all the knowledge isn’t available, and the situation gets worse when that same person is the bottleneck for multiple workstreams or when personnel changes occur.

In the video game world, the risks and consequences of soloing are typically limited to just you. People choose to solo because it’s convenient — they don’t want to wait or look for other players — or because they enjoy the challenge. Sometimes it feels easier to go it alone in software, too. However, software development is a team game, and you’re not typically looking for extra challenge just for the fun of it.

Ensuring you have multiple people working on a project mitigates the risk. One person doesn’t go down a bad path by themselves, and at least two people should know how things work and why decisions were made. Pair or group programming is inherently review-as-you-go which leads to better initial code quality, and that in-turn helps with completing stories efficiently due to less feedback cycles and re-work.

You don’t want everybody acting alone, but it’s equally important to make sure you don’t have too many resources focusing on a task. In other words…

Bring the Right Group

Image for post
Source

Quests in RPGs require a certain set of skills to complete. Easy quests are achievable by smaller, less experienced groups, but hard ones require more people, specific skills, or other special assistance. In games, it may seem more efficient to clear easier, low-level content with powerful, advanced characters, but if the strongest characters are focused on easy things, it means they aren’t working on more challenging, higher-reward objectives.

Software development is an exercise in efficiency. You have a backlog filled with user stories. Some are easy and some are difficult. You want to complete them all, though, and the faster you can do it, the better. The trick is for the team to determine the optimal way to complete as much as it can as possible as quickly as possible.

How would you do that in a game? First, you’d decide which quests are most important and what skills they require. Next, you’d look at which characters are available and what skills they possess. Then you can optimize who can do what. Perhaps one small group could tackle three easy quests while another group works on a single complicated one.

This same strategy can be applied to sprint planning. You’ve got stories in a prioritized backlog and a team of people to complete them. Which people have specific skills or knowledge required to complete the highest-value stories? Assign those folks first. Who’s left, and what’s the best way to utilize them? Make sure everybody is assigned, and balance the groups.

You may find that you don’t have enough people with the right skills to succeed with all the most important things. Luckily, RPGs give us a solution for that, too!

Level-up All You Characters

Image for post
Source

Characters in RPGs progress by completing tasks that reward experience. Once you’ve accumulated enough experience, you level-up and become stronger or gain powerful new abilities. In order to have a well-balanced team, you must use all your characters so they all gain experience. If you have a weaker, low-level character, you can grow them most quickly by leaning on them as heavily as possible in content that’s within their reach. Sometimes that can be painful, if you need to return to a low-level area and perform low-value activities, but the investment pays off with time. Once those characters “catch up” they provide valuable versatility to the team.

On a software team, this means ensuring that everybody’s getting reps with the most important skills. People won’t suddenly gain project management skills by not managing projects. Instead, acknowledge it: “I want you to manage this project so you can develop these skills.” You want someone to be a better decision-maker? Ask them to make decisions. Similarly, just because someone can do a thing in 15 minutes doesn’t mean they should do it simply because it would take someone else 2 hours. Instead, invest that 2 hours. The experience is as valuable as the time saved, and it contributes to both the growth of the individual and the strength of the team.

To be a successful team, there are multiple roles that need to be filled. As employees gain experience, they typically focus on a single role. For example, “I’m a developer, and this is what I do as a developer.” Often times, that’s enough to do a good job, but a great team member understands all the roles within the team and has the ability to recognize and step in when a role isn’t being fulfilled.

How do you develop that level of situational awareness?

Learn the Mechanics

Image for post
Source

Often times, games have encounters with mechanics that need to executed in order to succeed. You can win by knowing enough to go through the motions, but the best players don’t just know what to do — the know why they’re doing it. That also means understanding the consequence for not doing a particular mechanic and being able to adjust on the fly when things start to go sideways.

Software teams have a process designed to help the team succeed or — more pessimistically — prevent it from failing. Individual contributors can be successful by adhering to the rules and following the process. Great teammates will understand the underlying reasons for the process, though, and be able to make decisions around when it’s time to deviate.

Much like in games, a great way to become more familiar with the intricacies of your process is to learn it one role at a time from people who are already proficient. How does your team gather requirements and translate them into actionable work? What’s the best way to do a peer code review? What tests need to be run to verify there are no regressions? With better understanding, you can help improve these processes. Don’t just learn how to do things; learn why to do them.

Image for post
Photo by Jackson Simmer on Unsplash

These lessons from RPGs aren’t necessarily special or specific to software development; they’re just general best practices for teamwork and growth.

Recognize the strengths and weaknesses of individuals on the team, and utilize them in a way that makes sense — just like you wouldn’t have your squishy wizards standing in front of heavily-armored knights in a game.

Use the right number of people based on the task. There are both short and long term risks associated with using too few people but possibility for reduced efficiency & throughput with too many. It’s also important that the group have the right set of skills to accomplish the goal. Don’t poke the dragon alone, don’t bring the entire village to feed the horses, and don’t send a small group of adventurers into the dark cave without a torch.

Build your team by ensuring that people have the opportunity to grow. Acknowledge that having somebody less skilled perform a task pays dividends as they gain competency. If you don’t give people the chance to improve, they won’t. Having more people at level cap lets you tackle a wider array of challenges or accomplish more things at once.

Invest in helping team members understand the big pictures. What’s the greater purpose behind your team? Why do your processes exist? Encourage people to learn new roles and step outside the bounds of their specific job. The increased awareness and versatility differentiates good teammates from great ones. In an epic RPG boss fight, you can still win if somebody knows how to kite when the tank dies.

Know the team, grow the team. Use the right skills to get the kills, and collect that sweet, sweet loot.

Image for post
Source

Originally published at https://adamprescott.medium.com on October 5, 2020.

Transitioning from Developer to Manager

Image for post
Photo by Fabrizio Verrecchia on Unsplash

It’s not uncommon for successful software developers to find themselves in leadership positions. There are many possible leadership trajectories, one of which is management. Moving into management was scary for me, and over the years I’ve talked to a number of people at that point in their careers experiencing a similar dilemma. This is the story of my experience, why I made the decision I did, what I’ve learned along the way, and how it’s turned out.

The pre-management era

Let’s start with a little about my background, eh? I started my career as a junior developer and worked my way into a senior role, eventually becoming an architect. As an architect, I served as the technical lead for my team and worked closely with managers to make various leadership decisions. I wore many hats in order to best address whatever I felt my team needed most at the time.

After nearly 10 years with my first company, I left to join a former co-worker at a startup. At the time, this new company was small enough that we didn’t have much of an organizational hierarchy. We were a group of senior developers that all had decision-making authority with freedom to work on what we felt was most important. We still collaborated, of course, but we weren’t all chipping away at a common product backlog.

The loose structure worked great for us as a small team, but it doesn’t scale. As we added more people to the team and new products to our catalog, we needed more structure. We divided into product-specific teams with narrower focus and dedicated backlogs. That was our no/low-management tipping point, and that’s where my journey into management begins.

My boss was suffering the consequences of our very flat organization, and they needed people willing to take on some of these managerial responsibilities. I felt like I was being forced to commit: did I want to be a manager or not? I wasn’t given an ultimatum; in fact, my boss was very clear that there was no wrong choice, and my career would continue to grow regardless. That was comforting, but I still had the decision to make.

The management path was scary for a variety of reasons. I had a proven track record as a developer. I was good at coding and troubleshooting. I knew how to solve software problems. Managers take on an entirely different set of problems that require a different skills — skills I wasn’t sure I’d have. Managing a team when things are going well didn’t seem so bad, but it’s the whole “dealing with people” thing that had me worried. Did I really want to give up coding — the thing I enjoyed and had built a successful career doing — to be a manager and have to deal with people?

Making the decision

I ended up lingering at this juncture for a while. Depending on the day, I might’ve leaned one way or the other, but for the most part I remained undecided and non-committal. In my free moments, I’d research what made a good manager and read stories like this one to understand other people’s experiences. There were a few nuggets of wisdom that helped me make my choice.

Skills can be learned. It feels obvious to say, but hearing this was reassuring because I always considered “learning new skills” to be one of my strengths. It gave me confidence to know that I could supplement applicable existing skills with new, learned skills. For example, I know how to troubleshoot an application by stepping through code until I find a problem, then come up with a solution and implement it to fix the issue. The same critical thinking can be used to identify problems with a team, but I may need to do research on agile processes or collaboration techniques to come up with the solution.

You can nerd out on management. As a developer, there are always new things to learn and play with: languages and language features, tools, technologies, and techniques. I remember learning about something like Microsoft Azure for the first time and being so excited to have a reason to use it. The same kinds of continuous innovation exist for managers, too, but you need some awareness of manager & team problems in order for the solutions to make sense — just like you need context for those new things in software development. How can you automate team processes to reduce toil? What things cause the most friction or prevent work from getting done? How can you make 1:1s more effective? How can you maximize the team’s impact on company goals? How can you improve individual accountability? These are all super valuable areas to focus on, and they’re ripe for fresh ideas and innovation.

There is no “point of no return.” I was worried I’d go from awesome dev to mediocre manager, be unhappy, lose my edge, and feel trapped. It was reassuring to hear that I could go back and that my development skills wouldn’t disappear after being less active for a bit. I’m less involved in daily development tasks now and there are a lot of pull requests doing thing that I don’t understand, but when I do get back into the code, it all comes back.

As you may have guessed, I decided that moving into a manager role was the right move for me, and I’ve been at it for a few years now. It hasn’t always been fun or easy, but the more I do it, the more proficient I become. This has a cyclical effect, too, because increased proficiency leads to more engagement which brings more enjoyment and satisfaction.

Learning to manage

The most difficult thing about becoming a manager for me was the self doubt. (See imposter syndrome.) I felt like I was less valuable to the team “managing” than if I was a developer focused on getting things done. I wasn’t sure if I was spending my time on the right things, and the things I was spending my time on were different than that of my peers/other managers. I was failing to adequately help team members that weren’t meeting expectations. I was doing the best I could, and my boss was supporting and encouraging me — but I didn’t feel like I was doing a good job. It was tough.

Looking back, I think there were two key mistakes I made as a new manager. The first was not being direct with people. I was trying to focus on positive behaviors and encouragement and not being explicit about areas that needed improvement. The second mistake was that I didn’t think about the strengths and weaknesses of individuals on the team and strategize how to use them most effectively. (More on that, here!) You can imagine how these two mistakes can create problems: praise for strengths versus less feedback & higher expectations for weaknesses. It’s no surprise that situations didn’t improve!

The single most important advice I have for new managers is to lead with empathy. Get to know your team, and treat them like people. Give them positive and negative feedback. You’d want your boss to tell you if did something wrong, right? But, it would start to feel bad if they only talked to you about the things you did poorly, too. Learn details about their lives outside of work. It would get annoying if you had to re-explain every week why you had to be late to the same meeting for same reason. The better you can understand your team — professionally and personally — the more effectively you can manage.

The best way to get to know your team is through one-on-ones. One-on-ones are a pretty common “most important thing” for new managers, but the thing it took me a while to learn was how to prepare for one-on-ones. This is very hand-in-hand with leading with empathy. Being prepared for these intimate meetings is the best way to demonstrate that you care. Come up with questions and topics that are specific to the person you’re talking to. What do they like or not like about their job? What are their goals, and are there things you can do to help ensure they’re progressing toward them? What are things they did well or poorly? What do they think they did well or poorly? It’s also a chance to solicit feedback from them about you. Be sure to take notes! They’ll help ensure you don’t miss important follow-ups and make preparing for the next meeting easier.

The next steps

Managing with empathy and preparing for & conducting one-on-ones are things you can implement immediately regardless of experience. The next steps take some time and depend on your team. The most important things will be to establish behaviors that will maximize effectiveness and define a clear vision and purpose. These are no easy feats, though. They require thoughtfulness, focus, strategy, and persistence & dedication. You must monitor progress and be wary of regression, and advocate for the right amount of change to keep things trending positively. And, you need to do all this in addition to whatever your team needs to keep things going operationally!

This is a good summary of what my day-to-day looks like now. I’ve got meetings and operational concerns, and then extra time goes into reflection and solutioning for these bigger, longer-term items. There are still ups & downs; still days where I feel like I’m doing a bad job; and still days where I wish I could just write some code. It’s been a rewarding experience, though. It’s been amazing to watch the team adapt & succeed and to help people grow. I love when we can take on an ambitious goal and achieve it.

Making the transition to manager was a scary decision. I had to learn new skills to solve new types of problems, and I had to battle through some self-doubt. I don’t regret my choice, though. I’m not perfect, I make mistakes & bad decisions, and I’m still learning as I go. But, I love my teams, and I love the problem space that I get to live in.

Have you made this transition yourself? What things have helped you succeed? Are you faced with the decision now — what worries you? I’d love to hear from you!


Originally published at The Innovation on November 7, 2020.