My advice to other CIOs is to consider older engineers and developers who will add enormous value to the companies they work for
This is an exclusive interview conducted by the Editor Team of CIO news with Subash Warrier, a developer and ex-CTO serving large MNCs
I am a 61-year-old veteran of the industry. During my long career, mostly in India and the USA, I have worn many hats. These include developers, software engineers, managers, architects, principal architects, principal engineers, CTOs, CEOs, entrepreneurs, etc. I executed these with varying degrees of success. However, the job that gave me the most satisfaction was that of a developer. The almost childlike glee that you get when you see a programme running correctly and giving value to a customer is incomparable. Nothing can beat it. Therefore, when I started my last innings in the software industry, I decided I would do what I love and where I felt I had added the greatest value, which is developing code.
After my stints in engineering roles earlier, I found that from about 2008 to 2015 I was developing code, but mostly for prototyping and explaining to other developers and managers what they ought to do. It was satisfying, but not enough. Prototypes are often used and thrown away, and they end up like a school science project. I wanted more, which was to unlock the value of the prototype for a customer. This calls for participating in a full release cycle. Also, when you develop prototypes, you have total freedom in choosing the toolset and stack, which tends to box you into a technology stack you are most comfortable with. As time progresses, the technology stack becomes a self-serving silo, which works as a detriment to your progression as a developer. These were the first set of lessons I internalised, which is not to be afraid to learn new stuff at an advanced age, which is often difficult. I learned NodeJS and started programming in it about 6 months ago, and I can say with undisguised satisfaction that I am better than most and that my code tends to be more complete and less error-prone.
This journey of the last 8 years was not without pain. The first task I took up in trying to reinvent myself as a developer was in Python. I did not do too well there despite putting in a lot of dedicated and focused hard work. I could easily figure out what to do but had difficulty figuring out how to do it. This was in direct contrast to when I started my career, when the situation was reversed. I knew how to do it, but not what to do. Moreover, the mistake I made was trying to use the tooling the other developers were using, thinking that was the “cool” thing to do. Not using the tools I was comfortable with dissipated a lot of my efforts. My code often turned out to be buggy, and for the first time in my life, I had to suffer the ignominy of a pay cut because my contributions did not match the compensation I was drawing. In my next role, I was in a leadership role. Here, I just stuck to the toolset I was comfortable with, and the results were outstanding. I delivered all I was tasked with doing and more. I created path-breaking technology that integrated NLP, IoT, and messaging. It generated a lot of eyeballs, but COVID got in the way of generating enough business. But in retrospect, the IOT hardware was not good enough for prime time. If COVID had not happened, I may have had some more cash to improve the IOT hardware. But that was not to be. My learning here was to stick to the realm of technology, where I had a body of work. This is much like a cubist trying to become an impressionist and discovering that it takes a long time to learn to think like an impressionist. Although I knew hardware well enough to use it in designs, debugging it and making it production-worthy was difficult because I had never practised the skills I needed in a professional setting in my career. I surmised later that this is a pitfall of leadership. Often, a leader is not the best judge of what the team can deliver. After this stint, I did several short-term contracts that were mostly successful, and I delivered as per expectations. These were for companies outside India too. I started to hanker for a long-term contract for at least a year or so. This did land. I will talk about this experience in the next paragraph.
I am currently working for a US-based MNC that has a development centre in Bengaluru on an 18-month contract. I must unreservedly thank the company because they took a leap of faith in bringing me on board. This is because the hiring manager(s) there constructed interviews that were perfect for me. One of the things I found along the way is that a traditional skills-based interview, which is often what a developer goes through, was difficult for me to clear. This is because the older you get, the more you tend to rely on carefully crafted instincts and judgement and not on the technicalities of software development. This is much like an older cricket batsman figuring out what the bowler is attempting to do rather than solely relying on technique and reflexes. It’s this judgement, rather than pure skills, that becomes his mantra for success. The interviews I went through before being selected for this company were focused more on my judgement than on what I knew. When I started working for them, I found that something was new in this stint, which was that I had to work with peers, which I had not done in a while. I often felt lost when it occurred to me that I was unable to make the mental adjustment, and I almost got thrown out. However, at the right time, I figured out the way forward, which is that I must compete for my spot on the team. This was what I used to do when I was a developer starting out in software development. When I started to compete, everything fell into place. The company and my immediate manager started respecting me for what I brought to the table. I delivered two releases for them. Of course, the product is not where I want it to be, but in another couple of releases, it will get there. However, let me warn the readers. Competing has its pitfalls. It leads to ambition, and then that brings its frustrations and disappointments. One needs to be mindful of that. But overall, I am happy that I was able to make the mental adjustments to deliver substantial value to this company and earn respect.
My advice to other CIOs is to consider older engineers and developers who will add enormous value to the companies they work for. A lot of individuals like me have the desire to contribute to companies with our skills and compete with the best developers. We understand how to derive what to do and how to do it as well. We understand markets and business processes, which will help you all. We will have insights on all of these, which will come to you for free if you choose to hire developers of our ilk. In a software work environment, we talk about all kinds of diversity. Diversity also implies writing software for older people. This is because we have a generation who has used software technology all their lives, mostly in self-service mode, and who knows what software works for them. This tribe will only increase. You ought to consider developing software features that do not exclude older individuals who want to use self-help. Therefore, I make a humble request: in your product plans, do consider the views of people like yours truly, particularly since I can also build it. This is particularly true in the following areas:
- Fintech
- Healthcare
- Automation
- Mobility
Also read: Automate People and Process Management with greytHR
Do Follow: CIO News LinkedIn Account | CIO News Facebook | CIO News Youtube | CIO News Twitter
About us:
CIO News, a proprietary of Mercadeo, produces award-winning content and resources for IT leaders across any industry through print articles and recorded video interviews on topics in the technology sector such as Digital Transformation, Artificial Intelligence (AI), Machine Learning (ML), Cloud, Robotics, Cyber-security, Data, Analytics, SOC, SASE, among other technology topics
