Why is reducing engineering drag important?
Overall, it’s important to reduce drag so you can clear the obstacles on your team’s path to success. Hypercontext’s CTO and Co-Founder, Graham McCarthy puts it best:
“You can’t run fast with a parachute tied to your waist. No amount of gains from moving forward will fix the issues you’re building up by letting problems fester. The drag will get worse and worse. When things are going really well at your business, it won’t matter. But once things turn stagnant or move sideways, it’s all you’ll see. Tackle your issues as soon as you can.”
– Graham McCarthy, CTO and Co-Founder at Hypercontext
Drag is something that’s slowing your team down. Reducing drag not only helps you go faster but also reduces frustrations and helps your team to work more effectively together.
But, contrary to what you may think, there is such a thing as good drag too. Here’s how you know the difference:
Good drag vs. bad drag
Bad drag, the type of drag we’re predominantly focused on in this article, is when obstacles arise that slow you down now and in the future. For example, if tooling fails. Or if a bunch of tests that are being run don’t work. Those are instances of drag that’ll negatively impact the velocity of your team and are ideal to avoid when possible.
But, once in a while, we need to slow down to speed up. And that’s where good drag comes in.
There are situations when putting extra thought or research into something before diving in will help improve your velocity. For example, if your team doesn’t properly research a new project, it’ll often result in more code needing to be written down the line. Even though in the moment the extra time upfront contributes to drag, it’ll ultimately help make things run faster and smoother.
Top factors impacting drag on your engineering team
There’s a myriad of things that can cause team drag. Below we list some of the most common ones that my peers and I have come across.
System changes
When systems change — for better or for worse — drag is inevitable. As part of the process of making back-end changes to your product, a lot of testing is required. When those changes inadvertently affect something on the front end — and we’ve all been there— it takes time to figure out the cause and how to fix it.
While you can’t always avoid this type of drag, you can plan for it. You already know that system changes are going to require some extra time because unforeseen issues are inevitable. Build wiggle room into your sprint to account for those hiccups. Essentially, you want to give your team the space to fail.
Context switching
Focus is everything for developers. Interruptions, whether they be in the form of meetings, Slack messages or small tasks, disrupt the state of flow— and that has more of a negative impact than you might think.
Why? Because a 30-minute meeting in the middle of your team’s focus time isn’t only a 30-minute break. It’s breaking up their days into pieces that are potentially too small to actually get anything done in.
Paul Graham writes about the maker vs. manager schedule. Managers typically have a lot of meetings throughout the day — and that’s part of their job. They often run their schedule through hour, or even half-hour, intervals. Makers, on the other hand, like developers, typically use time in units of at least half a day. Throwing a 5-minute meeting in their schedule mid-morning is throwing a wrench into their productivity. You’re not only asking them to switch tasks, you’re also asking them to change the mode in which they’re working. And that takes a lot of mental energy.
“Engineers need and love to be able to focus. The amount of information a skilled engineer holds in their brain at any given moment while in a flow state is enormous, and interruptions cause all that memory to be flushed, resulting in slowdowns and frustration.”
– Scott Kosman, Engineering Director at Double Nines
Poor communication and unclear goals
Our CTO, Graham, cites poor communication and unclear goals as the single biggest factor impacting drag. This is important to look out for inside your engineering team and also cross-functionally.
It’s quite simple really: When your team isn’t communicating, misalignment occurs and frustrations and obstacles are bound to arise.
Plus, now that most of us are working in remote or hybrid work set-ups, proper communication and clear goal alignment are even more important. That’s why we use the agile framework at Hypercontext.
4 steps to reduce engineering drag and improve velocity
There are 4 steps we implement on the Hypercontext engineering team to reduce team drag.
1. Establish clear requirements
A good place to start is with clear requirements. This goes for both the product team and engineering managers themselves. There are a few ways we ensure clear requirements:
- Tickets: Tickets are our main vehicle for communicating what needs to get done each sprint.
- Detailed acceptance criteria: There’s no room for ambiguity in acceptance criteria. Acceptance criteria need to have a clear pass/fail and should focus on the end results. We also include technical criteria so there’s clarity around what’s expected technically.
- Write everything down: Don’t expect your team to remember everything. Write it down. In my experience, when a requirement’s not written down, it’s forgotten. Everyone has a lot on their plates, it’s challenging to remember the things that haven’t been documented. As a best practice, write everything down — even if it seems small or you think you’ll remember.
2. Implement proper tooling
Do you have the right systems and tools in place?
Ensure the same system is being used across your development team as a baseline. This will help reduce the ‘it works on my machine’ effect, to create better team cohesion and less back and forth.
One part of having proper tooling in place is an effective test suite that reliably tests the important features.
This plays into trust. Not only do you need your team to trust each other, you also need them to trust that the code they’re writing is going to work. That requires tools that allow them to feel confident that they’re doing the right things and meeting business requirements.
Having a test suite and tools your engineers can rely on will help reduce drag.
3. Reduce interruptions
One of my main objectives as a manager of engineers is to remove unnecessary meetings from their calendars. When I was doing more individual contributor work and getting pulled into 5-minute meetings, it had a significant negative impact on my productivity. So we try at all costs to avoid meetings that could have been emails.
Scott shares some wise words on the negative impact of too many meetings for developers:
“An engineer tasked between 2 or 3 different streams of work is suddenly going to find the number of meetings they have to attend increasing exponentially (3 different standups at the same time is not a shortcut to awesome) and can quickly spiral to a situation where 5-6 hours in an 8 hour day are spent in meetings and not writing code. Remember that human beings don’t scale – an engineer allocated to two separate projects at 20 hours a week each does not result in 40 hours of effort.”
– Scott Kosman, Engineering Director at Double Nines
A busy meeting schedule for the engineers on our team is 3 meetings/day. That’s the maximum.
Here are a few other things we implement to help decrease interruptions of flow:
- Set expectations: We have loose contracts to establish clear expectations for the team. For example, there’s a 4-hour turnaround time for poll requests. But, if a request is assigned to someone in the afternoon, they’re not required to look at it until the following morning so they can keep focused on what they’re already doing.
- Wired-in-Wednesdays: A couple of years ago we implemented wired-in-wednesdays. It’s essentially a day when meetings aren’t allowed so the development team can focus purely on coding.
- Be mindful of instant messaging: Sometimes receiving a Slack message can be just as disruptive as a meeting — especially when the message is from your boss. I let my team know that if the message is important, I’ll explicitly call that out. Otherwise, it can wait. I’ve also been taking advantage of Slack’s new scheduling feature. So I’ll schedule a message around a natural break, like lunch time, as to no disturb workflow.
4. Establish a high level of trust and collaboration
While the previous 3 steps are important, they won’t do you much good without trust. Trust is the single most important factor in reducing team drag.
When your team trusts one another, it allows them to move faster and collaborate effectively. While everyone may have their own respective tasks to complete, it’s important that the team’s not working in silos. I try to encourage my team to care more about the full feature set than their individual work. At the end of the day, that’s going to help you all push towards collective goals faster.
Replies to This Discussion