On the Spinach AI engineering team, velocity is always top of mind. How many story points are being completed each sprint? How can we make improvements to help increase the team’s productivity without cutting corners? It’s all about getting faster, while also maintaining (if not improving) the quality of our product. 

We’re not unique.

Agile teams are often velocity-obsessed. And that’s not necessarily a bad thing. It’s important to consistently evaluate and improve productivity levels on your engineering team. But your focus can’t solely be on your velocity score. You also need to dig deeper into why velocity is increasing or decreasing.

A huge part of understanding how to speed things up effectively is asking, ‘what’s slowing us down?’ AKA your team drag. Our friend Anjuan Simmons, Engineering Coach at Help Scout, got us thinking more about engineering drag with a recent tweet:

I’ve measured “engineering velocity” for a very long time, but I’m starting to focus more on “engineering drag”. These are the things that slow down engineering teams.

This includes product discovery, local dev environments, CI/CD pipelines, etc.

Reduce drag to go faster.

— Anjuan (@anjuan) September 6, 2021

We can’t measure velocity without also turning our attention to drag. 

Scott Kosman, Engineering Director at Double Nines explains:

“The two are inextricably linked. I’m constantly looking for ways to eliminate drag factors in my team and this naturally results in a more focused, more capable group of engineers. Telling a team to “just work faster” without actively removing impediments is a great way to have frustrated engineers start listening to recruiters on LinkedIn.”

– Scott Kosman, Engineering Director at Double Nines

Focusing on engineering drag helps uncover new truths that will ultimately improve velocity. In this article, we’ll explore:

• Why is reducing engineering drag important?
• Top factors impacting drag on your engineering team
• 4 steps to reduce engineering drag and increase velocity

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. Spinach AI’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 Spinach AI

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 Spinach AI. We stay in consistent contact through agile meetings, including:

• Daily scrum meetings
• Sprint retros
• Sprint planning meetings
• Backlog grooming

These recurring touchpoints help us get clear on the goals of each sprint, and foster constant communication so the whole team can stay in the loop and on track. 

👎🏼 Lack of trust

When your team doesn’t feel comfortable speaking up, asking questions and raising concerns, you’re more likely to miss important issues. 

According to Jossie Haines, VP of Software Engineering at Tile, it’s the most significant factor impacting drag. She explains:

“If the engineers don’t feel they can speak up, issues will start accruing that lead to more drag.”

– Jossie Haines, VP of Software Engineering at Tile

Trust is everything. When there’s enough trust on your team, it leads to psychological safety and allows for a culture of two-way feedback. 

4 steps to reduce engineering drag and improve velocity

There are 4 steps we implement on the Spinach AI 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.

Here are a few best practices for fostering trust and collaboration:

Conduct one-on-ones

I have consistent one-on-ones with all my team members. These meetings help build the foundation of trust and are an opportunity for me to encourage collaboration. I often ask them about who they worked with recently and their experiences working together to avoid behind-the-scenes issues.

This is also a great space to ask for more general feedback from your team and get a better understanding of issues that could be causing drag. Some examples of questions you can ask to elicit feedback include:

• What needs to change around our team meetings?
• What’s a problem we have on our team that I might not know about?
• How can we improve cross-functional collaboration?
• What’s something you’d like to share but is a little stressful to bring up in person?

👉 For more ideas of questions to ask in your one-on-ones, check out our list of 121 one-on-one questions.

Ask questions publicly to model vulnerability

When I have questions, I ask them in the public Slack channels so my team also feels comfortable asking questions. If you, as a manager, don’t feel comfortable asking questions, there’s no way your team will.

Pair up team members each sprint

There are a lot of developers who like to work independently. But, a team’s only as good as its slowest person. So to be fast-moving, it’s essential for your team to lean on one another. We pair up team members each sprint to work together on tickets even if they’re not totally the same. That way team members can learn from each other as they solve tickets with similar features. 

Assign buddies for new employees

New engineers are assigned someone they can ask questions to—  like a buddy system. We like to pair more junior employees with senior team members who have a good understanding of the system. Intermediate-level engineers, on the other hand, will typically get paired with peers — but know who to go to if they need more expertise. 

Reducing drag to move faster

At the end of the day, drag will always exist. The goal isn’t to eliminate it completely. After all, sometimes you need to slow down to speed up. And with the expectation to always be producing, your team will inevitably burn out.

But rather, the goal is to remove as many obstacles slowing you down as possible and learn from those challenges, as to not repeat them. 

If you’re looking to reduce engineering drag on your team, the first step is building trust. When there’s trust amongst your team of each other, your processes and tools in place, there are fewer hurdles to moving swiftly. 

---

Build a foundation of trust through one-on-ones. Try our one-on-one software to get started.

What you should do next

Next, here are some things you can do now that you've read this article:

1. Our YouTube channel is full of tips on management skills and team building.
2. Check out Spinach to see how it can help you run a high performing org.
3. If you found this article helpful, please share it with others on Linkedin or X (Twitter)