I've gone in the opposite direction: on projects I've led, I decided to have no recurring meetings at all, very much going against the flow of the broader organization. Instead, I would set up a time when we had something specific to talk about. I wrote a short but hopefully clear description of what we needed to cover on each event that I scheduled.
I found this worked really well in practice. We actually talked more as a team compared to the ones using a fixed process with recurring meetings or "ceremonies", but the discussions were consistently useful. There was a lot more time spent figuring things out together and developing a strong shared mental model for what we were doing—some non-trivial but not quite research-level machine learning work—and no energy wasted on glorified status updates that only one person on the team cared about, or "syncs" that became increasingly less useful week-over-week.
Most other teams I've been on had this seemingly contradictory dynamic where we had too many meetings but also did not talk nearly enough. It's amazing how a bunch of recurring meetings can take up a bunch of time and attention, but somehow not leave enough space to dive deeply into non-trivial technical or strategic questions, or meaningfully talk about "meta" team topics.
A real risk is that a recurring meeting can pull out the oxygen in the room to talk about a given topic. It's too easy to put off talking about something important until the next scheduled meeting—by which time you have less context and less time—and then, if the recurring meeting isn't long enough to go deeper, the discussion gets put off even further. A team I worked on recently had a quarterly "retro", never had enough time to cover anywhere near every "retro" topic we actually needed, but also didn't consistently talk about that kind of topic outside the retro. We'd just wait until the next one rolled around. (Worse yet, this still put this team ahead of a number of other teams I've seen...) In contrast, the best teams I worked with never had explicit retros because we just talked about things that needed talking about as part of our day-to-day.
I have no doubt that this approach works better than recurring meetings, but I do want to point out the trade-off, which is that this approach requires much more management attention and energy to keep their finger on the pulse and ensure all concerns are handled, compared to their time management being on autopilot with recurring meetings.
So it's a bit of a tautology. Managers who manage time better are more effective. Who knew?
I’d also give some pushback based on scheduling: fixed meetings are a known quantity people can schedule around.
For coders and people with lives, knowing what their week looks like is critical to planning and stress management (ie in X work hours topic Y will be landed, I have X - 2 hours to have my facts in line; daily 9:15 meeting ends at 9:30, everything after 9:30 is a predictable block I manage).
Now, to the issues and whattabout’s that implies:
1) bruuuuutal meeting discipline: off topic gets killed, new topics insta-popped onto next agenda, scripts of expected responses prepared and shared (“we are green, need approval by X”). Stand if ya gotta, chess-clock if ya gotta, bring in a non-teammate for secretary duties as needed. Meetings are not gab sessions.
2) if that agenda isn’t lava hot with everyone actively getting something, W-O-W, end the meeting. Split off, 1-on-1, task-group it. Fixed project meetings are to make manager-me not have to chase anyone or anything, we are racing to get that done ASAP and the second we’re done it’s time to get the fu… <ahem> grab a coffee, and return to the activities everyone is being paid for. Gab sessions naturally follow, as needed, dynamically adapting to needs and pressures.
Managers who manage meetings manage to meet without meetings managing them. Manage time or time will manage you. The real MBA was the one inside you the entire time.
I think it seems tautological to us because it's obvious to us. But other people do not understand or care to understand or even care to think about it. You can see it in this very comment section that there are people swearing how amazingly helpful fixed standups supposedly are even on a whole org level. It's obviously absurd but they have different jobs and priorities, they don't have to understand the inner workings of the product and for them it's invisible that the meetings are almost entirely worthless for the actual workers. The meetings are helping them in their job and so it must be great for the org, that's how many people managers think.
I’ve been on both sides of this. Engineers who complain loudest about the waste of time from too many meetings will also complain the loudest about how they feel disconnected from the decisions and from the product IME.
Decisions rarely need to be made on-the-spot in synchronous meetings. You can have asynchronous approaches with shared documents and RFC processes, where you make everything available if people want to contribute to areas that they find interesting. This does not, of course, mean that decisions need to be made by committee, and people who provide feedback should understand that getting the privilege to provide input does not mean that they also get a veto.
It's quite rare to find companies that do this for the same reason it's quite rare to find companies willing to "do agile correctly" and really scope out work before sprints and not put additional work in the middle of a sprint. It takes too much effort and gives up too much flexibility for most managers to make the investment and see if it pays off.
I've had the same experience with picking specific things to discuss over recurring meetings. A few coworkers and I have frequent, short, high-signal conversations over Slack huddles almost daily, and sometimes we need to converge with others to tackle bigger problems so we set up meetings around those topics.
I really prefer this over recurring meetings. The gist of it is that you're communicating early and often when you can't solve things in isolation, avoiding putting things off or letting understandings of problems atrophy while you wait. Ironically, I do this most with my remote coworkers. They're amazing. The coworkers I have in office are much less keen to give up time for communication. They're great too, in other ways, but harder to communicate with.
Your point about shared mental models is huge. Ironing these things out with another person is invaluable, but having more than one person do it at once means it's multiplied across the team. So many people we work with are building this model in isolation with LLMs, and I'm certain it's harming our collective grasp on what it is that we're actually doing. Very strange times!
It has never seemed more important for humans to communicate with each other and have these shared mental models. To simplify rather than add complexity, to cultivate that meat-space context that gives software purpose in the first place, to understand that purpose, and so on. Interacting with each other fluidly and regularly is such a great way to make that a reality.
We had that and major part of communication just stopped. People stopped talking about issues or solving them, unless those were super large. The bar to "and now trigger meeting in a team where manager seems to dislike" was too high.
Communication larger died, except a smaller "friendship minigroup".
A large part of the effect that cars have come from massive subsidies and policy choices that push for cars over alternative options. The comparison shouldn't be "cars vs literally nothing" but rather "car-dominated infrastructure vs the same investments in alternatives". (Not to say that it's an either-or; the optimal equilibrium might still involve some mix of car investments, just far less than we have now.)
It's the folks pushing cars that are both the most strident and the most successful at pushing their "obviously correct" way onto everyone, at least in the US.
Cars are not popular becuase people pushed them. Cars are popular because the utility is undeniable.
This is true for any kind of transformative technology. Marketing and lobbying can only get you so far. If something has enough utility, it will be used regardless of what people say they want.
> Cars are not popular becuase people pushed them. Cars are popular because the utility is undeniable.
I think this is somewhat of a chicken and egg problem. Cars' utility is undeniable partially because society has twisted itself thoroughly around The Car being an assumed part of it. This societal change was both pulled (by car customers) and pushed (by car manufacturers).
Yes absolutely—I think cars have obvious utility as machines, but there has now been 100 years of building everything around them and changing laws in such a way that encourages their use: through direct and indirect subsidy, land use rules that largely outlaw building cities in any way other than sprawl that itself increases the importance and utility of cars, and various other preferential regulations that often tolerate the harms in a way that is not applied elsewhere (c.f. panic over e-bike safety vs American highway safety overall).
Cars won because they were (and are) better than the alternatives. The need for powerful individual transportation with utility has always existed, and was originally met with horses. Bicycles meet the transportation need, but not the need for utility. Cars do both, and they do it better than anything else. Even before fueling infrastructure was rolled out, you could still run a car on petroleum you bought from the chemist, which is still infinitely better than the acres of pasture you need for horses. If you had an early diesel, it would run on oil, which is even easier.
The idea that cars needed all this infrastructure that other alternatives didn't just doesn't match the reality of the history of the automobile. And yes, we've leaned on those advantages in the century since, which has also created vast areas where a car is necessary to participate in society, but we only did so because the advantages and utility were so undeniable.
We can't read everything, so we need markers of taste to figure out what is and isn't worth engaging with. AI tells are markers of drastically bad taste.
It's a great time to get into programming languages stuff: designing domain-specific languages, building new tools/abstractions and, especially, formal verification. If you're mathematically oriented, you can explore formalizing mathematical proofs in Lean.
LLMs have really revitalized interest in these areas. AI can really help navigate the initial learning curve, can do a surprising amount of "heavy lifting" and can make tedious but useful work much easier. Do you want your little language to have a language server and nice editor-specific syntax highlighting? Do you need to write a parser with decent error messages? Do you need to prove a bunch of largely straightforward lemmas to get to the proof you actually care about? All of these things are easier (and, hopefully, more fun) than they were a few years ago. But, at the same time, there is still a lot of room for human insight and design in this process. There are a lot of areas that AI can't handle (or, at least, can't handle well) and, of course, nothing stops you from doing the fun stuff by hand even if you could hand it off to Claude.
And, of course, all this PL stuff was fun before LLMs. It's even more fun now even if you don't want to use AI yourself, because more people are doing and talking about PL stuff online, and there are more tools and libraries you can use yourself.
You can have both: you start with a small, mathematically inspired algebraic core, then you express the higher-level more user-friendly operations in terms of the algebraic core.
As long as your core primitives are well designed (easier said than done!), this accomplishes two things: it makes your implementation simpler, and it helps guide and constrain your user-facing design. This latter aspect is a bit unintuitive (why would you want more constraints to work around?), but I've seen it lead to much better interface designs in multiple projects. By forcing yourself to express user-level affordances in terms of a small conceptual core, you end up with a user design that is more internally consistent and composable.
Every layer of the organization tells a more rosy version of the truth up the chain of command. The programmer might tell the PM that they're running Apache software with the serials filed off, but by the time that filters up the chain to the CEO / Board, the product is "fully proprietary and 100% built in-house"
The most productive teams I've seen (eg at Jane Street) rewrite things all the time, and still move faster than any "normal" teams I've seen. I remember when I interned there over a decade ago, they were already on like the seventh? version of their incremental computing framework, and were building a new build system. But they were also incredibly effective at getting things done both on a per-engineer basis and in terms of making money.
I found this worked really well in practice. We actually talked more as a team compared to the ones using a fixed process with recurring meetings or "ceremonies", but the discussions were consistently useful. There was a lot more time spent figuring things out together and developing a strong shared mental model for what we were doing—some non-trivial but not quite research-level machine learning work—and no energy wasted on glorified status updates that only one person on the team cared about, or "syncs" that became increasingly less useful week-over-week.
Most other teams I've been on had this seemingly contradictory dynamic where we had too many meetings but also did not talk nearly enough. It's amazing how a bunch of recurring meetings can take up a bunch of time and attention, but somehow not leave enough space to dive deeply into non-trivial technical or strategic questions, or meaningfully talk about "meta" team topics.
A real risk is that a recurring meeting can pull out the oxygen in the room to talk about a given topic. It's too easy to put off talking about something important until the next scheduled meeting—by which time you have less context and less time—and then, if the recurring meeting isn't long enough to go deeper, the discussion gets put off even further. A team I worked on recently had a quarterly "retro", never had enough time to cover anywhere near every "retro" topic we actually needed, but also didn't consistently talk about that kind of topic outside the retro. We'd just wait until the next one rolled around. (Worse yet, this still put this team ahead of a number of other teams I've seen...) In contrast, the best teams I worked with never had explicit retros because we just talked about things that needed talking about as part of our day-to-day.
reply