Look at how people have responded to Rust. On the one hand, the learning curve for memory safety (with lifetimes and the borrow checker) can feel exhausting when moving from something like Ruby. But once you internalize the rules, you're generally cooking without it getting in your way and experiencing the benefits naturally.
Writing secure systems feels similar. If you're trying to back port something, as you said, it can be a pain in the ass. That includes an engineer's default behavior when building something new.
I think by the time you are hiring people at 27 years old or whatever, there is a noticeable gap in motivation. A quarter century of lived experience (which is "inherent" to the person you're hiring) is a lot, especially at the beginning of one's life.
There are all sorts of things like depression, cynicism, past experiences, etc. that can lead to someone have a lower baseline of motivation. It's also highly contextual, which I think is what you're saying and I 100% agree with. Some people thrive in role A and would want to bang their head against a wall for 40 hours in role B. Others vice versa, others would be meh in either, etc.
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.
I think motivation is contextual. When I love the mission of the project I'm working on, I'll put everything into it. When I hit a prolonged wall of politics or poor leadership, I'm not going to operate at 100%.
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.
I'd go further: a bad manager can turn a great engineer into a very bad one. People look up to great people, and when the strongest performers are demotivated, that spreads.
Commonly in the cultures that end up this way, leadership blames / gaslights the ICs. It's toxic and honestly kind of heartbreaking.
If they are very bad, the company can let them go. If they are simple good or fine, the company lost their great engineer, and now has a seat filler that they can’t justify firing.
For sure. At that point they have to fire them, even though it's the company / leadership's fault and hard to watch. Ultimately better for that engineer, as well, to move on.
One of my core philosophies as a manager is that by default I should get the fuck out of the way. From there, identify the biggest issues and solve them.
If you're successful hiring great people, I really don't understand the desire to micromanage them. Or do silly things that are demotivating, like 996 or trying to mislead them / market things / hide the bad stuff.
Treating people like adults is that One Neat Trick that influencer bloggers don't want you to know.
> Treating people like adults is that One Neat Trick that influencer bloggers don't want you to know.
In the companies below Big Tech in valuation at least, having been in the room with drunken executives speaking their real thoughts multiple times, I’ve found it’s because they don’t want to treat people like adults.
They want serfs to order around because they have some cultural value around being “the boss” and you can’t be “the boss” if you aren’t telling people what to do. The more things you tell them to do, the more of a boss you are.
It’s how you get executives crowing to you about all of these faang ideas like google’s 20% time back in the day, or engineers being able to vote with their feet and only attend meetings they found useful, but then have people on pips because they were consistently 30-60 seconds late to daily standups.
It’s not the only failure mode by far, but having leadership like that seems like a cause for companies getting hard stuck below a billion in profit
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.
i agree. but. there's something in the behaviour of these unicorns that should be examined.
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.
I've been an early employee (sub 10 and 20) in two unicorns and another (a presidential campaign) that didn't have a valuation but did the equivalent. People did not work 40 hours per week, and I feel comfortable saying that the companies could not have been as successful if people had.
The common threads were:
- incredible ICs
- founders who spiked in the most important areas for that market
- a mission that everyone truly believed in
- a culture of people who deeply cared about one another but were comfortable pushing back (as you said!)
It's incredibly rare to find all of these together. I agree that management is responsible for helping others thrive, but not necessarily that they should shape the environment to fit any engineer. Some people want things (projects, challenges, roles) that don't make sense in that company's context. It's okay, especially when it's hard, to agree that this isn't the place for someone.
Are you saying people worked less than 40 hours a week or more than 40 hours a week in those organizations? I’m assuming over, but it’s unclear to me from the tone of your post.
The Basic variant on a TI-84 was magic. One science teacher at my high school allowed us to use any program as long as we wrote it ourselves. I remember making programs with nested menus for all types of physics algorithms. Through debugging, I ended up memorizing them anyway, but it was more fun (and error-free) to use the program itself.
He was not trolling. Please don’t persist the lie that people spouting racism are “only joking.” It’s harmful, disrespectful, and either purposefully in bad faith or embarrassingly naïve.
Writing secure systems feels similar. If you're trying to back port something, as you said, it can be a pain in the ass. That includes an engineer's default behavior when building something new.
reply