Meetings are a waste of time for devs — case for Socratic questioning
Posted by dmp0x7c5@reddit | programming | View on Reddit | 140 comments
Posted by dmp0x7c5@reddit | programming | View on Reddit | 140 comments
Jaanrett@reddit
Maybe for rookie devs who just do what they're told and don't have any say in design or planning.
That's not to say there aren't meetings that aren't very productive, or are otherwise poorly thought out. It's not easy getting meetings right all the time, but you learn. It's all part of the job.
emperorOfTheUniverse@reddit
Devs who just wait for jira tasks to be assigned are the ones that will get replaced by AI probably. At some point the job is just typing if there isn't solution design, architecting, etc. At the least, you gotta tell PMs 'hey I can do this thing and it'll take this long'.
Jaanrett@reddit
Perhaps. But in my experience with ai, at least as it is currently, it's good a looking things up, but not very good at vetting it's own responses to ensure they're good.
But yeah, perhaps one day.
TedW@reddit
I think an important step for AI will be validating that whatever gibberish it produced, actually accomplished the request. Right now, it almost never does.
Extreme_Original_439@reddit
Yea, I’ve never understood this take. Meetings are especially great for understanding the context and edge cases for the business you are working with and knowing exactly where your team adds value. I also can’t imagine trying to gather requirements and all the nuances or discuss edge cases through email or slack. This is probably a popular take for devs who have extremely well defined smaller tasks with no ambiguity. I also wonder if these devs ever actually take the lead and communicate when some large portion of their bandwidth is taken by meetings that don’t add value or if they just keep it to themselves and vent elsewhere.
korkolit@reddit
Management wants updates. That's probably the gist of it.
ExtensionThin635@reddit
Yup, and I always say look at the board. They can’t read but want an email, spreadsheet, deliver plan, board, Gantt chart, meetings, syncs, standups, etc.
myringotomy@reddit
They want to know why the board is the way it is. For example why isn't this bug closed yet, the customer complained five times already.
billie_parker@reddit
Problem is they usually won't understand the reason.
jacobb11@reddit
Yes. And there may not even be a satisfying reason. There's a bug and we haven't found it yet. Or, we have found it, but there's no easy fix. The 2-5 day estimate for fixing it that we put on the board is our best estimate and no, we can't improve that estimate without investing hours.
I understand that executives would much rather manage a well-oiled assembly line than the chaotic herd of cats that is software development, but it's a crying shame that so many of them still don't understand the difference.
myringotomy@reddit
Honestly if you can't estimate without investing hours don't put 2-5 day estimate on the board saying you will fix it. Put "investigation" on the board and say it will take a day. Then put the estimate when that's done.
Transparency is important.
They are not paid to understand your daily grind nor are they paid to care about your toils. They are paid to deliver shareholder value which unfortunately involves making customers happy. If the choice is between making you happy or the customer happy they are going to choose the customer every time.
billie_parker@reddit
Sometimes you actually think it will only take 2-5 days, then you sit down and start the task and realize there is something you missed, so now you actually do need to spend a lot more time investigating. Some managers are even dogmatically opposed to the idea of adding new tasks while the sprint is ongoing because it messes up the burn-down chart. Things aren't so cut and dry when you're assigned to fix some legacy code that nobody understands, and your manager knows almost nothing about programming.
What are you even trying to say? The point he was making is that software development is fundamentally a chaotic process. Many managers don't understand that. If they think about it as an assembly line, they are going to be constantly confused about why it is so difficult to plan things accurately. Why new tasks keep getting expectantly generated, etc.
How is your comment a response to that in any way? Managers are in theory paid to understand how the software development process works.
The ridiculous thing is that if you try to explain this to a manager they tend to take it personally. "You think I'm not smart enough? How dare you?"
It's like chaos theory - you cannot predict the progression of a chaotic system regardless of how accurate your simulation. Software development is often the same way. You can't predict what tasks will spring up. Instead, you need to get good at dealing with them when they do. Bad managers will instead criticize you for not knowing ahead of time that this task would be needed, but that's unreasonable. Or, if they don't criticize you, they at least see it as some kind of fault of yours.
myringotomy@reddit
Why is that? Is it because you don't understand the product? Is it because you don't understand the business logic? Is it because you don't understand how the customer uses the product?
If you find yourself in this situation you should really give some deep thought to the matter.
Maybe, depends on how sprints are managed but bug fixes are not normally a part of the sprint item list.
It's not your manager's job to know how to program. They are not hired to program. I don't know where this idea comes from honestly. if the manager could do your job he would be doing your job.
just trying to exlplain how businesses work to people.
I wholly reject this idea. I have been involved in countless projects where the development process was not chaotic and certainly fixing bugs (which is what we are talking about) wasn't chaotic.
Exactly.
Well maybe don't be so insulting next time.
i reject the premise that building software or fixing bugs is a chaotic process. If it is then maybe you should examine what role you play in that fact.
Isn't that a part of your job description?
billie_parker@reddit
No, it's because it's legacy code that I am not familiar with.
But even if it was one of those reasons you state, what is your point, exactly? You say to put "investigation" on the board and say it will take a day. How do you know it will take a day? You can start investigating and find you need to do 2 more days investigation. So you just keep adding tasks on and on?
Everything I'm saying applies to both bugs or new features...
Among other things, a manager is responsible for evaluating the quality of your work. They are also responsible for planning to a certain extent. If a manager knows nothing about programming, they will typically have zero clue what is going on. I've seen this time and time again. This is how developers can get by working from home only 1 hr a day because they are able to mislead their clueless managers about their work. Seen this behavior time and time again, and you enable it.
Programming is not even difficult. I have been both a programmer and a manager. This idea that managers shouldn't know the basics of programming is frankly absurd. Your standard is so low that they might as well be mentally disabled.
My point was that it was irrelevant to what they had written.
I can at least concede the point that some projects are less chaotic than others. I suppose it depends on the amount of resources you have, how difficult the project is, etc. If you have a very easy task and tons of people, then yes it can be simple. If you have a few people who are stretched beyond their means working on 10 year old legacy code, then it will inevitably be chaotic. The latter is very common in the industry.
I don't believe you can understand the software development process if you have no understanding at all of programming.
The irony is that you seem to be taking it personally. You are making it personal even now.
lol, personal personal personal
Can you ever step back and analyze things in an impartial way? Can you imagine a scenario where you might be hired to maintain a legacy codebase where all the existing developers have left? And management is desperate to push out new features because the company is failing financially? Guess what - that is reality for many developers. And yes, often the problem is that developers are incompetent and have messed up the code, but that doesn't mean every single developer in that situation is at fault.
The truth is that standards are lowering across the board. If managers don't know how to program - you can bet they're going to hire people who also don't know how to program.
No, it's not part of my job description to know something before I could possibly know it.
Hey, I have a 100,000 line legacy codebase. How long do you think it will take to migrate it over to this new library? Isn't it your job to know this without even reading the code?
Oh - I see, you want to make a task to estimate to generate the estimate. How long is that task going to take you? See the problem?
The irony is you get so personal, but there's obviously something you don't understand. Again - it's like chaos theory. You think you can predict the chaotic process and think people are just stupid for not being able to. Do you know anything about chaos theory, by chance? The butterfly effect?
myringotomy@reddit
Whose fault is that? Also if you were not familiar with the code why did you say you would fix it in two days?
It's your job to know these things. That's a part of your job description.
No. A manager is responsible for the results of your work. Things like the pace of development, the amount of bugs, how fast bugs are resolved, and of course the final quality of the product and customer satisfaction of the product.
billie_parker@reddit
It's nobody's "fault." The job is to maintain and improve legacy code.
Why did I give an estimate? Because I was forced to give some kind of estimate. The fact is that it was impossible to give an accurate estimate, but i was forced to give one anyways.
My point is that it is impossible to know certain things. It's not part of your job description to do impossible things.
I'm holding a book in my hand right now. How long do you think it would take you to read it? It's impossible for you to estimate that. Just like it's impossible for me to estimate how long it will take to do a task based on some code that I am unfamiliar with. This is obvious - are you actually a developer?
Distinction without a difference. What is the "results of your worK" if not the quality? How can the "pace of development" be evaluated, if not in terms of the quality? Programming is not a binary situation. Features aren't just "completed." They are always completed within the context of the quality of execution. This is basic stuff.
In other words... the quality of you work...?
Never said I was. I just stated that I explained something to someone, and they took it personally.
Your only explanation was that I was insulting - it shows you don't have a lot of experience with dumb people. Maybe you're lucky enough never to encounter them, but I doubt that.
If I am hired to maintain a legacy codebase, then on day one I have no understanding of the codebase. Understand?
I am capable of reading and understanding the codebase, but that takes time. Understand?
So if on day one I am asked for an estimate for a new feature, it is impossible to provide a reasonable estimate, understand?
Sorry - but sometime people actually are stupid. If you think it's reasonable to ask someone to estimate how long a task will take when they have no way of possibly estimating it, then you are making a mistake. If you fail to see how that is a mistake, then you may in fact be stupid.
There is a difference between: "noticing someone is stupid" and "insulting them in a malicious manner." You seem incapable of differentiating between the two. I have been telling you that someone did something stupid - you can't help but assume that I acted like an asshole towards them. Your only recourse is to say that somehow I am at fault. To me, this indicates you are taking the situation personally, as though you are identifying with the stupid person. Just my observation.
myringotomy@reddit
OK let's sum it up here.
That's the scenario you have painted here. Like I said, if you smell shit everywhere you go, look under your shoes.
jacobb11@reddit
It's not a zero sum game. Happier employees make better products (or provide better service) which produces happier customers. Optimal executive practice includes understanding your employees, however much beneath you they may be.
myringotomy@reddit
But sometimes (often) it is. Happier employees don't make better products, happier employees don't give better customer service. Most customer service employees don't even like dealing with customers even though that's their job. Ever talk to a service employee? What's their number one complaint? It's customers.
Again. It's priorities. Customers and shareholder trump employees. Every time. Without exception.
That's just a fact of life under capitalism.
myringotomy@reddit
Why wouldn't they understand "I couldn't find the bug" or "I couldn't fix the bug because of XYZ" or "I got sick for three days" or whatever the reason was?
The meeting is to explain what happened and what is happening. If you can't fix the bug then you should be explain why right? You know the old saying "if you can't explain it to a five year old in five minutes you don't know it".
billie_parker@reddit
First of all, it does depend on the manager, like I said. It's very common for managers to have almost no technical knowledge at all, only operating with the understanding of how the software should act from the perspective of the users.
A manager might understand an explanation like "I couldn't find the bug," but that is a very superficial understanding of the issue. There's likely a much deeper nuance: what have you ruled out? How many more known avenues do you have to investigate? What is the relative probability that each will achieve results? How much time would each take? Do you need support for them, etc. Often the dev only has estimates for all of these details and they can be dependent on other things: "Well, if the code is good it should only take 30 min, but I haven't looked at that code yet, if it's bad it could take 2 days" etc...
Often managers don't even understand that this complexity exists. To them it's like they're asking you for an estimate for how long it takes to make a sandwich and you're saying you don't know exactly. In their minds a sandwich would take anywhere from 5 to 20 minutes to make. They can't comprehend that it might be significantly more complex.
I don't think that applies in all situations. I mean, that's just self evident. It doesn't matter if you're an expert on Russian history, you can't explain it all to a five year old in five minutes. Sometimes there's more detail than can even be communicated in five minutes, regardless of how clear and concise.
What it comes down to is how do we define "understand." If the manager trusts you, then they can understand what you're saying on a superficial level and leave it at that. But if they want to micromanage you beyond their capabilities, you will have to dumb it down for them in a way that wastes time and in the end ensures they don't retain much of the information.
myringotomy@reddit
First of all I don't know any programming manager or product manager that has no understanding of the tech stack the company is using.
Secondly the fact that bug still persists days after it was supposed to be closed is not a technical issue. It's an issue with the process or the developers who either lied about how long it was going to take or had no fucking idea and made a prediction anyway or are just incompetent and are fucking up.
honestly why not? Sure not all the nuances but you can certainly paint the big picture in five minutes.
Here is the thing. If they are micro managing you it's because they don't trust you. If they don't trust you it's because you didn't earn that trust. Maybe they did trust you at one time but after repeatedly missing deadlines and buggy releases they lost that trust. I have seen this happen countless times.
If that's the case then didn't the devs take that into account when promising to fix it in two days?
There is a saying. If everywhere you go you meet jerks maybe you are the jerk.
This is the exact kind of finger pointing I was talking about. You blame everybody and everything else except yourself for the failure to fix a bug.
billie_parker@reddit
Ok, so let's assume that was the case, because I've seen this many many times. I would say this is ubiquitous, even in the FAANG company I used to work at.
You don't seem to realize that some managers require a prediction - even if you don't have any way of giving an accurate one. They might demand all JIRA tasks have an associated prediction.
Hey, I can boil it down to two words: "Stuff happened"
See - there's nuance to this. There's difference levels of understanding or describing a scenario.
Yeah - you're just paraphrasing what I just said.
I never said the devs promised anything in that case. I was just giving a scenario that showed how a manger might not understand something in a fundamental way, no matter how clearly you explain it to them.
Noticing someone is unintelligent doesn't make you a jerk.
Obviously you didn't understand the scenario. I wasn't even assigned to fix the bug. I had too many other tasks to do. Management didn't understand the issue - tried to reproduce it, and when they couldn't that was enough for them to mark it done.
Guess what - you are pointing the finger at me when it's quite clear that if a manager is too stupid to understand the issue I described, and then mismanages the situation, then they are at fault.
By the way, I left that company eventually and it went out of business. Management was the problem.
Let me ask you this - do you think management is ever the issue in a failing company? Or is it always the person who notices that management is bad? Because that seems to be what you are saying. If a developer notices management is incompetent, then they are "finger pointing" and they must be the issue?
At the end of the day, management is almost always the causing of a company failure because they have so much power. They choose who is fired and who is promoted. So the buck stops with them.
myringotomy@reddit
Let's pretend this is true. Why did you give two days instead of two weeks or two months?
If that's your way use your allocation of five minutes no wonder you are having problems communicating with others.
you have to earn trust.
That's a failure on your part. You used the "stuff happens" approach when trying to communicate with somebody.
Why would the manager be trying to reproduce the issue?
Are the developer ever the issue when code breaks and is not fixed?
billie_parker@reddit
I mean, I can either over estimate or under estimate. The exact time frames aren't really relevant. The point is that it's not possible to estimate. I could say two days and it takes 2 hours. Same issue.
You completely miss my point and again make things personal. Notice how you repeatedly make things personal, while accusing me of doing just that. I'm not sure if I have made any personal comments against you, just describe the situation I have been faced with in a relatively concise manner. Instead of addressing what I say, you make unreasonable demands and then say I must be the problem. It just reinforces my notion that you are wrong.
Anyways, my point was that there are different degrees of explanation and understanding. It's not as simple as "understand" vs "not understand." You can explain the history of russia as simple as "stuff happened" versus a 10,000 page encyclopedic narrative.
Again - there is no disagreement on my end. Why do you think I disagree with this?
Even if a manager trusts you, they can still fail to understand certain concepts. These aren't mutually exclusive.
You don't know that. Again and again you seem to be biased towards "you just didn't explain clearly enough." Honestly, it's kinda ironic because I am explaining what I think is quite clear to you, but you don't seem to understand things very well.
Have you ever heard of the expression: "It is difficult to get a man to understand something, when his salary depends on his not understanding it."
Sometimes people are motivated not to understand things. And interestingly, I think this conversation might be one such scenario.
But ultimately, it's a bit absurd that you seem to be implying that any case where someone doesn't understand something must be the fault of the person doing the explaining. Do you think all people have equivalent intelligence? It seems to follow from how you think about this.
QA was trying to reproduce the issue. Manager told QA to do that. So, indirectly, management was trying to reproduce the issue so that they could understand if it was occurring or not.
Yes, obviously. Where do you think I am making this dichotomy? Developers are often incredibly bad at their jobs, writing garbage code and bugs. Why does it have to be an either-or?
The thing is, the managers are the ones that hire the developers. So if a team is completely full of bad developers, it's likely that management is the root cause of getting into that situation. Although then you can perhaps point the finger at the manager's manager, etc.
But this is all besides the point. You seem to be completely opposed to the idea that a manager can do anything wrong. I don't understand how you can say anyone is infallible. I never said developers, or even myself, were infallible. In fact, I could even concede that perhaps I could have explained things even better than I did, or estimated even better than I did. But this doesn't mean that managers are somehow perfect. And the discussion was regarding managers.
It's just bizarre that on one hand you seem to think managers don't need to understand anything about software, yet at the same time they are basically infallible and nothing is their fault. On one hand they can be idiots, yet on the other hand they cannot make mistakes.
Even if you accept that a manager need not understand programming, can you at least see how a manager who does would be more effective? You have two people who are the same in every possible way, except one knows absolutely nothing about programming, while the other is an expert programming. You can't see how the latter would be more effective in managing a team of programmers?
EveryQuantityEver@reddit
So ask that. They are capable of using words
myringotomy@reddit
That's what meetings are for. You pull the team together and you ask using words. This way when the finger pointing starts everybody is in the same room and can defend themselves and also you won't have to write an email chain for fifty rounds as people pipe up with their take.
dust4ngel@reddit
give a daily slack update with status changes and blockers.
firewall245@reddit
Our devs don’t even reply to us on slack lol. I try to avoid meetings as much as possible but there’s only so much leeway you can give until you force someone into a call
dust4ngel@reddit
if people won’t reply to slack, they should be punished with needless meetings
AntiProtonBoy@reddit
To be fair, Slack saps a lot of cognitive attention away from work. Who's got time to track endless stream of group discussions? It's gotten to the point where i muted channels.
aniforprez@reddit
I always check out of channels I don't give a shit about. There's always the usual offenders like the firehose of alerts and sentry issues. For a big enough company, seeing every single sentry error has no business being in my cognitive overload. My manager's job is to prioritise bugs based on customers or issues. Also the one that has the misconfigured AWS Cloudwatch alerts that goes off every 5 minutes cause the log didn't come in on time cause the service is barely used but no one has bothered to turn it off
namtab00@reddit
you should schedule a meeting for questioning the SNR of those channels.. 😁
newpua_bie@reddit
Solution: Another board where you explain the first board.
myringotomy@reddit
Exactly. All to avoid having a face to face meeting with somebody.
usrlibshare@reddit
Management wants meetings.
Updates they could get by looking at the Task tracking systems, or via Email. But that would involve understanding what is going on.
Richandler@reddit
Because they actually don't have anything else to do at the moment.
objective_dg@reddit
"Want" is the appropriate word choice there. The desire for a status update too often stems from a place of just wanting to satiate a curiosity rather than needing to make a tactical decision based on that information. It tends to do a better job at making people feel untrusted rather than improving the outcome.
rafosinski@reddit
They needs excels, not updated. Thats the biggest issue.
CatWeekends@reddit
And this is in addition to your team's daily stand-ups, manager-level stand-ups, project managers, product managers, project management software, and emailed reports all giving easily accessible updates.
chucker23n@reddit
This is a rather simplistic take not aided by consulting the opinions of some dead Greek dude.
But, yes, meetings are often a waste of time.
Lastly, I believe there's also simply a conflict of character. Some people prefer to be hyper-prepared, and to gather all information. An e-mail works great for that. It's written, asynchronous communication. Other people prefer the communal and brainstorming aspects. An e-mail thread of hell (ever seen someone say "my responses to your questions are in pink"?) is a poor medium for that; a meeting can, for those people, lead to productive outcomes. The idea that you can force such characters together in either medium ("this should have been an e-mail" vs. "let's call a meeting") lumps together different people, and is fundamentally silly.
Ironthighs@reddit
Okay. What does any of this have to do with the content of the article, which is talking about how to use Socratic questioning to dig deeper into problems and ideas? "Meetings are a waste of time" was just the example they used in which to apply the questioning.
RiverRoll@reddit
For all those not reading past the title, the article is about how to use Socratic questioning to gain insights and the premise that "Meetings are a wase of time" is only tho show an example on how it can be used.
Ironthighs@reddit
Holy shit, I read the article and then scrolled and scrolled through all these people's opinions on meetings. Took a long time to find someone who actually read the article.
michaelochurch@reddit
Counterpoint: status meetings are a highly effective method of collective punishment for low performance—what most status meetings are, really—when you can't or won't invest in your subordinates' careers and therefore will never get useful information about what is actually going on, but need to show your superiors that you're taking action.
colonelxsuezo@reddit
The only thing worse than a meeting you are stuck in is the meeting you don't know about, where management (who doesn't understand the requirements) makes unilateral decisions about things which may or may not be possible to execute.
badabummbadabing@reddit
Meetings without devs -- bad because somebody else makes a decision.
Meetings with devs -- bad, because then the dev just wants to code.
?
Larimitus@reddit
just make it an email
denseplan@reddit
Emails are for passing information along, like handing down decisions.
It's horrible for discussions.
CherryLongjump1989@reddit
Emails are absolutely perfect for transparency and documentation in a way that closed meetings are not. Emails can be forwarded and analyzed by people on a need-to-know basis in a way that meetings cannot, because you cannot invite more people to attend the meeting after it already took place.
deja-roo@reddit
Yes, if you're just passing off rote information to a decision maker.
But if that information doesn't exist and needs to be created through discussion and collaborative planning, that isn't going to happen over email.
CherryLongjump1989@reddit
Strong disagree. At the very bare minimum you should not even conceive of scheduling a meeting if you cannot write down the agenda plus everything you want to say on the topic it in an email that you send out first. You should have zero expectation that anyone will take time out of their busy day to talk to you if you can't even tell them what you need to talk about.
serviscope_minor@reddit
What is this mythical beast you call an "agenda"? 7 years in a bigcorp (no longer!) and I don't believe I ever saw one in the wild. I am beginning to suspect they are campfire legends.
CherryLongjump1989@reddit
That's the point. They have too many meetings because nobody forces them to explain why they are having a meeting.
serviscope_minor@reddit
Preach! We can't have agendas that's fuddy-duddy bureaucracy for old fashioned companies and we're a young company. Also, why do we have so many meetings and have them all drag on forever?
denseplan@reddit
Yes there are many ways to run a bad meeting, don't run bad meetings.
And don't blame "meetings" as a concept for the toxic work culture you are experiencing, the problems you describe ain't gonna be magically fixed by replacing meetings with emails.
ehaliewicz@reddit
Course it won't, it's just that meetings make people feel more productive than emails, and waste more time.
elebrin@reddit
That's why you pass information (not decisions!) around via email, give devs the time they need to read, respond, and ask a round of questions, solicit options, then finally meet briefly to choose one.
CherryLongjump1989@reddit
That's genius. What's next - teenagers start cleaning their rooms?
Mrqueue@reddit
Try get a developer to open their email client.
SubterraneanAlien@reddit
The vast majority of devs I have worked with in the past (hundreds, in different orgs) do not read emails in any sort of timely way - and for the record, I'm OK with that.
Consensus building should happen synchronously if possible, it's just much faster.
TangerineSorry8463@reddit
Devs with access to calendars and inviting themselves to meetings they find relevant = good
Plank_With_A_Nail_In@reddit
If you are going to create a fantasy world for yourself to live in at least make about saving elven princesses!
TangerineSorry8463@reddit
If only writing fantasy gave similar returns to similar investments with similar risks mate
Mrqueue@reddit
You’ll have the same 5 devs in every meeting doing stupid shit
deja-roo@reddit
I can't tell if this is sarcasm or you have never lived in the real world lol
harmar21@reddit
I dont think good meetings scehduled with lead devs are a bad idea.
I'm a lead dev and would be pissed if I wasn't included in some meetings, because decisions would be made without my input.
Of course there are still some meetings I dont see the point of, so before the meeting ill ask for the agenda, ask if I actually need to be involved, or I can skip it and be given the meeting notes afterwards.
corny_horse@reddit
Yes to both; ideally, a good engineering manager is in the middle working this stuff out and consolidating conversations to recurring 1:1s at a cadence that is frequent enough that feedback can be adequately provided in a timely fashion, but infrequent enough that there isn't excessive overhead or redundancy. How often this ideal state is achieved is a bit of a different story...
Vlyn@reddit
Or product managers who want to start a new feature two months before a hard deadline and say "It's no problem". Yeah, for you, all you do is say you want this feature. The devs have to figure out how to make it work, design it, plan it, implement it, test it and then ship it.
Neuromante@reddit
As if management takes into account input from development for anything actually relevant. Hah.
CowMetrics@reddit
Seriously! I don’t mind virtually attending meetings and just getting work done behind the scenes. In the off chance I can avoid people making dumb decisions. It is a small price to pay
Memitim@reddit
OK, so all of those plans that we've been making for the past three months are out the door. Management has decided that we're going to be doing something unrelated, starting tomorrow. Operational proof of concept is expected by end of next week. We'll have daily status meetings to track, and bi-weekly stakeholder reviews until completion. We'll need a list of all the tasks to be done with estimates by end-of-day.
savage_slurpie@reddit
Hey how did you find my CEOs playbook?
RavynousHunter@reddit
Somebody has to make sure there aren't any staples in the cocaine.
objective_dg@reddit
You mean to tell me that management would make important decisions without first consulting the people who understand and would perform the work itself? That goes beyond being fearless and is firmly in the reckless category for behavior.
mothzilla@reddit
Is this your first day on Earth?
ztbwl@reddit
They make decisions based on the meeting they held with the specialists. But half the devs declined or didn’t pay attention and fell asleep.
Leliana403@reddit
Found the manager.
colonelxsuezo@reddit
Yes, it happens.
ysustistixitxtkxkycy@reddit
I'll give you one worse than this: you've had the meetings with your manager where you patiently explained and got an understanding that you can't do the ask with the current resourcing and presented an alternative iterative plan based on what can be done.
Then you get to sit in the director level meeting where your manager misrepresents this as buy in for the original unrealistic ask, and the directors add more feature requests on top and your manager agrees to all of them.
zelphirkaltstahl@reddit
Or decisions about tools you will have to use, without prior testing, and then it turns out they are complete shit tools. Then suddenly those tools are elevated to "company wide tooling" and no way you as a single engineer could ever change any of that. Accept your fate, lowly engineer!
fried_green_baloney@reddit
Many meetings, especially all manager meetings, are struggles for dominance. The actual decisions are secondary to finding out who gets to make them.
Munbi@reddit
Old but gold: The Expert
gpacaci@reddit
This is so true! It's like, when they know it's actually a meeting where decisions will be taken, they get a hunch and keep the group small. Maybe so the decisions can be taken quickly without much interference. That's when you take suboptimal decisions that have to be reverted later. Often a symptom of people not knowing how to get decisions out of a group of people.
All the other meetings that can be an email? Better invite everyone!
qrrux@reddit
Not all meetings are a waste of time.
Bad meetings are.
Bad meetings with bad people are, and actually counterproductive.
Bad meetings with bad people and bad managers is a shit show you should be trying to get out of.
rafosinski@reddit
We know this from modern management and psychology as "Five times why"
The BIGGEST issue of meetings is that managers don't know why they want to meet. I am sorry if I broke someone's heart, but as a dev and manager, and board member, I feel like most of the meetings could me a email. We want to create a new meeting, just because we don't understand what we are doing. These steps in article can be done "offline". If all the possibilities will be ended/finished - than we make a meeting.
SockMonkeh@reddit
Every single meeting could be an email, most emails could be an update in the ticketing system.
A-Grey-World@reddit
I simply cannot imagine having a technical architecture discussion/design session via email...
Also, y'all use emails as devs lol? When I was all dev I could go weeks without checking my email. If someone needed me they'd drop me a message. Emails were almost exclusively spam, CICD/jira/git notifications, HR junk...
matsie@reddit
It's just people who think they can do everything by themselves without communicating or collaborating that think every meeting can be an email. It's cowboy coder bs, in my opinion. Meeting bloat is definitely a problem, but so is email fatigue, and slack fatigue.
EveryQuantityEver@reddit
I wonder if those people would count things like whiteboarding sessions as meetings.
matsie@reddit
Great question, I'd reckon they would. It's the disengaged, cowboy coder mentality. I've been struggling to get my team to actually provide refactor recommendations. One of my engineers asks for exact line numbers and file names to be put into tickets for things a simple sed command would surface in two seconds, all because the team often refuses to learn how our products are built.
Obviously, this is specific to my team. But I inherited them and wasn't involved in their hiring or assignment to this team. I limit our team meetings immensely. But I also see that I have a couple disengaged code monkeys who don't actually think through anything that isn't explicitly in a Jira ticket.
Direct-Squash-1243@reddit
I call it "Junior Engineer Disease".
They think their only job is to crank out code and never bother to pause and ask questions about the code they're cranking out and why.
maximumdownvote@reddit
Isn't email and slack communication and collaboration? Feels like it to me.
A-Grey-World@reddit
It is, it's just very inefficient to come up with any decisions or work collaboratively.
You have an idea for the architecture, you spend 5 minutes writing out an essay, send it to a group of people.
2 people stop what they're doing, read it, start to understand the context, and reply. 1 person doesn't check their email that day.
You have to give it enough time for that person to be clear they're not responding, now you're replying to the 2 people with their maybe overlapping suggestions, so you try combine them, respond with concerns...
It's the next day, they have to stop what they're doing, read the email - remember what it was about from yesterday...
It might take a week to come to a decision, causing loads of context switching.
Or you could jump on a meeting/call for half an hour - the advantage being you get instant responses, and only one instance of having to context switch, and people aren't missing each other's messages/comments and commenting on old chains.
teratron27@reddit
This! Worked with a few of these types of devs at my last job. Refused to meet on anything, constant complaining about the meetings they had (when it was maybe 3 regular a week) and wanted everything to be “async”. It took sooo long to make any decisions, context sharing was terrible and there was almost no team bonding.
harmar21@reddit
kickoff/Brainstorming meetings would be terrible over emails. Honestly I almost find it even more productive in person over virtual meeting (and this is coming from an introverted recluse)
I find as soon as the email starts getting over 10 or so replies, it easier just to schedule a 5-10 minute adhoc meeting. You actually end up saving time instead of so much back and forth over email, especially if one person isn't understanding.
SockMonkeh@reddit
I realized after making the post that I should have excluded kickoff/brainstorming meetings because those are the only things that should be meetings and actually need to be meetings, but so many people responded already that I just kinda faded into the bushes like Homer instead. What I really meant was every single meeting I get invited to could be an email.
matsie@reddit
This just isn't true. The echo chamber of reddit that leads everyone to think they can do everything by themselves without ever communicating or collaborating with anyone else is way too hard of a swing in the opposite, equally wrong direction.
maximumdownvote@reddit
No one is saying don't ever speak to your colleagues. It's a straw man.
EdenStrife@reddit
I mean isn’t speaking to your colleagues about s specific thing just another way to say meeting?
namtab00@reddit
this exactly is the problem.
meeting != talking
a meeting, IMHO, should have prep, structure and outcome.
chatting is inherently exploratory, meeting are for decision
a meeting can be exploratory, but has to have time and scope boundaries
zabby39103@reddit
Not every single meeting, just most... emails are low bandwidth, hard to discuss a meaty technical matter in an email especially one that hasn't been fully formed yet.
I might say every meeting with more than 6 people could have been an email though.
N546RV@reddit
A lot of good meetings start as emails or slack convos. For example, today a guy on the project I’m heading up came to me with some implementation questions, which made me realize that I was making some assumptions that might not be shared by the API team we’re working with.
So I went to the project slack channel and wrote out a summary of the convo and the questions it had raised in my mind. At the time I felt that it might merit a short zoom call with the 4-5 people on the team to get a good shared understanding.
I was wrong. The API guy ended up having a side slack convo with the guy I’d talked to, and things got cleared up, no meeting needed.
I think that’s a good escalation path. First, try to hash out things via async communication. If it works, great. If it becomes obvious that it’s a topic better discussed in realtime, schedule a call.
matsie@reddit
This is super true. We try to direct all conversation and requests to start first as conversations in our team's support channel.
rafosinski@reddit
That's great opinion! If you need more than 4-8 ppl - we don't need a meeting! Thx4that!
zabby39103@reddit
Thanks, I've also heard it referred to as the "The Two Pizza Rule" (if you can't feed a meeting with two pizzas don't have it).
rafosinski@reddit
Yeah, I forgot about that rule, but it is still valid
dalittle@reddit
If it is a topic folks are going to have a hard time understanding I would much prefer a meeting (and I hate meetings). One hour long meeting for 47 emails and then a meeting? Huge time saving for certain scenarios. Now the meeting because someone wants to feel "involved" or have a group hug. No thank you.
reddituser567853@reddit
A lot of context is not in the writing. If you are trying to get a group of people to agree, in person can dramatically speed things up.
Especially as a manager, you want to see how people are reacting, are they engaged, frustrated, etc
FlyingRhenquest@reddit
And updates could be requested by passive-aggressivly poking your co-workers! :-D
rafosinski@reddit
Not every. I am sorry, but as a lover of emails, I like meetings. If they have good topic.
applestem@reddit
I liked meetings if they had donuts.
rafosinski@reddit
me either xd
jl2352@reddit
This is a huge factor. I’ve worked at places with meetings that go no where. Endless discussions that repeat week after week. Resistance to change structures so we actually change stuff.
I’ve worked at places with more meetings, which were on point. Pointless stuff was vocalised and got cut, to only be replaced by more meetings, if they were productive. I got a lot more stuff shipped than the place with less meetings. A fuck load more.
The issue is not really the quantity. It’s the quality you get out of them. That includes acting on the content outside of the meeting (which affects if more meetings are meaningful or not).
The trope of too many meetings is as old as time. My own experience is too few just leads to pure chaos. No one has a fuck what is happening, nothing is organised, nothing gets done, and issues are left unfixed and just drift.
rollingForInitiative@reddit
We try to have clear agendas for meetings at work. Every meeting should have a purpose and an expected outcome. The purpose is allowed to be vague sometimes if it’s actually important, e.g. sometimes you need some vague discussions to figure out what’s really wrong. But by and large, a clear goal.
We also encourage inviting people as optional attendees, and the standard meeting time is 20-30 minutes instead of 60. Just the decision to cut down the meeting time was a huge improvement.
People are allowed to schedule longer meetings, but now it usually just happens for meetings that actually need to be that long.
rafosinski@reddit
Because meetings needs to has good agenda!
cc81@reddit
Meetings need to have a good agenda and you need to have a culture where people prepare.
If you have a clear agenda and material is sent out beforehand it is night and day if you have a meeting where people have read the material beforehand or not. I have colleagues who derailed review meetings because they asked tons of questions early in the presentation that was answered in the material that was already provided.
This was luckily shut down my management with a "This is answered in the material and you are expected to read that before the meeting".
I suspect people are still not reading it beforehand but at least the stupid questions have stopped.
LookIPickedAUsername@reddit
Seconding this.
The worst company I worked at for meetings invited every. possible. stakeholder to every meeting that tangentially involved them, just in case they might have an opinion about something. Hour-long meetings which turned out to be completely irrelevant to me were the norm.
At my current company I actually have even more meetings. But they are shorter, tightly focused, and there is a ruthless corporate culture towards avoiding or discontinuing useless meetings. People are (generally) only invited to meetings if they actually need to be there.
So even though I spend more hours a day in meetings than I used to, they actually feel very productive and I don’t mind it at all. We are designing important shit and that doesn’t happen without getting some minds into the same room to talk through it.
amayes@reddit
Agreed. The worst part is when you assume everyone at the meeting was paying attention, because they absolutely were not.
throwaway490215@reddit
Make it a requirement that a meeting consists of personalized & completable agenda items ( or the title of the meeting has to be the agenda item ).
No more "share progress".
sumwheresumtime@reddit
Something as simple as enforcing an agenda when calling for meetings with three or more people can reduce meetings tremendously.
These simple requirements make a lot of time wasting meetings suddenly disappear and as others have suggested email and tickets are created and shared instead.
I've worked in health and finance and this kind of thing has helped a lot.
yellowodontamachus@reddit
I totally get the frustration with unnecessary meetings. One thing I've found useful is setting time limits. A hard stop can push everyone to focus on the essentials. I’ve tried tools like Trello and Notion to track what could really just be an email update instead of a meeting. As a side note, while my company, Aritas Advisors, deals with financial services, we've streamlined decision-making processes by using structured reports and data analysis rather than drawn-out meetings. Interesting how platforms like Basecamp and Slack have transformed how we handle discussions in tech, right? Curious to see how others do it too.
matsie@reddit
No one in my company ever prepares for a meeting at all, even if there is an agenda. I'm usually one of maybe two (or the only) people who have actually prepared for a meeting.
matsie@reddit
It's not a manager specific issue. People just don't prepare for meetings. We have a standing meeting to go over and prioritize new intake items among key individuals on our team. No one comes to it having already read the intake requests, evaluated them, reached out to the requestor, etc. It's frustrating AF and means we have to meet again a lot of the time. Trying to drive home to my reports that they need to actually be prepared for meetings and we'd have WAY fewer of them then doesn't work. We send reminders and they still don't prepare.
Individual-Praline20@reddit
Most of my meetings occurred because of incompetence. Was it already documented? Yep. Were the participants already aware of the situation/issue/etc? Checked. Did they took time to get it on their own? Unchecked. Did they care? Obviously. Absolutely not. They just wanted me to tell them again, at a precise time, so they can move on with their lives. In the same exact way it happens in elementary school. That’s all.
f0urtyfive@reddit
So lets build an AI integrated scheduling system that forces you to answer the requisite questions before you can schedule a conference room.
rafosinski@reddit
We tied before AI, so many times... It doesn't work. Always you have that one person out of the story, who says "I didn't get an invitation, can we talk about... XXX" ¯\_(ツ)_/¯
ExtensionThin635@reddit
Well yea we know, now tell the managers scheduling to figure it out or get out, which will never happen
rafosinski@reddit
Yeah. Everybody knows, that will never happen ¯\_(ツ)_/¯ Cant help every organisation. Don't worry, as a manger I've in the same place... I can try, but...
GezelligPindakaas@reddit
One time I decided to skip a meeting. The consequences of the decision made in were suffered during months (because it took so long to finish and discussing sunken cost with upper management is useless), all for a consultant to grab a medal for the great innovative solution he designed.
Yeah, I'd rather sip coffee for an hour while staring at slides than getting in the same situation. Every time I went through that piece of shit module felt like a punch in the gut and would trigger me.
deadken@reddit
There's no issue so small that an Agile advocate can't address with 18 more standup meetings.
IsActuallyAPenguin@reddit
Yeah, well you suck at Socratic method.
birimbau1967@reddit
I blame scrum! I feel like the amount of useless meetings increased exponentially
reveil@reddit
I have been to very usefull meeting and complete wastes of time. General rule is the more participants the higher probability of it being a waste of time. The most usefull meetings were ususally 2-3 people and terminal or code editor and trying to solve a problem. This way frequently tasks estmated to take weeks were sometimes solved in 2h. Meetings should have point a tangible result that is supposed to come out at the end. Either something done or action items assigned. And no "information sharing" is in no way shape or form a desired outcome of a meeting. If that is the case it 100% could have been an email.
Newguyiswinning_@reddit
Lol no. A dev should be in every meeting. Otherwise you will get fired for not delivering an impossible feature yesterday
andrewfenn@reddit
The reason devs join meetings is because the other people in the meeting are discussing things that they have no idea what they're talking about and need the devs to correct them less they decide something that will screw everything up.
The sensible thing to do is delegate those decisions to the dev team in the first place. The problem with that is there are business decisions that the devs don't know, care about or give lower priority to. Thus why it is the way it is.
idebugthusiexist@reddit
No, this is not the way. Most people are not philosophers. I have the perfect team organization and meeting structure. I nailed it. This is not it sorry
mycall@reddit
It isn't when being a dev is just one hat to wear.
dustingibson@reddit
My biggest issue are multi-project meetings. Like the hour plus long meetings where 95% of it doesn't pertain to me. I am just twiddling my thumbs being unproductive for vast majority of the time.
If it's like a teams or zoom meeting, at least I can get stuff done. But still am less productive than usual though.
Emergency_Property_2@reddit
When I worked at Wells Fargo pointless meetings rehashing the same nonsense that was rehashed in a different meeting and then having a third meeting to go over the results of the first two meetings was SOP.