Having worked at a lot of companies, I think this advice is hit-or-miss.
I'd say as often as not, a good engineer is more knowledgeable than their manager in most respects, including the people dynamics. Ask your manager for help is often the nuclear option, because there's such a wide-range of outcomes when a manager tries to intervene -- maybe they misunderstand your message, maybe they fumble the delivery, maybe they forgot, etc. Even if the manager does intervene it could be neutral or negative "Hey I got you some 'resources' who know nothing about the project that's due this month to help out." Miscommunication is particularly common when there's a language and culture barrier at play.
Also, what? IIRC most engineering teams miss most goals most of the time. I guess if it's agreed in advance something is a "hard commitment" then yes let the manager know early you're not going to make it happen. But also the manager should be even more responsible and should be asking for periodic updates on all goals if not receiving them.
Also there's something really offputting about the "get it done" phrase/mentality for public companies. Delivering faster is not one of Meta's (or google's) top 50 priorities. Their priorities all need to be "This time, build a product that's going to be around in 10 years that will reflect well on our brand." Hustling is not only not a part of that equation, constantly feeling "under the gun" is antithetical to the kind of "Let's take a step back and do it right, even if it's twice as expensive and takes twice as long" approach they need.
"Also there's something really offputting about the 'get it done' phrase/mentality for public companies." This really resonates with me. I work at a larger company and sometimes get pressure to finish work faster. I don't know why I should, what I'm working on is clearly not critical to the company. At lot of this "work faster" is just there to meet arbitrary and questionable scrum practices. The only thing the manager cares is that I got x mount of story points done this sprint.
I don't know why I should, what I'm working on is
clearly not critical to the company.
Isn't it better to get more done than less (at the same amount of time), even if it's not critical? The only case where it's puzzling is if you're left twiddling your thumbs after you're done, rather than get more work.
Exactly, working faster just gets you more work, and if you're lucky maybe the bosses will throw in an extra 2-3% on top of your 2% raise at the end of the year. If you're really lucky, you might promoted. Now you're working 60 hours (50% more) for an extra 10-15% a year. Congratulations! Feel free to spend that extra money on a shiny new BMW to show everyone you've made it.
For whoever is doing the pressuring to work faster, supposedly the manager who is supposedly doing it for the benefit of the company.
I'm not saying this is better for the employee, but if you're asking "why are they pressuring me to work faster, my work is not critical" then the answer is "they still want to get as much out of you as they can, even when it's not critical".
I'm not advocating for anything, I guess the original phrasing of the question was ambiguous- I read it as "I don't know why my boss cares how fast I work if my work is not critical" and am answering that question.
But it can also be read as "why is it to my benefit to work as fast as I can?", which is apparently how you interpreted it.
I'm imagining a team of 10 with 3 dev, one "manager" and the other people being business related. Lacking resources would be something coming up naturally in every day conversations, whether a goal will tough to meet or not as well, and the manager's role also get a lot reduced as the political aspects are that more local and constrained.
"Get It Done" becomes a different beast once your manager is just one of the 4 layers separating you from the actual decision makers and their goal is just to become the bigger fish in the ocean.
IC -> mgmt transitions are a messy thing, and I've never personally experienced working at a startup where anyone had enough time to help the new manager get their bearings effectively. (I include myself in that group of people who made the IC->mgmt transition, and flailed.)
Good point. I kinda assume startups that have neither experienced managers/leaders nor self sustaining engineers gotta fail fast and we don't hear much about them.
I've mostly seen a mixed of both, with either senior staff supporting a youngish business team, or an experienced leader team pulling in youngish staff. The most intersting one was 4 old farts in the office next to us executing on their ideas like they'd play a jazz piece, there was clear tension, they were pretty loud, and the manager guy appeared more like riding a rodeo that playing the HR drone. But they looked crazy efficient.
I think bad management are people who got into management because it pays better, it is necessary for career advancement or social status. Those people do management because that is what they have to do to get their personal goal, money, promotions, fame.
Good managers are people who do it because they like it and they excel at it. Some might have started doing management for different reasons, but stayed because they discovered it to be their thing.
That is the reason for that bimodal distribution and why it looks as it does.
I think tons of jobs that pay very well, make you famous, etc. actually don't have a bell-curve-distribution for the same reasons.
I've found that that's mostly a fig leaf. It was the primary reason I left places. When I asked how to get the promotion and got that response, I got the promotion by moving to another company.
And of course I performed well in the new role, because it never was about performance. It was about people not expecting juniors to grow so quickly to medior, or about not having a free "promotion slot" this year, or it's just not a priority, or other organizational stuff.
For junior/mid level developers backwards-facing levelling doesn't really matter. For senior it matters more, and for staff/manager it matters a lot more.
There are usually organizational constraints like you mention, but that doesn't preclude there being a reason for backwards-facing levelling.
Junior to mid it doesn’t matter. A “senior” and above based on the leveling guidelines at every tech company that I’m aware of is not based on whether you “code well” or even how knowledgeable you are. It’s based on “scope” and “impact”.
As a medior, I've led a team of seniors on a mission critical project for several years, after which my manager said "maybe we should consider promoting you in another year or so".
And then it’s time to change jobs now that you can answer soft skill questions in STAR format that shows “scope” and “impact”.
But a new job is not going to give you a senior position if you haven’t already demonstrated it at your previous job.
Yes, I realize titles are meaningless outside of major tech companies with real leveling guidelines. I worked at your standard enterprise/Corp dev jobs all of my career until 2020.
Well, yes. That was my point. When companies say they want you to perform at the next level before promoting you, it's just something to say that's semi-friendly and still means no.
What I’m saying is that in either case, you have to perform at the next level to get the job.
A: Perform at the next level, go through the internal promo process and get promoted.
B: if you want to change jobs and get a job at the next level, you still have to work at the next level at your current job so you can convince your potential employer that you’re capable.
In other words, there is no way of getting promoted reliably without operating at that next level first.
I just added that in my experience A doesn't really exist. I have seen plenty of companies that pretend they have an A-policy, but none that actually do. Believing companies when they say you get a promotion when you perform at the next level is naive.
And even if it's true - which you shouldn't believe without proof - strategy B is still faster than following strategy A.
I’ve been doing this for a long time. 25 years between 6 companies you’ve never heard of and one former F10 non tech company. There were no formal leveling guidelines and I only got one raise that was more than 4% and that was in 2000. If I wanted a “raise” I had to switch jobs. I agree with you completely.
But now I do work at $BigTech. The promo process is real. People get promoted every quarter.
On the other hand, it is still easier to “boomerang” - get hired at the next level at a new company and then come back - than it is to get promoted at your current company.
Also because “salary compression and inversion” are real. Meaning, that getting promoted internally will still lead to lower compensation than someone coming in at your same level.
Taking the example from the OP, do you really think it would be better to slowly come to agreement over 12 meetings or to have some more senior person say a few words to skip the ego soothing or whatever in those meetings? Your second two paragraphs seem to imply that you think the former is better. Do you think that (and why)?
My best guesses are that I’m misunderstanding what you wrote, you’re thinking of a different example, or you’re imagining some hidden cost to the actions taken to ‘get it done’.
In my opinion the latter choice seems obviously better, both for the company that gets more productive employees, and for the people who would have been in those meetings because I think sitting in pointless meetings and having some task on the back burner for ages as you go through the meetings is not pleasant. Perhaps there’s some world where you’re expected to sit in the office for exactly N hours per day and so pointless meetings are a way to work fewer hours. But imo even if the choice is an hour of tedious meeting vs an hour of working, the work feels preferable to me.
> I think sitting in pointless meetings and having some task on the back burner for ages as you go through the meetings is not pleasant
What seems pointless to you is not pointless to the team you manage. What's important to you is often not seen that way by your team either. This is a really straightforward dysfunction to fix and it's always the manager's responsibility to do it.
> have some more senior person say a few words to skip the ego soothing
The best managers don't have this attitude. You're absolutely right that someone in charge of the project needs to moderate the meetings, but I'm curious if the "few words" are really constructive suggestions based on experience that speed up decision making, or just dumb whip cracking. If it's the latter, I wouldn't keep you on. If the team just needed to be reminded of deadlines, we would replace all managers with a clock on the wall.
I’m trying to describe the premise from the article rather than speaking generally, to better understand the opinion of the commenter whom I’m replying to. For the purposes of the question, I want to assume that the OP accurately describes the situation as one in which those meetings would be unnecessary. I perhaps did a poor job of representing that.
> Taking the example from the OP, do you really think it would be better to slowly come to agreement over 12 meetings or to have some more senior person say a few words to skip the ego soothing or whatever in those meetings?
I don’t understand what you mean. Did I do a bad job of representing the scenario in the original article? Those were the outcomes from the article as I understood it, where one is caused by ‘try to do it by yourself’ and the other by ‘get help’.
Sure, but I’m not asking about a situation where the choice is between right and fast. The choice I’m intermediated in is the one between ‘right and fast’ and ‘right and slow’. I wish that you would clearly write down what your actual opinion is instead of riddles. My actual opinion is that ‘right and fast’ is obviously better than ‘right and slow’ (with other things like hours worked kept equal). It seemed to me that the GP’s comment was implying something close to the opposite and I was curious for more details.
The problem is when it takes x10 longer is x10 more expensive and sucks. The trick is to align both the short term and the long term.
Deliver that short term faster, and deliver it in a form that aligns and/or informs the long term.
I was curious about the history of the iPod so was reading up on it. Apple took 8 months from zero to announcement and the product was available one month later. That was Nov 2001. The iPod touch still sells today. There's lots of details under that but you don't really see that kind of execution any more IMO.
The iPod really wasn't a technically complex product though - no more so then anything else at the time. The original iPod was "just" a hard drive with an LCD on it.
The big innovation was the wheel interface, and the quality of the plastic packaging/housing. Apple's big value proposition was realizing they could put premium-looking styling on a product and that would then justify the price point to add capability - at the time the whole point of the iPod was "it's got enormous storage". It literally was just a laptop HDD in a housing though.
Which is to say: Apple's timeline for that is a pretty standard consumer product timeline. If they'd taken much longer then that you'd have to wonder what they were wasting their time on.
EDIT: Like it's worth considering that Apple probably owes a lot of it's success to the specific finish and chemical formulation of the plastic they use, more then any specific technical merits of a lot of their products - building a plastic gadget that felt as good as an iPod did was a heck of an achievement, just not in the area people think.
I wouldn't trivialize the iPod effort. Zero to a finished, manufacturable, product. There's software. There was coordination with a bunch of external vendors. And, sure as you say aspects of design and materials.
I've seen many software projects of smaller scope that get stuck or lose direction.
>"is for people to more directly leverage their leaders."
I just couldn't parse this until I read the rest of the article. I think that the author is saying "Ask for help from your boss when you are stuck."
This is good advice, if you are personally empowered. If you can afford for your boss to go batshit crazy and crap on everything and everyone including you - then just go for it. If you can't afford for that to happen then you need to exercise this advice with caution. When you are in a really bad spot then the first thing you need to do is work up an escape plan - then you can go to your boss.
As an example, if you are debt free and have a good credit history go and get a credit card and get a high limit. Then if you are fired you will have some funds to work with. It's not ideal, but if you are fired you won't have the card and you may find things much more difficult. A better escape plan is to be a fair way along in the hiring process somewhere else.
I think you're thinking of career-ending fuckups (where you definitely should try all avenues, quickly, including asking trusted peers for help), rather than the article's more mundane examples of being blocked, having prioritization issues with another team, feeling overwhelmed, etc. If you can't talk to your manager about that kind of thing and expect some help (or at least some advice/sympathy), then agree with your point that it's time to look for another gig. That's no way to live...
> If you can't talk to your manager about that kind of thing and expect some help (or at least some advice/sympathy),
Perhaps I'm imagining it, but I believe this always has a side effect of incrementing a little counter in manager's head - one labeled "oh, they're failing to deliver again". The first few times around you might get sympathy, but then you'll start seeing irritation, and few rounds later you'll find yourself on a Performance Improvement Plan.
If you're constantly failing to deliver at the same rate and level as your co-workers, yes it is going to increment a counter.
If you're delivering work though, and keeping management aware of blockers that need to be resolved, then no it wouldn't. I've seen more co-workers wind up on management's bad side because they were afraid to say when something was going sideways than ones that asked for resources or help resolving a problem. Turns out management hates it when they think something is on track and then 2 days before the estimated due date they find out "we're 6 months behind" a lot more than they hate hearing "we need some resources to resolve X Y and Z or we will need an extra 6 months"
They generally can tell who is failing to deliver because they are constantly stuck on trivial things and who genuinely can’t do more and need help. If you go see your manager because the team next door is blocking you explaining clearly what you have tried and why you need the issue to be escalated you just sound professional. Same thing if you can tell you are going to be late in your delivery and need something specific done to help especially if you do it with a lot of time left.
Also I have a pro-tip. Managers intentionally ask people they view as competent and trustworthy to do the thorny things that need to get done. So surprisingly the people who are expected to need the most help are often the most valued.
Really this is senior leaders, not managers. In fact my line managers have (with very few exceptions) been great people.
Proper, proper senior leaders - folks who run the 80k FTE companies worth $40bn or more... well those are a different breed. There is a lot at stake, they are like wild animals in that their motivations are not available to you and they can act in very unpredictable ways.
I have seen rooms full of people emptied out of a business over a three month period due to an ill judged meeting that went badly. Could have been avoided... wasn't...
If someone is wondering what gaslighting looks like, this post is it.
If you, a "leader", are asking people to "get it done" but you simultaneously keep roadblocks in place or cannot remove them, YOU need to get things done before asking others.
E.g. if a manager asks you to finish something by the end of the week, but the devs don't have a reasonable development environment to test things out, it is up to the manager (and the layers of "leaders") who need to figure out how to clear the roadblock. There is no point pushing more on reports when you yourself cannot "get it done".
If no one bucks up and tells management that the dev environment is a blocker in the first place, how do they know? I've seen way too many co-workers sit and stew in silence about problems that get solved as soon as they start speaking up, or at the very least start getting factored into estimates once someone starts saying "hey this sucks and adds 3 days to every week of work". Maybe it never gets fixed because "reasons" but it at least stops being an "unseen" problem.
I worked on a team that used a free tool as part of the dev process that was just a continual source of problems for about half the team, with no obvious reasons why. Every 4th or 5th launch of the tool would just fail, and you'd lose half a day to trying to resolve the problem or otherwise clear all the settings / caches / accounts and start from scratch. Yet the team had worked like that for a handful of years because "it's just one of those things". It took 2 days after bringing it up to management to get the whole team paid licenses to an alternative tool. No one had bothered to bring it up because no one thought management would pay for a tool when a free one worked. But a half a day lost to a tool failure cost the company an order of magnitude more than just buying licenses to a better tool.
I have found that a lot of engineers learn helplessness because they've been burned by reporting issues to bad managers. Bad managers only shift the blame downwards. Why would any sane engineer ever report anything if there is a chance it will be held against them?
Because those bad managers are going to shift the blame downwards regardless and the people around you also see what you do. If you need to add CYA cc's to emails about blockers or bring things up publicly where it will be clear that you were upfront about the issues facing the project. Ultimately bad managers are temporary problems, but a reputation as an unreliable person is permanent.
Oh boy, you must be a decent manager. In my most recent experience, engineers who brought up issues publicly were berated, rated lower and then managed out. Why? Because the goal of the bad manager is only to "look good" for "long enough".
If the company culture is bad enough that you get pushed out like this, almost certainly your good co-workers are or will also be pushed out the same way. Those are the people I'm referring to when I say others will see what you do. They're the ones that make up the network that gets you a better position out from such a dysfunctional organization.
I've left such dysfunctional situations before, and the network of co-workers and other managers I built up in those situations by being reliable and communicating were key in finding multiple subsequent positions. In another case, a skip level manager who I'd probably met in person 2 or 3 times tapped me for transfer to another team out from under a lousy manager in part because of an earned reputation for being honest about what was feasible and then getting that done.
Like I said, bad managers are a temporary problem. Either they're gone or you're gone. But your reputation is what you trade on when you call on your network to help make that problem as temporary as possible.
This is exactly right. I used to think that execs were like “Super ICs” who knew everything under them. As I’ve moved up in my career I’ve been amazed to find that execs do not know all the details of what’s happening or where the problems are. They are human just like the rest of us, and someone else’s problem is not obvious. They need to be told in a meeting or in writing so they can help fix it.
> the mandate of such a job is not to “do the best you can.” It is to get it done. And if the way to get it done is to ask for help, then that’s what you should do.
In my limited experience in large companies I’ve often felt that the mandate for leadership is to position yourself for promotion (or better yet, a nice exit to a consulting firm).
The job is more an annoying distraction from feathering your nest, and this bodes poorly for the sucker who asks for help.
2) they often don't reflect the reality of those in the field in his own back garden.
In boot camp, I was expressly told that I shouldn't message people for help. Some smug ponytailed twat stood up and said "If I'm messaging you, I can't spend that time improving the system" The reason why he was getting messaged so much is because the code he wrote was "clever" old and entirely uncommented. The wiki was out of date.
Yet, he didn't take it as a signal that his docs/onboarding experience was shite.
So to him, this post basically says: make more code.
To compound the issue, if you're an intern or a junior, you are penalised for asking too many questions. This is at odds with the core message.
I agree with most of what you say. But uncommented code isn't necessarily a bad thing. You can often make it self documenting through long and descriptive variables names and function names.
I just want to use a "message queue"(or what ever), the one I'm trying to use has the semantics I need for a project. I just want to use it, not learn to maintain it. I don't want to have to spend weeks reverse engineering the tests to figure out how to make it work, I just want to build with it.
But, how do I know which Queue system to use? does it have the right semantics? what happens when you fill the queue, does it pause the producer or emit an exception? who knows, just look at the code! (this makes selection of systems really hard, unless you have the sacred knowledge)
And thats the problem. Meta might have the world's best scaling primitives, but unless you can find the right person to ask, you'll never really be able to figure out _how_ to use it in your project in any reasonable timeframe
This article presupposes a healthy and functioning company. Leaders are more often than not blind to the realities of the company as they have control and feel they’re doing a great job.
A useful analogy is reading self-help books about communication while having a toxic family environment. Sure the advice is good but some of us know how useless it is if the environment is not right.
This is great advice, but getting to a place where this works doesn’t always happen.
There’s a natural incentive to not need help. The more help you need to get things done the less valuable you are.
Conversely, great leaders are giving tasks that challenge people and can often include complexity beyond someone’s ability.
As a general rule, leaders expect people to:
- make a good effort (~90%) to solve problems (don’t kill yourself or your team)
- understand the solution space when problems don’t yield
- escalate with options for moving forward (the more fleshed out the better)
- clear communication around important changes
I worked at a startup at my last company where the CTO would give me “special assignments” to come up with proof of concepts that wouldn’t require him to go through the “process” - product managers, sales, project managers, etc.
I wasn’t expected to know everything. I was expected to pull in the right people.
Now that I work at BigTech, why would I struggle trying to figure out how something works on one of the hundreds of cloud products for more than a $Timeboxxed period of time when I literally can reach out to the team who wrote the service?
This advice feels a bit ironic, given that Meta almost entirely lacks centralised command-and-control. There would be way less need to push problems up the chain of command if the chain of command actually made decisions in the first place, rather than delegating them to the trenches (where no one is empowered to make decisions without escalating, thus starting the cycle over again...)
I think this applies to his boss more than anyone else. Zuck just did not get it done. He picked a fight with apple, spent billions acquiring occulus and none of this actually got Meta to be anywhere close to where apple is today in that space and how meta is losing ad revenue because Zuck failed to bend the knee. I just can’t believe that billionaires egos are so fragile and it has to come in the way of building profitable and successful companies.
Oof that hits home. This is something I always struggle with. My personality seems to fight me every time I need to go up the chain and deliver bad news.
You can also get help from other people in the team/org if the blocker is technical. If it is organizational then talking to your direct boss first of course a good idea.
I'd say as often as not, a good engineer is more knowledgeable than their manager in most respects, including the people dynamics. Ask your manager for help is often the nuclear option, because there's such a wide-range of outcomes when a manager tries to intervene -- maybe they misunderstand your message, maybe they fumble the delivery, maybe they forgot, etc. Even if the manager does intervene it could be neutral or negative "Hey I got you some 'resources' who know nothing about the project that's due this month to help out." Miscommunication is particularly common when there's a language and culture barrier at play.
Also, what? IIRC most engineering teams miss most goals most of the time. I guess if it's agreed in advance something is a "hard commitment" then yes let the manager know early you're not going to make it happen. But also the manager should be even more responsible and should be asking for periodic updates on all goals if not receiving them.
Also there's something really offputting about the "get it done" phrase/mentality for public companies. Delivering faster is not one of Meta's (or google's) top 50 priorities. Their priorities all need to be "This time, build a product that's going to be around in 10 years that will reflect well on our brand." Hustling is not only not a part of that equation, constantly feeling "under the gun" is antithetical to the kind of "Let's take a step back and do it right, even if it's twice as expensive and takes twice as long" approach they need.