A lot of people quote about Henry Ford’s remark, “If I ask my customers what they wanted, they will say faster horses”. We do not know if he really said those words but it is true that many of the ideas will always be incremental and not inventive, be it technology or ways of working.

If you ask bosses what they wan’t, everyone unanimously says “Longer working hours” especially more vehemently in the software development industry. My observation has been that with lots of automations and tech abstractions, the time taken to develop software has come down by a few magnitudes, compared to what it was a decade ago. What needed large teams with extensive management overhead can be done with smaller teams with fewer oversight.

In mature domains like mechanical and civil, breakthroughs are very less frequent; hence templating the work into easy to do steps that are verifiable by non techies is very productive. An abstract requirement will be translated to actionable steps, broken down into units of work and assigned to people to complete. Once the task is complete, it is very easy to verify by anyone else and the end of construction phase is typically the end of the project. It makes things rigid and predictable, so it has a linear relationship between number of people, number of hours and dependencies.

Software development on the other hand is very difficult to convert from abstract to concrete, any infusion of rigidity risks not getting the intended outcome. The combination of ever improving tech landscape, difficulty in communicating what a working software should do, the nature of knowledge work which degrades when stressed, makes it very hard to have a proven relationship with working hours, number of lines of code and number of people.

Photo by Tara Winstead on Pexels.com

When dealing in a dynamic environment, there is more than one way of doing things, sometimes exponentially time saving ways can be found if we strive to make the design simple. One personal example I had was to write a program to convert roman numbers to decimal. I wanted to shake off the inertia and start writing code, I dived deep into the code thinking in terms of objects, writing a lot of tests and completed it after a few hours when I was convinced that the solution is complete and clean. The next day I realised that I was constrained by the need to keep going, that I never questioned if my solution could be simpler. I just spent 20-30 minutes to rewrite it in functional paradigm and got that done under 10 lines of code in one file which was 100+ lines across multiple files. For an outsider, thinking hard about the problem looks like inactivity, wasting time and not showing urgency; to me it came down to a super simple solution that is very easily be read and maintained by others.

Bosses are often tuned to look for urgency and activity as indicators of productivity. Also in the software service industry irrespective of the productivity, the number of hours billed directly impact profits; hence bosses love long working hours. In the software product industry though billing hours don’t matter a lot, the apparent busyness of people is expected. As a result, no major improvements happen as it is always business as usual sometimes even slowing down overall, creating physically and mentally unfit individuals over the long run.

On the other hand if teams are given freehand, then they also tend to extend the thinking phase into analysis paralysis. This can be broken down by mandating outcomes and impact on fixed timelines than output and effort. It is an art and takes a determined effort to build high performing teams that keep punching above their weight. The easy way out is demanding long working hours.

If you are engaging a knowledge worker on physical effort, then you are buying into mediocrity

I recently installed an app to get groceries and milk delivery at home every morning. When I browsed through the catalog, a lot of items were cheap but when added to cart they asked for a subscription fee to checkout at the listed price or pay markup on the items which were much more than what it was listed on the catalog. So I went ahead and paid the subscription fee and when checking out I see that only some of the items are discounted but not all the others. When I looked into the details, the subscription had a fine print that the price was applicable for only 15 items and it auto applied to all the cheapest items, leaving out the bigger items at the markup price.

I anyways continued to order to check the quality of deliverables and over the course of few days I felt that provisions ran out a bit faster than the previous vendor. On checking the details, all the products sold are in the range of 400-450 grams or 400-450 ml instead of the standard measures of multiples of 500. I checked around who these people were and found a patch which proudly claimed that it was a product of IIM alumni. Why on earth someone spends entire early adulthood preparing to earn a good degree just to mislead and profit.

Photo by Wendelin Jacober on Pexels.com

These kind of rots and rusts are evident in the society, at workplace it is hard to spot. While it may not be deliberate act of mislead and profit, it is more of rent seeking that is rusting the workplaces. Job characteristic theory mentions that a good favourable job will promote

  1. Skill variety – To learn continuously and implement
  2. Task identity – Where people understand the larger picture about whatever small they are doing
  3. Task significance – The general good feeling of doing something positive for others
  4. Autonomy – Accountability on actions, elbow room and breathing space. No one constantly telling people what to do
  5. Feedback – To know whether what someone did is good for not in an actionable way so that they can build on the failures

Conventional industrial processes did not worry about any of the above as it was primarily a dead end job. When software was first developed it was very similar. Breakdown the entire work into small chunks, sequence it and give it to people to finish the product. The industrial type work relied on individual contributors working in isolation with a specific skill, as long as they follow the job description the end output however complex it looks can be achieved. The knowledge type work relies on individual contributors working along with others in the group to be successful. It is a key difference, the industrial type of job is a dead end job with no autonomy, skill variety or task significance.

The rots and rusts start from there, young individuals join the knowledge workforce expecting to do big on their career but are stifled by the system that was designed for industrial type of work. Eventually people become victim of systems, they become tired of always being told how to do and what to do. The faster they escape from the situation, the better so they try to get into management as soon as possible. This steps furthers the rot, an individual contributor who did not understand well how to do their work within a team is now equipped to tell others how, when and what to do.

Where do people look up for guidance in a new job role?, it is their peers who are doing similar things. Anything which has a short term gain and less learning horizon gains traction compared to long horizon ones. Example – Click bait to increase engagement but lose the brand value over long run. As long as the increase in engagement is rewarded handsomely this behaviour will continue and the person will move on to another place leaving the after effects to be handled by a successor.

Shanty towns – Locally optimised but a collective failure. Picture from pexels.com

Slowly many anti patterns become an accepted practice and become templates for career growth. A rotted and rusted system will cause more victims of the system. Every one will be governed to optimise for themselves but collectively fail. Agility in software development was a key issue when people were following the industrial type of work breakdown and development, a bunch of people got together and came up with the manifesto to bring agility into software development. What followed after 2 decades is that there are plenty of frameworks and processes but no agility. Ask this question, if a business needs to wait for a release train next quarter to test out their hypothesis and implement that in the following quarter, how is it agile?

People can attend a training for 3 days and become masters in driving agility in their teams, it is like saying you can become a football coach by attending a 3 day training, that is how broken the industry is. Unless an individual realises and resists to contribute to the rot, the rotting and rusting will continue.