Some of us who have worked in large organisations can relate to this as processes eventually overshadow purpose and we find ourselves mindlessly ticking boxes or attending recurring meetings which we can pass off as work. This article shows why this aspect is even more pronounced in the tech industry.
The author begins with his own experience of having worked with multiple organisations where he got by with little or almost no work. He then shares why his experience is the norm than the exception citing examples of others in the industry. And add to it, they all acknowledge they are paid rather well.
“Indeed, for a lot of people, the idea of being paid a lot to do nothing sounds like a dream come true. However, while we may not do almost any real work, we do have to constantly pretend that we do. That can be extremely frustrating and soul draining. Moreover, this shaky situation cannot last forever; it’s like a poorly balanced house of cards. With the recent massive layoffs and the collapse of SVB, the signs of strain are already there.”
Why do techies end up working so little?
The author points to a software development philosophy called ‘agile’ which was adopted in the early noughties to make coding process driven.
“In agile, software is developed in very short cycles, as short as two weeks, and the result is validated and goals realigned between cycles. Every couple of weeks, the team gathers to plan the tasks for the next cycle. But in this planning phase something really strange happens: It has become the standard practice to highly exaggerate the efforts required to perform a task, which we’ll call task bloating. In the planning session, hands-on people, managers and other stakeholders all agree that each task takes an abnormally high number of hours to complete and requires an abnormally high number of employees.”
He shares examples of how ‘agile’ creates task bloating and undermines productivity.
“…a lot of the work in tech involved “meta work” that seeks to plan or discuss the actual work: You first speak about the work you will do, then you speak about the work every day for two weeks as you do it (since tasks are really bloated, this requires a lot of pretending), then you demo the result of your work, then you collectively reflect on it. Very often, the meta work is almost the only work you do, as the 15-minute debriefs and planning sessions take longer than completing the bloated tasks themselves. I once attended a planning meeting in which it was discussed for 20 minutes whether a task should be included in the next sprint or not. The task could be done in five minutes.”
He acknowledges that ‘agile’ had the right intentions but along the way has been applied wrongly lacking purpose where the employees’ main goal becomes to abide by the methodology.
Another reason he cites where tech loses purpose is when it comes to hyped up new technologies or fads. Tech companies chase fads without realising the benefits to their client, simply because not following it might affect valuations.
Whilst the author believes this applies to other industries as well, it is accentuated in tech for two reasons:
“…one of the reasons for that is that technical work is poorly understood by business people. So, if techies tell a decisionmaker that reading a code template takes a week, instead of the more realistic 30 minutes, they are likely to believe it. It would be much harder for, say, a barber, to pretend that cutting someone’s hair takes days, as everyone has had a haircut before and roughly understands what a haircut entails.
Moreover, the benefits of many tech projects are intangible. If you promise to build an “AI-based insights engine,” it is hard for businesspeople to understand the return on investment. You can roughly measure the output of a barber in terms of number of haircuts, but how do you measure the value of a data science or an analytics project?
The adoption of agile recipes also helps conceal the problem, as it creates the illusion of agility and the illusion of teamwork. If you look at it from the outside, the team seems productive because every couple of weeks new tasks are completed and other tasks are collectively planned. It also seems that there is a lot of teamwork, as everyone meets all the time.”
But he says this doesn’t apply to start ups or when he has worked as a free lancer:
“The most common characteristic I see behind truly productive tech work is that the people involved prioritize building the right product above everything else. They build it in small cycles and validate it, which follows the agile philosophy, but they don’t limit themselves to a strict agile recipe. They sometimes borrow some elements of an agile recipe, but only because it helps them build the right product. For example, they have recurring meetings only if there’s a good justification for them. And, instead of letting the methodology dictate every single interaction, they hold impromptu meetings on an as-needed basis, even at five minute’s notice, all in the name of improving the product. …It seems to me that most tech companies optimize for the wrong thing. They optimize for compliance with methodologies, for the adoption of trendy technology, for having a billion-dollar valuation, and so on, but they’ve forgotten about their clients. However, thinking about clients is what makes a business successful and a team truly productive.”
If you are working in tech, we would love to hear about your experience and feedback on this article.
If you want to read our other published material, please visit https://marcellus.in/blog/
Note: The above material is neither investment research, nor financial advice. Marcellus does not seek payment for or business from this publication in any shape or form. The information provided is intended for educational purposes only. Marcellus Investment Managers is regulated by the Securities and Exchange Board of India (SEBI) and is also an FME (Non-Retail) with the International Financial Services Centres Authority (IFSCA) as a provider of Portfolio Management Services. Additionally, Marcellus is also registered with US Securities and Exchange Commission (“US SEC”) as an Investment Advisor.
