Just Let Me Code

The gentleman across from me was a good dozen years behind me on the trajectory of life as a software engineer. His demeanor and body language were as I would have expected from myself when I was at his stage. Even though he was trying hard to be friendly, it was clear that he regarded me as one of those who had never been a developer or didn’t like being one and had quickly ejected and joined the management ranks. The answers were cordial, but mostly monosyllables, and rarely if ever did they consist of anything other than simple sentences.

I was in the 17th year of my professional career and had built myself the confidence and reputation that had landed me my first assignment that I could officially classify as a project rescue. The problem had been presented to me as a classic failed release. The developers had failed to meet the requirements, the code was of poor quality and buggy and the users had jammed the phone lines complaining about how the software was making it impossible to do their work. Management had taken the standard steps. They had attended the escalation meetings, expressed their righteous indignation, empathized with the customer, had removed the most senior developer from the team, and as a final gesture of their commitments to make a difference they had promised to bring in someone with a track record of good delivery to fix the situation. Which is where I guess I made my entry. There was a small problem though. I didn’t have a track record of success, just a series of small failures that I fixed before they were noticed and rarely repeated. I had no idea of how to fix something that had fallen off the rails so badly. Somebody suggested that I talk to all the stakeholders and understand their perspectives. Which is what I was doing in one-on-one meetings with the various team members and what had brought me to this seemingly futile conversation.

The conversation with the rest of his teammates had been very different. They were a lot more senior than our current protagonist, and their experience and wisdom shone through everything they said. The customer was clueless and completely disconnected from the users. The technology decisions made by the architect were flawed. They also had advice for each other, although it was not clear why those ideas had not been implemented. There were a lot of issues with the methodology. One person thought that the sprints were too long, another that they were too short. One lamented the lack of retrospectives while another said that they provided no value because everyone was seasoned and professional and there wasn’t much scope for improvement. The team was clearly being forced to commit beyond their capacity, and that was causing low output and poor code quality. They had asked for additional help but the developer that had showed up to add to their capacity was too inexperienced and was very difficult to work with. He just didn’t understand how teams worked and had clearly not done Agile before.

In the hope of closing out the conversation with our current protagonist on a professional note I asked him, in what must have been quite perfunctory way, “What can I do to help you ?”

“Just let me code”, said our protagonist, before we thanked each other and walked away.

The current Sprint was just a couple of days from its close so there wasn’t much to do by way of change. The release was small and painful, but it did go out on time. The users weren’t thrilled but they were less angry. After the release was completed I went over the code check-ins and found to my utter surprise that the only code that had made it to production was authored by our difficult protagonist. For all the wisdom and experience of his senior colleagues none of them had contributed to anything on this release. Over the next few sprints, the team turned things around and came to be identified with high performance. The senior developers, surprisingly, opted out of the team, and even though they were replaced by folks with much less experience and wisdom, the team’s reputation of one that magically always met business outcomes, continued to grow. The team of developers seemed to enjoy connecting with the users, understanding their needs and improving the software to do more and more for them. The users got what they needed most before they needed it, and were willing to lean in as well, and be more forgiving than in the past.

Shortly after this project ended, I went on another assignment where the biggest challenge was an emerging technology that had very few experts on the planet. I duly identified the lack of an expert as the principal risk on the project. Unfortunately, those expert unicorns were backordered and not likely to appear in time to make difference. I reached out to our protagonist and asked if he would lead the team of developers on this project. It turned out that our protagonist would be the developer with the least experience add tenure on this team. It defied conventional wisdom and my decision was questioned by management, for good reasons. After all, I was questioning my own decision. The absence of expertise is a great leveler. When there are no experts, everyone has access to the same artifacts – technical documentation, process documentation, cookbooks, DIY videos on YouTube, are all such artifacts. The difference in outcome results from how different people approach these artifacts. If our basic assumption is that something was not possible, we can prove that assumption using these artifacts. If our basic assumption is that it is worth trying, we will use the same artifacts to find a way to do so.

Our protagonist loved to build stuff – code was his medium, but like all engineers, he loved to build stuff. My belief was that in their ardent desire to build this solution the team under the right leader will use all artifacts at its disposal to find a way. True enough, the team lived up to my belief. The project was delivered on time and within budget. The customer who had envisioned the solution received an award and was promoted. At the end of the day, the experts didn’t matter because there were none. The technical documentation that the team used didn’t make a difference because anyone and everyone had access to them. It was the team of people who love to build and who were inspired to do so that did.

The two anecdotes above helped formulate what had been latent in me for a long time – the value of the builder and their ability to build. It was why I had decided to be an engineer when I was in the 5th grade. It was why I chose to study computer science in college before it became fashionable. It was why I got goosebumps watching oxygen being blown into molten iron at the command of code that I had written. Observing our protagonist, who had a very similar professional profile, only a decade behind me in the graph of time, did I understand that it was only the builder and the building that mattered. That engineers, when afforded the opportunity to work with the users build high quality tools at a high speed.

That was in 2009. Over these ten years, I have continued to work with our protagonist, and many like him. In 2011, I was able to convince some influential executives in our company to allow me to set up what we called a solution center for our public sector customers in the Washington, DC area, where they could come and participate in the building of software solutions for themselves. Our financial targets were modest to begin with, but we exceeded them several fold in the first year and we continued to double our financial results, year over year. Very soon, we were working with customers spread across the entire United States and a few overseas. What might be interesting is that we did not even consider our financial results as a measure of success. We measured success by the number of successful releases of useful working software that we put in the hands of our customers. Our organization was small – I never exceeded 24 direct reports, and our delivery teams were lean. Our customers were amazed at how quickly we could build solutions for them. One customer once said that we built working software in half the time their other team would produce a requirements document. What was truly gratifying for us was watching our users react to what we had built. Our users were people that served us every day – often men and women in some kind of uniform – doctors, nurses, soldiers, firefighters, police officers, conservancy workers – and it was easy to connect how our code was making a difference.

Our organization’s scope was extended to include all enterprise customers around the world. There were some serious doubts as to whether what we did in the United States specifically in one industry could be replicated around the world. Those doubts turned out to be completely unfounded. We ended up working in 24 countries across six continents, in practically every major industry segment. Our team embodied every conventional dimension of diversity, yet we found people of our mindset around the world. Parallelly, we also produced artifacts in the form of process documentation and trainings that allowed others to do what we did.

Our organization’s success reflected on us too. My greatest achievement was to be able to shake hands and share a meal with one of the greatest corporate leaders of our times. I got the content and the confidence to be a keynote speaker at a regional-level event for PMI. Our protagonist went thru rapid promotions and emerged not only as one of the youngest technical directors in one of the world’s largest software companies, an achievement that seems to have eluded the senior developers on his first project.

My own role has evolved to where I find myself discussing software delivery strategy and methodology with stalwarts of the IT services industry as my day job. Conversations almost always veer towards the need for more governance and oversight. Project managers and architects want to discuss tools, processes and roles that would help improve governance and oversight of the so-called resources, very often developers.

I must say that I disappoint many of these stalwarts. I am not aware of any tool, process or methodology, let alone any wizards that build great software. Many of the stalwarts feel that I am either holding back on sharing wisdom – “you could do a better job documenting the methodology”, or feel that I am an impostor who just got lucky – “I see, so what do you do exactly?”

However, they miss a key point. Governance and oversight may lend relevance to project managers and other so-called leaders, but at the end of the day, they are not the ones who build anything. The protagonists in the software delivery story are the developers, and not the project managers and architects. Tools and processes and roles that do not directly support the builders, do not also support the building. At the end of the day, the true heroes in the business of building software are the developers. As leaders, all we have to wield are tools, processes and roles in ways that provide the help that millions of developers like our protagonist asked for: “Just let me code.”