It may surprise some project managers and executives to learn that trying to coerce, cajole, and bludgeon their engineers into just writing more code is not a solid strategy for attracting and retaining great talent.

Many companies focus entirely too much on trying to use extrinsic factors to drive performance of their engineering teams. In reality, it’s often the intrinsic motivators that have the largest effect.

Here’s the secret: Happier software engineers perform better.

This may seem like a simple (or even obvious) assertion. But, there’s no denying this fact. Multiple studies on this topic have confirmed that happiness and satisfaction are directly correlated with increased problem solving abilities and improved job performance.

If you want engineers that perform well–that find innovative solutions, build world-class products, and generally seem happy about the whole damn thing (or, if you’re just a human being who cares about the well-being of other human beings), then you should focus on providing the right environment for people to thrive.

It’s not just a hunch. It’s science.

You need to create a culture where engineers actually give a sh*t about what they’re doing.

Not because they’ll be rewarded for working faster or because they’ll be fired if they don’t work fast enough. You need engineers who are intrinsically motivated and care about their work.

Surprisingly, it’s not that all that difficult to accomplish if you pay attention to the findings of research on the topic.

Pay enough that salary isn’t an issue

You might think that throwing a big salary or bonus at your engineers will make them happier and therefore more motivated.

That’s wrong.

There’s something called the Two Factor Theory on job satisfaction. It says that there are two main types of motivators that affect professionals:

1. Hygiene factors
2. Motivation factors

Hygiene factors are the table stakes. If you don’t provide these things, your employees will be unhappy. They’re things like salaries, management, and working conditions.

But–this is the kicker–hygiene factors do not directly improve motivation. At least, not after a certain point. As the name implies, motivation factors are those that drive engagement and performance.

Motivation factors are less tangible. They’re more difficult to control and to quantify, like achievement, recognition, and growth.

For most software engineers, salary is a hygiene factor.

Yes, they want to be paid well. But more money won’t lead to better performance. Engineers often seek challenges, creative freedom, and personal growth. They want to feel motivated by the work itself more than be motivated by some outside factor.

Well-cited research by Daniel Kahneman shows that overall happiness and satisfaction (highly correlated with performance and motivation) plateaus at a reasonable salary. Some people remain motivated primarily by compensation, but chasing a motivated workforce with higher salaries seems like a losing strategy in the long term. (Note that the exact figure found in the study of about $75,000 may not be the same salary that’s appropriate for software engineers, specifically. They’ll likely be looking to paid a competitive market rate, which could be much higher than this specific figure.)

If your salary is below market rate, then you will have trouble keeping engineers motivated, even if they tend to enjoy their work. But salary is also a poor substitute for motivational factors.

Rather than trying to motivate your engineers with the promise of a higher salary or a better bonus, you should just make sure that your engineers are paid well enough that money is no longer a deciding factor. Take it off the table.

That doesn’t mean you have to pay the highest salary out there. It means paying engineers enough that they feel valued and aren’t tempted to leave based only on their pay.

Then, focus on the other factors that matter to their happiness and motivation.

Manage the process, not the people

Software engineers – like designers, writers, and strategists of all types – are primarily interested in solving problems. They want to analyze a situation, carefully consider the possible solutions, and then work through the implementation of the best one.

In a word, software engineers value autonomy.

But in practice, that means that managers should be trained to manage the process more than the people. Rather than instructing people what and how to do something, give them challenges and the right time and tools to solve those challenges.

This kind of freedom is something that professionals of almost any stripe crave. And, unsurprisingly, active management of people tends to reduce performance.

One study on software developers shows their feelings toward different activities that take place throughout the day. It’s probably not a shocker to learn that “coding”–or, probably more accurately, solving problems–ranks number one as the activity that most developers feel is productive.

Time tracking without the time-suck.

7pace is built for development teams who don’t have time to waste counting every second they spend working.

Fully integrated timetracking for TFS and VSTS that’s out of the way and works like magic (almost).

Things like meetings, documentation, and emails look a lot like distractions to many developers who are trying their best to focus on the problems at hand.

Of course, these activities are often mandatory parts of the job. Sometimes you just have to have a meeting to get things sorted properly.

Nonetheless, this points to the role that management should play in shaping the work environment. Their goal should not be to oversee individual tasks and work habits. Instead, focus on creating systems and processes that allow developers the most focused time to be productive. Set them up for success.

Giving someone a problem and challenging them to solve it makes for much more interesting work than directing someone to take a specific action. It engages higher levels of thinking and gives them some stake in finding a solution rather than simply being given a list of tasks to accomplish.

Give them a voice

Most engineers don’t like to be spoon-fed tasks. But they also don’t like to be given challenges to solve without context.

First of all, it’s just inefficient. By the very nature of problem solving, having as much context as possible is a prerequisite to being able to come up with the best solution.

But, more importantly, engineers should be given a sense of ownership over the work they are doing.

Not every project can be the most exciting. Not every product is the sexiest new tool on the market. But, as pretty much every entrepreneur knows, solving a problem can become important–even addictive–if it’s a problem that you feel strongly about in the first place.

In practice, this means having those meta-conversations about the work that’s being done and how it relates to the larger vision for the company. Or, how it’s helping to solve real problems for real people.

Isn’t that the whole point?

If you involve your engineers is discussions about why they are doing the work they’re doing–what it means for the company, what makes it important, and how decisions have been made to that point–then it becomes a collaborative, team effort to create something that solves a problem.

At that point, work becomes less of a job and more of a purpose.

Cut the stupid metrics

Many managers and executives still–yes, still–cling to measurements of engineering performance metrics like hours logged, bugs fixed, or line of code written (shudder).

Perhaps it seems funny that a software company that creates an application specifically for tracking time would question the premise of measuring performance based on time. But, it’s true. Time tracking is best used as a mechanism to allow developers to measure and improve themselves, not as a way for the company to evaluate performance.

If you think that you can motivate engineers by creating arbitrary goals based on these measurements, you’re in for a wake up call.

It’s a really poor way to measure work for creative professions that often require more “down” time spent incubating ideas, testing, failing, and restarting than actually “doing the work” (in the traditional sense).

Yes, it may take 1 hour to write a specific piece of code that does a specific thing. But it could easily take 5 hours–or even 5 days–to get to that point. These are not mutually exclusive.

Box’s former SVP of Engineering (now Google’s VP of Engineering), Sam Schillace, offers an interesting take on this whole thing.

He explains how Box implemented a specific performance rubric based on a variety of values. These values then have specific criteria that represent the person’s job, based on their position.

Rather than try to quantify performance that is inherently unquantifiable, they’ve found a way to make the process qualitative, specific, and segmented.

You should do the same.

Most developers don’t mind evaluating their performance and discussing it with their manager. It gives them a chance to reflect on their work and find ways to continue to grow and improve as a professional.

But the system for doing that needs to make sense. And, unfortunately, most companies are not good at doing this. So, rather than demotivating engineers by measuring their performance in a way that’s fundamentally broken, provide a positive feedback mechanism to help developers engage and improve based on their own innate drive for performance.

Create room for growth

Many companies focus so much on the day-to-day tasks and minutiae that they ultimately don’t offer their people any room for exploration and personal growth.

It can’t be overstated that most professionals naturally seek out opportunities to improve their skills and grow their abilities.

Maslow’s Hierarchy of Needs is a well-established model for understanding the natural desires for people beyond just meeting their basic needs for survival.

Among the top factors that motivate people are, unsurprisingly, esteem and self-actualization.

In practice, this means creating an environment for engineers to improve themselves. It means they have the opportunity to explore their own talents and find their strengths and weaknesses.

One well-known Microsoft engineer, Scott Hanselman, explains this well by creating his own version of Maslow’s hierarchy, specifically outlining the factors that contribute to each level of the pyramid.

There’s no surprise here, really. Once people’s basic needs are met, they become focused on something greater than themselves. They want to feel motivated and excited by the work that they’re doing.

Our job is to give them the right environment to pursue those needs.

Measure satisfaction, then improve it

This may come as a shocker, but you can actually measure the satisfaction of your employees.

It should be an obvious step, given that most companies measure hours, growth, speed, velocity, and any other other thing that can fit inside a spreadsheet. But, most companies don’t bother with any real measure of employee satisfaction, let alone act on it any tangible way.

Redfin–a technology-driven real estate company–measures their engineer happiness. Principal Engineer Dan Fabulich explains how the company uses Net Promoter Score (NPS), which is most often used to measure customer satisfaction, as a metric for their own employees.

“We’ve had fantastic results measuring customer satisfaction with NPS,” he writes. “So we naturally decided to measure the satisfaction of our employees the same way, with the same basic question: ‘How likely are you to recommend working at Redfin?’”

But even more important than the score itself are the insights that come from conducting the survey. You’re able to learn what kinds of barriers exist between your employee’s current level of satisfaction and something more ideal.

Then, you can actually take steps to improve that part of the work environment.

Retooling the perspective

At the end of the day, in order to do their best work, software engineers need to feel invested in the problems that they’re solving. They need some skin in the game.

If there’s one thing we know for certain, it’s that arcane methods for motivating employees don’t apply to creative professions. You can’t will your engineers into better performance by offering them a carrot. Nor can you expect them to perform based on the threat of a stick.

Keep time. Don’t waste it.

Studies have found, over and over again, that creative professionals thrive when given a sense of autonomy, mastery, and purpose–all 3 are important.

As such, any company operating in this old, outdated model of simple punishments and rewards as a mechanism for controlling performance is doing themselves a disservice. They’re poisoning their own well, driving away the best talent, and hurting their performance rather than improving it.

If engineers don’t feel motivated by their work, then they’re already half-way out the door.

7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.