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.

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

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.

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.