Three-day no-meeting schedule for engineers
medium.com
medium.com
I'd really rather not say there is a "Pivotal" style as much as an Extreme Programming paradigm. Extreme Programming says that an environment is better when you work normal hours. It states that an environment is better when there are fewer meetings. It states that an environment is better when you try paired programming, test driven development, continuous processes, simple design, good communication, etc etc etc. I think all of these things are very good. I also believe a few of these principles don't work well for specific individuals. There are principles that effect the business (fewer meetings, sustainable pace, continuous practices). So far I have always seen those principles as good. There are also principles that effect the individuals (paired programming, test driven development, close proximity for communication). I have seen those not work well for some individuals and should be adjusted to your individual employees.
How does this help with discovery of issues that other folks on the team may have experience/suggestions solving? I.e. do you require everyone to read the daily round up?
We have an absolutely open environment. It's a side effect of our process.
I'd love to see an app that analyzes the internal meetings that happen inside a company and flags the repeat offenders. I've always found that a small percentage of people hold the most meetings. It also can be a bit awkward to reject their meeting invites constantly.
Leaders should remind people about the time-cost of meetings (here's a calculator to help: https://hbr.org/2016/01/estimate-the-cost-of-a-meeting-with-...). There are meetings that can be beneficial for alignment, but then there are the reoccurring ones where people just want to know what you're working on.
Anyways, I'm working on a tool to help cut down on the "what's going on" meetings: https://www.fridayfeedback.com
In Lean Manufacturing, a common process improvement technique is to tighten some constraint. E.g., if you normally have 10 boxes of parts in play, you drop it to 9 and see what happens. Probably something will happen, as they ended up at 10 for a reason. But then you consciously solve issues until 9 is as smooth as 10. The metaphor they use is ships in channels: if you lower the water level a bit, it will expose rocks, which you remove. Then you lower the water level a bit more.
My guess is that if these teams are doing weekly retros, they'll feel the pain of compression. People will then brainstorm ways to make the least useful meeting unnecessary. Or to make a longer meeting shorter, and therefore more efficient. First they'll start with the easy things, but eventually they may move on to rearranging workflows, cross-training, and maybe even swapping people among teams.
It's really weird to me that in office-work meetings take priority over direct value-generating work. Compare that with a factory floor or a restaurant, for example, where everybody gets that it's bad to randomly stop direct productivity. Hopefully having clear time constraints will help reverse that.
I think, by and large, we understand the cost of meetings, and don’t casually organize them without going through the alternatives. It’s not rocket science. My thought process is generally:
0. Before anything, come up with a written agenda and goals for the communication. Don’t move past this step until done.
1. Does this communication even need to happen? Maybe there is an internal document already I can point people to.
2. If not, Can this be done async over E-mail?
3. If not, can it be done over chat?
4. If not, can it be done in a series of 1:1s between me and each attendee?
5. If not, then a meeting has to happen. What’s the true minimal list of required attendees? Who is optional? I am loathe to waste the time of a productive individual contributor if I don’t have to. If I can invite his/her manager instead, I will. Sorry, that’s the Faustian bargain you make when becoming a manager!
6. What’s the shortest possible productive duration?
7. Is there a time slot that is miraculously free for everyone, respecting time zones and working hours for people?
8. If not, is there a time slot that works for most people?
If, again by some great miracle, there are multiple time slots that work, I favor ones that are adjacent to other meetings in their calendars, so as to not break up a productive no-meeting block.
I hate those ones.
If your programmers are taking laptops to meetings to write code while you are holding the meeting, you should consider a career in yak-farming not project management.
Also we need to schedule a meeting to find out why we are behind on our deliverables because of last weeks meeting taking most of the day putting everyone behind.
That one made me giggle.
Or as one of my friends at that place had as a wallpaper "The beatings will continue until morale improves".
I set my own schedules, timelines, I prioritise bugs and maintenance and I handle buying anything we need as well having complete freedom in the technologies I choose to solve problems (currently moving to TypeScript for front end stuff for example) - his attitude is to hire good people across the business and then get out the way as much as possible.
The boss sets overall goals and we agree together on what is achievable in a given time period.
Honestly my job has made me remember what it was I loved about programming (solving real world problems that have a measurable impact).
Even the fact I inherited the worst codebase I've ever seen doesn't get me down because my boss knows how bad it is (it's why he got rid of the outsourced company and hired a programmer in house) and I get to work on a bunch of cool problems (production scheduling in a varied environment, global logistics (we import from China and India), some C# stuff (production control), Android (inventory control, scanners)).
I actually get to 5pm and want to keep working but the boss bollocks me if I stay late (even though he does most days).
I'd have to be offered a spectacular pay rise to even consider working for a 'tech' company again.
I'm routinely asked to join after-hours deployment calls that last hours and which my contribution is minimal, "just in case". You may not be casually organizing them, but there are plenty out there who are.
For makers, there are only 2 time slots: before lunch and after lunch.
True, but it forces meetings to compete with meetings rather than development in the schedule.
That was my first thought, too. I was talking once to a guy who was hiring for a developer position that he couldn't get filled - he told me that he was sweetening the deal by ensuring the dev candidates that they wouldn't have to attend any meetings; he would attend all the meetings for them so they could focus on coding. I had a sneaking suspicion that they realized what he didn't realize... that they'd be on the hook not only for implementing everything that was discussed in these meetings but also interpreting them through him.
This is on Chrome 66.0.3359.139, Windows 10, fullscreen on a 1920x1080 screen. I get the same layout issue in Firefox.
Meeting # 2: No seriously, how many more images can we fit on the page?
Same meeting every week at pininterest
A random interruption by an engineer when you're trying to focus is much more disruptive because it's unplanned and often pulls you right out of the zone. Often times, especially for more senior engineers, an enormous amount of patience has to be practiced as you listen to someone ramble on as the context in your head flutters away, while they go in circles explaining the problem to themselves.
This is all part of the job though. People don't have all the answers and the questions are often poorly defined. My skills wouldn't be nearly as valuable if the problems were so cut and dry that I could just program a solution straight through without interrupting anyone for clarity. I don't quite get the hang wringing over being interrupted. It happens, and it happens especially more as you get more senior. Some of the best solutions to problems I've come up with have not been technical, but have come about by talking to people and realizing that maybe the technical solution we were pursuing wasn't the best one, and we could save a lot of time and money by solving the problem a different way.
When you combine that with coworker interruptions and the need to eat I can end up with an entire day where I can't solve anything more than trivial problems.
I can always stay late or work on the weekends but I don't really have any desire to eat into my free time because management wants to constantly hear updates from me every day about how the very work they are interrupting is going
When any manager asks why you just tell them and explain. Seems to work fine.
A Product asks the dev manager how soon something can get done, so he urgently messages me asking for an eta. At a similar time, a product person messages me asking for the same thing.
And this is after the work is planned, pointed, and ready to work.
Worst of all, at the same time my product team is asking an eta, they're working with the marketing team to change the story!
At my current job I have about 10-15 meetings every week, and I'm an IC. It drives me crazy. I feel like I have to fight tooth and nail to get time to work on the project I'm assigned to.
With things like that, though, you can a) pull the engineer off for truly urgent 'done by Friday or we lose the customer(s)' issues, and b) losing some time due to interruptions isn't really world ending. For (a) to work you'd also probably want to stop having them interrupted.
Trying all the latest javascript framework is not important to the business, but but is your best person is free to try each fad, every once in a while he will be able to say "this one isn't just a fad we should use it". It is thus important for someone have time to do this.
Trying some new tool is not important, but it might long term result in better quality if the tool turns out useful.
Upgrading the CI system might not be important, but if you let it fall out of date you get into trouble.
Stepping back from the day to day schedule allows the best engineer to focus thinking up a better solution. There are many things that are done "because we have always done it that way", but in fact the pressures of a 8-bit CPUs and limited memory 40 years ago drove that decision and there is a better way that modern CPUs could do now if only people weren't blinded by how it has always been done. The proof of concept will get management excited enough to make this the number one project, but right now they can't imagine the better way is even possible. (and the best engineer will sometimes discover the algorithm isn't actually possible)
In short the unimportant projects the best engineers work on should be largely self directed. There is the following items that are a consideration so long as they don't take up too much time. (if they add up to 25% you need someone assigned to that problem)
The best engineer is also free when a customer discovers a show stopper bug. If it is easy he can get the fix done in a couple days without interrupting the main team.
The best engineer is free to tell marketing which ideas are possible and which is impossible. He can also help workout timelines. Thus ensuring that the next project is actually possible in the time given.
The best engineer is there when sales says "I could make this big sale if only we had feature..." - some of those features can be done in a few hours and make a lot of money. Others take years and lose money - but the salesman has someone to ask before making a promise that cannot be met (that doesn't mean the saleman will ask)
This is also a rotation - your second best developers will be playing "leapfrog" to the best and then your best developer gets rotated into a valuable assignment while the new best engineer gets to lead a project again.
If your company has any size to the engineering team you can find those engineers who are self directed who will enjoy the lest important project
"We only have 10 mins so let's get to the point"
I've found polling to be a good way to handle this while avoiding the problems of being interrupted yet still being reasonably responsive to coworkers needing help.
I take a short break every 20-30 minutes to avoid health problems from sitting too long [1]. Those breaks are a perfect time to check email and chat for requests for help.
My notifications are set so that when I get an email or chat I get a banner for a few seconds in a corner. If one comes in while I'm in the zone, I can assess it without losing flow because I know I've got a break coming up soon, and so I only have to decide if the incoming message is so important it can't wait for the break.
I get those notifications on my phone, so I just keep my phone face up next to my computer, so I can easily glance at the notifications, but I'm less tempted to respond.
- no headphones: you can talk to me
- headphone covers one ear: you can talk to me if it is important
- headphone covers both ears: only talk to me when the building is burning
It's not perfect by any means but it worked quite well.
It’s best if the people you work along side all establish this same rhythm so you don’t have some people interrupting others who are in a heads-down period, or on the other token, people missing important meetings because they’re catching up on their work. It’s even better if these periods correspond with your sprint/development schedule as well.
We’ve started enforcing this at my current company by having a calendar bot that automatically deletes meetings on certain days if engineers are on the invite list. It was painful at first but everyone eventually got on the same rhythm and now I can actually get the time to complete my work.
Yeah, agreed. I've started watching the balance between meetings and interruptions, and I've noticed that too many interruptions is often an indicator of too few meetings and/or poor planning, while too many meetings is often an indicator of not enough one-on-one communication in the office.
I'm fantasizing about something to schedule micro-meetings. Not a heavy hammer like days of quiet time, just something lightweight that only protects my flow-time a little bit, not a lot, by design. I want to and expect to have to talk to people, I'd just get a small amount of control over when, instead of an interruption right in the middle of my thought.
Yeah, I just want to be able to fence off 10-20 minutes of flow at a time, and let a couple of questions queue up so I can answer them both at the same time.
The worst days are when I'm getting single interruptions every 5-10 minutes.
I find that a lot of bad meetings are driven by procrastination: The person holding the meeting is doing it as a way to get out of work. Other times, the person holding a bad meeting has an inflated ego and thinks a whole bunch of people need to pay very close attention to something that doesn't really matter.
If your organization doesn't have these problems, then great!
By contrast, working from the comfort of my home is pure bliss. I have my standing desk and large monitor. I have natural sunlight filtering in through the window. I see some trees and hear the sounds of my quiet residential street. The rhythmic cadence of my mechanical keyboard soothes me and quietes my nerves. I’m focused and ready to take on a challenge of any size or complexity.
Meetings while WFH are not a major distraction. The other participants are cleanly separated from my world. I have a high-quality headset and microphone, which takes away the stress of being misunderstood. I can easily show my screen, or say nothing at all while tuning out a meeting that isn’t helping me get my job done.
I for one am waiting with bated breath for the world to catch up with the idea that some types of work are best done from home. Offices are the true black holes into which human productivity disappears.
I think the key take away is that there should be options, what works for one doesn't for others.
Pretty much the same for technical interviewing as well IMO. We'd probably like it a bit more if we at least got to choose the format.
If you want to talk about linked lists and Chicago piano tuners and things, fine, I actually remember data structures and algorithms quite well even though I took those classes 15 years ago. If that's the majority of the interview though, well... it's probably not a good cultural fit. I want to make sure that the people I'm working with are human beings I can tolerate being around 40+ hours/week, and that I can trust them to make reasonable decisions.
You're assuming that the height of the bar is tied to how good people are at their jobs. You're also assuming that having a high bar has to mean that the interviews must be a bad experience for the candidates. Neither of those are true.
If you want me to do the same sort of work as my last job, I'm naturally prepared - I've been doing it for years! But then if you interview me about unrelated garbage with no warning, I'm going to think less of your process and of your management skills.
I like good interviews for the same reason I liked most of my exams: it was a chance to show off what I've learned in a compressed format.
I like being around lots of people and having face-to-face conversations to work through problems.
Also, India is not that cheap anymore (roughly 1/3 for an engineer), and it's only getting more expensive.
The corollary to this is that it makes leaving Work at the end of day a lot easier. Once I leave the physical building where Work is done I am no longer working.
Having Home separated, both physically and mentally, from Work makes both more easy to focus on.
We meet once a week. That day in the week no work is done. Meetings are somewhat productive, and they are "required", but they don't get work done.
The key concept Cal talks about that's relevant for this discussion is "attention residue". When you switch from low-stimuli, high-value work that requires deep focus to high-stimuli, shallower work (like meetings), it can take up to 30 minutes to really switch back to focus mode again.
Relevant excerpt on attention residue - https://hackernoon.com/excerpted-from-deep-work-by-cal-newpo...
It's definitely a culture thing. I've worked with teams across the spectrum, and, personally, I definitely lean far towards async communication being the best most of the time. There's times when you can't beat a whiteboard session, but those are the exception for me.
Email is a medium that should require a little bit of thought and deliberation, and if you're doing it, you can't do much else. Incoming-email-driven development is one of the more frustrating and wasteful processes I've suffered through. Ping ping ping, bouncing all around, not concentrating.
It's also worth trying to cultivate some self-reliance in your coworkers, so they learn how to find information and solve problems on their own, without needing their hand held every step. It's sometimes overwhelmingly difficult not to send back a lmgtfy link to some questions.
I sometimes takes days to respond, unless something is truly urgent – which of course it almost never is. For whatever reason this pisses some people off, but they also learn that the best way to get an immediate answer out of me is to call (I work 100% remote.)
I want something that forces people to try to answer their own questions for a few minutes, or at least expect to wait, before asking. When there's a small cost to asking the question, a high percentage of the time, the request will vanish on it's own. The asker will answer their own question or realize the question wasn't what they really wanted to ask.
Part of the point of what I'm suggesting is to allow people to cancel their request. With my app suggestion, I'm hoping/expecting like half the interruptions (random made-up number) to just go away. Email doesn't do that, in fact it gets worse with email, you waste time reading the question and again reading the answer, or worse, answering the question only to find out the "nevermind" email was buried further down.
Email doesn't help me queue up or schedule micro-meetings with people. Email doesn't do anything to work around scheduled meetings. Email is a black hole from the sender's point of view, they don't get any feedback other than a reply, and they don't know when to expect a reply. People who want immediate help will send email and then walk over and interrupt after a few minutes anyway.
Email is a communication channel. I'm not looking for a communication channel, I'm looking for a scheduler & queue for micro-meetings.
Email could work, of course, if the company sets up rules & expectation. If people knew they were required to send email before interrupting someone, and if people could count on a reply within an hour for anything, then email might be adequate, but as it stands, we already have email and we still have an interruption problem, so it's clearly not solving the problem.
I see where you're coming from though w.r.t. communication vs. scheduling. I found this on a quick search, which has a free tier that I might try: https://calendly.com. Still, my worries are that:
1. it's not like email/calendaring/slack will go away, so now I have yet another tool to maintain (at least Calendly have calendar integrations)
2. like email, it could be abused, just in new ways I don't know about yet... what problems will arise that drive us towards more new tools to solve them?
I'm not sure the marginal improvement over using email/slack/calendars, plus some sort of rules/expectations, would be worth adopting another tool, but I am curious to see how it works out.
What I'm instead thinking of is essentially a message queue that holds any messages directed at you until you want to respond to them, and then they're all pushed to you at that time. This would also allow you to naturally auto reply to everything ("this user usually checks things around noon and 5 everyday").
Who knows, it could be a bunch of human nature that needs training that no software can do. I just know that I get a lot of "got a second?"s a day and would love a place for those to sit until I decide to get to them.
Slack is (or should be) a high priority queue. It seems like something in between is needed. A place for “please deal with this soon, but don’t stop what you’re already doing” and that has far less noise than email so you know a request will be seen.
I don't mind people asking a question, but just put it all on one line, "Hi Phil. This is the question..." That way I can sometimes just fire back a quick answer and it's not as distracting.
It makes sense too - you wouldn't walk up to someone, tap them on the shoulder and then make them wait before asking a question.
Whether that's true or not, I respond if I'm ready, or I ignore it and go on with my work if I'm in the middle of something, just like I would with a full question. The only difference is I'm not thinking about the question with my spare cycles in the mean time.
If someone is trying to inform me of something urgent with "Hi Drew" I think it's reasonable to say that's their own fault.
And while the greeting without a question causes anxiety -- (you said hello... what do you need??) -- I have to say I'd rather get a lonely "hello" than a "Hey I have this insanely urgent thing, you need to help me RIGHT NOW." And I'd way rather get a lonely "hello" in Slack than have someone walk up to my desk and "hello".
I explained to some people that it doesn't work well with my anxiety to see "Hey I think I found a bug in X" and then just get no further details for two hours. One person has actually listened and writes me up an email or whole long message now. Everyone else responded by saying it seemed too rude and inconsiderate to not ask about your day first so they continue to do that... You can still start your message with "How was your weekend?" but just type the rest of the message too without waiting for a response...
This isn't something people can or should have to do on their own. For it to work, it needs to be a company wide expectation on a company wide schedule that immediate interruptions are off limits during certain times.
I also generally agree with "you don't need an app for that" for pretty much everything... except that this app would need to integrate and work around online calendars. And I want it to queue people so I can answer them in order. And I don't necessarily want to have a specific time for interruptions, I really want people to try to answer their own question for 5-10 minutes before interrupting me. I'm happy to answer questions, but I get a lot of questions that people can easily answer on their own with 30 seconds of effort.
The last open floor plan I worked in established that the meeting rooms were allowed to be used for engineer quiet time, and that someone in the meeting room was not to be interrupted. It was great for the first couple of months in the building, but eventually the meeting rooms were crowded with meetings and there just weren't enough for engineers to use for focus time very often. Headphones became the only means of staying sane.
When I tried office hours, I was actually in shared offices. 4-6 people to a room. It was a game company, and I was supporting artists. The artists were the worst about not respecting office hours, most of the programmers left me alone because they also wanted to be left alone to concentrate.
Ultimately I decided I was setting a bad example by trying to establish office hours for myself. The company wasn't that great at planning, and the interruptions I was getting were a symptom of not enough training and formal communication. What was needed was a little more communication, not less. (*But the right kind, of course.)
The description looks close to what you were expecting.
* Meeting initiator fails to really consider if everyone on the invite list needs to be there.
* Meeting initiator fails to consider if a meeting will have all the necessary people in attendance in order to have the meeting (and furthermore, what if a required attendee can't make it? Can you still have the meeting? If so, they probably didn't need to be there in the first place)
* Meeting initiator does not have much of an agenda or firm outcome in mind when organizing the meeting (other than some topic or 2... i.e. "Discuss new feature X")
* Meeting initiator and/or attendees don't take any notes at all and then don't distribute the notes to people who may want to be informed but simply did not need to be in attendance.
There are other issues with why there are so many meetings, too, such as the structure of the organization and/or project being worked on, whether the culture of the company hinges on having "buy-in" from many different stakeholders, or a consistent "ask for permission" kind of culture. Also, a culture where people don't interact well between groups (marketing and engineering, product management and QA, and so on) or have poor relationships between these groups. Meetings serve as a more formal proxy in order to get people informed or consensus on things between disparate groups in the organization. These are additional factors that seem to play into the need for more meetings.
Care is needed when scheduling. Standard parallelization stuff. If all your sub teams want to have sub team meetings (retro, planning, blah blah), try to parallelize those meetings so there's more time on the clock for cross team meetings. If you don't do this, manager schedule ppl will start violating the DMZ.
To manage Slack interruptions disable whatever your personality is distracted by. For me I turn off all notifs that aren't direct messages to me or @mentions. I hide chat rooms with no unread messages. And most importantly I don't keep Slack on top 24/7 on some second monitor. When ppl need me the client grabs my attention and I answer. The rest of the chatter can be read at my leisure. We use emojis in our engineering channels to make it easy to scan for action items like code reviews and we use threads for replying to ppl so the channel is like the top level view of a message board.
This is functioning fairly well with ~30 engineers at the org but i think we will need to more consciously manage the 3-6 window if we doubled in size again. Fred Brooks stuff, the 3 hour window is fixed but as teams grow so does the communication overhead.
It helped but wasn't completely effective since we were split over 3 floors of a building (floor 4, 20 and 21), so it could take over 5 minutes to get from room to room.
I actually enjoy the break sometime and the sidebars on the way to and after the meeting are sometimes great ways to get micromeetings done.
Having the rest blocked gives me a two solid blocks of three hours to do stuff.
Probably part of the reason I'm gone now, but it is incredibly annoying to be in a groove and forcibly interrupted in the middle of it for an managerial ego-stroking session. (Also, you're paying me a decent chunk of change to sit there bored out of my skull).
- Meeting organizers actively used the scheduling assistant to determine the best time and room for a meeting
- Meeting organizers picked whatever time and/or location was most convenient for them and whoever made it made it
- Meeting organizers picked whatever time and/or location was most convenient then threw a fit if you declined due to another commitment
If you're a junior dev and your lead schedules a meeting for 11am you'd be hard pressed to tell them to pound sand because that's your programming time. Seniors have more leeway but I'm sure seniors at Facebook or Microsoft still probably aren't declining meetings with their boss because it's programming time.
As we see in this case, it started with one team. A junior dev can't unilaterally change the schedule, but they can certainly point out the problem, see if others are feeling the pain of too many meetings, and propose an experiment to improve productivity. And then if a whole teams says, "Manager, we are eager to be more productive, so we are trying X," it's going to be pretty hard for a manager to say, "No, productivity isn't important here."
I am moving teams at the end of the month and I look forward to suggesting this to my new manager, perhaps just a day or two to start and review the VCS after a few weeks to see how much more gets done on those day(s). I just think it would be very easy for a manager, especially a non-technical one, to disregard this entirely.
The other thing has been as a last-resort day for meetings that really need to happen soon, but half the people you need to get in the room are just in meetings all the time except that one special day, so you make a special one-time exception when you really need to. I suspect that this is just a band-aid though - those people can't be as productive as they think they are if they can't control their schedule more.
I try my best to respect people’s preferences but if by some miracle I’ve found a time slot that is actually free for the other 6 participants but happens on your “no meeting day” I’m going to regrettably have to schedule it then.
People are surprisingly respectful of it, and unlike just going dark it signals to people that you're available if need be but focused on something.
Note: notifications are disabled on Slack, but it still causes distractions.
How do they address the onslaught of Slack interruptions?
Most people aren't willing to skip meetings, or walk out of meetings when they realize the meeting is unproductive. Both are productive behaviors.
You can also propose an alternate time, which can be seen as less standoffish.
Ah that would be very helpful.
The thing is, as engineering manager and gatekeeper to my team, I would like to make those RSVP decisions for people on my team. We can solve this with organizational/communication policies, but was hoping to enforce within GC as well.
Also in a small minority of cases breaking up a developer flow to provide on the ground context in a meeting is better for the organisation than keeping the developer in-flow for another hour.
Rarely, I'll concede, but it's worth remembering that few developers are paid to "code", but to create value for the organisation. The vast majority of the time that's done by coding, but sometimes (in those rare moments) that value is derived from a meeting.
So, Tuesday-Thursday might me an ideal set of days to schedule nothing. It still leaves two days to schedule external things. I tried a one day system before but it was too rigid.
> As engineering managers, it’s our job to provide the space and support needed to help our engineers deliver great software.
The best managers I encountered were not telling the team what to do, but enabling them to do what needs to be done.
Since leaving the corporate world, I've been doing startups and freelance work. I tend to not use a calendar for meetings because they are so rare these days. Likewise, I've all but eliminated email from my life. It's just not a thing anymore to read and write lengthy emails. We use slack to replace both meetings and email.
Product managers, UX, and others need significant input from the engineering team to make good decisions (i.e. not design un-buildable things). And the idea that they can go for 3 business days a time without that input seems... unrealistic and/or counterproductive.
But of course meetings should be limited as much as possible... include just the relevant engineer(s)... and trying to cluster meetings instead of spreading them throughout the whole day...
Technically the stand-up would have been a meeting. But since it was our choice, we would have probably considered it a conversation, as it was not some uncontrollable schedule bomb, but our way of getting the day started.
I've never found any utility in standups at all, and the days we missed the standups were no different to the days we have the standups.
I think for those people meetings are saving their job.
What about the designers?
Does anyone really love meetings?