The Developer as a Resource

I work in the IT industry and in my opinion this industry is less efficient than it could be. In this text I want to look at one of the reasons why I think that is, namely a pull in the industry towards seeing workers as resources rather than people.

This article is not related to the ethical aspect of this question. Obviously there is an ethical aspect of dealing with humans as if they were objects and this is something that has attracted a lot of discussion throughout the years. This article only tries to concern itself with how you can get things done in the most efficient way.

Top level managers are tasked with assessing how many persons are needed to finish feature X within time Y. They have an awareness that some developers are better or more efficient than others. Using this knowledge, attempts are made to calculate some standardized measure of work hours needed for a project.

This apprach makes sense. First of all, once you are guiding a big company there is no way you can know or understand everyone you are working with. It will be your responsibility to move the company forward and you have to estimate what can be achieved and which achievements would be your fastest path to money. There is nothing wrong with this. This is the responsibility of the top level managers.

The problem is that compared to for example building a house or assembling a car, software engineering is less straightforward. When you have more practical or physical work it’s clear what needs to be done and how far along you are to achieving it. If you need to put tiles in a bathroom you can see how many tiles have been put and how many are missing. When you are dealing with software engineering the question is different. It’s about how ideas are shaped in a team and how they are executed to get the desired results.

In IT, most problems are more easily solved by four people than by forty because with four people it is easy to be aligned on what needs to be done and it’s easy to adjust to changes that are bound to come along the way. With forty people it’s difficult to be aligned and it’s not unlikely that things that are developed by some people will not fit together with things that are developed by others.

You will see it in practice where huge bureaucratic companies can take weeks just to change the color of a button whereas a single developer doing ones own project can deliver a complete solution from scratch to a novel problem just within a weekend.

Does this mean that Microsoft could fire all of its Software Engineers and just hire a genius like John Carmack and then productivity would go up? No. But it means that for isolated projects with a defined scope there is a cut off of how many developers can efficiently work on it and once you add more people than that to the project you are reducing productivity rather than increasing it. The fact that Microsoft has tens of thousands of developers enables them to execute on very many projects at the same time, something that naturally is impossible if you only have one developer.

If we then accept that the number of developers is not the primary predictor of how much work can be done, what is the best predictor?

A recent McKinsey report created a lot of discussion in the developer community. It was hitting (among other things) towards the holy grail of the manager, finding knowledge of how efficient each developer actually is. The article is nuanced and not one dimensional, still the knee jerk reaction of most readers (I guess a bit unfairly) is to interpret the article into saying that you can get objective metrics on how efficient individual developers are. This is “developers are resources” thinking. That thinking is a true impediment to productivity.

There are two factors at play there. The first, obviously, is the productivity and knowledge of the team. The second is how much work it is to achieve what we want to achieve. This second factor is often resolved by first letting someone create “user stories” on what features must be available and then doing up front estimations on these items by the developers. You then add up the sum of how much work that is and you get a rough estimate on how long it will take to finish. Some people do the trick of multiplying the number they get with Pi which usually lands them somewhat closer to the truth. All this is often done under the guise of being agile and doing scrum, this mindset is more aligned with doing waterfall project management. It’s the idea that you define what work needs to be done upfront. You then get some estimates and commitment from the team that the management can work with.

The unfortunate thing with waterfall is that it leaves little room for the project to act upon new insights that it’s getting along the way. Obviously you will learn things as you develop your project. As you ship features you understand more of your customers. As you see the system run you understand more of its bottlenecks and its strengths. Being unable to incorporate this acquired knowledge, which unlike your up front guesstimates of what is going to happen, is based on reality is a fatal hindrance to successful execution of IT projects.

But what am I supposed to do? Let’s say I’m a high level manager, I must allocate my resources in the most efficient way and I must be able to communicate to other stakeholders in the organization what they can expect coming out of my department. The key is that productivity in IT, if an organization is working almost halfway efficiently, is not coming from individuals but it’s coming from teams. By giving teams time to form and align you make it possible for teams to become efficient and these are then the units that you should best deploy to get done what needs to be done.

You might object that you must ensure that you have the right competences in your teams for the task at hand. To some extent you are correct, obviously an IT team where no one know how to code is not going to be successful. My experience is that as long as basic knowledge exists, having an efficient, aligned and agile team trumps having experts in the actual domain or tech that’s being used any day of the week. Recently I have worked with a team of four developers where only two of them had any knowledge of frontend at all to successfully create a full fledged Vue 3 SPA. The contributions and learnings from everyone in the team was vital for the success of the enterprise.

What you then need to do is to be clear enough of the direction that is needed but fuzzy enough on what specific user stories are needed to enable the team to leverage every single bit of learning that it is acquiring on its way to implementing the project. Create deadlines and explain why and what is important at that time and then let the team find the smartest way to achieve that deadline.

So I’ve come this far but I still don’t understand, why does thinking about developers as resources prevent productivity? Because it abstracts away the fact that productivity comes from teams and not individuals and it also abstracts away the fact that a team is more than the individuals that comprise it. A lot more. Much more important than the individuals of the team is the practices, the attitude, the mutual understanding and the acquired domain knowledge of the team. All of these things need time to be shaped and made efficient. By disregarding this aspect you prevent your company from becoming more than its individual part.