How to Make Your Software Engineering Team More Awesome (Even if You're Not a Manager)
If you’re a software engineer who works on a team, some of the following will probably be familiar:
You work with mostly decent, geeky people
- At least one person will have an unusual keyboard
- There will be occasional flashes of technical brilliance (or at least, the occasional smart and surprising solution to a tricky problem)
- Everyone on your team cares about good software, though each person has a different idea of what “good software” means
- Despite this, at some point you will manage to ship working software that does something useful
- You have the sense that, though you like your team and your team gets stuff done, your team isn’t meeting its full potential
If you identify with the last bullet point, this article is for you.
Sometimes, things are going bad.
Perhaps there are blind-spots, elephants in the room, lurking dangers, and unacknowledged risks that haven’t been dealt with. Maybe the team is being bogged down by a steadily mounting wave of technical debt or is at risk of being drowned out by the background hum of increasing entropy. Perhaps there are parts of the codebase that nobody wants to venture into, lest they never be seen again. Or, the team has no clear raison d'être. Perhaps there is tension between your team and its product owners, who are making unreasonable demands. Maybe comments on pull requests that were once helpful and kind, now verge on passive aggressive. Or perhaps someone new and disagreeable has joined the team, disrupting group dynamics.
Other times, things are going good, but not great.
Your team is full of smart and capable people who do good work but not truly great work. Perhaps your team is struggling to answer answer higher-order questions, like: Are we having an impact? Are we doing something meaningful? Are we actually giving our customers what they want and providing the services they expect? Are we prepared for what their requirements will be in 12 months and not just next Monday?
And the most important question that most dev teams don’t answer effectively: who even ARE our customers, really? Not the customers of the business — YOUR customers, as a software engineer.
You can’t always wait for your manager or team lead to save the day. In my experience, most team problems are solved bottom-up rather than top-down, since the team members who are closest to problems tend to understand them the best.
Some of the common states I’ve noticed in software engineering teams:
- Technically skilled but lacks a unified vision or coherent approach
- No technical leadership
- Mismatched personalities
- Never able to fix the cause of underlying issues and recurring emergencies
- Wants to improve technically but no time or space to do so
- Beset by unrealistic expectations
- Stuck in a reactive rather than proactive mode of working
- Buried beneath tech debt
- Working on something nobody wants or needs
In my previous role as a consultant, I worked on many teams like this and heard countless stories from colleagues about good teams with their own unique, intractable problems. Despite these issues, they were able to get things done and ultimately find satisfaction in their work. But it was tough.
This post is a toolbox of strategies you can use if you sense that your software engineering team needs help. I’ve seen plenty of non-managers and non-leads use these techniques with great success, including junior engineers.
Some of these are higher-level mindset shifts while others are specific tools and sessions you can use to address specific issues.
These are initiatives that any software engineer on a team can undertake, regardless of seniority. If your team is very hierarchical, sit down with your manager or team lead and ask if you can run one of the below sessions, just to see how it goes. It’ll be important to get their support so the rest of the team feels comfortable giving the session a try.
Meetings are Bad != Communicating is Bad
Many software engineers have a deep, almost pathological, aversion to meetings.
And, let’s face it, lots of meetings suck, and provide no value. We’ve all been dragged to a meeting (or fifty) that felt like a no-op — nothing happened as a result. At some companies, this issue is so bad that tech leads make a career of going to unnecessary meetings just so their team doesn’t have to.
This aversion to meetings leads some software engineering teams to swear off them almost completely. People just work on stuff. In some cases, teams like this can function incredibly well. Sometimes, you find groups of engineers that are so in-sync with their approach to work that they barely need to communicate. At least, I imagine such teams exist, somewhere… maybe at Google, Facebook, or other places that I’ve never worked at. At the kinds of places I’ve worked, every engineer is different, and every person on a team brings a different technical approach. A base level of communication, introspection, and reflection is needed to prevent little problems becoming big problems, and to ensure that everyone is moving in the same direction.
- Result in a change of state. If nothing changes or nobody does anything differently as a result of a meeting, it need not happen.
- Are uncomfortably short. The time allocated for a discussion should always be a little bit less than feels comfortable.
- Have a facilitator (not always the same person).
- Are enjoyable.
- Have snacks.
- Hold people accountable for changes and decisions.
- Worthwhile rabbit holes are split into a dedicated discussion at another time. - - Unproductive rabbit holes are politely brought to a close.
- Are no- ops — have no discernable effects. Usually characterised by lots of discussion and no clear decisions or actions.
- Action items are drawn up, but nobody is accountable for making sure they happen.
- Are allowed to run long.
- Fall down technical rabbit holes.
- Have no facilitator and nobody who can re-focus the conversation.
- Nobody looks forward to them.
- Include people who don’t need to be there.
Good communication can happen without meetings
There are many other ways to improve communication within your team that don’t involve scheduling more meetings. For example:
-Document critical processes. This includes things like how to deploy code and how to access important tools and services. If it’s necessary for someone to be productive on your team, it should be documented somewhere.
-Check in every day. The most effective teams check in with each other every day, whether it’s via standup, huddle, or Slack update about what you’re working on. Every team member should know what every other team member is working on at any given time. On teams where this isn’t done effectively, you’ll notice symptoms like:
- People making conflicting changes to the same area of the codebase
- People getting blocked on work because they were missing critical information from another team member
- Multiple people trying to fix the same problem in different ways, without collaborating
- Missed opportunities for knowledge-sharing that could have helped work go faster
-Make things visible. The team can only work to improve things that are visible. By visualizing things and putting them on a wall or whiteboard (or a shared digital space for remote teams), they can be improved by everyone on the team. The following things can be useful to display in your team’s work area or shared space:
- Mockups of features in development
- Team goals, milestones, and guiding principles
- What is being worked on currently and who is working on it
- Metrics that matter (e.g. uptime, traffic, conversion rate, profit, page load speed, or whichever metrics matter to your team) and their trend over time
- Progress bars (e.g. time remaining until release date, bugs fixed, funds raised)
- Anything else your team is trying to improve.
-Roundtable discussions. A roundtable discussion is a method your team can use to have an impromptu discussion about a topic. In teams without this culture, two people may have a discussion or make a decision that should not be unilateral. By developing a roundtable culture, other team members are invited to participate in the discussion if they wish, but involvement is optional. This helps ensure that only the people who need to be there, or are interested, are part of the discussion.
-Use pair programming as a tool. Pair programming is the practice of two developers working together to solve a problem while writing code together. Some teams do this all the time, while others don’t do it at all. I believe pair programming is a useful tool that should be in every team’s toolbox, and used wherever appropriate. In general, the output of pair programming is “slower but better.” When quality and reliability is more important than speed, pair programing should be an option for your team.
You need to spend time reflecting, growing, and focusing
(Lots of teams talk, but don’t reflect, grow, and focus. More on this later.)
You should spend 5% - 10% of the time on this as a baseline, depending on how well you are functioning. When things get really bad, you’ll need to spend more time talking and problem-solving together in order to resolve issues and get back on track. Very troubled teams may need to spend as much as 20% of their time working through issues. After a week or two of focused work, this can usually drop down to 10%, and then 5%. This is kind of like paying down technical debt — sometimes it’s necessary to slow down for a while so you can resolve issues and go faster in the future.
If you are spending less than 5% of your time reflecting together as a team (two hours in a 40 hour week) and your team is not awesome, this may be why. This might seem like a lot, but 5 x 10 minute standups and a single one hour meeting (such as a Retrospective, which I will introduce shortly) will quickly eat up this time.
I believe that most of the effective communication teams do fall into three categories: reflecting, growing, and focusing.
Reflecting is about critically reviewing the team’s work, processes, dynamics, and conditions.
Growing is about deliberate skill building and development, outside of day-to-day work tasks.
Focusing is about developing a clear direction and figuring out what truly matters.
How to help your team reflect
Retrospectives, a.k.a. “Retro”
Source: The Definitive Guide to Agile Retrospectives and Post-Mortem Meetings
In general, the retro is a place where the team discusses a finite time period (such as the last week) and talks about what went well, what didn’t go well, and team members raise questions or concerns.
A simple way to start is to draw three columns on a whiteboard: a smiley face (things that went well), a sad face (things that didn’t go well), and a question mark for everything else. Team members write discussion points on sticky notes and then stick them in an appropriate column. The facilitator (team members rotate into this role), quickly goes through all the talking points, usually just by reading them out loud. While he or she does this, they’ll group thematically similar post-it notes together. This gives team members time to formulate their thoughts and pick their battles — unless a team is functioning extremely well, there is usually only enough time to discuss two or three major issues in appropriate depth.
Once post-it notes are grouped and circled, team members get to vote on the issues they want to discuss by adding a mark next to each group with a whiteboard marker. Each team member gets a finite number of votes (e.g. 3 votes). Once the votes are tallied the team has a discussion on the topics with the highest number of votes.
The critical thing missing from many retros is change. Teams get together, discuss issues, and come up with great solutions, but nobody has clear responsibility for ensuring they happen. The most effective strategy I’ve seen is for people to take responsibility for implementing an action and for the team to check in on progress repeatedly throughout the week.
After your team has run a few retrospectives, you’ll want to mix it up a little bit. The website Fun Retrospective contains dozens of variants on the “classic” retrospective that will help keep things interesting for your team.
Spotify Team Health Check
Spotify’s Team Health Check is a wonderful tool to assess how your team is faring generally. It uses a traffic light model (green, yellow, red) to rate how well the team is functioning on a bunch of different dimensions:
- Ease of release
- Suitable processes
- Tech quality (code base health)
- Value delivered
- Pawns or Players
If your team is functioning well, this can be a bi-annual exercise. If the team is functioning moderately well, quarterly, and if the team is functioning poorly and trying to improve, a health check could be run about once a month. Keeping track of the results of each health check in a spreadsheet can help you see trends over time.
The team health check is kind of like analytics for your team’s functioning. It’s not necessarily the place to solve problems, but rather a space to track how you’re going, make trends visible, and identify areas that need greater focus.
Spotify has provided a fantastic guide on how to run these, including printable cards to help facilitate the session.
Things you can do to help your team grow
Sessions in this section are designed to help your team grow.
I mentioned that retros are not the place for individual feedback. ‘Speedback’ is a ritual for brave teams who want to get really comfortable giving regular feedback. Imagine a speed dating meetup where everyone in the room gets five minutes to chat with everyone else. However, instead of chatting, you’re each spending 2.5 minutes giving each other feedback!
This is an advanced technique, as effective feedback is usually only possible once the team has lots of practice communicating constructively with each other. If you’re coming from a place of low communication, try to implement some of the other activities in this post before holding a speedback session.
‘Brown bags’ are lunchtime sessions (though they can occur at any time) where someone teaches everyone else about something they think is awesome. It can be a new piece of tech, a new tool, a best practice, or a presentation about a hobby they love.
Source: Scaling Agile @ Spotify
Another innovation from Spotify, Chapters are interest groups that span across multiple teams. For example, many companies will have project-focused teams that contain a few front-end devs, a few back-end devs, business analysts, etc. How do the front-end devs across multiple teams share knowledge and skills? Chapters are designed to solve this problem. Companies may have a web dev chapter, a front-end chapter, a Python chapter, etc. Chapters meet regularly to talk about challenges, newly discovered techniques, best practices, cross-team conventions, and the latest and greatest tech in their area of interest.
Tech Debt Matrix
Source: Technical Debt Wall Retrospective
Tech debt items are things your team has done (or not done) that slow you down. Examples are:
- Features that were built and shipped quickly, but are brittle and buggy as a result
- Libraries that need to be upgraded
- Tools that no longer fit the team’s needs
- Parts of the codebase that are difficult to work on and difficult to change
- Areas of low visibility (e.g. “We don’t know why the app crashes in certain circumstances.”)
- Painful manual processes
If you feel like tech debt is significantly slowing your team down, it’s time to visualize it. When a team needs to fix something, visualizing it must be the first step.
In teams I’ve worked with in the past, the ‘Pain’ and ‘Effort’ axis labels have been confusing. I prefer the Y axis to be ‘How hard it is to fix’ and the X axis to be ‘How much it hurts us.’ If something hurts the team a lot but is easy to fix, it should be prioritized first. Conversely, things that are hard to fix and don’t hurt the team very much are probably not worth doing, unless you have ample time and resources, minimal tech debt, and nothing more important to work on. I have never worked on a software engineering team that matches this description!
The matrix is usually populated in a session where everyone on the team writes tech debt items on post-it notes or something similar. You might allow each team member to place it wherever they feel it fits on the matrix or decide collectively as a team.
During the team’s daily work, people can add to the tech debt wall as they discover new things that slow them down. When people fix tech debt, the post-it is removed from the wall.
Overall, the purpose of the Tech Debt Matrix is to help the team go faster by removing roadblocks and to discourage the introduction of more technical debt.
How to help your team focus
Sessions in this section are designed to make sure your team has a strong sense of purpose.
A ‘True North’ session has one goal: to determine the team’s raison d'être. In a sentence, what does your team do today? Does this align with what the team aspires to be, or needs to be?
An example for a Site Reliability team might be as follows.
What we do: “Put out fires.”
What we aspire to do: “Build resilient systems that put out their own fires.”
The latter statement, if everyone on the team agrees with it, can become ‘true north’ for your team, informing priorities and plans for the future.
These are longer sessions designed to get the team thinking further into the future. Many software engineering teams only think as far as the end of the current sprint. To meet future challenges, the team needs “an eye on the horizon.” The team should ideally have an understanding of where it wants to be in 12 month’s time, and the steps that will be required to get there. The Path to Nirvana is a useful visual aid for this activity.
At least once a year, try to spend a day outside the office focused on team improvement activities. Go somewhere delicious for lunch, and make sure to bring plenty of snacks. When you’re in the office, people are more likely to fall into existing mental sets and habits. Interruption is also a constant threat. If you’ve ever been just about to reach a consensus in a conversation, only to have a key person pulled out of the discussion because of another meeting or request for their time, you know how frustrating that can be.
Offsite days are great for team bonding, but also get everyone out of their element and into a safe space where distractions are minimal. If you can, make it a shorter day (e.g. 9 - 4) and have frequent breaks to check email and take care of any urgent issues.
- Assuming sufficient technical skill among team members, the factor that varies most between high functioning and low functioning teams is communication
- Small improvements in communication can be transformative
Communication doesn’t have to take the form of meetings, though certain types of meetings can be very helpful
- If your team wants to improve something, the first step is to make it visible
- Without a clear sense of vision and purpose, lower-order problems become much more difficult to solve because there is no objective criteria for success
- You don’t need to be a manager or team lead to improve communication in your team (but the support of your manager or team lead really helps)
What have you and your team done that has helped you communicate better? If there’s anything missing from this list, I’d love to hear about it in the comments!