Focus Time Saved Me from Burnout
frankgrecojr.medium.com
frankgrecojr.medium.com
- 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.
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.
Sorry, but I have to tear into this.
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.
</soapbox>
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.
My take away is this: For the most part - treat them like a game of "whose line is it anyways": https://youtu.be/9KAGwNtI26w?t=17
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.
- 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
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."
https://www.atlassian.com/agile/project-management/project-m...
Also your scrum master should be sheltering you from some of the distractions you are describing.
Yes. However, they're usually spread so thin and "scrum master" may too many teams to fully be invested in a single one.
I hate this one so much. It felt like I got blindsided the first time it happened to me.
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'd love to hear people's experience trying this out!
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.
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.
Younger me didn’t know what to do.
That would be nice.
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.
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.
Your thing seems like lying to me...
> 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"?
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.
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?"
It's really not that hard.
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.
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.
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.
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.
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 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.
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.
Find your people or you will go insane. That’s my unsolicited advice for you.
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...)
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.
https://docs.microsoft.com/en-us/viva/insights/personal/use/...