Do not disturb

People dislike being overwhelmed and distracted; however, this is quite common in software workplaces nowadays. We use apps, attend meetings, code, and often work on multiple projects at the same time. It's worth to mention that, each organisation has its own 'perspective.' In enterprises or more mature organisations, processes and coverage are well-balanced, making it easier to maintain a single context mode for engineers. While it might be more challenging to achieve this in a startup, it's still possible to find a healthy level. But first, let's stayed the obvious. Context switching is bad, as humans need some time to adopt and regain full focus capacity after switch but there is more, on the dark side like fatigue, higher chance of burnout, quality issues - yada, yada, yada - google it - there is a ton of data on it.

To give you some example, imagine that you started writing code, you have just entered high focus zone and Slack is ringing as someone calls you with some "quick" topic. Call took 30 min, you were asked for some totally unrelated topic, and then you came back to work. It took you 30 min to get in high focus mode and then, your gmail calendar pinged that in 15 min you have meeting. After 1 hour meeting you found out that there was only one question you had to answer too –You just spent ~3:45h and you did not write line of code.

I like the analogy to rally driver and rally pilot - it would be completely irracional to switch roles during the stage. You have to stop the car, switch seats, fasten seatbelts and adjust your new focus. Obviously it impacts the end result so the special stage time. The same is in software development but it's harder to summarise to a single unit - tt's just way more complex.

So without going into details of assessing productivity or engineering satisfaction - I have it on my list too - let's just keep the single rule - each block of context should have start and finish and almost zero distraction points. How to achieve it, you may ask. Here are my rules I stick to my team routine:

Firefightings

If you have some repetitive issues that distract engineers like incidents, bugs, some "adhoc" configuration related tasks. First address those problems. For first group secure time to get rid of them and stabilise environment - negotiate their priority with business giving with estimated calculation cost. For fast track business issues agreed on process and amount of time each sprint team secure on them. It's easy to be flooded with requests like - "Please, paste this new tracking pixel on the website". You as Engineering Manager must say no and build understanding how it impacts team performance.

No more than x projects in time

Team should focus and work on number of projects that will satisfy their work throughput but not more. It's like stating the obvious, but I found very common teams do more projects in parallel than they should. Team to be effective must be in focus, if engineers do 2 projects in parallel they have twice as much focus shift which we already know it's something Engineering Manager should avoid. As a rule of thumb, it's generally ok overlap some deliveries but having too much on a plate extend operational cost.

Extra important is to keep projects priority list and assess the state with the team to build alignment to always know what meeting is more important, what can be delayed and what's not.

Meetings and general work culture

Keep your meetings well organised, it's trivial but very helpful. Lead meeting with agenda, have only required guest and keep those meeting small - I like two pizzas analogy from Bezos and Amazon meeting culture. Also I encourage Engineering Manager to roughly calculate meeting cost. It will make meetings smaller, and some people will decide to focus on their work rather than spending hour on a meeting. To avoid FOMO always summarie meetings in a well structured way. Build work habit and promote deep focus time like no meetings days and do not promote instant replay culture. Distinct two meeting types - decision making and informational. For informational prefer writing communication over meeting.

Toolset

I think it's often something not taken into consideration but nowadays there is enormous amount of tools we use daily. Please minimise then to minimum. Have a single tool within organisation for the single purpose. They all have notifications and you need to track over them so please keep single tool for a single purpose and build policy around it, do not overlap notion with google docs or airtable with google spreadsheet or Miro with Whimsical. I strongly anticipate using just g-suite in organisation especially when it's small. Fancy tools costs a lot - it's something you may want to avoid nowadays.

End note

Efficiency is a king but your team members wellbeing is a queen. You must take care of your people and one of the biggest risk of losing engineer is because of chaos in the process and lack of clear objective. Adjusting workload to team throughput is crucial to minimize context switching.