Special Theory of Productivity
I call this my “special theory of productivity” because it is focused on the problems I’ve encountered with productively creating software in a team environment. Since I don’t have much experience in non-software work environments I can’t write a “general theory of productivity”. ;)
Responsibilities… and Authority?
Everyone talks about responsibilities, and job postings have endless lists of them, but no one talks about the authority people have. Or to put it in another way, who has any authority? For example, if a developer creates a pull request and several colleagues think it should be rewritten, does it have to be? If every disagreement results in an escalation to the “lead” then only that person has any authority.
As an aside, in my experience, people react in two ways to being told they have to participate at work, but then are basically ignored every day:
- They quit.
- They put in the absolute minimum effort to keep their job – they “tune out”.
The Three Types of People At Work
- The person with the money.
- The person who wants something built.
- The person who can build it.
Or to rephrase:
- The person with authority over spending money.
- The person with authority over what features are high priority.
- The person with authority over what technology is allowed.
Sometimes a single person will know what they want built and have the money. Oftentimes the person who can build it is a team of software engineers, testers, designers, writers, operations, etc. But at the end of the day those three decision makers have to have consensus about the project. Leaving out one or two of them during decision making is only going to lead to problems because assumptions will be made. For example, the Project Manager and Product Owner deciding amongst themselves that a bunch of features can be done in the next quarter. Or, equally bad, is when people are asked to make decisions and don’t have any real authority to do so.
Pick Any Three
It’d be nice to build a competitor to Google in a month, but that’s impossible because you can only control three areas out of the following four:
| Area | Comment |
|---|---|
| Cost | The amount of money being spent (usually relates to the number of people involved). |
| Quality | The quality of the software’s implementation. |
| Scope | The software’s features. |
| Time | How much time the team has. |
Note: it is the team of software engineers, testers, etc, that has control over the software’s quality.
To Summarize
- Determine which people have authority to pay for things, to decide what gets built, and how they get built.
- Decide on an area (Cost, Quality, Scope, or Time) that can change dynamically.
Disagreements can, and should, happen. But consensus must be reached or else the company will lose focus and spend more money than it needed to, build the wrong things, or use the wrong technology (which will have the wrong tradeoffs).
Note: “agile” is basically all about fixing the areas of Cost, Quality, and Time, but allowing Scope to change dynamically. [1]
To Summarize the Summary
Clarity and productivity go hand-in-hand. Passive-aggressiveness will destroy a company.
Footnotes
[1] In something like Scrum usually the size of the team is fixed (Cost), some amount of time is spent designing the code and writing tests (Quality), and Sprints are two weeks (Time). Based on feedback from the Customer the Scope can then be prioritized every Sprint. Thus, it is Scope that varies.