Posts

by on

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!

by on

The biggest killer of developer time is meetings, it is a double whammy when it is run by people who do not know how to run it or how to finish it. So often a meeting eats up as much as the 25% of day without adding benefit to any of the attendees.

Image courtesy: Unsplash

Developers cannot spend time in 30 minute slots like non developers. It takes some time to get into the groove and let the mind feel the code as if it is the extension of the natural language. 3 hours of unbroken developer time is the golden rule for me, it does not matter if I am coding, writing something or just starting out of the window thinking about something. The biggest killer of my productivity is when people pull me out of my zone for status checks during the middle of the coding session.

Also too often the planned meetings are more of information gathering sessions for the highest placed person in the corporate ladder. Any agenda or plans are thrown out of the window when the first question comes from a leader. These meetings scheduled for about 30 minutes will get converted to rants, status checks, random questions, fears and more that drags on and on to go well into 90+ minutes.

The best way to run meetings is to

  • Set agenda & time window (Make sure attendees are prepared, if it is a status check it is best done at the start or the end of the day)
  • A facilitator who can keep time and moderate conversations if that goes away from the agenda
  • A parking lot to make sure to capture random thoughts that can easily derail a meeting

Any one I have spoken to, agrees to the above points, but fails to keep the meeting in check because it is mostly run by non developers who don’t mind those additional 30 or 60 minutes getting wasted; or they just keep quiet and stay on so that the seniors are not offended.

If you are a manager and have a development team, please give unbroken chunks of time to developers and learn to run precise status checks and meetings without draining the energy that can otherwise be put into solving problems.

p.s: Design discussions and dev huddles do not follow in the above category but they also need to be facilitated well by the tech lead.

by on

In the last few years I see an overall increase in the busyness of people around in all professions. Everyone keeps telling about how busy they are; always behind tight deadlines and impossible to pursue goals yet they are able to somehow get things done. Managements usually set difficult to achieve deadlines, tightly control budgets, non negotiable scope of work and leave quality as the only leverage for the ground level people.

Dirty fixes and ill fitting designs are the norm

So people end up kludging together things to make ends meet. One of the dictionary meanings of ‘kludge’ is ‘a machine, system, or program that has been badly put together, especially a clumsy but temporarily effective solution to a particular fault or problem.’ I came across this term when reading this article. Kludge appears everywhere and it looks like a clever hack.

Sending that boolean variable named ‘donotTouchThisFlag’ through multiple layers of code and systems to bring up a new feature effectively cuts the time down by several hours that should have been spent in redesign. An engineer doing this for an aeroplane is beginning to get away from these blatant engineering blunders and instead gets praised for quick delivery of features and leave the headache to the technical support team to handle.

People have no other option than to succumb to this vicious cycle of too much pressure and low quality work. If they don’t fit in, they get kicked out. What is the leverage then? It is very hard to find leverage when people are bossing around in multiple layers, I kind of miss the unions of the yesteryears in many disciplines who demanded the right conditions, pay and working hours.

Good design and quality work can never come from pressure, if an output comes out of extremely forced timeline and budget then chances are high that failure follows suit. Sadly the manager gets rewarded for timely delivery and the engineer gets the stick for poor quality.