Leading someone with more years of experience than my age
danielrrojas.com
danielrrojas.com
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.
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.
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.
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.
In some places it's a good fit to be a bosses nephew.
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.
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.
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.
#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.
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.
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.
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.
Guess again, Batman.
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.
He is not effective on my scale: he has alienated a huge amount of contributors with his abusive style of communication.
And please do not say that it is necessary for "filtering" and quality assurance, it is equivalent to justifying mobbing.
Another unsuccessful aspect I blame him for is the sorry status of the kernel security, "a bug is a bug" and similar stuttering nonsense.
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.
Still, “doing right by the team” is distressingly not universal, or even when present, many don’t actually know how.
Finally out of desperation I took the position. Although I made it clear I didn’t want it.
Yea. Left after six months in that role.
Which was longer then anyone else had lasted.
I liked him. He was good at role.
I ended up being his goto for advice on how to deal with others and dealing with hard situations.
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.
“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?
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'.
You can be a terrible soccer player but end up being an awesome coach and vice versa.
"The Way of the Shepherd: Seven Secrets to Managing Productive People" by Kevin Leman and William Pentak
The principal's within it are highly effective and are not impacted by your age or comparitive experience.
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.
When I was six months into the job I certainly didn't know how the org functioned, nor did I have any political capital to move things my way.
I always suggest folk to embrace and understand an existing organization's culture before attempting to effect change within it.
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.
Perhaps that's why these seniors are being managed by someone with less experience?
Guess it depends on the team concerned.
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.
If it’s done correctly, in most cases it’s just firewall/interface between the rest of the company and the engineers of the team.
Dealing with upper management is not really “leading” imho. You are not leading the team unless you architect, design and code your team’s product.
Are you leading a team of surgeons if you haven’t seen the inside of a surgery room since you left school?
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.
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.
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.
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'.
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 is an accurate description of leadership or architecture as it is practiced in this industry.
I've only seen leaders who are intellectual vampires.
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.
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.
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.
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.
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.
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.
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 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.
Do you mean "military organization makes no sense at all" or "military organization is not the correct structure for for-profit software companies"?
https://en.wikipedia.org/wiki/Staff_(military)#Continental_s...