Build Nimble Teams, Or Fall Behind

Imagine this: You’ve got a team stacked with the most brilliant engineers on the planet. They’re creative, they solve problems quickly, and they build the absolute coolest products you’ve ever worked with in your career.

Unfortunately, they actually spend most of their time fixing broken code, or waiting for approvals, or tediously integrating tech that could be done a better way.

You’re not nimble, which means you’re severely underutilizing your world-class team. Here’s how to fix it:

Build quality in

I've heard many times that "quality" and "velocity" are competing forces. But to that I say - if you're constantly dealing with unplanned work, how are you moving forward?

Quiz: in which direction are we all weirdly, intensely staring? FORWARD.

Some engineering teams have a dedicated QA department, which means developers finish their code and immediately throw their work over the wall at them (figuratively speaking). Then it goes to production, something inevitably breaks – and they’re left scrambling to fix it while probably pointing fingers across departments.

A better approach is to focus on quality from the start. As a manager, I build in time on the front-end to give my team the time they need to test, experiment, and break things. We always focus on the critical business pathways first – which critical journeys through our system MUST be flawless to continue driving revenue? Then we layer the rest in. It’s an iterative process, but it sure beats unplanned fire drills to get things back up and running.

Work in small batches

On my team, we started with a really unorthodox branching system that got WAY out of hand over the years and were really tough to integrate. Now, we’ve worked hard to move to a trunk-based system, and we’re able to keep our main line in shippable state at all times. Was it incredibly painful to make that switch? Absolutely. But the speed and agility our engineers are now able to operate with isn’t even comparable to the old system.

Automate what you can

This one’s simple: Let the computers do what they’re good at, and let your humans focus on the fun stuff.

Pictured: humans having fun.

Recruit “pilots”

Have an idea to improve a system or process? Rather than disrupt the entire organization, test it out with a small group first. Find out what the pitfalls are, what the advantages are, and whether or not it’s really feasible to roll it out globally. It always makes more sense to start with a few small wins than… the alternative.

Bring the pain forward

Avoiding tasks you know are time-consuming or a pain point for your team only makes them harder to deal with. Instead, draw those things out. Find ways to do them more often, so you can build up muscle memory and flexibility. Plus, the more you’re exposed to those processes, the more likely you are to find ways to improve them.

Observe and maintain

On my team, if we build it, we ship it, we own it, and we’re going to support it. If something breaks, we’re not running to our Ops teams to find out what’s going on. Our system is fully instrumented (especially in the financial areas), and we monitor our tech in real-time to understand where we’re succeeding and where we’re failing. It means our engineers learn faster, AND they feel more accountable to optimize for the long-term as opposed to moving too quickly just to get things out.

Pay your technical debts

I can’t say this one enough. As leaders, we HAVE to figure out how to provide our teams appropriate time to deal with technical debt. Otherwise, it’s easy to spend more time dealing with the sins of your past than actually moving forward.

Here’s my advice. If you’re a manager with significant technical debt, it’s OK if you need to intertwine those issues into current business solutions in the short-term. (Alternatively, you can find a short-term business solution to buy your engineers time to deal with technical debt.) However, it’s just like driving a car without ever changing the oil. You’re not going far before you run into a critical problem.

On my team, we host a “Day of Quality” every other Friday that’s totally dedicated to checking our code. We find ways to make it fun, and since we’ve all experienced the benefits firsthand, it doesn’t feel like a chore.

TGI(QA)F

Our responsibility as engineers is to ensure our products continue running smoothly and deliver value to our customers, and that includes being nimble enough to solve potential issues before they become a problem.


Can't get enough RV Tech? (It's okay, neither can we.) Click right here to learn about three game-changing, proprietary tools our tech team built from the ground up.

Previous
Previous

DEEP DIVE: The Future of Ad Personalization

Next
Next

2018: Red Ventures Year In Review