Recently we did some renovation at home which involved buying a few big ticket items. As I had read a lot about supporting local vendors, I drove to the stores after doing some browsing online on big marketplaces for options.
My first reaction on the purchase experience was the level of willingness to negotiate an offer when the bill is running close to a lakh. Every shopkeeper wanted to keep the conversation on the MRP, declining to accept credit cards or were trying to pile on more charges like delivery, installation etc when preparing the bill. In all, the transparency was poor and the mindset to extract as much as possible from a lead was set in stone.
The same I had observed from a medical store nearby, with aged people at home; the maintenance medicines for a healthy life add to substantial costs, so I tried asking the store keeper that I will place order with them month on month but let us work out a deal because the big medical chains give me 20% and I am willing to take a cut for convenience. The shop keeper flatly declined saying that he does not do business less than MRP and I can continue to shop at the retail chains, he does not need my business.
Why is this happening? We perceive a loss to be greater than a profit of same magnitude. Winning a gold coin may not be equal in magnitude of happiness compared to the sorrow of losing a gold coin. That is what is at play at the small vendors. They do not see the overall profit gained in the transaction instead they read the money lost on the transactions that could happen on MRP. This clouds the judgement even if this can tun into a repeat business with a steady cash flow.
On browsing more for stores, finally I found places that gave a good deal even bettering online deals. These were businesspeople who are in the same business for generations even though their turnovers were small, looks like the family wisdom is passed on as a trade secret and I ended up noting their numbers to give to friends who will have similar needs.
Even people who run a kitchen everyday underrate waking up to a clean one and often leave the dirty dishes in the sink and leave the counters unclean. This clutter over the course of the days will bring two major issues. It will lead to tiring because of cleaning up first on waking up even before a coffee and the other which causes the fatigue in the long run due to the cycle of clutter and improper cleaning. When you enter the kitchen, you should be able to make your breakfast or coffee just right away instead of cleaning the kitchen and washing the dirty dishes. I also some time ago, wrote about parallels in running a kitchen and programming.
What if the cook wants to keep the kitchen clean but work piles up so much that they have to leave a wave of mess behind to achieve the dishes of that day. It happens once in a while during feasts and festivals, which is often followed by cleaning up the mess and cooking a little light next day. As a routine, it is always best to clean up the counters, rearrange the utensils and clear up the dirty sink before going to bed every night. Waking up to a clean kitchen is something that has a cascading effect on the peace of mind because a day always starts good. So one cannot plan feast after feast without resetting the state of the kitchen.
This is what you will hear from Software developers, they are never allowed to prioritise to keep their code clean, they are made to pile on tech and architectural debt to prepare for release after release. Developers end up starting on a back foot and will be inclined to add more mess to the existing pile. I like the idea of how Basecamp has a cycle of big and small batches, this gives enough leeway to the tech team to prioritise between features, bugs and debts and keep a healthy momentum going.
Waking up to a clean code is also an underrated feeling, but it will leave a great positive impact on the team that lives in the code.
I was speaking to a tech lead who was inspired by Dan Pink’s drive and motivation video. This person was speaking great lengths about how to motivate team members, how to set them goals etc and also went on to say that only if this person’s managers showed same consideration and handover more autonomy, then there are so many more things that can be done.
Below is the link for the nice presentation by Dan Pink, about his work on Drive
I asked a few questions to understand what kind of autonomy was working for this tech lead. The team size was around 8 with a mix of Developers, QA and BA. The team members were given a free hand on when to take a day off, go on vacation, flexible timings etc. The flexibility in working and taking a time off is not directly related to autonomy so I asked my favourite question next.
Given your team size is small, what is your version control process? The answer was that everyone works on their own branches, they will then raise a pull request to the tech lead, the tech lead will review the piece of work, some back and forth happens before it can be merged to the master. The tech lead controls the merge to master and it is a privilege to commit to master.
Where is the autonomy in this process? Code for developers is like a habitat, they should feel connected and own the place they are considering it as their habitat. By putting a very strong gated process that too in a small team is removing the autonomy away from the members. Will members be connected and own the code they are developing or is it just that they are following their tech lead says?
Then the question arises on ‘how to ensure quality’; in our teams we never gate someone’s commits as a merge request/pull request is not the only safety check we have in place. We have a huddle every morning and people demonstrate what they have coded & committed to main along with any observations they have on other’s code. This is repeated every day and this mob review works a lot better than a gating PR review because the learning as a group is much stronger and less hierarchical. This activity also enforces the collective ownership and every individual takes up the challenge of living upto the expectations. The only catch is, it has to be moderated well in the initial days before the new found inertia can take over and run without the chaperone.
I started following this style after reading the chapter “Habitability and Piecemeal Growth” in the book Patterns of software architecture by Richard Gabriel. Autonomy is not just about working from home, flexible timings or casual holidays, it is about the ability to own things at grass roots level.