Get It Done
boz.com
boz.com
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.
Which is why shit, unmaintainable code often goes unpunished
I don't know why I should, what I'm working on is
clearly not critical to the company.
You’re advocating for finishing work faster so that you can be given more work faster? Sound like something to pitch to owners, not salaried workers
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'd say that in many startups, MOST managers are not good at their jobs, as they are freshly promoted ICs who have to figure out a new role.
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.)
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'd suspect it's bimodal, and the "bad" peak is much higher than the good one.
Ay least, that's how my own experience maps.
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.
People just take what opportunities they can get or they choose to study some field hoping that they like it.
And often, a few years in, they learn that they hate their job.
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.
There are usually organizational constraints like you mention, but that doesn't preclude there being a reason for backwards-facing levelling.
It's not scope and impact either.
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.
Believe the no, don't believe the reason.
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.
And even if it's true - which you shouldn't believe without proof - strategy B is still faster than following strategy A.
Only strategy B is reliable.
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.
https://a16z.com/2011/03/31/whats-the-most-difficult-ceo-ski...
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.
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.
That's not the opposite though.
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 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've seen many software projects of smaller scope that get stuck or lose direction.
This sounds like a you problem. Maybe your communication skills are lacking?
> 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."
Lol I couldn't disagree more. I believe this sort of mindset leads to analysis paralysis.
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.
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 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.
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 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".
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'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.
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.
It’s possible that I’ve become overly cynical.
If it blows up and you fix it after a day of outage, you're a hero.
if you deliver it late, but fix the problem first, you're not "getting it done"
1) they lack nuance,
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.
But.
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
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.
As with all, knowing when and what to collaborate is paramountly important.
More generally, erring on the side of collaboration is better, than being self reliant and sub optimal.
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 changesI 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?
If you view source, you'll see
<meta name="generator" content="Gatsby 2.15.26"/>
server: cloudflareThere’s asking for help when you know it will accelerate things for everyone.
There’s asking for help to avoid responsibility.
Do the former while avoiding the latter.
otoh, the best advice i've ever had was from a CTO of an investment bank i worked for - "just f*cking do it!"
in other words, don't sit around overdesigning things and thinking why they might not work.