> Who's going to write the fine-detail code if they whole day is a meeting?

From my experience, in good teams people understand when it's time leave each other alone. I hate the word "sprint" which comes from the much hated "agile" culture, but it's what it is: there are these small sprints when everyone signals DND by taking on their headphones. Which also means only disturb me if it's very, very important or urgent.

But it is also important to be aware of what's going on in the company. Not just what you are doing but also why. Everyone can take part in decision making which happens during the day spontaneously. Or at least be aware of the process. From my observations: if done right, this kind of environments can be super productive.

> the much hated "agile" culture

I never got on well with Scrum, especially with the way it has become synonymous with “agile”. Really a shame that “agile” which focused on people has been swamped as a term by Scrum which is process process process.

Scrum isn't bad, but there are better agile processes. Most people doing scrum don't really do retrospectives and make changes to the process. In a large company this isn't really reasonable as there needs to be some process in common with each team, and the processes you most need to change in scrum are the ones that can only be changed if every team does it at once.

I favor kanban processes - it locks in less at an organizational level and thus allows more freedom to make changes for the team. Though in my experience there is less change needed in the first place because the only processes specified are the ones that are locked in and everything else is whatever it takes to make it work.

Your thinking is part of the problem.

Agile is rooted on focusing on people. Make a group of good people and empower them and they will create a process that works well. Also on the cases the process fail, they will change it. But if you go and decide the process, that's more than half the way towards a failure already.

What you propose works in a small organization - which is the type of place where scrum was created and works well. In a large organization there would be too many people trying to make conflicting changes for that to work. Any individual change might be good, but they conflict and nobody can track what you are supposed to do now. That is why large organizations are so hard to change.

Agile focusing on people is a good thing. People are number one, but agile has always acknowledged the roll of processes.

> In a large organization there would be too many people trying to make conflicting changes

Ideally, even in a large organization, it should still be structured down into small teams that can self-manage. You'll end up with Conway's Law taking effect, but you'll also alleviate the O(n^2) communication problem. In my experience, it works a lot smoother than 50 person teams where everyone's tripping over each other all the time.

Right, thanks for the correction, I meant Scrum of course.

> From my experience, in good teams people understand when it's time leave each other alone. I hate the word "sprint" which comes from the much hated "agile" culture, but it's what it is: there are these small sprints when everyone signals DND by taking on their headphones. Which also means only disturb me if it's very, very important or urgent.

When I was working in a startup, we did a "hybrid wfh" thing: we knew when we were about to have something requiring our full attention and would work one (or multiple) days from home. We had Google chat (or whatever it was called at the time) for anything that could handle a delay in response and the phone for anything that needed a chat right away.

At the time, the office was in a kind of co-working space, so it was a particularly hellish combination of open-space and multiple companies, complete with people unaware of their phones' silent mode. The upside was that even for regular work, productivity skyrocketed when we were home, so the founder, who initially was against this, started warming up to the arrangement.

More broadly, I think that different jobs have different requirements. I hate it when people talk around me and find it harder to focus. I never got used to this even after multiple years. And while I love listening to music, even while working, I don't enjoy wearing headphones all day long. I'm wearing glasses, so bigger headphones start to hurt after a while and in-ears are pain to put back in after every interruption.

Also, headphones cut you off from the surrounding discussion (that's the point, right?) so the whole "you can overhear the spontaneous decisions during the day" kinda falls flat, doesn't it?

> "you can overhear the spontaneous decisions during the day"

This is a good thing if the spontaneous decisions are always and only the ones that are important to you. This is a bad thing if there is any other decision. In a shared multiple companies space the only decision that matters to you is "where should we go for lunch" (they might not work with you, but you can still eat lunch with them). In a company only space it is better, but there are still a lot that don't matter to you. If it is a team only shared space most of the decisions matter to you.

> I hate the word "sprint" which comes from the much hated "agile" culture

Lowercase agile culture is not hated. What's hated is usually completely wrong implementation of that idea and cargo-cultism.

Even more so, the whole industry of capital-case Agile.

>Who's going to write the fine-detail code if they whole day is a meeting?

In a start-up ? You around midnight. Believe in the mission bro.

I’ve worked passed midnight maybe twice in my 3 years working at startups. Both times it was because I wanted to get something done not because the founder asked. Some times I wake up in the middle of the night and, with nothing else to do, start working on something but it’s only because I want my equity to be worth something (nothing or everything) as quickly as possible so I can move on: not because I have to do these things.

> Who's going to write the fine-detail code if they whole day is a meeting?

Reminds me of the time I worked at an early stage startup. I used to take official vacation time, and disappear from company collaboration tools to get real work done.

I find this incredibly sad for many reasons.

Taking time off to work for the company that doesn't let you work for them during normal work hours.

The irony is so strong but I understand the sentiment and why you'd do it

Did not expect to find someone who does the same thing as me. I am actually kind of embarrassed I’ve taken sick days just to work without interruption or to investigate some tech I wouldn’t get company time to research (“we need you pumping out code, whats learning? You already know everything you’ll ever need!”)

I used to take sick days for that reason when I worked in an open office space. Then, I realized how dumb that was and quit that job.

That's the biggest red flag I've seen in a long time.

That’s really awful. These companies shouldn’t be allowed to exist. I mean, of course they always will, but many exist that aren’t like this.

Ugh, me too. These are really dark memories though.

Huh. During my undergrad, one of the most time-consuming courses was almost entirely pair programming. Having another person there to pull you back on track when you get distracted, and vice versa, was definitely a productivity improvement. Also less time wasted going down the wrong rabbit hole.

The chance that one of us was feeling motivated to put in the work to deal with that corner case is higher than the same chance for either of us individually. Though I guess it depends if the distracted person is more able to derail the other person, vs being pulled back on track.

Maybe “meeting” has the wrong shade of meaning here. The comparison isn’t to a pro-forma “let’s sit down for 30 minutes and focus on discussing this” meeting. It’s more to a “war room” continuous-until-it’s-fixed meeting that happens in response to an incident:

• bringing all stakeholders together with exactly one goal (in a startup-as-meeting, that’s “finding product-market fit”),

• where everyone in the room has domain expertise and heavily-overlapping capabilities;

• and any non-shared knowledge relevant to solving the problem that each stakeholder brings in with them, is immediately pulled out and put on the table, until there is formed a complete shared understanding of the problem,

• and micro-tasks / “there’s always another thing” tasks are then being greedy-scheduled by whoever’s free and able jumping to take them on next;

• with everyone keeping track well-enough of what the solution-space for each task is looking like, that at any time the person working on a task can drop it to work on something else more urgent+suited to them, and someone else will be able to immediately pick up that task — not because the other person had the time to document everything and make onboarding to the solution-space easy for them, but rather because everyone was learning all they could about everything everyone else was doing in expectation that they might have to jump in.

In regular work, you do heads-down work and then you explicitly decide to “have a meeting”, which interrupts your heads-down work for a while. In a war room, you’re always “in” the continuous meeting, and people explicitly decide to break off to do heads-down work while the meeting continues around them. (Usually with one ear open to notice if they need to jump back in and contribute/adjust the course of the plans being made.)

For extremely-early-stage startups (i.e. founders and no-one else), this is what every day looks like. Rather than dividing up the problem along lines of domain-expertise (a sort of human Service-Oriented Architecture for problem-solving, with single-person “departments”), you instead essentially act together as one “multi-core person” to solve problems.

IMHO, if this isn’t how most hours of the day at your early-stage startup look, then you either don’t have the right founders, or you don’t have enough shipping pressure (i.e. “too much” runway.)

War room is an excellent term in this case, thank you. Going to use it from now on. And this:

> Usually with one ear open to notice if they need to jump back in and contribute/adjust the course of the plans being made.

is precisely what I was trying to describe here in the comments. Thanks again.