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

This seems entirely false to me. To be honest it is so incorrect it significantly puts into question the rest of the article.

1. I have absolutely had managers motivate me to work harder. I have also had managers completely demotivate me and cause me to quit. How on earth can anyone who has worked in the industry for any amount of time say that "The only place where managers motivate people is in management books"?

2. Of course most of the facile strategies mentioned in the article (like 996, micromanaging, etc) won't work. The article then generalizes this to all strategies - but "if terrible methods can't solve it, nothing possibly can" feels like a shaky argument at best. A good manager understands this, and motivates by helping you understand how the things you are doing are actually critical to the success of the team and the company. (If success of the company isn't something you're interested in, then yes, it's going to be hard to motivate you.) A poor manager sabotages motivation in a hundred different ways - he makes you feel like your efforts are totally wasted, or fails to articulate why they are important.

Initial motivation is the hired trait. It’s very easy to demotivate people. The trick is to not do that.

Setting this expectation early seems honest and the best thing to do. The worst is when companies sell people on WLB but then flip it to 996 -- you end up with all the wrong people and no one wins. Best to be transparent from the onset.

I always encourage candidates to go visit the company several times if possible, including a visit at 5:30pm or 6:30pm to see the state of the office and attendance. There is no right or wrong answer --

   I'll dedicate a post to specific ways you can identify motivation
   during hiring, but in short, look for: the obvious one: evidence that
   they indeed exhibited these external signs of motivation (in an
   unforced way!) in past jobs; signs of grit in their career and life
   paths (how did they respond to adversity, how have they put their past
   successes or reputation on the line for some new challenge);
   intellectual curiosity in the form of hobbies, nerdy interests that
   they can talk about with passion

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'll dedicate a post to specific ways you can identify motivation during hiring, but in short, look for

All will be gamed by interviewees, by the afternoon this hits the HN front page.

(And, for example, tech interview prep has already been telling people to fake passion and curiosity, for many years now.)

Here's what you do:

1. Consider that the early startup also belongs to the early hires. It's their startup too. You're the last-word decider, but it's not only your startup. You want it to also be theirs. Believe this, and act like it.

2. Reflect that in the equity sharing. "0.5%", to be diluted, as options, with ISO rules that discourage exercising at all... while co-founders divide up 70% of founder real shares between themselves... is nonsense, for that founding engineer, who you should want to be as motivated as you, and contributing as much as you do.

3. With equity like you're serious, make the salaries low-ish. Not so low that it's nonviable for modest family cost of living, but low enough to self-select out the people who aren't committed to the company being successful, or who don't actually believe in the company.

4. Have an actually promising company and founding team, or you won't get many experienced people biting.

1. Motivation is a feeling, it's an emotion, it comes and goes, it's a bonus. It's discipline and professionalism that make the huge difference. Many people have the motivation and dream to "create their own programming language", "launch their startup", "make it to the NBA", "lose 40 pounds and get fitter" but this motivation, a feeling, will consistently fight the emotions telling you to have fun, relax, go out with friends, play video games to relieve stress. Motivation is a great boost to discipline and professionalism, but those two survive even when motivation goes off, whereas won't take you anywhere.

2. You cannot hire for motivation and if you're looking for that trait you'll likely projecting your own biases. I suspect that the author of the blog post has nerdy hobbits so he projects himself on candidates. Non sense. Yes, nerdier engineers are likely more interested in the craft and in overall engineering, but that says absolutely nothing about them being motivated in building yet another B2B SaaS.

3. A very good engineer joining a startup, should have the implicit motivation of wanting to get rich in few years, otherwise he/she's be joining a cushier job that pays better.

If you don’t know what good people look like you can’t win.

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.

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.

If you are an early stage startup and your founders have a habit of talking about "competitors", run like hell.

Although I know that a lot of people would argue for "what's wrong with doing your day job well and going home to your family, friends, etc?", in my experience, it is also true that the best software engineers I've seen during my 25 year career are the ones that made their job also their passion and hobby. I think intellectual curiosity and being a 9-5 person are inversely correlated, again in my experience.

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.

But I think some of the management and team stuff is much more complicated in B2B or B2B2C situations, regulated industries, or cases where there are substantial non-engineering employees, perhaps doing sales, onboarding, or things related to the "offline" world (if there are physical aspects to the business).

In particular, I don't think you can have a super flat eng structure run out of a few docs if eng needs to be working with one or more teams larger than the eng team itself unless there's some kind of separate interface to large outside teams.

If you end up with a significant sales team, account management team, support team, significant numbers of contractors, or other categories of workers because of the nature of the business, you will have to be more regimented about how things are structured. In companies that face this issue, it's often one of their major challenges and not avoidable compared to other kinds of startups - your sales team may have all kinds of ideas and some of them may even be good, and some may even want to sell them before you've built them. And if your sales team is 2x the size of product and engineering... it's not easy to run out of one document. (Note that I don't love or endorse this, but in certain kind of markets and products it seems like a bit of an unavoidable issue.)

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.

Who on EARTH would opt in to a system like that imposed by your management? (Barring the obvious compensation-related encouragement)

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!

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.

Bad managers also exist, and can reduce performance, which can be fatal to a startup. But that’s not a reason to avoid having management functions assigned to employees.

Source?

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

When they see results deteriorating, "managers" think the solution is "more management," which is never, ever the solution.