81–90 of 361 posts
lol. "don't motivate engineers." dude can't motivate engineers with money so he thinks you can't motivate engineers. that's actually funny. and a little depressing.
why don't you criticize the arguments his making instead of the person, he is basically saying hire people with autonomy not people who need motivation.
When I read about 996-style culture I am happy to be European. That would not work here. 40 hours per week max and most engineers prefer to not work more than 32 hours a week. So you have a good work/life balance. I currently work 4 hours a week.
>I currently work 4 hours a week. Which employers hand out 4h contracts?
> do not adopt all the "Scrum rituals" like standups, retros, etc. wholesale, and if you do, keep them asynchronous. There is little added value to a voiced update I couldn't disagree more. I know it's an unpopular opinion, but when standups are done synchronously, everyone actually pays attention, notices blocks and helps with them. Things get surfaced and quickly addressed that simply wouldn't otherwise, which is t…
In a large org where the most senior IC and the manager are both in 35 hours of meetings a week while the rest have 20 a week you need rituals. When all they are focused on in engineering then you don't.
Earlier quoted context omitted.
As usual, the problem is not 996 itself but comp. You can get 996, you just have to pay for it. The reason Europeans don't want to do 996 is because the extra effort isn't fairly compensated.
Not only is it rarely compensated, it's rarely effective. Software work is bursty and creative, not mechanical and hourly.
Earlier quoted context omitted.
Engineers were the privileged class. They were part of the group occupy wall street wanted to bring down. Not hard to guess why they didn't want that.
I would say more precisely, engineers are closer to the managerial or capital wielding class; usually the adversary of the union.
> Motivation is a hired trait. The only place where managers motivate people is in management books Initial motivation is the hired trait. It’s very easy to demotivate people. The trick is to not do that.
Thw word hired is doing a lot of work. Is motivation intrinsic to a person. Or is it a person plus situation. Ot is it person, situation and reason (reason given in interview) I have been most motivated when there was an aha in the interview process. Or a "cooll!" feeling. For me usually about the end product over the tech stack. I like to work on things I like to use myself.
There's a trifecta that works well:
1. The job is what the employee wants to be doing (IC, manager, FE/BE, end product or mission, whatever).
2. It's what the company needs. (Don't let a high performer do something that's Priority 10 just to keep them.)
3. It's what the employee is good at. (This includes areas of growth that they have aptitude for!)
People in those situations, in my experience, tend to thrive. It's great that you've recognized the kinds of products (ones you use) that give you that.
Something I don't think hiring managers do enough is convince applicants not to work there. Have a conversation to discover what the person wants. If it's not this role, that's totally fine! It's far better to help someone discover what they love than hire someone into something they won't.
Earlier quoted context omitted.
Which is why fewer and fewer companies are hiring in Europe.
I'd say the exact opposite. engineering is markedly being outsourced to europe.
> at 15 engineers, it is very doable for a single person to keep track of everyone's work and ensure alignment. All my past experience disagrees. Sure you have 15 engineers, but you're supporting a business of 150 people. This is a pretty common ratio. The noise gets very loud at that scale and it becomes almost impossible for self-managed engineers to make forward progress. At the very least you need super clearly d…
I don't believe a manager can be effective at 15 direct reports. I think it's possible to keep things afloat, but split that team in half and hire another manager and you'll be in a much better position.
What usually happens here is that your most senior members of the team are picking up management responsibilities instead of doing IC ones. By all means they should contribute to mentorship, direction, culture, etc. but there is way too much going on to have a deep understanding of those 15 engineers.
The only times I think this work is when the leader sucks, so swamping them with reports means they have a more difficult time micro-managing. But they're probably getting in the way in some other fashion.
Earlier quoted context omitted.
>I currently work 4 hours a week. Which employers hand out 4h contracts?
Depends what one considers “work”; if you’re only counting focused, active coding work then there are places where 4 hours is the max you’re going to achieve of that anyway.
But let's say it's only counting "focused work", 4h/week is huge stretch, unless we're competing in slacker olympics.
> I know several top 1% engineers in the Valley who disengage from recruiting processes when 996 or something similar is mentioned. A few years back, on this board, 996 was something people made fun of when it was reported that some Chinese companies did it [1]. And now, the strongest claim this blog can make is that some engineers in the US would disengage from recruiting? That the issue with working on saturdays is…
I would tell a recruiter directly that 996 is a red flag. Prior to that it was cracked (née 10x (née ninja)) engineers or sigma grindset or whatever. It's performative. If you bring people together to build something that they actually give a shit about, you'll out-perform a group of people who are grinding out of fear. And you'll _definitely_ out-perform the kinds of people who are buzzword heavy.
the idea that an engineer can be a ninja, 10x or unicorn independent of the processes of their environment and working group is laughable. i have known several people who were identified as "highly productive" and they all had some individual traits like a) they were very good with individual time management, b) were not afraid to say when they didn't understand something and c) were all pretty smart. (and d, knew how to give good code review comments without pissing people off.)
but... they also needed an environment where they could push back and say things like "i do not feel participating in today's 1-on-1 meeting (or meeting with product management) is a good use of my time", where task design gave them chunks of work that were appropriate and they were given the freedom to identify (and avoid) "wicked" problems.
which is to say... i don't think the story of the ninja/unicorn is complete fantasy, but management has to understand how it's real and craft an environment where an engineer's inner-unicorn can emerge.