Cumulative and compounding effects are poorly perceived by us, so is our understanding of micro behaviours (not to be confused with micro-optmisation) that have impact on large outcomes. I read the following story in the book ‘You can win’ by Shiv Khera which had many short stories that stay in mind for a long time.

“A baker who is illiterate, operates a very profitable business. His hearing loss also meant that he was not aware of current affairs happening at large. The only thing he did was, bake very good different kinds of breads which was so famous in the town that a lot of people stop by to keep trying his exotic varieties; as he did good business he sent his son for higher studies. When the son joined the business he was shocked to see his father making very expensive breads and experimenting with many more types; he was shocked because he knew the economy took a downturn recently and a lot of people are going to struggle keep themselves fed. He convinced his father to bake only plain bread so that people could afford. Slowly the customers ended being disappointed that their favourite varieties are no longer available and stopped coming. The business had to shutdown as no longer customers turned up, the father tells his son you are right the economic depression is here glad that I listened to you.”

The above story is profound, how a simple technique of listening to customers and keeping them happy kept a business blooming even in tough times. Rolling up information is only possible when people acknowledge that I don’t understand everything going on but let me learn from each step or be unaware of lots of things.

This is why some of the best developers I meet always have an element of doubt when they take a new step and make sure there are many safety nets. I have seen know it all attitudes that have brought down multi million dollars programs to stand still.

This is not new so called ‘Agile’ methodology wisdom. This thought has been there for millennia as told in the Tamil proverb – அடி மேல் அடி வைத்தால் அம்மியும் நகரும் (Adi mel adi vaithal ammiyum nagarum) which means “even seemingly large & heavy stones can be moved step by step”. This was told very often by my grandparents whenever I picked up tough new lessons in school.

If you are a software engineer and want to be very productive, ditch the attitude of “know it all” or “get every thing right always”. Instead of it, approach step by step and reap the benefits that accumulate over time that are easy to roll back when things go wrong.

During summer holiday in school days, we cousins used to play around with water a lot. We used to get toy water guns, water filled balloons and use a water hose as our weapons. It was always and almost the person with the water hose hits the targets all the time. All the rest were having scarce resources and tracing the trajectory with guns and balloons was hard to hit moving targets.

Why am I talking about this, because it is the same in software development. The team with the water hose wins, this means whichever team is equipped to deliver any commit to production at will, is the one that will be able to deliver desired results and beat other teams.

So much has been talked about agile development but I have not seen it practiced in true spirit. It is usually about sprints, backlogs and masters; instead of building high performing, long running, well equipped teams.

Signs of teams that will meet business goals often and with precision

• The managers let work happen by setting direction, instead of managing work and allocation
• The teams know the financial & business impact and is able to take decisions that can help achieve it instead of decisions being top down
• Tests are first class citizens, there are safety nets at all levels from units to systems to overall, no compromise on tests
• 1, 2 & Automation. Automation is at all levels, removing any scope for repeated laborious tasks
• Power and ability to operate the production environment by the team themselves
• Well staffed and sustainable working schedule
• Equal respect for one another, no heroes or heroines.

When you are not able to lift weights at a gym, what do you do? Typically people go back, take rest, find what makes them stronger and eat that food; reduce the weights and slowly work their way up. In short people will nurture and train themselves to be better and stronger. They will not cane their hands and legs for not lifting those weights to expect a better performance.

Yet so many SDMs (Software delivery managers) prefer to use coercive power to try to make their teams perform well instead of nurturing and building a strong team. The reason being, many people treat their teams as a resource to be exploited than a team of individuals trying to solve a creative problem.

One solution to this problem is to remove the power the SDMs carry.

• Make them mere facilitators and deal makers instead of the power to review, promote and reward people.
• Distribute the powers within the team itself and keep the teams small enough to have meaningful connections and identify non-performers very quickly.
• Decision making should ultimately rely on technical abilities and feasibilities than pure ego
• Do not hire SDMs who claim that they can code but they prefer management, these are the know-all people who ruin everyone and everything!