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

> 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

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

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

When I read about 996-style culture I am happy to be European. That would not work here. 40 hours per week max and most engineers prefer to not work more than 32 hours a week. So you have a good work/life balance. I currently work 4 hours a week.

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

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.

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.

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!

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.

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.

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)

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

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.

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.

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.

[dead]