As the year comes to a close, I’ve had some time to reflect and debrief on my work over the course of the year. I couldn’t help but notice the 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 a ‘Trust’ pandemic

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 gives 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 roles and have not overlapping availability hours with regards to when the work should be done. However, even this could prove problematic. For me 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 to 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 team member who shares their screen and reveals the ‘other’ codebase they’ve been working on during work hours. However, if not dealt quickly, by the time the bad behavior is uncovered, time has been lost, and there may have been substantial impact on project delivery.

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. Also, it may push employees to give the bear minimum required since nobody likes been monitored 24/7. However, I think some basic presence monitoring is appropriate, perhaps as basic as having a clear minimum availability requirement during work hours and this can be done using ‘presence’ indicators (which are available in all the major online collaboration tools) or even tracking timeliness of responses. However, care must be taken since this not an effective measure of output/outcome by itself and may quickly become a victim of Goodhart’s Law.

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 a cheating engineer’s antics than another engineer who has just as much context because they work on the same code-base? But hey, that’s a conversation for Part II.