The flip side of focus (to me) is responsiveness. A post to SO might deliver me the exact answer I need, but it will take focus to write the correct question and patience to wait for a response and then time spent iterating in the comments. In contrast an LLM will happily tell me the wrong thing, instantaneously. It’s responsive.

Good engineers must also be responsive to their teammates, managers, customers, and the business. Great engineers also find a way to weave in periods of focus.

I’m curious how others navigate these?

It seems there was a large culture shift when Covid hit and non-async non-remote people all moved online and expected online to work like in person. I feel pushed to be more responsive at the cost of focus. On the flip side, I’ve given time and space to engineers so they could focus only to come back and find they had abused that time and trust. Or some well meaning engineers got lost in the weeds and lost the narrative of *why* they were focusing. It is super easy to measure responsiveness: how long did it take to respond. It’s much harder to measure quality and growth. Especially when being vulnerable about what you don’t know or the failure to make progress is a truly senior level skill.

How do we find balance?

Notification blindness.

I've been struggling with finding balance for years as a front-line manager who codes. I need to be responsive-ish to incoming queries but also have my own tasks. If I am too responsive, it's easy for my work to become my evening time and my working hours for everybody else.

The "weaving" in of periods of focus is maintained by ignoring notifications and checking them in batches. Nobody gets to interrupt me when I'm in focus mode (much chagrin for my wife) and I can actually get stuff done. This happened a lot by accident, I get enough notifications for long enough that I don't really hear or notice them just like I don't hear or notice the trains that pass near my house.

I built a distributed software engineering firm pre-covid, so all of our clients were onsite even though we were full-remote. My engineers plugged into the engineering teams of our clients, so it's not like we were building on the side and just handing over deliverables, we had to fully integrate into the client teams.

So we had to solve this problem pre-covid, and the solution remained the same during the pandemic when every org went full remote (at least temporarily).

There is no "one size fits all approach" because each engineer is different. We had dozens of engineers on our team, and you learn that people are very diverse in how they think/operate.

But we came up with a framework that was really successful.

1) Good faith is required: you mention personnel abusing time/trust, that's a different issue entirely, no framework will be successful if people refuse to comply. This system only works if teammates trust the person. Terminate someone who can't be trusted.

2) "Know thyself": Many engineers wouldn't necessarily even know how THEY operated best (if they needed large chunks of focus time, or were fine multi-tasking, etc). We'd have them make a best guess when onboarding and then iterate and update as they figured out how they worked best.

3) Proactively Propagate Communication Standard: Most engineers would want large chunks of uninterrupted focus time, so we would tell them to EXPLICITLY tell their teammates or any other stakeholders WHEN they would be focusing and unresponsive (standardize it via schedule), and WHY (ie sell the idea). Bad feelings or optics are ALWAYS simply a matter of miscommunication so long as good faith exists. We'd also have them explain "escalation patterns", ie "if something is truly urgent, DM me on slack a few times and finally, call my phone."

4) Set comms status: Really this is just slack/teams. but basically as a soft reminder to stakeholders, set your slack status to "heads down building" or something so people remember that you aren't available due to focus time. It's really easy to sync slack status to calendar blocks to automate this.

We also found that breaking the day into async task time and sync task time really helped optimize. Async tasks are tasks that can get completed in small chunks of time like code review, checking email, slack, etc. These might be large time sinks in aggregate, but generally you can break into small time blocks and still be successful. We would have people set up their day so all the async tasks would be done when they are already paying a context switching cost. IE, scheduled agile cadence meetings etc. If you're doing a standup meeting, you're already gonna be knocked out of flow so might as well use this time to also do PR review, async comms, etc. Naturally we had people stack their meetings when possible instead of pepper throughout the day (more on how this was accomplished below).

Anyways, sometimes when an engineer of ours joined a new team, there might be a political challenge in not fitting into the existing "mold" of how that team communicated (if that team's comm standard didn't jive with our engineer's). This quickly resolved every single time when our engineer was proven out to be much more productive/effective than the existing engineers (who were kneecapped by the terrible distracting existing standard of meetings, constant slack interruptions, etc). We would even go as far as to tell stakeholders our engineers would not be attending less important meetings (not immediately, once we had already proven ourselves a bit). The optics around this weren't great at first, but again, our engineers would start 1.5-2X'ing productivity of the in-house engineers, and political issues melt away very quickly.

TL;DR - Operate in good faith, decide your own best communication standard, propagate the standard out to your stakeholders explicitly, deliver and people will respect you and also your comms standard.

This is why I honestly like discord over forums