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.

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.

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 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?

Good reminder: "Project management tool is not the answer, clear priority is the one".

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.

https://www.data-imagery.com/one-person-one-problem/

Write a book

Edit: sorry for the low-effort comment. Write a book, please. I’ll buy it. I might even read it!