12 ms·

The business case for fewer developers in meetings

134 points by redbell 4y ago

cardy31 4y ago
$200K comp and 2 weeks of PTO. I don’t know how people handle only having 2 weeks off per year. American working culture is bizarre.
- dilyevsky 4y ago
  I think most european countries have 4 weeks counted as weeks not days and american ones usually only count work days so 15 days is actually 3 weeks. At google I had 25 days in my last year = 5 weeks which is not too bad. Amazon is traditionally a shit show with only 2 weeks your first year and 3w thereafter
  - nicoburns 4y ago
    4 or 5 weeks, usually (although this might vary by country) counted in days where 5 days = 1 week for a full time worker.
  - Traster 4y ago
    The UK has 28 days minimum, that includes "bank holidays" (USA: Public holidays?) which are days decided by the government as holidays for everyone - like Christmas. So it's more like 5.6 weeks total in the UK, and the UK aren't particularly generous - your final year in Google, an exceptional comapany, barely meets the statutory minimum in the UK.
    - dilyevsky 4y ago
      Google also had around 14 holidays so no it far exceeds uk min requirement. Most us companies dont count holidays in their pto numbers and most have around 10 holidays
    - ByteJockey 4y ago
      That might be the difference, nobody (that I've met) in the US would count a public holiday in PTO time. Google's not super exceptional in this matter (that's mostly their pay/on-site experience). I have 4 weeks (20 days) at the moment, and have for a few years, along with 8 paid holidays (28 days total). Next year I get a fifth week (33 days with holidays). I don't work at a FAANG/MANGA company, but just some random company in the Mid-West. But I've also worked service jobs before with 0 paid days. Holidays were mandatory work days because everyone who did have decent jobs were off and wanted to eat at a restaurant. The talk about the bottom in the US being below elsewhere isn't a myth. The US doesn't like putting floors on matters this side of the 60s.
    - infamia 4y ago
      Is it still common in the UK/EU to only grant "holiday pay" (i.e. you get paid a fraction of your normal salary) during PTO? In the U.S. it has always been standard practice to get paid your full salary on PTO and national holidays. Even if that is so, I still think I prefer the European system.
      - juki 4y ago
        At least in Finland you get the holiday pay (0.5 * salary) on top of the normal salary. It can also be converted to additional days off.
      - steve_gh 4y ago
        No
      - EEBio 4y ago
        Holiday pay is full pay. Parental leave is usually not. Parental leaves start rather high (100% or 90%) and then go slowly down (to 60% or 50%)
  - Scarblac 4y ago
    And sick days aren't limited, you can't control how long you're going to be sick.
  - deleted 4y ago
    [deleted]
- ezfe 4y ago
  I’m a “Software Engineer” in Boston at a large company. Base time off is 24 days flexible time off (sick and personal) plus 8 fixed holidays. Lots of jobs are just shitty.
- PragmaticPulp 4y ago
  PTO is measured in addition to standard holidays, which is 8-11 days depending on the company. So 2 weeks of PTO would mean 3.5-4 weeks of time off total at most professional jobs. I haven’t seen a job posting or working at a company with only 2 weeks of PTO since I was a junior, but they’re out there.
- dkasper 4y ago
  At Meta we get 21 PTO days + 2 choice days + 5 "Meta days" + 10 government holidays. That's a total of almost 7 weeks off... Not sure if it's still the case but when I worked at Reddit we had "unlimited" PTO and I saw quite a few people taking over 6 weeks off per year. If you want to see an extreme work culture maybe look at China or Japan, but as far as tech goes the US ain't bad these days.
maxehmookau 4y ago
2 weeks PTO is average? That's nuts! Shut your laptops and go outside!
ggm 4y ago
The inverse function: "what level of aggregated pay makes a meeting more than an MBP" is needed because MBP price and renumeration vary by economy and time. I for one would welcome this service so I can ironically distain meetings on sound financial bases.
Tagbert 4y ago
Do developers really spend that much of their time in meetings? When I have worked closely with dev teams, it seems like there are a few regular short coordination meetings that are over quickly. Then there are occasionally more substantial meetings where they are working out architectural questions. As a program manager, I usually have 4-5 meetings a day because that kind of is my job to review and coordinate. Developers are only rarely in those meetings.
- goalieca 4y ago
  I’ve had stints where it’s mostly meetings with an hour here or there of actual work. Too much talking about doing stuff instead of doing the thing. More process to ensure quality instead of just making someone responsible for it.
  - Tagbert 4y ago
    Sounds like a very dysfunctional organization
- torstenvl 4y ago
  Yes but the function isn't workinghours - meetinglength > timeneededforwork The function is workinghours modulo meetingtimes > timeneededfordiscreteworkingblocks A task that requires four hours of concentration cannot get done in a day with a five-minute mid-morning coordination meeting and a five-minute mid-afternoon admin huddle.
- Trasmatta 4y ago
  Depends on the team. Also, a single meeting is extremely expensive for a developer's productivity. I generally think the developer productivity cost is about twice the amount of time it actually takes. And it's even worse when they're staggered throughout the day. Two one hour meetings is more like requesting 4 hours (or more, depending on what time of the day they take place in). Managers not realizing this is one of the major failings of modern day software development.
- steveBK123 4y ago
  It varies by org. I’ve been on teams where the only recurring meeting was a 30min weekly. On the other hand I’ve been on teams with 25+ devs on 6+ hours/week of recurring meetings together.. plus any ad-hocs, project or task specific meetings, etc. Some were 2 full hours long and could run over to 3 hours. Was insane.
Traster 4y ago
Co-ordinated effort is much more valuable than raw engineer effort aimed scatter-gun at a project. There's so much more to meetings than the author covers in this. For example, in a meeting you're made aware that engineer X is working on Y, you have prior experience in Y. Immediate win. Does this happen 100% of the time? Of course not, but there's a probability it will. Hell it doesn't have to be experience, it could just be an interestin insight - what are we paying you guys for anyway. Communication often is the most valuable thing you can foster as a manager, and this article just seems naive. Sure, there are bad meetings. But we don't measure the thousands of hours of wasted engienering hours that could've been saved by having 1 decent meeting.
- dilyevsky 4y ago
  Consider this - communication on its own is worthless if no time is left to do productive work. If communication was so important then slack/hipchat/etc shitposters would be your most productive employees and they usually aint
  - fijiaarone 4y ago
    I had a manager who measured how much time everyone spent using slack and actually boasted that he was the person most active on slack as if that was some measure of productivity. And I guarantee you that 90% of his posts on slack were cat gifs and the like. Most of the other 270% of his messages were automated notifications for build, deployment, and test failures that everybody ignored.
- recurrence 4y ago
  Hi, author here -- kind of weird to see my post on hn. Yea, a good meeting can absolutely be worth all the developer time it costs! I tried to carefully qualify all my calculations in terms of 'opportunity cost' and 'pointless meetings', but clearly it didn't work :). The main idea behind the post is that the expected utility of a meeting with n developer, E[u(x_n)], should be greater than or equal to the opportunity cost of having that many developers in the meeting. Furthermore, through batching and async context transfer we can reduce the opportunity cost of having those developers in that meeting, which is pure upside for the business. In a previous job I frequently got invited to meetings that were planned because the expected utility is > 0, which is imo really bad business.
peterbonney 4y ago
Sort of an obvious point, but the opportunity cost analysis here has basically nothing to do with whether the meeting attendees are developers - it applies to anyone who has other things they could be doing with their time and has a cost from context switching. On a separate point, missing from this is the potential opportunity cost arising from NOT having a meeting. It’s a harsh reality, but sometimes the reason you’re sitting in that “pointless” meeting is that there’s a small chance you’ll need to be called upon, and if you aren’t present there is a person or people whose time is even MORE expensive than yours who will suffer a cost that more than offsets the cost of 2 or 5 or 10 developers sitting there twiddling their thumbs. (That’s not often the case, mind you, but it does happen.) Anyway, “High Output Management” by Andy Grove does a great job articulating the math of meetings and how to maximize their value.
- recurrence 4y ago
  Adding High Output Management to my to-read list, thanks!
- civilized 4y ago
  > It’s a harsh reality, but sometimes the reason you’re sitting in that “pointless” meeting is that there’s a small chance you’ll need to be called upon, and if you aren’t present there is a person or people whose time is even MORE expensive than yours who will suffer a cost that more than offsets the cost of 2 or 5 or 10 developers sitting there twiddling their thumbs. Why are we in this horrific situation where a person's knowledge can only be leveraged if they are "called on" in 30 seconds of an hour-long meeting? My God, Slack me if you must.
  - marcosdumay 4y ago
    Some work is inherently synchronous. On those, if you are needed for 30 seconds but it takes 30 minutes for you to get there, the people doing it will have to stop until you come. All work is not this way (even though some managers pretend it is), and very likely the majority of your work isn't like it (assuming you are a software developer). But some work is like it, and pretending it isn't as about as expensive as gathering people doing asynchronous work into meetings. (The "what should we do" decisions normally require more synchronous work than "how should we do it", some professions do spend most of their time in the former.)
travisgriggs 4y ago
Hmm. I think the author got confused. “A business case for fewer meetings.” That’s better. I can help develop it if they want.
- Layke1123 4y ago
  The developers are the only ones who actually know how to do the actual work needed to teach machines what businesses do, which is why we see all the bull shit happening. Execs and managers are neigh useless in the modern world because they can't fake it anymore. Cut the middle men out!
  - travisgriggs 4y ago
    Good luck. I fear Pournelle’s iron law of bureaucracy will ever prevail. Sadly.
onion2k 4y ago
Meetings force us to context switch, kill our flow, and sap our job satisfaction long term. That's what developers say, but I suspect that it's not actually true. Something that leads to a far worse reduction in job satisfaction is not knowing what's going on, being surprised with complex features that the product people have assumed will be simple, and not having opportunities to be seen as an expert. Those things generally require developers to be in meetings. If devs don't have those things they get grumpy and quit. The problem with most meetings is organisational. If your day is fragmented by lots of one hour meetings with one hour gaps between them then you can't get much else done. That's the frustrating part - you have lots of meetings and lots of 'dead space' between them. If you change things so meetings are 50 minutes long, and only have ten minutes between them, and that 'defrags' all the 'dead space' to a single block where you can focus, then meetings suddenly stop being so much of a problem. If you hate meetings because they require too much context switching away from code, and they stop you focusing, reorganise them so they don't do that. If your first reaction to this suggestion is "But I can't because I don't control when meetings are", then the problem isn't meetings, it's your colleagues not giving a shit about your working environment. That's a very bad sign.
- pif 4y ago
  > Meetings force us to context switch, kill our flow, and sap our job satisfaction long term. That's what programmers say. Developing software is much more than programming, at least when you are developing something else than an information system.
- MarkMarine 4y ago
  How do you manage to move 8 other people's schedules around such that you get these blocks of time? Usually the hardest people to schedule are the manager who wants to sit in on every meeting, and the PM who also wants to be in every meeting. They look at my time and see something easy to schedule, there is a big empty block right there and it fits the tiny sliver of time they have free in the day. There is an impedance mismatch between professional meeting attenders, and the people the build, and the meeting attenders are in charge.
  - 4y ago
adamp42 4y ago
No meeting days are the way. I advocated for a no meeting day in one of my workplaces and our director agreed to try it out. We called them "Developer Days" and he'd block off the entire day on everyone's calendar and enforce to anyone outside the team we simply were not available those days. Worked so well we ended up adding a second Developer Day! And meetings become more productive too since we batched those up into the other days and could focus on the meeting instead of context switching between talking with people and talking with a computer.
cakoose 4y ago
> The business value-added per developer is 80% from flow state and 20% from non-flow state following the Pareto principle. That's not what the Pareto principle says, is it? Am I missing something?
- hinkley 4y ago
  It’s generally held that Pareto applies to a lot of things you wouldn’t assume it does. But in this case I think Sturgeon’s Law is better: 90% of everything is crap. This is a journeyman or lower understanding of development (how old is the author? Should they know better?). In fact I’ll assert that he has it exactly backward, and that 80% of code you write only provides 20% of your value. Only code monkeys provide 80% of their value from flow state. And Code Monkeys always feel underpaid because they think writing code is their entire value., and which is a slippery slope to thinking more code is better.
- benplumley 4y ago
  Not at all, the application of Pareto here would be something like "80% of a developer's value is contributed in 20% of their time", that 20% being the time spent in the flow state. Edit: rereading, those are actually the same thing, though the quote is confusing because it refers to a different 20% than Pareto refers to.
  - marcosdumay 4y ago
    > "80% of a developer's value is contributed in 20% of their time", that 20% being the time spent in the flow state. Hum, no. One does absolutely not follow from the other. If the Pareto principle actually applies, it would say that 80% of the development value comes from 20% of the time the developer spends in flow. And the rest 80% of the flow time adds only to 20% of the value. The same would come from the value from meetings and the time spent on them. But do keep in mind that, about the Pareto principle: you can never predict the value of anything - those are only post-fact measurements; and those proportions vary widely, it's never actually 80-20.
thrower123 4y ago
I've got about three meetings in me on an average day before my batteries are exhausted and I am effectively done for the day. When agile-ish processes use up on of those lives every day, that leaves very little slack before recurring customer statusing, actual troubleshooting, or an honest-to-god productive planning meeting wipes the counter out. I suspect you could waste a lot less time if meetings required agendas distributed beforehand and minutes distributed afterwards, but absolutely no one does that, or would read such material if it was produced.
Simon_O_Rourke 4y ago
I'm delighted someone is putting a cost to pointless meetings like those described (well, pointless from a devs perspective). I worked in a utility company, where morale was in the basement, and management organized a full day (on-site) off-site meeting. 60 to 70 devs in a big room, whiteboards everywhere. Some corporate events enabler stands up and says everyone is to write on their whiteboard what the word "team" means to them, then discuss it. I did the math, and after a couple of hours each group had to discuss what they found. I said it's just cost us 15k for this chitchat and at the end of it we'll be none the wiser and no actions will be taken. Was called in to the bosses office the next day and chewed out for not being a team player. Week after that the boss was fired. shrugs
zerop 4y ago
One of the main causes of too many meetings is number of priorities org has. Lots of Parallel initiatives are a big problem. This causes inefficient meetings, not all stakeholders come.
- Viliam1234 4y ago
  Doing things in parallel contributes to this problem a lot. Daily standups, plus a meeting or two per week seems doable. But if you work on two or three things in parallel, and you need to multiply the number of meetings by two or three, suddenly it feels like you spend more time on meetings than being able to focus on your work.
choeger 4y ago
The worst part is the non-linear growth in productivity of uninterrupted blocks of work. Not always, but very often a 4h block is much more valuable than 2 blocks of 2h with a meeting in between. This is not even about "flow", it's about getting your work environment sorted out, getting all the tools ready, doing a couple of experiments, actually thinking about the context of your solution, etc. It's a very costly fallacy that developer productivity is simply linearly dependent on time spent on an issue. In consequence, I strongly believe that there should be a minimum latency in software development that cannot be cut further. Say, it's two days. That would mean you should not attempt to have any meetings from Wednesday onwards and be able to deploy on Thursday evenings and collect and discuss results on Fridays. Monday's for retros, especially regarding Friday's findings and Tuesday is the day for planning. That's a very, very compact schedule and I doubt it's sustainable, to be honest. But it's already longer, and has stricter constraints, than most managers would accept, I bet.
- Macha 4y ago
  Yeah, this has been my problem since being in a role where I am more responsible for the work of others and reporting to upper management. Theoretically I still have 50% of them for individual work I had before, but that's fragmented and prone to interruptions because some exec wants to know how the XYZ project is going in between weekly status updates, or some junior developer needs help understanding why the Foo system does what it does the way it does
  - fendy3002 4y ago
    Which is frustrating since more and more senior level now are required to manage juniors while also having works yourself. In previous company I attended meeting more than I develop. Thankfully my current company treat developers as developers.
cauliflower99 4y ago
The business value-added per developer is 80% from flow state and 20% from non-flow state following the Pareto principle. Can someone explain to me why this is true? It seems like the author just used the numbers 80 and 20 and concluded "the Pareto principle works here".
chiefalchemist 4y ago
> I sat through a particularly useless meeting the other week with a meeting screen full of other devs – oddly, it was initiated by a tech lead on a different team. This is a red flag. What type of org / culture would allow this to happen? Fact: Wasteful pointless meetings don't only plague developers. They plague everyone, if not society itself. - No agenda? Red flag. - No clear takeaways / going forward expectations (i.e., "X with do ___. Y will do ___...")? Red flag. - No decision / progress? Red flag. - No minutes (read: something trusted that let's non-attendees catch up)? Red flag. - Most are complicit & complacent with shite meetings? Red flag! Consistently sloppy meetings are a nearly perfect proxy for: 1) lack of training (i.e., ultimately is a leadership issue) 2) lack of trust (i.e., the more need for CYA, the more ppl invited) 3) micromanaging (in the sense that managers don't allow their direct reports to show up and participate; instead the manager must be there). -- Being a developer has nothing to do with this plague. Flow switching effects everyone. In fact, presenting it as a niche issue dilutes the argument for more productive meetings *for all*. p.s. If I had $20 for every waste of my time meeting I'd have Bezo's money, perhaps even Musk money.
ivanhoe 4y ago
I've always seen that my job as a lead, among other things, is to act as a buffer in communication between my team and "the business". One big thing is my devs not having to attend most of the meetings - I go there for them, and then on the next daily I pass the relevant information. If we need to make an estimates or architectural decisions, we do that in our internal meetings and then I let the business know what they need to know. Keeping meetings highly scoped is IMHO big win-win for both sides, because in reality devs don't really care about the business side that much, nor business cares about all the technical details (or even can understand them) so keeping them isolated and me (together with PM) just "translating" the information from business to dev lingo and back, is actually saving everyones' time, avoiding misunderstandings, and keeping meetings shorter and more focused.
ChrisMarshallNY 4y ago
I used to work for a Japanese corporation. You think you have it bad? Japanese corporations say “Hold my Asahi.” I’m talking around-the-clock meetings. Our Shinagawa headquarters was this huge building, with two floors dedicated to meeting rooms, and those rooms were constantly full. It has to do with the consensus-based methodology they use. It requires regular feedback between stakeholders. If you miss a meeting, you could find your team booted from the project, so managers often grab any poor random schlub from the engineering floor, and direct them to attend a meeting, where they have no clue, whatsoever, about the topic. They are only there to “stake a claim.” I often saw people fast asleep, in meetings. I have a general policy that regularly-scheduled meetings should always be avoided, but that never seems to happen, IRL.
jopsen 4y ago
This is just the cost of a meeting. The opportunity cost is a different factor, it's the cost of not doing what the dev would otherwise be doing. Given that your not hiring devs to make up hours lost to meetings, the opportunity cost is the cost of not shipping earlier or with more features. The caveat is that this all assumes you know what to build, if you don't attend meetings.
a-dub 4y ago
i've always thought it would be interesting to create a quarterly token system for meetings where meetings cost tokens depending on number of attendees (where ics are "expensive") and the ideal effect is that some level of consensus needs to be reached prior to calling the meeting in order to pool the tokens needed to pay for it. the reason why there are too many meetings is because they are free.
- RegW 4y ago
  Ah ha! I like it. Mangers with a restricted budget for meetings. The more people they invite, the more rapidly their quota burns.
- ryathal 4y ago
  I've heard of something like this being used to buy priority for a dev team to work, but expanding a similar system to scheduling meetings would be interesting. the biggest problem would probably be "meetings" become informal things to get around the rules rather than improve practices.
throwaway787544 4y ago
The thing that frustrates me about people who insist on meetings is that they're lazy. We all know we can communicate asynchronously. We all know that giving people more time to come to conclusions and do research leads to better decisions. And we all know that waiting for everyone to have free time in their schedule in order to make a decision is actively wasteful of current time. But many people continue to use meetings as the only method of group communication. People are creatures of habit. We need a formal change of culture within tech to stop using meetings by default to solve all our problems. We need a manifesto that says exactly when you should use a meeting, and when to use other methods. Take the guesswork out of it so it's second nature.
- ebiester 4y ago
  Check out the "Death By Meeting" by Patrick Lencioni for his take in a non-tech scenario.
- frakt0x90 4y ago
  Gitlab does this in their employee handbook. As a guideline they say if you go back and forth 3 times asynchronously, consider a meeting. I don't work there so I don't know how much people adhere to this in practice. https://about.gitlab.com/handbook/communication/#video-calls https://about.gitlab.com/handbook/communication/#video-calls https://about.gitlab.com/company/culture/all-remote/asynchronous/ https://about.gitlab.com/company/culture/all-remote/asynchro...
- ehnto 4y ago
  Especially considering hybrid remote/office and flexible working hours are becoming common. Asynchronous communication is such an advancement in productivity, documentation and clarity. Since it's all written down by default, and everyone can contribute even if they were away that day or otherwise engaged by work. I think software agencies are inherently better at this, since they don't have to estimate an opportunity cost, the opportunity cost is billable hours that developer is currently not doing because they are in a meeting. I find working at agencies a bit more simple, with a lot less of the Org BS, because their is a level of pragmatism you need to have in order to operate profitably. Even more true if your agency is mostly contractors, because your boss is probably watching money tick away inside their head during sprint planning.
EddieDante 4y ago
I found meetings much more objectionable when I worked onsite. Working at home, meetings don't bother me as much because nobody expects me to have my camera on and we're expected to keep our mikes muted unless we have something to say. So I can just listen while doing other things, like squats, pushups, crunches, etc., because most meetings are (like onion2k said) organizational and their substance is generally condensed into an email I can skim at my convenience on the off-chance that I missed something.
deleted 4y ago
[deleted]
ehnto 4y ago
I find meetings are often covering a deficit in the planning and documentation of the project and technology environment/project plan anyway. A great deal of the time, the information should have been documented somewhere already, and it would be much more valuable to the team long term if they just found the information, documented it properly, then circulated the document in an asynchronous way so that people can take their time to properly consider it and respond if needed and when they have time.
karaterobot 4y ago
When I was a developer, I hated meetings, and just wanted to work on my feature as much as I could. Tell me what you need to have built, and let me build it. When I switched to product design, I tried to respect the engineers' time by not scheduling synchronous meetings very often. I would write documents that nobody read (or at least did not comment on) and record video demos that I know for a fact only about 25% of people watched. What I said to them was: "here are the designs, and here's why I did it this way, and if that makes sense to you go for it, otherwise let's meet to answer questions". A couple engineers would reach out to me, most would never say a word. At retro, the feedback I got was "design is not communicating, we want to be involved earlier in the process". Okay, great! Maybe I went too far in trying to free up their time. So, I continued documenting my work, but also scheduled a 30 minute recurring meeting once per week, to synchronously update the engineers on where the design was headed: here's what we heard from customers, here's what I'm thinking we need, are there any constraints I should be aware of, and do you have any ideas on how we could approach this differently? Keep in mind that I'm still doing IC work on the design itself, and I'm putting in a lot of time documenting things for the engineers, and I'm attending way more meetings than them (this is the nature of design). I thought these design syncs were going great, but the feedback at a later retro was "gah! too many meetings, we don't need a recurring meeting with design every week". Since documenting things and scheduling meetings on an ad hoc basis was not enough communication, and 30 minutes a week was too much of a burden, and most of the team would not voluntarily engage in asynchronous communication anyway, I was sort of at a loss about how to make them happy. My conclusion was that every engineer is different, and there is no magic bullet that results in perfect communication but does not "break flow". And since they are being paid for their time, I'm not going to try to tiptoe around scheduling meetings when I need to, to do my part of the job.
- y-c-o-m-b 4y ago
  I'm like you; tell me what you need and I'll just do it. If I get a work-item that is decently written or at minimum has design mocks, I can immediately get to work and basically never have to communicate backwards with anyone. Like you said though, everyone is different. I work alongside many devs that need hand-holding through the entire process. That's totally fine, but what I ask is don't make my attendance to meetings mandatory. Don't force me to partake in the ceremonial BS. I get nothing out of it. If you make the attendees optional, then they can choose whether or not they need that meeting. I know - with strong confidence - that I don't need the meetings.
fijiaarone 4y ago
Meeting means coming to the same place. But not all meetings are the same. Here are some reasons for meeting: 1. Working together 2. Sharing information 3. Reaching a consensus 4. Social gathering Most meetings do not qualify for any of these reasons. And if they do, you probably don’t call them meetings. They’re discussions, collaborations, announcements, or parties; and are usually self-organizing, asynchronous,optional attendance, and flexible scheduling. But meetings usually have a purpose like: 5. Satisfy the ego of the person organizing the meeting 6. Make sure everyone is in attendance 7. Get the status of everyone’s work 8. Occupy time You can see that none of these are valuable or meaningful and generally don’t benefit most of the meeting attendees. If there is any purpose or benefit to the group, it can be done asynchronously and individually.

134 points by redbell 4y ago

$200K comp and 2 weeks of PTO. I don’t know how people handle only having 2 weeks off per year. American working culture is bizarre.

dilyevsky 4y ago
I think most european countries have 4 weeks counted as weeks not days and american ones usually only count work days so 15 days is actually 3 weeks. At google I had 25 days in my last year = 5 weeks which is not too bad. Amazon is traditionally a shit show with only 2 weeks your first year and 3w thereafter
- nicoburns 4y ago
  4 or 5 weeks, usually (although this might vary by country) counted in days where 5 days = 1 week for a full time worker.
- Traster 4y ago
  The UK has 28 days minimum, that includes "bank holidays" (USA: Public holidays?) which are days decided by the government as holidays for everyone - like Christmas. So it's more like 5.6 weeks total in the UK, and the UK aren't particularly generous - your final year in Google, an exceptional comapany, barely meets the statutory minimum in the UK.
  - dilyevsky 4y ago
    Google also had around 14 holidays so no it far exceeds uk min requirement. Most us companies dont count holidays in their pto numbers and most have around 10 holidays
  - ByteJockey 4y ago
    That might be the difference, nobody (that I've met) in the US would count a public holiday in PTO time. Google's not super exceptional in this matter (that's mostly their pay/on-site experience). I have 4 weeks (20 days) at the moment, and have for a few years, along with 8 paid holidays (28 days total). Next year I get a fifth week (33 days with holidays). I don't work at a FAANG/MANGA company, but just some random company in the Mid-West. But I've also worked service jobs before with 0 paid days. Holidays were mandatory work days because everyone who did have decent jobs were off and wanted to eat at a restaurant. The talk about the bottom in the US being below elsewhere isn't a myth. The US doesn't like putting floors on matters this side of the 60s.
  - infamia 4y ago
    Is it still common in the UK/EU to only grant "holiday pay" (i.e. you get paid a fraction of your normal salary) during PTO? In the U.S. it has always been standard practice to get paid your full salary on PTO and national holidays. Even if that is so, I still think I prefer the European system.
    - juki 4y ago
      At least in Finland you get the holiday pay (0.5 * salary) on top of the normal salary. It can also be converted to additional days off.
    - steve_gh 4y ago
      No
    - EEBio 4y ago
      Holiday pay is full pay. Parental leave is usually not. Parental leaves start rather high (100% or 90%) and then go slowly down (to 60% or 50%)
- Scarblac 4y ago
  And sick days aren't limited, you can't control how long you're going to be sick.
- deleted 4y ago
  [deleted]
ezfe 4y ago
I’m a “Software Engineer” in Boston at a large company. Base time off is 24 days flexible time off (sick and personal) plus 8 fixed holidays. Lots of jobs are just shitty.
PragmaticPulp 4y ago
PTO is measured in addition to standard holidays, which is 8-11 days depending on the company. So 2 weeks of PTO would mean 3.5-4 weeks of time off total at most professional jobs. I haven’t seen a job posting or working at a company with only 2 weeks of PTO since I was a junior, but they’re out there.
dkasper 4y ago
At Meta we get 21 PTO days + 2 choice days + 5 "Meta days" + 10 government holidays. That's a total of almost 7 weeks off... Not sure if it's still the case but when I worked at Reddit we had "unlimited" PTO and I saw quite a few people taking over 6 weeks off per year. If you want to see an extreme work culture maybe look at China or Japan, but as far as tech goes the US ain't bad these days.

maxehmookau 4y ago

2 weeks PTO is average? That's nuts! Shut your laptops and go outside!

ggm 4y ago

The inverse function: "what level of aggregated pay makes a meeting more than an MBP" is needed because MBP price and renumeration vary by economy and time. I for one would welcome this service so I can ironically distain meetings on sound financial bases.

Tagbert 4y ago

Do developers really spend that much of their time in meetings? When I have worked closely with dev teams, it seems like there are a few regular short coordination meetings that are over quickly. Then there are occasionally more substantial meetings where they are working out architectural questions. As a program manager, I usually have 4-5 meetings a day because that kind of is my job to review and coordinate. Developers are only rarely in those meetings.

goalieca 4y ago
I’ve had stints where it’s mostly meetings with an hour here or there of actual work. Too much talking about doing stuff instead of doing the thing. More process to ensure quality instead of just making someone responsible for it.
- Tagbert 4y ago
  Sounds like a very dysfunctional organization
torstenvl 4y ago
Yes but the function isn't workinghours - meetinglength > timeneededforwork The function is workinghours modulo meetingtimes > timeneededfordiscreteworkingblocks A task that requires four hours of concentration cannot get done in a day with a five-minute mid-morning coordination meeting and a five-minute mid-afternoon admin huddle.
Trasmatta 4y ago
Depends on the team. Also, a single meeting is extremely expensive for a developer's productivity. I generally think the developer productivity cost is about twice the amount of time it actually takes. And it's even worse when they're staggered throughout the day. Two one hour meetings is more like requesting 4 hours (or more, depending on what time of the day they take place in). Managers not realizing this is one of the major failings of modern day software development.
steveBK123 4y ago
It varies by org. I’ve been on teams where the only recurring meeting was a 30min weekly. On the other hand I’ve been on teams with 25+ devs on 6+ hours/week of recurring meetings together.. plus any ad-hocs, project or task specific meetings, etc. Some were 2 full hours long and could run over to 3 hours. Was insane.

Traster 4y ago

Co-ordinated effort is much more valuable than raw engineer effort aimed scatter-gun at a project. There's so much more to meetings than the author covers in this. For example, in a meeting you're made aware that engineer X is working on Y, you have prior experience in Y. Immediate win. Does this happen 100% of the time? Of course not, but there's a probability it will. Hell it doesn't have to be experience, it could just be an interestin insight - what are we paying you guys for anyway. Communication often is the most valuable thing you can foster as a manager, and this article just seems naive. Sure, there are bad meetings. But we don't measure the thousands of hours of wasted engienering hours that could've been saved by having 1 decent meeting.

dilyevsky 4y ago
Consider this - communication on its own is worthless if no time is left to do productive work. If communication was so important then slack/hipchat/etc shitposters would be your most productive employees and they usually aint
- fijiaarone 4y ago
  I had a manager who measured how much time everyone spent using slack and actually boasted that he was the person most active on slack as if that was some measure of productivity. And I guarantee you that 90% of his posts on slack were cat gifs and the like. Most of the other 270% of his messages were automated notifications for build, deployment, and test failures that everybody ignored.
recurrence 4y ago
Hi, author here -- kind of weird to see my post on hn. Yea, a good meeting can absolutely be worth all the developer time it costs! I tried to carefully qualify all my calculations in terms of 'opportunity cost' and 'pointless meetings', but clearly it didn't work :). The main idea behind the post is that the expected utility of a meeting with n developer, E[u(x_n)], should be greater than or equal to the opportunity cost of having that many developers in the meeting. Furthermore, through batching and async context transfer we can reduce the opportunity cost of having those developers in that meeting, which is pure upside for the business. In a previous job I frequently got invited to meetings that were planned because the expected utility is > 0, which is imo really bad business.

peterbonney 4y ago

Sort of an obvious point, but the opportunity cost analysis here has basically nothing to do with whether the meeting attendees are developers - it applies to anyone who has other things they could be doing with their time and has a cost from context switching. On a separate point, missing from this is the potential opportunity cost arising from NOT having a meeting. It’s a harsh reality, but sometimes the reason you’re sitting in that “pointless” meeting is that there’s a small chance you’ll need to be called upon, and if you aren’t present there is a person or people whose time is even MORE expensive than yours who will suffer a cost that more than offsets the cost of 2 or 5 or 10 developers sitting there twiddling their thumbs. (That’s not often the case, mind you, but it does happen.) Anyway, “High Output Management” by Andy Grove does a great job articulating the math of meetings and how to maximize their value.

recurrence 4y ago
Adding High Output Management to my to-read list, thanks!
civilized 4y ago
> It’s a harsh reality, but sometimes the reason you’re sitting in that “pointless” meeting is that there’s a small chance you’ll need to be called upon, and if you aren’t present there is a person or people whose time is even MORE expensive than yours who will suffer a cost that more than offsets the cost of 2 or 5 or 10 developers sitting there twiddling their thumbs. Why are we in this horrific situation where a person's knowledge can only be leveraged if they are "called on" in 30 seconds of an hour-long meeting? My God, Slack me if you must.
- marcosdumay 4y ago
  Some work is inherently synchronous. On those, if you are needed for 30 seconds but it takes 30 minutes for you to get there, the people doing it will have to stop until you come. All work is not this way (even though some managers pretend it is), and very likely the majority of your work isn't like it (assuming you are a software developer). But some work is like it, and pretending it isn't as about as expensive as gathering people doing asynchronous work into meetings. (The "what should we do" decisions normally require more synchronous work than "how should we do it", some professions do spend most of their time in the former.)

travisgriggs 4y ago

Hmm. I think the author got confused. “A business case for fewer meetings.” That’s better. I can help develop it if they want.

Layke1123 4y ago
The developers are the only ones who actually know how to do the actual work needed to teach machines what businesses do, which is why we see all the bull shit happening. Execs and managers are neigh useless in the modern world because they can't fake it anymore. Cut the middle men out!
- travisgriggs 4y ago
  Good luck. I fear Pournelle’s iron law of bureaucracy will ever prevail. Sadly.

onion2k 4y ago

Meetings force us to context switch, kill our flow, and sap our job satisfaction long term. That's what developers say, but I suspect that it's not actually true. Something that leads to a far worse reduction in job satisfaction is not knowing what's going on, being surprised with complex features that the product people have assumed will be simple, and not having opportunities to be seen as an expert. Those things generally require developers to be in meetings. If devs don't have those things they get grumpy and quit. The problem with most meetings is organisational. If your day is fragmented by lots of one hour meetings with one hour gaps between them then you can't get much else done. That's the frustrating part - you have lots of meetings and lots of 'dead space' between them. If you change things so meetings are 50 minutes long, and only have ten minutes between them, and that 'defrags' all the 'dead space' to a single block where you can focus, then meetings suddenly stop being so much of a problem. If you hate meetings because they require too much context switching away from code, and they stop you focusing, reorganise them so they don't do that. If your first reaction to this suggestion is "But I can't because I don't control when meetings are", then the problem isn't meetings, it's your colleagues not giving a shit about your working environment. That's a very bad sign.

pif 4y ago
> Meetings force us to context switch, kill our flow, and sap our job satisfaction long term. That's what programmers say. Developing software is much more than programming, at least when you are developing something else than an information system.
MarkMarine 4y ago
How do you manage to move 8 other people's schedules around such that you get these blocks of time? Usually the hardest people to schedule are the manager who wants to sit in on every meeting, and the PM who also wants to be in every meeting. They look at my time and see something easy to schedule, there is a big empty block right there and it fits the tiny sliver of time they have free in the day. There is an impedance mismatch between professional meeting attenders, and the people the build, and the meeting attenders are in charge.
- 4y ago

adamp42 4y ago

No meeting days are the way. I advocated for a no meeting day in one of my workplaces and our director agreed to try it out. We called them "Developer Days" and he'd block off the entire day on everyone's calendar and enforce to anyone outside the team we simply were not available those days. Worked so well we ended up adding a second Developer Day! And meetings become more productive too since we batched those up into the other days and could focus on the meeting instead of context switching between talking with people and talking with a computer.

cakoose 4y ago

> The business value-added per developer is 80% from flow state and 20% from non-flow state following the Pareto principle. That's not what the Pareto principle says, is it? Am I missing something?

hinkley 4y ago
It’s generally held that Pareto applies to a lot of things you wouldn’t assume it does. But in this case I think Sturgeon’s Law is better: 90% of everything is crap. This is a journeyman or lower understanding of development (how old is the author? Should they know better?). In fact I’ll assert that he has it exactly backward, and that 80% of code you write only provides 20% of your value. Only code monkeys provide 80% of their value from flow state. And Code Monkeys always feel underpaid because they think writing code is their entire value., and which is a slippery slope to thinking more code is better.
benplumley 4y ago
Not at all, the application of Pareto here would be something like "80% of a developer's value is contributed in 20% of their time", that 20% being the time spent in the flow state. Edit: rereading, those are actually the same thing, though the quote is confusing because it refers to a different 20% than Pareto refers to.
- marcosdumay 4y ago
  > "80% of a developer's value is contributed in 20% of their time", that 20% being the time spent in the flow state. Hum, no. One does absolutely not follow from the other. If the Pareto principle actually applies, it would say that 80% of the development value comes from 20% of the time the developer spends in flow. And the rest 80% of the flow time adds only to 20% of the value. The same would come from the value from meetings and the time spent on them. But do keep in mind that, about the Pareto principle: you can never predict the value of anything - those are only post-fact measurements; and those proportions vary widely, it's never actually 80-20.

thrower123 4y ago

I've got about three meetings in me on an average day before my batteries are exhausted and I am effectively done for the day. When agile-ish processes use up on of those lives every day, that leaves very little slack before recurring customer statusing, actual troubleshooting, or an honest-to-god productive planning meeting wipes the counter out. I suspect you could waste a lot less time if meetings required agendas distributed beforehand and minutes distributed afterwards, but absolutely no one does that, or would read such material if it was produced.

Simon_O_Rourke 4y ago

I'm delighted someone is putting a cost to pointless meetings like those described (well, pointless from a devs perspective). I worked in a utility company, where morale was in the basement, and management organized a full day (on-site) off-site meeting. 60 to 70 devs in a big room, whiteboards everywhere. Some corporate events enabler stands up and says everyone is to write on their whiteboard what the word "team" means to them, then discuss it. I did the math, and after a couple of hours each group had to discuss what they found. I said it's just cost us 15k for this chitchat and at the end of it we'll be none the wiser and no actions will be taken. Was called in to the bosses office the next day and chewed out for not being a team player. Week after that the boss was fired. shrugs

zerop 4y ago

One of the main causes of too many meetings is number of priorities org has. Lots of Parallel initiatives are a big problem. This causes inefficient meetings, not all stakeholders come.

Viliam1234 4y ago
Doing things in parallel contributes to this problem a lot. Daily standups, plus a meeting or two per week seems doable. But if you work on two or three things in parallel, and you need to multiply the number of meetings by two or three, suddenly it feels like you spend more time on meetings than being able to focus on your work.

choeger 4y ago

The worst part is the non-linear growth in productivity of uninterrupted blocks of work. Not always, but very often a 4h block is much more valuable than 2 blocks of 2h with a meeting in between. This is not even about "flow", it's about getting your work environment sorted out, getting all the tools ready, doing a couple of experiments, actually thinking about the context of your solution, etc. It's a very costly fallacy that developer productivity is simply linearly dependent on time spent on an issue. In consequence, I strongly believe that there should be a minimum latency in software development that cannot be cut further. Say, it's two days. That would mean you should not attempt to have any meetings from Wednesday onwards and be able to deploy on Thursday evenings and collect and discuss results on Fridays. Monday's for retros, especially regarding Friday's findings and Tuesday is the day for planning. That's a very, very compact schedule and I doubt it's sustainable, to be honest. But it's already longer, and has stricter constraints, than most managers would accept, I bet.

Macha 4y ago
Yeah, this has been my problem since being in a role where I am more responsible for the work of others and reporting to upper management. Theoretically I still have 50% of them for individual work I had before, but that's fragmented and prone to interruptions because some exec wants to know how the XYZ project is going in between weekly status updates, or some junior developer needs help understanding why the Foo system does what it does the way it does
- fendy3002 4y ago
  Which is frustrating since more and more senior level now are required to manage juniors while also having works yourself. In previous company I attended meeting more than I develop. Thankfully my current company treat developers as developers.

cauliflower99 4y ago

The business value-added per developer is 80% from flow state and 20% from non-flow state following the Pareto principle. Can someone explain to me why this is true? It seems like the author just used the numbers 80 and 20 and concluded "the Pareto principle works here".

chiefalchemist 4y ago

> I sat through a particularly useless meeting the other week with a meeting screen full of other devs – oddly, it was initiated by a tech lead on a different team. This is a red flag. What type of org / culture would allow this to happen? Fact: Wasteful pointless meetings don't only plague developers. They plague everyone, if not society itself. - No agenda? Red flag. - No clear takeaways / going forward expectations (i.e., "X with do ___. Y will do ___...")? Red flag. - No decision / progress? Red flag. - No minutes (read: something trusted that let's non-attendees catch up)? Red flag. - Most are complicit & complacent with shite meetings? Red flag! Consistently sloppy meetings are a nearly perfect proxy for: 1) lack of training (i.e., ultimately is a leadership issue) 2) lack of trust (i.e., the more need for CYA, the more ppl invited) 3) micromanaging (in the sense that managers don't allow their direct reports to show up and participate; instead the manager must be there). -- Being a developer has nothing to do with this plague. Flow switching effects everyone. In fact, presenting it as a niche issue dilutes the argument for more productive meetings *for all*. p.s. If I had $20 for every waste of my time meeting I'd have Bezo's money, perhaps even Musk money.

ivanhoe 4y ago

I've always seen that my job as a lead, among other things, is to act as a buffer in communication between my team and "the business". One big thing is my devs not having to attend most of the meetings - I go there for them, and then on the next daily I pass the relevant information. If we need to make an estimates or architectural decisions, we do that in our internal meetings and then I let the business know what they need to know. Keeping meetings highly scoped is IMHO big win-win for both sides, because in reality devs don't really care about the business side that much, nor business cares about all the technical details (or even can understand them) so keeping them isolated and me (together with PM) just "translating" the information from business to dev lingo and back, is actually saving everyones' time, avoiding misunderstandings, and keeping meetings shorter and more focused.

ChrisMarshallNY 4y ago

I used to work for a Japanese corporation. You think you have it bad? Japanese corporations say “Hold my Asahi.” I’m talking around-the-clock meetings. Our Shinagawa headquarters was this huge building, with two floors dedicated to meeting rooms, and those rooms were constantly full. It has to do with the consensus-based methodology they use. It requires regular feedback between stakeholders. If you miss a meeting, you could find your team booted from the project, so managers often grab any poor random schlub from the engineering floor, and direct them to attend a meeting, where they have no clue, whatsoever, about the topic. They are only there to “stake a claim.” I often saw people fast asleep, in meetings. I have a general policy that regularly-scheduled meetings should always be avoided, but that never seems to happen, IRL.

jopsen 4y ago

This is just the cost of a meeting. The opportunity cost is a different factor, it's the cost of not doing what the dev would otherwise be doing. Given that your not hiring devs to make up hours lost to meetings, the opportunity cost is the cost of not shipping earlier or with more features. The caveat is that this all assumes you know what to build, if you don't attend meetings.

a-dub 4y ago

i've always thought it would be interesting to create a quarterly token system for meetings where meetings cost tokens depending on number of attendees (where ics are "expensive") and the ideal effect is that some level of consensus needs to be reached prior to calling the meeting in order to pool the tokens needed to pay for it. the reason why there are too many meetings is because they are free.

RegW 4y ago
Ah ha! I like it. Mangers with a restricted budget for meetings. The more people they invite, the more rapidly their quota burns.
ryathal 4y ago
I've heard of something like this being used to buy priority for a dev team to work, but expanding a similar system to scheduling meetings would be interesting. the biggest problem would probably be "meetings" become informal things to get around the rules rather than improve practices.

throwaway787544 4y ago

The thing that frustrates me about people who insist on meetings is that they're lazy. We all know we can communicate asynchronously. We all know that giving people more time to come to conclusions and do research leads to better decisions. And we all know that waiting for everyone to have free time in their schedule in order to make a decision is actively wasteful of current time. But many people continue to use meetings as the only method of group communication. People are creatures of habit. We need a formal change of culture within tech to stop using meetings by default to solve all our problems. We need a manifesto that says exactly when you should use a meeting, and when to use other methods. Take the guesswork out of it so it's second nature.

ebiester 4y ago
Check out the "Death By Meeting" by Patrick Lencioni for his take in a non-tech scenario.
frakt0x90 4y ago
Gitlab does this in their employee handbook. As a guideline they say if you go back and forth 3 times asynchronously, consider a meeting. I don't work there so I don't know how much people adhere to this in practice. https://about.gitlab.com/handbook/communication/#video-calls https://about.gitlab.com/handbook/communication/#video-calls https://about.gitlab.com/company/culture/all-remote/asynchronous/ https://about.gitlab.com/company/culture/all-remote/asynchro...
ehnto 4y ago
Especially considering hybrid remote/office and flexible working hours are becoming common. Asynchronous communication is such an advancement in productivity, documentation and clarity. Since it's all written down by default, and everyone can contribute even if they were away that day or otherwise engaged by work. I think software agencies are inherently better at this, since they don't have to estimate an opportunity cost, the opportunity cost is billable hours that developer is currently not doing because they are in a meeting. I find working at agencies a bit more simple, with a lot less of the Org BS, because their is a level of pragmatism you need to have in order to operate profitably. Even more true if your agency is mostly contractors, because your boss is probably watching money tick away inside their head during sprint planning.

EddieDante 4y ago

I found meetings much more objectionable when I worked onsite. Working at home, meetings don't bother me as much because nobody expects me to have my camera on and we're expected to keep our mikes muted unless we have something to say. So I can just listen while doing other things, like squats, pushups, crunches, etc., because most meetings are (like onion2k said) organizational and their substance is generally condensed into an email I can skim at my convenience on the off-chance that I missed something.

deleted 4y ago

[deleted]

ehnto 4y ago

I find meetings are often covering a deficit in the planning and documentation of the project and technology environment/project plan anyway. A great deal of the time, the information should have been documented somewhere already, and it would be much more valuable to the team long term if they just found the information, documented it properly, then circulated the document in an asynchronous way so that people can take their time to properly consider it and respond if needed and when they have time.

karaterobot 4y ago

When I was a developer, I hated meetings, and just wanted to work on my feature as much as I could. Tell me what you need to have built, and let me build it. When I switched to product design, I tried to respect the engineers' time by not scheduling synchronous meetings very often. I would write documents that nobody read (or at least did not comment on) and record video demos that I know for a fact only about 25% of people watched. What I said to them was: "here are the designs, and here's why I did it this way, and if that makes sense to you go for it, otherwise let's meet to answer questions". A couple engineers would reach out to me, most would never say a word. At retro, the feedback I got was "design is not communicating, we want to be involved earlier in the process". Okay, great! Maybe I went too far in trying to free up their time. So, I continued documenting my work, but also scheduled a 30 minute recurring meeting once per week, to synchronously update the engineers on where the design was headed: here's what we heard from customers, here's what I'm thinking we need, are there any constraints I should be aware of, and do you have any ideas on how we could approach this differently? Keep in mind that I'm still doing IC work on the design itself, and I'm putting in a lot of time documenting things for the engineers, and I'm attending way more meetings than them (this is the nature of design). I thought these design syncs were going great, but the feedback at a later retro was "gah! too many meetings, we don't need a recurring meeting with design every week". Since documenting things and scheduling meetings on an ad hoc basis was not enough communication, and 30 minutes a week was too much of a burden, and most of the team would not voluntarily engage in asynchronous communication anyway, I was sort of at a loss about how to make them happy. My conclusion was that every engineer is different, and there is no magic bullet that results in perfect communication but does not "break flow". And since they are being paid for their time, I'm not going to try to tiptoe around scheduling meetings when I need to, to do my part of the job.

y-c-o-m-b 4y ago
I'm like you; tell me what you need and I'll just do it. If I get a work-item that is decently written or at minimum has design mocks, I can immediately get to work and basically never have to communicate backwards with anyone. Like you said though, everyone is different. I work alongside many devs that need hand-holding through the entire process. That's totally fine, but what I ask is don't make my attendance to meetings mandatory. Don't force me to partake in the ceremonial BS. I get nothing out of it. If you make the attendees optional, then they can choose whether or not they need that meeting. I know - with strong confidence - that I don't need the meetings.

fijiaarone 4y ago

Meeting means coming to the same place. But not all meetings are the same. Here are some reasons for meeting: 1. Working together 2. Sharing information 3. Reaching a consensus 4. Social gathering Most meetings do not qualify for any of these reasons. And if they do, you probably don’t call them meetings. They’re discussions, collaborations, announcements, or parties; and are usually self-organizing, asynchronous,optional attendance, and flexible scheduling. But meetings usually have a purpose like: 5. Satisfy the ego of the person organizing the meeting 6. Make sure everyone is in attendance 7. Get the status of everyone’s work 8. Occupy time You can see that none of these are valuable or meaningful and generally don’t benefit most of the meeting attendees. If there is any purpose or benefit to the group, it can be done asynchronously and individually.