How do you keep good engineers on your team?
It's easier said than done, right? It's especially tough when seemingly everyone on Earth is trying to hire engineers and companies all have deeper pockets, a more impressive campus, and cooler perks than you.
It's simpler than you think, though. Start by cultivating an environment that keeps engineers happy and engaged in their work.
How do you do that?
There aren't too many major differences between what it takes to keep an engineer motivated and engaged and what it takes to do that for any other member of your team, but paying attention to the subtle differences can change the game.
Autonomy and ownership
A need for autonomy isn't unique to software engineers, but if you're not fulfilling that need, you're missing a big part of what attracts and retains a good engineer. A strong sense of autonomy, and freedom to choose how to approach problems, is essentially table stakes for a talented software engineer.
If you think you can keep a talented engineer on the team under a strict 8 to 5 timetable, you're missing something important: creativity and inspiration don't follow a schedule.
Bonusly software engineer Andrew Brown puts it best, as he explains that it's not just the ability to work from home now and then, or unlimited vacation, it's about:
Having a results-driven culture. The freedom to work from anywhere, anytime because results are the most important — not punching a clock every day.
A big part of building a successful engineering team is understanding that great work and true innovation can just as easily happen in a coffee shop, or a comfy couch as they can in an office chair.
Flexible paths to career growth
Career growth doesn't necessarily have to follow a linear progression across the company hierarchy.
A brilliant engineer isn't a brilliant manager by default
This may seem counterintuitive, but a "big promotion" that cuts into their development time or creative process might be the thing that makes a great engineer quit. Many of the world's top developers aren't interested in traditional leadership positions because they don't want to manage others; they simply want to keep building amazing things.
This doesn't mean engineers don't want to lead — just that a perfect leadership position might look different than you'd expect.
So what does it look like?
Yvette Francino detailed a great solution in her Tech Beacon article "13 Ways to Motivate Software Engineers":
Providing opportunities for them to excel and become technical leaders within the organization will go a long way toward motivating your software engineers to continue producing quality work and maintaining their loyalty to the business.
Give your engineers the room and support they need to grow, but be creative in the options you provide. Don't force them away from the creative process unless that's the path they choose to follow.
Learning and mastery opportunities
Mastery isn't a static state; it requires an element of playful curiosity and a hunger for learning. Even at the level of mastery, there's always an infinite path of progression ahead. Once you've mastered a tool, a technology, or a language, the learning truly begins. Learning is a journey that has no end.
Sometimes this learning comes in the form of new tools and technologies, processes and methodologies. Bonusly's Aaron Davis explains,
As an engineer, I am constantly required to learn new technologies and find better ways of doing things.
Support the team's educational journey by providing as many learning opportunities as possible, and by providing an environment where learning is a natural part of daily life.
Access to modern tools
How many master chefs are willing to work with dull knives? How many drivers in last year's Le Mans competed in a 1985 Yugo GV? (Sorry, Yugo fans).
You can't expect exceptional results out of someone if they're given rudimentary or broken tools. You might get lucky, but one day that luck will run out the door (along with your team).
In his article "Nine Things Developers Want More Than Money," Drip founder Rob Walling explains:
Every developer I know loves playing with flashy new technologies. It was Perl and HTML in the mid-90s, ASP, PHP and Java in the late-90s, ASP.NET and XML a few years ago, and today it’s AJAX and Ruby (and in some circles ASP.NET 2.0). Give someone a chance to use these toys and they’ll not only be able to impress their friends, but fulfill that piece inside of them that needs to learn.
If you can (and you probably can), allow the experts to choose which tools they'd like to use to get the job done as effectively as possible. They're the ones who are going to be working with them day to day, and they won't be happy if the tools they're given are more obstructions than instruments.
Healthy challenges are just as important as learning, and the two are closely correlated.
Think about it— if you're spending all this time training and learning, there's nothing better than using that knowledge to tackle a big challenge. But there are productive challenges and unproductive challenges.
It's important to understand the types of productive challenges that edify and motivate software developers, and which push them away.
Giving a developer a difficult but worthwhile project that will require all their knowledge, plus some learning as well — that's a good challenge.
Dropping a huge and poorly-scoped project in their lap, and adding an impossible deadline — not a good challenge.
As our own Andrew Brown explained, one of his top motivators is "being surrounded by people who understand software is never done. A 'deadline culture' is counterproductive."
This doesn't mean deadlines shouldn't be met, or that it's better to remain in an infinite development loop that never ships a line of code.
It's just important to understand that there's never going to be a piece of software that is perfect on its ship date — there's always going to be room for improvement.
A meaningful mission
Most great engineers are interested in working on solving big problems, and seeing the results of their hard work.
Bonusly software engineer Aaron Davis shared his thoughts on the intrinsic value of owning a meaningful project:
I take responsibility for the projects I work on. It's satisfying to see the work I've created out in the world used by many people.
Make sure you're providing the necessary context for the projects you're assigning. Even the most menial tasks often have a great impact, and it's your job to help them see it.
Give someone stuck in a rut a meaningful project, and you'll see the uncommon but beautiful transformation from someone who must be "held accountable" for their work, to someone who embraces accountability.
Recognition for contributions and achievements
If someone is making contributions that move your organization forward, it's absolutely paramount that those contributions are recognized.
It's a common stereotype that software engineers are introverts who work in a cave, have trouble communicating with others, and aren't interested in public recognition.
You don't believe that, do you?
It's true that some software engineers are introverted — but that doesn't mean they're not interested in being recognized for their hard work. Everyone deserves to know that their work is appreciated.
Find a way to show everyone on your team how much you and the organization value their contributions. Depending on the size of your organization, it might seem extremely daunting, or even impossible to do this, but it's not. It just takes some creative thinking.
One of the easiest ways to do that is to empower and encourage everyone on the team to express their appreciation for all the great work that is happening around them daily.
We all spend a huge percentage of our time at work. If none of that time is spent doing something fun, or in the very least enjoyable, it's going to be a slog. Fortunately for software engineers, their skills are in high enough demand that they don't need to accept a slog — and most of them won't.
You can be working in what most people would consider a very boring industry, but if you're solving exciting problems and doing it in a fun environment, that won't matter.
Although the tasks at hand may not always be up to you, how you choose to approach them will always be.
If you have a mind-numbing task coming up, find a way to inject a bit of fun. Make it a contest, or provide a fun incentive for the one who takes it on.
Limited cleanup duty
Have you ever been tasked with setting up last year's holiday lights?
You dig them out of storage, painstakingly untangle them strand by strand, shake them in hopes of loosening the snarl.
Now imagine untying that giant, complicated knot in the dark.
Then comes the fun part: finding out only half the strand lights up, then checking the fuses on each bulb see which is the culprit. If you do find it, finally, you can begin to build something beautiful.
This is often what you're asking a software engineer to do when you hand them someone else's project to fix.
Coplex CEO Zac Ferres offers a key piece of advice in a recent article he wrote for Entrepreneur:
A developer typically hates being handed someone else’s code, then being told to fix or expand it. If only minor work is needed and the old code isn’t a nightmare, sit down with your developer and explain the business goals behind the change.
Sometimes it's impossible to avoid handing a software engineer someone else's code, so when you do, just think back to that tangle of lights and realize what you're really asking them to do.
A great community
Software engineering is often a highly collaborative exercise, and most engineers benefit from being part of a creative community.
Make sure you're supporting a strong community environment amongst your own team by breaking down silos, and promoting teamwork. Encourage the team to participate in community events in your area, and get to know other people who are working to solve equally interesting problems.
If there aren't any communities local to you, encourage participation in online developer communities like Stack Overflow, Reddit's /r/progamming, and of course, GitHub are just a few of many vibrant developer communities.
Visible and tangible impact
Nobody likes spinning their wheels.
This is true for most anyone, but it's especially important that software developers to see the real impact their work is making — whether it's QA engineers seeing the impact on their team, iOS developers knowing App Store downloads, PMs interviewing customers, CTOs understanding their teams influence within the organization, or CEOs sharing the team's affect on the world at large.
KMS Technology CTO Kaushal Amin explains why this is so important in a post he wrote for Developer.com:
Working on questionable features demanded by one loud client, or suggested by a marketer trying to show their value, can be demotivating for developers. Every cycle should have something that really matters in terms of improving the end user experience.
Make sure you're providing an opportunity for your team to work on projects that truly make an impact.
It might not always be obvious to everyone what that impact looks like, so it's worth spending a few cycles on making that impact visible and clear to the team.
You might not expect this: the blocker could be you.
Does it take an act of congress (or at least a committee approval) in your organization to get a small change approved?
It doesn't matter what size your organization is — you can eliminate inefficiencies and blockers. The time and thought taken to streamline pays big dividends down the road in terms of efficiency, and also morale. Valve's Gabe Newell was once quoted:
A lot of times I make people better by getting stupid, distracting, bureaucratic stuff off their desk. That's an incredibly easy way to make a senior person more productive.
Keep unnecessary blockers out of their path, and engineers will not only work more efficiently, they'll have a better time doing it.
There are often multiple ways to solve a problem, and half of them haven't been invented yet.
Give your team the creative flexibility to solve problems the best way they know how, regardless of whether or not it's part of standard operating procedure (SOP). After all, today's creative solution becomes tomorrow's SOP.
Provide whatever tools and infrastructure you can to help improve flexibility, so engineers are empowered to solve problems and make contributions from wherever they are.
Respectful consideration of ideas
It's hard to draw a definitive line between a brilliant idea, and one that's too far out to succeed. That's why it's important to provide an environment that promotes and rewards creative thought.
Brown mentioned "giving respectful consideration to all ideas, no matter how dumb they may seem" as a crucial work environment trait that keeps him motivated and happy as a software engineer.
This benefits everyone in multiple ways.
For one, nobody has to experience the unfortunate and extraordinarily crushing feeling that their ideas aren't good. That's the quickest way to ensure not only a lack of motivation, but a lack of confidence — neither of which are productive traits you'd want to cultivate in your team.
Secondly, when everyone feels a certain level of psychological safety, they're more likely to perform at their best, and have the courage to come up with creative solutions to tough problems.
Google produced some fascinating research on how the level of psychological safety within a team directly impacts their output.
Still stuck? Just ask
Finally, just ask them. It's as simple as that.
Ask them if they're blocked on anything, if they have all the tools they need, or how their week is going. Find out if there's anything you can do to improve their experience in your organization.
Arin Olson, Digital and Creative Recruiter for TEKsystems, explains in a piece he wrote for the Stack Overflow blog:
While there are plenty of other perks your company could offer, the best way to find out what is important to your software developers is to simply ask.
You may think you've got the perfect retention solution, but unless you run it by the people you're hoping to retain, there's a chance it will be a swing and a miss.
Take time to keep an open dialogue with your team; it's good for you, good for them, and good for the organization. Instead of just saying, "my office door is always open," make sure you're actively promoting these interactions.
The more of these elements you can get right, the better the experience your engineering team will have in your organization. The better the experience they're having, the stronger likelihood they're going to stick around, do their best work, and surpass all your expectations.
If you're ready to take the next step in building a great culture that motivates and engages your team, check out our latest guide: