Reporting to someone younger than you (even much younger) is perfectly normal, and common in the industry. Not every mid-late career engineer has management aspirations. What I don't understand is someone becoming a team lead out of the blue and directly managing multiple people with 6 months of total experience? I cannot think of any situation where someone right out of college would be a good fit for a management role.
I think it just takes a different view of management. If you think of management as a sort of permanent, exclusive role like in a traditional large company then yes it's hard to justify.
But in this case a young employee got the chance to lead a small team of three people, and as long as the company keeps an eye on it, management can be learned just like everything else, and if it doesn't work out then that's okay as well.
I think it's much healthier to see management roles as horizontal and as a process that everyone should try out, even early, rather than this status role that you have to climb into. Managers are part of a team and the best way to learn to manage is by doing it. You can have a great impact on the life of a young person if you give them responsibility even if they themselves don't think they can do it.
At a previous company, management pushed for all the Scrum Masters to be level 1 engineers. It felt like I knew nothing and was then being asked to lead my team of 6. While it was intimidating, it was a wonderful opportunity to learn and grow. 90% of my time was still spent coding, but that 10% was spent communicating with other teams and working out any issues that popped up across the 7~ scrum teams. It was a lot of fun and I only stepped down from the role so a young lady on my team (also a level 1) could give it a try.
It's kind of like in matt ridley's "the rational optimist" - in trade both sides think they're suckering the other side.
Yes, "individual contributors" have little power, sometimes get a little less compensation, and have to do the work.
But I've seen plenty of younger folks put in management positions. Instead of playing around with the technology that brought everyone to the company, they get suckered into bugging people and asking for status. They get to hear people's complaints about inconsequential things. They get to run meetings and juggle deadlines in spreadsheets and shitty enterprise apps. And they can't be always be friends with their tribe.
Back to individual contributors - they get to be less responsible. They get to play with stuff. They are more likely to be able to leave it at work. If they can't do something, they can ask for help. And they can "be normal" with the rest of the team. They can make jokes that arent' taken seriously and even spend time with others outside work.
Now where it could go wrong is power. If all of this becomes a power relationship it might suck. so don't make it that.
The most effective managers I've had were the ones who mainly acted as touchstones of communication and prioritization, instead of authority figures. Maybe thrusting someone under-experienced into the role ensures a certain degree of humility? Sounds like that's what ended up happening here
That is the "happy path" of a being a manager. In practice, problems with reports happen that require either an exceptionally talented (but inexperienced) manager, or some acquired experience to deal with them adequately.
Most new grads are still getting used to how a working environment feels for themselves, and probably can't handle tricky issues that involve other people.
I've known several offices and high-ranked enlisted military members. This is what I was told:
Yes, the most junior of commissioned officers fresh out of academy technically outranks the most senior non-commissioned officer that's been there for 20 years. Also, you can bet that that junior officer will get a very thorough chewing out if s/he ever disrespects the experience, commitment, and knowledge that NCO rank represents.
Very likely the guys just did the job and took care of themselves. It is not particularly rare. There are managers who don't contribute anything to actual output, coasting on ground work done by predecessors and being absentee enough to not interfere.
Had he ever faced an actual crisis, change or was stuck in the position for more than brief moment, this would very likely ended differently.
Similar situation for me in my 20s. It was my first real industry job and in particular was responsible for leading two people who, technically, were way beyond me and had been actively mentoring me.
Lessons I learned in this specific context:
1. Sometimes you become the leader because you you can kiss ass better than others. Sometimes it's just that upper management is an ass and you're more tolerant of that.
2. I learned a lot more about leadership from my mistakes than any successes. I don't think I was cocky, but more humility would have served everyone better.
3. Have your team members' backs. Having authority sometimes means keeping problems and mistakes internal. Exposing these upward can seem like its showing your ability to find and fix things and feel like the right (even the necessary) thing to do. It might be the worst possible thing to do by destroying team moral and any respect you may have had.
When comparing leadership that (mostly) works (in the military) to leadership that (mostly) doesn't, I notice a few fundamental differences:
1. Flat hierarchies. In SE, there are officially only very few levels between a grunt and the CEO. In the military, hierarchies are deep. You have squad leaders, platoon leaders, sometimes even more staff, company staff, and so on. That means the gradient between a leader and someone being lead is rather small. Ideally, everyone can step up to a higher position immediately (useful because of the, ahem, high fluctuation).
2. Planned career advancement. The military has always agreed that leaders (that is, officers) require special training. But that training comes after they have learned the fundamentals. In SE, most managers come from dedicated management backgrounds. If an engineer becomes manager that is considered unusual and difficult.
3. Strategic training. Officers have wargames and even colleges dedicated to improve their decision making. SE Managers have what? A few books on amazon? It's not just the how that is important in great leadership, the what should not be forgotten.
Your observations are interesting to me because #2 and #3 have virtually zero overlap with my life experience.
#2 - working at a major tech company, there was a big emphasis on progression for each level up the engineering org, as well as the expectation that anyone (with at least say, 6 months experience at a given level) would be capable of stepping up to fill a hole at the level above them on short notice. This happened from time to time and often was an opportunity to accelerate career progression -- if you did well filling in short-term at the next level up, you'd probably get some extra training and get promoted to make that permanent in the near future.
Also #2, in my 10+ year career I've never met an engineering manager (at any place I worked, or in my extended network) who got in via any path except spending >= 5 years as an engineer first. I'm aware that such managers exist, but I've never encountered one.
#3 - Every place I've worked has had a management training program of some sort. Where I worked most recently, if you wanted to move into engineering management you must be a Staff Engineer and you must apply (and get a supporting recommendation from your manager) to the Apprentice Manager Program (AMP). During AMP, trainees get assigned a small team to lead, and that team is part of the training program, as they give regular feedback. The managers in training attend weekly training sessions, have homework, etc., and are getting feedback from multiple directions throughout. At the end the candidate may or may not be approved to move to the manager track - and they also have the chance to decide it's not for them and go back to the IC track with no problems. They can also apply again in a year if they fail the first time through.
My understanding is this kind of stuff is pretty standard among major software companies.
> leadership that (mostly) works (in the military)
I'd say by everyday metrics, military leadership doesn't work. It is incredibly wasteful, structurally leading to the $5K hammers and an entire year to design an official face mask.
It also utilizes and requires a "punishment is one misstep away" dynamic - without which there would be no functional lower levels of the pyramid, and higher levels would look very different.
You treat an engineer badly, they leave their job and possibly go to your competitor. You treat a soldier/pilot badly, and ... you can keep doing that for quite a while.
Steve Jobs' management style was, perhaps, the closest SV can get to military style. It works, but I wouldn't work there. And Jobs paid people handsomely to endure that.
On the other hand, there's Linus Torvalds. He has incredibly effective leadership, over almost 30 years now, without hiring people, without even paying them, yet still getting a lot done. Not entirely flat hierarchy, but anyone is one email away from Linus (though not one commit away); No planned career advancement or horizon, and no strategic training.
I've seen many projects on the spectrum between Jobs and Torvalds, and in my experience the Jobs side of the scale is not generally more successful.
Who is effective on your scale? I suspect Jobs, Gates, Ballmer and even Pichai have alienated more people than Torcalds, if that’s your metric (it’s hot mine). Though Linus is the only one doing it in public - other than some anecdotes about chair throwing and cursing, you don’t hear about the others.
Yeah, I wonder if flat orgs are similar to open plan offices in that they're a good idea when you're small, but don't scale. On paper it sounds nice if there's only 3 people between you and the CEO, but that often becomes an excuse to avoid implementing any process for bubbling ideas upwards. "We're a flat company, just go talk to the CEO!" doesn't work when there are a thousand people trying to talk to the same person.
Not my experience at all. All kinds of random people - including HR office clerks, janitors and receptionists, this is no joke - end up sneaking into the product org via personal connections.
The bar to become a product manager is incredibly low in tech, as demonstrated by the mere existence of roles such as “junior PM”, often filled by kids straight out of arts college.
Regarding #2 - is that really true? My understanding has always been that while NCOs might well steadily work their way up from grunt to rank N, COs start immediately at N-1 (or N-2, whatever), minimal non-managerial/leadership training required, with indeed no expectation that they would ever fulfil any lesser role.
Then they work their way up from there, the NCO's maximum conceivable career goal being for them just some minor stepping stone on the way to whatever - or they get stuck/give up on the way, and go off and do something else. Up-or-out is not uncommon in non-military lines of work either.
Apples and oranges. Officers start as O1 as second lieutenant or equivalent. Enlisted men including NCOs start as E1. An O1 always outrank any enlisted man. They go to completely different schools. Officers hope to go to eg Army War College and learn about commanding great units, tens of thousands. Enlisted schools are more tactical.
No. And not to the parent comment. Senior enlisted schools are tactical and strategic and philosophical, with a heavy emphasis on ethics. Even technical schools have both tactical and strategic subject matter to provide the basis for reasons and rationale for systems specs and design.
For example, before they ever see a fleet unit, junior Marine officers have had 10 weeks of OCS (not for academy grads), 26 weeks of TBS, then they are sent to the school house for their specialties, which can be for a few months to over a year. OCS and TBS are essentially run by senior enlisted personnel.
And I sat in two schools where officers and enlisted go the the same school, and where NCOs were coveted by the officers' after-school study groups.
Sounds like he did it right. Age and experience don't have to be a barrier, in fact it can work well. The young / new person likely has lots of excitement about their new role and will hustle hard to do right by their team. The more experienced person is in a position to put their expertise to work without the operational overhead of being in the coordinating role of team lead.
When I was in my first management role, I was in a similar situation. One of the best compliments of my professional career was when a much older team member said that I'd helped him reinvent his career by the work I'd helped him take on. If we're all humble and honest with each other, these kinds of age / experience gaps can be good for everyone.
This. Management is harder than many, especially junior, engineers think. The key is that you have to intrinsically want to do right by your team, sublimating your ego for the greater good of the whole. Not everyone does, and to me that’s table stakes for management, it means the person has the raw material to be a decent manager. That said it’s not sufficient. The hard part is trading off the team needs and desires versus the larger strategic imperatives. That and resolving conflicting priorities within the team.
Still, “doing right by the team” is distressingly not universal, or even when present, many don’t actually know how.
I've been led by people much younger than me many times. The thing that helps the most is just transparency. If I know the reasons for decisions, I won't always like it, but I'll back off. Also, ask for what you really want instead of what you think will accomplish that. If the budget was cut by X dollars, work with your team on the best way to deal with that instead of choosing how to deal it with on your own.
I wouldn't think of it as a leaders / follower relationship - it's more so a partnership / fellow colleagues relationship. I'll gladly report to younger people if their perceived nature of our relationship is more flat / equitable than it is hierarchical.
Management is a function of maturity. There are kids who have just graduated from B school and with just a year or two of work experience, who are great managers. We have to remember that they have been living on the planet for 20-24 years and their experiences in life , families , sports teams etc. Define their level of EQ and maturity. So it’s not just those years of work experience that lead to great young managers - it’s life experience as well.
Leadership is about getting people from point a to point b. Generally to do that you need trust, a good idea of where point a,b are, and what the path between them looks like.
Age is a component of trust, but only a small one and very dependent on the situation.
If you want to be leading someone who has more experience than you, best be sure you have trust and a rock solid understanding of the path you need to be on.
I had a really funny exchange with some longtime former Microsoft executives. They were talking about another former colleague still at Microsoft, who was not known for being that smart or talented.
“How did he last so long?”
“Oh, he never became a manager.”
It made me realize how lethal management is as an occupation. Enemies above, below and on all sides, who would want to sign up for that?
A 'project' can easily be led by a very young person, with super experienced techies.
Think: bathroom/kitchen upgrade.
But if it's 'direct leadership' ie the kid was to literally work on the project with them, leading the details, then it's just ridiculous.
In the former case, don't even think of it as 'giving orders'. Think of it as 'setting project parameters'. The team will fill in the blanks.
At 20, there's nothing you can do but trust them. You don't have the experience to know when/if they are screwing you over. You definitely won't know if they are not even aware themselves.
A cynical manager might assume nefarious/lazy when none is there. A too easy-going manager might get walked over.
But with 6 months experience the only thing you can do is trust them to do their jobs.
Basically frame the job as 'helping them do their jobs'.
Difference in experience and age are not really relevant as the skills required to be a good Manager have little overlap with the skills required to be a good engineer.
You can be a terrible soccer player but end up being an awesome coach and vice versa.
I don't think being led / managed by someone younger is a big deal, but this is a weird story. The author was just 6 months into his first job then made a leader of three much more experienced employees. That makes me think someone up the chain wanted those three guys gone.
I've worked in companies where standard practice was to give new managers senior-level engineers, because senior engineers were less likely to require some of the more complex management issues that someone more junior might.
Speaking as someone who, when I was a junior, only ever worked for first time managers -- I hated it, and wished that I had a more experienced manager. Meanwhile, my senior friends who had a first time manager enjoyed the process of teaching a new manager the ropes.
That makes a lot of sense. I remember having bad managers early in my career as well, but I was also in a customer facing position that required much more feedback from management (weekly one-on-ones). Compare that to now, when the only time I hear anything from management is when I get a raise, or a shout out at the end of year "all hands" meeting.
I think mainly what's wrong is our thinking of it as hierarchical. The "leadership" position should be/is a support position to help production staff perform to the best of their abilities. That could be someone less experienced as long as they're good at eliminating obstacles for their team(s) and communication.
It definitely helps to be familiar with an organization to actively participate in it. You can accumulate political capital independent from the management structure, though, and you can manage without playing politics.
I always suggest folk to embrace and understand an existing organization's culture before attempting to effect change within it.
It's usually a bad idea to try to change a process without understanding the reason behind it. It's always a bad idea to try and change it without TRYING to understand the reason behind. it.
I'm one of the most senior/revered software engineers at the company I work for, and my manager is just a few years out of school. He's interested in developing his management skills, whereas I and many others on the team are not. It seems to be working well. Our company culture highly values servant leadership, though.
It's not really that strange. My first full-time gig as a software engineer threw me into the team lead position at the six month mark as well. I found that we simply work in a field where most people do not want to be in a leadership position.
> where most people do not want to be in a leadership position
This happened to me too. I didn't picture myself as a manager and I thought I wasn't legitimate to lead the team, being less experienced. But it turned out my team members were quite introverted and none of them wanted to take that role. In the end, it was a fruitful collaboration and a very good experience. I never saw that position as hierarchical, more of a different role within the team.
Yes I couldn't agree more. I am currently in a leadership role and I feel like I spend most of my time taking bullets for the team. I am not trying to act like a martyr or anything but someone has to go to a bunch of stupid meetings and if that means a marginal increase in pay then I am happy to do it. I don't get to write as much code as I want but it still is a means to an end.
thinking you're in charge or leading someone when you're a manager is a bad mentality. you should look at yourself like an offensive coordinator on an NFL football team, and maybe not even the head offensive coordinator. You're a role player. you have a role to fill, and it's not leadership. Maybe you _will_ be a leader from this role, but it's not what it calls for.
If someone is more capable than yourself as the developer then do not lead. Let him/her do their part and try to learn.
If you are a manager then your duty is not to lead but to facilitate development, help them organizationally and in this case your experiences are orthogonal and are not subject to comparison.
I think the reality is that a manager’s job is alignment. Sometimes that is resetting the expectations of the organization, and sometimes that is redirecting the team or team members. Realigning without pissing people off is what leadership is.
Managers who only ever “interface” or act as a “shit umbrella” end up screwing the team over in the long run.
Your surgeon metaphor only stands up in a situation where 100+ Surgeons are operating on the same person.
Anyone writing code is not leading. That largely goes for Staff Engineers and up, not just managers.
Architecture review, product strategy, ensuring knowledge transfer and robustness to turnover, developing hiring plans, and ensuring your people are set up for success and are set up for career growth - that is leading.
Leading by implementing is a nasty anti-pattern, like a player-coach. It just means you’re doing a poor job of both by not focusing.
In coding, leadership by example and mentorship are one of the most fundamental aspects of true leadership.
In fact, if you have junior devs, the most rapid way to make them more productive, is by putting them with senior devs with good habits they can lead from.
The article is also misguided: someone with 6 months experience can literally not 'lead' someone with 20 years experience in the hierachical sense. It's completely illegitimate.
They can however, manage staffers with senior abilities, in the same way you can hire contractors to build a house. The 'contracting' relationship implies a lot of trust across the boundary, which is what will have to be the case in a 'junior leadership' role.
In fact, they probably should avoid calling it 'leadership' in any sense of the word.
He is probably the 'team bus driver / manager / stock guy' compared to the senior devs, who are like the 'players on the field'.
I think you have it very backwards. Coding leadership usually involves nearly zero coding itself. Rather it involves getting the other person to write down RFCs, tech specs, requirements, design diagrams, etc., and guiding them through how to think about macro structure of solutions and outcomes for specific product deliverables and business cases.
Training involves teaching specific tactics of coding, like a new technique of multi-processing, or an approach to refactor a legacy class implementation. Helping someone learn tactics is teaching or training, which is a different thing than leading.
A young person could lead an older, more experienced person. For example, they could drive them to outline a solution in architecture documents that better align with product management. That can be true even if there are no tactics of software design that the younger person can teach the more experienced person. So that doesn’t reduce credibility or anything in the leadership sense.
In general it’s important to separate these: mentorship, coaching, teaching / training, and leading. They are all very different things.
This statement trivializes far too much the mechanics of code and software.
The 'process requirements' like RFCs, tech specs and requirements, are important, but they're not generally that hard.
It takes 5 years of being surrounded by 'good devs' to understand the more material aspects of software - and the very long list of more mundane things.
It's like an apprenticeship.
There's just 'a lot to know'.
Basic style, approaches to solving common problems, getting comfortable with the toolchains etc.
On mobile, just knowing when to do something in 'native' on Android vs. not.
Just getting comfortable with git.
Every tech domain has a ton of 'know how', in the above example, it takes 6 months to really be comfortable with the JNI java bridge for example.
Good code review etiquette.
Being able to compile massive code bases and overcome the invariable problem on the different platforms.
Knowing how how to properly approach a bug fix, how much to test.
etc.
During this time, there's no way a 'young dev' can 'lead' a much more experienced dev.
A young person could certainly 'lead a project' but they'll have to depend pretty heavily on the professionalism of the senior devs.
FYI - if you're building basic CRUD apps on relatively established frameworks, and never need to go beyond that at all, a lot of this can be compressed.
After 15 years as an individual contributor and five as an engineering manager, I have to say, you are flat wrong. Doing the work of implementation is a dime a dozen. Getting quality RFCs and prior alignment on solution architectures is at least an order of magnitude more difficult, more valuable and more rare.
Cocksure senior engineers who think, “RFCs are easy, this’ll be quick” are the single biggest source of money-wasting errors that I have to navigate.
I’ve implemented huge distributed applications serving machine learning predictions in global scale ecommerce products, real-time image processing, eventually consistent and SOX compliant billing applications and dozens of other similar solutions in my time as an individual contributor.
Being a manager responsible for not wasting hundreds of person-years on the wrong architecture is way more challenging. It’s not even the same sport.
Correct, the captain is not a managerial or decision-making leader at levels higher than pure implementation.
The soccer captain might influence who takes the penalty shot, but they don’t choose the lineups, tactics, player recruitment, training workflows, etc.
The “lead” in “team lead” is not referring to leadership in the same sense of this discussion, only in a much narrower implementation-only sense.
The coach is the leader of the team overall. The captain is the player on the field who leads the team on the field. The captain is not the one deciding the strategy for offense and defense; he/she is more responsible for exemplifying character, work ethic, motivating others and keeping up team morale.
> Architecture review, product strategy, ensuring knowledge transfer and robustness to turnover, developing hiring plans, and ensuring your people are set up for success and are set up for career growth
Of this list, I would say only product strategy is leading. The rest is managing. Of course one role could and often does have elements of both. But leading means making decisions, rejecting some things and advocating for other things. Leaders have their butts on the line for their decisions. Managers are more the implementors of what the leaders decide.
"Co-ordinator" describes the work that a lot of these managers do much better. A lot of my manager's work in spent in having meetings and such with other teams to find out things that would otherwise take the same amount of time out of 5 people's calendars.
The description of the job in OP's post sounds like it's largely a project management role.
I ended up in a similar role during my first job out of college, with a fancy title, managing people who all had more experience than me.
I was chosen for the role because I was very detail-oriented and was willing to do the organizational work to make sure everything was running smoothly and on schedule. Not everybody enjoys that work; sometimes it can feel like secretarial work. But if you can do it well, it's a good way to start out your career.
You got me thinking.. "manager" truly means someone who should be managing resources and process, smoothing out the kinks and letting his team work like a well oiled machine. Unfortunately most managers are rarely this, they thrive on micro-management and road-blocking initiatives.
What are you basing the idea that most managers aren’t like this from? All of my managers in my 15 year career have been about managing resources and process. I have yet to have a micro-managing manager.
My best managers were experts at that. Didn’t realize how good they were until they got poached. It helped that they were able to push back on things above them they knew to be harmful.
TL;DR: New team lead learns that "leadership" isn't about giving orders?
I agree with the other commenter who says "Sounds like he did it right." Leadership isn't ordering people around. It's more like steering a ship in the proper direction.
And I think it's hard for a young person coming in, even a very talented one (or maybe especially one), not to go in thinking they know all the answers and creating a lot of friction. Or thinking that obviously things should be done differently.
I agree that in general a lot of senior people (including myself) have no interest in managing. But my best managers have always understood to manage liqhtly.
Yeah, I get that. It's ironic that not knowing all the answers is the key to managing well. More specifically, not believing that you have to know all the answers. That's part of why you have people on a team.
I have read (somewhere) that the single most important role of a leader is to create consensus. It is not your job as a leader, ideally, to make the decision, but to facilitate your team members coming to a consensus on the best decision. Sometimes, of course, you will have to make a decision, and that is where having a strong background in the area helps out, but that is when a consensus could not be reached or some other constraint got in the way of your team coming to the best conclusion themselves.
Also a Steve Jobs quote I always found informative on leadership, “You don’t hire smart people to tell them what to do; you hire smart people so that they can tell you what to do.”
The hierarchical org structure in software companies is so broken. It has all the problems of a monolithic/centralized design and very few benefits. It's copied from people that were copying military organization which makes no sense at all.
The alternatives are many but pioneering new org structures is scary to most people. The cargo culting is extreme in this case.
Some company that is The Next Google might have a new org structure as its defining characteristic and core advantage.
I meant the latter but the former is probably true as well. It does seem telling that elite military units don't operate much like the bulk of the military does.
The key part of modern military organization is the utilization of specialized staff officers for planning and management.[1] Even elite units still use it at the battalion-level or above. Organization below the battalion is driven by a LOT of factors which vary across nations, but there's a reason so many countries employ a division of labor for specific functional areas for which a unit is responsible.
