I'm probably not saying much. I liked it, it IS terse, and that IS useful. But, the red flags aren't no-go, you need to tease things out.
I'm in a NFP and was employee 22-24 and now we're 100. I know the pain of transition into states with intermediate management from 2-level. I've been in the c* role for the tiny entity, I think it doesn't deserve the c* flag actually, now, I work at a lower tier and I prefer it, because the decision logic drive isn't in me. I can't always fathom what we're directed to do, and I don't like that, but I do know some aspects of work depend on commands, not on mutual consent. So, sometimes, you wind up saying "please, tech, don't politicise this internally, do the things we need in other areas" and that winds up being told to do things, not doing it to common cause, (eg when you know a solution sucks, or is an outsource, but its a booked in signed contract you have to work to so your tech input to vary the spec or requirement was lost)
Sorry if I should have known. I did try searching and found Non-Farm Payrolls, Nurse-Family Partnership, Natural Family Planning, and an insurance broker. It's not one of those, is it?
NFP is used a lot in the not for profit sector, alongside NGO for non-government organisation.
However, I get asked about red flags so often that I finally tried documenting a few to help people get a sense.
My only suggestion would be to reframe as something other than red flags. Hiring is rarely a matter of binary yes/no evaluations.
In my experience, it's better to approach these as concerns that need further exploration during the interview process, or something to be flagged for additional coaching if the person is eventually hired.
Up, meaning that you are able to understand the goals and mission of the organization at a deep level, including questioning new directions to make sure you understand how they align.
Out, meaning you need to work with peers and indirect reports, leveraging relationships to get things done as a team.
Down, in that you need to hold your team accountable, or better yet, help them hold themselves accountable.
A good manager aligns his team with the business's actual, committed vision while protecting it from churn related to comments that senior leaders make in passing or ideas they are excited about for 5 minutes.
- Seeing their job as “protecting” their team from “the business”
- Talking about “the business” like a foreign entity
I’ve had to clean up many teams whose weak managers tried to isolate them in mini-silos, tossing problems over the fence to nameless mythical entities.
You don't want to protect the team from a foreign entity, having to understand the political structures around them or the actual value they bring to the organization.
You do want to protect them from pressures of working 60 hours a week. You want to protect them from feeling like their priorities are a shifting sand. You do want to protect them from a VIP who just goes to them and says,"can you do this for me?" which confounds another series of priorities unbeknownst to the cofounder.
If there are toxic elements of the business, you cannot completely shield them, but you do want to preserve an island of sanity.
The bigger the business, the more "protection" the job entails because the sheer number of moving pieces can subject a team to thrashing. The smaller the business, the more a manager needs to make a strong decision of if those toxic elements exist at all and stamp them out. If you need to "protect" a team at a small company, you are at the wrong company and need to get out.
This is the entire concept of Scrum, isolate the developers so the only contact is through the scrum master and the product owner. I agree it is a methodology for weak managers.
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.
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.
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.
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'
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.
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.
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?
> What possible meaning did you place on it other than that?
I do wish you the best of luck as you try new roles and advance in your career.
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.
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.
Typical path I see is IC at company A, team lead at company B, manager at company C. Some people do this in entire path in less than 5 years.
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.