Tiled Hacker news on React Router

No management needed: anti-patterns in early-stage engineering teams

266 points - yesterday at 6:54 PM

Source

TuringNYC
today at 1:40 PM
"I know several top 1% engineers in the Valley who disengage from recruiting processes when 996 or something similar is mentioned."
Setting this expectation early seems honest and the best thing to do. The worst is when companies sell people on WLB but then flip it to 996 -- you end up with all the wrong people and no one wins. Best to be transparent from the onset.
I always encourage candidates to go visit the company several times if possible, including a visit at 5:30pm or 6:30pm to see the state of the office and attendance. There is no right or wrong answer --
johnfn
today at 4:22 AM
> Motivation is a hired trait. The only place where managers motivate people is in management books.
This seems entirely false to me. To be honest it is so incorrect it significantly puts into question the rest of the article.
1. I have absolutely had managers motivate me to work harder. I have also had managers completely demotivate me and cause me to quit. How on earth can anyone who has worked in the industry for any amount of time say that "The only place where managers motivate people is in management books"?
2. Of course most of the facile strategies mentioned in the article (like 996, micromanaging, etc) won't work. The article then generalizes this to all strategies - but "if terrible methods can't solve it, nothing possibly can" feels like a shaky argument at best. A good manager understands this, and motivates by helping you understand how the things you are doing are actually critical to the success of the team and the company. (If success of the company isn't something you're interested in, then yes, it's going to be hard to motivate you.) A poor manager sabotages motivation in a hundred different ways - he makes you feel like your efforts are totally wasted, or fails to articulate why they are important.
pyrale
yesterday at 9:31 PM
> 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
burnto
yesterday at 9:26 PM
> 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.
epolanski
today at 10:29 AM
The whole thing about motivation is non sense.
1. Motivation is a feeling, it's an emotion, it comes and goes, it's a bonus. It's discipline and professionalism that make the huge difference. Many people have the motivation and dream to "create their own programming language", "launch their startup", "make it to the NBA", "lose 40 pounds and get fitter" but this motivation, a feeling, will consistently fight the emotions telling you to have fun, relax, go out with friends, play video games to relieve stress. Motivation is a great boost to discipline and professionalism, but those two survive even when motivation goes off, whereas won't take you anywhere.
2. You cannot hire for motivation and if you're looking for that trait you'll likely projecting your own biases. I suspect that the author of the blog post has nerdy hobbits so he projects himself on candidates. Non sense. Yes, nerdier engineers are likely more interested in the craft and in overall engineering, but that says absolutely nothing about them being motivated in building yet another B2B SaaS.
3. A very good engineer joining a startup, should have the implicit motivation of wanting to get rich in few years, otherwise he/she's be joining a cushier job that pays better.
neilv
today at 8:36 AM
It sounded good, up until the examples for:
> I'll dedicate a post to specific ways you can identify motivation during hiring, but in short, look for
All will be gamed by interviewees, by the afternoon this hits the HN front page.
(And, for example, tech interview prep has already been telling people to fake passion and curiosity, for many years now.)
Here's what you do:
1. Consider that the early startup also belongs to the early hires. It's their startup too. You're the last-word decider, but it's not only your startup. You want it to also be theirs. Believe this, and act like it.
2. Reflect that in the equity sharing. "0.5%", to be diluted, as options, with ISO rules that discourage exercising at all... while co-founders divide up 70% of founder real shares between themselves... is nonsense, for that founding engineer, who you should want to be as motivated as you, and contributing as much as you do.
3. With equity like you're serious, make the salaries low-ish. Not so low that it's nonviable for modest family cost of living, but low enough to self-select out the people who aren't committed to the company being successful, or who don't actually believe in the company.
4. Have an actually promising company and founding team, or you won't get many experienced people biting.
tptacek
today at 3:30 AM
We're apparently back to making psychoanalysts out of interviewers:
```
   I'll dedicate a post to specific ways you can identify motivation
   during hiring, but in short, look for: the obvious one: evidence that
   they indeed exhibited these external signs of motivation (in an
   unforced way!) in past jobs; signs of grit in their career and life
   paths (how did they respond to adversity, how have they put their past
   successes or reputation on the line for some new challenge);
   intellectual curiosity in the form of hobbies, nerdy interests that
   they can talk about with passion
```
I'm pretty confident that this doesn't work, and that searching for "intellectual curiosoty in the form of hobbies and nerdy interests" is actually an own-goal, though it's a great way to keep your Slack channels full of zesty, nerdy, non-remunerative enterprise during the core hours everyone has to actually ship code together.
Swizec
yesterday at 9:27 PM
> 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.
bsoles
today at 3:21 PM
> Intellectual curiosity in the form of hobbies, nerdy interests that they can talk about with passion
Although I know that a lot of people would argue for "what's wrong with doing your day job well and going home to your family, friends, etc?", in my experience, it is also true that the best software engineers I've seen during my 25 year career are the ones that made their job also their passion and hobby. I think intellectual curiosity and being a 9-5 person are inversely correlated, again in my experience.
today at 1:56 PM
systemtest
yesterday at 9:19 PM
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.
jayd16
yesterday at 9:24 PM
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.
lifeisstillgood
yesterday at 9:17 PM
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.
Animats
yesterday at 10:39 PM
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.
givemeethekeys
yesterday at 9:15 PM
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.
joshcsimmons
today at 3:25 AM
This reads like someone who has mostly had unskilled managers. The force multiplier difference a great manager can have is immense. I worked so much harder as an IC at small startups when I knew someone had my back and cared about my growth.
Glyptodon
today at 5:11 AM
As a former engineer at a YC startup from pre-A to post-B, I generally agree with much of this in a broad way if the startup is a technology first one with organic growth or hasn't really figured out product/market fit.
But I think some of the management and team stuff is much more complicated in B2B or B2B2C situations, regulated industries, or cases where there are substantial non-engineering employees, perhaps doing sales, onboarding, or things related to the "offline" world (if there are physical aspects to the business).
In particular, I don't think you can have a super flat eng structure run out of a few docs if eng needs to be working with one or more teams larger than the eng team itself unless there's some kind of separate interface to large outside teams.
If you end up with a significant sales team, account management team, support team, significant numbers of contractors, or other categories of workers because of the nature of the business, you will have to be more regimented about how things are structured. In companies that face this issue, it's often one of their major challenges and not avoidable compared to other kinds of startups - your sales team may have all kinds of ideas and some of them may even be good, and some may even want to sell them before you've built them. And if your sales team is 2x the size of product and engineering... it's not easy to run out of one document. (Note that I don't love or endorse this, but in certain kind of markets and products it seems like a bit of an unavoidable issue.)
marcus_holmes
today at 2:45 AM
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.
chis
yesterday at 9:21 PM
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.
_blk
today at 3:25 PM
Did I miss the article mentioning to ask the eng staff how they actually like to work? I get corporate culture and all but engineers like having their subculture and that's fine. As a manager, it's my job to make sure my ppl feel equipped (schedule included) and to keep upper mgmt happy and convinced that it works even if work hours don't match other jobs. So I don't thinly it's ever too soon to hire a manager, as long as he thinks of himself as part of the eng team. Concerning motivation, you can absolutely motivate people by explaining why their work matters and by helping them with the corp paperwork. Example: engineers don't like SAP, I don't like it either, but the project we're working on is so cool that it's worth the 30min hassle per week and I'll sit with them until they get it.
tuleiff
today at 2:04 PM
The professional won't avoid doing things because they lack motivation.
sailfast
yesterday at 9:35 PM
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)
rballpug
today at 3:25 AM
Series A scripts in Linux, to concurrent 996 work mesh networks. The Catalogue of Network Training Material refers to specifying READ_ONCE(), WRITE_ONCE().
blinkbat
yesterday at 9:48 PM
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!
everlier
yesterday at 9:48 PM
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.
yfw
yesterday at 9:30 PM
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.
ungreased0675
today at 4:55 AM
The author is ignorant, and I mean that literally, not as an insult. They haven’t thought deeply about why some methods of work produce better outcomes, and are still looking at the surface level artifacts. A management function is important for aligning effort, enabling performance, and clearing obstacles. Even if there isn’t a “manager” those functions are still helpful.
Bad managers also exist, and can reduce performance, which can be fatal to a startup. But that’s not a reason to avoid having management functions assigned to employees.
badc0ffee
today at 4:42 AM
So glad I've never had a "Saturday Standup". Is that really a thing?
dogman1050
today at 11:05 AM
As a manager, my job was to make sure they were working on the right thing. If they didn't carry their weight, I either reduced the impact by assigning them necessary-but-boring tasks to offload the high performers, or PIP'd them. I "rehabilitated" several engineers over the years and even gave them references when we parted. Staff that lied to me more than once were terminated.
cmrdporcupine
yesterday at 9:28 PM
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.
burnt-resistor
today at 12:57 PM
Do not be a sole founder / tech lead / manager who uses obscure tech or add immediate geometrically-increasing tech debt to be paid almost immediately by others.
akst
today at 9:47 AM
> Motivation is a hired trait. The only place where managers motivate people is in management books.
Source?
karlitooo
today at 11:56 AM
Just let me do what I want to do and if you get the sense the team is not performing please ignore that lmao
crazygringo
yesterday at 9:31 PM
> 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.)
OhMeadhbh
yesterday at 9:15 PM
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.
theturtle
yesterday at 11:21 PM
[dead]
0-679-72034-0
yesterday at 9:29 PM
[dead]

No management needed: anti-patterns in early-stage engineering teams

TuringNYC

setopt

TuringNYC

dkarl

pessimizer

dgxyz

johnfn

f1shy

gen220

f1shy

AdamN

ubercore

cudgy

skeeter2020

n4r9

ljm

skeeter2020

ragall

ljm

philipallstar

pessimizer

Y-bar

lan321

skeeter2020

skeeter2020

yolo3000

Draiken

friendzis

n4r9

friendzis

watwut

friendzis

solatic

skeeter2020

jimbo808

trusche

theshrike79

xkbarkar

boobsbr

evalstate

zeroq

tayo42

sgillen

dannersy

friendzis

rectang

idontwantthis

pyrale

exabrial

numpy-thagoras

Gravityloss

nemomarx

phendrenad2

burnt-resistor

Herring

bob001

ta-asdo989

al_borland

theshrike79

joe_mamba

conradfr

theshrike79

bob001

theshrike79

Muromec

bojan

ernst_klim

raw_anon_1111

Herring

raw_anon_1111

Muromec

malfist

array_key_first

bob001

acdha

bob001

Muromec

DarkNova6

pif