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.
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.