As teams begin to scale, it’s only natural that communication suffers first. This is something we experienced at Names & Faces when we rapidly grew from a two-developer team to an eight-developer team. However, because we understood how valuable clear and frequent communication was for driving projects and aligning the team, we’ve built deliberate actions and habits into our workflow to keep our interfaces strong. Here’s how.
When I first started my career as a software engineer I was a freelancer – a team of one. Working as a solo developer was simple because I knew everything there was to know about the project and the codebase I was working in.
This wasn't any different when I joined Names & Faces as the second developer on the team. The CTO and I would have frequent informal catch ups, where we would chat about what had to be done, why what we were working on was relevant to the business, new things we'd learned and how we’d approach building out the tech.
Fast forward three years, and we've grown to a team of eight developers. Those regular, informal 1-on-1 catch ups quickly became impossible as the scope of our work grew. To add to this, we also switched to being a remote-first company with team members in five cities across four different time zones.
We quickly saw that the bigger your team gets, the harder it is to communicate, share knowledge, and align. This means it becomes gradually more important to work deliberately on improving communication in your team.
Communication is actively sharing knowledge
When I talk about communicating, I'm talking about actively sharing knowledge – any kind of information that is relevant for the team to do their job. This knowledge is an accumulation of all the learning, experience and decisions of the team. In a dev team, I’d identify the most important aspects of this as follows:
- Technical knowledge: Skills that help developers build things, such as how to write effective tests, or how to provision cloud infrastructure.
- Architectural knowledge: How the team's systems are structured, and how to work on those systems. For example, how the auth service works, or how you're going to approach building the new share feature.
- Operational knowledge: How the team operates. For example, how the team should process a potential change to their design system.
- Domain knowledge: The problem space and goals of the business, and what role the dev team should play in that. For example, what the value of a new feature is to the customer and the business.
Being visible about all these complex moving parts is hard though. Why?
In my experience, knowledge naturally propagates throughout a team, but that doesn’t mean you shouldn’t be deliberate about continuously sharing it, especially when your team starts to scale. Doing this is hard for a few reasons:
- Things move fast: The pressure to deliver is ever-present, and development teams have to move fast and be agile, so things are constantly changing. It’s often hard to avoid deliberate communication taking a backseat when this pressure starts to mount.
- Things are complex: Businesses are complex. The domain of software development is also incredibly complex, which means it's often hard to communicate because the information is complex.
- Humans are human: People don't always listen, and people forget, and people misunderstand. I have zoned out in so many meetings and missed out on key pieces of information, or didn't quite understand what someone meant, but didn't say anything.
I’d like to talk a bit about how my team at Names & Faces approached getting over these hardships. Here are some of the things we’ve actively done, as well as practical habits that we’ve put in place, to make communication more deliberate in our development team.
Actively building deliberate communication into team workflows
Pair programming
Pair programming is something that many development teams know about and are already doing, which is great because it’s one of the most effective ways to learn from each other. When I first started doing pair programming, however, I didn't enjoy it. It felt way more efficient for us to work separately on different things than to have a couple of us working on the same thing.
But, as the team grew, I found that pair programming was not just an excellent way to solve complex problems, but it's also a great way to share knowledge.
When two or more developers solve problems together, you learn each other's problem-solving processes and technical knowledge. You also have two minds working on one problem, meaning you'll probably get a better solution and have multiple people with context on that work.
I've also found it to be a great social exercise for remote teams: I've had days where I paired with a few teammates for the whole day, and found that what we were working on wasn't so important – it was more about having a bit of social time and catching up.
Here are three pro tips to start reaping the benefits of pair programming immediately:
- Identify complex pieces of work, where the solution isn’t defined, and pair on those. Complex pieces of work are usually best solved by multiple engineers who can combine their individual knowledge. You’ll very quickly find this work is completed much faster, and with better solutions.
- If you are a senior engineer, make more of an effort to pair with juniors, and if you’re a junior engineer, make more of an effort to ask seniors to pair with you. You will be amazed at how quickly this develops a senior developer's teaching abilities, and how rapidly junior developers absorb the senior developer's skills.
- To actively encourage pair programming, set a hard limit on the number of ‘In Progress’ tickets to the number of developers on the team, minus one. This way, there will always be one ticket for two developers to pair on at any given time.
Learning sessions
We've been doing regular learning sessions at Names & Faces for a while. Once every two weeks, one person volunteers to host a session that the whole dev team attends.
This is a great learning experience for the team, because one developer who is very strong in a particular area can share that knowledge with the whole team. An hour may not be long enough to become an expert in a given area, but it's enough for everyone to gain sufficient knowledge to learn more themselves. We've done these both as lecture-style sessions and as workshops.
I've also found it's a great learning experience for me when I present these sessions: It forces me to research the topic, and broadens my knowledge of it even more. It's an application of the ‘See One, Do One, Teach One’ concept.
Often, we schedule these sessions around upcoming work to help us learn and apply ideas on a practical level.
For example, when we were about to start building our new mobile app, I presented a few sessions on what to expect as I had quite a bit of past experience working on mobile apps.
Other times we do sessions that aren't related to current work, but are relevant to our system. Our DevOps wizard has done a few sessions on AWS, which I've found invaluable. They're optional, but everyone always attends, which speaks to how important the team finds them.
Team-wide discussions
I don’t think there’s a team out there that doesn’t have team discussions – and for good reason! We've found that the more of these we have, the more aligned we are as a team. We use our grooming sessions not just as a time to break down and estimate tickets, but also to talk through how we should approach certain problems.
We’ve learned that there is definitely a balance that needs to be struck when it comes to the depth of discussion in a grooming session, however, and everyone needs to find the right balance for their team.
When we first started doing grooming sessions, I personally felt the sessions were way too long and far too technical. It felt like the time spent discussing the work could have been better spent doing the work. Over time, though, my thinking on this has evolved: The more we discuss the work, the more we can be aligned in how we approach it.
We've also struck a good balance with the level of detail in these sessions. We’ve learned that when we start discussing how to go about implementing something, and the discussion starts getting too ‘in the weeds’, it’s useful to form smaller groups and chat about it in more depth later, or set aside time for a ‘spike’.
In addition to our regular grooming sessions and our retros, we also sometimes have impromptu discussions.
When there is a complex problem to solve or a big decision to make, and the thread on Slack is getting a bit long, it's easier to just jump on a call to discuss it.
Pro tip: When you have a team discussion, be sure to take notes of any key decisions or lessons, and post them to a team-wide channel. This helps cement the information before it disappears into the ether, and means anyone who wasn't in the meeting, or isn't in the dev team, has visibility on what was discussed.
Written documentation
Whenever a decision is made, whether by the whole team or by a subset of the team, we’ve found it incredibly useful to document it in a team-wide channel.
It’s important for the whole team to be aligned when we work on something because things move fast and having context is the key to keeping everyone on track, especially as a remote team with developers in multiple time zones.
Good written documentation means that people can get up to speed faster, and know from the get-go why certain decisions were made.
In our case, we’ve found it most useful to have a visible owner who is in charge of documenting and communicating specific things. Having a single point of contact for something that people can go to with questions or ideas helps keep everything streamlined.
For example, I'm part of the Design System team at Names & Faces. Part of my responsibility as a member of the core Design System team is making sure there is buy-in from the rest of the Product team on the vision we have for the design system.
I think I've talked through our approach to building component APIs dozens of times with my team, and when my teammates hear me talking about it, they probably roll their eyes – but I take that as a good thing! A reaction like that confirms you’ve got to the stage where you know everyone has absorbed the knowledge because you’ve communicated it thoroughly – both as a team and through your documentation.
Learning in public
In a dev team that uses a platform like Slack to communicate almost everything, we’ve found it invaluable to ask and answer questions where the whole team has visibility.
If you have a question and you ask it publically instead of in a DM, you get the following benefits:
- You'll probably get a response sooner, because the person you ping may be busy and someone else knows the answer.
- The question may spark a dialogue that leads to more interesting discussions.
- If anyone else has the question in the future, it's all recorded — in fact, someone else may have had that question already, and you helped answer it.
I also find that I give better answers when it's public and written. Both of these constraints mean I want to make sure my answer is as thoughtful, correct, and clear as possible. It also gives me time to think about the question, whereas on a call you don't have that luxury.
If there is one thing you take away from this post, it's that: Good communication in a development team can be hard, but it's vital for a team to function efficiently and move together in one direction. No team will be perfect, but we can all make steady progress in the right direction by intentionally incorporating habits and approaches like these into our teams.
Jacques Blom is a software engineer who has been working with technology all his life. He works as a senior full-stack engineer at Names & Faces. He's also getting into teaching by sharing his learnings through blog posts and tutorial videos. Check out what he's up to here.
