In Remiges, I have been seeing the emergence of a community of technical leaders who have begun to talk the language of quality. You hear things like “This is not the proper way to do the code, even if you’ll get the right results.” Those of you who have built organisations will know what a milestone this is for a growing organisation. We always were fussy about quality, but the quality flag was held aloft by the top tier of the company. Now there are technical leaders at the middle level who are speaking this tongue. We are no longer a fledgling – we have taken wing.
When interviewing young engineers, I used to ask them “What, in your opinion, are the differences between good code and ordinary, mediocre code?” And I would just sit back and listen. Most officers would fall flat on their faces and not even realise how badly they’ve fared. I would hear responses like “indentation” and “files must be neat” and “comments must be there”. After five years of writing code, this would be the limit of most of their understanding of code quality. And what a delight it would be to meet the rare exception.
I now see an emergence of awareness about real quality in Remiges. Oh joy, oh glee.
But it throws up unexpected challenges. We are a projects business. We execute projects, and pressures of resources and time are a fact of life for us. The technical leadership confronts the project leadership and says “We can’t let this code pass through, it must be refactored.” The engineer in me exults to see this, and the project-management part of me gets this nasty sinking feeling – how will I meet delivery commitments? As the company grows, we need to address this conflict, without adopting the trader mentality – “if it can be palmed off, it’s good enough”. That would destroy the technical soul of Remiges and condemn us to the plebian brand position which the large software services players suffer from today.
So, what did we do? We brought the project leads and technical leads together and set some ground rules. First: all quality challenges need to be discussed and solved as a team; any adversarial stance is counter-productive. Second: if the project leader or delivery lead decides that delivery needs to happen, then it needs to happen, and even then, the tech leads are responsible for ensuring quality. In that case, how do we reconcile the conflicting pulls? Answer: the technical leadership negotiates with the delivery lead about resources, time and sequencing. Three magic words.
Sometimes, a quality problem can be fixed by diverting resources from somewhere else, or even by bringing in additional developers temporarily. This can be arranged by the delivery lead if the technical leads clearly define what they need and build a strong case. But for this, they need to collaborate, and the tech leads need to be articulate. Sometimes, we get poor soft skills in the tech lead, and all that the PM gets to hear is “This can’t be done.”
Time may be bought too. If the delivery lead goes back to the client and asks for a bit of extra time for the milestones, it’s surprising how flexible many clients will be. Once they realise that this delay is getting them better quality and if they trust the delivery leader, one may be able to buy time. This requires the PM to nurture a certain credibility with the client, sometimes go out of his way to accommodate some strange requests from the client to get them (the client) out of a tight spot, etc. The subtle art of negotiating is rarely transactional.
And finally, there are often opportunities to change the delivery sequence. We have a problem in the XYZ module, can we deliver that module a week later, and the rest now? This sort of juggling is again in the hands of the delivery lead. But this too needs clarity and excellent communication between the tech leads and the PM. It is the PM who knows which precise sub-module the client will need in two weeks, which others can come later. She needs to bring this insight to the discussion with the tech leads, and see if the tech lead can do a better job if he is given the freedom to postpone some sub-modules. The tech lead on his part must figure out how he can get his team to deliver good quality rapidly if some sub-modules are taken out of the game for now — this may sometimes require writing some tiny amounts of throwaway code. So, all in all, wonders can be achieved if the dialogue flows smoothly and PM and tech leads can work as friends.
We crossed a milestone in Remiges when we began to see our tech leads putting their foot down on quality, owning the quality space. But we then realised that we needed to introduce a new collaborative playbook to keep the delivery pipeline flowing. In our business, delivery is like oxygen – it ensures life. But quality is our identity – it tells us who we are
Leave a Reply