Hacker News Reader

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

> The only thing the manager cares is how much more work they can get out of you to show to their managers.

*appear to get out of you

Which is why shit, unmaintainable code often goes unpunished

Yes, there's a lot of technical debt in the codebase.

    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.

Better for who?

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

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 know why bosses/owners want it. I'm asking why a commentator is advocating for it

Am I that commentator?

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.

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.

This highlights how lots of managers are just plain not good at their jobs.

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.

Most people are not great at their jobs. We’re all on a bell curve.

I suspect good management, as plotted on a curve, does not follow a Bell curve.

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.

Same.

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.

What professions start with experienced people out of the bat?

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.

There is a reason that many organizations have a leveling guidelines that you have to perform at the next level before getting promoted to it.

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

It's not scope and impact either.

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.

Believe the no, don't believe the reason.

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.

Only strategy B is reliable.

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.

> If CEOs were graded on a curve, the mean on the test would be 22 out of a 100.

https://a16z.com/2011/03/31/whats-the-most-difficult-ceo-ski...

Wouldn't startups have way less of these issues ?

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.

Maybe, but I sort of doubt it.

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.

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.

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

That's not the opposite though.

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

Taking time to do things right is not the same as more meetings with more stakeholders.

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.

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

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.

Just wanted to say, that is an excellent username.

> maybe they misunderstand your message, maybe they fumble the delivery, maybe they forgot

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.