I previously wrote about how I worked on an agile team as a tech lead. The article focused on the things I recommend. Today, I’m going to take the opposite approach and share what to avoid: the misuse of authority including mistaking an influencing role for an authoritative one.

You can read the original article here.

Roles, Roles, Roles

On agile teams, a Tech Lead is far more like a Software Architect or an Agile Coach or a Product Owner or an Engineer than a Manager, Director, or another role with people reporting directly to them. You don’t have AUTHORITY as a Tech Lead, your weapon of choice is INFLUENCE. Of course, even people with authority should rely on influence as much as they possibly can. Authority is a tool in the toolbelt of some roles, and those people must use it sparingly. Autonomy is too important to take away from creative workers (and Engineers are indeed creative).

At times authority must be used by people in what I like to call “dark side” roles. Managers, Directors, Veeps, etc. must at times use the stick instead of the carrot. Usually, this is reserved for extreme cases when a team member is refusing to follow company policy or is threatening or endangering someone. In a positive culture, these things should seldom IF EVER happen.

One of the things I love about the organization at my current company, HealthEquity, is the culture of influence. Influence is the currency of the day at all levels of leadership, and it’s used efficiently and effectively.

What Does Misuse Of Authority Look Like?

Some key things to look out for: body language, word choices, and the audience. Watch for words like these coming from your mouthhole:

But, I’m the Architect/Manager/Director/Scrum Master/Tech Lead/etc…

…you have to do this.
…this is the only option.
…because I said so.
…it’s my way or the highway.
…eat crap and die.

Absolutes and personal attacks/insults are not going to work. They may sometimes achieve the immediate effect you wanted, but it’s going to come back to bite you in the end.

Avoid negative feedback in a group setting at all costs. If you MUST provide negative feedback (and yes, sometimes we must) always, ALWAYS, do so in a private 1:1 situation. Involve your people leader if you aren’t comfortable one-on-one.

Instead, look for ways to encourage, build-up, support, and assist people in doing what you believe should be done.

Shameful Anecdote Time

Once, in an earlier decade of my life, I was an inexperienced young team lead. I had responsibility for a developer who was undertaking a critical task. The task wasn’t moving along the way my manager and my manager’s leader hoped it would. There was some time sensitivity involved, and I was asked to research the issue and get things moving along. I did some investigation and found that the developer was spending a lot of time (over 50%) not engaged in his work.

I’ll admit it; I was frustrated.

Instead of following the advice I’m giving in this article, I decided to walk right up to this person’s cubicle and ask how the work was progressing. Nothing particularly wrong with the approach, although in hindsight, I should have known the discussion was likely to become sensitive. I should have invited the developer to a private location to discuss one-on-one.

Anyway, when we spoke, the developer told me how well it was going and how hard he was working and how he’d have this already late project completed just as soon as he could, but not for at least a few more days. When describing the work remaining, I felt it was completely trivial. It could have been completed THE NEXT MORNING.

I won’t go into detail, but I lost my cool. I felt pressured and I let the pressure rule my emotions. My voice rose high enough for at least neighboring cubicles to hear, if not more. I told this developer that he would finish this work by the end of the next day or there would be hell to pay.

I’ve never seen someone’s face go from zero to pure unadulterated hatred so quickly.

The developer finished the required work on my timeline, but I had ruined a relationship and completely demotivated my co-worker. As kind, cheerful, and pleasant as I could be, it never made up for my error. The individual became a habitual underperformer, and eventually was let go by our manager.

I’ve always wondered how the situation might have gone if I knew then what I know now. Would I have pulled this individual aside privately? Would I have offered my help or another’s on the team to push through the last bit of work? Would I have asked more about the situation and sought to understand why he was underperforming in the first place?

I’d like to think I would have. I’d like to think I’d have given less weight to some of the authoritarian “truths” I’d been exposed to growing up.

Avoid False Truisms Of Authoritarians

Avoid being taken in by the truisms of autocratic leaders like Bonaparte and Hitchcock. Do not let their philosophies influence your leadership style.

“Men are moved by two levers only: fear and self-interest.” -Napoleon Bonaparte

“If an actor comes to me and wants to discuss his character, I say, ‘It’s in the script.’ If he says, ‘But what’s my motivation?’ I say, ‘Your salary.’” – Alfred Hitchcock

The work we are doing in any creative or thought-related organization requires 100% of the team’s buy-in, commitment, and enthusiasm to be as effective as possible.

Leaders don’t and can’t have all the best ideas. Create psychological safety for people you work with to aid their growth and contributions.

Authoritarian leadership styles have little or no place in Agile organizations.

In closing: I recommend avoiding the “command and control” mentality in favor of “inspire and innovate”. Tech leads (and technology leaders in general) aren’t running military operations; we are engaged in creative endeavors.

If you enjoyed this article, why not check out some of my other favorites on the subject?