I suspect it depends a lot on the standup. My favorite place I worked had a great one. 10-15 minutes every morning, a brisk and helpful way to get focused, line up the help you needed, and kick off the day. I miss it deeply.
Conversely, I did a project once where we had not a single stand-up in 9 months. CEO would come up with some designs, I'd asynchronously comment on them with questions or concerns, then slice the designs into tickets that'd I'd pump good amounts of context and detail into, estimate and prioritize, then chuck my engineering team at them. We'd all asynchronously work on them. If they had questions, they'd slack me. This across five timezones.
Once or twice we'd have a miss on a ticket probably because I didn't define it well enough, but I'd just point out the issues in code review and they'd rewrite as needed. Oh well.
Meanwhile we all have a phenomenal quality of life because our entire day schedule is set on our terms. And we delivered a whole ass SaaS product from scratch in like 9 months for around 2,500 engineering hours if my brief math is right so the founders were happy.
2500 hours in 9 months could be two developers logging hours on the project. The project may have had stretches when dependencies limited the amount of work that could be done, and often one assumes at least an hour of non-billable time lost to miscellaneous business shit, per IC, per day.
The rest of the team (not logging engineering hours) may have included a (probably part-time) designer and likely some kind of project manager (likely also part-time—that is, managing 2+ projects at once for different clients).
7 (billable, on average) hours * 47 weeks (assuming 25 weekdays lost to holidays, sick days, and vacation, over a year) * 5 weekdays only yields 1,645 hours per worker per year, anyway. Divide by four, times three, to get ~9 months, and 2500 hours just looks like two full-timers on the project, really, if we're talking billable hours, but that's also (it reads like) not counting support roles and non-dev contributors like design or PM or maybe testers. Or it might be one full-time and two half-time devs, or whatever. I'd guess not more than four developers contributing significant time, anyway, based on the numbers and with fairly pessimistic assumptions for how many hours could be logged a week, and maybe as few as two.
I'm rough on the math cause I don't have the billing sheets in front of me, but the other person was pretty close.
The team I managed was me, functioning as frontend lead / architect / engineering manager as well as individual contributor. I then had three junior / early mid-level frontend engineers working with me.
I was pulling 40-60 hour weeks (contract so I didn't mind, just meant more money), the other devs were between 10-40 depending on how much work I could lay out in a sprint. Timezones were Taiwan, somewhere in Europe can't exactly recall, NYC, and California iirc.
That accounts for the frontend. There was a data system that was mostly built when I showed up, by one full time engineer at the startup. So that would be another 40 x 4 x 9 engineering hours on whatever he was working on in the meantime.
Then there was an API that would middleman requests to the data system and build out models and handle customer accounts and shopping carts and other data adjacent requests. That was one full time backend engineer over whom I didn't have responsibility, so add another 40 x 4 x 9 for that.
Finally, the designer was just the CEO. He would draw things up on figma and I'd slice them into frontend tickets. Now that I think about it I think the API engineer was consulting the same designs as he built out the API, I'm not remembering exactly.
So technically my original estimate is just for the frontend, it cost more when considering the whole system.
We "released" every merge into the main branch, internally. The CEO would constantly be giving feedback. It caused some friction occasionally, the classic "right the alignment is slightly off but what do you think about the actual interaction" type shoulder bumps, nothing major. Good feedback loop that basically daily aligned where I should be directing frontend priority.
There was a major customer facing release where a couple core customers were brought off the no code platform onto the new system, that cooked for about two weeks while we collected feedback and engineered against it, then another major release where I took advantage of the respite to do a major rewrite of the naively implemented request management system and fixed up some auth stuff, then another big release and then everyone else is brought over.
I still work a couple hours a week on the projecy but no longer as a leader. Looks like releases are still just kinda whenever, which I think is fine. There are "sprints" and have been the entire time but always quite informal.
I think a lot of this is just personality driven. I don't find meetings to be a way to get focused or a way to "kick off the day"; indeed, I always need a break afterward. Yes, this applies to a good 10-15 minute standup. And I don't really know what people mean when they say things like "line up the help you need". Why would I wait until a meeting the next morning to reach out to relevant people for help?
However, I recognize that lots of people don't feel the way I feel about any of this.
> Why would I wait until a meeting the next morning to reach out to relevant people for help?
It's hard to notice you're stuck when you're stuck. For a lot of programming problems putting your head down and ploughing through is the right approach - but you do need to come up for air occasionally. And if you need help then it can be hard to ask without feeling like you're interrupting someone else's work, so having a regular point where everyone's already not going to be in the middle of deep work is useful.
Again, I recognize that this is a "to each their own" situation, but I don't relate to this at all. I know when I'm stuck and I know who to ask (or who to ask who I should ask) and I have good asynchronous communication tools where I can ask people things without immediately interrupting them.
A lot of people believe they know the optimal time to reach out. But with my manager hat on, it's also true that a lot of people wait well beyond what's optimal for the organization. Things that can get in the way include pride, anxiety, laziness, a tendency to procrastinate, underestimating the resources available, and overestimating the cost of interruption, and underestimating the cost of delay. Maybe you are the rare sort of person who is perfectly calibrated. But if so, know that it's rare.
No, I'm not that rare sort of person. But it also isn't in the organization's best interest to force everyone into a single style of work, rather than supporting people in their own preferred style of work. That's why management is hard! If it were as easy as "having a status update meeting every morning is the optimal process for everyone", we could pay managers a lot less :)
I think there's conflict between "own preferred style of work" and what's effective for a given team. If there's a team of people who are, say, doing fine communicating only via pull request, then I wouldn't mess with them. But if somebody of those habits wanted to join a team that was into pairing and a faster release cycle, then I would suggest that new person look elsewhere. So although I don't think it's in the best interests for a large org to force everybody to work similarly, I do think it's in an org's interests to support teams finding an effective joint work style, even if that means a given individual might not find it optimum or might even have to find something else to do.
For what it's worth, treating my social anxiety made a big difference for me in this. A bad meeting is still draining, but good ones can be positive and energizing.
> Why would I wait until a meeting the next morning to reach out to relevant people for help?
Having a specific time for it makes it easier for people to do. It normalizes it, so it lowers the bar to ask for help. Also, note that this comes after a discussion of what people are working on for the day. So it's natural to say "Looks like I'll be getting into the foobar system today; who worked on that most recently?" And it's also natural for people offer help without being asked, so that lowers the help bar futher.
See, I used to think like this, that I have social anxiety. But as I've grown older and participated in more kinds of social situations over the years, I've learned that I don't, actually, have social anxiety problems; I love socializing, I think even more than average (the pandemic social starvation taught me this lesson).
What I have is a personality, which means that I have a set of preferences for my interactions, just like everyone else. It's fine that some people prefer group meetings, and it's fine that I prefer documents, chats, and 1:1s. We're just different people with different personalities. What I don't like is the group-meeting-preferrers seeming to believe that their preference is normal and my preference is aberrant. I find that condescending. I'm happy to accommodate other peoples' preferences, but I don't need to change my own preferences to align with theirs in order to do so.
> Having a specific time for it makes it easier for people to do.
Again, I don't relate to this. I agree with you that it makes it easier for some people to do, but I'm not in that group of people. My point in this thread is that people are different.
> So it's natural to say "Looks like I'll be getting into the foobar system today; who worked on that most recently?"
It is much more natural for me to say "`git log`, what have people been up to in this system recently?". I prefer to read text than listen to verbal explanation. I also don't usually want to be offered help without being asked, I just want to go read and work.
Again, I'm not at all saying this is the one true way, but please believe me that I just have different preferences that make status meetings less interesting to me (and I think a lot of other people) than they seem to be to you (and many others).
I believe that you have different preferences. And I'm happy to take your word that you don't have social anxiety. However, loving socializing doesn't prove it. I loved it and also often got anxious. Now I love it as much but am not as anxious, which has made the social parts of collaborative work easier for me.
As to the second bit, I'm sorry to be contradictory, but having a specific, in-person time where asking for help is normal and expected lowers the barriers for literally everybody, because the particular barriers being lowered include costs like "figuring out how to contact the person", "being concerned about catching them at the right time", "contacting the person", and "delay in receiving a reply".
If you have a different approach you like better, that's great! The way a team works should match the needs of the people on the team, and of the team culture. There are plenty of teams out there, and good work gets done lots of different ways. I hope everybody ends up on one that works for them.
That said, "personality" is not an immutable set of characteristics, and not all of the way people express their personalities are equally good for collaborative work. As an introvert who also wants to get things done at the scale only a team can provide, I'm just always going to have to stretch myself.
I may also decide that I can only stretch myself so far, and so my limits may mean that there are kinds of work I'm just not well suited for. E.g., large companies demand too much of what I think of as "political" behaviors for me to find the work sustainable. So although I think we should generally try to honor each other's preferences, we must also be honest about the fact that not all preferences are equally suitable for every kind of work.
I disagree with your (in my view) far too prescriptive certainty that a lot of synchronous communication is universally best for collaboration. It is a common view (especially among managers) that I believe is simply wrong, and based on vibes rather than empiricism.
It's not universally wrong though. All I'm saying is that it isn't universally right. It just isn't universally anything. A good manager or lead should be able to look around on some teams and realize, hmmm, we aren't getting much value out of all these synchronous touch points, and on other teams they should realize, hmmm, we could use some more frequent synchronization here. But a manager or lead coming in with their own prescriptive preference for daily synchronous meetings, and failing to notice if they aren't valuable, is not doing their best work, IMO.
I have been on both kinds of teams. Indeed, right now I'm on a team for which I think daily morning meetings are working really great, regardless of my own personal preferences. But I've also been on teams where they are working terribly and only the manager is happy with the situation, and that's bad.
For me it's based on a pretty simple feedback-loops model. The length of the feedback loops limits all sorts of important things, especially external responsiveness, adaptation, learning, and error correction. Collaboration requires co-laboring.
There are circumstances where collaboration isn't particularly necessary, of course, so maybe that's what you're looking for.
I agree of course that there are plenty of ways to have bad collaboration even with short feedback loops, as in your last example. It's not a panacea. Nothing is.
We talk for a full hour every day, but there are only usually 5 or 6 of us, and we are all invested in every feature, so the meetings end up being a fairly detailed review and feedback on everybody work.
I got pushed to a team that did this. I decided to try to extend the meetings for as long as possible with the goal of eating so much time nothing got done anyday. The daily stopped shortly after
