I love building software but software has become increasingly difficult to build as the systems we create have grown both in size and scope. A feature that I could write by myself in a weekend now takes a team of highly specialised engineers supported by product and design functions. Every software specialisation has become a world onto itself with folks spending years mastering their very specific craft.
This is great and I absolutely love all of the innovation that’s come about as a result of operating at this scale but this has also come at a cost. Every engineering team I join seems to be a bit more fragmented than the last. People working on the frontend have no idea the number of services backends need to orchestrate. Backend folk (rightly) haven’t kept up with the pace at which the frontend ecosystem moves, and only infrastructure engineers understand the ins and outs of Kubernetes and how our systems actually run in the real world.
I’ve found it increasingly difficult to operate in these highly fragmented teams. When people don’t have a good picture of how things work across the stack, they’re blind to the constraints of the other side and find it difficult to empathise with each other. This often leads to regular lengthy discussions where a majority of time is spent communicating how things work rather than how we’re going to solve problems. Even if you’re able to put something out there, members of the team are often unable to support it in its entirety.
Here are a few ways we’ve managed to tip the scales back in our favour, increase empathy, and generally foster a better team environment:
Planning together as a team
I’ve often seen planning and sizing of tasks happening in silos in the name of efficiency. Doing this ensures no one ever gains deeper context & insights into how the other half of the team operates. Conversely, planning together can be time consuming as authors (at least initially) have to build context & justify every task they propose to a wider audience.
To address this pain, it’s important to have a common set of guiding principles and actively remind the team of their existence. For instance, a common guiding principle might be user centricity, in this case we’d actively try to frame discussions in terms of the user, even when discussing deeply technical or infrastructure issues. This helps us ground every decision when planning and sizing tasks together as a team. At the end of the day, all software needs to serve a purpose. Having a team that’s aligned on that purpose cuts through a tonne of back and forths when planning.
High effort, low complexity tasks
If you take one thing away from this post, please let it be this. We actively encourage everyone on the team to pick up high effort, low complexity tasks in unfamiliar areas of the stack or codebase. These tasks often have prior art for the implementer to learn from and are found to be boring by engineers who specialise in the area.
Picking up these tasks lets people gradually explore the stack while still actively contributing to the team’s goals. It isn’t free win of course as people unfamiliar with the tasks will likely take longer to complete them, however, you should see this as an investment into the overall health of the team.
Backend examples
- Creating new controllers / handlers that call through to existing services
- Introducing or modifying validation rules that exist elsewhere
- Plumbing data to / from the database for a new feature
Frontend examples
- Building an experience using existing data & components
- Introducing new fields to an existing form
- Building simple (low interaction) reusable components
Coming together regularly to share specific knowledge
Sharing what you know is great for everyone in the team. You never know what people don’t know, a nugget of knowledge that’s obvious to you may have been completely missed by someone in the same specialisation. For presenters, it helps build confidence and often a deeper understanding of what you’re sharing.
Getting people to sign up can be challenging initially as it involves putting yourself out there to potentially fail. This is where having a caring, empathetic team pays dividends. Over the years we’ve had both general sessions around programming practices but also deep cuts into specific technologies like the CSS Grid and even how to write an IoC container in Kotlin.
In the end, businesses will always strive for efficiency and hire increasingly specialised people to push the business forward. It’s our responsibility as leaders and members engineering teams to ensure we retain talented folks by creating an empathetic, engaged team environment.