It is going to be hard to write anything about management for this month’s issue, because the entire field is moribund. There has been no innovation in management for decades, supposed sea changes in thought have either failed to take hold or failed to deliver anything new, and we are all still mired in the industrialist, piecework thinking of Taylor’s scientific management and workplace surveillance.
The acephalous nature of the modern workplace is evinced by the supreme slow pace of innovation in even the most high-tech of industries. The tablet computer was conceived in 1968, described in detail in 1972, and thanks to the breathtaking pace of private sector innovation was soon ready to pre-order…in 2010. Its place in a modern office, in a scalable suite of devices from wall-mounted smart TVs to pocketable badges, was clearly described in a program that started in late 1987. We still do not have the product.
Meanwhile, the CEOs of the largest companies use their friendship with and gifts to their agents in the political system to gain windfall tax breaks, meaning the poorest in society pay to keep that society together while they get the discounts. What do they do once they have dipped their scoop into the public purse? Do they increase wages? Hire more people from traditionally marginalised backgrounds? Fix worker abuses in their own offices and in their supply chain? Double down on R&D spend to create life-changing new categories of commodity?
No, of course not, ha ha. How ridiculous. They engage in massive stock buybacks that give the money directly to their investors, and go on patent purchasing sprees to stop anyone else from accidentally innovating. Just to put the amount of money involved into perspective, that $90B stock buyback was enough money to buy the 87th largest company on the S&P 500 outright (Booking Holdings, at time of writing), or the 15 smallest companies on the index (which are not the 15 smallest publicly traded companies, but the 486-501 largest taking Alphabet’s two listings separately again).
Have the most valuable companies (i.e. the ones at the top of capitalism’s high score table) done the most to improve standards of living, or introduced the most innovative and exciting products? Hardly. A quick scan of the top 11 (Alphabet is counted twice, because their class A and C stocks are listed separately) shows one genuinely life-changing company: Johnson & Johnson, one of the manufacturers of Covid-19 vaccines. Everyone else is in advertising (Alphabet, Facebook), finance (Berkshire Hathaway, Visa, JPMorgan Chase), retail (Amazon), reselling rechargeable batteries (Tesla), or renting you software that you used to buy (sorry, “license”) outright (Microsoft, Apple). Read that again: fully six of the ten largest companies in the US are in the business of circulating capital, not producing anything: the ones who are producing anything are inventing new business models on old products to turn those into circulating-capital businesses too.
The latest product announced by the United States’ largest company is a radio locator beacon (regularly in use since the 1950s), which adds to their portfolio of variously-sized television screens and wireless headphones. But of course it all uses the internet (developed in the 1960s with publicly-appropriated funding), which apparently legitimates the whole shebang being rented to you under the guise of “services”.
So much for executive management and the C-suite, but what about middle management? What changes have their been to the way our employers interact with us software engineers in the 53 years since the job title was invented?
Once again, we see that Western culture’s fascination with Adam Smith manufactory and Taylorian management science has held back innovation in this area, too. The old-school traditional software engineering approach featured managers trying to get more productivity (measured in function points per day) from their over-stretched workforce. The new-school, post-Agile approach features managers trying to get more productivity from their over-stretched workforce, but now we measure in story points per day so that is progress, right?
This is not to say that the lightweight methods/Agile realignment has achieved nothing. Indeed, for many adopters it achieved a large subset of its goals: focusing on producing customer value instead of on fulfilling a predefined plan; frequent re-evaluation of practices and methods; integrating all development activities into a unified process rather than tackling them in distinct phases as isolated division-of-labour tasks. For some adopters, this transition did not go smoothly, so DevOps was born as a way to tell the same story using different words to try to get it to land again.
However, the entire concept of Agile software development required cultural shifts, and by and large those did not happen. Particularly, the people in the top and middle of the org charts did not buy into the ideas, or see them as relevant. If agile is the thing that your engineering division does, or that your backend team does, then I am sorry, but I have two pieces of bad news for you. The first is that they are not “doing Agile”, because they cannot. The second is that you are not managing your company, because you have failed to foster a shared cultural understanding of the work and the way of working.
The principles behind Agile software development—but wait. We must point out that these are the principles that were behind the construction of the manifesto in 2001. This context is important. This is a document written in reaction to the world as it existed then, much as the “Rights of Man” was written in 1791, or “Go To Statement Considered Harmful” was written in 1968. Each of these is a reaction to the perception of the world its authors had at time of writing, and can only truly be understood through the lens of that time; and interpreted through the lens of our time.
Anyway, those principles include ideas that can be seen as much more collaborative, maybe even anarchistic, than could be found at many contemporary Anglo-American businesses.
Business people and developers must work together daily throughout the project.
This does not transcend the division of labour—there are still “business people” and “developers” (you still hear engineers talking about “The Business” as if it is a separate organisation) but it does mitigate the division of labour. We go from analysts turning requirement-resources into specification-products, architects turning specification-resources into design-products, developers turning design-resources into code-products etc. into everyone working together to turn “customer needs”, whatever they are, into “valuable software”, whatever that is.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This is the bit that requires a lot of trust from management. A lot. I mean, it is written right there: “trust them to get the job done”. If you are demonstrating your distrust through presenteeism (related: “Management by Walking Around”), setting “stretch goals” above what your team forecasts it can achieve, or by ensuring that the daily stand-ups are actually daily status reports from your DRs, then it does not matter how nice a monitor you bought them or what the staff:foosball table ratio in your office is. You are still managing like it is the 19th century.
Here is a test of your level of organisational trust. Under what circumstances does the stand-up get canceled? If the answer is “when the manager cannot make it” or “when the product owner cannot make it”, you are doing daily status reports. If the answer is “if we collectively decided we would not get any value from them”, then there is some chance your managers trust you to get the job done.
The best architectures, requirements, and designs emerge from self-organizing teams.
Once management trust its professionals to act professionally, it can let them get on with the task of apportioning the work. Now there is a true transcendence of Adam Smith, a genuine change in philosophy since the time of the pin factory and the innovation of paper money. We have gone full anarchism here: rather than trying to get management buy-in to some new methodology, the management are trying to get worker buy-in to the project they want completing.
Maybe that is the issue. Maybe it is “employment” that is the problem. Managers gonna manage, because they have paid for eight hours of your time per day and by golly gosh are they intent on getting out of those eight hours whatever it is that they can think of. Perhaps for software engineering management to get itself out of the moribund state it has been in for at least five decades, the managers need to be contracted by the workers.
Photo by Mathew Schwartz on Unsplash.
