Sad, but I would occasionally use my "unlimited" PTO to take a week off and just get work done. Most of the pain started when we transitioned to a sprints from a lack of process. In theory, this was to make things faster (which actually most of the reasons we were so slow was unrelated to process). My week suddenly went from getting things done to:
- 60 minute meetings fighting over whether tickets were 3 or 5 story points
- turning our entire process into some kind of perverse waterfall method where stories involved days of prep work defining every step so that we could accurately estimate story points (I thought this was the opposite of agile?)
- offers to "help" from project managers and managers when things took longer than expected - this help took the form of additional meetings.
- absolute inflexibility over my noon standup. I could be in the deepest of zones and people would literally slack repeatedly until you showed up for that thing
Cue the "oh you were doing <X> wrong!!" people. Modern software practice sucks. Its fine for small bugs and very well defined tasks. Outside of that it is just interruptions, interruptions, interruptions.
I also ended up just quitting. New place is better, but still in many ways the same. At least here I don't have comparisons made to my old days of the pre-software-process productivity.
Were you playing planning poker? The 3 or 5 story points is something I've definitely experienced.
Standups are okay, but they have to really be focused. Too often I see people dragging the standup into a side discussion instead of handling it off line. I also don't think they need to be daily. Twice a week is enough.
The real problem is micro management. Breaking everything down into bite sized ("2 or 3 point" chunks) is incredibly tedious. In the old days, estimates were less granular. "Joe, we need you to build X. Can you do that in 3 weeks? It also needs to handle blah."
- 60 minute meetings fighting over whether tickets were 3 or 5 story points
- absolute inflexibility over my noon standup. I could be in the deepest of zones and people would literally slack repeatedly until you showed up for that thing
I've never worked anywhere with story-points, but reading about it now sounds like a metric that will be abused the moment there's any meaning or consequence behind it
But you roughly need to understand what the company is trying to do - namely: Someone has a job to pick features that we know customers want, and they've been tasked to provide the most value as quickly as possible.
This means someone has to try to guess roughly how long it will take for a feature to materialize, and weigh that against the value it will provide to customers (and then the company - since we're paid by customers).
It's a shit job, but as long as it's clear that teams will screw it up, and that point velocity DOES NOT continually increase over time (unless devs are lying), and everyone understands why they're getting asked - it can be a reasonably productive way to lay out timelines.
From my experience, it only works if the entire company is completely bought in to the entire system. Even going so far as the SAFe framework. Companies think they can pick/choose which pieces they implement and this is a recipe for failure.
Don't think I've ever disagreed more passionately with an HN comment. Being "bought in" to agile development means individuals over processes, teams pick and choose what works for them. Insisting that everyone everywhere goes all the way on the same predefined process is as far away as it gets.
Is this practical though. An engineering team has a product team, a sales team that needs a feature. If those 3 teams don't align on the fact that the dev team is practicing "agile" and can expect potential drastic changes to customer promises, then they'll be issues.
The sales team does not need a feature. The sales team needs to convince a customer to sign -- and then to stay a happy customer and refer others.
The product-management team also does not need a "feature"; they need to identify which of the customer's problems the org can solve to get the customer to sign, stay, and refer.
It's the job of engineering to write clean, maintainable code that gets the customer to do those things in an ethical way. That's it. By this metric, they should write as little code as possible -- preferably none at all.
The whole point of agile (without the scare-quotes, without the branding) is that human beings have conversations about the business' needs (both the customer's and the seller's), continuously uncovering more and more information -- and working together to transform that information into a solution.
If the customer's org -- or the seller's org -- managed to make it for 3 months without needing to change a planned feature, that's equivalent to saying that they failed to learn anything for 3 months. That would be pretty worrying.
The issue happens, as you rightfully note, when everyone in the company suddenly decides they're qualified to be engineers -- and they start deciding what features need to be built to solve business problems. That then turns the actual engineers into assembly-line workers who are simply there to blindly build those features.
In a healthy org, we recognize that the job of sales is to build relationships and gather information; the job of product-management is to translate that raw information into clearly-articulated problem statements and get buy-in across stakeholders and customers; and the job of engineering is to decide how to solve those business problems.
And, yes, as part of that, the questions that engineers ask may well ripple all the way back to changing the problem statement itself. That is why engineering, product-management, marketing, and sales all need to work together to build a great product.
I love this soapbox! I'm trying to figure out why a well-intentioned company starts this way, and then quickly digresses. I think part of the issue is the feedback loop doesn't exist. If your end to end cycle is done, the sales team can tell the customer that feature x will be done on date y (we can say they should never gives dates but I think this is impractical). Then, let's say priorities change, and the agile cycle determines that we should focus on other items. I think product and sales fail to "bubble this up" and then a toxic culture starts to brew where product and sales despise engineering and middle management can't be trusted to "fight for their engineers".
Thanks! And, yeah, I agree -- it's basically a communication breakdown.
It takes work to continuously bring everyone together to disagree-and-commit over priorities. It's one of the major components of leadership and influence in organizations these days. Ideally, managers are continuously broadcasting information and regularly pulling each other into meetings to have healthy debates.
(An old mentor taught me that timelines are the lowest-common-denominator of communication. When people stop getting useful information and get frustrated, they resort to pushing on timelines, since that's the one common language everyone in the org can speak without needing any other strategic context.)
I think another major contributor is that so many people have never worked at a healthy, well-functioning technology organization. Then, as people bounce around, they bring their habits (and coping skills) with them. Endless hordes of certified scrum-masters team up with non-technical stakeholders to turn engineering teams into coding teams -- and the cycle continues on.
Also, I think if we normalized what we both mean by "is completely bought in" we'd be closer to agreeing ;) Perhaps what I meant by this is an understanding that team x is following methodology y and can expect i, j, k because of it.
I am not saying you are doing <X> wrong, but I am always amazed how many mangers want to do Agile, and at the same time don't understand that means not doing waterfall. They are completely different methodologies.
> For those who use Google calendar as I do, a recently introduced feature allows you to set up focus blocks with the option to decline conflicting events.
I'd recommend against announcing that the meeting is being declined because of a focus block. Someone will read that as "free time" and demand you meet anyway. Put 3-4 fake "meetings" on your calendar during the time you need, so it just looks like you're booked. If your company requires you keep your calendar public, call the meetings something gross like "vendor review" or "Finance and Engineering Integration: Overlapping Initiatives" and nobody will question it.
I think giving fake reasons, which is just systematizing and publishing dishonesty in the form of your calendar, is a bad strategy long term and could potentially have a serious impact on your reputation.
A generic, nondescript "Do Not Book" should be sufficient. If you feel the need to make up fake meeting titles then there is some broader issue that should be addressed.
I'm being hyperbolic and trying to add levity. My broader point is that I've experienced -- first-hand -- that some people don't respect "Focus Time" as a legit reason to miss _their_ meeting and inconvenience them to find a different time. They might not schedule over it, but they'll slack and ask you if you can join anyway, creating more speed bumps and awkward conversations. People generally don't slack you to ask "Can you miss your Vendor Review to come to our Marketing Brainstorm?" You don't have to go full-on deceptive and make up fake meeting names -- that was a bit of humor -- someone else on this thread suggested "Unavailable," which is probably equally effective.
I agree. However, if you're going to do Do Not Book, I'd say auto-decline in better. As I say in the blog, I usually see the decline and reach out to book a better time.
Yeah, if I want to join it's easy to say "sorry can't make it there, but I'd like to join, can we reschedule?"
Sure that's annoying to the organizer, but everyone understands that finding a time where everyone is available is annoying and hard. If it's really hard to reschedule, you'll find some solution. "Sorry I can't, how about xyz attends and you get together after?"
The person is just communicating they have that time booked. If it takes a different form for people to respect that, so be it. The content is the same and truthful: that time is blocked.
I've yet to encounter this. I do get "Is it ok if I schedule over your focus time?" on occasion.
Being honest about it and up front with people creates an understanding. Some even ask how it's setup because they also want focus time.
Correcting misunderstandings isn't a huge burden, and if someone is DEMANDING you meet: There's a good chance it's actually important. Declining because "this can wait a day" helps set expectations that "I need to focus on my assigned work first".
Even better: let your manager know you're doing this, if they have your back. They can respond to complaints/inappropriateness of people complaining about you doing the work they want you to work on.
Where I work only the availability is public, the actual meetings aren't. It's pretty common to block out time for "Focus" and similar (I saw it a lot when folks have their calendar open, in the old office days or when sharing the screen) and, as far as I can tell, very well accepted.
Possible that people would schedule meetings over "Focus" time, but since they can't see calendar details, they don't. If they did, I'd push back. (It's easy to see: "This thing is due on Monday, and that's the time I have to work on it. If you don't like that, take it up to my manager." But I don't remember it being an issue.)
I'm not sure if my boss can see my meetings, I never really wondered too much, but if he can he seems to be respecting intervals I block out with a "Focus" meeting very well, so no issue.
I edited just before you replied, here's the relevant paragraph again:
> Possible that people would schedule meetings over "Focus" time, but since they can't see calendar details, they don't. If they did, I'd push back. (It's easy to see: "This thing is due on Monday, and that's the time I have to work on it. If you don't like that, take it up to my manager." but more diplomatically. But I don't remember it being an issue.)
However, you're saying people straight scheduling over other people's meetings generally? The only times where that happens to me are either:
1) I'm really non-essential, and more invited as a courtesy in case I want to join, or
2) this is really, really important, and we will work together to sort the scheduling out, including manager if necessary.
Otherwise, what else can they expect than me saying "sorry, have another meeting already"?
3) People add so many people to the meetings that it's never ever possible to find the same free block and so a certain percentage of people get scheduled over.
I can highly recommended not adding a reason at all for rejecting a meeting request. If I feel I do not need to attend at all I will let the organizer know. If the time conflicts with my schedule / plans I will simply ask for a reschedule. (And no, I’m not the CEO).
Yeah, I don't see why we need to play games - just say no. It's a normal human instinct to want to please others and say yes, but it can be short sighted as you will need to tell them that, no, you didn't finish that strategic project because you went to a lot of meetings..
I also don't accept many meetings. I leave them as tentative, with the belief that my meeting time is based on priority, not first-come-first-served. This gives me flexibility to attend the meetings that I really do view as most important.
That definitely is an alternative and is something I used to do. The reason I like the focus time feature (if implemented the way I suggest) is that the goal is to instill this culture across the team so that it's more of a team/company culture and less of something that just you do.
I'd love to hear people's experience trying this out!
I do this regularly, and to the extent that I'm able I put the task in the description so that my team knows more or less what I'm prioritizing. You can also create recurring OOO and Focus Time events now, so I have lunch blocked off and 30min at the end of each day to prepare for the next. It's a secret super power to staying on top of things and creating rituals that help me sign off at a reasonable hour instead of sliding into unproductively and less time with family.
Really, my only gripe with Google Calendar at this point is that you can't define custom colors nor label those colors. I use that feature heavily now to give me an at a glance view of which projects or activities my time is going to on a weekly basis. The colors don't have consistency across months though because I have to re-use colors for different purposes.
Reading these threads, I'm either blessed working at a non-dysfunctional place, or people are exaggerating, or people are reading things into meeting invitations that aren't there? (For example, being invited to a meeting that you don't have to be there, but as a courtesy if you want to be there, so it did not take your scheduling into account.)
I’ve worked in places like this. You have to be careful what you push back on and how you do it. It requires a certain amount of political awareness and social skills.
Now that I have over ten years of experience and forced myself to learn how to handle conflict instead of avoiding it, this isn’t difficult for me.
In Outlook you can "invite" a bunch of people but save the meeting as a draft. It will block out the time on your calendar but not send the meeting invite out. For meeting location, just put "TBD."
Nice :) Thank-you. Do you have any Outlook automation workflows? Not Power Automate, but scripts to parse Outlook's equivalent of "mbox" and execute secret magic against.
This is an oddly weird thing to be dishonest about.
If anyone has an issue with me blocking some focus time to get things done, I'm happy for them to take it up with my boss, challenge my priorities and see what happens then.
> If your company requires you keep your calendar public
Find a different company. I have no idea how anyone could work in such circumstances. You're held responsible for getting your work done but others can schedule your time.
The senior architects and principle engineers at my company have started scheduling focus hours as well as office hours for people to drop in and ask questions.
They were getting stretched pretty thin by being invited to design meetings for multiple different teams, and the office hours have been a great way to combat that burden. People drop in, ask some design questions and leave. Since there are usually multiple people waiting to ask questions it keeps the discussion short and focused instead of filling up a 30-60 minute meeting just because that's what was scheduled. It also lets the architect decide to schedule a focused design session if it's needed instead of letting others fill their calendars.
“Deep Work” by Cal Newport (and the related “Time Block Planner” he published as well) goes into depth about why deep work focus time is so important for knowledge workers, and has some additional tips for how to make the most of your workday. Would highly recommend both books!
Everyone at my new job uses Clockwise, which will rearrange calendars across the org to maximize focus time for everyone (also address double-booking). This is my first time in 10 years since becoming an EM where I don't have to spend time managing my calendar every day to get focus time. The jump to my productivity is huge. Can't recommend focus time (and Clockwise!) enough. If I could buy stock in them, I would.
I hate it rearranges a meeting that I know it'd happen in a few hours, I plan my day accordingly, boom it's changed. That's frustrating. I worked at a big corp and people loved fully packed calendars with meetings. Wondered when they'd get any actual work done alone, without a meeting. My calendar was mostly empty except meetings that were crucial. Even though I was in a Principal role, new grads had more packed calendars than me. As a result, Clockwise moved most of my meetings.
This "when do you get actual work done" bugs me sometimes. It's true to some extent, but sometimes a bunch of engineers in a room together get a lot of work done. Sometimes even a lot more than if they each did their own thing, come together, and discover that it doesn't fit together.
Not all meetings are like that, yeah, and there's a limit, but meetings not being "actual work" is not generally true.
Also, since pandemic times, I've had it a few times that people were circling via chat or email on a topic forever, and a quick 15 minute online meeting (independently of whether the camera was on) resolved it immediately.
I'm not saying you cannot do any work in meetings. But if the only empty space in your calendar is lunch time and 2 or 4 hours for a whole week, as a Software Engineer, there won't be much time to do get, I repeat, actual work, which is mostly programming & debugging done, at least for most junior level positions. When an enterprise gets large enough, even just regularly checking in with projects, program managers, executives, designers, product managers was %50 of my busy time for a week. And it was exhausting. Not everywhere would be like that, but that caused a serious burnout with me and I've quit.
Ok I understand what you mean now. If there are so many meetings, then all the "meaningful" meetings become meaningless, if there's no time to actually execute what was discussed.
> Wondered when they'd get any actual work done alone, without a meeting.
Some people are not able to get work done alone and therefore drag others into meetings for the minutiae. Even worse, some people are not able to tolerate being alone, so they take every opportunity to organize meetings.
I used to work at a place that had so many meetings. They reserved a couple afternoons a week for "focus time." Unfortunately, that didn't work. People just started scheduling meeting during those times. Eventually, I got so disgusted with the constant interruptions that I found another job.
I quit my job instead. If the schedule is randomly or unpredictably fragmented by meetings, being expected to also write high quality code is quite simply inhumane. It’s not you that should find tricks to save you from a burnout. It very much looks and sounds and it surely is a mess of a management.
The only reason we can't book 4 hours of time a day is because our employers run "lean" and completely neglect to scale out personnel along with projects.
I know people who would absolutely be replaced by 3 people if they quit.
My advice? Advocate for yourself, because your boss and their boss doesn't actually have any clue how much work it is in the trenches.
Management is almost never aware of all that much about what you're doing, and a lot of capacity issues like this eventually bubble up and catch them by complete surprise simply because individual contributors have just been silently dealing with the frog-boiling.
This all means you should:
1. Come up with specific and measurable justification in terms of hours/dollars for why you need more employees as the company and therefore your workload grows
2. "Offer" to push back excess work and give your management choices while doing so: "Project A will take us X hours over capacity for next quarter, should I prioritize Project A or Project B? We can only deliver # projects in the next quarter at our current staffing level."
Blocking off time on your calendar doesn't really solve the problem because it's something that a lot of people, especially customer-facing ones, simply can't do without doing everything I described above.
Some people constantly want more meetings because it's de facto money with zero effort. As someone who wants to do stuff one can feel a clear lack of meaning in all of it. It's like you are stuck in a web of trivialities.
it's not overwork but work (and even just presence) without a sense of purpose and some progress toward a goal which leads to depression.
If you’re a builder - someone who lives to work, not just works to live - then you should start a company or work for yourself. Otherwise you’re wasting your potential by transferring it to someone else.
Find your people or you will go insane. That’s my unsolicited advice for you.
Don't think that's true. Building and running a startup or even a freelance business is 99% things that aren't developing software: marketing, talking to customers, paying your taxes, hiring, getting financing, etc.
That's an interesting take! I think I agree with it. Of course every builder might not have the risk appetite for that but they could join an early stage startup as an alternative.
This is very common and sometimes deeply ingrained in the company culture. At my previous company, we had a situation where no one wanted to be promoted to a team lead role due to the expectation that the person was completely moved off of any meaningful work to exclusively to participate in meetings (also the reason why the previous lead left).
Yes agreed. I like to gain sticky consensus on work and then apply deliberate focus for me and my team so that we can ride a wave of motivation. By doing this, people are surprised with how fast things can get done.
I seem to remember reading about one or two companies that had a focus time or a no meeting time part of the day or week for the whole company - or at least the departments where it made the most sense (engineering, but not sales perhaps).
I can really see the advantages of having focus time synchronised across your colleagues. If we all did focus times across different parts of the day, you would _never_ be able to schedule a meeting. (Hmmm, that may actually be a good thing...)
Despite many well-intentioned attempts, it feels like the whole process of software development, from people management to software architecture, has barely improved in the past 20 years or so.
It sounds like this guy should probably have a pure management role, where they're reviewing code but not expected to write very much themselves. Having a role with both responsibilities seems bound to lead to frustration.
Daily standup was helpful when covid first hit to be a means to help keep our team together. But since then it’s sort of morphed into a check-in just for the sake of checking in. Very little value. And folks don’t feel the need to address real issues because it wasn’t brought up in that daily standup. I think there should be more intention to keep folks focused and heads down when they need to be and schedule one-off meetings that serve a purpose.
I used to work somewhere with three standups every day. I'd lose and hour and a half every morning for updates that often didn't involve me or could have been async.
Usually it's pretty clear, e.g. you can say to yourself in the morning "If I complete X today, it will have been a good day". Yet somehow at the end of the day you will have spent all your time doing everything but X.
- 60 minute meetings fighting over whether tickets were 3 or 5 story points
- turning our entire process into some kind of perverse waterfall method where stories involved days of prep work defining every step so that we could accurately estimate story points (I thought this was the opposite of agile?)
- offers to "help" from project managers and managers when things took longer than expected - this help took the form of additional meetings.
- absolute inflexibility over my noon standup. I could be in the deepest of zones and people would literally slack repeatedly until you showed up for that thing
Cue the "oh you were doing <X> wrong!!" people. Modern software practice sucks. Its fine for small bugs and very well defined tasks. Outside of that it is just interruptions, interruptions, interruptions.
I also ended up just quitting. New place is better, but still in many ways the same. At least here I don't have comparisons made to my old days of the pre-software-process productivity.