Becoming a Technology Team Leader

Noah Brier, co-founder of Percolate, wrote an article for TechCrunch on Becoming An Engineering Manager, where he goes on to say:

Essentially the job of being a manager, beyond the human side, is about building a system of people.

While throughout his article he makes several good points that I agree with, I noticed that he was lacking in some parts of his message, and his use and description of the position of manager is something I strongly disagree with.

For the past 6 years I have found myself in managerial positions in a number of organizations varying in size from small startups to national corporations. Each job came with its own unique set of challenges and teachings, but there has been one constant lesson shared among all those positions, and that lesson is best described in the words of a personal hero of mine, the great Grace Hopper:

You manage things, you lead people. We went overboard on management and forgot about leadership.

My refusing to think of human beings as things that need organizing and managing is why I refuse to call myself a manager. I do not see the role as managing people or building systems.

Contrary to what you learn in traditional corporate management training programs (of which I’ve had to attend a few) the role of a manager is not about evaluating skills and personalities, or knowing when to play one pawn and when to play the knight: that’s called Chess! Rather than refer to the position as “Manager,” I believe I have a better title for this role: Technology Team Leader.

The word “Leader” speaks volumes by itself, however, there seems to be the belief in our industry that software developers are special (though the connotation is a negative one).

Developers are surrounded by negative stereotypes, and instead of attempting to understand and appreciate each developer’s unique personality quirks, thereby finding better ways to harness their skills, the traditional school of management way of thinking would prefer to impose conformity than empowerment on these individuals.

Stereotyping Developers

I saw this firsthand while working at the CBC where I led a team of 17 developers. When I was first got approached for the role, the department’s director told me:

We need somebody who understands and knows how to deal with developers, as nobody on my team knows how to motivate them and get their trust.

I took that as a sign of the director’s willingness to build bridges and empower the development team. It wasn’t until later than I learned another important lesson, for I found out how very wrong I was in thinking that.

On the first day I started the role, I had a project manager pounding on my door. Without even an introduction or welcome, the first words out of her mouth were a demand that I fire a certain developer. The developer had previously expressed concerns about the technical aspects of a project, and had been vocal about the decaying code quality, the need for better testing, and his desire for more discussion around the project’s goals. I explained that I was not going to do anything until I spoke with everybody and understood what the situation was. “Well you better handle him” is all she had for a reply as she fled my office office.

Another senior-level manager uttered this nugget:

“Web developers, they are a different ‘breed’ of developers, not like good ol’ Java developers.”

The way he waved his hands about and the look on his face when he said the word breed clearly emphasized his feelings about the inferiority of the web developer.

I spent half my time at the CBC playing defense and blocking all sorts of attacks against my team by the corporate culture-pushing techno-illiterate, and the other half attempting to pull the CBC into the modern age of software development, only to be blocked by that same backwards corporate culture.

I had zero support from the Director who had approached me for the role. I had finally realized what they actually wanted, and that was not someone who empowered their developers but rather someone to organize them and buffer them from the all-holy upper management team.

Towards that end, a new senior manager was hired to oversee me and my team and other teams in the digital department (more buffers). He spent his first few months on the job working on his real-estate degree, then eventually started yet another side-business beyond the real-estate one! At no point did he bother to take the time to understand the level of technology his teams were trying to accomplish, nor did he leave his closed office enough to get to know his team!

That of course is an extreme example of how bad things can get with “Management” mentality. I have no doubt Noah and his team at Percolate are nothing of the sort, and from what I’ve read about the company, it genuinely seems like a great place to work. I just hope they can forgo the old-world HR terminologies, especially the title: “Manager.”

So what does it mean to be a Technology Team Leader? I’ll share some of the lessons I learned along the way.

The Human Parts of Leadership

Understanding individuals’ motivation

Noah is spot on over how important it is to understand people’s motivations. This is the first step to establishing a relationship with your team as a group and as individuals.

However, this is not a 1-on-1 weekly meeting you do going through a list of some scripted questions or following some book or article that you read. You must get to the point of WANTING to know your team, if you don’t want it, then you’ve already failed.

If being social is not one of your strengths (as it wasn’t mine) then you have to work on it, get out of your comfort zone and share, share a lot, get intimate and listen.

Establishing a relationship

Essentially you are making a friend, and more importantly: you are becoming one!

This probably goes against all the traditional “management training” you’ll experience in the corporate world, where you might be subjugated to hours of training videos and sessions by people who have never been in your shoes, telling you in order to succeed as a manager, that you must behave like a robot; But if you can’t be friends with your team, then why would they ever listen to you? or far more critical: why would you trust them, or them, you!?

Boots on the ground

It certainly is not necessary to share the same skills with your team (in this industry or any other) but it certainly goes a long way in helping you appreciate your team’s effort and in understanding their challenges.

A good leader understands the field of battle, while a great leader not only understands the field, but is also leading the charge!

The leader’s role is not to give commands or directions, but to be a part of the team in everything they do. From writing code, fixing bugs, suggesting ideas, listening to feedback, and empowering the team, a leader is there helping them to make their own decisions with and for the team. Your role is to facilitate good teamwork ending with measured valuable decisions, and not to making those decisions yourself.

Some might find a dilemma here: You’re promoted to lead the team, and not be involved in developmental tasks and bug fixes. I personally have no clue why anyone would want to stop programming, never mind not be involved in fixing bugs and building new product features. But if that is how you treat the promotion, that it elevates you beyond needing to do the grunt work, then that is how your team will see it. No longer would they see you as working with them, but would instead see you taking all the credit for your team’s hard work and accomplishments, and that is not only ridiculous, but poisonous to the team’s thinking.

To be or not to be (a manager)

Many promoted developers fall into the promotion trap, thinking they can balance the expectations of a typical managerial role, while retaining their connection to their friends on the team and continue to be part of the team in contributing to the work.

once they start behaving like “Managers of things” as the expectation of them is, they start loosing trust and connection to the team they came from, some end up reverting back to development roles since they enjoy that more and felt more accomplished, others keep pushing forward and fully embrace the managerial suit, until eventually they loose touch with technology and end up moonlighting as real-estate agents, or spend their nights playing in a bar band in search of meaning for life.

There is clearly a difficulty in staying on a coding role throughout one’s career as most traditional organizations (courtesy of evil outdated HR departments) are structured with a pay and/or promotion ceiling that ends at a senior developer level, and to move beyond that, you MUST jump to a managerial role.

There is hope however, not all organizations are structured like that, companies like Hootsuite, for example have a Guru program, in which they encourage developers to stay in programming roles, but continue to get promotions and recognition for their achievements.

Here’s hoping that’s a trend that goes viral!

YMMV

Don’t undermine the human factor! My experience and the people I’ve had the pleasure (and misfortune) of working with may or may not relate to some of yours. If you are a software developer being promoted into a Development Manager role, take your own path and don’t forget your roots! Stay connected to your team and never wear that metaphorical suit!

As for non-developers attempting to lead a team of developers, spend the time to know your team AND the technologies they are using. It’s 2015 and you still don’t know how to code yet? There are a plethora of courses, programs, and community efforts to help people learn a programming language. You really have no excuse.

Better yet ask your team to teach you! What better way to gain insight and knowledge while at the same time winning your team’s respect by showing that you are willing to learn from them directly!

Good luck!