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.

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.

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.

Good at managing people--hiring, coaching, nurturing, and (sometimes) firing

Understanding of code/development--some knowledge is necessary

Manages up--represents the team and their interests to directors and executives

Filters and shields--keeps the team focused on important tasks

Deals with conflict--doesn’t avoid difficult conversations

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.

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.

About Tyler:

Tyler Hakes is a writer and content marketing strategist. He writes for 7pace on topics related to team work, productivity, and personal development. Nerds out about behavioral economics, physics, craft beer, and writing.