When it comes to software development, we talk a lot about the “hard” skills.

Raw talent, individual intelligence, knowledge of frameworks and libraries. We all know these are important. But we often forget about the role of “soft” skills.

At the end of the day, every software developer is human. (At least, for now.)

As humans, we are driven and affected by more than just our abilities and IQ. Psychological and human elements play a huge role in the ability of a developer to do their job.

One of the biggest factors is how individuals on a team feel about the work they’re doing.

Do they feel invested and energized?

Or are they just there to punch the clock and collect their paycheck?

For software teams, lack of motivation is the enemy.

It zaps performance and productivity. It takes an otherwise talented and focused developer and turns them into a robot--someone who’s simply going through the motions.

Unfortunately, there’s no magic formula for boosting your team’s motivation and performance. But there is plenty of data and insight out there about the types of things that help keep employees engaged.

Let’s look at some of the biggest factors.

Focus on Process & Culture

One of the most important aspects of any team is the culture, which is often shaped by a process.

The role of a manager in a development team should be, first and foremost, to shape the process and the culture. A true leader should be focused on putting people in the best possible position to do their best work--not managing how they do that work.

As a strategist, creative, or engineer, the last thing that I want is for my manager to tell me how to do something. By removing autonomy with overbearing management processes, companies often create a toxic culture where developers feel they aren’t trusted enough to do their jobs properly.

Similarly, enforcing arbitrary rules or systems can impose a sense of strict control.

The why behind policies and processes is often just as important--or perhaps, more important--than the policy or process itself.

If developers feel that a certain policy is being implemented without merit or it’s harmful to them and their abilities to their job, they’re likely to reject that policy. Enforcing it will create resentment and lower morale.

Case in point: Most developers will reject the idea of time tracking on its face.

The reason for this is obvious. Tracking time has been seen as both a burden (i.e., timesuck) and a way for managers to exercise control over a process that they may not fully understand. Both of these things suck for developers, so it’s no surprise that they want nothing to do with it.

But, if the idea of time tracking is proposed not as a management tool, but instead, as a device that enables individuals to measure and evaluate their own performance--like a Fitbit for software development--then it’s no longer just a needless requirement.

Of course, some developers are still going to reject even the idea of tracking time (those scars cut deep), but others will come to understand it as a tool that has a clear benefit for them and for their team.

Put The Right People in Charge

There’s a famous phenomenon known as the Peter Principle

Basically, it says that most organizations take people who are good at their job and then promote them right up until the point that they become incompetent.


Source: Staffsquared.com

The elements of a successful development manager include some obvious skills, but there are many that may not be immediately apparent:

Obviously, this is bad practice.

Just because someone is an incredible engineer does not mean that they are a good manager.

In fact, given that effective leaders generally rely on skills like empathy rather than pure logic and problem-solving, it seems likely that the average software developer is not particularly well suited to lead a team.

And that is totally okay.

There is no rule that says that you must promote your most talented engineers into management roles. Many developers are likely to shudder at even the idea of taking on such a role.

What is important, though, is that you have the right people in charge.

The leader’s role is not just to enforce rules and take the blame if things go wrong. The leader of any development team will determine how the team works together, the level of engagement, and how motivated they feel by the work that they’re doing.

The elements of a successful development manager include some obvious skills, but there are many that may not be immediately apparent:

  1. Good at managing people--hiring, coaching, nurturing, and (sometimes) firing
  2. Understanding of code/development--some knowledge is necessary
  3. Manages up--represents the team and their interests to directors and executives
  4. Filters and shields--keeps the team focused on important tasks
  5. Deals with conflict--doesn’t avoid difficult conversations
  6. Leads by example-- set the tone for the rest of the team

Now, again, when we think about all of these traits, it’s clear that just because someone is talented at doing a job does not mean they will be talented at managing other people doing that same job. In the case of development managers, technical skill is only a small portion of the overall picture.

Make sure that your team is being led by the right person. The wrong manager can sabotage any other efforts to build a successful culture.

Make Work Collaborative

Lastly, most developers want a seat at the table.

The nature of creative work and engineering is that you’re tasked with dissecting problems, finding solutions, and then evaluating and implementing those solutions.

In order to do this effectively--and feel connected to the larger purpose--people need to feel like they’re being heard and included. Software developers want a voice.

Scott Hanselman’s version of Maslow’s hierarchy for software developers makes this point abundantly clear.


Source: Hanselman.com

Top-down management styles are about dictating tasks to people. For software teams, the process of assigning and completing work should be a collaborative effort; teams and individual team members should be involved in the strategy, planning, and decision-making processes.

Not only does this help facilitate smoother operations, but it makes the work more meaningful--it adds context and understanding around a shared goal.

Doing something because “it’s what I was told to do,” is not very motivating. But, having a deep understanding of the larger problem - and its consequences - can provide the right boost to push people to do their best.

When we think about what matters to developers, we should think about what matters to humans. What are the factors that provide people with a sense of pride and ownership over their work. What factors lead to people feeling energized and motivated. And which factors have the opposite effect.

When you get down to that basic level, the things that matter are pretty universal.

People want to be set up for success, they want to have a leader that they can respect, and they want to feel included and important. Developers want the same things.

Turns out, software teams are just made up of people after all.


State of software development 2018 report