Thrashing(exple.tive.org) |
A manager’s job is first and foremost to manage tasks. I’ve instituted real sprints and they’ve started burning through the backlog. It’s not that agile is amazing it’s that structure is. There’s now a single on call person who is the target of sudden important bugs. Work doesn’t just fly in unannounced and blow up the whole team anymore. The team knows if I ask a question they can respond the next day.
It’s crazy to me how little many leaders I’ve encountered appreciate focus. I do think part of the problem is thrashing looks productive to some leaders. But it almost never is. There’s that quote: “slow is smooth, smooth is fast”. It almost always holds true.
One framework is autonomy, mastery, and purpose. If this is what drives people and helps them be productive then the manager's job is to give his team autonomy, facilitate them becoming masters, and explain the purpose of their work.
To the author's point re: tools. Autonomy should mean you don't force tools and processes on the team. In the real world however there are constraints and tools are used across teams and larger organizations for purposes that may not always perfectly align with the team's productivity goals. Like anything, judgement and balance are important.
And they project this by constantly questioning if x “really” is being productive on y or they maybe should do z.
> People multitask because they’ve been assigned multiple unprioritized tasks. People are distracted and unfocused because day to day their managers and leaders value responding to distractions and interruptions over consistency and focus
This in particular rings so true, makes me think of a meeting not so long ago where, within a 15m bracket, one of the tied-up VPs was telling us "leaders" we needed to pay more attention to side-projects because devs were working on things that weren't mandated by the hierarchy. That was introducing too much distraction, and slowing down delivery. We need to foster innovation and make sure devs ideas are listened to. And also we need to make sure we don't leave any stone unturned and leave time in the schedule so that explorations requested by PMs are addressed faster.
It's terrifying. Sometimes I tell myself "they're just untrained, they don't know", but when you get higher ups requesting more focus, then immediately asking for breadth as well, it tells me they know, but they also don't care. They just don't want to give any priority, they shove every contradictory requirement down the line, set expectations that everything should be promptly worked on, and proceed to blame devs for their shortcomings.
Then set their LinkedIn tagline to "humane leader with high expectations for excellence".
There have been a few variations over the years: "Just focus on the happy path" and "Build the feature now, and we'll work on stabilisation later". This week I heard twice: "The sooner we get the feature out to the customers, the sooner we can gather feedback and change our product".
Anyway you all know the punch line: there's no 'later', there's no 'stabilisation', only the next feature. And the feedback that we get from the customer is support tickets because the product doeesn't work.
Behind every 500 you encounter in the wild, every piece of lost data or missing transactions, there's a manager really good at keeping his devs focused.
> "The sooner we get the feature out to the customers, the sooner we can gather feedback and change our product"
Maybe analyze the target audience before shipping? Also an org issue, where a the PO should put their business analyst hat on. I mean, to me it’s a question of competence if the team is supposed to ship something that must be changed (not fine-tuned or improved) - it’s about how much.
The problem is that there’s a risk the analysis finds out that “the product adequately fits our target market’s needs, there’s no easy way to adapt to another market, so most pragmatic approach is to stay put, cut costs and reallocate resources to marketing or other projects”.
No product/project manager and very few devs want to hear they’re not needed, so it’s better for everyone is busywork is continuously being made up, regardless of whether it’s actually beneficial for the business.
I’ve been at dysfunctional places where the winning strategy would’ve been to just give the whole team a 3-month paid holiday while higher level management figures out an actual direction for the product, rather than desperately thrashing around and causing damage/tech debt that would continuously slow down further development (I originally wrote “that would need to be fixed later”, but who am I kidding, that will never happen).
I don't envy project managers who are responsible for tracking all our engineering shenanigans and trying to communicate trends to upper management. They have a hard, thankless job that probably needs to be done. But the tooling they so often inflict upon teams (I'm looking at you, Jira), is soul-deadening. Bug trackers are great. As soon as they involve a workflow with statuses more complex than backlog/to-do/doing/review/done, too much of the devs' job seems to involve keeping the task manager happy instead of building software.
I don't know where the happy medium is. I won't claim I know a better way. But I do know I've worked in shops that optimized for getting work done, and I've worked for shops that optimized for tracking how much work is getting done, and the former outdelivers the latter every single time.
In the past I’ve attributed this to the people in those organisations. Some people like to get things done. Others just like to be doing things (and they don’t understand the difference).
My interaction with JIRA is read ticket, assign myself, add estimate, create branch, check out, do thing, put pr up, merge pr, next day after builds have run overnight i move the ticket to 'ready for test' and add the build number so QA can look at it.
Overall its less than 5mins per day in general. For big tickets i wont touch it for many days, sometimes even a couple of weeks.
Its better than qa messaging me to ask which build has the new feature they need to test.
True, management often foists tools on their underlings without a good understanding of the disadvantages of those tools. But that's a somewhat different (albeit related) issue from that of time management. Even with the best tools, time management can still be a problem if you're being inundated with tasks faster than you can complete them.
In my experience, where things go most sideways isn't forced use of clunky tools but rather poor prioritization skills amplified by poor articulation skills. In other words, the worst offenders are people who are bad a prioritizing, and bad at verbalizing what they're having trouble with so they can get help. Of course, poor management on top of that will practically guarantee massive failure. But without employees (at any level) who have insight into their situation, and can communicate well, you're dead in the water before you've even started.
You could well have everything prioritized, and be multitasking between your highest priority task and interruptions.
By acknowledging interruptions, you appear responsive, even if you don't start working on them.
You can't ignore all interruptions. How do you know your boss doesn't have something urgent that will preempt your current highest priority task?
Isn't that literally the job of the manager? Don't they know what tasks you're assigned and what priority they are?
If not, what value is the manager bringing again?
So how does that work then, if you can't be interrupted?
Boss has a new task for you which is higher priority than your current highest one.
How do you learn about this?
OK, you are not interrupt-driven, so you must poll. The boss puts the task into some task tracking system, which you check every hour.
1. Isn't the hourly check an interruption? (You actually are interrupt-driven: you have a timer which interrupts you every hour so that you poll the task list.)
Polling still requires multitasking: multitasking between the polling loop and its timer, and your higher priority task.
2. What if something comes up which can't wait up to an hour? Maybe you should poll the task list every five minutes. Then when you see it change, just do not call that a notification.
How about the scenario in which we remove management; they don't bring value. Well, you are doing a job which means doing things other people want done. Instead of your boss feeding your tasks, those customers that were behind your boss are now doing it.
Those people don't have access to the internal task system, so polling is out of the question. They use strictly messaging systems with notifications.
Nope; they only way you can escape being interrupted by notifications is if you have a manager who lets you do leisurly polling.
Edit: sorry for the low-effort comment. Write a book, please. I’ll buy it. I might even read it!
It reminds me of what is said to be Peter Thiel's style of management at Paypal: One person, one problem.
He is said to make one person the clear owner and decision-maker for each significant problem. This person is given the authority and resources to solve it, and is held accountable for the outcome.
People naturally gravitate toward easier, B+ problems they know how to solve, rather than the hard, high-impact A+ problems. Thiel's rule forces focus on the most important, difficult issues, even if it feels uncomfortable or limiting at first. Over time, teams saw that this intense focus led to breakthrough solutions, like PayPal's fraud detection system, which was only possible because one person was given total ownership of the problem.
Look at construction sites. Do you see the manager telling the dude on the crane lifting some beam up that he has to stop mid-way and go do something else? Never. If you plan and execute well this should not be a problem to start with. If it's not a problem then polling or interrupts doesn't matter. Plans can change but they don't change every hour.
The customers behind your boss generally don't have new tasks every hour either. They could require service or have some sort of problem. When your car breaks down do you call the guy who designed it?
If you're building software, and you're constantly (hourly) shuffling priorities or engineers are constantly fixing the software for customers, then that's the problem that needs fixing. It's not a tooling problem.
EDIT: In the days before Slack and being constantly plugged in people were a lot more conscious about interrupting others and we had less interrupts. The reason we have more interrupts today is that it's just too easy to interrupt people. Not because we really need them - we don't. It makes us a lot less productive.
So much this. Our org moved pretty quickly into organising and communicating via Teams when the lockdowns hit and people starting working from home. Moving that quickly meant that many basic things like messaging etiquette never really got thought about. Even now I'll still receive messages when my status is set to DND or receive complete junk openers like "You there?".