IX. We Will Not Allow Our Devs to Wander Off

Even if you hire the most capable and motivated devs in the universe, it’s naive to think they’ll naturally stay that way without any intervention. Why? Without strong leadership, they’re going to wander off. They’ll either start spending more time on their own projects, or they’ll find another leader to follow.

People are not static. Motivation, enthusiasm, and engagement will naturally decrease over time. A new company or project will provide a boost, but this doesn’t last forever. If you’re not careful, productivity will slow. Even small changes will start to take forever. You’ll see careless mistakes that affect users in production.

If a dev doesn’t physically wander off to a different company, you still want to prevent their mind from wandering off. This causes them to work on things that don’t matter or to introduce costly bugs.

How can you do this? Every dev needs a recurring one-on-one meeting with their manager to pull them back to the center. Devs wander off for specific reasons, and as long as you can consistently and directly address those reasons, you’ll keep your devs and their attention much longer.

First, you need your dev to want to help you. It’s difficult to follow someone you don’t like—or who doesn’t like or care about you. You might be able to fake it for money, but that’s hard to keep up. The same goes for your devs. If they feel that you don’t care about them as people, don’t count on them giving you 100% of their effort and attention. You don’t need to be best friends or have them give a toast at your wedding. A little bit of care and attention goes a long way toward building their loyalty.

Second, keep in mind that even if a dev loves you and is committed to helping you and your company succeed, that’s not enough. Not only do they need to want to help you, but they also need to know how to help you. Sadly, it’s common for devs to have a distorted (or missing) view of what the company’s priorities are. This makes it difficult (or impossible) for them to align their work with your goals.

Here’s a thought experiment: If you were to ask all of your devs what their top priorities are, would you be able to guess their answers? If you were to tell all your devs to guess your top priorities, would they be correct? If you and your devs are not in sync about what is important, you won’t be happy with their output and, ultimately, neither will they.

Sometimes they might be able to build or fix things that are helpful or will be helpful in the future. It’s plausible that they might surprise you by building something valuable that you didn’t know you needed. Regardless, it’s reckless to rely on your devs to guess the best way to help your business. Make sure that your devs are always clear on what your goals are and that their priorities align with them.

Third, you need to pay attention to when your devs are being blocked or slowed down. How can you tell when this is happening? Your devs will tell you.

Engineers prefer to get work done. They don’t like to be impeded. If it’s taking too long for their pull requests to get reviewed, they’ll complain about it. If they can’t figure out how to run your app locally, they’ll complain about it. If product specs are too vague, they’ll complain about it.

Developer complaints are evidence that something is wrong with the process. You don’t need to make a change every time a dev complains, but it’s your responsibility to figure out what the underlying problem is.

For example, if a new dev can’t get your app running quickly, your docs might be out of date. Or you might need to update the app so that it’s less picky about its running environment. Or new devs might need to take a crash course on Docker before they attempt to run the app locally. Or maybe this dev is just careless.

Your job is to find out. It’s dangerous to always assume the dev is the problem and your process is perfect. It’s just as dangerous to always assume that your process is deficient and the dev is running into an issue that needs to be addressed.

Running engineering teams is like flying a plane. Don’t ignore your gauges and instruments, and don’t fly blind. You’ll want to make adjustments based on the feedback you receive. If you see a warning light, investigate. Make sure it’s not a false alarm and then do something about it. Ignore problems at your peril. Your devs will become less productive and less motivated—and, eventually, they’ll look for another job.

The feedback you get from devs will often be more subtle than, “I can’t get this to work.” Instead, you might see a lot of confusion around why your codebase is set up in a particular way or why particular technology choices were made. This can either be genuine confusion or veiled disagreement. It can be limited to a single engineer, or it can be pervasive on the team. This is important for you to figure out. Keep in mind that if one engineer has an issue, others might be silently struggling as well.

Often, the struggle isn’t process related. A dev’s productivity and motivation can be tanked if they’re working on parts of the stack they don’t like. Some devs just don’t like working with markup and UI. A task here and there might be novel or interesting, but if that becomes the majority of their work, they’ll lose interest. Even if a dev likes the part of the stack they’re working with, if the work is too far outside their ability, it can be draining. It can be exciting initially, but over time, work that is too challenging will take its toll. Try to keep tasks aligned with a dev’s interests and talents.

The fourth and final thing that causes devs to wander off is lack of meaning. This might sound abstract, but it’s actually one of the simplest—and most commonly overlooked—things you can provide to an engineer. In your company, you think about your customers and clients a lot. Your company exists because it saves those customers time, eliminates pain, or helps them be more productive. It’s probably easy for you to see how new features or fixes directly affect them. You know why your work matters. It’s often very difficult for engineers to see that.

Your engineers won’t automatically know that the last feature they shipped was a lifesaver. They won’t know that their last fix made a customer’s day. If a dev thinks nobody cares about their work, they’ll stop caring too.