You Don't Have to be a Manager to be a Leader Because Leadership != Management
You Don't Have to be a Manager to be a Leader Because Leadership != Management
Leadership is a way of relating to others. Management is an organizational construct. Many leaders are not managers, and (unfortunately) some managers are not leaders.
Hello there, I’m Dave Anderson! Welcome new folk, and long-time readers! This is my weekly newsletter where I share stories and advice for both technology veterans and newcomers on how to grow their careers, build their leadership capabilities, and level up their interviewing skills.
Today I’m going to talk about Leadership, and Management. Those two terms are often conflated. I’ll share how many leaders are not managers, and (unfortunately) some managers are not leaders.
Side note. We recently went to the South Island of New Zealand for a few weeks. Amazing place! Particularly if you like hiking & the outdoors. It’s like a whole country filled with Banff and Norway and Hawaii, all rolled into one. If you have a chance, I’d strongly recommend visiting! And beyond the pricey long flights, the rest of the country wasn’t too expensive. For example, I saw a vape shop which was selling farm fresh eggs for the equivalent of $4 USD. Pretty good! And I remember that price, because in what world does a vape shop sell & advertise farm fresh eggs? New Zealand. Because everyone’s a farmer.
We’re all repeatedly tricked when we phrase things as our “leadership team”, or “the leader of that group is…” because we use those terms loosely. Let’s address the difference between these concepts.
Dave’s definitions.
I’ve defined these words before in a different newsletter, almost certainly. But one of the best things about writing your personal newsletter is that you don’t need to be internally consistent. I’m just going to make up new definitions right now.
Leadership is the act of inspiring, influencing, and guiding others towards a common goal or vision. In short, a leader is someone who says, “This way everyone!”
Management is the responsibility to coordinate and organize resources (usually people) to achieve an objective or set of objectives. In short, a manager must ensure the work is organized, everyone knows their role, and resources are on track to achieve their objectives. This responsibility typically comes with organization given authority.
Why is it essential to be picky about this?
Non-managers frequently believe that leadership is not their job.
Managers often believe that they’re leaders, simply because they have responsibility.
Both beliefs are wrong.
Welcome to those of you new to Scarlet Ink! Each week I send an article to all subscribers. Free members can read approximately half of each article, while paid members can read the full article.
For some, half of each article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member!
Leadership without authority
Earlier in my management career, I was lucky enough to have a particular engineer transfer into my group.
In a one-on-one meeting:
Candis slid my office door closed, and sat in my guest chair.
As a side note, I was thrilled to have a guest chair because it meant I didn’t need to book a dozen conference rooms each week for my one-on-one meetings.
Candice spoke first. “I’ve been on your team for a couple of months, and it’s been great. Now that I’ve ramped up a bit on how your team operates, I’d love to convince the team to change a few things with our processes, if that’s alright with you. I could bring up my proposals in our next team meeting?”
I would have been just fine if she’d just talked to the team directly, but it was awfully polite of her to come to me first. It made me feel included, which is nice.
“Absolutely, go for it. Most of our team processes were decided by the engineers anyway. Happy to have you all change them.”
In our later team meeting:
"Next on our agenda.” I say. “Candis asked for some time.”
Candis looked around the room. “I’m really enjoying my time on the team. Thanks to Julian for inviting me to join. It was a great decision.”
Julian awkwardly smiles. “No problem!”
What a pleasant intro, I think to myself. Maybe a bit cheesy, but people like being appreciated. And I can vaguely guess that Candis is trying to make the team more receptive to change.
“I wanted to talk through a few things that I’d like us to test changing.” She said. “Then you all can decide if you like those changes, or not. They’re a few small things my previous team did differently, which I feel might apply to how this team does their work.”
Everyone generally nodded around the room.
Candis stood up, and walked to the board.
She proceeded to explain three major changes.
A style checker she wanted to set up on our build system. She explained that everyone on the team seemed to have a similar opinion about code style, and we should update our build system to enforce the style. It would decrease our code review steps, since we’d know the system would handle it automatically.
She wanted to decrease our sprint length from 4 weeks to 2 weeks, and see if we could insist on making them uninterrupted. She said our sprints were interrupted repeatedly during her two months here, and she suspected that we’d be better off with a shorter, but uninterrupted sprint. If our sprint was short enough, we could more reasonably ask partner teams to wait until the next sprint for their emergency work.
She wanted us to cross train more. She said that we had too many instances of a single engineer being the only one familiar with a system, and we’d all be better off if the engineers spent more time working on systems they were less familiar with.
On every item, some engineer on the team had issues with the proposal at first. And each time, Candis handled the objection well.
Team member: “That sprint length is too short, we couldn’t get anything done. We’d spend half our time in sprint planning.”
Candis: “I agree that we don’t want to spend a higher percentage of our time planning. That’s a good point. And I also agree that we need to be realistic about how much we could get done in a sprint. However, to your two concerns. Currently, our sprints are interrupted, often before two weeks have passed. So that’s currently an issue for us already. And our sprint planning time could be cut in half, considering we’re only planning two weeks instead of four. I believe it’d be a wash. But I’d love to try it if you’re open to it, and we can see what the experience is like?”
In the end, the team members agreed to follow Candis’s recommendations. While it doesn’t matter for the story, her recommendations all worked out well.
It’s interesting that Candis sticks out in my head. Why? Because she did a few special things:
She did it, not me.
She brought up the recommendations with the team, not with me. Most ICs, if they want to change something with the team, try their hardest to get their manager to do it. “Could you ask everyone to…” For reference, this also hits the “influence” expectation.
Had empathy.
I know it’s an engineer cliché, but many engineers are blind to the emotional impact of their recommendations. “We should change X because of Y.” While Y may be true, there could also be team members who like X, who invented X, and might have an irrational reaction to a proposal to change it. Factual arguments don’t always win, even if they’re right. It’s great to recognize change is critical.
Had a vision of a better way.
This is one aspect of having a vision for the future. It doesn’t necessarily mean that you have a vision of the next groundbreaking product, or where the company should go in 3 years. Any vision of the future can guide a team to a better place. “We could have shorter builds.”, “We could have fewer bugs.”, “We could have fewer pages during our on-call rotation.”. A leader doesn’t accept the current situation and react, they image a new place, and they help bring others there.
Leading without authority, even for managers
Jeff Bezos always spoke last in his meetings. I attended several meetings with him, and you could see the purposeful way that he had the junior members of the team speak first, then his TA (tech advisor), then the SVPs in the room, then himself.
The reason he chose that process is that he didn’t want the authority of a position to compromise the opinions of the rest of the team. He wanted to find the best answers to problems, or find the best vision for a product.
If he spoke first, he’d give his answer, and that would be the end of seeking the truth. If he waited and others had a chance to share, he could guide and inspire others, rather than dictate.
I’ve repeatedly been in meetings where decisions were being made, and I had to explicitly explain to my team that I would rather not be the deciding voice. Like the above situation with Candis, I prefer to take advantage of the smart people in my organization, rather than relying solely on my judgement.