Keeping Engineers Engaged And Happy Is Critical - Here's How To Do It

Christopher Steiner is the founder of ZRankings, and Aisle50, YCS11, which was acquired by Groupon in 2015.

In the history of the U.S. economy, particular classes of workers rarely have had a run so prodigious and extended as the current ride that engineers and developers find themselves on. The nature of capitalism means that lucrative job categories that experience shortages are typically fed with hordes of newly-trained workers who even out the imbalance. Or, quite simply, capitalism finds a way to go *around* these workers, to automate what it is they do, even if it's at a high cost.

But that hasn't yet happened in tech. Universities are pumping out more engineers capable of writing code and developing algorithms every year, but the tech demands of this economy quickly swallow them up. Yes, there exist more capable engineers than ever, but opportunities for this class of worker only continue to expand, along with salaries.

That makes hiring engineers hard. It's a competitive process where good candidates field multiple offers with generous terms. We've addressed things that founders and employers should look for in finding and interviewing the right engineers. 

As hard as hiring engineers can be, losing a good one can pose an even bigger challenge. Especially for smaller teams, losing key technical employees can be a serious blow not only to a product's development, but also to a company's overall domain knowledge, and even the morale of the rest of the technical team. 

"Engineering turnover is especially painful. Detailed knowledge of a system’s architecture is often lost when a team member departs. It’s also common that new team members, lacking the appreciation of why the system was built in the way it was, embark on a mission to make significant, sometimes unnecessary changes that consume time and money," explains Jason Heltzer, a partner at Origin Ventures, a Chicago venture capital firm.

Turnover can't be eliminated. Some people will always look for different challenges and changes of scenery, both in the work they do and where they do it. But turnover can be mitigated. Companies and startups can be proactive in building roles and experiences around valued employees' evolving careers. It takes extra work from founders and managers, to be sure, but the difficulty of replacing elite tech talent makes these sacrifices and measures well worth it. 

We've drawn from our own experiences as founders, plus we've tapped other founders who have salient thoughts on the subject, to put together a compact set of guidelines on what to do and what not to do when trying to create an environment that seeks to maximize the creativity and productivity of engineers while also keeping them engaged, happy and far from burnout.

For those who don't want to read the entire piece, here's our takeaways, in short:

• Pay matters, but it's not the single keystone factor for most people (including engineers)

• For companies that weren't started as tech companies, ensure that developers are treated as normal, key members of the team

• Support side projects

• Provide a research interest/experimentation outlet 

• Code that regularly goes live and has an impact on the business

• Create concise product specs that matter

• Know that mistakes will be made 

• Managers of tech people should be tech people  

• Let engineers determine their tools and methods 

• Give engineers unique tasks and duties

Pay matters, but it's not the single keystone factor for most people (including engineers)

Joe Carella, the assistant dean for executive education the University of Arizona, has studied the drivers of retention for senior engineering and tech staff. "Some of our finding suggest that salary is not an intrinsic motivator, especially for specialist skills," Carella says.

The reason for this is simple, Carella explains: For limited supply skills, most people will be already earning at the top of their profession—a circumstance that would certainly include developers on popular frameworks and those familiar with edge technologies in AI, data and cloud systems.

For companies that weren't started as tech companies, ensure that developers are treated as normal, key members of the team

This isn't an issue for tech startups. In the case of these companies, usually the founders are technical, and the product, which is tech itself, is central to everything in the company. At many tech startups, it's more likely that non-tech members of the team will feel excluded, rather than the other way around. 

But it's different at companies whose core competency may not be tech, but whose business still require an engineering team. Examples of this would be marketing firms, services companies, retailers and anything in brick and mortar. 

"Too often, the engineering team is thought of as a factory that makes things and that their input is unnecessary to the other functions of business, or that they have no interest in it," says David Evans, CTO of Uncorked Studios, a product design company focused on mobile.

More often than not, these assumptions are false or wrong, and they can lead tech team members to become disconnected from the rest of the company, and lead to an tangible rift between those in engineering roles and those in places such as sales and marketing. I've seen this exact thing manifest at more than one company. 

"It is easy to find a tech job, and if a company is willing to treat you as an interchangeable resource, then engineers will treat companies as interchangeable as well," says Evans.

Good practices on this front (for non-tech companies): 
    • Give tech a real seat at the table; invite tech to all consequential meetings at company
    • Give engineers chance to provide input on the business at large
    • Borrow a page from tech companies, give engineers a chance to pursue projects and tech outside of core purview

Support side projects

At my first engineering job out of college, I signed a contract that included a no-moonlighting clause, which disallowed me from working for others on the side. It was never much of problem for me, but at that age I wasn't concerned with pursuing other work or projects. The attitude toward this kind of thing has changed, however, which is better not only for employees, but also for startups and companies.

When I was running Aisle50, several people on our engineering team had ongoing side projects. These were things that we talked about regularly at lunch and around the office. We encouraged this kind of thing, and took a genuine interest in the code that our employees wrote outside of work. 

Why? Because passion projects keep people happy. And they're a natural way through which developers keep learning, a fact that makes the developers better and more valuable to their employer. It's a win-win.

"Side projects enable coders and developers to do what they love while also pushing them limits of their talents," says David Kalt, the founder and CEO of Reverb, a web marketplace for musical instruments. "Recognize and reward employees who pursue side projects and provide the flexibility that makes those projects possible."

Provide a research interest/experimentation outlet

Most developers tire of working on repetitive projects. That can't be totally avoided, as it's sometimes the nature of the business. But the effect of grinding on the same kind of problems day after day can be mitigated by giving engineers time to explore other technologies and non-essential projects. 

It may seem anathema to a company's overall development goals to bankroll engineers to work on things that aren't critical to the core application, but keeping engineers' interest is, in fact, core to the company. Bored technical employees tend to find their way to recruiters and job sites. And in some cases, these side projects can turn into major developments or features for the company. Having more expertise in-house is always handy, even if it's something that's just used in business development and talking to prospective clients.

Side projects within in the company don't have to be focused on AI or some other tech that's considered on the edge. Sometimes it's enough to give engineers a new problem to solve, of a sort they haven't solved before, says Maximillian Page, the founder of coupon site CouponHippo.

"Giving engineers unique problems to solve will help maintain a high level of engagement," Page says.

There's no can't-fail recipe for the time that should be dedicated to this kind of thing, but as little as 10% of available work time—so half a day per week or so—can go a long way toward not only keeping engineers engaged and happy, but it will also help keep a company on the edge of trends and perhaps even open new paths for its products and software.

Code that regularly goes live and has an impact on the business

Nobody likes wasting their time on projects that never make an impact. Many younger developers, having spent years working on their own projects or at early startups, are used to seeing their code merged and deployed quickly. In these settings, they can see that what they do matters; it makes a impact on the product and the business almost immediately. 

Seeing the product of one's work in production is always satisfying. Ensuring that happens regularly for all developers should be a priority for founders and CTOs. 

"This means creating an environment where engineers can draw a line between their contribution and impact with our users and fintech at large," says William Hockey, CTO of Plaid, a platform that allows developers easy access to users' data from financial institutions such as Chase, Wells Fargo and Fidelity. 

Understandably, the feedback loop won't be as quick at a larger operation. Projects take longer, are more complicated and involve more people. Developers understand that. That being said, there should be a palpable effort at all sizes of companies to limit scope and to keep feedback loops as short as possible. 

Create concise product specs that matter

In working to ensure devs work on meaningful projects and write code that matters, specs handed to development teams should be concise and well thought out. Project managers should be judicious in what is included in these documents. Specs should be specific and focused without leaking into the kind of superfluous feature bloat that large management teams and committees can engender.

Adhering to these kinds of practices is one reason Agile development processes have become so widespread: they allow for quicker iterations and keep engineers from being heads-down on a project whose specs clearly need adjustment. Giving engineers meaningful work with step-by-step feedback and timely integration into the main business application is a good way to keep the team engaged and limit boredom and frustration—which leads to turnover.

"Good engineers leave bad shops because they can quickly discern that their work is not aligned with business goals,"" says Trey Stout, the CTO of ScribbleChat, an app that supplies additional fonts and emoticons to texting interfaces. "If a good person is building things that are objectively good, but fail to accomplish goals, they will move on to a place that better utilizes their output."

Know that mistakes will be made

QA work won't always catch bugs and mistakes before they make it into production code, especially at a startup where the QA process may be limited compared with a full-fledged company with lots of enterprise clients. Those mistakes will invariably trace back to the work of an engineer.

Assuming this isn't part of a longer pattern with this particular person, it's important that founders and leaders don't ascribe the failure to the engineer in any significant way. Nobody wants a crown stolen from them in a conspicuous manner. Build the person back up, don't pull the project back from her, let her prove herself by finding another solution.

"Sometimes if an engineer makes an error, he falls from grace in the management's eyes and someone else becomes a favorite," says Emma Moore, CEO of Fundamental, a Los Angeles development shop. "Recognize that programming is problem-solving. It is a process, so let them work out their process and it may involve some mis-takes."

Managers of tech people should be tech people

Most developers don't enjoy trying to explain arcane engineering problems to people who don't have a significant amount of technical knowledge themselves. By putting a non-technical person in charge of developers, it's also a signal to engineers that there isn't room for advancement for their ilk inside the company. 

"Developers don't want to be stuck reporting to somebody who has never written a line of code," says Jeff Szczepanski, COO at Stack Overflow. 

The other side of this is that putting non-technical people directly above developers also puts the manager at a disadvantage, where it may be difficult to win over the reporting team. This is all in addition to the fact that doing this generally doesn't sit well with engineers.

It's akin to having an NBA coach who never played high-level basketball. It can work, but in most cases it won't.

Let engineers determine their tools and methods

Standardizing some things, like CSS and Git branching, is great, but putting in too many regulations on how engineers have to carry out their jobs can be stifling. People work differently. There will never be consensus on the best set of tools or ways in which to view and build out code. That's okay. It's important to let developers leverage the tools with which they feel most comfortable. 

It goes beyond tooling, points out Jeff McConathy, Trulia’s Vice President of Engineering for Consumer Product. "Employees should be empowered to define which technologies are most suitable for specific tasks, while at the same time being held accountable for their decisions."

While there might be wide discussion on how to structure data to best facilitate the current task and also allowing for product growth and expansion, it's often best to let the engineers figure out the languages and frameworks best for actually carrying out the task. Forcing PHP onto a set of 20-something engineers—and other similar top-down declarations of technical frameworks or tooling—will often seed disinterest and discontent on the technical team, leading to more turnover than necessary.

Give engineers unique tasks and duties

Giving technical employees ownership over something is a meaningful step of trust. Doing this will often lead engineers to be more methodical and more thoughtful when working on something that is more or less their own. Carving out particular features or pieces of the software for a single engineer quite likely allows them to expand their own knowledge base, as digging deep on something solo will inevitably open up new avenues for the engineer, which, again, keeps developers engaged and enthused.

Felix Winstone, co-founder of Talkative, which makes SaaS for in-browser chat, voice and video-calling, recommends keeping developers' workloads distinct from each other. 

"The number one problem with motivating developers is a lack of purpose," Winstone says. "Prevailing wisdom is for every engineer to be well versed in every area of the code base. But if your role is not clear, or is shared among others, your work can lack meaning."