The Trust pandemic

As we draw the curtains on year 2024, I’ve had some time to reflect and debrief on my work over the course of the year. I couldn’t help but notice that something fundamental had shifted in the world of work in general and specifically as it pertains to software engineering.

It seems it all began with the COVID pandemic at the turn of the decade. All too quickly, the world adjusted to a seismic shift in the fundamental belief that ‘work’ should be done in offices, realizing it was possible to have teams work effectively on a remote basis. However, even though it’s been almost five years since then, I think that was the beginning of what I would term the ‘Trust’ pandemic.

The Remote Work Call-out

I spend a quite a bit of time on X (formerly Twitter), which is my go-to platform to keep up-to-date on the latest news and happenings. I stumbled upon this tweet

As someone who has been an advocate for remote work, I find this evolving ‘culture’ very disturbing. I think I may have even responded to the tweet (which is not something I do often). The fact is that this appears to be a clear and degenerative abuse of the opportunity and agency that remote work offers engineering teams.

At the heart of the matter, this attacks a fundamental principle that forms the basis of effective software/product engineering teams. I strongly believe that engineering teams, and by extension engineers, flourish when they are given agency and flexibility regarding how they go about their work while maintaining a consistent focus on the outcomes or outputs of said teams. What better way to foster this than by giving engineers the liberty to determine where and perhaps even when the work is done? For instance, some engineers do their best work after midnight (when there are fewer distractions).

In effect, the act of working two jobs under the cover of remote work feels like a betrayal, especially to all the people who directly or indirectly contributed to opening up the African continent to opportunities around remote work. This is a cancer that needs to be addressed and excised quickly before it takes a strong footing. The only acceptable exception would be if the roles are part-time and have no overlapping availability hours with regards to when the work should be done. However, even this could prove problematic. Personally, my best ideas come when I’m away from a computer screen. So, having some down-time is an important part of a productive day. Otherwise, I might be as effective as a monkey pushing keys on a typewriter.

Fortunately, experience shows that whenever an individual tries to play this game, there is always a tell: the promising junior or intermediate engineer whose output experiences a sudden and drastic dip with no clear explanation, the team member who is almost always unavailable at critical times, the team member who unmutes during a standup and happens to be on another call simultaneously, or my favorite; the one who shares their screen and reveals the ‘other’ codebase they’ve been hacking during work hours. However, if not dealt decisively, given time the actions of a few may have a substantial impact on the team’s ability to deliver.

Counter Measures

A simple way solution to possibly address this is to install remote monitoring software on engineers’ machines and some companies have resorted to this. A quick google search for remote monitoring software turns up tons of solutions, most didn’t exist before 2020. However, this feels like another extreme in the opposite direction, nothing says “I don’t trust you” better than monitoring my screen and camera during working hours. Imagine having a manager sit over your shoulder all through the work day. It may actually push employees to give the bare minimum required since nobody likes being monitored 24/7. However, I do think some basic presence monitoring is appropriate, perhaps as simple as having clear minimum availability requirements during work hours and monitoring this can using ‘presence’ indicators (which are available in all the major online collaboration tools i.e. slack, teams, etc) or even tracking timeliness of responses. However, care must be taken since this by itself is not an effective measure of team output and may quickly become a victim of Goodhart’s Law.

Goodhart’s Law

   “When a measure becomes a target, it ceases to be a good measure”. 

In the end, I think the best way is to build and empower effective engineering teams. This is because the best software engineering teams are self-regulating. Who better to call out an under-performing engineer’s antics than his team-mate who has just as much context because they work on the same code-base? But hey, that a conversation for another day.

A word of Advice

To the software engineering caught up between two opportunities. I know the economy has been bad lately and cost of living has gone through the roof. You have to understand that your reputation is worth more than a second paycheck. If you’re sure of your value ask for a pay-raise, negotiate new terms and if that fails, make a clean break, but please let’s keep it clean.