4 ms·

> 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

• metb 5y ago
  > 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.
  • obedm 5y ago
    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
    • 8note 5y ago
      Doesn't let you do the work that you want to do* The thinking and talking is still work
  • christophilus 5y ago
    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.
  • goodpoint 5y ago
    That's the biggest red flag I've seen in a long time.
  • alanwreath 5y ago
    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!”)
  • sodapopcan 5y ago
    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.
  • steve_adams_86 5y ago
    Ugh, me too. These are really dark memories though.
• reader_mode 5y ago
  >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.
  • edgyquant 5y ago
    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.
• mojuba 5y ago
  > 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.
  • DougBTX 5y ago
    > 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.
    • mojuba 5y ago
      Right, thanks for the correction, I meant Scrum of course.
    • bluGill 5y ago
      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.
      • marcosdumay 5y ago
• smichel17 5y ago
  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.
• jusssi 5y ago
  > Who's going to write the fine-detail code if they whole day is a meeting? You do it in the meeting, while others discuss things that aren't your concern. If it's something hard you really need to focus on, you tell the others to either shut up for a bit, or lend their eyeballs for a while. Also, the boring stuff gets done just fine in a group everyone getting their last month's pay depends on it. Been there, on both counts. The only thing I miss about it is how much you get done, compared to being a €€€ consultant tied to a spot with red tape.
• derefr 5y ago
  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.)
  • mojuba 5y ago
    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.