3 ms·

This article seems to be advocating sticking your head in the ground when something goes wrong There’s a world of a difference between telling others “that’s

This article seems to be advocating sticking your head in the ground when something goes wrong There’s a world of a difference between telling others “that’s not my job” for tasks that have nothing to do with you, and owning the success of your own projects And it feels like this author is conflating the two concepts If there’s a dependency of yours that’s not working the way you need it to, it doesn’t mean you can simply go home free. At the very least you have to fill in the communication gap of informing management of the blockers. If need be, then you have to own driving the call to either add more resources to your own project (to compensate for the bad dependency) or push forward the call to nix your project since it apparently has a high chance of failure And if none of those attempts pan out, _then_ you can try to move on to a different place where you can actually be effective. But know that you’ll face this same type of challenges in your new role as well! There’s no easy escape: if you took a position of leadership, then it’s definitely your job to lead

deleted 4y ago
[deleted]
David 4y ago
I read the article as saying you can't solve everything yourself. That's different than saying you should ignore problems. Instead you need to communicate when you see a problem that you're not positioned to solve, because you don't have the bandwidth or you're not in a position of authority for that domain > you should be working on properly communicating the gap and its risk to the business (and risk to which part of the business) and NOT attempting to solve everything.
Dave3of5 4y ago
> There’s no easy escape: if you took a position of leadership, then it’s definitely your job to lead Leading != to fixing every problem that has no one assigned to it or filling every gap. It's about helping the other so that overall the org can achieve it's goal. Leaders should be miles away not in the trenches. You can ask Russia what happens when you send your general to the front lines. A similar effect happens in software when more senior devs take on all the work themselves. The original tweet is saying the higher up you go the more you have to do everything. That's wrong an extremely unhealthy.

deleted 4y ago

[deleted]

David 4y ago

I read the article as saying you can't solve everything yourself. That's different than saying you should ignore problems. Instead you need to communicate when you see a problem that you're not positioned to solve, because you don't have the bandwidth or you're not in a position of authority for that domain > you should be working on properly communicating the gap and its risk to the business (and risk to which part of the business) and NOT attempting to solve everything.

Dave3of5 4y ago

> There’s no easy escape: if you took a position of leadership, then it’s definitely your job to lead Leading != to fixing every problem that has no one assigned to it or filling every gap. It's about helping the other so that overall the org can achieve it's goal. Leaders should be miles away not in the trenches. You can ask Russia what happens when you send your general to the front lines. A similar effect happens in software when more senior devs take on all the work themselves. The original tweet is saying the higher up you go the more you have to do everything. That's wrong an extremely unhealthy.