> Being in the same space physically I think speeds up a lot of things. In small teams and esp. at early stage startups your whole day is a meeting where things are discussed and resolved spontaneously.

Who's going to write the fine-detail code if they whole day is a meeting? It may change from case to case, but for some small teams the biggest challenge is to produce something so good that it out-competes the product of teams significantly larger. A brilliant idea gets you 5% of the way, the rest is getting busy with very boring details and corner cases.

My small teams and startup experience: none of that boring work gets done as soon as there are two people together. Simply put, social interaction is way nicer than boring work. This is not just technical development work, but even commercial research. I know this is a thought crime, but I sometimes feel like it would be a good idea to lock the socialite sales person in a room with no human contact whatsoever until they finish that Excel spreadsheet.

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

I work remote at an early stage startup, I’m not sure you’re right. It might be faster to work together but only by the amount of time it takes to type. We’re on slack talking all day and have video meeting when needed. We work fast as it is so I’m not sure we’d gain much by being in person (other than social stimulation.)

I work on site in an early stage startup, and I think it's about commitment to a communication model.

We have a 2x2 grid. On the top we have 'in person' and 'remote'. Down the side we have 'synchronous' and 'asynchronous'. I've worked in companies trying all five (yes) of these combinations. This is my experience.

- in person, synchronous: everything happens in meetings. Business likes the certainty of meetings, engineering doesn't like the disruption. With the right accommodations, most people are content.

- in person, asynchronous: everyone's in the office, and no-one knows why. The CEO offers vague maritime platitudes.

- remote, synchronous: "can you go on mute" now causes a company-wide gag reflex. Everyone's happy because they can apply for new jobs without being noticed. (Seriously, the company I worked in that did this had absurd turnover, for this reason.)

- remote, asynchronous: engineers contribute to discussion when they have time. Hotshot managers want there ideas validated now, though. Despite this contention, most people are happy.

- hybrid: A cabal has formed in the office. Finally, it formalizes when a Jira account named 'Office' appears. When a remote worker creates an issue, the cabal convenes to decide a response. There is no room for negotiation. Gradually, the remote staff evaporate. Only the hive mind remains.

I'm in the same boat with the addition of a Mumble server. We're always a keypress away from talking to each other.

You can have that remotely. In my team we (8 people) spend our whole day on a visio conference room. We’re mainly idle but we use it to ask for help, discuss decisions informally, vent, talk about whatever(games, movies, etc.), all of that exactly the same as in the open space, but better because we can still disconnect if we need to focus.

If we need a real meeting or need to talk with a specific subject, we just go to another conference room, in the same way we’d use a meeting room in the office.

The thing though is that we have a dedicated device for the visio. For now it’s a Cisco DX but it could work with an iPad for example.

Are you not self conscious, constantly?

The massive difference between what you describe and sitting in person is body noise. A cough in an office is normal while a cough in a video chat gets everyone’s attention.

I feel like it would be very draining but it sounds like you’re enjoying it?

We just mute ourselves when we’re not talking an close the camera lid if we’re not comfortable with it.

I used to be self conscious about it, but I think the company culture plays a role. We had these devices and this behavior way before COVID because our teams were already remote (5 people in a city in France, 2 in another, 2 in Tunisia…), this is the company way of keeping remote people close to one another. The whole company works like this because all the teas are distributed. I went from not caring about it to loving it, and if I switched company I would do my best to advocate for such a system.

I usually use Push-To-Talk mode on most video calls when I can. I'm not perfect about it, but I do manage to mute probably 90% of throat-clearing noises or 75% of my typing.

I'm also divided, and I still go to office because of that (at the moment we can sort of choose it ourselves), 1 or 2 days a week. Sometimes 0. I enjoy the time in the office, I see who is there, try to gather a big group for a good lunch and talk as much as I can. At home I focus on coding, document writing etc. I'm all for letting teams hash it out among themselves.

One argument that I think fails in the long run is that creativity drops. Maybe it does, in the short term, but if people are happier at home, and more companies will support it, new ways of being creative or even together will be found. I wouldn't worry so much about losing the "classic, old" way creativity worked before, there is so much to be gained and so much yet to be learned. Give it some time, embrace it, see where it takes us.

One example of growing creativity for me has been: One colleague in our team is from the US, he's the only one. Pre-Covid he'd be on a speaker in our meeting room, no cam on. Since Covid he has his cam on, same as everyone else. We engage much more in small talk, recently we got a tour of his house and garden via webcam. What a nice guy! We wrote some patents together now too. Even though we are 8 hours flying away from each other. The talent pool for teams just grows much bigger.

In my experience, reasons like "spontaneity" and "dynamism" are used to cast lack of vision, poor planning and management, and amateurish execution in a positive light. YMMV.

> Being in the same space physically I think speeds up a lot of things. In small teams and esp. at early stage startups your whole day is a meeting where things are discussed and resolved spontaneously.

I do not understand how people can get work done in an environment like this. I've had similar experiences and "the whole day is a meeting" only served me for unnecessary interruptions, useless workplace banter and unsatisfactory results.

I do think some work circumstances can benefit from periods of nearness.

Programming is not one of them. ;)

People who tilt towards extrovert thrive in an environment like this.

I think that small teams with high throughput communication can work in place and remote. In place the high communication is there by default where the default remote position would probably be lower communication / more isolation. It doesn't have to be this way of course, but it would require the remote high communication model to be put into action intentionally.

It's worth remembering that this high communication method isn't really scalable too, and that larger teams trying to follow it will find themselves dedicating a larger % of their time to noise. It would take some intentional actions to move away from it as the team grows.

> this high communication method isn't really scalable too

True, from what I've seen the threshold lies somewhere at 10-12 people, assuming a mixed team engineering + marketing + etc.

But while you are small you can take advantage, remove all formalities and be in-place as much as possible. You can move so much faster, having trivial respect and ethics in mind, as in don't talk loudly about sales just next to an engineer who seems to be working on something. And vice versa.

You can reproduce it somewhat with an always open mic & video chat on all sides. I've done it once, it was remarkably effective.

Many people who like remote work although also do not like something like that arrangement although.

> Being in the same space physically I think speeds up a lot of things

...and also makes a lot of people unable to focus.

Communication points are a bottleneck. Smaller teams help, but the ideal team size for accomplishing a task is 1.

Putting engineers in a war room or open office is only going to irritate the ones who want to spend their time doing deep work. And those are usually the better ones.

Look at the entire crypto space. $1.5T+ of value and growing and the vast majority of it is built remotely, sometimes anonymously, and it's one of the most free and spontaneous industries.

the best of both worlds would be to work remotely most of the time and have (frequent?) sprints where you get to know your coworkers and also engage in this kind of high bandwidth settings.

The solution to this is gather.town