Updated: August 14, 2024
If you think I harbor disdain for mid-level management borglings, sycophants and their minions, you're absolutely right. I do. The perfect blend of cowardice, lack of imagination, shifty morals, and inability to truly inspire others is hard to like. And yet, these seem to be the defining characteristics of the vast majority of managers in the tech world. Wherever you work, whatever your role, there's a pretty good chance, at least 80% I'd say, your manager will be Bill Lumbergh from Office Space. Or one of his near-identical clones. On top of that, your boss wants you to be productive! Hear hear.
More disdain. Indeed, whenever I hear any workplace mention "let's measure productivity", my BS klaxons fire off. Not because the concept is bad. No. It's because the concept is completely misplaced, misguided, and impossible to achieve. And in this article, I will explain why, and also vindicate thousands upon thousands of people who tried to tell their manager it can't be done, only to be met with a blank stare of incomprehension. Begin, we shall.
Commence to be efficient! Or fast! Or productive. Or, or, or ...
Productivity is defined, not measured
What you measure is output. Output defines productivity, as in high output = high productivity, and vice versa. Not just, but you get the idea. Now, this works great for simple, deterministic tasks like a factory assembly line, where every single operation is clearly defined. Zero imagination, 100% repetition. Predictably, this does not work for any sort of creative work, like most functions in the tech space.
If you want to "measure" productivity, you need to define output. OK, someone picks apples. Awesome. Fifty apples per minute. Done. You have your definition. Now, as a wild example, what's the output of a software developer? Code. Great. What kind of code? Uhm.
What is the airspeed velocity of a laden software developer?
If your work requires you to pause and think, your work cannot be defined by a number. Period. It's as simple as that. If you must reflect and use cognition to figure out a solution to a problem, you defy the productivity formula.
Productivity measurements, here, yes. Credits: Wikimedia Commons, licensed under CC BY-SA 3.0.
Speed versus reality, quantity versus lazy management
I will start with an inane example. Someone says, design a website. Cool. It can be done in five minutes. You do it in five minutes. Done. Technically speaking, you were very fast in completing your assignment. Does that mean you were productive?
The answer is: maybe. If you satisfied all of the design criteria for the said website, yes. Now, you go, oh wait. What criteria? And thus, the entire productivity formula breaks.
- Most tech world work is done through collaboration among people; therefore no one individual's output can truly be measured in isolation, even if the very measurement of intellectual work were possible.
- Most tech world work is done in discrete bursts; time in between cannot be factored into productivity formulas because it does not constitute part of the same system, and yet often, almost always, approximation and extrapolation and averages are used for all sorts of purposes.
- Productivity, or rather, the quality of output, depends on a lot of things, many of which run contrary to any time-based or quantum-based measurements.
Let's go back to my silly website example. For example:
- Is the website secure? How secure? Can it handle personal data? Can it handle financial transactions? What about patching? Licensing?
- Can the website handle the necessary workloads? What are the contingency plans for high loads or slow response times? Is the website designed to offer an identical experience to users across the globe? What about localization?
- How easy it is to upgrade the website? Is there any documentation available?
I can think of dozens if not hundreds of questions you could ask about any which piece of technology being developed or designed in the modern tech world. And not until ALL of these questions have been answered fully and completely can one define productivity really.
What's the purpose of an amazing site that gets hacked after three minutes of going live? Or an ultra-secure site that fails its intended purpose, whatever it may be? What about a site that uses outdated technology that has no support? Or a site that uses bleeding-edge technology that has no support?
We got it, folks, the perfect formula.
Then, even if one assumes a project has been completed, such as say a software version release, it's only then the real work begins. How will that project behave six months, three years, ten years down the road? When you look at all the factors that truly define success and quality in any project, you end up with an equation that's too complex to define or use in any meaningful manner.
Alas, managers want easily digestible results. They want dashboards. Like politicians, they want flashy data that shows great results now. Whatever happens tomorrow will be someone else's problem.
Now, let's narrow this down a little. Let's talk about an individual working in tech. Say a software developer. Say a manager comes over and says, write this code. The person writes it. How will we know that the individual has done their work correctly, efficiently, in a productive manner?
Over the decades, everyone has tried to come with an ultimate productivity formula. Something that is composed of multiple "factors", which you then combine to get a unique value of productivity. There are two major issues with every single approach used so far, ever:
- It cannot quantify thinking - if you spend three hours conceiving your code and then writing for five minutes, or if you spend five minutes thinking, and then writing for three, which one is better? The answer is, it entirely depends on so many other factors that by watching, observing the employee at work, you cannot derive any meaningful conclusion.
In other words, the employee's activity has ZERO correlation to productivity.
- The second problem is that any individual work is only "measured" in the present, at best. But the real testament of quality lies in the future. This is why there's no meaning to saying someone finished a piece of software, until that software has been used by people, for a long, long time.
BTW, this is why you shouldn't refer to software developers and programmers as engineers. If you look at any non-tech discipline, an accredited engineer like say a civil engineer who designs a bridge, that person guarantees their work will stand the test of time, weather, traffic, and other factors. Similarly, an electrical engineer will guarantee their circuits won't burn when turned on. Often, there might even be criminal liability for shoddy engineering work. But not so in the software world. At best you get "no warranty, as is, mi scusi" nonsense. No consequence, no imperative for quality; no quality, no real productivity; only visible activity to appease the management.
Why productivity then?
Let me tell you a well-known secret. Control.
There are two primary reasons why (bad) managers want productivity metrics:
- It's something that allows them to control their people.
- It's something that allows them to feel important and needed, because if there's no reason for the manager to "check" the work, then they are ipso facto a glorified administrator in charge of pay slips. Which, to be fair, most managers ought to be. Very few people have the skills to be mentors and teachers and help their employees improve, in any which regard really, personally or professionally. In the past, in countries that had communist or socialist regimes, a way around unemployment was to provide a workplace for everyone, even if that meant running a completely non-profitable, meaningless business. In our current, more capitalistically flavored world, a way around having too many people for a given task is to promote them to management. I mean, c'mon, you've been there. That useless team member that barely works? Bump, now there's your manager.
And so, tragically, things MUST be measured, even if they are utterly meaningless.
Going back to the software world, you may have seen, heard or experienced the following examples:
- How quickly support case tickets get closed.
- How many lines of code have been submitted to a code repository (like git).
- How many tasks an employee has done in a sprint.
Managers carefully observing developers git the git.
And the list goes on and on. Bad managers define these nonsense metrics to feel good about themselves, control their people, and have something they can show their own bosses. But at the end of the day, no metrics can truly show the value of creative work:
- Ticket closure is meaningless without context, or taking into account problem severity, user satisfaction, repeat incidences of the problem resulting in future ticket openings (which are of course not accounted for whenever any one ticket is closed), and so forth.
- Lines of code can be added, removed, re-added, they can include comments, sloppy code, bugs, security vulnerabilities, performance issues, race conditions, and tons of other things. There isn't a single metric, ever, which can compare any two piece of distinct code (not the same project, duh), whatever their language or length, and say A is better than B.
- The number of tasks means nothing. Someone could work for three seconds and save their company a million dollars, or someone could work for a month and cause a blunder that leads to a massive loss.
But hey, whatever may be, productivity will be measured!
Productivity & AI
Vomit alert! There are two words corpo-drones salivate over: CapEx and OpEx. If they can reduce cost, by whichever means necessary, then they will do it, even if means feeding humans into a meat grinder. Until recently, the rituals of spending and saving and perceived productivity were constrained by the ability of systems to collect and analyze data. Now, with the turbo-boost provided by "AI", the corpo-drones have an entire new universe of nonsense to enjoy and play with, and see how they can transform your lack of work enjoyment into their annual bonus.
Just remember, if a human cannot measure it, or rather, cannot create a meaningful formula for productivity, then the machine can't do it, either. There are only two possible outcomes. Either the "AI" "hallucinates" a completely wrong and inaccurate method, or it comes with good numbers, but there's no way to derive the formula out of the blackbox and its 400-billion-parameter algorithms, making the entire ordeal useless.
That won't stop the clueless managers, of course. On the contrary, AI is now the holy grail of productivity, no less. Don't look for logic when there is none. Do you expect bad managers, whose very ethos is all mangled and wired the wrong way, to suddenly develop a keen sense of justice and reason?
Ai ai ai ai ai, the machine is here to replace you! Credits: Maximalfocus on unsplash.com.
Now, everything I mentioned earlier still applies, except now, there's an adjective. AI. Simply add AI to everything, and it's still the same pointless load of dung, only with an extra word. Worse, because we now have powerful software that can do all sorts of mega-calculations quickly, and we have managers who confuse activity for productivity, you can bet both your kidneys that you will be asked to define your productivity using AI voodoo magic. But tools do not change the reality. They can help you attain results IF AND ONLY IF you know what you want to do. Otherwise, you might as well give a toddler an entire car mechanic's toolbox, and watch them play.
There really is no reason to talk about AI in the context of productivity. But I wanted to bring it
up, because inevitably, the concepts of bad managers and AI cannot be separated. In fact, you can bet
the more pointless your manager is, the more likely he or she is to bring up the phrase AI. The phrase
will come up almost randomly. You will say: "Good morning" and they will say "AI AI AI". And your day
in the office will be complete.
It's not all pointless, is it?
Not all. But 99.99% of it definitely is. There are still meaningful ways to measure things. In fact, there's only one way, and it's called the scientific experiment. Whatever type of work you do, you start with a well-defined hypothesis for what you're about to undertake (hence many work-as-you-go IT methodologies are large useless, or at best, suited for very small, narrow, non-creative types of work), an experiment (the actual work you do), objective methods for measurement, and criteria for success. Without all of these laid out, your projects are nothing more than a ritual between one salary payment and the next.
The issue with this approach is that it's very harsh, very objective, very hard to hide behind. It does not focus on unnecessary details, it focuses on the end result. The whole thing requires philosophical thinking. And it runs contrary to the busybody meddling of mid-level management with frequent status reports and updates and pointless meetings.
As an abstract example, say you want to build a house. The architect comes with a plan that satisfies the customer's needs and law-enshrined safety standards . The builders then put bricks and concrete and whatnot down, following the plan rather unimaginatively. One brain, many workers. One creative persons, lots of executioners. But even so, the executions still have some freedom in their work.
You don't need to tell people how to place individual cinder blocks or where to pour the slurry, unless they aren't really skilled or capable of following instructions. The workers follow the plan. In the end, they will build a house, and it needs to meet relevant the aforementioned safety requirements (and customer needs). That's all. Whenever this work takes three days, nine months, five people, or seventy-three trucks of cement makes no difference. Not really. A productive architect and a productive building project manager will do these things efficiency. And non-productive ones won't. Very simple. In this regard, productivity is not doing things faster or with fewer bricks. It's doing it right, in line with the plan - and safety standards. If the planned work and actual work match, then you are being productive.
Code as a building, or something.
Translate this to software. An architect (not necessary a software architect) will design a product, based on whatever the market needs (provided these are correctly defined). The builders (software developers) will then code until the project is complete.
I once referred to software developers as glorified digital welders. Sad but true. There's no great imagination needed in writing code. Some programmers are talented, but most just use funny languages to get computers to do certain tasks. Function in, function out. That's it. What happens in between is largely irrelevant. C, Python, Java, it makes no difference. Indeed, the work of the developers can and should be treated as a black box. Give the folks the freedom and time to do what they need. The only thing that matters is that the final product meets the necessary standards.
Ah ...
There are virtually no standards in the software world. Safety is often an afterthought. Because there are no ramifications to shoddy work, there's no incentive to write clear, safe, manageable code. If you're paid to code, then you don't want to make perfect code, because that code won't ever need any maintenance. On the other side, money is always a factor. The less the company has to spend the better. Corner cutting, if you please! Why hire a team of excellent professionals when you can hire three teams of cheap offshore junior developers to do the same work? After all, if quality and standards aren't part of the definition, then why not save a dollar or two?
This lack of criticality of quality is well known to everyone. It's no surprise. But then, managers think: wait a minute, my employees may have fluid morality as I do, and if my employees know they don't really need to work hard, they might actually relax and enjoy themselves at work. No! Catastrophe! Productivity, productivity, productivity!
For managers, this translates into maximum value for money, and so the circus of pointless activity rituals begins (anew).
- Work eight hours in the office. Why? Are you a Prussian administrator at the Frederick's court? Nope. You're a software developer, but you show dedication by staying long hours behind your desk, regardless of how long it takes you to do your job. Also, let's ignore any inconsistency in companies' messaging and sloganeering regarding the WFH and RTO mandates during and after the pandemic.
- Show you're busy. Why? Because if you're not busy, you're idle, and if you're idle, then you're basically being paid to do nothing, and free money is communism. This is why most managers want to hear frequent keyboard clicks and see your status icon set to green in the chat program, because these are indicators of money well spent. Ignore the fact you could be busy causing damage by your pointless work. Or the fact that happy people not being unnecessarily pressured to do menial, pointless work are actually more productive. Ignore those facts.
- Attend frequent meetings. Why? Because your manager doesn't do any real work. So what's the metric for management productivity? Meetings. If your calendar is fully booked, it's not a sign of you not being able to write short, efficient emails with all the relevant information that could save tens of people hours and hours of their time, nope. It's a sign of dedication and sacrifice, that.
- Try to think of productivity metrics. Why? Because they show you're being productive. The more you measure, the more you can add to the company's dashboard. The busier the dashboard, the higher the chance the top boss will only skim over the details and not ask any hard questions about any which metric.
Productivity does exist
Now, I've been a wee cynical until this point, if you haven't noticed. So what then? Is everything truly lost? Can we not differentiate between efficient, productive workers and the rest? Of course we can. However, what that requires is a rather hard, blunt approach. A rethink of the modern workspace.
The one metric of productivity is happiness. Everything else is a corollary. And before you say anything silly, in my formula, I assume that every person at the workplace has achieved their position based on merit and skill and actual professional abilities. I'm not talking about some campfire happiness nonsense. No.
If your workplace is actually composed of professionals (even middling quality, as most people), then if you keep those people happy, their work will be better. Simply let them be. Yes, some people will abuse the freedom and hands-off approach. Most won't. Most people will appreciate the unspoken grant of responsibility and trust given to them by their employer, and will try to reciprocate. They will be more receptive to feedback, more likely to adopt safe or strict procedures in their work, so they don't lose the authority they've been entrusted with.
That's all. Sounds simple, and it is. The only problem is, most managers cannot fathom the concept of not having control over their people. It's alien to their narrow-minded thinking. The most productive teams are self-governing, and they deliver work up to predefined standards or any which criteria. What happens in between is entirely up to them.
Good communication helps. It can reduce the time needed for teams to talk to one another, giving people more freedom to go back to do what they enjoy. After all, if someone writes code because they like it, or someone solves difficult equations because they love math, then you can assume those people will try their very best if you give them the space for their weird fun. Of course, you define the boundaries of the sandbox. Play all you want, just make sure what you deliver meets ABC. That's it. The manager should be present only to make sure things stay inside the boundary, but whatever goes on in the creative space is private and inviolate.
And that's true productivity.
Conclusion
There are two ways to go about life. You can assume people are animals barely kept under control by law, or the fear of punishment, or you can assume that people will assume the role you want them to assume. Both these conditions can be true at the same time. In the tech world, though, the would-be cream of the crop of the industry, the elite, whatever, the primal factors are a bit less extreme. There is really no reason to treat the nerds as an unruly, dangerous mob. But whatever they may be, they will resent the assertion of control, and they will match their productivity to the inverse of their manager's level of control. In other words, if you treat people as sheep, out of spite, subconsciously, they will behave like sheep. And vice versa.
Productivity measurements work great for deterministic types of work. They fail miserably for intellectual work. They also make people wary, angry, demoralized, and purposefully dumb. Spite is a great force, and it beats strongly among the geeks and the nerds and the Python lovers. But give them space, give them freedom, just tell them how big the playground is, and you might be surprised with the outcome. Right now, the industry has no boundaries, but it has a plenty of meddling managers herding people around an infinite field of greed. Well, there you are. I'm quite certain nothing major will change. But maybe one or two people might read this and chuckle ever so softly, and that's good enough for me. I would consider that a productive outcome of this article. Take care.
P.S. Images without explicit credits above are in the public domain.
Cheers.