Recently I have seen a lot of leaders put up policies on their linkedin walls saying they respect sane working hours, weekend holidays, encouraging personal time off and many more. This is a case of giving back what was taken from others but disguised as a perk. Working late and on the weekends had been baked into as a given thing for a lot of leaders. It gets equated to more effort which was presumed to end up in more productivity.

The mindset is infectious, a person who comes into the workforce gets subjected to late working hours and weekend work, it becomes imbibed into their minds and they repeat for other new comers. The idea continued to grow stronger by Lindy effect, with people promoting workaholics and thereby creating more workaholics.

There is a change in workforce dynamics. Two decades ago, knowledge work boom brought in jobs that elevated the standards of living. The upgrade in lifestyle was so big that people were ready to do what was asked at the workplace. Leaders who were used to manufacturing mindset jumped on the opportunity and took it towards a downward spiral. Eventually people who worked insanely long hours and weekends were seen as committed irrespective of the outcome they bring.

What changed now is the workforce that is entering the market, a good chunk of the workforce has a pretty decent standard of living and what they look for is quality of life. The long working hours immediately removes the quality of life aspect and hence a lot of leaders are scrambling to understand how to improve productivity without stretching the people.

It was never fruitful to prolong the working hours to get more done in a knowledge work situation, yet a lot of leaders held on to that opinion strongly and rewarded hustle culture. Now that there is not much option to hold on to the hours of working, people are forced to return what was never theirs and look for different ways to engage and improve effectiveness.

In the software world, focussing on developer experience will attract and retain talent while helping achieve goals in a sane and sustainable pace. This involves balancing standardisation vs freehand, homogenous vs fragmented tech, governed vs federated ownership along with information symmetry and clean communication.

We would have read the story of ‘The conditioned elephant’ where a fully grown up elephant is tied using a small rope but it never tries to break free as it was conditioned as a kid that it cannot break a rope. We humans are also trapped with those constraints that we learned to become helpless. I have some stories during my journey.

When I started to program, access to computers were very limited. I have to write my program in paper, verify it a few times, get it reviewed on paper before getting system time and trying how mine works. Even my first few job interviews, I wrote the programs on paper and my interviewer went through the input and output manually before pursuing my candidature to solve tougher problems using a computer.

What this meant was I learnt the language fundamentals well, I understood many gotchas on the syntax and often I can write 100s of lines without syntax/compilation errors, without referring to any manuals or help articles. My behaviour continued even when I had my own system full time along with internet access. I spent a lot of time understanding in detail before I would claim myself proficient in a specific language or a tool and also refused to use IDE.

Barring a few occasional WOWs, I was slowly slipping into struggle like “The boiling frog“; observed in an experiment that a very gradual raise in temperature can kill a frog without it realising that it is being boiled. My years of conditioning with poor hardware and no internet meant I had to get a fair degree expertise before I could code professionally. While it is a good thing that something forces you to master a topic, the bad thing about this is I learnt to have a delayed feedback about trying new things out. When it came to experiment I used to lag behind as I was more inclined to deep dive instead of fail fast.

Every time someone whom I know coaxes me into changing my ways of working, I was held back by IT policy of “not upgrading the machines until they fail”. For a few years my machines at work never supported anything beyond a simple text editor which reinforced my older ways of working. It was only after an upgrade (I bought my own laptop), I realised the joy of programming in an IDE. For the first time TDD was a breeze and I fell in love with that method but not before wasting a few years in an outdated style.

Every few years information, hardware, connectivity, software is becoming more accessible. It is churning up faster than we can sense and adapt to the new landscape around us. We are often caught up like boiling frogs and stick to our trusted and tried methods at work until a jolt comes externally. New year beginning is always a good time to identify what constraints are we victim to and do they really exist? Every year I keep finding things that are outdated in my style of working and upgrade them. It is not just limited to workplace, it is in every aspect of life. Try finding out, what constraints are holding us back and do they exist?

There are different kinds of sports when you classify on how do you train people for the sport. There are one shot sports like archery, athletics with a single focussed task on winning. Then there are individual multi shot sports and team sports.

Mental and Physical fitness is a pre-requisite for any sport for we will not talk much about it; eating, exercising and sleeping well will be part of any training. For majority of the one short sports the line is blurred between drills, practices and performances. You don’t want the players to think in a one shot game, they have to behave as trained by the coach. For years they will be doing things that will help them in just one thing, to take the best shot at their sport every time they hit the track.

The training changes from when moving from one shot to multi shot sports. Sports were individuals compete against another head to head falls in this category. Here the difference starts to arrive between drills, practice and performance. Drills for a tennis player is to work on weak areas and improvise on certain shots until it becomes muscle memory, practice is to have a fun game with another athlete to practice the shots and learn in a match setting. If we note that practice matches without drills will not help a tennis player get stronger with their shots and having drills alone without practice will not help them win matches.

Then the added layer of complexity for team sports where you need drills & practices for sure but there has to be a game plan that is a shared understanding among all the players, camaraderie within the team, post match analysis. The method of training a sportsperson for one shot sports won’t work in a multi shot team sport setting.

If we draw parallels to software development, it falls close to the team sports category. Yet a lot of executives design the environment to groom people for one shot sports. Many of the developer training lessons concentrate on development as if all three drills, practice and performance are all the same and the more someone keeps doing the more experienced they get.

Drills in software development are activities like code katas and architectural katas, Game plans are activities like planning meetings and retrospectives, Practice matches are activities like group refactoring/coding sessions and hackathons; also not to forget to educate software engineers to take care of the most neglected part which is their fitness. Many of the executives I had interacted with sadly neglect all these aspects and are worried only about the delivery part of software engineering. Engineering’s effectiveness comes only when the skills are improved using all the types of activities not just exposure to development and production problems.