> 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?!
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.
Not just that, but the union would likely end up capping their salary much lower so the wealth can be spread around. How hard is the 10x engineer on the team going to work when the compensation is the same regardless? This is where people end up working multiple jobs, if they can keep up with their peers only working one day per week.
Again see Steve. Something can look like a good position and still rapidly deteriorate.
This one wasn’t that rapid either, you had plenty of warning. I remember discussing inequality with friends in 2014, and probably knew about it since Occupy Wall Street (2011). Or earlier.
Privileged is too generic of a word that does not accurately describe the cohorts. There is the capital class. Occupy was after the Capital class but im not sure if they accurately zeroed in on that. Its been too long since then.
Engineers were never part of that class. They work for a living while capital owns assets that work for them.
Engineers were part of the "Intellectual Elite" class that made good money but were super socially progressive. (Think putting BLM signs in their yards while at the same time pricing out the people they claim to help).
They ended up becoming a lot of the Elizabeth Warren cohort after being the Hillary and Obama cohorts(before it fractured into part Bernie part MAGA with the rest going to Hillary).
Extremely socially progressive but don't you dare touch economics.
Having talked to Occupy Wall Street people at the time I don't think many on the ground differentiated as much as you think they did. I used a generic word because from my experience that is how they saw the world. I got told I deserved to have everything I own set on fire for saying I spent $100 on a nice dinner once. That was on the more extreme side but the sentiment seemed to not differentiate.
They are closer but they are not part of the class so does it really matter how close they are? Engineer still has to trade their time for wealth in the form of work. Capital class has assets that work for them.
To me the only question is if there's a hypothetical revolution who will end up swinging in the wind by their neck and I have no doubt many engineers working for big tech would have been in that group. There's always nice rhetoric and focused rhetoric to not make too many enemies but the people on the ground differentiate a lot less and have in every revolution.
i disagree. i also disagree that most people developing tech solutions for startups are engineers or are applying an engineering discipline. but i would agree that the majority of people in valley tech firms are closer to the rentier class than they are to working engineers.
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.
I've been an early employee (sub 10 and 20) in two unicorns and another (a presidential campaign) that didn't have a valuation but did the equivalent. People did not work 40 hours per week, and I feel comfortable saying that the companies could not have been as successful if people had.
The common threads were:
- incredible ICs
- founders who spiked in the most important areas for that market
- a mission that everyone truly believed in
- a culture of people who deeply cared about one another but were comfortable pushing back (as you said!)
It's incredibly rare to find all of these together. I agree that management is responsible for helping others thrive, but not necessarily that they should shape the environment to fit any engineer. Some people want things (projects, challenges, roles) that don't make sense in that company's context. It's okay, especially when it's hard, to agree that this isn't the place for someone.
> 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.
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.
One of my core philosophies as a manager is that by default I should get the fuck out of the way. From there, identify the biggest issues and solve them.
If you're successful hiring great people, I really don't understand the desire to micromanage them. Or do silly things that are demotivating, like 996 or trying to mislead them / market things / hide the bad stuff.
Treating people like adults is that One Neat Trick that influencer bloggers don't want you to know.
> Treating people like adults is that One Neat Trick that influencer bloggers don't want you to know.
In the companies below Big Tech in valuation at least, having been in the room with drunken executives speaking their real thoughts multiple times, I’ve found it’s because they don’t want to treat people like adults.
They want serfs to order around because they have some cultural value around being “the boss” and you can’t be “the boss” if you aren’t telling people what to do. The more things you tell them to do, the more of a boss you are.
It’s how you get executives crowing to you about all of these faang ideas like google’s 20% time back in the day, or engineers being able to vote with their feet and only attend meetings they found useful, but then have people on pips because they were consistently 30-60 seconds late to daily standups.
It’s not the only failure mode by far, but having leadership like that seems like a cause for companies getting hard stuck below a billion in profit
I'd go further: a bad manager can turn a great engineer into a very bad one. People look up to great people, and when the strongest performers are demotivated, that spreads.
Commonly in the cultures that end up this way, leadership blames / gaslights the ICs. It's toxic and honestly kind of heartbreaking.
If they are very bad, the company can let them go. If they are simple good or fine, the company lost their great engineer, and now has a seat filler that they can’t justify firing.
For sure. At that point they have to fire them, even though it's the company / leadership's fault and hard to watch. Ultimately better for that engineer, as well, to move on.
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.
As a manager, yeah I’ve seen several of my peers wash out of the role for one reason or another. It happens. Usually it’s self selected though, disliking the inherent drama, having difficult to work with employees, moving up from engineering and realizing that was actually what they loved, etc.
But a bad people manager who still manages resources and timelines and expectations isn’t necessarily bad for business. Promoting them up into a more strategic role that deals less with managing a larger group of individuals directly isn’t necessarily a bad move either.
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.
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.
> 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.
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.
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.
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.
There’s sort of a rotation going on in a lot of companies. There were companies which had Europe as the low cost location compared to America are now moving the type of work that had been done in America to Europe and what had been in Europe to India. But also companies treating European countries as high cost now and looking for new low cost countries
we also sort of effed up a while ago with changes to section 174... suddenly software devs in the states were 10%-25% more expensive. once that happened it made sense to see if moving devs to europe for situations where you have a european based product and sales team made sense.
in the states we've sort of repaired the damage of the section 174 changes, but i think they were rolled into a tax bill that sunsets in a few years. so we may see this again in 2029.
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.
Stockholm is not representative of entire Europe same how SF isn't representative of entire NA. There's too many variables and shades of gray to give a simple answer, with closest to a correct answer being "it depends" based on where you live, how good you are and how in demand your skill set is to the demand of your local market, but the market is pretty much fucked in many high-CoL locations worldwide due to offshoring to cheaper locations and many businesses in Europe seeing orders fall.
I deliberately chose to compare two tech-heavy locations to avoid weird and difficult comparisons like the tech industry in rural Nebraska Vs Moldavia.
Stockholm was a natural point of comparison for me given that I used to live there until very recently.i have a decent picture of the dev market in Stockholm. Silicon valley is the most mentioned tech centre on here, and is therefore the American tech market I know the most about (even if my knowledge is very limited in this front)
I live in Spain. I’ve been in the industry for the last 10 years.
I’ve seen from a very close distance several European companies move a big part of their operations to India. Have had close friends laid off recently and seen them struggle for months to find a new jobs. Plus, I see tighter freelance market these days.
is that for startups or for the big guys like Ericsson?
i have to admit i was surprised by how much startup activity was going on in Stockholm in the last 20 years. but disappointed by how few startups don't get B or C rounds or get bought after their A or B rounds run out.
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.
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.
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
if you surround yourself with people who are only motivated by money, you will believe that everyone is only motivated by money. if you surround yourself with people who are motivated by a creative urge to build something they can be proud of, you may start to believe that this is everyone's motivation.
it is often useful to think of people as only being motivated by one thing, to see clearly how application of that thing might change their behaviour. but if you believe that is the only thing that motivates them, you will have a very simplistic (and eventually incorrect) model of how they are motivated.
Maybe 15 years ago I would've agreed because there was genuine innovation in tech where you could actually be passionate and proud of building it. "I want to work here because I want this product to exist" could've been a legitimate thing to say back in the day.
Nowadays with every market being saturated and tech being a race to the bottom quality-wise, what's there to be passionate about and/or proud of? Do you think people are proud of building yet another OpenAI wrapper or advertising surface? If they actually are proud of those I would feel pretty sad for them.
Also, the majority of landlords don't take payment in "passion" or "pride" and rents have skyrocketed since the glory days of tech.
i think it's still out there, but yeah, you have to wade through an amazing amount of poop to find it. insert here the joke about someone digging through the muck in a horse stable and the punch line is "there's got to be a pony in here somewhere."
Many people aren't motivated by money so much as wanting to spend as much time they can with their family, where they find their creative energies most rewarding.
Making the most money per hour merely allows me to spend more time with my family rather than working more for less and giving my creative energies to greater society or an employer instead of directly to my wife and children.
I think the occasional burst of activity can and does work, but it’s a budget you need to spend strategically and let it recover. Constant 996 indeed won’t work.
you are lucky to have lived a career where that is true. it is largely true in the states and sometimes true in startups. there are corners of the world where it is less true than one would hope.
That's a good callout - I have found European employers and founders to be much stingier with salaries in comparison to those I've worked with in the Bay or Israel, but I feel a lot of this is because of much more conservative investors, with boards pushing back on more "realistic" compensation.
I've been adamant about paying 75th percentile TC - I want the employees in my portfolio companies to be extremely motivated, and that requires incentivizing employees and founders correctly
I agree, but the issue is the impetus behind the statement. The tone which that poster took and the default negative assumption is a negative trait to most hiring managers - especially at the early stage. At an early stage organization, you want your employees to be self-motivated but also open to pull crunchtime if needed (eg. customer escalation, rolled up product launch, pivot)
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.
I count work the contracted time I need to be available/tied to my employer. Doesn't matter if I'm doing focused coding or not, it's still work because I can't be paragliding or swimming in that time, I need to be at the office or near my laptop, so it's not leisure, it's still work time.
But let's say it's only counting "focused work", 4h/week is huge stretch, unless we're competing in slacker olympics.
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.
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.
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.
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.
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.
Good ideas need the right timing to line up. AT&T can afford to keep a research project around until the timing is right where a startup needs to find market fit immediately.
i'm not sure that is true about AT&T. you may be thinking about Bell Labs, which effectively destroyed it's culture in the 90s or early 2000s.
but i take your point to mean there are large companies that have budget to maintain projects that do not have an immediate need to be profitable. and agree that for startups, it's a great idea if you're building things for which a market is emerging. everyone talks about how Steve Jobs is a miracle worker. not to diminish his accomplishments, but he was also very lucky. he wanted to sell apple 2's into a market that was just starting to want to buy apple 2's. i'll give him the iPhone, however. i think he was smart enough to understand the forces were aligning to make a product that your average user would like.
but apple didn't spend 30 years making the iPhone. they had to wait 'til the market was there and manufacturing costs were low enough and bandwidth was available. i'm mostly agreeing w/ you, but i think ideas can weave in and out of companies and organizations. CALO jumped from DARPA to SRI to Apple to Quato and motivated several more startups.
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.
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.
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.
> 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.
To me you're describing a team with mediocre communication and social skills. That's common but its not all teams.
It has everything to do with maturity, motivation and competence. The best teams I've been on didn't care about these rituals because each person bridged the gap with other people. The TLs kept an eye on everything the TL and EM kept an eye on all the people side and concerns. In a startup it'd be the founders. There was mutual trust built by those in leadership roles and issues were communicated and everyone kept an eye out for them.
> 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.
Have a meeting, align on some norms for these things and then hold people accountable to them. It's not hard. We're all adults. You don't need constant meetings to hand hold people like little kids.
> Have a meeting, align on some norms for these things and then hold people accountable to them. It's not hard. We're all adults. You don't need constant meetings to hand hold people like little kids.
Yes... the meetings are called retrospectives.
One of the norms is called standups.
You don't need to belittle these processes as being for "little kids". That's deeply unprofessional.
Maybe there are some teams made up entirely of these 10x communicators you describe where everybody perfectly "bridges the gap" with other people. All I can say is, I've never seen it. And knowing everything I know about how easy it is for miscommunication to happen, I'm inclined to suspect that if you think you worked somewhere like that, you simply weren't aware of how much further communication and processes could have improved. After all, how could you? It's incredibly easy for us to assume that things are working as well as they could be. Until we try something like standup+retrospectives and are surprised at how much value they end up bringing.
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.
> 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
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.
Until recently?
Now it's 20x at the AI labs instead of 5x at FAANG.
Not just that, but the union would likely end up capping their salary much lower so the wealth can be spread around. How hard is the 10x engineer on the team going to work when the compensation is the same regardless? This is where people end up working multiple jobs, if they can keep up with their peers only working one day per week.
That's right, no more "10xers" working 80 hr weeks making those who can't or won't look unproductive.
Still do
Again see Steve. Something can look like a good position and still rapidly deteriorate.
This one wasn’t that rapid either, you had plenty of warning. I remember discussing inequality with friends in 2014, and probably knew about it since Occupy Wall Street (2011). Or earlier.
Engineers were the privileged class. They were part of the group occupy wall street wanted to bring down. Not hard to guess why they didn't want that.
Privileged is too generic of a word that does not accurately describe the cohorts. There is the capital class. Occupy was after the Capital class but im not sure if they accurately zeroed in on that. Its been too long since then.
Engineers were never part of that class. They work for a living while capital owns assets that work for them.
Engineers were part of the "Intellectual Elite" class that made good money but were super socially progressive. (Think putting BLM signs in their yards while at the same time pricing out the people they claim to help).
They ended up becoming a lot of the Elizabeth Warren cohort after being the Hillary and Obama cohorts(before it fractured into part Bernie part MAGA with the rest going to Hillary).
Extremely socially progressive but don't you dare touch economics.
Having talked to Occupy Wall Street people at the time I don't think many on the ground differentiated as much as you think they did. I used a generic word because from my experience that is how they saw the world. I got told I deserved to have everything I own set on fire for saying I spent $100 on a nice dinner once. That was on the more extreme side but the sentiment seemed to not differentiate.
They basically hated on anyone making more than a livable wage at the time ($60k).
I would say more precisely, engineers are closer to the managerial or capital wielding class; usually the adversary of the union.
They are closer but they are not part of the class so does it really matter how close they are? Engineer still has to trade their time for wealth in the form of work. Capital class has assets that work for them.
To me the only question is if there's a hypothetical revolution who will end up swinging in the wind by their neck and I have no doubt many engineers working for big tech would have been in that group. There's always nice rhetoric and focused rhetoric to not make too many enemies but the people on the ground differentiate a lot less and have in every revolution.
i disagree. i also disagree that most people developing tech solutions for startups are engineers or are applying an engineering discipline. but i would agree that the majority of people in valley tech firms are closer to the rentier class than they are to working engineers.
Steve Jobs was also an expert at suppressing software engineering wages. Karma has a funny way of coming around.
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.
I've been an early employee (sub 10 and 20) in two unicorns and another (a presidential campaign) that didn't have a valuation but did the equivalent. People did not work 40 hours per week, and I feel comfortable saying that the companies could not have been as successful if people had.
The common threads were:
- incredible ICs
- founders who spiked in the most important areas for that market
- a mission that everyone truly believed in
- a culture of people who deeply cared about one another but were comfortable pushing back (as you said!)
It's incredibly rare to find all of these together. I agree that management is responsible for helping others thrive, but not necessarily that they should shape the environment to fit any engineer. Some people want things (projects, challenges, roles) that don't make sense in that company's context. It's okay, especially when it's hard, to agree that this isn't the place for someone.
> 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.
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.
> 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
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.
If they are very bad, the company can let them go. If they are simple good or fine, the company lost their great engineer, and now has a seat filler that they can’t justify firing.
For sure. At that point they have to fire them, even though it's the company / leadership's fault and hard to watch. Ultimately better for that engineer, as well, to move on.
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.
As a manager, yeah I’ve seen several of my peers wash out of the role for one reason or another. It happens. Usually it’s self selected though, disliking the inherent drama, having difficult to work with employees, moving up from engineering and realizing that was actually what they loved, etc.
But a bad people manager who still manages resources and timelines and expectations isn’t necessarily bad for business. Promoting them up into a more strategic role that deals less with managing a larger group of individuals directly isn’t necessarily a bad move either.
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.
“ It’s very easy to demotivate people”
So true. And really hard to reverse
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.
i stopped reading and upvoted this comment right after you wrote "i think motivation is contextual." i cannot agree with you more.
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.
> 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.
+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.
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'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.
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.
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.
i think Amazon only had one person jump out of a building last year. it's not as common as you might think.
"One company only had one suicide via jumping last year" is not a ringing endorsement.
I'd say the exact opposite. engineering is markedly being outsourced to europe.
There’s sort of a rotation going on in a lot of companies. There were companies which had Europe as the low cost location compared to America are now moving the type of work that had been done in America to Europe and what had been in Europe to India. But also companies treating European countries as high cost now and looking for new low cost countries
we also sort of effed up a while ago with changes to section 174... suddenly software devs in the states were 10%-25% more expensive. once that happened it made sense to see if moving devs to europe for situations where you have a european based product and sales team made sense.
in the states we've sort of repaired the damage of the section 174 changes, but i think they were rolled into a tax bill that sunsets in a few years. so we may see this again in 2029.
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.
Stockholm is not representative of entire Europe same how SF isn't representative of entire NA. There's too many variables and shades of gray to give a simple answer, with closest to a correct answer being "it depends" based on where you live, how good you are and how in demand your skill set is to the demand of your local market, but the market is pretty much fucked in many high-CoL locations worldwide due to offshoring to cheaper locations and many businesses in Europe seeing orders fall.
I deliberately chose to compare two tech-heavy locations to avoid weird and difficult comparisons like the tech industry in rural Nebraska Vs Moldavia.
Stockholm was a natural point of comparison for me given that I used to live there until very recently.i have a decent picture of the dev market in Stockholm. Silicon valley is the most mentioned tech centre on here, and is therefore the American tech market I know the most about (even if my knowledge is very limited in this front)
I live in Spain. I’ve been in the industry for the last 10 years.
I’ve seen from a very close distance several European companies move a big part of their operations to India. Have had close friends laid off recently and seen them struggle for months to find a new jobs. Plus, I see tighter freelance market these days.
This was unthinkable not long ago.
UK companies have been moving IT or other operation functions to India for decades
It's the typical Western management behaviour of knowing the cost of everything but the value of nothing
is that for startups or for the big guys like Ericsson?
i have to admit i was surprised by how much startup activity was going on in Stockholm in the last 20 years. but disappointed by how few startups don't get B or C rounds or get bought after their A or B rounds run out.
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.
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.
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.
if you surround yourself with people who are only motivated by money, you will believe that everyone is only motivated by money. if you surround yourself with people who are motivated by a creative urge to build something they can be proud of, you may start to believe that this is everyone's motivation.
it is often useful to think of people as only being motivated by one thing, to see clearly how application of that thing might change their behaviour. but if you believe that is the only thing that motivates them, you will have a very simplistic (and eventually incorrect) model of how they are motivated.
Maybe 15 years ago I would've agreed because there was genuine innovation in tech where you could actually be passionate and proud of building it. "I want to work here because I want this product to exist" could've been a legitimate thing to say back in the day.
Nowadays with every market being saturated and tech being a race to the bottom quality-wise, what's there to be passionate about and/or proud of? Do you think people are proud of building yet another OpenAI wrapper or advertising surface? If they actually are proud of those I would feel pretty sad for them.
Also, the majority of landlords don't take payment in "passion" or "pride" and rents have skyrocketed since the glory days of tech.
i think it's still out there, but yeah, you have to wade through an amazing amount of poop to find it. insert here the joke about someone digging through the muck in a horse stable and the punch line is "there's got to be a pony in here somewhere."
Many people aren't motivated by money so much as wanting to spend as much time they can with their family, where they find their creative energies most rewarding.
Making the most money per hour merely allows me to spend more time with my family rather than working more for less and giving my creative energies to greater society or an employer instead of directly to my wife and children.
Not only is it rarely compensated, it's rarely effective.
Software work is bursty and creative, not mechanical and hourly.
I think the occasional burst of activity can and does work, but it’s a budget you need to spend strategically and let it recover. Constant 996 indeed won’t work.
you are lucky to have lived a career where that is true. it is largely true in the states and sometimes true in startups. there are corners of the world where it is less true than one would hope.
> there are corners of the world where it is less true than one would hope.
And it's readily visible in terms of software quality and technological capability of the company.
and the quality of software produced that way shows
That's a good callout - I have found European employers and founders to be much stingier with salaries in comparison to those I've worked with in the Bay or Israel, but I feel a lot of this is because of much more conservative investors, with boards pushing back on more "realistic" compensation.
I've been adamant about paying 75th percentile TC - I want the employees in my portfolio companies to be extremely motivated, and that requires incentivizing employees and founders correctly
I wouldn't work 996 because I like having weekends off and a life outside work
Working more hours however =/= getting more done. In fact, some experiments show the opposite (within boundaries of course).
I agree, but the issue is the impetus behind the statement. The tone which that poster took and the default negative assumption is a negative trait to most hiring managers - especially at the early stage. At an early stage organization, you want your employees to be self-motivated but also open to pull crunchtime if needed (eg. customer escalation, rolled up product launch, pivot)
> 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.
140k AUD. In major cities in Australia that is a reasonable mid level salary. I imagine that is good in Prague.
It's a much better salary in Czech republic, Poland, etc, yes.
80k a few years ago was the price point at which you would get few Western Europe remote candidate and many Eastern Europe ones.
>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.
I count work the contracted time I need to be available/tied to my employer. Doesn't matter if I'm doing focused coding or not, it's still work because I can't be paragliding or swimming in that time, I need to be at the office or near my laptop, so it's not leisure, it's still work time.
But let's say it's only counting "focused work", 4h/week is huge stretch, unless we're competing in slacker olympics.
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.
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.
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.
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.
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.
Good ideas need the right timing to line up. AT&T can afford to keep a research project around until the timing is right where a startup needs to find market fit immediately.
i'm not sure that is true about AT&T. you may be thinking about Bell Labs, which effectively destroyed it's culture in the 90s or early 2000s.
but i take your point to mean there are large companies that have budget to maintain projects that do not have an immediate need to be profitable. and agree that for startups, it's a great idea if you're building things for which a market is emerging. everyone talks about how Steve Jobs is a miracle worker. not to diminish his accomplishments, but he was also very lucky. he wanted to sell apple 2's into a market that was just starting to want to buy apple 2's. i'll give him the iPhone, however. i think he was smart enough to understand the forces were aligning to make a product that your average user would like.
but apple didn't spend 30 years making the iPhone. they had to wait 'til the market was there and manufacturing costs were low enough and bandwidth was available. i'm mostly agreeing w/ you, but i think ideas can weave in and out of companies and organizations. CALO jumped from DARPA to SRI to Apple to Quato and motivated several more startups.
Ah, the mythical secret weakness of all startups: another startup doing the same thing.
of course. how else would they get funded?
Why
Scarcity mindset.
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.
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.
thx for the info. i'm not familiar with Linear, i'll have to check it out.
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."
> 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.
To me you're describing a team with mediocre communication and social skills. That's common but its not all teams.
It has everything to do with maturity, motivation and competence. The best teams I've been on didn't care about these rituals because each person bridged the gap with other people. The TLs kept an eye on everything the TL and EM kept an eye on all the people side and concerns. In a startup it'd be the founders. There was mutual trust built by those in leadership roles and issues were communicated and everyone kept an eye out for them.
> 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.
Have a meeting, align on some norms for these things and then hold people accountable to them. It's not hard. We're all adults. You don't need constant meetings to hand hold people like little kids.
> Have a meeting, align on some norms for these things and then hold people accountable to them. It's not hard. We're all adults. You don't need constant meetings to hand hold people like little kids.
Yes... the meetings are called retrospectives.
One of the norms is called standups.
You don't need to belittle these processes as being for "little kids". That's deeply unprofessional.
Maybe there are some teams made up entirely of these 10x communicators you describe where everybody perfectly "bridges the gap" with other people. All I can say is, I've never seen it. And knowing everything I know about how easy it is for miscommunication to happen, I'm inclined to suspect that if you think you worked somewhere like that, you simply weren't aware of how much further communication and processes could have improved. After all, how could you? It's incredibly easy for us to assume that things are working as well as they could be. Until we try something like standup+retrospectives and are surprised at how much value they end up bringing.
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.