As a manager I strongly agree with this post. I’m currently responsible for taking a team whose old manager wanted to go back to being an ic. The team has a reputation for being slow, not being the best at architecture. So far I don’t really care about that. The problem is that no one at any level can even agree on what their priorities should be. When every standup you’re told to do something different of course you’re going to be slow. And this isn’t to bash the old manager this is coming from above him.
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.
There is also something about confidence in there. If the manager is not confident, then they will be perpetually unsure about if person x should be doing y or if it is a waste of time.
And they project this by constantly questioning if x “really” is being productive on y or they maybe should do z.
There are many different structures. Sprints, standups and burning through backlogs to many of us sound like a non-productive setup. But it also can work, especially when coming from dysfunction. On the flip side it can also be abused.
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.
Superb piece!
> 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".
Managers only have one phrase in their vocabulary: "Get this one feature out as quickly as possible." Everything else is just making devs 'heard' (so they can get back to feature).
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.
But the manager gets to report a new feature, a boon to their career, at the cost of the devs’ careers and satisfaction. The manager might be glossing over or just muting any product satisfaction issues, particularly if no one in their line of report directly puts a KPI on that. That’s about company culture.
> "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.
> Maybe analyze the target audience before shipping?
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).
Write a book
Edit: sorry for the low-effort comment. Write a book, please. I’ll buy it. I might even read it!
That was exquisitely well put. Nicely done.
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.
I've maintained for a long time that Jira (and similar tools) are where work goes to die.
I think it's overly simplistic to frame the issue as one of manager-vs-managed. Everybody is distracted by whatever messages come their way, whether orders from above or reports from below (not to mention self-imposed distractions like social media).
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.
I don't think that people multitask only because they have multiple unprioritized tasks.
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?
> 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?
Yes, the manager knows what tasks you're assigned and what priority they are.
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.
Constant interrupts is a sign something is wrong.
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.
> 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.
So much this. Our org moved pretty quickly into organising and communicating via Teams when the lockdowns hit and people worked from home. Moving that quickly meant that many 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?".