How to avoid being cheated in software development

Pitfalls explained

In economic literature there is a research area called Principal Agent Theory, which emerged in the 1970s from a number of economists and theorists, It is occupied with an economic problem that is common in all sorts of relations in which a principal's profit or payoff depends on the behavior of an agent. By definition, an agent is using the resources of a principal. The principal has entrusted money but has little or no day-to-day input. The agent is the decision-maker but is incurring little or no risk because any losses will be borne by the principal. The principal is limited in his ability to monitor and judge the agent's input and output. This leads to mistrust and can only be avoided under high monitoring costs. The problem is especially acute in software development due to missing metrics and measures for programmers' productivity.

Principal Agent Theory is based on several assumptions, but we'll focus on two:

1. The agent has an advantage due to incomplete and asymmetric information and monitoring costs. The smaller the ability to control the agent's activity (i.e., the bigger the information asymmetry), the bigger is the principal's uncertainty.
2. There is a divergence of interests i.e. the agent shows opportunistic behavior to maximize their own expected profit instead of acting in line with the goals of the principal. The three types of opportunistic behavior are hidden characteristics (the abilities and skills of the agent are not "common knowledge"), hidden intention (agent has goals and interests not known by the principal) and hidden action (principal cannot fully control the principal's actions).

There are two groups of problems arising due to the above assumptions. First is before the start of the interaction (ex ante), Second is after the start of the interaction (ex post),

We are interested in the applications of Principal-Agent theory to software development. In one case, the principal is an executive officer of a company and the agent is an engineering manager, a team lead. In another case the principal is the team manager and the agent is a software developer on the team. In what follows we'll consider a combined case, where the executive is in contact with the manager, whose output depends on the team.

Before the start of the interaction (ex ante), the principal cannot fully judge:

• The team's "quality" (hidden characteristics) indicated by historical productivity.
• The plans of the manager and each of the team members (hidden intentions) if and how to maximize their own profit through overemployment, developer lock-in.

After the team have started the work (ex post), the principal cannot control:

• The activities undertaken by the agent (manager and the team members) (hidden action). The agent has an opportunity to utilize its information advantage and to maximize his profit e.g. through working less than expected, unnecessarily high budgets. not enough work. managers do not want to know who the poor performers are.

The end result is low productivity of software development.

Low productivity of software development is the problem.

How to overcome the pitfalls?

On the diagram below we have the problem of low productivity outlined. How can we solve this problem?

The problem is manifested in six undesirable effects namely working less than expected, unnecessarily high budgets. overemployment and not enough work.

Common trait to all six undesirable effects is that they are instances of underutilized human potential. Thus, the underutilized human potential can be used as an indicator of all undesirable effects.

If we find instances of underutilized human potential we can be sure at least one of the undesirable effects is present.

All six undesirable effects have a root cause - the lack of managerial oversight. Thus, we can conclude as presented in the diagram above that if there is underutilized human potential then there is:

1. Lack of managerial oversight
2. Higher than needed software development costs

You can use KEDEHub to check the utilization of human potential.

In general, to mitigate against all of the above the executive needs to decrease the information gap, the information asymmetry. Benchmarking is an important tool to ensure performance over the course of a software development process. However, few executives have been invoking their rights to compare a team's performance to other teams in the company or to the industry average.

You can use KEDEHub to frequently benchmark a software development organization's capability.

Developer lock-in

A developer has the incentive to make it as costly as possible to be replaced. They do that by not sharing the knowledge they acquired while working for the company. One way is to have as little documentation as possible. Then the technologies and tools used need to be novel and difficult to find developers for them. That decreases the talent pool that can replace the developer.

Working less than expected

“People are great at interviews, excel during the trial, then their output plummets.” ~ Anonymous Project Manager

A developer can win a job by performing a solid interview. After that their performance does not reflect what they showed during the interview. There can be several reasons for that.

One reason might be that some people frankly optimize for working 3-4 hours/day[7]. That is possible if the developer is not at the company's office but works remotely. It really stings how some local cultures and remote work ethic don't mix. The developer could do that to be able to have more leisure or to start on overemployment.

You can use KEDEHub to set capacity utilization standards for your project.

Working less than expected is successful only if the company lacks the managerial oversight needed. The end result is underutilized human potential for the company.

Overemployment

“Some people took a second job on the side… I never expected this.” ~ Anonymous Engineering Manager

Some developers do two jobs at the same time because they can pull it off, and make 2x the money. This is called "dual employment", "overemployment" or simply "OE"[1]. That is equally possible when people work at the office or remote. And applies both for developers and managers alike. OE for the management roles are easy because managers delegate most of their work. they can work their first job on-site and the second job remotely[2].

One needs to get the first job down to 20 hours a week to allow room for a second job. The strategy is to create slack but look busy. The ways to create slack are: delegation, automation, over-communication, insistence of asynchronous communication, and setting your ego aside to meet the minimum performance requirements instead of being a rising star[3].

Here we need to emphasize that from a scheduling flow of work perspective slack is a necessity. Slack means free capacity. If your organization's goal is to become fast, responsive, and agile, more local efficiency is not the answer - you need more slack. Implementing slack could mean designing workloads that allow people room to think, innovate, and reinvent themselves. It means embracing risk, eliminating fear, and knowing when to go slow. Slack allows for quick change, fosters innovation, creates room for quality improvement, and thus produces growth[4]. Question is: what will the slack be used for? For being able to accept work on a short notice? Or for being able to work a second job?

High performers are potentially big winners in a remote world. Let's say a developer produces 5x the code the person next to them does. Very few companies will pay them 5x more. Maybe double... If a high performing developer can manage their time well enough to get the job done in some fraction of the work time, they could realistically do two or three full time remote jobs worth of "normal" work, and increase their pay - and income security - over having just one job. That doesn't work that easily when they have to be at the office in person all day, but is not impossible.

What happens when both of the jobs decide to schedule a recurring meeting at the same time? Yes, meetings clash, but it's easy to get meetings rescheduled if one just asks. The developer can handle two calls at the same time if they know it's a call where they're mainly going to be listening. If needed the developer can always claim "bad internet" and drop out of one to answer questions in another.

Overemployment is successful only if the organization lacks the managerial oversight needed. The end result is low capacity utilization.

You can use KEDEHub to compare current with the historical capability of the team and each of the developers.

Unnecessarily high budgets

Some companies are extremely focused on retention, personal and professional development, and talent leadership. They would go above and beyond in order to retain their staff and receive glowing reviews on Glassdoor.com. When employee retention becomes a problem, lazy managers may be quick to suggest pay raises or bonuses as the antidote — a costly solution that may fail to address the underlying issues. This way managers free themselves from doing the hard work of considering how their own management style affects developers satisfaction and turnover[6].

Management is not easy, and it takes effort to develop and retain highly motivated people. When retention issues show up, company leaders should consider whether lazy management is contributing to the problem. When employees are underperforming, rather than asking what is wrong with them, company leaders should instead consider the possibility that management is doing something wrong[6].

Employees know who the underperformers are. One reason good performers leave a company is because poor performers are not dealt with by management. Keeping poor performers means that development opportunities for promising employees get blocked, so those subordinates don't get developed, productivity and morale fall. A reason cited by managers to leave poor performers in place is because they want the company to be seen as humane. Managers could remove all the difficult parts of an underachiever's job and delegate them; in a vain attempt to help the poor performer cope. The result is human potential is underutilized. Why don't managers act? Debra Dunn, a senior executive at Hewlett-Packard, puts it like this[8]: "I feel there is no greater disrespect you can do to a person than to let them hang out in a job where they are not respected by their peers, not viewed as successful, and probably losing their self-esteem. To do that under the guise of respect for people is, to me, ridiculous."

Not enough work for all developers

Sometimes a company just doesn't have enough work for all their developers. Especially if some of them are very specialized. Sure, they could send those employees back home, fire them even. But the risk is that once they would be needed again, they would not be available anymore! Or the managers could need to preserve their department's budget. That's a sort of use-it-or-lose situation, where firing someone who does little work might convince the executives that the budget could be reduced. So, a manager could want to sustain a larger budget, even if it meant some developers didn't have enough work. The result is an unnecessarily high budget for the company. Now the human potential is underutilized because of this lack of managerial oversight. Developers could start on overemployment.