My Summary of 'Management and Control of Technical Labor'

I’ve read a post on Linked in about an employee cheating their employer by working four (!) remote jobs.

As I am a voracious reader, I found that post coinciding with something that I’ve been reading on recently - namely the ‘Management and Control of Technical Labour’ by Gordon Cuaser and Carol Jones.

Here’s my summary of the above-referenced text and my conclusion as to how it pertains to the issue in the linked LinkedIn post.

Summary

Here's the summary of the info that I found important in Management and the Control of Technical Labour (by Gordon Causer and Carol Jones).

• Expert workers, due to their expertise, may be "problematic" to manage due to three things:
  • First, they have expert knowledge which the manager might not have - it's good if the manager came from the same background - but that's not always the case. Even if it is, going into management might "blunt their edge".
  • Second, it's hard to quantify results of experts work ahead of time - this is related to the general issue that I have with making predictions on "when work will be finished" - for the most part, people are lousy estimators (software engineers included) - put differently, there isn't an easy way to predict the outcome of an activity - that's why we have planning poker etc.
  • Third, values and interests of professionals and managers might not be aligned. This is a tough one.
• For expert workers, one strategy of management is "high trust", achieved through:
  • job security
  • career advancement possibility
• Managers with less expertise, if compelled to evaluate their subordinates' complex activities, might inadvertently end up demotivating expert workers by judgement calls perceived as random or mis-informed
• The Manager's Dilemma: trust the expert worker, or control them - how do determine if the worker is "coasting". It's only made more difficult because:
  • the manager's ability to estimate an expert worker's performance is hindered by the above-described dynamic
  • obvious "solutions" might result in the employee feeling demotivated
• One listed viable solution is citing the case of a newly-appointed engineer-manager who spent 50% of his time keeping up with his area of expertise, and 50% of his time managing his expert worker subordinates
• However, as an engineer manager keeps managing more expert workers - with each expert worker having their own area of expertise - the solution from the bullet-point above becomes impracticable - the solution is to introduce "Senior Group Leaders" - in the example given, out of 30ish employees in a department, four were picked for these roles
• Thus, the proposed solution of the authors is to have these combo-roles, a hybrid person who's both a senior expert and a team lead
• The above strategy is all the more important in settings where workers undergo periodic appraisals (the focus here being on technical appraisals)
• Rather than purely a "trust-based" relationship between the "expert team lead" worker and their managers, the performance-based pay might be a way to control the workers - "personalization of rewards" might be a way to go
• The worker-manager or the worker-team-lead approach somewhat blurs the lines between the management and the expert subordinates in an organization
  • As a consequence, on any given project, even some juniors might lead some seniors on a specific project's sub task where that junior has more specific competency
  • An added benefit is that this indirectly resolves the trust vs control conundrum - through giving the more junior employee the "right" to lead his more senior co-workers in specific tasks, managers effectively put those juniors in a situation where they "manage themselves" - i.e put themselves under scrutiny, self-imposed control, and determination for the project to succeed - because each team now has interdependence and reciprocal duty to their peers - either to guide them or to be guided. This "reversal of junior and senior roles" is very important. But it also needs to be organized correctly.
  • With joint work on projects, seniors can determine juniors ability, and possibly even be empowered by it. An added benefit is that this should go both ways.
• The potential to manage as a demotivation-averter
  • The possibility of an engineer to become a technical manager in the future might be one of the ways to dampen the demotivation dynamic described earlier
  • This reinforces the "commonality" of all workers in the hierarchy - because they all have the same background and "get" each other
  • Paraphrased: "No one is a know-it-all, and we run our department by allowing everyone to have a go at someting in meetings - and then we decide together what needs to be done. We work as a team - but in the end it is our lead or manager how determines the way to go."
  • This collegial culture is the one to strive for to maintain, but gender differences might be an obstacle in a "men's club"

My conclusions

It seems obvious to me that the best situation a software engineer should strive to find themselves in is a company with the following characteristics:

A workforce of at least 100 workers, mostly other software engineers.

A fluid (non-rigid) organizational structure in which even as a junior, with specific and unique expertise - you will be tasked to lead your co-workers on such tasks where you’re the expert - it can be as simple as being an expert in A11y in HTML.

The focus of the company, second to being profitable, is “to grow your professional competencies” - through a rigorous system of learning goals and outcomes for each employee - set in quarterly plans. Employees should be given a choice to pick from a smorgasboard of technologies.

A culture of “we leave no-one behind”. The team an engineer is in should work like those Spartans in the movie 300 - but with gender-neutrality.

As a manager, if the above points are met, you are very likely to not have a trust vs control issue in your organization.

So, what can you, as a manager, do when faced with a cheating remote worker?

How do you even “catch them in the act”? The solution, based on the information above, and my own experience and research, is multi-faceted:

Obviously, use a project management software, either Jira or whatever else you prefer.

Assign coders to pair program from time to time. It can even be “surprise” pair programming session. It’s enough for another worker to see how far a co-worker has gone in the development of a feature and what their Jira board looks like.

Strive to include juniors into “part-time” senior positions - as explained a few paragraphs above. Basically, you want to “show the way” to the junior, and get them to senior level expertise as soon as possible. These “islands” of expertise should eventually grow to become “expertise continents”. But you gotta start somewhere small. As a technical manager, find several areas of expertise where a junior coder might catch some quick wins. For example, if no-one on the team knows too much about accessibility (A11y) - assign the task of learning about it to the junior coder - then have that junior coder teach the rest of the team about it, comment on the teams pull requests, etc. A rising tide lifts all boats. Give that junior a reason to take pride in their work, and something to look forward to. Instead of peer pressure, flip it around and turn it into peer support. A non-bitter junior today might become a non-bitter senior in your company tomorrow.

If the issue is with the more senior “time thief”, implement the same strategy. Have a game of “surprise flip” of teams. So one team lead guides another team lead’s team for the day, and vice versa. This is another version of the “pair programming” solution.

There’s plenty of things to do - and they are implementation details. The important thing is - you won’t grow as the manager if you put all the blame on “one bad apple”. Even if that is 100% true, the least you can do is improve your processes so that it’s tougher for bad actors to act in a bad way. The panacea for that is the team spirit with the motto: “No one left behind”. For example, I’ve worked in a company where the team lead used to take out for lunch only the select few “boys in the club” - I never even got an invite. That’s the first thing that should’ve been done by that team lead, the very first day. But it never happened. So how would I feel as a member of that team? While I took the high road, some other dishonest developers might have reacted differently in the same situation - you never know what is going to trigger bad behavior - and it’s your duty as a manager to try to make everyone not only feel, but actually be a part of the team.

Ultimately, even if you as a manager do all of the above-listed things, people might steel act dishonestly. However, if all the above-listed systems are put in place, that becomes an ever less likely occurence.