I wonder if attention span can be increased somehow.
Also related, I noticed context switching from one deep task to another requires significant energy and time, I also wonder if that can be optimized.
I found that AI coding allows me to work on more stuff because it's doing its thing faster, but it also greatly diminishes my attention per project, reducing to less optimal solutions.
Great article. "To be reliably able to focus on something, you need to be intuitively, emotionally invested in the outcome." This rings 100% true for me. I've succumbed to a sort of fatalism though, where I'm not confident at all I can control what I'm emotionally invested in and that they just arise out of the situations I find myself in along with seemingly random thoughts from the brain.
> Once I was full-time managing, I had no shiny distractions and was able to spend my showers focusing on how to be a better manager. And once I was 50%+ focused, well, I haven’t become a “superstar 10x manager” yet, but I quickly stopped being 0.1x.
Counterpoint: a manager who is not spending at least some time on programming or in the codebase/PRs is not able to evaluate fully their teams' strengths and weaknesses and collaboration and is less of a 1x manager than a manager who does code/spend time in the codebase(s).
Let me elaborate further.
# Engineering Excellence
It's a part of our job to foster and encourage engineering excellence. A hands-off "I only manage" type of engineering manager can get the following signals for a team member in terms of excellence:
- from other team members (great)
- from Jira/PRs merged output (good-ish)
But is this merged PR the best work that can be done? Is it maybe not shoddily but quickly done, and LGTM-ed by others? Do you get good feedback about that person from other team members because they are great at being friends, or because they are excellent engineers? Is the codebase slowly becoming unmaintainable from the whole team vibe coding? You can't know for sure, cause you didn't check, and if you are "I only manage" type of engineering manager, after some time you wouldn't be able to tell the difference even if you checked either.
Conclusion: an engineering manager who doesn't frequently check the codebase and or/code themselves can rely on fewer signals to gauge technical ability in their team and is less informed and capable to steer engineering excellence than a hands-on engineering manager.
# Promotion and recognition
It's a part of our job to recognize talent for the work they do and reward them for that. An "I only manage" engineering manager can rely only on two things to find things to reward in a software engineer:
- Other teammates' feedback (okay-ish)
- If that software engineer themselves brought up a significantly difficult achievement and self-advocated for their work (bad, selects for chest thumpers)
An "I only manage" engineering manager not looking at code is blind to the achievements of more shy engineers that don't loudly advertise their work, and can be also blind to a dynamic where teammates don't know what others are doing. On the other hand, a hands-on manager might find achievements that teammates don't, and build a culture of celebrating each others' achievements + actually knowing what the hell others are doing.
Conclusion: "I only manage" engineering manager can be blind to some dysfunction and reward disproportionately people good at selling themselves. A hands-on engineering manager has a better and ampifly teams' recognition of one another and create a culture of shared celebration of achievements.
# Know what people are talking about
If you don't code/solve technical problems and you "only manage", what makes you qualified to hold a discussion, and even worse, judge merit of your team members? Why are we shoving a dynamic where the least qualified judges others and "solves" their problems. Sure, many problems are people problems, like salary, conflict, etc, but these problems are very often related to actual job performance. How can you judge thoroughly if someone is actually doing a good job ("I only manage" uses 80% vibes and 20% second-hand stories) and deserves that salary increase if you haven't seen their code or how they communicate with others in PRs?
I want to stress out that I don't advocate for managers that are the best devs in their team, nor managers who don't care for their teams' wellbeing. I am simply saying that to actually manage well, you gotta be "in the things", know well what your team is doing AND HOW WELL. To judge software engineering capabilities, you yourself need to have s...
Attention is relative, like if you're in the middle of some code review and your kid calls saying they've got a problem, then you may get distracted - but rightfully so.
I should give time-boxing a try. My problem with 50+% focus and monotasking is that I tend to ignore everything else as much as possible when spending even 5 mins would take care of a side task. I take "All or nothing" to heart
Spoken like a true middle manager. Attention is not the resource, but the act of spending the actual resource; time.
Time is your most precious resource. Everyone wants more, but there is no way to get more. Nobody knows when their supply will run out. We do not produce it, having been granted a finite amount of it by our existence.
Attention is to time as shopping is to your paycheck.
My best ideas always come to me when I'm almost asleep and I have no idea why that is, which is really frustrating because I know I'm never going to remember them. Sometimes I'll get up and write it down but the bar's pretty high for that because then I'm awake and I know I'll end up zombie-ing around the house for another 2 hours until I'm tired enough to sleep again.
I realise this is interesting to no-one but me, but it's WEIRD, right!?
I like the idea of a 'bullshit timebox' - an hour period of protected time for minor chores & slightly annoying tasks.
I wonder what the best way of arranging it is. I guess you want to schedule them or have set weekly times, otherwise there's a slight overhead of remembering and finding the best time to timebox. Or maybe you use the last timebox to schedule the next one..
39 comments
[ 3.4 ms ] story [ 46.4 ms ] threadMaybe that works in huge companies, but most managers I have worked with are unlikely to agree with zero concurrency in software engineers :)
Nobody is complaining though, stuff gets done.
So whenever you spend attention you spend life time.
This helps me now and then to put away my phone and just live.
It forcefully tries to hack you and steal your scarcest resource.
(Only re-opened to comment this)
Counterpoint: a manager who is not spending at least some time on programming or in the codebase/PRs is not able to evaluate fully their teams' strengths and weaknesses and collaboration and is less of a 1x manager than a manager who does code/spend time in the codebase(s).
Let me elaborate further.
# Engineering Excellence
It's a part of our job to foster and encourage engineering excellence. A hands-off "I only manage" type of engineering manager can get the following signals for a team member in terms of excellence:
- from other team members (great)
- from Jira/PRs merged output (good-ish)
But is this merged PR the best work that can be done? Is it maybe not shoddily but quickly done, and LGTM-ed by others? Do you get good feedback about that person from other team members because they are great at being friends, or because they are excellent engineers? Is the codebase slowly becoming unmaintainable from the whole team vibe coding? You can't know for sure, cause you didn't check, and if you are "I only manage" type of engineering manager, after some time you wouldn't be able to tell the difference even if you checked either.
Conclusion: an engineering manager who doesn't frequently check the codebase and or/code themselves can rely on fewer signals to gauge technical ability in their team and is less informed and capable to steer engineering excellence than a hands-on engineering manager.
# Promotion and recognition
It's a part of our job to recognize talent for the work they do and reward them for that. An "I only manage" engineering manager can rely only on two things to find things to reward in a software engineer:
- Other teammates' feedback (okay-ish)
- If that software engineer themselves brought up a significantly difficult achievement and self-advocated for their work (bad, selects for chest thumpers)
An "I only manage" engineering manager not looking at code is blind to the achievements of more shy engineers that don't loudly advertise their work, and can be also blind to a dynamic where teammates don't know what others are doing. On the other hand, a hands-on manager might find achievements that teammates don't, and build a culture of celebrating each others' achievements + actually knowing what the hell others are doing.
Conclusion: "I only manage" engineering manager can be blind to some dysfunction and reward disproportionately people good at selling themselves. A hands-on engineering manager has a better and ampifly teams' recognition of one another and create a culture of shared celebration of achievements.
# Know what people are talking about
If you don't code/solve technical problems and you "only manage", what makes you qualified to hold a discussion, and even worse, judge merit of your team members? Why are we shoving a dynamic where the least qualified judges others and "solves" their problems. Sure, many problems are people problems, like salary, conflict, etc, but these problems are very often related to actual job performance. How can you judge thoroughly if someone is actually doing a good job ("I only manage" uses 80% vibes and 20% second-hand stories) and deserves that salary increase if you haven't seen their code or how they communicate with others in PRs?
I want to stress out that I don't advocate for managers that are the best devs in their team, nor managers who don't care for their teams' wellbeing. I am simply saying that to actually manage well, you gotta be "in the things", know well what your team is doing AND HOW WELL. To judge software engineering capabilities, you yourself need to have s...
Focus on your goal + discipline & practice + semen retention = you will be a "übermensch".
Not like this jerk, who's kid had to put time in his calendar for playing chess with him, because he was too interested in his own career https://www.pathtostaff.com/p/work-life-balance-slows-career...
Time is your most precious resource. Everyone wants more, but there is no way to get more. Nobody knows when their supply will run out. We do not produce it, having been granted a finite amount of it by our existence.
Attention is to time as shopping is to your paycheck.
My best ideas always come to me when I'm almost asleep and I have no idea why that is, which is really frustrating because I know I'm never going to remember them. Sometimes I'll get up and write it down but the bar's pretty high for that because then I'm awake and I know I'll end up zombie-ing around the house for another 2 hours until I'm tired enough to sleep again.
I realise this is interesting to no-one but me, but it's WEIRD, right!?
I wonder what the best way of arranging it is. I guess you want to schedule them or have set weekly times, otherwise there's a slight overhead of remembering and finding the best time to timebox. Or maybe you use the last timebox to schedule the next one..