3 ms·

If you work on a team, being reachable is part of your work. There are (few) opportunities for solo thinking, and Cal is lucky to find one. I hope you find one

If you work on a team, being reachable is part of your work. There are (few) opportunities for solo thinking, and Cal is lucky to find one. I hope you find one for yourself. But as a team, the answer "I can't reach the expert because they secluded themselves" is not acceptable. Because as a senior figure on a team, you job is to become a force multiplier for others, not a solo force. Not to do work that magnanimously benefits others, but work that makes others better. You need occasional deep work time, sure. But the whole "I must disconnect from everything, always" thing does not work for any social endeavor - and most meaningful things are of a scope that requires a team. I wish I had a better answer here, because I too like thinking quietly for long times - but I also see that I fulfill a useful function when I'm reachable, and ultimately, you get paid for usefulness to the larger endeavor. (This points strongly towards solo/entrepreneur tracks if isolation is your only useful mode of work, but even then, you'd be well advised to find a partner who handles the people parts)

Joeri 6y ago
As a technical team lead I’ve struggled more than once with the trade off between getting meaningful deep work done for myself and getting others on with their work. Over the years I’ve come to realize it is not as clear cut of a trade off. Teams can be coached to be self-reliant and to distribute knowledge effectively, so that they have fewer urgent questions. I try to proactively take myself out of the critical path as much as possible. Documenting thoroughly is one way. Another is to use channels for question-asking and encouraging the use of the channel instead of dm. There’s a higher chance a person can answer who is not interrupted, and because everyone passively follows the channel the knowledge is shared more effectively. Decision-making is always the tricky part. Junior devs need constant handholding and it is more about a lack of lived experience than a lack of knowledge. You need enough senior devs so that the load of constant micro-decisions for the juniors can be spread around. The thing is that getting to the point where there is enough time for deep work is a process that takes time and that is easily undone by team churn. IMHO the only way to sidestep the matter entirely is to have a lieutenant who handles all the urgent matters, but I’ve only had that once and in retrospect it was hardly a fair situation.
FalconSensei 6y ago
Exactly. Of course, if you are working as an expert - and not an expert mentor - you will need time for deep work. But it's a balance of times when you can't be interrupted, and times when you should. Ultimately, talking to the team, scheduling 'busy' times on your calendar, or letting people know in the morning that you need a day to focus on something can really make a difference. Also, setting up expectations on how long can it take for you to reach back in matters that are not urgent. And urgencies that are critical for the business always have a preference over deep work, but if the team knows you are busy, they can think if they really need you to solve it or give instructions.
peruvian 6y ago
This is my main issue with Newport's work. It's all great advice but not much of it applies to a regular office worker.
BlargMcLarg 6y ago
Yet we're increasingly figuring out not all things have to be synchronized, and many people can save themselves while thrown in the deep as long as there is documentation. It's not that I disagree with the premise. Rather, I believe as a society, we've largely taught ourselves helplessness and failed to document properly how things are supposed to work (both when requesting features and checking how existing things work, both functionally and in code). Add short tenures onto this, and it makes for a system which needs a lot more synchronized "are you available" time than need be. Additionally, maybe I'm biased, but many juniors don't need as much mentorship as the average senior dev here likes to claim once they're settled in. Again, it might be backfiring in terms of learned helplessness, where they won't try and solve their own problems first. Furthermore, it stimulates not documenting processes in a way that newcomers can learn, where seniors become glorified encyclopedias. Most juniors I come across stumble here: not when the problem can be found online, but when the problem is a piece of domain knowledge / in-house framework documented extremely poorly, and requires an extensive amount of time to communicate. Combating this may cut down required mentoring significantly. Now imagine you might be able to cut down regular mentoring to a 1-2h window. On a regular 8 hour day, that leaves a whole 6-7h to plan at your own convenience. This could have different setups as well (two days with high accessibility, three days of access only in critical cases). Most of all, as long as we don't make the deep dive and continue our existing ideas, we're only setting ourselves up for a selffulfilling prophecy. It's only after we try, we can accurately make such bold claims.
tehjoker 6y ago
I don't know who defines what work is but "being reachable" at all times seems like an arbitrary line in the sand. It's pretty annoying to be dictated what is and isn't possible. For example, what about "being reachable" four days a week, or 7 out of 8 hours a day, or using the toilet? Bright line rules like these are usually fake and promoted by people that benefit from them.

Joeri 6y ago

As a technical team lead I’ve struggled more than once with the trade off between getting meaningful deep work done for myself and getting others on with their work. Over the years I’ve come to realize it is not as clear cut of a trade off. Teams can be coached to be self-reliant and to distribute knowledge effectively, so that they have fewer urgent questions. I try to proactively take myself out of the critical path as much as possible. Documenting thoroughly is one way. Another is to use channels for question-asking and encouraging the use of the channel instead of dm. There’s a higher chance a person can answer who is not interrupted, and because everyone passively follows the channel the knowledge is shared more effectively. Decision-making is always the tricky part. Junior devs need constant handholding and it is more about a lack of lived experience than a lack of knowledge. You need enough senior devs so that the load of constant micro-decisions for the juniors can be spread around. The thing is that getting to the point where there is enough time for deep work is a process that takes time and that is easily undone by team churn. IMHO the only way to sidestep the matter entirely is to have a lieutenant who handles all the urgent matters, but I’ve only had that once and in retrospect it was hardly a fair situation.

FalconSensei 6y ago

Exactly. Of course, if you are working as an expert - and not an expert mentor - you will need time for deep work. But it's a balance of times when you can't be interrupted, and times when you should. Ultimately, talking to the team, scheduling 'busy' times on your calendar, or letting people know in the morning that you need a day to focus on something can really make a difference. Also, setting up expectations on how long can it take for you to reach back in matters that are not urgent. And urgencies that are critical for the business always have a preference over deep work, but if the team knows you are busy, they can think if they really need you to solve it or give instructions.

peruvian 6y ago

This is my main issue with Newport's work. It's all great advice but not much of it applies to a regular office worker.

BlargMcLarg 6y ago

Yet we're increasingly figuring out not all things have to be synchronized, and many people can save themselves while thrown in the deep as long as there is documentation. It's not that I disagree with the premise. Rather, I believe as a society, we've largely taught ourselves helplessness and failed to document properly how things are supposed to work (both when requesting features and checking how existing things work, both functionally and in code). Add short tenures onto this, and it makes for a system which needs a lot more synchronized "are you available" time than need be. Additionally, maybe I'm biased, but many juniors don't need as much mentorship as the average senior dev here likes to claim once they're settled in. Again, it might be backfiring in terms of learned helplessness, where they won't try and solve their own problems first. Furthermore, it stimulates not documenting processes in a way that newcomers can learn, where seniors become glorified encyclopedias. Most juniors I come across stumble here: not when the problem can be found online, but when the problem is a piece of domain knowledge / in-house framework documented extremely poorly, and requires an extensive amount of time to communicate. Combating this may cut down required mentoring significantly. Now imagine you might be able to cut down regular mentoring to a 1-2h window. On a regular 8 hour day, that leaves a whole 6-7h to plan at your own convenience. This could have different setups as well (two days with high accessibility, three days of access only in critical cases). Most of all, as long as we don't make the deep dive and continue our existing ideas, we're only setting ourselves up for a selffulfilling prophecy. It's only after we try, we can accurately make such bold claims.

tehjoker 6y ago

I don't know who defines what work is but "being reachable" at all times seems like an arbitrary line in the sand. It's pretty annoying to be dictated what is and isn't possible. For example, what about "being reachable" four days a week, or 7 out of 8 hours a day, or using the toilet? Bright line rules like these are usually fake and promoted by people that benefit from them.