1) Many early-stage companies end up with a bunch of engineers who don't want to be managers. You can't promote from within if no one wants the job.
2) These same criteria apply for promoting from within. Sometimes I chat with folks who think none of their people have what it takes to manage the team properly. Going over this model helps them re-assess.
Great points. Dual career track exists for good reasons.
If your ICs want to become managers, apply similar hiring criteria as you would to outside managers.
Also keep in mind that first-time managers can require a lot of mentoring to come up to speed as managers. If you're a small startup without additional bandwidth for proper mentoring, transitioning someone from IC to manager without proper support is not doing them any favors.
Promoting someone into management whose never managed before without a proper mentorship/training structure is going to be a mess 9 times out of 10. Since they are the first engineering manager the lack of mentorship/training is a given.
I've always like the anecdote taken from Carnegie's "How to win friends and influence people": hire the person who is the best manager, but don't neglect those who excel in their roles. Giving them a promotion of a new title with salary adjustment that reflects their value to the company, while maintaining their current responsibilities, keeps everybody happy.
Notably, Dale Carnegie never managed anyone and actually changed the spelling of his name to suggest to readers that he was somehow associated with wealthy industrialist Andrew Carnegie. I'm not sure he offers good engineering management advice and not, you know, trite pablum.
You seem to have some axe to grind about this, but it's not really helpful. Engineering management is hard, and a number of skills and traits are necessary. If ICs are willing and able to be promoted that's great, but it's not a panacea. When it comes to early scaling, even with the best of intentions the bottom line is you may be growing faster than existing folks can acquire the requisite skills. Of course hiring from outside runs the risk of cultural damage, but promoting from within runs the risk of dysfunction via the Peter principle. Choose your poison, but at least you're growing right?
Promoting only from within can also lead to an echo chamber of dysfunctional management and process since no one knows better. The blind leading the blind and all that.
no way. you'll take someone who is a great individual contributor and find they're a terrible manager since they want to turn everyone else into _themselves_.
if you're going to promote from within, please send them to a course or something. get them some real training first or you'll have a predictable outcome.
having someone cut their teeth on you as their first management position is BS and the rest of the team will probably resent your new 'hire'
That's a good chunk of the role and why they got "promoted" though! You want more such cogs, so naturally you expect them to make others into similar-behaving cogs. Otherwise they're just "admin" and you might as well automate-them away with tools and processes.
A good choice, but also bakes in some stuff. You may need to term limit this, once it gets bigger. Sucks for the original occupant but how do you change culture for the better against a near-founder?
How do you move from "move fast and break things" to being more risk averse against your obligations beyond startup phase? Might need another person, to get the other outcome.
I was promoted. I failed in role. Maybe that colours my outlook.
In my experience, companies naturally evolve away from "move fast" to "risk averse" as they grow and anyone who wants to preserve the former has to actively fight for it. There are surely examples where more stability is useful, but stasis is pretty close to the default as companies grow.
With all due respect, your failure in a new role is your own.
Bringing in outside managers is an anti-labor practice. Especially in the context at hand, where we're talking about a company's first EM.
"What if they ruin our culture?" Promote from within, so you can be sure your first EM exemplifies your culture. If you don't think your own employees exemplify your culture, you don't have culture.
"What if we lose good people because of them?" Promote from within and backfill with a new junior hire. If your engineers are so hostile to each other that they can't stand the thought of one of them getting promoted, then you have a dysfunctional company with a hostile culture. If you yourself have the prejudicial belief that your employees will get jealous, then you're actively supporting the same anti-labor culture that says that salary transparency is bad because it makes employees aware of structural inequity.
"What if they cause harm?" Promote from within, and you can be sure that they have far more historical context and product insight than a random person you might air-drop into your team.
Unwillingness to promote from within says far more about the founder and the labor-hostile culture they're building that it does about effective engineering.
> With all due respect, your failure in a new role is your own.
What possible meaning did you place on it other than that? I completely own my own failure in role. Why else would I say maybe it colours my outlook ?
Struggling to understand what value you thought you were bringing to the conversation, saying this. You really think I didn't own my own mistakes? Why?
idk about your "anti-labor" strawman here. promoting wholly unqualified internal people who have never managed anyone before and expecting them to take over a high performing team is not a good plan, nor is it "anti-labor". think about the people on the team who have to suffer as this internal candidate learns things that anyone with schooling or training in management would already know. at least send them to a course first or something. "historical context" and "product insight" don't count for anything in an engineering manager. they're not a product designer. that engineering manager should manage engineers, not plan the product. if they want to plan product, pick a C-level position where they can do that and hire a _manager_ externally.
promoting wholly unqualified internal people who have never managed anyone before and expecting them to take over a high performing team is not a good plan, nor is it "anti-labor"
So provide training and mentoring.
We have normalised in our industry that the only way to progress is to job-hop, and it's actually to the detriment of both engineers who have to jump through the ridiculous hoops of interviewing these days, and companies who lose their valuable assets every day.
> We have normalised in our industry that the only way to progress is to job-hop
I share that this is a bad state but I think this situation is an exception. Almost all the engineering managers I know got promoted into management in a company where they held an IC position before. (Almost) nobody hires engineering managers without management experience.
this 100+ -The assumption a subject matter specialist who has fulfilled a role can become the C* is a fundamental problem. Everyone thinks it will work. Sometimes it works. Its not a given.
Managers have to learn how to be a manager. Believing anyone can do it ab initio devalues the role.
1. If someone was promoted from within at another company, should their next job be a senior engineer again? Should we have our managers grinding leetcode when they're looking for their next position? If there is more than 40 hours of management work in a week, does the developer stop coding? If they stop coding, how will they get their next development job? (After all, you aren't hiring managers, you're promoting from within.)
1a. If this is the case, does your management team all keep coding because their next job will require it? Will management tasks become backburner, or do you have a large cadre of part time managers?
2. If you are promoting all managers from within, what do you do when you don't have any developers who want to manage?
I was a developer for over 15 years before transitioning to management. I'm not saying I'd never take a dev position again, but I am a better manager than I am a developer at this point because I've spent my time leveling up as a manager, not as a developer.
