Now I'm realizing my job is actually to attend meetings. I should ask for a raise! Though in reality I'm just going to quit soon.
The sweet irony is that this meeting heavy company of 50ish people uses Zoom without pro accounts...it's enough to make a grown man cry.
My manager absolutely has more than 8 hours of meetings ina given week, and not jut useless ones. I've seen calendars of people a level or two above me where several days a week are wall-to-wall meetings. I don't think it's all that uncommon either. At some point, your job is coordinating and strategizing and communicating what needs to be done, and after a while, beyond meetings being an unfortunate nesesity, the meetings are the work
Unfortunately, they are. Largely due to inexperience and incompetence at the managerial level (zero technical chops once you go any level above IC).
I'm well aware most software companies aren't like this, though. They'd go out of business, like this one will. Almost every key engineer (including CTO) has left this company already - six of them in the three months since I joined. One of them wrote a 10 page open letter to the CEO on the way out. Things are a real mess...
Among other gems in that open letter was a link to this article [0].
[0] https://neilonsoftware.com/2020/09/08/non-technical-developm...
Federate your business today.
It's probably not, though - or, at least one of those meetings is the one where you have to showcase/demonstrate what you "accomplished" in spite of all the interruptions. You do have to produce something in spite of all the time wasted in meetings. I've unironically been told that that's what the weekends are for.
> I've unironically been told that that's what the weekends are for.
This kind of rings true, I've only been here around 3 months. I did spend a couple of weekends on code in the first month, but overall this company (and my comp) really isn't worth that kind of effort, so I've stopped.
I really only joined this company because I wanted a better work life balance (joke's on me) and my business isn't yet profitable, but I'm actually financially independent so it's tough to muster up motivation to work overtime for free.
Or pitting two managers against each other? I would love to attend your meeting but this other team needs this. Let them schedule it out for you?
And sometimes with an agenda, I will try to reply and resolve whatever it was about asynchronously. There have been several meetings avoided when I replied with something like "this sounds like known bug #1234" or "here's the wiki page documenting this: is there something else not covered?".
My # meetings went down after I started doing this. Maybe it changed the culture in a good way, or maybe people got tired of me and stopped inviting me to meetings.. but either way seems like success.
How doesn't that make sense? If you want to compress all your meetings into one day for every two-week sprint (ten working days), you only need to average 48 minutes a day of meetings to fill that day. That's not an obscene amount.
It just sounds like a combination of lazy scheduling and no desire to improve dev experience.
I have a plan for this. I'm writing a small program to move certain meetings to an auto-scheduled state. You pick some blocks on your calendar where you'll accept auto-scheduled meetings. You then say "I want to have a meeting with X, Y, and Z", and the system will use a constraint solver to find a time. The cost function favors bin-packed meetings, keeping entire days free, etc. If existing meetings have to move to optimize the cost function, so be it.
I don't actually know if people will tolerate this. People are creatures of habit, so if you're used to a biweekly team meeting on Monday, it will be weird when it gets replaced with a postmortem review that starts 30 minutes earlier and the team meeting moves to Thursday or whatever. I also think it will be hard to get people to commit to giving the bot a slot to work with. We shall see. If anything interesting comes of this I'll write up something about how it went.
Edit: I see what you're saying, that makes perfect sense.
> Finding time for six one-[unit] [block]s is by definition easier than finding time for one six-[unit] [block] of meetings.
that you responded to. As long as there's anything at all with fixed position, you can end up with fragmentation, and even when (you can guarantee) there isn't, the former is just "exactly as easy" as the latter, so the general case degrades to "is by definition at least as easy as".
That's frustrating in its own right, but what's worse is that nobody ever factors it into scheduling estimates. If your team is getting 6 hours of work done in an 8 hour day, that's the equivalent of the whole team taking a day off every week and expecting everything to still get done on schedule. Except it's worse, because it makes you less efficient all the time rather than just one day a week.
On the other hand, I don't think that trying to fit all weekly meetings into a single day would solve the problem either. It's often the case that decision makers — the people you need to have at a lot of meetings — are involved in different areas of a business or product, so they'd have overlapping demands on their time. Where I work, there are a few people who are like this, and their schedule shapes how meetings are planned for everyone else. When any of these people have conflicting meetings scheduled, one or more of those meetings have to be rescheduled for another day.
So now everyone else has 2 half days of meetings a week, rather than one full day. And then, what happens if you learn new information and have to make a decision? Do you wait a week to talk about it? Probably not. So, you'd probably have a couple heavy meeting days, and then a number of ad hoc meetings scattered over the week. This is not the improvement we were looking for, and I think at a certain point the team would just drift away from the initial vision, and settle into the former pattern.
Not saying it's a good thing!
It sounds to me like you guys are estimating in hours, thus you give an 8 hour estimate, they expect something to be done 8 work hours after you started work. Everyone knows you have 80 hours in a two week period so they expect you do finish 10 of these 8 hour tickets.
Compare that to Story Points. Your velocity over a two week sprint is auto adjusting for the typical/average meeting load and other interruptions. If you estimate a ticket at 8 story points and your velocity is 24 story points then everyone should expect you to finish 3 of these tasks per sprint.
This is obviously all 'on average' and there might be a production incident that means this time you didn't get it all done or maybe the other way around, someone got sick and 3 large meetings didn't happen and you got a 4th ticket through.
Also note that I chose 8 story points at random. 8 story points is specifically NOT to be equated with 8 hours. Story points are just uses as a relative complexity measure, meaning something with 3 story points is roughly a third as complex as that 8 pointer.
Many managers and even people that claim to be Scrum Product Owner or even Scrum Masters don't really understand that.
I've been somewhere that did this, and it worked reasonably well.
Story points are not a cureall. But it can help shift the conversation even with the 'unreasonable' people that just look at the hours vs a 40 hour work week. As mentioned though it needs someone that really understands what story points are and that won't let "them" just equate story points to hours. Seen that too many times even from "Scrum Masters". If 2 Story Points always equal 16 hours then you don't need to use Story Points.
Back to the preciseness. You estimated 30 hours but it took 33? How dare you! You could try and only estimate in whole or half days to mitigate.
Story points? They have a built in jitter as estimates get larger. 0.5 1 2 3 5 8 13 20... Some unreasonable people will try to compute a number of hours from your velocity. Luckily it will usually at least be imprecise but really you should try to make them understand that it makes no sense to even do that. Also don't let them do math with story points. That's a try at making thing more precise again which just doesn't make sense. Jira for example only allowed whole numbers in the story point field. They were pressured by customers to allow/show floats. That make no sense!
Even with story points you should only take in 70-80% of your velocity into each sprint. I usually average the velocity over the last few sprints too. It all serves to make it 'less precise feeling'. Yes that's math but the only math I will allow: avg(last5SprintsVelocity)*0.75 is what we take in. Round about, a bit more or a bit less depending on how the team feels since this never matches 100% to what's in the sprint anyway.