Software engineering teams are more productive when they work at a comfortable pace

My motorcycle goes about 140 miles per hour, and gets there pretty quickly.

I do not need to go 140 miles per hour. It’s wildly dangerous, it’s not great for the bike, and my ego is not so fragile that it is harmed by riding safely.

However, I do need to occasionally crank the throttle to speed by a distracted commuter on a cell phone or someone weaving in a lane or a pickup truck’s blind spot.

A fast bike doesn’t mean I go fast all the time. A fast bike means I sprint around an obstacle and drop back down to a normal speed.

But what does this have to do with software engineering? Top-speed should not be a software engineering team’s normal operating mode. Just like you wouldn’t normally ride a motorcycle with the throttle wide open, engineering teams should operate at a comfortable pace.

Now, these teams occasionally need to go fast, like if a real - actually real (often software deadlines are timelines, not deadlines) - deadline approaches, or to fix a critical bug. But if you over-allocate the team’s time, they can’t react well to changes, engineer autonomy is reduced, and people burn out.

Just like my bike goes fast, but I don’t always ride it fast, teams need to have the right tools to work fast when needed, but should normally have some unallocated time.

If teams have a lot of defined and prioritized work, it can be hard to take on new opportunities. That would “push out” the existing work, and since it’s already assigned and prioritized and defined, it must be important, right? I’ve observed this phenomenon in myself and on teams: if the team is swamped, new ideas and opportunities look harmful because they’ll increase the workload even more.

Without some slack time, the team doesn’t have time to stop, breathe, evaluate, and decide if this new thing should bump out the existing work. The team transforms into an assembly line, heads down, pulling stuff off a queue, frantic to keep up with the conveyor belt.

This is not a good thing.

Software developers generally want to do good work and they know their own pain pretty well. If you give a motivated and talented developer slack time, the result is generally great.

They’ll fix a nagging broken thing that has been causing more pain than you realized, or they’ll explore an opportunity you hadn’t thought of, or they’ll jump in to help someone who’s struggling, or they will rest and recover for when you actually need to sprint again.

Shortcut is fast and easy to use, so that when your teams need to work fast, they can work fast. It’s also fast and easy to use when they don’t need to work fast. Plus, it allows teams the autonomy and organization to work how they want to work, while making decisions easier so that teams can focus a lot more on the work that matters to them and a lot less on debating next steps.

Shortcut helps you get your work done so that you can do other things, like ride motorcycles. That’s because Shortcut is project management without all the management.

Whatever you’re working on, make sure you’re using the right tools in order to work comfortably. See what I mean by starting your free Shortcut trial.

Want to come work for a company who values your time? Check out our job descriptions.