I've had the luxury of working for a quickly growing company, which meant that they were always short on managers, so virtually anybody with the interest would get a shot at running a small team. Fast forward a few years and I'm running an organization of about 200 engineers. At least for me, there was a big right-place-right-time component.
In my experience, the transition from an individual contributor to an entry level manager is awkward, but not exceedingly hard. If you're a good engineer and work reasonably hard, you can (albeit shouldn't) stay involved in detail in everything happening in the team. To be clear: that's not recommended, it's a trap. On the upside, performance evaluations are still relatively easy. (Maybe awkward to communicate, but at least you will KNOW intuitively how well people are doing and you'll get a trust bonus.)
It's when you take the next step that things get much more challenging. You get to coach people and manage indirectly. You can't keep everything in your head that's going on and you have to learn right now to let go enough.
The step after that becomes easier again. Strategy gets added to the mix and that's not everyone's cup of tea. There's more representation challenges and more politics. But you get to work with more senior people yourself, so people management gets a lot easier at that stage.
In short, every step along the way has unique challenges which keeps things interesting. People don't get boring!
People tend to ask how they get a shot at managing others regularly here. Somebody else already said that it's highly context dependent. So you may have to change jobs to get a shot. At the very least though, gently make your interest known before you pull the trigger on that. You might be surprised.
I think more interesting than the question "how can I?" is "should I?".
If your primary motivation is career advancement, then you might find that you're not cut out for the job. (You might also discover that it was your calling all along, of course.) IMNSHO, the best managers tend to be at least a tiny bit reluctant because they recognize the burden of responsibility for others. They realize it's not about them, but everyone else. Without their team, they are nothing, but without them, their team might still be okay. Their impact is that of a force multiplier, and they'll rarely get to go home thinking "that was a mighty brutal bug I singlehandedly fixed today" or something similarly directly gratifying. They accept that sometimes doing the right thing by someone does not involve bring their best friend and do the job anyway. They are constantly in a tension between representing their employees' interests to the company as well as the company's matters to their employees. They accept that there's no more black and white in their professional life ever, and that it's compromises all the way down. (Except for some matters of ethics, eg. sexism, where there must not be compromises.)
But above all, they have to care. About what the company does, about how it does it, and about the people that make up the company. They will find a way to be themselves within that envelope. People will know that they care and repay in trust and commitment.
I've had a lot more success with growing managers by looking for people with the right attitude and convincing people to try than with people why stick out mostly due to eagerness.
When I went from freelance developer to managing a team of 20, I went through many of these challenges, especially of feeling like you're handing off a project that won't be done as well as if you did it yourself.
But when you find great people and the project is done as good or better than you could have done it it feels amazing as you're accomplishing more than you ever could have by yourself.
I too have had that uneasy feeling you are talking about. Letting go of total control over how things are being done as I went from just me hacking away, to leading a small team has been interesting. I tell myself (sometimes to my team directly) that we can just redo any choice that we make if it doesn't work out or we will work together to make the choice work. I want them to own problems and decisions. I want to empower them to as best I can.
As a result, I have never had to totally redo any technical choice that my team has made. We have had to fix a few things together, and that has only brought us closer.
I took that approach for a while, but it ended up blowing up in my face one time too many.
Now I try to block bad code from landing in the first place by requiring code reviews prior to merging into master. Sometimes a patch is thrown away entirely and usually it takes two or three tries before a patch is ready for merging, but the overall code base quality is higher.
I think there is a fine but meaninful distinction to be made here: One can (and IMHO should) require code reviews for each change, but not be the person to actually do the code review. If every code review needs to go through you, then you become a bottleneck. This means that you need to trust members of the team to do solid reviews, and you focus on observing the team's processes and debugging problems like:
- We don't have clarity on what our conventions look like.
- People take too long to review others' code and it blocks the team.
- People get interrupted by code reviews too frequently and it keeps them from focusing deeply.
- We are missing some piece of build/test infrastructure and it isn't clear to any one person that she should take 3 days to do that longer-term investment work.
- We don't have a clear way to onboard newer team members into our frontend toolchain and so it takes them a long time to get productive.
- There is a process people are following which is just getting in the way and can be slimmed down or eliminated.
I agree. I didn’t mean to indicate all code reviews should go through the tech lead. But the tech lead should have a circle of trusted lieutenants who act as gatekeepers. That’s how linus runs the kernel and it seems to work well.
I am in the same boat; I'm good at taking responsibility and doing "The Right Thing"(TM) when it comes to my own work. Having to be more directly invested in what other people are or are not doing makes me feel uneasy. I think it's going fine and I don't hate it or anything, it's just that worrying about other people's work isn't really my idea of a dream role.
As is the case every time I see an article like this... I agree with the points - but I want to know how one gets the position, not what to do when you get there.
The fact that it's just sort of taken as granted is a frustrating thing for those of us who have wanted, but never been offered, such a position.
I made the transition about 4 years ago. In trying to help my senior engineers level up to leadership positions, I've learned the following:
1. Leadership = Ownership
2. Organizational priorities > engineering purity
3. Tact > undiluted truth
In order to be able to lead more than one person, you need to be able to first lead one person: yourself. Ownership means taking a responsibility assigned to you, understanding why it's important to the organization objectives (rather than blinding executing), driving it to completion and reporting progress without your manager ever having to poll or prod you.
As engineers, our first instinct is to engineer things the best possible way with the best possible technologies. As managers, we'll need to understand that in a non-ideal world, there are tradeoffs. Sometimes you need to be able to prioritize organizational goals ahead of your engineering preferences. E.g. sometimes you'll need to maintain a legacy codebase a little longer even though you know you want to rewrite using the latest tech; sometimes you'll have to prioritize new features over tech debt etc.
As right-brained/logical individuals, we tend to hold objective reality over all else and tend to communicate it in concentrated form. We may want to be efficient in communications, but sometimes in doing so, we end up making the team inefficient by unnecessarily generating negative emotions within the team members. Communication is a local maximum. The global maximum is the team. In other words, sometimes you must suffer fools gladly, you'll need to learn to tell people no without hurting their egos.
If you exhibit these qualities as an engineer, any good manager will mark you as a lead candidate.
This is correct, but it's important that you never dilute the truth so much that you end up not delivering the whole truth. Obviously, you should avoid ever being in such a situation, but if circumstances are such that you have to choose between delivering the whole truth or tact, choose the truth and clean up afterwards. Hurt pride can be mended, broken trust and untruths left to fester generally can't.
I agree on the ownership and proactivity being key here. Look for possibilities to show and practice leadership skills within the current company setup and role.
This can be as simple as taking one story end-to-end to production from requirement analysis to deployment and experiment analysis while interacting with different roles (product, engineering, devops) and even explicitly asking your manager(s) for such possibilities. Being the person that knows the progress and owning success is key here, plus you will score some points for being someone that work can be delegated to.
Organising learning groups, guilds is also of help to get visibility within an organisation while still being fairly close to tech as you form a group of people around a topic you're passionate about.
Another important aspect is cross-team collaboration. For example, bringing key people together to solve a problem for the organisation (i.e. spending too much time on deployments, production incidents, repeating the same problems). Calling such situations out and suggesting ways to solve it or collaborating on a solution is another great way to try out leadership skills.
I don't there's a single answer. The "right" path is usually some combination of soft and hard skills, persistence, and dumb luck. Skill and persistence come into play because to a large extent, you are the master of your destiny, corporate or otherwise: you can settle for what's expected of you in a role, or you can go above and beyond, trying to find and fix pressing problems that others didn't even know they have, trying to help others grow, persuading other groups to give you the tools you need, and balancing it all with the reality of the business... Rinse and repeat enough times and you will probably be noticed for good judgment and the ability to get stuff done.
Now, dumb luck comes into play because to some extent, it's also a matter of being at the right stage of your career at the right time and in the right place. In some companies, especially smaller ones, there might be no way to become a manager or a director until somebody retires or is forced out. And if you miss that window, it might be several years until another opportunity to advance presents itself.
As with any other role, there are also many "wrong" paths, depending on the culture of the company; favoritism, cronyism, political horse-trading, bamboozling people, and so forth. But realistically, such things are less common than most people think. It's just easier to be cynical about others than to acknowledge our own personality flaws. We all have some, they weigh us all down; we just need to find a way to work around them and hope for the best.
From my experience you have to exhibit signs of leadership yourself before leadership position finds you. If you are already working in a company and when there is a problem, offer solutions, speak up, communicate your ideas. If your manager doesn’t listen because they think they have a better solution and you disagree speak up, challenge their idea. Being a leader isn’t easy it means sticking your neck out in the name of finding the best solution for the team.
It also means when you offer solutions and it’s accepted you will become the go to guy / girl for everyone, that’s how people around you will see you as a leader. You took that risk to stick your neck out for them.
You will also then have to learn to work with people learn how to motivate people because now they are coming to you. You can’t just shun them away you have to offer a solution to their problem. If you don’t have an answer empower your people to find a solution.
Leadership is an art form in itself, it can be learned, like any other skill. It takes a shift in mindset from being a worker to a leader.
Another key thing to remember you don’t have to have the “label” before you become a leader. If you act like one the label will come on its own.
I suggest you read / watch “Great Leaders Eat Last” by Simon Sinek. Was an eye opener for me.
Change jobs, probably? A toxic environment like this will not make you happy, and you can't easily fire your boss. The good news is that if you're working in IT, you probably have the luxury of being able to go somewhere else with relative ease.
On that topic, I'm a huge believer in a degree of financial independence, a rainy-day fund [1]. When you don't have to worry about having money for next month's rent, it really changes your outlook on things and makes it easier to make decisions that are just or right for you, without stressing over every possible misstep. And it's pretty easy to build such a fund [2].
Hope they actually steal it and implement it properly rather than completely butcher it so badly that you wouldn't want anyone to hear that this was supposedly your idea.
Erm, no. Speaking as someone who was raised on ideas like this.
This is convenient for others, but not for you. They will take advantage of you if you think like that and you not be seen as leadership material.
Either challenge it, leave or find a way to prevent that next time. If you truly have no choice but to put up, then you have no choice. But don't be naive doormat.
It depends on your professional goals. If your goal is to be esteemed by your peers then you are correct.
If your goal is to see how much good stuff you can coerce into existence for the company then it doesn’t matter who does the work, who takes credit, or even whether anyone realizes anything happened. All that matters for you to hit that goal is the stuff getting done.
Tolerating ideas stealing (and other sorts of toxicity) is not good for company either through. Because what will happen is that people who steal ideas will go up and others will grow resentful or will stop sharing ideas. Not reacting to things like that enables it and makes it more frequent. If you want to be leader, you have to be conscious of shaping culture and this is part of it.
Also, leader needs to be able to protect team or company from under-the-belt attempts of customers, suppliers, competitors and such. Some of them will try that for sure and it is leaders job to deal with it.
The words I most commonly try to say when a project I have passed off comes back to me are: "I trust your judgment." By explicitly saying them, it reminds me that I employ them to make those judgments, and my role is to step back and let them do it.
"Happy to help, are there any of the technical details you specifically need my eyes on? Otherwise, I trust your judgement."
Are you being approached because you are the only only around who actually remember working on the Foo Widget and the team wants to make sure they're not breaking something subtle, or are they implicitly coming to you for permission to trespass on your territory?
Former situation, you do the code review as a techie (and remember to commend the team for finally getting around to tackling the badness in the Foo Widget), for the latter situation you trust their judgement.
I wonder how much the author considers this applicable to lower levels of management, such as team leads? I’m transitioning into a TL role currently, and the “giving up control” aspect is the one which is the least clear to me. A TL is more responsible for technical details around project execution than a manager, so more control is required...but certainly less than working individually. Finding where to draw the line, particularly given that different people working with me have different levels of desire and readiness for autonomy, is challenging.
Even as a TL, the realization that my mistakes can negatively impact my peers is daunting. I have a lot more respect for the pressure that further leadership brings.
In my experience, the transition from an individual contributor to an entry level manager is awkward, but not exceedingly hard. If you're a good engineer and work reasonably hard, you can (albeit shouldn't) stay involved in detail in everything happening in the team. To be clear: that's not recommended, it's a trap. On the upside, performance evaluations are still relatively easy. (Maybe awkward to communicate, but at least you will KNOW intuitively how well people are doing and you'll get a trust bonus.)
It's when you take the next step that things get much more challenging. You get to coach people and manage indirectly. You can't keep everything in your head that's going on and you have to learn right now to let go enough.
The step after that becomes easier again. Strategy gets added to the mix and that's not everyone's cup of tea. There's more representation challenges and more politics. But you get to work with more senior people yourself, so people management gets a lot easier at that stage.
In short, every step along the way has unique challenges which keeps things interesting. People don't get boring!