> Motivation is a hired trait. The only place where managers motivate people is in management books.
This seems entirely false to me. To be honest it is so incorrect it significantly puts into question the rest of the article.
1. I have absolutely had managers motivate me to work harder. I have also had managers completely demotivate me and cause me to quit. How on earth can anyone who has worked in the industry for any amount of time say that "The only place where managers motivate people is in management books"?
2. Of course most of the facile strategies mentioned in the article (like 996, micromanaging, etc) won't work. The article then generalizes this to all strategies - but "if terrible methods can't solve it, nothing possibly can" feels like a shaky argument at best. A good manager understands this, and motivates by helping you understand how the things you are doing are actually critical to the success of the team and the company. (If success of the company isn't something you're interested in, then yes, it's going to be hard to motivate you.) A poor manager sabotages motivation in a hundred different ways - he makes you feel like your efforts are totally wasted, or fails to articulate why they are important.
I’ve been working for more than 30 years. I was seriously demotivated by managers, but never motivated by them. The beat I got was protection from them to give me free space to work. But the motivation was always internal.
Being a manager myself, I never got to motivate anybody do anything they didn’t want to. If they wanted to, it worked, but the motivation AFAIK was internal.
Of course that is one person speaking. Milage can vary.
This is a core part of systemantics [0]! People are going to do what they’re going to do, as a manager the most you can do to help is to put people in the right teams and to get distractions out of their way.
It’s a difficult idea to accept but once you accept it, it’s kind of liberating. It follows that hiring and then work-assignments during roadmapping are the two points of highest leverage in making a mutually-successful employee-manager relationship.
The problem you’re solving there is a search problem. You’re trying to discover if the employee’s motivation landscape peaks in any dimensions that align with the roadmap. They can be the most skilled person in the world, but if the peaks don’t overlap, the project will never run smoothly. It also follows that in extreme cases where you have a tenured employee that you want to retain for future work, you should absolutely let them drive and shape the roadmap.
You're making a nuanced point but it's correct. Good managers can give a little motivation (mostly by talking about and finding the right areas to work on for those people that don't otherwise already know). But for the most part good management is buffering the core that allows individuals own motivation to be self-sustaining (and productive over time) and also making sure that people aren't on a path that won't be useful (i.e. the manager knows the company will never fund phase 2).
I want to hazard a guess that a motivational manager is just like a well-oiled cog in a machine. You essentially never notice them as having influence over your motivation and only pay attention to the squeaky and rattling and faulty ones.
>> I never got to motivate anybody do anything they didn’t want to.
I'd be willing to bet that as a manager you've gotten people to do the shit work no one wants to though, mostly by explaining why & how it's important, sharing it across the entire team, working to eliminate dumb parts of it and stepping in to do some of it yourself - and yes, occasionally assigning it directly. To me, that's motivation: sustainably coordinating energies in a shared direction for the greater good.
I think you can indirectly motivate, or is that something else? If you create a good working/team environment and reduce the factors that demotivate people, then you will indirectly motivate them. This includes working on yourself as a manager. There are of course edge cases, but most people will thrive if the environment is good.
> A good manager understands this, and motivates by helping you understand how the things you are doing are actually critical to the success of the team and the company
Your definition of a "good manager" is essentially "does not actively sabotage work of subordinates". That's not motivation, that's merely absence of active demotivation. A person knowing how and in what ways their work contributes to the success of the unit and the whole are absolute basics and if a person is not aware of those either their manager is incompetent as hell or actively hostile.
Reminds me of those job ads where "benefits" section contains gems like "salary paid on time". That is not a benefit, that is such a basic that even mentioning it puts into question everything about such company.
Disagree. This is explicitly active: "helping you understand how the things you are doing are actually critical to the success of the team". It could include building out a team dashboard that tracks the consequences of bugfixes, for example.
Not really? At a small startup, sure, this should be obvious, but a manager who is able to articulate how my work bubbles up to company success at a 1000 eng company, in a way that makes sense, is a pretty rare breed.
> Your definition of a "good manager" is essentially "does not actively sabotage work of subordinates".
This is not even remotely what that person said. They said "motivates by helping you understand how the things you are doing are actually critical to the success of the team and the company". That is not nearly "does not actively sabotage".
> A person knowing how and in what ways their work contributes to the success of the unit and the whole are absolute basics
Oh please. If you reject every single thing good managers do to motivate people as "does not count" then of course you will end up with nothing. It is super easy to not see how this or that contributes to the success of a thing. It is also possible to be in position where you are in fact not contributing to the success - while you created an illusion in your head about how important you are.
I'll agree with you that the author tried to put in a sound bite and it failed to clarify the author's point.
The author is trying to argue for hiring early engineers who have exhibited ownership values and who want to take ownership for their work. These are the people for whom you establish "extreme transparency" (see: late in the post), a Google Doc for them to help align with others on high-level plans, a kitchen for people to informally talk in, and then get out of their way. That kind of environment is indeed in and of itself quite motivating for a certain kind of engineer.
Of course, it doesn't scale to BigCorp-size. Eventually you have too many cooks in the kitchen. The truth is that the vast majority of engineers really do want someone to tell them exactly what to do, so that they can come in to a highly structured 9-5 job and earn a paycheck that pays their mortgage and feeds their family. Author's prescriptions do not apply to large companies or to most engineers, and Author makes it clear as such.
I d argue its not the manager that motivates people that can only be found inbooks.
Its the manager that can come in and mend a toxic and dysfunctional team.
The toxic teams end up breaking good managers in the end and they either become part of the problem or leave.
The hero manager described in the phoenix project is a myth.
The motivational one imho is very real but they need a good platform just like everyone else.
I've only experienced de-motivation from managers, personally. At least for me, motivation comes from ownership, impact, autonomy, respect. You can cause me to lose motivation in a lot of ways, but you can't really cause me to gain motivation unless you've already de-motivated me somehow.
You can de-motivate me in a lot of ways, some examples:
- throwing me or a coworker under the bus for your mistakes
- crediting yourself for the work of someone else
- attempting to "motivate" me when I'm already motivated
- manufacturing a sense of urgency, this is especially bad if you try to sustain this state all indefinitely
- using AI or market conditions as a fear tactic to motivate the team
- visibly engaging in any kind of nepotism
Honestly this list could go on and on, but those are some that come to mind.
> manufacturing a sense of urgency, this is especially bad if you try to sustain this state all indefinitely
Sadly, I have seen this in almost every startup led by founders without an engineering background I've ever been a part of.
In my personal experience, this is often caused by overeager sales team promising the world for the next deal, only to fob it off to the engineering team who now "urgently" need to build "features" and "work hard" to make it happen. This is when your intrinsically motivated engineers start looking for the exit.
The point is that the 'maximum motivation level' for an employee is an inherent trait. It is a ceiling. Some people have high ceilings and some don't. If an employee has a low ceiling, no manager can motivate that employee higher.
But if someone has a high ceiling, the most a manager can do is create an environment that allows the employee to achieve their max potential. A bad manager on the other hand, can very easily bring a normally high-potential motivated employee down to mediocre levels.
If you are one of those self-aware leaders that knows how to create an environment where people can excel, then hiring highly motivated people is the winning strategy.
The author seems to lack any sort of understanding of motivation beyond some sort of vague, blackbox "fire in the belly" concept. This is definitely not true. My take aligns with yours: motivation is a vector, having both magnitude and direction. You want individuals with the fire and then somehow need to figure out how to direct the combined heat. In the earlier stages of an externally-funded venture this is the difference between building a jet engine and pouring gasoline on a campfire. I agree you don't need a manager to do this, but also feel strongly that by the time you're at multiple teams your CTO-founder is also the wrong person. They're probably a core developer who earned the title with limited experience; don't make them learn how to manage a dev team's day-to-day while they also learn every aspect of engineering management. I wish every CTO started as a team lead, but in this scenario it's too late. CTOs largely lead the parade, but you're devs need a servant-leader in the trenches who can articulate from the front, constrain the sides and push from behind.
The author seems to be thinking of word "motivate" in the way that someone in the olden days would motivate a donkey - with a whip. Every example they're listing is not "motivation", it's effectively forcing additional work and hours. No motivation is happening there.
The fantastic element that explains the appeal of games to many developers is neither the fire-breathing monsters nor the milky-skinned, semi-clad sirens; it is the experience of carrying out a task from start to finish without any change in the user requirements.
As a lead or mgmt I set my highest priorities to:
(a) make sure that the goals are set to stone and crystal clear
(b) the team can do their work without any unnecessary distractions
(c) try to remove some of these "necessary" distractions as well
It can be really hard. And it can very ungrateful. I aim to be a nightwatchman, and I'm really proud of myself when the team thinks I'm getting paid for nothing. The bigger the structure the bigger the drama and I don't want them to be any part of it.
Meanwhile I struggle with stakeholders who are like "c'mon, you already build the skyscraper, we just want you to move the parking lot from the underground to second story, how hard can it be, you have all the parts in place, just move them around".
Cared about anything other than their own upward movement, actively worked towards my professional development, made sure I had actual, not hand wavey, feedback, and made sure my compensation reflected my growing responsibility.
I am aware that all of those things may not be in their power to give, but some combination of that in any org that is somewhat functional would be motivating.
I have read the sibling comments here and it is so saddening. The general expectations for management are, apparently, so low, that a manager attempting to do some duties in their job description is lauded as some savior. <crying-cat.jpg>
I had one manager who got extremely excited about whatever you were working on. It was infectious and motivated most of the team including myself. He’s an innately curious person, but also whip smart and surely developed this skill deliberately.
I had another boss, a founder, who had a difficult relationship with engineering but was extremely gifted and had a great vision. I found myself highly motivated at this company as well, but for wholly different reasons. There are many paths to success.
Both startups had successful exits, and I felt as though I contributed meaningfully to both.
> 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 daily standup? What happened in these years for such a change to happen?!
Former Alibaba employee for a season of my life. I have to be careful with my next sentences because on the internet because it's easy for people to read things in a vacuum and interpret in the worse possible way, so don't do that because thats not how I mean it. The 996 hours are not useful work. It's appearance over productivity.
Yep, if you were to watch what happens at a 996 shop, it's people literally living their at-home life with their fellow employees for most of the time.
I've worked with a few coworkers who came from a 996 environment and kept doing it out of habit. As I was young and impressionable, I started doing it also. I'm not going to be careful with my sentence: these people were absolutely NOT getting more work done than others, in fact they seemed to move glacially, because they had so many more hours to fill up. It's a total footgun, and it chases away good people once the rot reaches management and they start promoting based on perception rather than reality.
- 30 people between the ages of 18 and 25 sharing a tiny, single office room working on folding tables and CAT 7 cables hanging from the ceiling
- Whiteboards from floor to ceiling on every wall covered in scribbles and diagrams in red, black, and blue pen, half-erased with some "SAVE FOREVER" circled parts
- Typing really fast on loud, clicky keyboards
- Doing nothing but coding or working 18 hours/day with no life at all
- Living at work in sleeping bags
- Surviving on cold delivered pizza, hot instant ramen, and coffee with only a mini fridge, a microwave, and a coffee pot
- Spending absurdly little money on everything
The problem is that if even one gigabusiness began vaguely in such a manner, someone will declare some aspect(s) were "essential" and try to cargo cult the "hard work" pseudo-signals without considering sustainability or that it's even necessary. There are far too many engineers who will overwork themselves until they reach burn out or will not maximize real productivity by working less and taking breaks/vacations, and then won't want to work on a venture at all anymore.
PSA: Don't be a sucker and don't work for below market rates. Eschew working for other people and megacorps when possible; form unions, worker-owned co-ops, and/or get significant amounts of preferred liquidation-preference shares.
Until recently American engineers made a lot of money at comparatively cushy jobs. A decent engineer in the US could make 5x their equivalent in most European nations. Staff+ engineers at FAANG could make 5x that. People in a good position tend to not like rocking the boat.
There are unionized engineer jobs in the United States. Every time this conversation comes up people act like we don’t have any unions, but that’s not true. There are unionized engineering jobs.
One of them even tried striking a couple years ago, quite publicly. They ended the strike a couple days later without gaining anything.
I think American engineers know their situation and options better than you think.
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.
> And now, the strongest claim this blog can make is that some engineers in the US would disengage from recruiting?
The statement was specifically about top 1% engineers in Silicon Valley. That’s a very, very small subset of all engineers in the US.
The pointy end of the talent spectrum in SV is a very weird place because it has had a lot of engineers for whom work is life. Living at the office and having coworkers working 24/7 might be something they like.
I’m not condoning this or saying it’s common. It’s not common. However, once you narrow down to the extreme outliers in the long tail of talent distribution you will find a lot of people who are downright obsessive about their work. Their jobs also pay north of $1mm including equity, so spending a few years of their life 996ing on a topic they love with energized people isn’t exactly a bad deal for them.
In general, if a recruiter told an average engineer that 996 was expected that would be the end of that conversation. Average US engineers are not signing up for 996 for average compensation.
I am this person (not a genius or whatever) but work is absolutely life for me.
I still absolutely resent the 996 culture and would never do that. I'd like to have agency when I want to abuse myself
What happened? Started with Musk purging half his staff ...
I've been around long enough in this industry to see the pendulum swing back and forth a few times. The peak of 2020/2021 was the epitome of "spoiled tech worker" but now we're well on our way the other side, I'd say.
If you had enough time to look back through my post history, you’ll find back in 2021 2022 I was loud as hell Screaming from as high as I could on this board primarily that we need to be doing everything we possibly could do to unionize, build labor cooperatives etc. and absolutely nobody gave a shit.
I would get roasted every time and that’s fine I know what I’m doing.
but the attitudes are changing and while it’s frustrating to have to deal with that I feel like being a Hector on this topic is just the entry fee.
I’m extremely dissatisfied at the pace and scale and lack of leaders and organization and push back and etc… so I expect the next two years to be really really really bad and the hope is that people wake up at a large enough scale that they actually are able to affect something but I don’t have a lot of hope for that.
What I describe is not real activism imo but at least I can tell you from first hand documentation that sentiment is changing.
"I know several top 1% engineers in the Valley who disengage from recruiting processes when 996 or something similar is mentioned."
Setting this expectation early seems honest and the best thing to do. The worst is when companies sell people on WLB but then flip it to 996 -- you end up with all the wrong people and no one wins. Best to be transparent from the onset.
I always encourage candidates to go visit the company several times if possible, including a visit at 5:30pm or 6:30pm to see the state of the office and attendance. There is no right or wrong answer --
> including a visit at 5:30pm or 6:30pm to see the state of the office and attendance
As an academic, I used to work 11am-8pm many days when I was younger thanks to flexible working hours, and I wasn’t the only one working late but not early. I realize this is probably more rare in corporate settings, but keep in mind if the place has flexible hours you might see more people at 6pm despite people not doing 996.
I think that is great if you want flexibility, and I used to do that also!
What i'd assess at 6:30 is whether people are on meetings or on focus time. If you have monitors with zooms full of 5-6 people, I wouldn't think that is flex hours, i'd assume that is a meeting being scheduled at 6:30.
On the other hand, if you have people focus working, you cannot draw any conclusions from that.
Personally, I stay at work late. But there is a difference between me being obsessed with a problem and working thru the evening trying to solve it (awesome for me) vs meetings that are being scheduled at 6:30pm or 7pm
That was true of me as well, and at the same time, I was working alongside parents who worked 7:30-5:30 with a break to pick up the kids from school.
Nobody wants a "visit" from the founder, anyway. They want timely two-way flow of information, access and guidance on the occasions when they need it, and maybe (maybe) an occasional chance to hang out socially as a group with no reference to work. Nobody wants the founder randomly dropping by during work hours to assess morale.
This is really my priority to achieve at a job, and one of the reasons I try to be good enough to be indispensable is to be allowed to roll in in the morning whenever I get there.
I have a very tough time in the morning convincing myself to go to work, and a very tough time at work tearing myself away from something in an intermediate state. Things at work are always in an intermediate state at 5:00, unless you stopped working well before then (or got very lucky), so I always end up working late whether I come in on time or come in late.
So I'm always trying to get to the point where management lets me get there when I get there, and trusts me to be productive. It's a mental thing. I get up early and do a lot in the morning; I'm a morning person. Maybe too much so. The time between getting off work and going to bed is garbage time for me; a long annoying commute and a meal. When I leave at 5:00 I just fall asleep by 9:00.
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
we used to say "employees don't quit jobs, they quit managers." i was very happy at Amazon until they moved me under a sub-optimal manager. i quit less than a month later. that manager got promoted. this will tell you everything you need to know about working at Amazon.
maybe they were trying to get me to quit. maybe that area's director was incompetent. maybe both.
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.
I may not be using the same definition of "motivation" as the author, but understanding what motivates your people, putting the right mix of people together to work on the right problems, and knowing how and when to apply pressure to get people to do their best work are absolutely something managers can do to motivate their teams.
Yep people have all sorts of sources of motivations. One of the key ones is a sense of ownership. Many people join startups instead of BigCorp because they want voice and influence that they don't get in a larger company. I've seen so many founders, managers, leaders, etc kill that by not recognizing this fundamental fact.
Of course there's also the problem that you can find and hire people who are motivated people but there's absolutely no guarantee people are going to be motivated for your specific problem.
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.
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.
We're apparently back to making psychoanalysts out of interviewers:
I'll dedicate a post to specific ways you can identify motivation
during hiring, but in short, look for: the obvious one: evidence that
they indeed exhibited these external signs of motivation (in an
unforced way!) in past jobs; signs of grit in their career and life
paths (how did they respond to adversity, how have they put their past
successes or reputation on the line for some new challenge);
intellectual curiosity in the form of hobbies, nerdy interests that
they can talk about with passion
I'm pretty confident that this doesn't work, and that searching for "intellectual curiosoty in the form of hobbies and nerdy interests" is actually an own-goal, though it's a great way to keep your Slack channels full of zesty, nerdy, non-remunerative enterprise during the core hours everyone has to actually ship code together.
10 years ago I bought into the idea of hiring for nerdy interests and hobbies as a proxy for motivation. I will say I met some excellent people during this time, but looking back those same people would have been hired anyway due to their accomplishments at companies.
> though it's a great way to keep your Slack channels full of zesty, nerdy, non-remunerative enterprise during the core hours everyone has to actually ship code together.
Spicy take, but that's 100% consistent with my experience. Hire a lot of people for their nerdy interests and hobbies and your company comms become full of chatter about nerdy interests and hobbies. Meanwhile the "boring" people who ship code and then go home to their families (or pets, or anything) are trying to ship code and get the job done.
Nerdy interests and hobbies is not a good proxy for work ability. Hiring someone primarily for nerdy interests and hobbies is probably a red herring. Focus on what matters.
>10 years ago I bought into the idea of hiring for nerdy interests and hobbies as a proxy for motivation. I will say I met some excellent people during this time, but looking back those same people would have been hired anyway due to their accomplishments at companies.
>Nerdy interests and hobbies is not a good proxy for work ability.
I'm not optimistic about scalable strategies to identify "motivated" employees, but I'm not certain. I am pretty certain these strategies are bad. They're what everybody did in the mid-2000s.
> 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 defined ownership boundaries. That means business process and workstream ownership, not code ownership.
My rule of thumb is that management complexity is given by #direct reports x #project, where project is defined as a set of stakeholders (be it PM, etc. depending on business).
Concretely, managing 12 ICs on a well defined platform team w/ a single PM is much easier than managing 6 people working across 6 businesses, as is more common when managing a team of data scientists.
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.
it's worth reading Mythical Man Month WRT team composition. not because Brooks says anything new about the subject, but to get perspective on how long people have been trying to find a good idea for how to structure teams.
> I'll dedicate a post to specific ways you can identify motivation during hiring, but in short, look for
All will be gamed by interviewees, by the afternoon this hits the HN front page.
(And, for example, tech interview prep has already been telling people to fake passion and curiosity, for many years now.)
Here's what you do:
1. Consider that the early startup also belongs to the early hires. It's their startup too. You're the last-word decider, but it's not only your startup. You want it to also be theirs. Believe this, and act like it.
2. Reflect that in the equity sharing. "0.5%", to be diluted, as options, with ISO rules that discourage exercising at all... while co-founders divide up 70% of founder real shares between themselves... is nonsense, for that founding engineer, who you should want to be as motivated as you, and contributing as much as you do.
3. With equity like you're serious, make the salaries low-ish. Not so low that it's nonviable for modest family cost of living, but low enough to self-select out the people who aren't committed to the company being successful, or who don't actually believe in the company.
4. Have an actually promising company and founding team, or you won't get many experienced people biting.
I think what people miss about indexing on social signals is that convincing social performance is hard. My suspicion when people say things like "ah but if you index on a social signal then everyone will just perform the social signal" are themselves feeling as though they do not naturally signal that thing, and ironically are frustrated by the effort that it takes to appear as though they do.
The context on this one is that we've gone from an environment in which kids were mocked for having curiosity and passion about nerdy things like systems, and it didn't pay that well as an adult, and those people would go home at the end of the day and also write open source code...
To one in which it's now a high-paying career, and a bunch of interview prep manuals coach on faking that, doing open source to promote your career, etc.
So if OG nerds look around at the environment and see the dynamics, of people who just want well-paying jobs (nothing wrong with that) seeming to do a performative dance with interviewers who also just want well-paying jobs (nothing wrong with that), and everyone is being told to project passion and curiosity (when they really just want well-paying jobs) and to look for it in others...
You think the problem is that OG nerds, for example, feel that they do not naturally signal that?
They may signal that just fine, but merely be questioning all the performative theater by people who aren't here for that, but some management fashion told them they should pretend to be.
1. Motivation is a feeling, it's an emotion, it comes and goes, it's a bonus. It's discipline and professionalism that make the huge difference. Many people have the motivation and dream to "create their own programming language", "launch their startup", "make it to the NBA", "lose 40 pounds and get fitter" but this motivation, a feeling, will consistently fight the emotions telling you to have fun, relax, go out with friends, play video games to relieve stress. Motivation is a great boost to discipline and professionalism, but those two survive even when motivation goes off, whereas won't take you anywhere.
2. You cannot hire for motivation and if you're looking for that trait you'll likely projecting your own biases. I suspect that the author of the blog post has nerdy hobbits so he projects himself on candidates. Non sense. Yes, nerdier engineers are likely more interested in the craft and in overall engineering, but that says absolutely nothing about them being motivated in building yet another B2B SaaS.
3. A very good engineer joining a startup, should have the implicit motivation of wanting to get rich in few years, otherwise he/she's be joining a cushier job that pays better.
I disagree. Motivation is not just an emotion but an inherent desire. For a motivated engineer the balance between the work with pleasures and dreams is already won and pre-balanced for sustainable achievement.
I find the work itself rewarding and I find world improvement results reinforcing of my enjoyment. I want to code and I'm happy to direct that energy largely according to my employer's needs and our shared benefit. I can be given high level directives and refinement feedback over time. My observed results are faster, more effective progress as reported by internal and external stakeholders. I haven't minded becoming wealthier but it was never my primary motive.
> Motivation is not just an emotion but an inherent desire
Desires change as we grow up and life changes us.
The people you hire today, aren't going to be the same 3/6/9/12 months from now when a parent gets sick, a partner leaves, a child is born, when something suddenly changes their priority, etc.
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 second this. On paper Austria has below average working hours in EU statistics but I've seen a lot of overwork in the tech companies I've been at by some people, but which was never officially reported because the workers themselves just went along with it.
Scandals in the papers around the crazy hours workers at big-4 consultancies in Vienna typically do, which again went unpunished by labor agencies, since there were no written orders from management imposing those long hours but workers just tactilely accepted it as part of the work culture there.
Similarly, a mate of mine at major finance gig in Frankfurt noticed that they were working longer hours than their colleagues from NY. Heard similar stories from colleagues from Italy and France.
So work hours are super dependent on local culture and industry. The meme about everyone in the EU being paid to slack off all day is not as common as people imagine, unless maybe you work for the government or got lucky to score a great gig in some dysfunctional monopolistic megacorp.
I've found in (EU) academia at least that people essentially lie about how much work they do. In anglosphere it's far more common for people to be open/expectant of 80 hour weeks etc. Probably the lieing approach is better for society/culture.
not everyone in the states is 996, but yeah, there's a pandemic of bad management here. or rather... not so much bad management... but management by people who read articles about how Amazon, a company with tens of thousands of engineers, manages projects and then decides they're going to manage their startup of 4 people the same way because they think it's a "growth hacking" hack.
just keep in mind that American tech startups are often just vehicles to evade estate tax. and certainly vehicles for converting VC money into more VC money by selling dreams to greater fools. there's also a down side.
Are they? Do you have a source for that? My impression is that it's easier to find engineering work in Stockholm than in silicon valley atm, but I haven't measured objectively.
How does this work though? Do you have around 4 hours worth of work you report on? Are you paid for more than 4 hours? I’m so curious when people throw completely alien statements like this out like it’s something that doesn’t even warrant explanation.
I freelance. Occasionally I get called by former clients to work on legacy systems I was lead on. And I have some support tasks for former clients.
For one company I log on once a month, I start a Renovate process which generates pull-requests for updated dependencies. Patch-versions get auto-merged after tests succeed, minor and major need approval of the current lead. Sometimes I need to manually tweak the code a bit because of API changes or to get tests to pass. I'm allowed to bill them four hours on it regardless of actual work, which is between five minutes (no manual intervention required) and two hours (need to rewrite some code).
For another company I create a report once a month for all outages and which errors frequently show up in logging. I automated this to be a five minute task and it generates a Wiki page. I review the page to see if everything is ok. I bill an hour on this.
The company is happy to not have to allocate engineer hours on maintenance so they can continue pumping out new features.
I'd say that on average I work 4 hours and bill 12 hours. This is comparable to the income of someone in employment working around 24 hours. But I do run a significant risk obviously.
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.
You don't have to work at an early stage startup - in fact most people don't. But some people do wish to participate in an early stage startup, and plenty do in Europe as well.
> So you have a good work/life balance. I currently work 4 hours a week.
And this is why when I was a PM, we shut down our Amsterdam office and shifted it to Praha, Bucharest, and Warsaw. You won't find as many people who will complain about a 40 hour workweek while earning €80k TCs
I think its clearly false that motivation is an inherent trait. That would imply that demotivation is also inherent, which I think is even more obviously wrong.
I think demotivating people is incredibly easy, see any Dilbert cartoon featuring the PHB ever.
That doesn't mean that motivating people is also easy. They're not equivalent.
Motivating people requires understanding their psychology, their values, what they want from their life, etc, and then applying that knowledge to create a workplace culture that feeds all of that. Demotivating them just requires not understanding any of that, or ignoring it in favour of feeding your own ego or psychology. It's a lot easier to demotivate.
Certainly it's easier to destroy than to build but if you tell yourself "my teams motivation is entirely intrinsic" you might, for example, think you can abdicate the duty of removing demotivations.
Ah yes the workplace culture, psychology angle. I would expect to read that on Linkedin, not here.
No, motivating people simply requires giving them more money (performance bonuses, stock options, thirteenth salary/end-of-year bonus...). DUH. OBVIOUSLY.
People in management positions always try to weasel their way out of paying their people more. (Well, not always, not all of them do, but you get my point.)
Unless you work on truly cutting edge stuff (by which I mean the likes of SpaceX and its equivalents in different industries), motivation is money.
It's as simple as that. No need to twist yourself into all kinds of pretzels.
No, it's not the coworkers (which, by the way, are not your friends unless you meet outside of work), it's not the job as such (very few people outside of art actually enjoy doing their job as an activity after say 10 years of doing it), it's money.
Money is the primary motivator (by far). You work for money. End of story. Anyone saying otherwise is a bs artist.
It is better to divide motivation between intrinsic and extrinsic. Intrinsic comes from within and is probably best explained as an inherited personality trait. Extrinsic comes from external factors, usually money and rewards, as well as positive feedback. Demotivation is most probably a result of poor management (leaving aside mental health issues).
it's not hard to de-motivate people. but here's the thing... not everyone is motivated by the same thing. the trick of motivating people as a manager is spending the time to figure out what motivates them.
and if you could only de-motivate people, eventually everyone in your team would be de-motivated.
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.
The biggest thing is trust, in just about any relationship. The truth is, I think, most people are very well meaning and highly ambitious. It's disillusionment and distrust that creates the rift.
People want to work hard and they want to do good - but they're scared. They're scared that working hard will only be to their detriment and, well, can you blame them? When managers create an almost adversarial relationship, it can feel like doing your best is setting yourself up for failure.
And pay them well. If you want people to build you a thing that prints money, you better give them a sizeable cut. Otherwise enjoy "market rate" performance.
If you need motivation, maybe the organization is designed badly.
It was once said of the Roman legions "The Legion is not composed of heroes. Heroes are what the Legion kills."
Field Marshall the Viscount Slim, who commanded in the China-Burma-India theater in WWII, once wrote "Wars are won by the average performance of the line units."
He wrote negatively on various special forces type units, preferring to use regular infantry and training them up to a good, but not superhuman, standard.
Arthur Imperatore, who had a unionized trucking company in New Jersey, is profiled in "Perfecting a Piece of the World" (1993) for how he made his trucking company successful despite a very ordinary workforce.
There's an argument for winning by steady competently managed plodding. The competently managed part is hard. Steve Bechtel, head of the big construction company that bears his name, once said that the limit on how many projects they could take on was finding bosses able to go out to a job site and make it happen. Failure is a management problem, not a worker problem.
This post is talking about very small companies. At that 20+ person department, it's true. Once you have a team where the founder doesn't know everyone, the average matters a lot more.
If you have 15 people, you can hire 15 people and they will be able to organically organize if you hire well. If they have a question, they know what everyone is working on. The code base is small enough that everyone can just figure it out even if the documentation is bad.
The larger that group is, the more effort it takes to make sure everyone has the context they need to get their job done. That's where management matters.
And honestly, when I was the first manager (team of 17) brought in, I was writing code and on my own project in addition to starting to build up the "what do we need to do to scale?" You bring someone like me in at 17 people because you're going to need to scale soon and someone needs to build the first set of processes that solve the problems of the next stage, and figure out the onramp because done wrong, they make everything worse.
in the military we had a saying "you don't go to war with the army you want, but with the army you have." consequently, there was a lot of effort given to training and planning. the nature of most combat arms roles is such that you need most of the team operating at a decent level. i think the idea behind so much training is that if you can raise the performance of the worst performers, you might be able to improve the overall unit performance dramatically.
to put it in marketing manager speak, for many tasks in a combat arms unit, individual performance is a satisfier, not a a delighter. if one person in the unit does a bad job, the unit will fail. if everyone in a unit does an "okay" job, the unit will not fail. the outcome between the two cases is dramatic. but if you have a unit where everyone is "okay" and then expend effort to make everyone in the unit exceptional, you will not notice a concomitant increase in performance.
flipping this over to software development... you have a lot more control over whom you hire to be in your unit. but everyone has a bad week or a skills gap, so training (which could be as simple as giving people time to read up on a subject or write a few test programs) will eventually be important. like line military units, everyone needs to be hitting on all cylinders for the dev team to work in accordance with plan. investing in upskilling existing developers who are competent but underperforming may be a better strategy than uber-skilling your best developers or firing them and hoping you can replace them with someone with better ability to figure out how to be productive on the team.
as a humourous aside... at amazon my manager discovered i was prior-service, saying "Oh! You were a MARINE!? I want to manage my team like a military outfit." unfortunately, my response was "WHAT!? You want to spend 80% of your budget on training and logistics!?" that was probably not the best thing to say in that situation.
also... if we're talking about applying military metaphors to product development, it's worth it to look up the various OODA talks by John Boyd. i don't know if i agree with all of it, and it's not directly applicable. but there's enough there to justify at least reading about it. Boyd was a friend of my dad's, so i remember thinking he was crazy when i met him as a child, but again, he may have been crazy, but he was definitely an intellectual outsider who hit more than he missed.
because comparing yourself to your competitors will get you a faster horse buggy, not an automobile. if you're in a startup, you should be risking making automobiles. if you want to make faster horse buggies, go work for AT&T.
Your competitors are not necessarily targeting the same users, and their internal strengths and weaknesses are different from yours. All comparisons to competitors are superficial and distract you from building what your users want and improving upon your internal strengths and weaknesses.
> Intellectual curiosity in the form of hobbies, nerdy interests that they can talk about with passion
Although I know that a lot of people would argue for "what's wrong with doing your day job well and going home to your family, friends, etc?", in my experience, it is also true that the best software engineers I've seen during my 25 year career are the ones that made their job also their passion and hobby. I think intellectual curiosity and being a 9-5 person are inversely correlated, again in my experience.
You can make your job in general a passion/hobby/craft but that doesn't mean you have to work more than your fair share for your employer to be a competent craftsperson.
Your overall opinion might be true, but it's also unfair to competent people who treat it like their day job, and do it competently (but maybe without being amazing).
There is a place for this kind of people, among which I count myself nowadays -- I used to be way nerdier, learning new programming languages and embarking on projects just because, until life got in the way, my interests shifted, etc.
> I think intellectual curiosity and being a 9-5 person are inversely correlated, again in my experience.
I think this is objectively false. I've seen plenty of terrible coworkers -- terrible at their jobs, that is -- who I later found to have hobbies they were passionate about. One was an excellent standup comedian in her spare time. Another did lots of sports and took them seriously. They just weren't very good at software, and they also "phoned it in". One was essentially a "used car salesman" personality, I'm sure he would have excelled at selling used cars! But his code was awful, and he was very combative towards the rest of the team during code reviews, resisted testing his stuff in any way, shape or form, etc. A friend of mine is a middling developer (not bad, but he's the first to admit he's average), but is an awesome guy, funny, and also an outstanding magician.
This reads like someone who has mostly had unskilled managers. The force multiplier difference a great manager can have is immense. I worked so much harder as an IC at small startups when I knew someone had my back and cared about my growth.
As a former engineer at a YC startup from pre-A to post-B, I generally agree with much of this in a broad way if the startup is a technology first one with organic growth or hasn't really figured out product/market fit.
But I think some of the management and team stuff is much more complicated in B2B or B2B2C situations, regulated industries, or cases where there are substantial non-engineering employees, perhaps doing sales, onboarding, or things related to the "offline" world (if there are physical aspects to the business).
In particular, I don't think you can have a super flat eng structure run out of a few docs if eng needs to be working with one or more teams larger than the eng team itself unless there's some kind of separate interface to large outside teams.
If you end up with a significant sales team, account management team, support team, significant numbers of contractors, or other categories of workers because of the nature of the business, you will have to be more regimented about how things are structured. In companies that face this issue, it's often one of their major challenges and not avoidable compared to other kinds of startups - your sales team may have all kinds of ideas and some of them may even be good, and some may even want to sell them before you've built them. And if your sales team is 2x the size of product and engineering... it's not easy to run out of one document. (Note that I don't love or endorse this, but in certain kind of markets and products it seems like a bit of an unavoidable issue.)
I wonder how universal these stages are. All I can say is when I worked at a 15 person company, it was extremely clear to me that we needed more structure than "everyone reports to the CEO". We struggled to prioritize between different projects, milestones weren't clearly defined or owned, at times there would be long debates on product direction without a clear decisionmaker, etc etc.
Not to say the article is so wrong. I think their advice to consider elevating a few engineers into informal tech leads is a great answer. We went with the path of hiring one dedicated "manager" of all engineers and that worked pretty well too.
Depends team to team and founder to founder. I've seen early stage startups where most ICs were able to self manage, but others where some form of structure was needed. At the stage that you mentioned, it's natural for founders to end up hiring an Engineering Lead.
> consider elevating a few engineers into informal tech leads
It is potentially risky - I've seen plenty of talented engineers flounder because they were thrust into an ill-suited management role too soon, but I think if someone is motivated and eased into the role they tend to be superior to an outside hire.
The only quibble I'd have is with "1:1's happen organically and infrequently" - I think this is based on a misunderstanding about what 1:1's are for.
Regular, formal, 1:1's are the opportunity to get above the work and talk about meta stuff - career direction, morale, interpersonal issues, etc. It's the founder/manager's chance to check if the employee is happy and thriving, or if there's something that needs to change.
These sorts of conversations can happen organically, but often don't, and can be awkward if they do happen organically. Getting the awkward out of the way with a formal agenda can really help to get into the guts of it. Rather than having to manipulate the conversation to get to an emotional item, the manager can just flat-out ask the question because it's on the agenda.
Obviously, you can overdo this, and it can turn into a nightmare for folks so I can see why TFA proposes eliminating them. But properly done, formal 1:1's are really valuable even in small teams.
I find a lot of this to also be true with sole engineers managing agents.
I've now seriously approached vibecoding two nontrivial projects, and in each case using "safe tools" was a good way to get to a working stage, faster:
- in one I insisted on typescript early and found it to be more of a hurdle than letting the LLM cobble js learning in and address bugs in a way an engineer might find uncivilized (trial and error over bulletproof typing).
- in another, I found that using react was not offering much benefit to a given project, and asked the llm to rewrite in vanilla. while this mostly worked, it introduced new bugs that were not present when using react. switching BACK to react eliminated these and enabled the LLM to continue writing features at no (current) technical or performance cost!
This is such a great advice overall. Many people are commenting about flaws in the overall approach, yet everything said is exactly what I saw working/not working in such early companies.
i saw that people who wear black turtlenecks are lauded as visionary geniuses, so don't forget to buy some turtlenecks and yell at people on a daily basis.
I used to be very motivated to do the right thing but the culture at my company doesnt reward it and actually actively seems to be promoting bad practices e.g. not documenting. Now I also dgaf.
You dont necessarily need managers but you do need someone to set expectations and keep the team accountable. Otherwise its a race to the bottom. There's no way for me as a single engineer to undo slop faster than its generated.
The author is ignorant, and I mean that literally, not as an insult. They haven’t thought deeply about why some methods of work produce better outcomes, and are still looking at the surface level artifacts. A management function is important for aligning effort, enabling performance, and clearing obstacles. Even if there isn’t a “manager” those functions are still helpful.
Bad managers also exist, and can reduce performance, which can be fatal to a startup. But that’s not a reason to avoid having management functions assigned to employees.
This is all a bit messy to read, but seems TFA recommends against 1:1s and any kind of ticket management or any eng. management all when you have 5-6 engineers and this ... insane.
People need to get on the same page. You don't need to be (shouldn't be) process insane or go SCRUM or whatever to do that. But having regular organized interactions and task definitions is absolutely imperative even early on when you don't know for sure what you'll be doing.
yeah. i think you can get away with no 1-on-1's for small teams (like 4 people) but by the time you're at 6 or 8, it's probably a good idea. i suspect the OP has reason for believing this, so rather than say "they're wrong," i would say "i'm not sure they explained their environment sufficiently to explain their conclusion."
as for ticket management. JIRA is not your friend. i would rather go with a stack of post-its than JIRA. JIRA does not help you understand what you are trying to do (in my experience.) once you've figured out specific tasks, JIRA can track those tasks, but so can BugZilla or (as my teams are using increasingly) text files checked into the repo.
people often confuse the tool with the process and confuse following the process with making progress. the first rule of issue tracking systems is they should not get in the way of making tasks you need to do visible. JIRA routinely violates this rule.
Agree about JIRA. It trends towards TPS Reports and form filling, substituting a workflow in the issue tracker for actual human processes and communication.
We just rolled out Linear, and I'm gauging how I feel about it. GitHub / GitLab issues I don't find useful. Linear seems like a middle ground. And it's nice and fast. It also doesn't seem to let PMs go apeshit with custom fields and workflows, so that's good.
I always crave for something closer to Buganizer we had internally at Google, which was just nice and minimal and not invasive. At least in its V1 form.
As a manager, my job was to make sure they were working on the right thing. If they didn't carry their weight, I either reduced the impact by assigning them necessary-but-boring tasks to offload the high performers, or PIP'd them. I "rehabilitated" several engineers over the years and even gave them references when we parted. Staff that lied to me more than once were terminated.
Series A scripts in Linux, to concurrent 996 work mesh networks.
The Catalogue of Network Training Material refers to specifying READ_ONCE(), WRITE_ONCE().
Did I miss the article mentioning to ask the eng staff how they actually like to work? I get corporate culture and all but engineers like having their subculture and that's fine. As a manager, it's my job to make sure my ppl feel equipped (schedule included) and to keep upper mgmt happy and convinced that it works even if work hours don't match other jobs. So I don't thinly it's ever too soon to hire a manager, as long as he thinks of himself as part of the eng team.
Concerning motivation, you can absolutely motivate people by explaining why their work matters and by helping them with the corp paperwork. Example: engineers don't like SAP, I don't like it either, but the project we're working on is so cool that it's worth the 30min hassle per week and I'll sit with them until they get it.
Do not be a sole founder / tech lead / manager who uses obscure tech or add immediate geometrically-increasing tech debt to be paid almost immediately by others.
> 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 the purpose of standups. When it's async, people just put in what they're working on and mostly ignore everyone else. Standups need to be about 2-way communication, not 1-way.
And retrospectives are about improving how the team works. Every team has challenges of every kind. Retrospectives are for surfacing those and addressing them. They take up a couple hours a week, but the idea is that after several months the team is more productive and it pays for itself in time.
> Organic 1:1s (as opposed to recurring ones): keep them topic-heavy and ad-hoc, as opposed to relationship maintenance like in the corporate world.
Also disagree. 1-1's aren't about "relationship maintenance", again they're about surfacing issues that wouldn't arise organically -- all the little things that aren't worth scheduling a conversation over, but which need to be addressed for smooth functioning.
At the end of the day, managing a team is managing a team. In terms of managing people, it's not fundamentally that different if you're a 10-engineer startup or a team of 10 engineers at a megacorp. These things aren't "anti-patterns" or "rituals". When done correctly, they work. (Obviously, if done badly, they don't -- so if you're managing a team, do them correctly.)
I disagree. In a company of 5-6 total engineers who are actually self-motivated and competent none of these things matter. If you need stand-ups for people to be aware of work being done then you're bandaid fixing a deeper issue. Same for retros since all of that should already be getting communicated in five other ways. If not then you've got bigger issues. Same for 1-on-1s. If the founders don't know these things organically then they have failed either in their own roles or in who they hired. The solution to that isn't rituals.
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.
It has nothing to do with motivation or competence.
Teams don't just work together magically and "organically". They're made of diverse human beings, every one of us, who come from different backgrounds with different expectations about when and what to communicate and when and what not to and around what is who's responsibility when. Different levels of experience, having worked at different places with different practices, and different preferences about how to do things. This is a recipe for a hundred miscommunications and inefficiences and misunderstandings a day.
These processes exist to surface the most important things not being surfaced, and to identify and fix problems that affect the team but which nobody is understanding in full because everyone only knows their own perspective.
Again, these aren't "rituals". They're processes that are proven because they work. Including with 5-6 engineers.
yes and no. "agile" has become doctrinaire and "one size fits all." i miss the eXtreme Programming era where standups, pair-programming, test-first, timeboxing, etc. were all "tools in a toolbox" to be applied as needed. i think the OP is experiencing a world where they're told "oh, here's AGILE. you have to do everything in this book," which i think i would push back on as well.
but... if you're going to do standups and retrospectives... i agree with you. do them synchronously. the idea is to get everyone to listen to everyone else. the reason they're STAND-ups is 'cause everyone's supposed to be standing so there's motivation to keep them short. this often makes it difficult to do "follow the sun" development. i quit a job a couple years back because my management insisted my engineers on the US west coast be included in standups for teams in Pune (India).
and that 1-on-1's are for surfacing issues that haven't come up elsewhere seems like received wisdom among my peer group. it seems to work well for me, so +1 on that too.
the phrase "when done correctly" is doing a lot of heavy lifting here. i bet people who have bad experience with these practices were in situations where they weren't done correctly.
one of my problems with environments where management thinks devs are interchangeable bots motivated only by money is that there is zero motivation for management to change their approach when it doesn't work. if they think the only thing that motivates people is money, they think they have to add more money or fire their devs and get devs that are appropriately motivated by cash.
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.
the idea i am criticizing is, as explained, "motivation" is something which can be managed and throwing more money at engineers is not a universal motivation.
Yeah. This. In 42 years in IT, i saw way too many situations where the last thing engineers need is a "team" or "management," or even worse, an outside "team leader," which usually resulted in the engineer's work or the team's work turning directly into cowshit. "Managers" want to talk about doing a thing; engineers want to actually do the thing, and both cannot happen simultaneously.
When they see results deteriorating, "managers" think the solution is "more management," which is never, ever the solution.
> Motivation is a hired trait. The only place where managers motivate people is in management books.
This seems entirely false to me. To be honest it is so incorrect it significantly puts into question the rest of the article.
1. I have absolutely had managers motivate me to work harder. I have also had managers completely demotivate me and cause me to quit. How on earth can anyone who has worked in the industry for any amount of time say that "The only place where managers motivate people is in management books"?
2. Of course most of the facile strategies mentioned in the article (like 996, micromanaging, etc) won't work. The article then generalizes this to all strategies - but "if terrible methods can't solve it, nothing possibly can" feels like a shaky argument at best. A good manager understands this, and motivates by helping you understand how the things you are doing are actually critical to the success of the team and the company. (If success of the company isn't something you're interested in, then yes, it's going to be hard to motivate you.) A poor manager sabotages motivation in a hundred different ways - he makes you feel like your efforts are totally wasted, or fails to articulate why they are important.
I’ve been working for more than 30 years. I was seriously demotivated by managers, but never motivated by them. The beat I got was protection from them to give me free space to work. But the motivation was always internal.
Being a manager myself, I never got to motivate anybody do anything they didn’t want to. If they wanted to, it worked, but the motivation AFAIK was internal.
Of course that is one person speaking. Milage can vary.
This is a core part of systemantics [0]! People are going to do what they’re going to do, as a manager the most you can do to help is to put people in the right teams and to get distractions out of their way.
It’s a difficult idea to accept but once you accept it, it’s kind of liberating. It follows that hiring and then work-assignments during roadmapping are the two points of highest leverage in making a mutually-successful employee-manager relationship.
The problem you’re solving there is a search problem. You’re trying to discover if the employee’s motivation landscape peaks in any dimensions that align with the roadmap. They can be the most skilled person in the world, but if the peaks don’t overlap, the project will never run smoothly. It also follows that in extreme cases where you have a tenured employee that you want to retain for future work, you should absolutely let them drive and shape the roadmap.
[0]: https://en.wikipedia.org/wiki/Systemantics
1 reply →
You're making a nuanced point but it's correct. Good managers can give a little motivation (mostly by talking about and finding the right areas to work on for those people that don't otherwise already know). But for the most part good management is buffering the core that allows individuals own motivation to be self-sustaining (and productive over time) and also making sure that people aren't on a path that won't be useful (i.e. the manager knows the company will never fund phase 2).
12 replies →
I want to hazard a guess that a motivational manager is just like a well-oiled cog in a machine. You essentially never notice them as having influence over your motivation and only pay attention to the squeaky and rattling and faulty ones.
2 replies →
>> I never got to motivate anybody do anything they didn’t want to.
I'd be willing to bet that as a manager you've gotten people to do the shit work no one wants to though, mostly by explaining why & how it's important, sharing it across the entire team, working to eliminate dumb parts of it and stepping in to do some of it yourself - and yes, occasionally assigning it directly. To me, that's motivation: sustainably coordinating energies in a shared direction for the greater good.
I think you can indirectly motivate, or is that something else? If you create a good working/team environment and reduce the factors that demotivate people, then you will indirectly motivate them. This includes working on yourself as a manager. There are of course edge cases, but most people will thrive if the environment is good.
1 reply →
> A good manager understands this, and motivates by helping you understand how the things you are doing are actually critical to the success of the team and the company
Your definition of a "good manager" is essentially "does not actively sabotage work of subordinates". That's not motivation, that's merely absence of active demotivation. A person knowing how and in what ways their work contributes to the success of the unit and the whole are absolute basics and if a person is not aware of those either their manager is incompetent as hell or actively hostile.
Reminds me of those job ads where "benefits" section contains gems like "salary paid on time". That is not a benefit, that is such a basic that even mentioning it puts into question everything about such company.
Disagree. This is explicitly active: "helping you understand how the things you are doing are actually critical to the success of the team". It could include building out a team dashboard that tracks the consequences of bugfixes, for example.
2 replies →
Not really? At a small startup, sure, this should be obvious, but a manager who is able to articulate how my work bubbles up to company success at a 1000 eng company, in a way that makes sense, is a pretty rare breed.
> Your definition of a "good manager" is essentially "does not actively sabotage work of subordinates".
This is not even remotely what that person said. They said "motivates by helping you understand how the things you are doing are actually critical to the success of the team and the company". That is not nearly "does not actively sabotage".
> A person knowing how and in what ways their work contributes to the success of the unit and the whole are absolute basics
Oh please. If you reject every single thing good managers do to motivate people as "does not count" then of course you will end up with nothing. It is super easy to not see how this or that contributes to the success of a thing. It is also possible to be in position where you are in fact not contributing to the success - while you created an illusion in your head about how important you are.
2 replies →
I'll agree with you that the author tried to put in a sound bite and it failed to clarify the author's point.
The author is trying to argue for hiring early engineers who have exhibited ownership values and who want to take ownership for their work. These are the people for whom you establish "extreme transparency" (see: late in the post), a Google Doc for them to help align with others on high-level plans, a kitchen for people to informally talk in, and then get out of their way. That kind of environment is indeed in and of itself quite motivating for a certain kind of engineer.
Of course, it doesn't scale to BigCorp-size. Eventually you have too many cooks in the kitchen. The truth is that the vast majority of engineers really do want someone to tell them exactly what to do, so that they can come in to a highly structured 9-5 job and earn a paycheck that pays their mortgage and feeds their family. Author's prescriptions do not apply to large companies or to most engineers, and Author makes it clear as such.
I have experienced both.
I d argue its not the manager that motivates people that can only be found inbooks. Its the manager that can come in and mend a toxic and dysfunctional team.
The toxic teams end up breaking good managers in the end and they either become part of the problem or leave.
The hero manager described in the phoenix project is a myth.
The motivational one imho is very real but they need a good platform just like everyone else.
In my experience, no manager can fix a toxic, dysfunctional team.
That team is doomed and the best course of action is to disband it and let the worst people go.
I've only experienced de-motivation from managers, personally. At least for me, motivation comes from ownership, impact, autonomy, respect. You can cause me to lose motivation in a lot of ways, but you can't really cause me to gain motivation unless you've already de-motivated me somehow.
You can de-motivate me in a lot of ways, some examples:
- throwing me or a coworker under the bus for your mistakes
- crediting yourself for the work of someone else
- attempting to "motivate" me when I'm already motivated
- manufacturing a sense of urgency, this is especially bad if you try to sustain this state all indefinitely
- using AI or market conditions as a fear tactic to motivate the team
- visibly engaging in any kind of nepotism
Honestly this list could go on and on, but those are some that come to mind.
> manufacturing a sense of urgency, this is especially bad if you try to sustain this state all indefinitely
Sadly, I have seen this in almost every startup led by founders without an engineering background I've ever been a part of.
In my personal experience, this is often caused by overeager sales team promising the world for the next deal, only to fob it off to the engineering team who now "urgently" need to build "features" and "work hard" to make it happen. This is when your intrinsically motivated engineers start looking for the exit.
Also:
- not letting me have ownership of what I build and dictating features
- not giving me autonomy of how to solve a problem
The point is that the 'maximum motivation level' for an employee is an inherent trait. It is a ceiling. Some people have high ceilings and some don't. If an employee has a low ceiling, no manager can motivate that employee higher.
But if someone has a high ceiling, the most a manager can do is create an environment that allows the employee to achieve their max potential. A bad manager on the other hand, can very easily bring a normally high-potential motivated employee down to mediocre levels.
If you are one of those self-aware leaders that knows how to create an environment where people can excel, then hiring highly motivated people is the winning strategy.
The author seems to lack any sort of understanding of motivation beyond some sort of vague, blackbox "fire in the belly" concept. This is definitely not true. My take aligns with yours: motivation is a vector, having both magnitude and direction. You want individuals with the fire and then somehow need to figure out how to direct the combined heat. In the earlier stages of an externally-funded venture this is the difference between building a jet engine and pouring gasoline on a campfire. I agree you don't need a manager to do this, but also feel strongly that by the time you're at multiple teams your CTO-founder is also the wrong person. They're probably a core developer who earned the title with limited experience; don't make them learn how to manage a dev team's day-to-day while they also learn every aspect of engineering management. I wish every CTO started as a team lead, but in this scenario it's too late. CTOs largely lead the parade, but you're devs need a servant-leader in the trenches who can articulate from the front, constrain the sides and push from behind.
A lot of those books are more about persuasion than motivation - they can look similar from a distance.
The author seems to be thinking of word "motivate" in the way that someone in the olden days would motivate a donkey - with a whip. Every example they're listing is not "motivation", it's effectively forcing additional work and hours. No motivation is happening there.
It is.
Motivation is a whimsical thing.
As a lead or mgmt I set my highest priorities to:
(a) make sure that the goals are set to stone and crystal clear
(b) the team can do their work without any unnecessary distractions
(c) try to remove some of these "necessary" distractions as well
It can be really hard. And it can very ungrateful. I aim to be a nightwatchman, and I'm really proud of myself when the team thinks I'm getting paid for nothing. The bigger the structure the bigger the drama and I don't want them to be any part of it.
Meanwhile I struggle with stakeholders who are like "c'mon, you already build the skyscraper, we just want you to move the parking lot from the underground to second story, how hard can it be, you have all the parts in place, just move them around".
So what did those managers do to make you more motivated?
In addition to what the other responses said:
1. Share a cohesive and inspiring vision for the project.
2. Understand your skills, strengths/weaknesses etc and try to give you work that challenges you / help you grow / are interesting.
I think these are rare and can be hard to do (I'm now trying to do it myself!), but when it happens it's very motivating.
Cared about anything other than their own upward movement, actively worked towards my professional development, made sure I had actual, not hand wavey, feedback, and made sure my compensation reflected my growing responsibility.
I am aware that all of those things may not be in their power to give, but some combination of that in any org that is somewhat functional would be motivating.
I have read the sibling comments here and it is so saddening. The general expectations for management are, apparently, so low, that a manager attempting to do some duties in their job description is lauded as some savior. <crying-cat.jpg>
I had one manager who got extremely excited about whatever you were working on. It was infectious and motivated most of the team including myself. He’s an innately curious person, but also whip smart and surely developed this skill deliberately.
I had another boss, a founder, who had a difficult relationship with engineering but was extremely gifted and had a great vision. I found myself highly motivated at this company as well, but for wholly different reasons. There are many paths to success.
Both startups had successful exits, and I felt as though I contributed meaningfully to both.
Treat me like a human being, work with me to set reasonable expectations, share blame and focus praise.
> 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 daily standup? What happened in these years for such a change to happen?!
[1]: https://news.ycombinator.com/item?id=19507620
Former Alibaba employee for a season of my life. I have to be careful with my next sentences because on the internet because it's easy for people to read things in a vacuum and interpret in the worse possible way, so don't do that because thats not how I mean it. The 996 hours are not useful work. It's appearance over productivity.
Yep, if you were to watch what happens at a 996 shop, it's people literally living their at-home life with their fellow employees for most of the time.
2 replies →
I've worked with a few coworkers who came from a 996 environment and kept doing it out of habit. As I was young and impressionable, I started doing it also. I'm not going to be careful with my sentence: these people were absolutely NOT getting more work done than others, in fact they seemed to move glacially, because they had so many more hours to fill up. It's a total footgun, and it chases away good people once the rot reaches management and they start promoting based on perception rather than reality.
1 reply →
The mythology is:
- 30 people between the ages of 18 and 25 sharing a tiny, single office room working on folding tables and CAT 7 cables hanging from the ceiling
- Whiteboards from floor to ceiling on every wall covered in scribbles and diagrams in red, black, and blue pen, half-erased with some "SAVE FOREVER" circled parts
- Typing really fast on loud, clicky keyboards
- Doing nothing but coding or working 18 hours/day with no life at all
- Living at work in sleeping bags
- Surviving on cold delivered pizza, hot instant ramen, and coffee with only a mini fridge, a microwave, and a coffee pot
- Spending absurdly little money on everything
The problem is that if even one gigabusiness began vaguely in such a manner, someone will declare some aspect(s) were "essential" and try to cargo cult the "hard work" pseudo-signals without considering sustainability or that it's even necessary. There are far too many engineers who will overwork themselves until they reach burn out or will not maximize real productivity by working less and taking breaks/vacations, and then won't want to work on a venture at all anymore.
PSA: Don't be a sucker and don't work for below market rates. Eschew working for other people and megacorps when possible; form unions, worker-owned co-ops, and/or get significant amounts of preferred liquidation-preference shares.
It’s better to look at what didn’t happen: unionization.
Americans often remind me of Steve Jobs trying to cure cancer using diets & acupuncture. You know what the solutions are, you just don’t like them.
Until recently American engineers made a lot of money at comparatively cushy jobs. A decent engineer in the US could make 5x their equivalent in most European nations. Staff+ engineers at FAANG could make 5x that. People in a good position tend to not like rocking the boat.
84 replies →
There are unionized engineer jobs in the United States. Every time this conversation comes up people act like we don’t have any unions, but that’s not true. There are unionized engineering jobs.
One of them even tried striking a couple years ago, quite publicly. They ended the strike a couple days later without gaining anything.
I think American engineers know their situation and options better than you think.
Exactly how do you think unions would help for tech workers?
Unionization does not happen because it's typically anti-immigrants. It's an unworkable solution, and liking it will magically make it work.
1 reply →
Steve Jobs was also an expert at suppressing software engineering wages. Karma has a funny way of coming around.
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.
6 replies →
> And now, the strongest claim this blog can make is that some engineers in the US would disengage from recruiting?
The statement was specifically about top 1% engineers in Silicon Valley. That’s a very, very small subset of all engineers in the US.
The pointy end of the talent spectrum in SV is a very weird place because it has had a lot of engineers for whom work is life. Living at the office and having coworkers working 24/7 might be something they like.
I’m not condoning this or saying it’s common. It’s not common. However, once you narrow down to the extreme outliers in the long tail of talent distribution you will find a lot of people who are downright obsessive about their work. Their jobs also pay north of $1mm including equity, so spending a few years of their life 996ing on a topic they love with energized people isn’t exactly a bad deal for them.
In general, if a recruiter told an average engineer that 996 was expected that would be the end of that conversation. Average US engineers are not signing up for 996 for average compensation.
I am this person (not a genius or whatever) but work is absolutely life for me. I still absolutely resent the 996 culture and would never do that. I'd like to have agency when I want to abuse myself
The fact that 996 is coming to America is an ill omen for worker's rights and, well, society in general IMO.
What happened? Started with Musk purging half his staff ...
I've been around long enough in this industry to see the pendulum swing back and forth a few times. The peak of 2020/2021 was the epitome of "spoiled tech worker" but now we're well on our way the other side, I'd say.
[dead]
Sentiment is changing
If you had enough time to look back through my post history, you’ll find back in 2021 2022 I was loud as hell Screaming from as high as I could on this board primarily that we need to be doing everything we possibly could do to unionize, build labor cooperatives etc. and absolutely nobody gave a shit.
I would get roasted every time and that’s fine I know what I’m doing.
but the attitudes are changing and while it’s frustrating to have to deal with that I feel like being a Hector on this topic is just the entry fee.
I’m extremely dissatisfied at the pace and scale and lack of leaders and organization and push back and etc… so I expect the next two years to be really really really bad and the hope is that people wake up at a large enough scale that they actually are able to affect something but I don’t have a lot of hope for that.
What I describe is not real activism imo but at least I can tell you from first hand documentation that sentiment is changing.
"I know several top 1% engineers in the Valley who disengage from recruiting processes when 996 or something similar is mentioned."
Setting this expectation early seems honest and the best thing to do. The worst is when companies sell people on WLB but then flip it to 996 -- you end up with all the wrong people and no one wins. Best to be transparent from the onset.
I always encourage candidates to go visit the company several times if possible, including a visit at 5:30pm or 6:30pm to see the state of the office and attendance. There is no right or wrong answer --
> including a visit at 5:30pm or 6:30pm to see the state of the office and attendance
As an academic, I used to work 11am-8pm many days when I was younger thanks to flexible working hours, and I wasn’t the only one working late but not early. I realize this is probably more rare in corporate settings, but keep in mind if the place has flexible hours you might see more people at 6pm despite people not doing 996.
I think that is great if you want flexibility, and I used to do that also!
What i'd assess at 6:30 is whether people are on meetings or on focus time. If you have monitors with zooms full of 5-6 people, I wouldn't think that is flex hours, i'd assume that is a meeting being scheduled at 6:30.
On the other hand, if you have people focus working, you cannot draw any conclusions from that.
Personally, I stay at work late. But there is a difference between me being obsessed with a problem and working thru the evening trying to solve it (awesome for me) vs meetings that are being scheduled at 6:30pm or 7pm
That was true of me as well, and at the same time, I was working alongside parents who worked 7:30-5:30 with a break to pick up the kids from school.
Nobody wants a "visit" from the founder, anyway. They want timely two-way flow of information, access and guidance on the occasions when they need it, and maybe (maybe) an occasional chance to hang out socially as a group with no reference to work. Nobody wants the founder randomly dropping by during work hours to assess morale.
This is really my priority to achieve at a job, and one of the reasons I try to be good enough to be indispensable is to be allowed to roll in in the morning whenever I get there.
I have a very tough time in the morning convincing myself to go to work, and a very tough time at work tearing myself away from something in an intermediate state. Things at work are always in an intermediate state at 5:00, unless you stopped working well before then (or got very lucky), so I always end up working late whether I come in on time or come in late.
So I'm always trying to get to the point where management lets me get there when I get there, and trusts me to be productive. It's a mental thing. I get up early and do a lot in the morning; I'm a morning person. Maybe too much so. The time between getting off work and going to bed is garbage time for me; a long annoying commute and a meal. When I leave at 5:00 I just fall asleep by 9:00.
Glad I live somewhere that I had to look up 996 because I didn't know what it was.
> 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.
Yeah this 100%.
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
we used to say "employees don't quit jobs, they quit managers." i was very happy at Amazon until they moved me under a sub-optimal manager. i quit less than a month later. that manager got promoted. this will tell you everything you need to know about working at Amazon.
maybe they were trying to get me to quit. maybe that area's director was incompetent. maybe both.
Do managers ever get fired or fail? All of my worst managers seem to keep moving up the ladder from what I see on LinkedIn. I don't understand it.
4 replies →
A bad manager can turn a great employee into a good one. It’s really hard to go back once that happens.
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.
2 replies →
“ It’s very easy to demotivate people”
So true. And really hard to reverse
I may not be using the same definition of "motivation" as the author, but understanding what motivates your people, putting the right mix of people together to work on the right problems, and knowing how and when to apply pressure to get people to do their best work are absolutely something managers can do to motivate their teams.
Yep people have all sorts of sources of motivations. One of the key ones is a sense of ownership. Many people join startups instead of BigCorp because they want voice and influence that they don't get in a larger company. I've seen so many founders, managers, leaders, etc kill that by not recognizing this fundamental fact.
Of course there's also the problem that you can find and hire people who are motivated people but there's absolutely no guarantee people are going to be motivated for your specific problem.
thank you. can i hire you to run one of my teams? i've been trying to explain this to my managers for half a decade.
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.
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.
1 reply →
We're apparently back to making psychoanalysts out of interviewers:
I'm pretty confident that this doesn't work, and that searching for "intellectual curiosoty in the form of hobbies and nerdy interests" is actually an own-goal, though it's a great way to keep your Slack channels full of zesty, nerdy, non-remunerative enterprise during the core hours everyone has to actually ship code together.
10 years ago I bought into the idea of hiring for nerdy interests and hobbies as a proxy for motivation. I will say I met some excellent people during this time, but looking back those same people would have been hired anyway due to their accomplishments at companies.
> though it's a great way to keep your Slack channels full of zesty, nerdy, non-remunerative enterprise during the core hours everyone has to actually ship code together.
Spicy take, but that's 100% consistent with my experience. Hire a lot of people for their nerdy interests and hobbies and your company comms become full of chatter about nerdy interests and hobbies. Meanwhile the "boring" people who ship code and then go home to their families (or pets, or anything) are trying to ship code and get the job done.
Nerdy interests and hobbies is not a good proxy for work ability. Hiring someone primarily for nerdy interests and hobbies is probably a red herring. Focus on what matters.
>10 years ago I bought into the idea of hiring for nerdy interests and hobbies as a proxy for motivation. I will say I met some excellent people during this time, but looking back those same people would have been hired anyway due to their accomplishments at companies.
>Nerdy interests and hobbies is not a good proxy for work ability.
Aren't you actually describing a great proxy?
1 reply →
So do you think there's no useful strategies to identify highly motivated prospective employees, or just that these aren't good ones?
I'm not optimistic about scalable strategies to identify "motivated" employees, but I'm not certain. I am pretty certain these strategies are bad. They're what everybody did in the mid-2000s.
2 replies →
> 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 defined ownership boundaries. That means business process and workstream ownership, not code ownership.
My rule of thumb is that management complexity is given by #direct reports x #project, where project is defined as a set of stakeholders (be it PM, etc. depending on business).
Concretely, managing 12 ICs on a well defined platform team w/ a single PM is much easier than managing 6 people working across 6 businesses, as is more common when managing a team of data scientists.
+111111
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.
it's worth reading Mythical Man Month WRT team composition. not because Brooks says anything new about the subject, but to get perspective on how long people have been trying to find a good idea for how to structure teams.
Yup, 15 is just too many. I think that 10 is already pushing it, depending on how many projects are going on at the same time.
It sounded good, up until the examples for:
> I'll dedicate a post to specific ways you can identify motivation during hiring, but in short, look for
All will be gamed by interviewees, by the afternoon this hits the HN front page.
(And, for example, tech interview prep has already been telling people to fake passion and curiosity, for many years now.)
Here's what you do:
1. Consider that the early startup also belongs to the early hires. It's their startup too. You're the last-word decider, but it's not only your startup. You want it to also be theirs. Believe this, and act like it.
2. Reflect that in the equity sharing. "0.5%", to be diluted, as options, with ISO rules that discourage exercising at all... while co-founders divide up 70% of founder real shares between themselves... is nonsense, for that founding engineer, who you should want to be as motivated as you, and contributing as much as you do.
3. With equity like you're serious, make the salaries low-ish. Not so low that it's nonviable for modest family cost of living, but low enough to self-select out the people who aren't committed to the company being successful, or who don't actually believe in the company.
4. Have an actually promising company and founding team, or you won't get many experienced people biting.
I'm quite cynical, but all this sounds fair to me.
Modest compensation with good equity sharing is hard for candidates to game too.
I think what people miss about indexing on social signals is that convincing social performance is hard. My suspicion when people say things like "ah but if you index on a social signal then everyone will just perform the social signal" are themselves feeling as though they do not naturally signal that thing, and ironically are frustrated by the effort that it takes to appear as though they do.
Why is that your suspicion?
The context on this one is that we've gone from an environment in which kids were mocked for having curiosity and passion about nerdy things like systems, and it didn't pay that well as an adult, and those people would go home at the end of the day and also write open source code...
To one in which it's now a high-paying career, and a bunch of interview prep manuals coach on faking that, doing open source to promote your career, etc.
So if OG nerds look around at the environment and see the dynamics, of people who just want well-paying jobs (nothing wrong with that) seeming to do a performative dance with interviewers who also just want well-paying jobs (nothing wrong with that), and everyone is being told to project passion and curiosity (when they really just want well-paying jobs) and to look for it in others...
You think the problem is that OG nerds, for example, feel that they do not naturally signal that?
They may signal that just fine, but merely be questioning all the performative theater by people who aren't here for that, but some management fashion told them they should pretend to be.
The whole thing about motivation is non sense.
1. Motivation is a feeling, it's an emotion, it comes and goes, it's a bonus. It's discipline and professionalism that make the huge difference. Many people have the motivation and dream to "create their own programming language", "launch their startup", "make it to the NBA", "lose 40 pounds and get fitter" but this motivation, a feeling, will consistently fight the emotions telling you to have fun, relax, go out with friends, play video games to relieve stress. Motivation is a great boost to discipline and professionalism, but those two survive even when motivation goes off, whereas won't take you anywhere.
2. You cannot hire for motivation and if you're looking for that trait you'll likely projecting your own biases. I suspect that the author of the blog post has nerdy hobbits so he projects himself on candidates. Non sense. Yes, nerdier engineers are likely more interested in the craft and in overall engineering, but that says absolutely nothing about them being motivated in building yet another B2B SaaS.
3. A very good engineer joining a startup, should have the implicit motivation of wanting to get rich in few years, otherwise he/she's be joining a cushier job that pays better.
I disagree. Motivation is not just an emotion but an inherent desire. For a motivated engineer the balance between the work with pleasures and dreams is already won and pre-balanced for sustainable achievement.
I find the work itself rewarding and I find world improvement results reinforcing of my enjoyment. I want to code and I'm happy to direct that energy largely according to my employer's needs and our shared benefit. I can be given high level directives and refinement feedback over time. My observed results are faster, more effective progress as reported by internal and external stakeholders. I haven't minded becoming wealthier but it was never my primary motive.
As you note, there are other approaches.
> Motivation is not just an emotion but an inherent desire
Desires change as we grow up and life changes us.
The people you hire today, aren't going to be the same 3/6/9/12 months from now when a parent gets sick, a partner leaves, a child is born, when something suddenly changes their priority, etc.
1 reply →
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'm in EU and I can't agree this describes most engineers.
Overwork culture is also present here and exploited by a lot of companies.
I second this. On paper Austria has below average working hours in EU statistics but I've seen a lot of overwork in the tech companies I've been at by some people, but which was never officially reported because the workers themselves just went along with it.
Scandals in the papers around the crazy hours workers at big-4 consultancies in Vienna typically do, which again went unpunished by labor agencies, since there were no written orders from management imposing those long hours but workers just tactilely accepted it as part of the work culture there.
Similarly, a mate of mine at major finance gig in Frankfurt noticed that they were working longer hours than their colleagues from NY. Heard similar stories from colleagues from Italy and France.
So work hours are super dependent on local culture and industry. The meme about everyone in the EU being paid to slack off all day is not as common as people imagine, unless maybe you work for the government or got lucky to score a great gig in some dysfunctional monopolistic megacorp.
I've found in (EU) academia at least that people essentially lie about how much work they do. In anglosphere it's far more common for people to be open/expectant of 80 hour weeks etc. Probably the lieing approach is better for society/culture.
not everyone in the states is 996, but yeah, there's a pandemic of bad management here. or rather... not so much bad management... but management by people who read articles about how Amazon, a company with tens of thousands of engineers, manages projects and then decides they're going to manage their startup of 4 people the same way because they think it's a "growth hacking" hack.
just keep in mind that American tech startups are often just vehicles to evade estate tax. and certainly vehicles for converting VC money into more VC money by selling dreams to greater fools. there's also a down side.
Which is why fewer and fewer companies are hiring in Europe.
And why people are jumping out of buildings, actually and metaphorically, in 996 cultures.
6 replies →
I'd say the exact opposite. engineering is markedly being outsourced to europe.
2 replies →
Are they? Do you have a source for that? My impression is that it's easier to find engineering work in Stockholm than in silicon valley atm, but I haven't measured objectively.
10 replies →
Don't get the wrong impression from this article. 996 is exceedingly rare in the United States.
Most engineers in the US work normal 40 hour work weeks, too.
How does this work though? Do you have around 4 hours worth of work you report on? Are you paid for more than 4 hours? I’m so curious when people throw completely alien statements like this out like it’s something that doesn’t even warrant explanation.
I freelance. Occasionally I get called by former clients to work on legacy systems I was lead on. And I have some support tasks for former clients.
For one company I log on once a month, I start a Renovate process which generates pull-requests for updated dependencies. Patch-versions get auto-merged after tests succeed, minor and major need approval of the current lead. Sometimes I need to manually tweak the code a bit because of API changes or to get tests to pass. I'm allowed to bill them four hours on it regardless of actual work, which is between five minutes (no manual intervention required) and two hours (need to rewrite some code).
For another company I create a report once a month for all outages and which errors frequently show up in logging. I automated this to be a five minute task and it generates a Wiki page. I review the page to see if everything is ok. I bill an hour on this.
The company is happy to not have to allocate engineer hours on maintenance so they can continue pumping out new features.
I'd say that on average I work 4 hours and bill 12 hours. This is comparable to the income of someone in employment working around 24 hours. But I do run a significant risk obviously.
>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.
1 reply →
You don't have to work at an early stage startup - in fact most people don't. But some people do wish to participate in an early stage startup, and plenty do in Europe as well.
> So you have a good work/life balance. I currently work 4 hours a week.
And this is why when I was a PM, we shut down our Amsterdam office and shifted it to Praha, Bucharest, and Warsaw. You won't find as many people who will complain about a 40 hour workweek while earning €80k TCs
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.
11 replies →
Working more hours however =/= getting more done. In fact, some experiments show the opposite (within boundaries of course).
3 replies →
> But some people do wish to participate in an early stage startup
You don't need to push yourself into burnout as an employee in order to participate in an early stage startup.
> earning €80k
80k€ gross is not a lot for a decent SWE in western europe. The reason people complain in Amsterdam is not the hours, it's that your comp is shit.
2 replies →
4 is very low. Kind of an outlier.
I guess either you have wealth, very low costs or a great hourly rate, or you are the one person who got that Tim Ferriss book to work.
I think its clearly false that motivation is an inherent trait. That would imply that demotivation is also inherent, which I think is even more obviously wrong.
I think demotivating people is incredibly easy, see any Dilbert cartoon featuring the PHB ever.
That doesn't mean that motivating people is also easy. They're not equivalent.
Motivating people requires understanding their psychology, their values, what they want from their life, etc, and then applying that knowledge to create a workplace culture that feeds all of that. Demotivating them just requires not understanding any of that, or ignoring it in favour of feeding your own ego or psychology. It's a lot easier to demotivate.
Certainly it's easier to destroy than to build but if you tell yourself "my teams motivation is entirely intrinsic" you might, for example, think you can abdicate the duty of removing demotivations.
Ah yes the workplace culture, psychology angle. I would expect to read that on Linkedin, not here.
No, motivating people simply requires giving them more money (performance bonuses, stock options, thirteenth salary/end-of-year bonus...). DUH. OBVIOUSLY.
People in management positions always try to weasel their way out of paying their people more. (Well, not always, not all of them do, but you get my point.)
Unless you work on truly cutting edge stuff (by which I mean the likes of SpaceX and its equivalents in different industries), motivation is money.
It's as simple as that. No need to twist yourself into all kinds of pretzels.
No, it's not the coworkers (which, by the way, are not your friends unless you meet outside of work), it's not the job as such (very few people outside of art actually enjoy doing their job as an activity after say 10 years of doing it), it's money.
Money is the primary motivator (by far). You work for money. End of story. Anyone saying otherwise is a bs artist.
1 reply →
It is better to divide motivation between intrinsic and extrinsic. Intrinsic comes from within and is probably best explained as an inherited personality trait. Extrinsic comes from external factors, usually money and rewards, as well as positive feedback. Demotivation is most probably a result of poor management (leaving aside mental health issues).
it's not hard to de-motivate people. but here's the thing... not everyone is motivated by the same thing. the trick of motivating people as a manager is spending the time to figure out what motivates them.
and if you could only de-motivate people, eventually everyone in your team would be de-motivated.
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.
Hire good people and trust them, they will build the best they can for the users they can talk to
If you don’t know what good people look like you can’t win.
The biggest thing is trust, in just about any relationship. The truth is, I think, most people are very well meaning and highly ambitious. It's disillusionment and distrust that creates the rift.
People want to work hard and they want to do good - but they're scared. They're scared that working hard will only be to their detriment and, well, can you blame them? When managers create an almost adversarial relationship, it can feel like doing your best is setting yourself up for failure.
And pay them well. If you want people to build you a thing that prints money, you better give them a sizeable cut. Otherwise enjoy "market rate" performance.
If you need motivation, maybe the organization is designed badly.
It was once said of the Roman legions "The Legion is not composed of heroes. Heroes are what the Legion kills." Field Marshall the Viscount Slim, who commanded in the China-Burma-India theater in WWII, once wrote "Wars are won by the average performance of the line units." He wrote negatively on various special forces type units, preferring to use regular infantry and training them up to a good, but not superhuman, standard. Arthur Imperatore, who had a unionized trucking company in New Jersey, is profiled in "Perfecting a Piece of the World" (1993) for how he made his trucking company successful despite a very ordinary workforce.
There's an argument for winning by steady competently managed plodding. The competently managed part is hard. Steve Bechtel, head of the big construction company that bears his name, once said that the limit on how many projects they could take on was finding bosses able to go out to a job site and make it happen. Failure is a management problem, not a worker problem.
This post is talking about very small companies. At that 20+ person department, it's true. Once you have a team where the founder doesn't know everyone, the average matters a lot more.
If you have 15 people, you can hire 15 people and they will be able to organically organize if you hire well. If they have a question, they know what everyone is working on. The code base is small enough that everyone can just figure it out even if the documentation is bad.
The larger that group is, the more effort it takes to make sure everyone has the context they need to get their job done. That's where management matters.
And honestly, when I was the first manager (team of 17) brought in, I was writing code and on my own project in addition to starting to build up the "what do we need to do to scale?" You bring someone like me in at 17 people because you're going to need to scale soon and someone needs to build the first set of processes that solve the problems of the next stage, and figure out the onramp because done wrong, they make everything worse.
Hiring well is extremely hard.
in the military we had a saying "you don't go to war with the army you want, but with the army you have." consequently, there was a lot of effort given to training and planning. the nature of most combat arms roles is such that you need most of the team operating at a decent level. i think the idea behind so much training is that if you can raise the performance of the worst performers, you might be able to improve the overall unit performance dramatically.
to put it in marketing manager speak, for many tasks in a combat arms unit, individual performance is a satisfier, not a a delighter. if one person in the unit does a bad job, the unit will fail. if everyone in a unit does an "okay" job, the unit will not fail. the outcome between the two cases is dramatic. but if you have a unit where everyone is "okay" and then expend effort to make everyone in the unit exceptional, you will not notice a concomitant increase in performance.
flipping this over to software development... you have a lot more control over whom you hire to be in your unit. but everyone has a bad week or a skills gap, so training (which could be as simple as giving people time to read up on a subject or write a few test programs) will eventually be important. like line military units, everyone needs to be hitting on all cylinders for the dev team to work in accordance with plan. investing in upskilling existing developers who are competent but underperforming may be a better strategy than uber-skilling your best developers or firing them and hoping you can replace them with someone with better ability to figure out how to be productive on the team.
as a humourous aside... at amazon my manager discovered i was prior-service, saying "Oh! You were a MARINE!? I want to manage my team like a military outfit." unfortunately, my response was "WHAT!? You want to spend 80% of your budget on training and logistics!?" that was probably not the best thing to say in that situation.
also... if we're talking about applying military metaphors to product development, it's worth it to look up the various OODA talks by John Boyd. i don't know if i agree with all of it, and it's not directly applicable. but there's enough there to justify at least reading about it. Boyd was a friend of my dad's, so i remember thinking he was crazy when i met him as a child, but again, he may have been crazy, but he was definitely an intellectual outsider who hit more than he missed.
I'd like to add to this, only because it is an early stage item but maybe a little unrelated:
If you are an early stage startup and your founders have a habit of talking about "competitors", run like hell.
+1. and if they say things like "we're going to disrupt the industry," again, run.
There were many things I did not like about working for Jeff Bezos, but one I did like is he kept repeating this.
> If you are an early stage startup and your founders have a habit of talking about "competitors", run like hell.
Why? Comparing what the competitors are doing can be a great way to come up with new ideas
because comparing yourself to your competitors will get you a faster horse buggy, not an automobile. if you're in a startup, you should be risking making automobiles. if you want to make faster horse buggies, go work for AT&T.
5 replies →
Your competitors are not necessarily targeting the same users, and their internal strengths and weaknesses are different from yours. All comparisons to competitors are superficial and distract you from building what your users want and improving upon your internal strengths and weaknesses.
[dead]
Why
Scarcity mindset.
> Intellectual curiosity in the form of hobbies, nerdy interests that they can talk about with passion
Although I know that a lot of people would argue for "what's wrong with doing your day job well and going home to your family, friends, etc?", in my experience, it is also true that the best software engineers I've seen during my 25 year career are the ones that made their job also their passion and hobby. I think intellectual curiosity and being a 9-5 person are inversely correlated, again in my experience.
You can make your job in general a passion/hobby/craft but that doesn't mean you have to work more than your fair share for your employer to be a competent craftsperson.
> that doesn't mean you have to work more than your fair share for your employer
I would never argue for that. My meaning was more about having a passion/hobby in the field that you are working in.
Your overall opinion might be true, but it's also unfair to competent people who treat it like their day job, and do it competently (but maybe without being amazing).
There is a place for this kind of people, among which I count myself nowadays -- I used to be way nerdier, learning new programming languages and embarking on projects just because, until life got in the way, my interests shifted, etc.
> I think intellectual curiosity and being a 9-5 person are inversely correlated, again in my experience.
I think this is objectively false. I've seen plenty of terrible coworkers -- terrible at their jobs, that is -- who I later found to have hobbies they were passionate about. One was an excellent standup comedian in her spare time. Another did lots of sports and took them seriously. They just weren't very good at software, and they also "phoned it in". One was essentially a "used car salesman" personality, I'm sure he would have excelled at selling used cars! But his code was awful, and he was very combative towards the rest of the team during code reviews, resisted testing his stuff in any way, shape or form, etc. A friend of mine is a middling developer (not bad, but he's the first to admit he's average), but is an awesome guy, funny, and also an outstanding magician.
This reads like someone who has mostly had unskilled managers. The force multiplier difference a great manager can have is immense. I worked so much harder as an IC at small startups when I knew someone had my back and cared about my growth.
As a former engineer at a YC startup from pre-A to post-B, I generally agree with much of this in a broad way if the startup is a technology first one with organic growth or hasn't really figured out product/market fit.
But I think some of the management and team stuff is much more complicated in B2B or B2B2C situations, regulated industries, or cases where there are substantial non-engineering employees, perhaps doing sales, onboarding, or things related to the "offline" world (if there are physical aspects to the business).
In particular, I don't think you can have a super flat eng structure run out of a few docs if eng needs to be working with one or more teams larger than the eng team itself unless there's some kind of separate interface to large outside teams.
If you end up with a significant sales team, account management team, support team, significant numbers of contractors, or other categories of workers because of the nature of the business, you will have to be more regimented about how things are structured. In companies that face this issue, it's often one of their major challenges and not avoidable compared to other kinds of startups - your sales team may have all kinds of ideas and some of them may even be good, and some may even want to sell them before you've built them. And if your sales team is 2x the size of product and engineering... it's not easy to run out of one document. (Note that I don't love or endorse this, but in certain kind of markets and products it seems like a bit of an unavoidable issue.)
I wonder how universal these stages are. All I can say is when I worked at a 15 person company, it was extremely clear to me that we needed more structure than "everyone reports to the CEO". We struggled to prioritize between different projects, milestones weren't clearly defined or owned, at times there would be long debates on product direction without a clear decisionmaker, etc etc.
Not to say the article is so wrong. I think their advice to consider elevating a few engineers into informal tech leads is a great answer. We went with the path of hiring one dedicated "manager" of all engineers and that worked pretty well too.
Depends team to team and founder to founder. I've seen early stage startups where most ICs were able to self manage, but others where some form of structure was needed. At the stage that you mentioned, it's natural for founders to end up hiring an Engineering Lead.
> consider elevating a few engineers into informal tech leads
It is potentially risky - I've seen plenty of talented engineers flounder because they were thrust into an ill-suited management role too soon, but I think if someone is motivated and eased into the role they tend to be superior to an outside hire.
Love this, and agree with almost all of it.
The only quibble I'd have is with "1:1's happen organically and infrequently" - I think this is based on a misunderstanding about what 1:1's are for.
Regular, formal, 1:1's are the opportunity to get above the work and talk about meta stuff - career direction, morale, interpersonal issues, etc. It's the founder/manager's chance to check if the employee is happy and thriving, or if there's something that needs to change.
These sorts of conversations can happen organically, but often don't, and can be awkward if they do happen organically. Getting the awkward out of the way with a formal agenda can really help to get into the guts of it. Rather than having to manipulate the conversation to get to an emotional item, the manager can just flat-out ask the question because it's on the agenda.
Obviously, you can overdo this, and it can turn into a nightmare for folks so I can see why TFA proposes eliminating them. But properly done, formal 1:1's are really valuable even in small teams.
It seems like a tautology that high performers are turning down positions when 996 is mentioned.
Who on EARTH would opt in to a system like that imposed by your management? (Barring the obvious compensation-related encouragement)
I find a lot of this to also be true with sole engineers managing agents.
I've now seriously approached vibecoding two nontrivial projects, and in each case using "safe tools" was a good way to get to a working stage, faster:
- in one I insisted on typescript early and found it to be more of a hurdle than letting the LLM cobble js learning in and address bugs in a way an engineer might find uncivilized (trial and error over bulletproof typing).
- in another, I found that using react was not offering much benefit to a given project, and asked the llm to rewrite in vanilla. while this mostly worked, it introduced new bugs that were not present when using react. switching BACK to react eliminated these and enabled the LLM to continue writing features at no (current) technical or performance cost!
This is such a great advice overall. Many people are commenting about flaws in the overall approach, yet everything said is exactly what I saw working/not working in such early companies.
i saw that people who wear black turtlenecks are lauded as visionary geniuses, so don't forget to buy some turtlenecks and yell at people on a daily basis.
I used to be very motivated to do the right thing but the culture at my company doesnt reward it and actually actively seems to be promoting bad practices e.g. not documenting. Now I also dgaf.
You dont necessarily need managers but you do need someone to set expectations and keep the team accountable. Otherwise its a race to the bottom. There's no way for me as a single engineer to undo slop faster than its generated.
"lift up your hearts. all will come right. out of the depths of sorrow and of sacrifice will be born again the glory of mankind."
The author is ignorant, and I mean that literally, not as an insult. They haven’t thought deeply about why some methods of work produce better outcomes, and are still looking at the surface level artifacts. A management function is important for aligning effort, enabling performance, and clearing obstacles. Even if there isn’t a “manager” those functions are still helpful.
Bad managers also exist, and can reduce performance, which can be fatal to a startup. But that’s not a reason to avoid having management functions assigned to employees.
This is all a bit messy to read, but seems TFA recommends against 1:1s and any kind of ticket management or any eng. management all when you have 5-6 engineers and this ... insane.
People need to get on the same page. You don't need to be (shouldn't be) process insane or go SCRUM or whatever to do that. But having regular organized interactions and task definitions is absolutely imperative even early on when you don't know for sure what you'll be doing.
Even works just doing it for yourself, Personal Kanban style:
https://www.personalkanban.com/pk/personal-kanban-101/
I recommend Sunsama:
https://www.sunsama.com
yeah. i think you can get away with no 1-on-1's for small teams (like 4 people) but by the time you're at 6 or 8, it's probably a good idea. i suspect the OP has reason for believing this, so rather than say "they're wrong," i would say "i'm not sure they explained their environment sufficiently to explain their conclusion."
as for ticket management. JIRA is not your friend. i would rather go with a stack of post-its than JIRA. JIRA does not help you understand what you are trying to do (in my experience.) once you've figured out specific tasks, JIRA can track those tasks, but so can BugZilla or (as my teams are using increasingly) text files checked into the repo.
people often confuse the tool with the process and confuse following the process with making progress. the first rule of issue tracking systems is they should not get in the way of making tasks you need to do visible. JIRA routinely violates this rule.
hmm... maybe i should write my own blog post.
Agree about JIRA. It trends towards TPS Reports and form filling, substituting a workflow in the issue tracker for actual human processes and communication.
We just rolled out Linear, and I'm gauging how I feel about it. GitHub / GitLab issues I don't find useful. Linear seems like a middle ground. And it's nice and fast. It also doesn't seem to let PMs go apeshit with custom fields and workflows, so that's good.
I always crave for something closer to Buganizer we had internally at Google, which was just nice and minimal and not invasive. At least in its V1 form.
1 reply →
So glad I've never had a "Saturday Standup". Is that really a thing?
The professional won't avoid doing things because they lack motivation.
As a manager, my job was to make sure they were working on the right thing. If they didn't carry their weight, I either reduced the impact by assigning them necessary-but-boring tasks to offload the high performers, or PIP'd them. I "rehabilitated" several engineers over the years and even gave them references when we parted. Staff that lied to me more than once were terminated.
Series A scripts in Linux, to concurrent 996 work mesh networks. The Catalogue of Network Training Material refers to specifying READ_ONCE(), WRITE_ONCE().
> Motivation is a hired trait. The only place where managers motivate people is in management books.
Source?
Did I miss the article mentioning to ask the eng staff how they actually like to work? I get corporate culture and all but engineers like having their subculture and that's fine. As a manager, it's my job to make sure my ppl feel equipped (schedule included) and to keep upper mgmt happy and convinced that it works even if work hours don't match other jobs. So I don't thinly it's ever too soon to hire a manager, as long as he thinks of himself as part of the eng team. Concerning motivation, you can absolutely motivate people by explaining why their work matters and by helping them with the corp paperwork. Example: engineers don't like SAP, I don't like it either, but the project we're working on is so cool that it's worth the 30min hassle per week and I'll sit with them until they get it.
Do not be a sole founder / tech lead / manager who uses obscure tech or add immediate geometrically-increasing tech debt to be paid almost immediately by others.
> 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 the purpose of standups. When it's async, people just put in what they're working on and mostly ignore everyone else. Standups need to be about 2-way communication, not 1-way.
And retrospectives are about improving how the team works. Every team has challenges of every kind. Retrospectives are for surfacing those and addressing them. They take up a couple hours a week, but the idea is that after several months the team is more productive and it pays for itself in time.
> Organic 1:1s (as opposed to recurring ones): keep them topic-heavy and ad-hoc, as opposed to relationship maintenance like in the corporate world.
Also disagree. 1-1's aren't about "relationship maintenance", again they're about surfacing issues that wouldn't arise organically -- all the little things that aren't worth scheduling a conversation over, but which need to be addressed for smooth functioning.
At the end of the day, managing a team is managing a team. In terms of managing people, it's not fundamentally that different if you're a 10-engineer startup or a team of 10 engineers at a megacorp. These things aren't "anti-patterns" or "rituals". When done correctly, they work. (Obviously, if done badly, they don't -- so if you're managing a team, do them correctly.)
I disagree. In a company of 5-6 total engineers who are actually self-motivated and competent none of these things matter. If you need stand-ups for people to be aware of work being done then you're bandaid fixing a deeper issue. Same for retros since all of that should already be getting communicated in five other ways. If not then you've got bigger issues. Same for 1-on-1s. If the founders don't know these things organically then they have failed either in their own roles or in who they hired. The solution to that isn't rituals.
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.
It has nothing to do with motivation or competence.
Teams don't just work together magically and "organically". They're made of diverse human beings, every one of us, who come from different backgrounds with different expectations about when and what to communicate and when and what not to and around what is who's responsibility when. Different levels of experience, having worked at different places with different practices, and different preferences about how to do things. This is a recipe for a hundred miscommunications and inefficiences and misunderstandings a day.
These processes exist to surface the most important things not being surfaced, and to identify and fix problems that affect the team but which nobody is understanding in full because everyone only knows their own perspective.
Again, these aren't "rituals". They're processes that are proven because they work. Including with 5-6 engineers.
4 replies →
yes and no. "agile" has become doctrinaire and "one size fits all." i miss the eXtreme Programming era where standups, pair-programming, test-first, timeboxing, etc. were all "tools in a toolbox" to be applied as needed. i think the OP is experiencing a world where they're told "oh, here's AGILE. you have to do everything in this book," which i think i would push back on as well.
but... if you're going to do standups and retrospectives... i agree with you. do them synchronously. the idea is to get everyone to listen to everyone else. the reason they're STAND-ups is 'cause everyone's supposed to be standing so there's motivation to keep them short. this often makes it difficult to do "follow the sun" development. i quit a job a couple years back because my management insisted my engineers on the US west coast be included in standups for teams in Pune (India).
and that 1-on-1's are for surfacing issues that haven't come up elsewhere seems like received wisdom among my peer group. it seems to work well for me, so +1 on that too.
the phrase "when done correctly" is doing a lot of heavy lifting here. i bet people who have bad experience with these practices were in situations where they weren't done correctly.
one of my problems with environments where management thinks devs are interchangeable bots motivated only by money is that there is zero motivation for management to change their approach when it doesn't work. if they think the only thing that motivates people is money, they think they have to add more money or fire their devs and get devs that are appropriately motivated by cash.
Just let me do what I want to do and if you get the sense the team is not performing please ignore that lmao
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.
the idea i am criticizing is, as explained, "motivation" is something which can be managed and throwing more money at engineers is not a universal motivation.
Yeah. This. In 42 years in IT, i saw way too many situations where the last thing engineers need is a "team" or "management," or even worse, an outside "team leader," which usually resulted in the engineer's work or the team's work turning directly into cowshit. "Managers" want to talk about doing a thing; engineers want to actually do the thing, and both cannot happen simultaneously.
When they see results deteriorating, "managers" think the solution is "more management," which is never, ever the solution.
[dead]