Elastic Staffing Challenges

I have been away from this blog for a while. In fact, I don’t remember when I last posted (I looked it up it was May.) In my hiatus, I have worked on some other writing projects and spent some time with Zed A. Shaw’s excellent “Learn Python the Hard Way”. As a matter of fact I. will post my impressions of that book soon. Preview: It is an interesting take from an interesting guy at solving the coding bootstrap problem.’

Today I want to talk about something else that has been bothering me for a while. The notion of an elastic software delivery staff. This is not a new problem, in fact, it is as old as software. Fred Brooks wrote “The Mythical Man Month” almost 40 years ago, based on experience almost 50 years ago. I was introduced to that book in 1984 while I was studying computer graphics with Sam Uselton at the University of Tulsa.

When you haven’t tried to “run” a software delivery team or project, the tremendous wisdom in that book pretty much goes in one ear and out the other. You don’t have the experiential context to comprehend the problem space. When I read Scott Adams brilliant Dilbert comic strip today, I see much of the same problem space. There are types of work that don’t scale well. Our traditional strategies for elastic staffing that developed during the industrial age don’t really work effectively for this kind of work.

Why is it so hard to scale some kinds of work? (like software development)

After thinking on this for a while, this is what I believe. There are three reasons:

1) The work is not reproducible –

Unlike many tasks, the lowest level of work in software delivery work, “writing code” is not reproducible. It can’t simply be done by any skilled programmer. Skill is not the driver of productivity. Understanding of the problem is the driver of productivity. And since no two people understand the problem the same way, and since we don’t even understand the words we use to talk about the problem the same way, what we produce as programmers will not be “the same”. The best we can hope for is “functionally equivalent”.

2) The problem isn’t easily divisible –

A software “system” has to work together as, well, a system. If you want multiple people to build something that has “integrity” – that works together, that can be experienced as a “whole” rather than a collection of parts, they all have to understand how the part they are working on fits into the whole. Every software development “methodology” expresses some pattern for solving this problem. All of them fail in some way. Primarily because of the first reason, a lack of common understanding.

3) The vision is not easily shared –

The vision required to define a new system from the ground up can’t easily be distributed among a group. Maintaining a clear sense of purpose for the software and a clear strategy for how the software will accomplish that purpose gets harder as more people are added to defining roles. The most brilliant visions often emanate from a single mind. It isn’t that others can’t refine, or expand on the vision, but no two people will ever share the same vision, for exactly the same reason – a lack of common understanding. This is largely because any new creation may not be supported by our existing vocabulary. Think of the following examples from the industrial age – iron horse, horseless carriage, assembly line, telephone, television. Now, think of those from the information age – file server, database, personal computer, smart phone. The vision to create these now category defining products defied our ability to describe them.

In essence, the reason that software delivery is hard is because human language is insufficient to describe the vision in a way that every person perceives it the same way. In physical construction and other engineering disciplines, we resort to elaborate drawings with strict conventions rather than the written word to solve this problem. We have tried to do these kinds of drawings in the software industry, but they often fail to convey some aspects of the vision. I submit that this aspect is semantics. It is the very thing that human language is insufficient to solve, but is the only means that we have to communicate.

Said another way, in order for any type of work to be highly scalable (being able to successfully be executed en masse) it must be reproducible, divisible, and supported by a sharable vision.

How can we create an elastic staff for work that is neither reproducible, divisible, or supported by a shared vision? By scaling the skills of representation (imparting vision), collaboration (developing common understanding) and facilitation (coordination of effort).

It is not sufficient to have skilled technicians, coders, in order to scale we need people who can impart the vision for the work, by representing the unfamiliar in terms of something familiar.

It is not sufficient to have people heads down, in order to scale, we need leaders who can ensure that the right conversations happen, information and understanding is transmitted between workers to keep the work moving forward together.

It is not sufficient to have managers who can assign people to roles, in order to scale we need leaders who can organize the team’s activities and adjust responsibilities to develop trust and competence between workers.

Elastic Staffing Challenges

Why is it so hard to scale some kinds of work? (like software development)

No Comments

Post a Comment