Growing from engineer to manager
newsletter.eng-leadership.com
newsletter.eng-leadership.com
Both still put they hands on the product, but in completely different perspectives.
Maybe a store manager would be more applicable?
How the heck did that one work?
You’re right that people skills are more important but they are often necessary but insufficient depending on the specific team and business situation.
What needs to die is this trope. Few places cut salaries when people move to EM role. This might be true for some big tech companies, but even then it's only in the beginning. If you look at companies that have unified levels for SDEs and EMs (Google, Amazon), you can see that on the same level EMs have slightly higher TC.
Not to mention that there's a whole world outside of big tech where moving to management is considered a promotion (and often the only way to grow, because dual career ladder is not implemented everywhere). The cases where EMs make more than SDEs are really way more common than the reverse situation.
senior engineer == engineering manager.
staff engineer == senior engineering manager.
senior staff engineer == director / VP
This is in terms of scope, responsibility, salary, whom you report to and on which level... everything.
I doubt Mark Reinhold, Brian Goetz or John Rose are undervalued at Oracle because of them not being managers.
Acquiring incremental engineering skills is great and we should all do it. But let's admit that it's just that - incremental. You go from being a good engineer to slightly better engineer- something you already are.
When you pivot to management or something else that's more different to you - you are taking on a bigger challenge and there's no guarantee of success. In order to succeed you need to hone a whole different set of skills - and if you manage to do that, you will certainly have grown in a real way.
I totally get the sentiment that going into management isn't the only way to advance a career and I agree. I am just saying that those who take that path indeed open themselves up to a challenge and evolution.
Because I am not then gonna go down to a junior eng role, but I may flex into eng when it makes sense.
In my closing on 30-year career in this industry, "managers" have been the least important part of any team, and had the least impact on success or failure. I'm not anti-manager at all (although I have spent my entire career trying to stop people who think they are rewarding me or giving me a promotion by giving me more "manager" duties. I have zero interest in deciding compensation or going to more meetings), it just truly is a position that is the closest to fungible. Everyone fear mongers about AI replacing engineers, but in the real world it could far more easily replace manager level resources.
I spent ten years in my 20s grinding to become great at engineering. I don’t regret it at all. And then when I did get those skills, many people in my life around me didn’t give a fuck, because I was leaving money on the table by not chasing status and management promotions.
It’s allowed me to get to a really good position at an advanced R&D company.
But I still hear the acclaim afforded to those who continue to ascend the ladder, and it stings a bit.
I suppose that is just people needing to believe in those things, and I should let it go.
It’s complicated.
I'd disagree...I think it can be difficult to see what the manager brings in when a team is good and runs well enough. It's a lot more obvious when you get a bad manager: the team stagnates, loses focus, valuable members will quit (there's the saying "employees don't quit their jobs, they quit their bosses"), recruiting also becomes harder.
There's too much to discuss in one comment, but managers that don't seem to be doing much while the team members are killing it are a precious breed and worth their weight in gold. An alternative way to look at it: they don't need to brag about being important, and have at least enough grasp of what their team does to not be standing in the way.
If they increased their product KPI by 150% but their manager had the goal at 200%, your team's suddenly underperforming. If they need 2 more engineers to fill specific spots, the manager will be the one pitching it to HR and convincing upper management to green light the expense. Same for the team budget in general, same for company-wise deadlines, resource allocations, what growth opportunity the memebers get. And so on, and so on.
There's a myriad of super critical things that members take for granted but go through their mamager and get screwed when the manager is bad at its job.
Junior engineers should be able to drive smaller, well scoped projects.
Senior+ engineers should be expected to tackle complex, cross-org, ill-defined technical challenges, examples include technical mergers of company acquisitions, large scale migrations of business critical systems, technical design of big bets (also analysis on which big bets to take), evaluate new technologies/platforms, dev tooling to multiply productivity, etc
A lot of this requires buy-in and stakeholder management to succeed.
- Alignment / priority management / keeping team focused
- Saying yes/no to projects
- Medium term planning, resource balancing
- Helping to set team vision and mission
- Reporting to upper management (up)
- Keep up to date and abreast with what’s happening in the org, filtering info to the team (down)
- People management (career, performance, strengths/weaknesses etc)
- Spotting and creating opportunities for the team
- Often acting as a tie breaker for decisions (including technical)
- Often involved in steering technical design and solutions
- Help keep the team productive and happy
- Probably a ton more I’m forgetting
Tons of finesse and strong communication skills required for this as well as strong technical experience.
And then there’s project management which I haven’t touched on — either can be done directly by engineers (personally I enjoy it, some don’t which is fine), engineering managers or dedicated technical project/program managers.
>- Saying yes/no to projects
>- Medium term planning, resource balancing
>- Helping to set team vision and mission
>- Keep up to date and abreast with what’s happening in the org, filtering info to the team (down)
>- Often acting as a tie breaker for decisions (including technical)
>- Often involved in steering technical design and solutions
I think it should be done by senior engineers organically as engineering is a social activity. No one person can achieve greatness and to me an engineer becomes a senior engineer not by being a brilliant coder (for example) but by understanding that the job is to solve problems.
These are my rough notes on project management (from an engineer’s lens):
https://docs.google.com/document/d/1XFdBUfi3MvQuh9NTFBJMQFA0...
Lots of blanks to fill still, but I am a proponent of engineers owning their own project management.
> I think it should be done by senior engineers organically as engineering is a social activity. No one person can achieve greatness and to me an engineer becomes a senior engineer not by being a brilliant coder (for example) but by understanding that the job is to solve problems.
100% agree, lots of overlap between responsibilities and often a good thing! Roles from all parts of the org coming together to solve problems is the ideal situation.
My first approximation is that engineering managers are responsible for the team health, whereas engineers are responsible for project health, or at least raising issues when things aren’t so healthy.
That's rare. In most companies managers aren't engineers, don't understand the craft and are picked by their buddies. They also have completely different incentives which allows them to throw engineers who spent ages to master the craft under the bus without any regards/regrets.
So much damage is done by the wrong people being constantly rewarded and promoted for creating noise by "leading" large pointless projects instead of doing the real work. Sometimes I've seen the new hire engineer solving the critical issues like problems in a data pipeline by collaborating across teams is actually having more impact that any of the senior engineers or management bsers.
On some it might be an architect level engineer who also manages the team. In others it'll be nothing more than a middle manager that only will see code on their spare time. And it can be everything in between.
So depending on the kind of move it will not have anything to do with engineering and everything to do with managing. And that's HARD. Changing your whole set of skills for another overnight it's not pleasant.
Principal engineer at FAANG (L8): likely one of the best engineers in the world.
Engineering director at FAANG (L8): manager who's been there for a while and is good at acquiring more reports.
As a ratio, there are far more eng directors to managers than principal engineers to engineers.
All that said, know what you want in your career. If you love building, build. If you want money, do management.
So if you start with a population of 100,000 employees at entry level, after a few years "most" of them will end up as L7?
That does not make any sense. Senior is the terminal band for "most".
Is this the "if you type randomly type stuff you'll write Shakespeare given enough time" thing?
It might be true (though I doubt it), but the original claim is "by mid 40s". You also need to look at the overall statistics (i.e. percentage of people who made the promotion vs those who haven't), and while the projected ratio based on the previous company growth rates may still support the claim, it's quite clear double digit percentage growth YoY isn't infinitely sustainable...
However... This is starting to change. We now have engineers reporting to higher levels, so basically each manager has an equivalent IC reporting directly to them. In theory this means the numbers are more equivalent.
During calibration the ladder generally isn't consulted but it could be weaponized at any time. It is quite intimidating.
High level ICs have LOTs of weights on the technical directions. They are not replaceable by the managers.
The other thing to watch out for is manager growth over the last 10-15 years was a result of the structural needs of an unprecedented tech bull run. Now that the industry has moved into belt-tightening mode, the heaviest scrutiny is falling on managers. The type of political games a typical 35 year-old EM (5 years coding, 10 years EM) may not be as effective as they were in the previous environment. There are a LOT of EMs getting pipped or knocked back to IC these days, whereas ICs with a bit of product/UX sense, ability to think a bit beyond their silo, and willing to work on "boring" business applications will continue to be highly valued, especially given the amount of dead weight that has found its way in by grinding leetcode.
https://www.youtube.com/watch?v=Ff4fRgnuFgQ&t=6585s
<quote> [From 1:49:53] Um, you know, at the beginning of this, we, um, I asked our, our people team, what was the average number of reports that a manager had? And I think it was, it was around three, maybe three to four, but closer to three. I was like, wow, like a manager can, you know, best practices that person can, can manage, you know, seven or eight people. Um, but there was a reason why it was closer to three. It was because we were growing so quickly, right? And when you're hiring so many people so quickly, then that means that you need managers who have capacity to onboard new people. Um, and also if you have a new manager, you may not want to have them have seven direct reports immediately because you want them to ramp up. But the thing is going forward, I don't want us to actually hire that many people that quickly, right? So I actually think we'll just do better work if we have more constraints and we're, um, you know, leaner as an organization. So in a world where we're not adding so many people as quickly, is it as valuable to have a lot of managers who have extra capacity waiting for new people? No, right? So, um, so now we can, we could sort of defragment the organization and get to a place where the average is closer to that seven or eight.
If you make it to my comment, please - do not go into management for the money. If you want to build, then remain an IC. If you want to grow other engineers, further THEIR career, make THEM better - go into management.
The friends of mine who ended up in management for the money and complain about their reports make me so angry.
Please won’t do much, even if I agree. Incentives and all that.
Plenty of people I know do it for other reasons: power, control, purpose, leverage, …
I’ve had too many shitty managers in my career to think I’d put other people through similar experiences. So, my switch into management was motivated by, hopefully, making the experiences on my team positive ones
And sometimes, the people who were asked, due to a combination of stubbornness and a desire not to “sell out”, deny the request for 7-8 years. Eventually, a person might realize that the original requesters may have been correct and that’s how they become a manager.
Or so I’ve heard.
A lot of engineers, of all flavors, are at least partially in the field for the money. Maybe they enjoy their work, maybe they're good at it, but for a lot of people it was more of a plan C or D after the things they really wanted to do turned out to be something they couldn't make money at.
Some of them would rather be authors or musicians, some of them chemists or physicists, a number of them are just waiting to buy a goat farm upstate. If you include them people who would rather be engineering something else, but that something else doesn't pay the bills, it may be a majority of engineers who are in it for the money.
No, it is not. You switch from L6 IC to L1 M (FB/Google scale). Compensation remains exactly the same.
> If not immediately, the cap for ICs is much lower.
This is different from management being a promotion...
While you can absolutely be a manager without extensive IC experience, most people will benefit greatly from having deep IC experience before becoming a manager.
That's a very linear outlook. One can also grow be expanding the base of skills one has, and that often comes by shifted to adjacent jobs where you can capitalize on your first skill. There's some benefit in engineers who want to grow by transitioning to manager: nobody wants a non-engineer as your manager/leader - how would they understand your work or attract fantastic talent?
Now, don't get me wrong: I'm not saying for an engineer to grow one has to become a manager, but it is a legitimate strategy.
It is a difficult balance.
It’s growing - hell it’s escaping Getting as far away from working constantly for no reward and more goddam leatcode Interviews where 25yo who know nothing gatekeep your career - maybe you live in a different reality than I do, but I can always just build for myself at home.
But then, here's the reality: any large company will have a new for an army of directors and VPs, compared to only a handful of ultra-senior, visionary engineers. Take Google and compare the ratio of Jeff Dean-type folks to senior managerial staff collecting similar paychecks.
So yeah, if your goal is to retire early without depending too much on luck or on being exceptional, management is your career growth path. For better or worse.
I do however find it extremely motivating to help a true leader solve their problems in a self-organising team of collaborative peers.
I can’t fathom why so many software organisations are still structured for hierarchical command and control, with the trend of good engineers being ‘promoted’ to management?
Yes I think we need more leadership: with organisations cultivating a culture of leadership, communication, openness and trust. Everyone can display leadership skills depending on the context/task within a team. It is not something reserved for the ‘manager’ (appointed leader).
Do we really need more ‘management’? I don’t think so. Management != Leadership.
Would be keen to see some more articles along the lines of ‘Growing leadership skills for engineers’.
I'm told Seeing Like a State shares this insight.
I also hate it. But it's unfortunately "left as exercise for the reader" to come up with an alternative that concentrates power differently.
At current workplace trying to subtly suggest/introduce that there’s an alternative way…
I don't think you can make an existing company change it's stripes; you can only start a new one that believes in collective power and try to find a way to make that stick.
Maybe B Corps help? At least you can prioritize something other than maximizing shareholder value. But even then, I'm not sure how you deal with bad actors without some degree of strong power.
The professional managerial class have completely taken over most tech companies now. 'Technologists' trading buzz words, peddling 'influence' and crowding out the people that actually build things.
Red flag == ‘Talent Acquisition Manager’ messages on LinkedIn.
In the corporate world it’s all about hiring/firing versus the military where it’s all about developing people and liability at all levels. The key consequence of that is that in the corporate world people are eager to play it safe and follow trends versus the military where its generally considered a safe environment for learning more tolerant of controlled failure. Tolerance of controlled failure is how I learned to become a developer while working at Travelocity a billion years ago and I have not seen that since (in the corporate world).
Good formations exists, somewhere. But they’re well hidden.
If you bring down the production system with a change that is a learning opportunity and your team should be supportive (i.e. help you recover it) when these things occur. Thats why its important to be constantly deploying code and knowing how to roll back, etc.
I’ve worked at a company that did releases months apart and everything was supposed to be perfect, it never was. In that culture it was all about posturing, covering up mistakes and blame-game which is utterly frustrating to work in.
The manager is supposed to shepherd career growth and decide how much people should get paid. In my view this is a really part time job at best.
I think we need to go back to coupling more of these roles together, similar to what would happen in a startup. A strong leader should be able to fill product, tech lead and management roles.
But demote them to smaller projects when they fail to deliver. And allow team members to apply to work for a different team if they trust the team ceo there more. Like an internal startup environment but teams. This is how I would try relentlessly to structure my company.
Managing down tends to be the easy part, career planning, 1:1’s, performance/development and running rituals is a cake walk. The only real hard part of managing down is when you have an employee that’s poisoning the well or is on a PIP.
Oh, and some managers also have to still pick up cards and push code in some orgs.
Most posts here are from those who have never walked in a manager's shoes so only know what they see (or hear/read).
Think about it, minus a few exceptions, most managers are paid better than the engineers they manage. Now why would exec/sr mgmt. do pay more unless they are getting their money's value?
Either the person quits.
Or the person resigns to giving mediocre output and coasts.
Neither is good for the business and yet people keep pushing workers (not even just in tech) into that position to the point it's now a cliché.
This obviously varies from role to role but I was told I would be highly involved in deciding what the team does and how they go about it. The reality is that I am responsible for arbitrating the delivery of decisions from more senior managers to the teams and the decisions from the teams on how they execute on those decisions back to the managers.
Facilitating the growth of other engineers is wonderful but, frankly, I can do that (and was doing that) as an IC.
If I'm honest I don't think the exact role I want exists out there but I think I'll make a far better "lieutenant" to a manager who actually likes the job than I make a manager who is becoming increasingly unengaged with their own role.
"What would you say... you do here?"
I was recently promoted from Principal Engineer to Director of Technology in $JOB, and the difference has been striking, mostly in the ability to influence things so we can build the right technology before we start. That feels like a much more natural step for an engineer than throwing away their entire skillset and moving them to a position that requires an entirely different one.
If you want to grow your engineers, give them more (and higher-level, higher-impact technical stuff to do. If they want to become managers, great, but there's not as much overlap between engineering and engineering management as most people seem to think.
A coworker and friend is both an engineer and a manager, and he happens to be great at both of those. Instead of losing one of the skillsets, he has a role where he both manages his team and sets the technical direction for them. This means he manages a much smaller team than he would otherwise, but he loves doing both, so this a natural fit for him.
All this is to say, build your roles according to your people, don't shoehorn them into labels that other companies have told you is "how to do things".
"Dear Engineer, you are so good at your job we've decided to have you stop doing it and do a different job with an almost completely disjoint skill set. You get to do something that you will most likely hate and be bad at. Plus you can never go back to your old life."
It's even better if as you say the success is determined by the team, because then also the failure can be pushed on the team.
Edit: FWIW not that I want to be a bad manager. The environment is what shapes your incentives and behaviours.
The thing being managed is the performance of the team. Bad performance == Bad management.
In fact, you are more likely to work longer hours, and attend meetings at stupid times because that's the only slot you can get the more senior managers to meet at.
However, you sound disillusioned with your work, and maybe you do need to transition into something else. A new challenge can revitalise you, and it doesn't have to be forever.
I've met plenty of engineers who seem to believe that everyone else's non technical role is easy. Keep an open mind, and don't approach new opportunities with a negative attitude, or you will probably remain discontented.
Not easy. But it's the difference between being the one who is approving and the one who is doing the work.
The one who has some autonomy and the one who doesn't. The one who is valued and the one who isn't.
Having to attend OOH meeting is less stress for me, then having to build something OOH and make it work. One requires communication, politics, the other one actual tangible deliverables.
> you sound disillusioned with your work
yes, you're right.
In my experience it’s like that (I’m talking about engineers vs eng. managers). Another significant difference is the amount of work, I believe: as an engineer I work 4h/day but those 4h are “hard” hours (fully focused) and my brain ends up a bit exhausted after. But that’s all I do in the day for work. On the other hand, eng. managers do more lightweight work, but work longer hours.
I have to say that in my experience, what my eng. managers were doing all day was: 1:1s, meetings with other managers to decide how to shift around people, interviews, being present at some sprint plannings without saying much, being present at some daily meetings without saying much.
Obviously, it depends on the organisation you work at.
For engineers it’s different: we have complete control regarding when to work, and we don’t have as many meetings as eng. managers have. So there’s more freedom in my opinion.
I think it’s not very realistic for a manager to say: I’ll work extra today so tomorrow I’ll work only 1h (because you probably have meetings to attend that you cannot postpone). As engineer, I work whenever I want and rest whenever I need it (as long as I meet deadlines and the like)
Of course I won’t actually know until I am one myself, but it certainly feels doable if I’m willing to sort of trust my team.
If you do become one and find you can control your schedule, please write it up and share!
However, there are so many parameters affecting this result that I wouldn't dare to make a call on which role is more tiring in general at a regular company.
- I'm less experienced as a manager, I have to continuously learn a lot and grow fast.
- This is in a young start-up context.
- This is with a very broad scope of responsibilities.
- I'm me.
- etc.
YMMV
The largest fatigue factor to me seems the amount of context switch I have to do as a manager.
Unless you work with someone internationally and the only time both teams are awake is at ungodly hours for both, so you never get any meetings at normal times.
Neither is 100%, but if you try to push failure 100% onto the team, you’re going to have a really bad time personally and be rightly reviled as a weak leader by your team, your peers, and your senior leaders.
not in my experience tbh.
i worked 16 years as an Engineer across 6 orgs including Fang. What I saw is that the closer you are to management the more valued and rewarded you are.
Simply because you are doing the management's dirty work (your influence is direct) and you have more insight into finances, so it's more difficult for them to underpay you.
Credit very rarely flows down and when it does, in very generalistic way "thanks to X and Y and also the team for their efforts".
On the other hand, even though eng. managers mostly do meetings, their calendars are usually packed with them. Even worse, they may have one meeting at 8am, another at 12, and another at 4pm… that kills your day completely since you have to stay available during the whole day. Definitely something I would hate.
But if it a project without intrinsic motivation or large and clearly present business value (like fixing an incident or saving a $10M client contract but not some hopeful!thing that might pay off in two years), then I keep my weekends to maintain myself as a human being (which ironically also happens to benefit the company on that two year time scale).
There is something supremely disgusting in being forced to work on projects ("hey client X needs this Y thing done asap") that you don't care about, know they have a close to zero chance of working to an acceptable degree and also know you'll be blamed for their failure. Over and over and over.
1. You’re wrong and you’ll find yourself working more 2. You’re right and you are screwing over your team.
You must have some very good managers who make their work seem effortless. Perhaps get them to be a mentor when you make the shift so when reality strikes you won't have to deal with it by yourself.
Just stop this nonsense.
Understanding the meta problem is not the same as understanding the problem and vice-versa.
Michael Jordan's supervisor is not Michael Jordan. They're people with valuable, non trivial skills that take time and effort to cultivate, but people don't buy tickets to go see a manager, just like customers don't buy manager deliverables, they buy individual contributor deliverables.
The customer doesn't buy issue tracker tickets, or speeches, or gantt charts, or burndown charts, or diagrams, or whatever manager deliverable of your choosing. They buy working software that is stable, performant and that has an ergonomic and polished interface. The manager's job is to facilitate an environment where that can happen. They are not the neurons of the team, they're more like the glia of the team.
That is, if you build a team consisting solely of managers and ask them to solve a problem, and designate one of them as the manager, they won't be an effective team. Did they really "grow"? Or they pursued a different track?
Software engineering is a team sport in that same regard. If we're lucky we have a MJ on the team but still needs to be managed for their own (and the team's) good.
I know engineering manager can be loads of work. I wouldn't want to do the job my engineering manager is currently doing. I would probably die of boredom in meetings or completely fail, as my brain shuts off during the meetings or something. I want to build things. With code. That does not make me any less of a senior.
I wish these different organizational choices would be more widely known. My current employer nowadays has these non-management career tracks, but I'm not sure if we communicate them clearly as one of the reasons to join the company.
A major accounting firm may have some senior engineers, marketers, etc. but since their work isn’t “core” to the business, the top tiers of the technology and marketing tracks will tend to be exclusively management roles — whereas accountants will be allowed to… account… up to a much higher seniority level before they get forced into management.
The most common reason I see people become managers is because they weren't cut out for engineering work or it burnt them out over time. Many couldn't keep up with the ocean of new technologies and philosophies software has gained in the last few decades and so they are relegated to being a machine that checks email for twice a starting engineers salary.
Some managers really have done so to steward a company or team through a problem but so many more of them just want to "check out" essentially and in just a few short years loose most of the engineering context value they had and become some degree of roadblock to progress because sadly they want their cake and they want to engineer it too...they often create tasks and conversations they don't make sense or deliverables that are missing the point because they are no longer engineers no matter how badly they still want to identify as one after leaving a organic growing codebase.
I get it they have families and they are getting older and the kids coming out of college are honestly intimidating sometimes but that's a problem with the absolute lack of upward mobility within engineering and they unhealthy standards of modern corporate culture.
It's sad really. Very intelligent opinionated people slowly go from talking about solutions in concrete terms to a mix of language about deliverables, burn charts, agile, circling wagons, getting on the same page, and determining a funnel for Q4 while the software they are talking about has no unit tests and they themselves have determined that it's not part of the MVP...
If they could go back 10 years and hear themselves I wonder what they would think of the people they've become...
There's nothing wrong with being good at your job and not wanting to change your role. But it's obvious that in most situations, progressing to other roles is necessary if you want to have more influence and control over your product - and usually higher compensation as well. In a professional kitchen, obviously the person actually cooking has to be really good. That doesn't mean this person gets to choose the menu of the restaurant, and their name also won't be displayed outside. They are more easily replaceable than a chef, even if they are very competent technically. As most things in life, it's all about trade-offs, I just think that ignoring what the actual pros and cons are will lead you to bad decisions down the line.
As an engineer it's easy to practice many new skills and also to see improvement. I might be interested in orchestration, I pick up Kubernetes course. I want to build iOS app, I start learning Swift. After a month or two I can see a difference in my skills. Others can see it too - I contributed to iOS app at work which I haven't done before, it's a new skill I learned.
As a manager, I need to be better at negotiating with stakeholders, or recognizing underperformance, or interviewing candidates. I can read books, take courses, but I can only see my improvement over longer period of time. What's more, most of people around me won't see that I'm a better interviewer now, or that I'm better at helping to improve individual performance. It doesn't mean I stopped growing, it doesn't mean I don't cultivate new skills. They're just different skills.
Of course you grow as a manager. But you're right you're not growing as a technical expert - that's not the goal of managing. Managing becomes more about the business and less about the technical details.
It's a very different job and an important one if you know anything about running a larger company. The technical work you do as a IC is one part of many that drives the business forward.
We need real engineer.
I'm not going to say it's better than this, but let's just say it's different.
I usually see managers as being far less competent (in general) or valuable than engineers and leaders.
Maybe get a job as a manager, manage a few software engineers for a couple years and then see if your original (bold) statement holds true.
Since we are talking about it though, let's apply the 5 whys: 1. Why do companies need managers? Because they need they're employees to be managed 2. Why do companies need their employees to be managed? Because they are not certain that they will follow the company's short/long-term strategy and vision 3. Why are they not certain? Because they're having trust issues 4. Why are they having trust issues? Because they are not investing in proper hiring 5. Why are they not investing in proper hiring? Because it's expensive and requires tremendous multidisciplinary skills, time and effort
We are dealing with one night stands masked as serious dates ladies and gentlemen. Managers are just pawns which patch the original issue. Solving hiring would make them redundant.
Focus on writing down your thoughts and supporting them. Build a case for something and then make decisions and execute. If you can put together a cogent argument, even people who disagree can often stomach working hard on it as long as you acknowledge their criticism and occasionally reevaluate past decisions.