#7 - Continuous Delivery and Secrets of Consulting - Sriram Narayanan

Episode Introduction [00:01:32]

Henry Suryawirawan: Hey everyone. Welcome to a new episode of the Tech Lead Journal with me your host, Henry Suryawirawan. Do you know that Tech Lead Journal provide comprehensive episode show notes on its website at techleadjournal.dev? Unlike majority of podcasts available out there, Tech Lead Journal provides full transcript that you can use to follow the discussion, or even search favorite parts of the conversation that you would like to go back to for deeper understanding. The show notes page also provides interesting quotes that I personally curate, and also the list of links and resources that are mentioned throughout the conversation. And if you’re like me who listen to podcasts when doing exercise or other activities, and frequently find it challenging to remember the important parts of the conversation, do check out the episode show notes page on the Tech Lead Journal website at techleadjournal.dev. It is my mission to provide the best possible medium for all of you to consume the podcast content. And I would love to hear from you if you have a good story on how you are benefiting from the show notes page.

For today’s episode, and this is so far the longest episode that I have on the podcast, I’m very, very happy to share my conversation with Sriram Narayanan, or Ram for short. I consider Ram as one of my go-to mentors, and I always love hearing him talking and sharing his insights on many things that he has interest in.

Ram is a Principal Consultant at ThoughtWorks Singapore, helping customers on their journey to Continuous Delivery. Ram likes to explain things in a deep way, touching the fundamental principles of the topic, and utilizing interesting anecdotes from his vast experience, and you can find those a lot throughout this conversation. Every time I have this kind of conversation with him, I always learn a lot and I hope all of you can learn a lot from this as well.

In this episode, we discussed in depth about what Continuous Delivery is, including several important concepts in the DevOps world, such as Testing Pyramid, Value Stream Map, and Segregation of Duty. Ram also gave his valuable tips on how to become a successful consultant and how to manage client stakeholders well. We also touched on a few fun discussions on how one should keep up with the rapid changes in technology, and also deal with a plethora of industry buzzwords. And you do not want to miss the insightful archery analogy anecdote in our conversation.

And before you start listening, I would suggest you to find a quiet place, clear your mind, and probably get some coffee to enjoy this episode. Let me know how you like the conversation and don’t forget to subscribe to Tech Lead Journal, if you haven’t.

Introduction [00:04:40]

Henry Suryawirawan: Hey everyone, today I’m very excited to meet one of my mentors in my career. So I met Sriram Narayanan in ThoughtWorks. Ram is one of the thought leaders in the industry, around Continuous Delivery, Agile, DevOps. And today, I’m excited again to be able to be speaking with him, discussing about things that he’s passionate about, and also hopefully he can leave some of the wisdom and gist of his career that we all can learn and apply for our career as well. So without further ado, welcome Ram.

Sriram Narayanan: [00:05:11] Hello, Henry. Thank you very much for the kind words.

Earlier Career and ThoughtWorks Journey [00:05:14]

Henry Suryawirawan: [00:05:14] So Ram , looking at your career, I must say that I’m pretty stunned in terms of your progression from your 14, 15 years, journey in ThoughtWorks. You gradually shift from like being a junior developer, up to a Principal Consultant, up to now, considered one of the thought leaders within the region. Can you probably share with us, what’s your journey like and what are the major turning points in your career that could be shared with all of us here?

Sriram Narayanan: [00:05:39] Thank you, Henry for the generous praise. The truth is, I’ve been really fortunate. I’ve been very fortunate to have had the right kind of mentors and support in my journey at ThoughtWorks. And to tell you even before that. I have come to realize that there is always something to learn from everybody around us. And I can tell you, often I’m the stupidest person in the room. I’ve not gone through all of that much of a formal education for family reasons, and, you know, I started to work rather early in life. Maybe in retrospect, I would say like Steve Jobs said connect the dots. In my case, that helped a lot, you know. At an early age, around 15.5 to 16, I had to go start partly my own businesses, partly work for other people. And when you’ve just kind of finished school and you start doing things like that, it changes your exposure to the world. You don’t really get the chance to grow up with other teenagers as they go through college, but life becomes way more serious where it’s a revenue earning requirement on a day to day basis, you know. Especially when you’re that young, you’re not going to be a high flying consultant with a fixed guaranteed minimum salary a month, right. These are all the small jobs or jobs that you get to do and which you have to do for survival. I would say in many ways, the mentoring that I received at that time, just general life skills, the opportunity, and the exposure to businessmen and who would freely share with me what their strategy is, and then make me be part of it as they execute and make money. When you’re really young, people don’t mind sharing a lot of things with you, right? Because to them, you’re not really a threat. But then you get very good insights into how people make money, and then that motivated me to starting my own businesses. Due to the economic downturn in the very late 1999, I stopped my various businesses. I used to run computer training institutes and invoice customers and sell PCs. I even had my own aquarium fish business. I’ve done a variety of things like that, you know, some things related to IT, some not.

I had to shut it all down and go and become an employee full time employee yet again. That time I got the chance to work with very good Smalltalkers. It’s to my regret that I did not become very, very good at Smalltalk. But I got to learn object oriented design, from some of the best Smalltalkers in the world. We’re talking about people who are architects of things like Visual Age Smalltalk , amazing object oriented design principles for UI. Really really good people. So that got me through understanding - what does it take to deliver? Then I had to, you know, again economic downturn yet again, we had to cater to the India markets, till then we were catering to the global markets. Then I had to again, you know, learn what does it mean to go make a cold call to a customer and tell them we have very good skilled software professionals. “Is there some problem for you that we can solve?” That one sentence, which is “identifying what is the problem that the customer has and can I fulfill that” - that lesson, it took me a few weeks to get to, but when I did, my life has changed since then.

Again, life happened and I got a chance to start working at ThoughtWorks. My interview was good. It was an interesting interview. At that time, I felt it a bit not so great, because I came from a very small town, very small company, and these were people who were used to working with a global pool of very, very skilled developers with the famed ThoughtWorks software development network. And they have full international exposure. So the kind of problems that I used to solve and they used to solve were very different. So, for example in my interview, there was a mild amount of hostility at one point even, where one of the guys said, “Hey, you know, we don’t believe in just sitting and creating all these frameworks. We solve actual problems.” Which was correct, because at that time there were all these large, massive framework-y companies who just keep churning code after code after code and not really show any value. But ThoughtWorks being very agile was all about showing value, right from day one. I had not really understood that that is what they are doing, which is what I was also doing. Because when you’re really a small company, you don’t have the luxury of resting on your brand, but I didn’t understand it then, my immaturity. So I routed it back to them that “have you written servlets, have you used Spring?” Then they said, “yeah”. I said, “yeah, people like me write stuff, which people like you use.” It was very arrogant and you know, a slap back from me to them. I’m sharing this, just to say that when one is immature or one has not really understood the other person’s position, from both the sides, when you don’t understand each other’s positions, things can go very bad, very, very rapidly.

However, they did take to their credit, who, you know, both my colleagues, they later became my colleagues - I became their colleague. To their credit, they actually probed a bit saying, “what do you mean?” And I went on to talk a lot of innards of Tomcat, and how servlets work and what does it take to do JSP generation and whatnot. And we dove into, a bit of deeper technical stuff over there. It actually went right. And my final interview was also really really good. Ajey, Ajey Gore who you know. Ajey and another colleague called Vishy were my final interviewers. Very very pragmatic business questions. Ajey when he heard that I enjoyed COM programming with Visual Basic. Whoa. He deep dived into it. And I really enjoyed those things with them, you know, discussing TLDs and interfaces. And what does it take to align code in memory. Woah that’s when I said, “Alright, if I have very good tech colleagues like this, this is a place I want to work at.” So I joined ThoughtWorks that way. Yeah. That’s around 14.5 to 15 years ago by now.

Henry, there’s a very interesting thing you asked right, about my journey from being a developer all the way to principal consultant There’s another very good colleague of ours at ThoughtWorks. You know him Henry. Sriram Narayan, right? The same name as me and a very similar surname to mine. And he tells me that it’s just a clerical error - because of it, just different. Otherwise we actually have the same surname. So this Sriram, who early he was my mentor, then he still is my mentor and buddy and all of it. He identified very soon enough that I come from a small company and I don’t understand all these large companies setups. ThoughtWorks was just 120 people at that time. But for me, it was large, coming from a 6 person group. So he taught me that a consultant can influence the story card when they are pairing with another person. A senior consultant is usually one who can influence the team in terms of feature or story directions without needing the supervision of a tech lead, right. They end up becoming de-facto tech leads. A lead consultant, which is the next in hierarchy at ThoughtWorks, is a person who should be able to influence the client. And very often, the whole delivery hinges on the lead consultant. They also end up becoming the officially appointed tech leads, in case the client requires such a designation. And principal consultants of course, should be able to influence the entire program and ideally the entire industry. So, he explained this to me and it gave me a very nice set of things to, you know, look forward to, capabilities to build, aspire and to even engage myself. Does the company offer me a promotion, just because I’ve spent certain tenure here? Does the company owe a promotion, just because I’ve helped, you know, in certain engagements? Or am I already performing at that level, but it’s just very naturally said, “Here you go, Ram, here’s your promotion. You are now hereby so and so.” Very very very insightful thing and it really set the direction for me.

I would also say that in the middle of all this, briefly I was weak in between and you know, I had a two year campaign to asking the company, “Why am I not yet a principle consultant? Have I not influenced this? Have I not done that?” And then I decided I will just drop it because it was eating into my mental bandwidth. And I was actually getting to learn a whole lot more directly working with clients. And indeed this is what, now when junior ThoughtWorkers ask me, “Hey Ram, how do I get promoted, what should I do this, that.” I’ll be very candid and say, half the time they’re asking, “Is there any system to game?” Honestly, there might be. I don’t know, because I’ve not wasted my time trying to see if there’s a system to game. I can tell you that the influencing activities and this and that. It will help you get promoted. Okay. You may know all the right people to, you know, suck up to, and appease and all of it. But that’ll take you only so far. Your reputation becomes hollow. When you have to hit the ground running, you won’t be able to, because you never were of that calibre. So I just gave up on all these designations and hierarchies, because I had got the chance to work with Rackspace in the US and then there was this other insurance company, certain banks. I got exposure to work with them and do a whole lot of stuff right there, entrusted with millions of dollars of revenue and even calendars of months at stake when time is money. So that exposure already took me to quite some level. I no longer ran after designations. Like I said, I was weak in between. I did none after it. Then I gave up. And then I was just promoted to the so-called principal consultant. What I would say is the larger reward for me is not a designation. I tell you it means nothing after a particular point. People think, “Oh, you’re a prin con. You know, I’m sure you must be some great demigod!” What, what really happens is there are a whole lot of responsibilities you should be able to shoulder and pull off. If you can do that, that’s much more than any designation. Because tomorrow when you go to the next place where they do not have the same kind of, you know, levels and hierarchy mapping and not. I know that the FAANG, they’re kind of somehow naturally or by coordination figured out, come up with the appropriate levels. So someone from Netflix or goes to Amazon and then to Google, and they get promoted. They already know what to expect. But what if you do go to a startup? What if you go to someone who’s really small or you go to a bank or an insurance company where they don’t have these levels? Where they only have tech at core and their business is not technology. Then what is the point of all these designations. It means nothing. What’s more important is - can you hit the ground running? Can you identify the customer’s needs? Can you make sure that you identify and eliminate quality issues? And completely reduce the turnaround time, from requirements to go live?

These are the capabilities that people really need. So hierarchy matters to some extent. And often in many places, your salary is linked to your hierarchy. Sure. But I would urge everyone to let go of that. Build up your competency, you know, money will follow.

Henry Suryawirawan: [00:15:25] Thank you. I mean it’s very insightful obviously.

So one thing I also realized, your progression is not just linear in terms of role, right? You basically, I think started from like a sysadmin role, and then gradually moved on to become a developer, and gradually moved on to become more like Agile, DevOps consultant. All these are very interesting.

Sriram Narayanan: [00:15:45] Very, very amusing you bring it up, Henry. The thing is I actually joined ThoughtWorks as a developer. In the company I was at earlier, I was a developer for about six years, and then I joined ThoughtWorks also as a developer for about a year full time. For the next six months I became what we now call DevOps. I used to take care of build and release engineering. First year as Dev, second year as build and release engineering. And then Ajey tapped me and he pulled me out of all of this and got me into his sysadmin team. So I worked there for about 5.5 years as one of the sysadmins in ThoughtWorks.

I was made IT manager and everything, but I tell you, when you’re working with sysadmins of a particular caliber who are used to seeing hierarchy and they get scared, you don’t call yourself a manager in front of them. And that’s what I did. I had this very tricky situation once when HR lady, she came and gave me a letter and said, “Congratulations Ram, you are now a Lead Consultant. They are marking you IT manager.” And I just told her, “Hey, don’t joke. You know, let’s talk later.” And she understood I’m doing something here. Then I went and told her, “Never call me a manager in front of these folks. They will all just stop talking to me and, and, you know, I will never learn what I actually need to learn” - which is a very important point. When you’re working in the Ops world and this is something that - most people, you know, they just think they learn a bit of Terraform, and some CloudFormation and something, and, you know, Hey, I’m a DevOps guy, you know, Jenkins pipelines or whatever. Uh, sorry. That’s not the real Ops life that you just learn to use certain APIs, but actually working with Ops people, understanding what the Ops means requires you to work with them, get into their mindset and make sure that they trust you.

But Henry, I’m not surprised that you thought I started off as a sysadmin. Because many people have seen me talk a lot of sysadmin-ish things . In fact, I used to be known as “IS Ram”. That means Information Systems Ram, right. That, that used to be my nickname. Henry, now in Southeast Asia, you know this. In India, that’s what everyone called me and there are entire generations who don’t know that I actually write code. By the way, I was also known as Solaris Ram because there’s a lot of stuff I used to do.

So anyway. Yeah, Henry, like I said at the start, right. I’ve been very fortunate. The exposure that I have got, which is I got to run my own businesses, non-IT and IT. I got to work in a very small company with, you know, Swiss and German banks. Then I got to work in ThoughtWorks as a Dev for a year where I had some of the best experiences. I had Sriram (Narayan) who took all these hierarchy things out of my head. I had our colleague Sapna Maheswari who taught me what it means to test drive. And I tell you till date, I use that same lesson with everyone.

Then I had Mahadev Naig, who Henry, you know as Maha, he’s still in ThoughtWorks Singapore. And Maha taught me in about 10 minutes, what it needs to make sure that you have Continuous Integration in place. These people taught me really, really good things. And I learned that in my first year, I was able to apply a lot of that in my last six months in professional services. Then I went into IT operations, where again thanks to Ajey and the kind of autonomy that he gave all of us, I got to become the IT manager. I learned to set up a data center. I learned to, it was my aspiration at that time that I should be able to place purchase orders of US $10,000. Talking about $10,000 a month is a very big deal.

But to his credit, Ajey trusted me and one or two other colleagues to set up entire data centers. The company backed us. They put in $300,000, worked out with the finance team that we already recovered within the first six months. So that’s the kind of amazing growth that I had.

I would also say I was fortunate because now in all these large setups, you have a network team, a firewall team, a SAN team, a virtualization team. You know, you have people then who would be Operating Systems specialists, right. There’ll be a whole separate security team out there. Whereas when we were at that time at ThoughtWorks, our IS team was just 12 or 14 of us around the world. Because I was in Bangalore and it’s a major delivery center, for a lot of our projects I used to get onto the call with customers. So they would say, I’m from SAN, I’m from hypervisor, I’m from switching, I’m from network, I’m from security, this, that. And then I would say, “I am Ram. I represent all these roles at ThoughtWorks. Let’s discuss.” When you get to talk that way, when you are able to talk in a cross domain proficiency , I can tell you in the IT role, what people generally call it as Ops, each of these is a huge separate proficiency by itself.

So that kind of, my God, that kind of exposure, I can tell you with a little bit of immodesty or whatever. Very few people get that kind of luck. I got it. That’s why I keep saying I’m very fortunate. And Henry, I’ve exchanged with you about my sleep and everything, right. So I can just share. Day of yesterday I suddenly woke up at 4:00 AM, very grateful for how my life has been so far for my good health, and my income, and my grades. And of course all these learning opportunities. So, yeah Henry that’s how it has been, man. I can tell you I’m very very very fortunate. Very fortunate, really.

Continuous Delivery [00:20:50]

Henry Suryawirawan: [00:20:51] So, you mentioned something about one of your colleagues, Maha, right, who explained to you Continuous Delivery in 5, 10 minutes, right. Maybe you can share with us as well. What is actually Continuous Delivery?

Sriram Narayanan: [00:21:02] Sounds good, Henry. So just to clarify, at that time, we had not had the buzzword of Continuous Delivery yet. Maha actually had explained to me about Continuous Integration. So to tell you very quickly there’s Continuous Delivery and we touch Continuous Integration. As with the word Agile and it means so many things, there are people who think that if they have JIRA, Confluence, and the Atlassian suite, they are Agile. There are others who say, if they do the $3,000 Scrum certification, I don’t know how much it costs, that you become Agile or whatever. You have an Agile transformation officer. So same way, right. And the way it has all got diluted and with weird interpretations with DevOps also.

The same thing has happened with the acronym CD, Henry. So CD in CI/CD right. The CI over there is Continuous Integration. The CD, honestly, depending on who you talk to can be Continuous Deployment or Continuous Delivery. There are those who say that, “Oh, I’m sorry, we have CD that is Continuous Deployment. Therefore we must go live.” There are others who say, “Oh, you know, because we ought to have a bunch of gatekeeping checks, we can’t have CD that is Continuous Deployment, therefore I’m not going to let you do any of the rest either.” So all of this becomes a bit of a mess, Henry, in the adoption of all these practices.

So Continuous Integration, when you are integrating with the other developers on that code base. You may or may not have branches, but the larger objective is you integrate with each other as soon as possible. So this usually gets you into disputes of, you know, should you have a branch, should that be a branch for a feature or a story? Should every individual have their own branch? The truth is, in the Subversion days, right, these were all a little bit of an issue. Yes, in Subversion also copies are cheap, but with Git, it is cheaper. The thing with Git is, when you have a local copy, you got an entire separate repository. Nevermind having to start a branch. You’ve got a whole repository of your own locally, right. So you essentially are integrating with various repositories. That’s what master means. So Continuous Integration is when all the devs, they do whatever they have to do, branch, no branch, whatever, but they have to integrate with each other. That means onto the development branch, not into just a feature branch, definitely not into just a story branch. That is Continuous Integration. And if you do it with the best of efficiency, you can reach trunk based development eventually.

Continuous Delivery is when your code is in a deployable state and functionally correct. That is Continuous Delivery. Continuous Deployment is when you realize, Hey, look I have all these gatekeeping checks. They’re all automated. Everyone is happy with their respective gatekeeping checks. And we all feel that you know, if the gatekeeping checks help us, we agree to this artifact being good enough for us. Let’s just go live with it. So if you have that, then you have Continuous Deployment. Actually the owner of the environment, the product owner, the systems owner, they have to first be comfortable with the artifact being ready in terms of gatekeeping checks, all the gatekeepers also have to stand by the automated gatekeeping checks, then go for it. Otherwise, don’t just push Continuous Deployment and then, you know, sabotage yourself.

Henry Suryawirawan: [00:24:10] Hmm. So I can see there are lot of important things that you should have in a Continuous Delivery, right. So things like, for example, first of all, Continuous Integration, continuously merging with each other. And then you have the gatekeeping checks, and I believe you also need to have automation in place. So what do you think we should do to get started with all these practices?

Sriram Narayanan: [00:24:33] Wonderful, wonderful, Henry. So just incidentally Henry, I’m actually working on a book called “The Journey to Continuous Delivery”, which is actually literally covering this. Where do you get started?

So I just tell you - the end goals, okay, the end goal should be that your code should be deployable and functionally correct. Now, Jez Humble, Dr. Nicole Forsgren, and Gene Kim, right. They all worked on the DORA metrics, the DevOps Research Agency, right. They came up with the DORA metrics where the expert level in the DORA metrics is - you should be able to go from commit to go-live in less than an hour. This is where you should aim for. So where do you get started is literally with: do you know what is working in production? Do you know the versions of your artifacts that are in production and do you know the version of code that they are tied up to?

Okay, let’s split this in two parts: where do you get started and how do you know that you have the good continuous delivery in place, right? So when customers call us in and they say, “Look, we’ve invested in all the right CI/CD tools, they’ve done this and that and everything.” In my head, I groan a bit because, when I hear CI/CD, I unfortunately already know what to expect. Right. I keep an open mind, but usually I’m proven correct.

Unfortunately, they would have invested in some Jenkins or JIRA, you know, they would have forced a bunch of devs to write a few tests and all of it. And they will say that we’ll have A, B, C, D environments. And with this, we’re going to go live. And nowadays, the new thing is if you want to do all this, you better have microservices and Kubernetes, right. To me things get mixed up over here. My questions to such customers are, “Do you have defects in production?” Okay. I literally start with that question. “Yes.” Okay. Most of the time they do have defects in production. Okay, my second question. “Do you have an automated test suite?” “Yes. We have an automated test suite.” Third question, “If you have an automated test suite, how come you still have defects in production?” Right? That is the question that gets people. They don’t know what really to answer to me because they don’t know why things are going wrong. Hey, not a problem. And that’s when I tell them, “Look, treat me like a doctor. If you go to a doctor saying I’ve sprained my ankle and they laugh at you and say, ha ha, you can’t even run. Look, you’re spraining your ankle. What’s the point of them being a doctor? They, they meet people who have made mistakes. They meet people who did not make a mistake and things just happen to them.” Right? So that’s when I tell customers, “Please, these are not supposed to embarrass you. They’re just hard questions. You ought to be asking yourself.” So third question is this one, right? If you have an automated test suite, how come you still have defects in production? Okay. Not a problem. Let’s move on. “How long does it take you to triage a defect and understand why did that defect happen?” Right? Half the time or most of the time they don’t have a clear answer. Then my next question is, “Okay. Let’s say you do fix, you identified the defect and fix it, how do you know that you did not undo anything else that was already working?” Right. That’s my next question. Usually they don’t have an answer. It’s related to the comprehensiveness of the test suite. And my last question to them. “Okay. From the time that you are satisfied with this package, how long does it take you to get to all your gatekeeping checks into prod?” I can tell you Henry, at this point, people, you know, they, they, they realize, the more mature of the managers, they realize, “Okay, it does look like there are opportunities for improvement.” Then they asked me, hey, what is the industry best practice? Then I, which is when I tell them over the DORA Expert level. To which they say, “Oh, you know what? We need to go live once in two months. We don’t have to go live once in an hour. We don’t, we don’t have any requirement to go live within an hour.” To which I say, “Not a problem I’m with you. I’m sure you have to go live once in two months because of integration and partnership agreements. No problem. But if there is a production defect, can you always afford to push all that fix only two months later?” That gets them again.

So this is how I make people understand that if you feel that you have the so called CI/CD in place, you should not have such dismal answers to these things. Then they asked me, “Okay, what does it take? You know, what will it require?” That’s when I make them understand that just having a Continuous Integration system and a declaration of Continuous Deployment does not take away defects. Your code, okay, it does not guarantee that from the time you start your deployment, it will actually finish. Not as a guarantee that whatever you’ve finished deploying will actually be defect free. Which is why in my definition of Continuous Delivery, I say the code has to be in a deployable and functionally correct state.

Sorry, this is a slightly longer answer Henry, but I gave all of this with the anecdotes so that you know, our listeners and we all come to the same page with us. You know, that there is more to all of this than just having a Jenkins or a JIRA. Right?

And and let me just add one other thing, because I brought up the phrase “CI/CD” over here. Once upon a time, I used to be very, you know, you know, me Henry on this point, I used to be extremely strong, you know, against the phrase “CI/CD”, because like I said, just having a JIRA and an agreement to go live regularly does not make you defect free and does not have the right guaranteed deployment either.

So it’s as I keep explaining to customers, I make them realize the need for a test suite. They realize the need for uniform environments, consistent deployment and configuration practices, the need for comprehensive automated tests and exploratory tests, and automated deployment and gatekeeping checks that are baked in. As they learn all this, they realize that that there’s more to this than just CI and an agreement to do a Continuous Deployment. That’s when I tell them, “Let’s stop saying CI/CD, let’s start saying Continuous Delivery. That’s the only way you’re going to get everybody onto the same page. Otherwise, what happens is, you may very well have a trunk based development with devs merging on trunk, you know, most efficient merging, they merge on trunk, but you get an artifact which is going to sit there for the next two months while every gatekeeper goes through their own process of promoting it ahead. Right? Where’s your Continuous Deployment then? It’s not happening!” So that’s how I walk people away from the phrase “CI/CD”, which is limiting to them, towards the correct phrase which is Continuous Delivery.

Henry Suryawirawan: [00:30:44] Hmm I see. So looking at this, right, again looking at the list of questions that you have, every time you ask that, obviously it brings a much deeper thought process, right, whether we have actually implemented the CI/CD the correct way, or meeting the actual intention of the CI/CD, right. So is there any some kind of like maturity level? Again, coming back to my first question, how do we start, right. So is there any like maturity level, for example, a small team with few developers, they want to implement this. Obviously they won’t be able to achieve everything end to end. So is there something like a progression maturity level that they can aspire to achieve? And over the time they can improve, obviously.

Sriram Narayanan: [00:31:27] I’m completely with you, Henry. There is this phrase called “let’s take baby steps”, which has its role and which can be harmful as well. When does it have its role? When is it harmful? Honestly, I used to think it’s the cowards who want to take the really, really, really small baby steps. But I have also matured and come to terms with the fact that, people will take a smaller baby step as they feel comfortable taking. Okay. The comfort can be genuinely a lack of technical understanding or process understanding. It can go all the way to extreme weird political things of saying, no, no, no. I think my job may be a threat. I better go slow on this and see if these people actually worth it. And until I figure out what’s in it for me, right. I’ll be very plain on this talk. It actually ranges from this to this. And I’ve had to deal with both the sites and all things in between. Yeah.

Here’s what I do. So one is Henry, as you saw on those five questions. Our code should be in a deployable state and functionality correct. That is why I start from a functionally correct point of view, you know, that do you have defects in production? If you have defects in production, you’re not functionally complete.

So where do you start? And this is a very good question. Where do you start? In greenfield projects, that means where we start from scratch, this is easier. Yeah. We know exactly what will be setup as CI, we’ll agree on trunk. We start test driving. And life is great. What do you do when you’re a team, who already has code, you already actually understand the domain. You in fact, may even have working stuff in production for maybe even a few years. Now we go to these five questions and realize my God, I don’t have really honorable answers for these. You know, I have very embarrassing answers in fact. No problem. No problem. Everyone has to start somewhere. So how do you start?

I’ve got some process ideas and I’ve got some technical ideas. Let me quickly tell the technical ideas and get them out of the way. The first thing is to create an inventory. What are you running in prod? This goes from broad environment composition. That means how many VMs or servers and all of it. Who are you connected to on the network? Who do you integrate with and on what protocols? Okay. One is an inventory of that. The second is what are the artifacts that you have in production? Right. I have these three different WAR files for Java apps, or I have, you know, those specific node packages or whatever that I’ve set up. Sure. You have to have that. Get that inventory first. The reason I’m saying get an inventories, can you for sure confirmed say that no one has made any changes in prod? Often we cannot say that. You do not know that, did you go and hot patch or, you know, tweak a config file or a code file to apply a patch or a fix in production, which you forgot to check back into version control? You don’t know. So usually the best thing that I advocate is take a snapshot of all of it. That includes a snapshot of security settings. That includes talking to security teams and understanding what are the settings that they’ve applied. Some security teams are very secretive, but I can tell you generally, all security settings are usually based on the CIS level one or level two benchmarks.

So once you have an inventory of that, the next immediate thing to do is do we have the source code that was used, do we know the exact source code and the version in the source code that was used to create these artifacts. So that is the source code of the application, but also the build scripts and the packaging scripts. And I’m using these words carefully here, build scripts and packaging, because for example, someone might use Gradle to just come up with a WAR file, but they might choose to repackage that WAR file and digitally sign it, using somebody else’s script. You know, the prod team might give a script for that. Or some other prod ops team might say, “Okay, here you go. Run this RPM. We will take your whole, you know, your Spring Boot app. And we will convert it to internal RPM for you.” So do you have an inventory of all of it, right? Make sure you have an inventory and version control.

Then the third step would be, can you recreate those prod artifacts? Believe me, these are such interesting and painful things to go through, you know, because you realize that there are only specific machines where certain compiles go through. There are only such certain machines in which the packaging goes through, because some signing certificates are kept only there. Once you discover all this, you have to create an inventory of that also.

Now you build up a backlog of things to fix, which is, can we arrive at uniform environments. This can be a whole track by itself, uniform environments from prod all the way back to dev, which includes the security settings. It includes an OS versions and patches. Then you come up with your second track of activity, which is, how are we deploying this? Can we use the same deployment scripts to deploy in prod and in dev so that you have consistent deployments? The third thing is can we have consistent configuration? Can we configure in dev the same way we configure in prod? And this is very interesting and important. In today’s world where people are busy using Kubernetes and this and that and everything, right, they may not realize this, but sometimes, there are all these cloud provided services, as well as third party services that you have to set up and configure where you better understand how to configure it. Otherwise, you will end up in situations where that VM disappears. Amazon, for example, says with their shared responsibility model, that, Hey folks, we will bring the AMI and the VM up, but beyond that is your responsibility. So that’s not a time to say why is the cloud down and all of that, you know? So do you have consistency in your configuration, right? So uniformity in the environment, consistency in the deployment, consistency in the configuration of the environment, as well as the app.

Once you have this much, right, Henry, this gets you ready and it removes a lot of unpredictability that comes up in questions. Once you are able to do things like this, you can stop certifying environments and start certifying builds. This will help you move away from conversations like… So it’s really natural, there are people who say, is SIT green? Is that app working in QA? Is UAT red today or is it green? For how many days has UAT been red? That’s all nonsense, you know. What does it mean actually for an environment to be red? An environment is a composition of the physical infrastructure, let’s take it right up to virtual machines also, with the OS and the patching. It is the security configurations and other OS kernel tunings, which go in configuration. It’s the build of the app. It is configurations for the app, which also includes, you know, database schema and configuration, and all of it. It’s all of these things together. So there is no such thing as saying, is UAT green or is SIT green or QA green? No. Is that build working in that environment? To remove the variable and unpredictability, first you get the environments uniform, but you get consistent with deployment, configurations, and builds, right, and then packaging.

Once you get to this, it removes the variability of, “It works on my machine, it works on QA. I don’t know why it’s not working on UAT.” Once you get them all uniform, and certain things consistent - you’re good.

Testing Pyramid [00:38:34]

Henry Suryawirawan: [00:38:34] I think the way I see what you’re describing here, I mean, you have, like, for example, uniform environments, deployment consistency, including the configuration, are you able to recreate the builds from your version of software, right? I think the other thing that you mentioned about the definition of Continuous Delivery is that the build should be functionally correct, right. And I think the most important thing here is that, whether you have some kind of gatekeeping checks or automated tests in place, which kind of brings me to this topic about testing pyramid, right? So maybe you can explain to the audience here, what is testing pyramid? What is the concept behind it and why is it important to understand that?

Sriram Narayanan: [00:39:16] Yes, yes, let’s go for it. So, a lot of these things are not either-or. You can actually start some of these things in parallel. Creating an inventory of your production, figuring out the version control, try to sort out the builds, you know, making sure that your build machines are recreatable. These, all of these activities can happen in parallel and it is fine to happen in parallel. In fact, it’s a great time saving. It also gives ideas to others on what else they should be checking for. Once you have these things sorted out, Henry, is when we can actually start leveraging the tests, the automated test suite.

So now I happen to be very good friends with a lot of good exploratory testers, right. Okay. Testing is a whole business by itself and there are, there are, there are all these humongous, you know, mega corporations software delivery companies. We all know them, who have entire testing offerings and testing departments and all of it. I have come to realize that they have their place because not everyone would take a test first approach, you know, from an automated test, and therefore you need these kinds of companies, you know, where they will take your code. They take your artifact. These are testers who check as part of their test cases, what are the valid and invalid state transitions? And which of these valid and invalid stage transitions happen or do not happen? And that is their test report. This is often called black box testing. The less mature black box testing is just randomly clicking about and going through a spreadsheet and declaring, oh, you know, your app doesn’t match these 400 out of these 500 different test cases I’ve got, which are just rows in an unfortunate spreadsheet. The real question is how do you arrive at that spreadsheet? One of the things you do is go through a state transition planning. This is what you have to do when the devs do not test drive. Which is what gets us to the test pyramid.

I think it is a waste of people’s time eventually, okay. And it’s a very mind numbing and there is no real growth for such testers, when they have to again and again and again, repeatedly validate or invalidate these state transitions, as well as the input and output acceptance criteria, right? If you are going to create a calculator and you know that four plus three should equal seven, there is no fun in them validating four plus three equals seven and every build that’s given to them, you should actually automate that.

This is where these are the kinds of tests that we should automate. So Mike Cohn, you know, who drew the test pyramid, Martin Fowler blogged about it. And I use their diagram a lot in my conversations. I use a test pyramid to say, “What should a test tell us? Our automated test should help us understand: what failed, where it failed, and why it failed. With various tests being used by various people.”

So the “what failed” tests are things such as, “I was able to add an item to the shopping cart, but I cannot check it out.” Great. You at least know that the checkout process did not work, but I could search for an item and add it to the shopping cart. Very nice.

Where did it fail? That’s when integration test comes into play. It says, “That other shopping card service with some other team, it turns out that when we made an API call to them, they gave a response code and it failed.” Right. An integration test will tell you that.

A unit test tells you, “Hey, I’m using that shopping cart stub service. We are supposed to pass three parameters to this API call. We are passing only two. So that’s given me a test error.” Or a test says “four plus three, seven, four plus minus three is also seven. Sorry, there’s a problem.” Unit will tell you things like that, right? Because four plus minus three should be one. Correct? So “four plus three is seven” is an acceptance criteria. “Four plus minus three is one” is another acceptance criteria. “Make a call to that stub with three parameters” is an acceptance criteria. “I should be able to add items to a cart and checkout” is another acceptance criteria. But you will see that these are all at various degrees of granularity.

From a triaging point of view, from knowing something broke, the top of pyramid test “could not add to a cart” is great. But from knowing why it broke, the fact that you passed two parameters instead of three is what actually lets you triage issues. And that gets us, you know, to how should your test therefore be arranged? If you take the test driven development approach, which means unfortunately, you know, the word test has many connotations and when I’d work with experienced developers, I make them understand that what we are following is really coding to specification.

So when you code to specification, and as devs, you’re working at the lowest level possible, right? That’s why it’s called a unit. When you code specs right at the unit level, and you keep working your way upwards, you will find that you will have a massive amount of unit tests, some amount of integration tests and even lesser number of functional tests, right. The adding something to a cart, right. Or clicking the checkout button. So once you look at all of this and you spread it out, it becomes like a pyramid, humongous number of unit tests, some amount of integration tests, even lesser number of functional tests. Once you do this, you can spare your QA from having to, you know, like a drone, keep clicking search for an item, added to a cart, click a checkout. You spare them from all these pains, you know, Henry. They can now focus on what they actually should be focusing on, which is exploratory testing. Which is a problem. There are many people who buy the CI/CD medicine, they’ve just declared, “Oh, everything has to be a hundred percent automated” and they will thump the table and demand that many things which cannot be automated tested should also be tested and, you know, it just becomes a misery game.

So no fun there, no fun. The point of the test pyramid is also to tell people that just because you have a QA team does not mean that every particular core flow part in your app should be tested by UI. That need not be the case. For example, I have been in eCommerce setups, where they have said that “I want every product category variety to be added via the UI and tested. I don’t care that you have, you may or may not have lower level tests. But testing team, I’m paying you to write this rule. You better write all these kinds of, you know, UI tests”. I can tell you Henry, I’ve been in that situation, I’ve seen some 6,000 odd UI tests, and then we were able to work it out with the client and show that the same code paths and the variety that’s happening at the UI level is already being tested at a much lower level. So if you cut down the UI test suite size from 6,000 to just 30 or 50, that frees up the UI testing devs. It frees them up, you know, coding testers. It frees them up to automate for the other things, or if they’re actually exploratory itself, they can do that. So it’s a bit of a journey and you have to show this to customers.

There are test writing companies who are paid on the number of tests that they write. There are people who have finished paying for a large number of tests, and here I’m coming in saying, “Cut out your 6,000 tests and replace them with just these 30.” So what happens in these cases is people behave as they are measured. The testing company is being paid on number of tests - they will write a number of tests. There is someone who has justified to their management that “I paid for 6,000 tests. And now I’m throwing it all away in double quotes, you know, throwing it all away to just remain with 30.” So people are going to ask them, “My God, why did you get all those built? Did you waste money? Or if you do not waste money, then are we losing out our safety net that we paid for?” Right? So these are the scary questions and you have to have strategies on how you deal with these. See, the truth is computers are very fast. What also happens is most business people, product owners, team managers, even business analysts, and sometimes I would even say testers who have not seen the speed at which code runs, you know. These are not people who will understand the speed and the magnitude at which unit test suites can run. For example, “Browser start, search for something, add something, navigate, navigate, navigate, check out.”

Let’s say this takes 10 seconds. In those 10 seconds you might have as well run some three to 500 unit tests, depending upon the computation core over there, right? And humongous number of UI paths that people would want, you might as well tested it at a much, much, much lower level and finish your whole combinatorial matrix over there. What is really required is to show the costs of maintaining such humongous test suites and the cost of not performing exploratory tests, and also the cost of breaking one’s head and trying to achieve 100% automation of all considerable usage scenarios in one automation test. Whereas you could have just said, “Okay, these eight things, let’s just manually verify them and move on.” So these are the things that people will have to do. There’s no one answer, but these are the kinds of things I would pay attention to.

Buzzword Driven Development [00:48:07]

Henry Suryawirawan: [00:48:07] These days technologies move so fast, so rapid in fact, like every few other days, you, you will hear something new being introduced, including not just software libraries, right. But also like technical practices, and things like that. So obviously, some of us, I mean, who probably are much younger in terms of professional experience. We sometimes are confused with all these, you know, insurmountable terms being thrown at us and, like buzzwords, we just need to follow and try to say, okay, we have achieved this.

So what, what do you think about that? How should people approach these so called buzzword driven development?

Sriram Narayanan: [00:48:44] Yeah. Henry. So one of our colleagues, you know her Stella. So Stella and I, we ran a few Continuous Delivery pipeline workshops in the ThoughtWorks office last year. We kind of developed the syllabus together and now what I’ll be doing is putting out all the syllabus out there. That what does it actually mean to design a pipeline? It’s not just something that you pay, you know, CloudBees or, actually TeamCity is very good on it. They don’t call it build pipelines. They call it build chains because that’s what they are. One of the interesting (thing) , when Stella and I were putting together the FAQ, right. One scenario that I threw at her is, “Hey, Stella, let’s say it’s a company of just you and me, both of us writing code, sitting side by side. Do we still need Continuous Delivery?”

Henry Suryawirawan: [00:49:26] Good question.

Sriram Narayanan: [00:49:27] Right. So she and I, we actually thought about this a bit and we came up with a scenario. And our scenario was. Let’s say Stella needs to fly home for this weekend. And she thinks that she may extend it and come back on Thursday. Right, take a rather long holiday also with it. In her absence, I don’t want to call her and interrupt her. But there is a particular defect a client has reported. I fixed it. And now that client says, “Whoa, you fixed this. Do you think it will undo that other feature you build for me?” I have to know authoritatively without calling Stella - this fix that I did did not undo something else.

So if my code base has to be functionally correct, it’s not enough that I just have a CI, wherein the code went in, the thing went green and I have an automated deploy and I push it into, you know, Amazon or whoever. No, I have to have the right test suite that says, these are all the functional acceptance criteria that we had and Ram where you made this fix, did you break some other existing acceptance criteria. Did you violate the acceptance criteria fulfillment? Yes or no? So I should be able to tell the client, “Come buddy, I know Stella is not around and you’re worried about it. Here you go. Here’s the test suite we put together for you. The build is green.” Right?

So Stella and I, we came up with that scenario. Even if it is me as a solo operator, right? It’s just me writing my own cool internet, you know, sensational app no problem. If there is a paying customer, and this is one of your startup fears, right? These things happen that when suddenly there is one heavyweight customer, for who you have to start enhancing, you know, and you have a product vision and whatnot. You should be able to think that “If I make this enhancement, what is its impact on everything else?” You better have the right test suite, which tells you, “Oh, if you do this, you are going to be disappointing those other five customers.” So Continuous Integration, right, is not just that a CI system could check out your code and compile it and keep it ready, right. It also means that the known acceptance tests, at least the functional acceptance tests to the extent possible are automated and they are captured and they are executed. So that your code is functionally ready. So that’s how you should leverage your CI and you make it CD by making sure that your code is in a deployable state. And you automate your deployment. You let the client decide when they want to deploy. You want to continuously deploy, go. That’s just a flag. That’s a flag that says “If this pipeline passed, I’m happy with pushing it.” Don’t want to do it automated, not a problem. Give the environment owner the rights, tell them, “Click this button, go live.”

Henry, you know, like you say, all the young people, I wouldn’t call it so much young, I would just say it’s the exposure to various blog posts and whatnot. And they hear Continuous Delivery, Continuous Deployment and they thump the table and say, “We better deploy continuously.” No problem. No problem. You can deploy continuously if you know that you’re functionally correct. You know, that others you have to interface with, if they are not ready, you can detect it and not invoke those interfaces yet. You give the client the ability to activate that interfacing when the client is ready, you know, let’s say these are opening up some new API. And you give the client the ability to step back from it and even roll back those transactions. If you can engineer all this, depending on the domain, go for it.

So for people, right, who are confused with all this, and with even my contrary views compared to what’s on the market, I would say, look, let’s accept that. Accept and acknowledge that some buzz words are even necessary. Buzzwords help something become popular. Buzzwords also give a name to a huge set of practices. Let’s acknowledge it. But let’s also understand that buzzword or no buzzword, you have to give something that’s functionally correct. If you can do that, it doesn’t matter if you don’t know any of the buzzword names because you would have figured out the engineering practices needed for it. If you can do that, don’t worry about your years of experience because the maturity that it takes to arrive there and the wisdom you will gain from making mistakes will really serve your purpose.

Keeping Up with Technologies [00:53:27]

Henry Suryawirawan: [00:53:27] So I have one question as well. Like, I’ve always wanted to hear people’s thought, especially from people like you, right? So these days there are a lot of technologies love, like frameworks, languages, even like cloud providers and things like that. Right. So how should we as an individual keep up. Do we need to learn all these technologies? Or should we just aim for those that are popular? So what are your thoughts on that?

Sriram Narayanan: [00:53:52] My goodness. I think one of the better decisions I’ve taken in my life, is to regularly keep diversifying. Don’t stagnate. Keep diversifying. Let me tell you a thing or two. Let’s take a typical audience member, for the sake of discussion that they are going to write a multi-tier application which has a web based front end or server side, some service APIs, and a database. Let us also further assume that they’re going to be deploying this on Google, Azure, or AWS or Kubernetes. This is a typical push nowadays. Isn’t it? Then this person, let’s say the tech stack is Java Spring. Then they go to meetups or they nowadays with all our COVID life, they go see what’s online. Woah, there’s now the MERN stack. Oh, Python is gaining popularity. Look, look, look that AI company just got funded $20 million, man. And you are doing everything with Google Keras. And here I’m stuck with the Spring Boot. Oh God. I’m outdated dinosaur already, right? It’s a typical worry. It can be really scary - all this. I tell you, you can feel very rapidly that you’re going to get outdated.

My feeling is, yes, you will get outdated. You have to accept that you will get outdated and you have to start putting in strategies in place to help make sure how much are you outdated and what will be the effort involved to get up to date again. Once you understand this, being outdated is no longer scary.

I can tell you Henry. About every two years, I end up changing my role. Even though, I’ve kind of close to completed 15 years at ThoughtWorks by now, still every two odd years, I have been fortunate enough to get to change my role or to pick up something new. And this is not just because I’ve been assigned to different projects. I have in fact changed my role entirely from being a dev, to being an ops guy. And in that world, I can tell you it’s a massive world. It’s part of who I am today that, you know, I can go to traditional data center people and make them understand what it means to move to the cloud. You don’t go to such people and say, sir, you are all outdated. I’m using Kubernetes now. No, no, no. That’s not how it is to succeed. So my suggestions will be, make sure you can do this.

My own true story is, a long time ago, this is around the year 97-98, I was teaching at a small computer institute, right? And I was just teaching C and Unix. That’s what I used to teach then. And I thought “I’m going to learn this, that and everything”, but just learning C and Unix itself was a lot for me, I tell you. Then one day I got the opportunity that some other senior faculty who was teaching Windows programming, he just quit and went. And these small institutes, right? You don’t have too much of professionalism. People just come and go or whatever. So suddenly they told me, “Hey, look, here’s an opportunity. You can now teach Windows programming.” And Windows 95, had just come in a few years ago, relative to my time then. And, it was on only one computer. One of the students, he came and he gave me a book. He said, “I know you’re stuck, but we need your help to clear this syllabus. Here is a book from my office. See if you can learn from it and teach us.” We are talking about times when we did not really have computers at home. So I’d go through the book, write it out on paper. Then come to the training institute very early in the morning to type it all, because floppy disks were very, very expensive. I couldn’t afford them. Whoa, I became good at Win32 programming right. Now onwards, every windows app that I saw, I knew exactly what’s going on. Okay, great. I’m now the new whiz guy and I’m sure audience will identify with this because once you become good at your tech stack, you can churn out code in a day.

One day this new guy comes in and installs something - Visual Basic 5. It blew my mind. The stuff that I would take about two to three hours, he just clicked two three buttons and had an executable out. My God. I was outdated! Everything that I had thought of doing, right, till that time all these months that I have poured in, just disappeared, man. I thought, “Oh, this will not do!” And I was just some 18 or 19 years old at that time. And I knew someone in my locality who was a union officer, you know, worker’s union officer. I said, I’m sure these people have protested to management and all, and saying “Remove computers, remove all this, we will lose our jobs.” There used to be industrial times like that also. Okay. So I went to him and I thought I would get advice on how to protest to the management. So I told him all this and he asked me, “Hey, how many people know this technology?” I said, only that guy. And I was scared this man will tell me, “Go break his leg and make sure he never comes!” I said, “Whoa, I don’t wanna be violent here.” Union - I had a certain mental model of union. This man advised me, “Hey, if he’s the only guy who knows it, how about you become the next guy who knows it and know it better than him?” My God, Henry. I’m telling you. My life changed. From that day, I have made sure that I don’t just use the technology. I find out how and why it works. I go to its plumbing and I go on from there.

The reason I gave this example is - you will always get outdated. But you have to dive in a bit, understand a bit of the fundamentals, and then you know what, the fundamentals still just translate around.

Javascript frameworks, at the end of the day, it’s a single threaded tech stack. All that it is going to do is just emit some HTML. No matter what million number of Javascript libraries you pull in, at the end of the day accomplish certain activities. If you understand that much, switching from one message to library to the other should not take too much time. If you understand the notion that Node is single threaded, whereas the JVM is multithreaded, that can teach you a bunch of stuff that you can and cannot do.

Yet again, Henry, I gave this anecdote for a reason. Some years ago we had the DevOps days in Singapore. Someone had asked me this, have I ever been scared of being outdated? Right? And I gave them this worker union Visual Basic example, you know. Another person from the audience asked me a very amazing question. He said, “What if?”, and this is interesting and important.

So he said, “Ram, I’ll ask you an archery based analogy. His scenario was. He is working for a King who’s employing archers. The enemy King is having people with much more powerful crossbows.” So, Henry, just so you know, and for the audience, there are pros and cons. With a bow, you can be much more frequently firing an arrow than with a crossbow. But with the crossbow, the velocity and the punch that it packs is like three, four times that of an archer. Okay? And I have a crossbow in, in India. And I know how powerful it can be. So just to share. So my response to this audience member, right? My response to this audience member was, “Steal out of your camp, look at what is this enemy doing? Understand that crossbow. Okay. If you can, then steal across one, come back to your camp. Shoot to your peers and shoot to your King. Tell the King, ‘This is what we can do with the crossbow. And this is what we are up against.’ Your King is also going to adopt the crossbow. If your King is not going to adopt the crossbow, then my dear friend, leave the archery tent and go to the crossbow tent!”

Henry Suryawirawan: [01:00:56] Wow. Interesting anecdote.

Sriram Narayanan: [01:00:57] Yes. It’s fine to, you know, deep dive into tech. It’s fine to do a lot of due diligence and, you know, wish well for the client and the team and be sincere. But also do not get siloed. Do not become a bank, or a government, or a particular company’s specialist. Do not. Because you never know, when you get so typecasted or so siloed that you actually cannot adapt to something new, right. That you can’t do it. At that time, sticking to certain principles or, or certain tech or whatever, right, is foolishness.

There is a saying by one of our ex-Presidents in India. Don’t love your company. Love your job, right? But I would say something else. Focus on the outcome and not just the technology, right? You are not here as a technology specialist. You are here as an outcome specialist. Today, it’s Java 4. Tomorrow, it will be Java 8. Then it’ll be Java 12. But then one fine day Graal comes in. What does that mean for you? Right? Because then someone with amazing Ruby skills in, in a fraction of the time that you do it with Java, they’ll do it with Ruby. Or they leverage Graal, they interop with everyone, and then walk away. What do you do then? Amazon comes up with stuff like Lambda, where you know, it will scale up to a few thousand instances and cut back down and let you stitch a lot of stuff together. What do you do then? Do you want to stay on as a VMware specialist. Oh no, because even VMware is not sticking to VMware, even VMware is expanding out. So why are you being so loyal?

Henry Suryawirawan: [01:02:27] Right. Thank you for this wisdom. I mean, it’s pretty profound and I’m sure like everyone of us can really, really relate to that story. And hopefully everyone of you can get this wisdom and apply it in your own career as well.

Segregation of Duty [01:02:41]

Henry Suryawirawan: So coming to my next question, right. You mentioned a couple of roles, like developers, infrastructure engineers, right, or DevOps, what people call these days, and then you have this QA or testers, then obviously there’s this security people as well. So where do you see security comes, in the CI/CD space? And also you have this interesting topic last time about segregation of duty, right. So do you think with a Continuous Delivery pipeline, you may say that we don’t need separate people or role to actually certify the builds?

Sriram Narayanan: [01:03:14] Wow. Very, very, very interesting question. So Henry, part of the “where do we start” is also once you understand a lot of these things, it’s also to draw the entire process tree, from the time someone decides we need this project, till the time they say yes, they have been live for three months and we’re busy enhancing features. What is the entire cycle of that, right? There’s this concept called the Value Stream Map. In a value stream map, you identify what are the processes that are involved? What are the wait times? And what are the cycle repeat times? So you will have process A, which takes five minutes. Then you wait for one hour, then process B, which takes half an hour. And then B fails, so you go back to A, and (say) this happens on average of three times, right? So in this case, this is your value stream map. In the real world, you would go all the way from stories being identified for a sprint or an iteration until the time that it goes live. So you have the devs committing code. They’ll take their time to commit code. Then you have to merge. Then you have to merge with the master branch or the development trunk, whatever they want to call it. Then you create a build for the QA environment. And there is a whole cycle of the build passing, failing, not getting deployed correctly. Then QA is rejecting that two, three times. Then it goes to the UAT environment or the SIT, whatever you want to call it. It goes to the UAT environment. Users reject it. They say, “Oh, this is not what I asked for.” Or “Sorry, it looks like you missed this requirement” or, “Oh, you know, some business circumstances have changed. We need to change the requirement.” Right. And from that, then you keep it ready for prod. But then the prod ops team says “The next deployment window is two weeks from now. You’ll have to wait till then.” Meanwhile, there are the security teams who will come with their gatekeeping checks. There’ll be the prod DB guys who come and say, “Sorry, I can’t let you make these schema changes.” Or “This is not allowed of, that because of performance issue”, then, you know, things go back. Therefore you learn the hard way to create huge checklists and get sign offs from people. And then you painfully go live only to find that your users are reporting certain defects and then the whole cycle starts again.

So, what I do is I tell everyone, “No problem. Let us recognize that we have to do all these things. Let’s just draw whole process map. So you have the processes, the wait time between the processes, the lead times that is, you know, it takes to start the next process. And how many times you go back. So with this, you’ll find out which are the various opportunities for improvement, right? Which are the spots where there is a largest number of waste? The biggest waste is of course, the further you go down and it comes back, that is a huge waste of time.

So what I advise is, “Let’s identify all these kinds of wastes.” And this is where the phrase “left shift” comes from. Many people don’t quite understand this, but you don’t just like that, you know, draw a simple plain pipeline in Jenkins and declare you want to do left shift. No, you have to actually do a value stream map to understand what to shift left. So, what do you shift left first, assuming that you know, our environments are uniform, our deployments and configurations are consistent, and we have tests. Now what you start left shifting are how comprehensive are these tests? And these tests, by the way, now no longer have to be just by the QA team, they can also be test by the users. They can be now the checks that DBAs hooked in, which is where you’re going to DBAs and say, “Guys, look, we traditionally keep coming up to here and you keep kicking us back. Can we please just discuss with you early on - for example, a conversation with the DBA team and say - can we discuss with you early on? What schema should we be using? What are you, what are you fine with?” Right? “These are the requirements coming in. Can you advise us on this? Let’s have a calendar date when you need advice, whatever, and you tell us what indexes to create/not create, what we should also look for in perf testing or whatever. No problem.” Suddenly you have your database admins gatekeeping checks with you. I found that it is socially more advantageous to approach and get the database checks than operating system and other people’s checks. Right? Because you can then go to the operating system people, show your due diligence by saying, “We have done this functional validation. Here are our gatekeeping checks. We are working with the database team. We are listening to what they’re saying and making those checks part of our pipeline and tests. Could we please have your checks as well?” That’s when you show them the network diagram, that’s when you show them which service talks to whom, what identity, what access. Show them the column level access. Show them, walk them through all of it in layers. Ask them whatever that they need checking for? Mostly they will tell you stuff like “It will be a hardened production OS environment.” Sounds good. Tell them, “You know what, you want a QA environment to be hardened like production. Give it to us. If it doesn’t pass in QA, it’s not going on it.” Right? Once you are able to demonstrate with an auditable manner that you are not getting into a QA environment, SSH-ing, and making changes, and that QA environment is the same as prod, you can now say “The security folks have given us their gatekeeping checks. We have codified this. Here is evidence that we have not changed the code. Here is evidence we have not changed the target. And we have successfully left shifted prod security.”

Once you can start doing things like that, you will find out that the process time in your value stream map will take more time, because you know, more checks are running. But you’ll find out that the wastes are reducing. Often it is better that a build and checks and everything instead of half an hour, if it takes two hours, let them take it. Just as a start, please bear with me. It is better that instead of half an hour and repeats for four days or even two to three weeks, it is better than that half an hour takes two hours with a guarantee that there will be no repeat. Once you are able to do this, you can then start figuring out “How do I reduce the individual process times?” Right? So for example, do we have to apply the security checks as part of the deployment? Or can we bake the security settings into the AMI, I’m using Amazon terms here, Henry, into the AMI and never change it. Because then suddenly the whole, you know, OS installation and security hardening and all, is baked in. Then you only focus on deployment and configuration. Suddenly that process time cuts down.

Then comes to other things like waits. Just to give you an example of wait (time) , many people may not realize this. So I have worked with clients where devs commit code throughout the day, and then they have to raise a ticket to get the CI triggered at night. Not a problem. I sat and I discussed with the CI people, I asked them, “What is it that you do?” It turned out that they had a bunch of checks of their own. And a long time ago, the devs did not know to run a bunch of these checks. Okay. Which was, does the code even basically compile? The code that people have committed? Have they tagged it with the right messages? Right. There were a lot of, lot of things like this. So what these CI-triggerring guys would do at night is, they’ve looked at all of it, come up with all of it, create a manifest document and say, “This build is related to all of these stories.” So you might normally laugh, “Ho ho ho, why do you have to, you know, raise a ticket with someone to trigger a build?” Go check with them, find out what is it that they are doing. Once I learned this, I went and told the devs, “Folks, with all our stories, let’s start committing it, linking to the story card number.” And I worked it out with a CI triggering people and then suddenly, they changed the whole CI to be triggered at a polling interval of every one minute. That’s it. Instead of raising a ticket and doing it at night, they did this.

So with these mechanisms, right, you can reduce the wait time between processes. So what we discussed was left shifting so that you reduce the waste, optimizing so that you reduce the process time itself, and then you’ll figure out “Why do you have waiting time in between? What can you do to eliminate it?” So once you’ve codified checks and once you understand other people’s needs and all of it, right, this is what it takes to arrive at and optimized and the best optimized value stream map. And then you can say, “I am now going to certify a build and not an environment.”

Henry Suryawirawan: [01:11:11] Hmm. So hearing from what you explained, just now, right? So the way I see it is that. Yes, there’s still some kind of segregation of duty, but instead of being explicit, now with all these gatekeeping checks and automated tests, and this shift left practice, right. You can have this all implicit and automated and you improve your value stream map as well. And even like, for example, from time to time, right? We have this Continuous Delivery pipeline where you can accept sort of like explicit trigger, like what people used to call “push of a button” that can sort of signal some kind of approval. So is that the correct understanding?

Sriram Narayanan: [01:11:46] Oh, sorry, Henry. May I say, I got a little too deep into what it takes to optimize a value stream map, which actually comes before the topic of segregation of duty. Just to tell you, Henry, I am still an accredited auditor. So in my work in a Singapore government space, I got to meet with a lot of very diligent process people and auditors and everything. It seemed painful at the start, but I will admit that I became a much better person with a far deeper understanding of the kind of regulatory and, you know, process controls that people often need, especially when they are not the techies, right? So that gets us to the topic of segregation of duty.

See, a lot of us, right, as devs, we know what it takes to compile code, even nowadays with a lot of cloud and automations. We know what it takes to provision an environment. I even push out a build and demonstrate that it is all correct. And for those of us who do a lot of good automated testing ourselves, we even know, yes, this is functionally a good build. Correct.

With such kinds of habit, and especially if you do a lot of work in a startup or the private sector where you’re your own boss, or where, you know, really high speed is the essence of the art. It can annoy you a lot when suddenly, you know, the company appoints a Chief InfoSec Officer, they come up with an auditor team. There’ll be, you know, security officers at every step of the way for every piece of infrastructure. And they will even tell you, “No, you are only allowed to keep a build artifact in this third party artifact storage system”, that they bought without even consulting the dev team or thinking about the suitability. They will just declare, “Oh, you must place it there. And we will decide, you know, how to deploy it.” Actually, these are unfortunate things, because there are several things I pointed out over here. What happens if someone goes and procures an artifact storage system without consulting the devs? Often devs are treated on a need-to-know basis, and told “You don’t need to know all this because I’m owning prod.”

Now look, here’s the truth. There’s this phrase called segregation of duties. Okay. Would you be comfortable with a situation where you learn that your bank has given out a software contract to some outsource company, those devs implement the software and those devs just mandate and push that build in production and no one from the bank got the opportunity to review that build and inspect it for back doors, or for functional correctness, or for regulatory compliance. That means this bank, which had this kind of liberty given to the devs, just could have given the devs opportunity to sink in a back door. And, you know, every month, one cent is removed from everybody’s account siphoned off to this other account, but the numbers are not shown in the UI, but that person has the ability to withdraw or transfer out that cash, with no records in the system. All the devs who are listening to this know that such kind of engineering is possible. It’s just coding after all. Would we be comfortable with this? They wouldn’t, right. That’s what the banks are here to watch out for. So the principle of segregation of duty says that the person who writes the code should not be that person deploying. So this is the principle. This is the intent. Actually let me refine it. The real intent is more than one person should be aware of what is happening. Right? So even in our outsourced dev company, the bank doesn’t want situation where the whole company in general is very diligent, but there’s one bad character in that, in that whole setup, decided to just push in a back door. The bank should not be held hostage to situations like this. So segregation of duty says more than one person should be aware.

Now what happens is, how does this get implemented? The way this gets implemented is who are the techies and the situation, devs. Do devs know how to write code and deploy it? Yes. Okay. Who are the next, if you don’t want devs to be deploying it, who are the next set of techies that we, as the bank know? It’s all ops people.

So, what has ended up happening over the years is, it’s become a kind of a norm. Who deploys? Ops deploys. And if ops people are told they have to deploy, they will buy tools that they understand, to store an artifact, and to deploy. They will go to that tech stack company and say, “Sell us some ops tooling that you can agree to.” And if they don’t, they go to any other company. Why do they do all this? Because those people do not know how to, I mean mostly, they do not know how to write a proper deployment script, which is predictable and consistent. They don’t know this. So they’ll just go and buy some artifactory, some random Urban Code, whatever have you, which has nothing to do with what the devs really prescribed for this. And things go very, very bad, Henry.

So the real thing that I’ve started to make sure clients understand this, “Let the environment owner deploy, let the ops people also be gatekeepers, let them prescribe what are the, you know, ops friendly deployment that they need to see. Let the devs or the prod deployment scripts or whoever write the script, and let’s use that throughout.” So now you can still have segregation of duty, where the devs and the QA - they collaborated, the test suites have passed. The product owner has seen it in UAT environment. Product owner goes to the prod, deploy button and clicks “deploy”.

There’s nothing wrong in a prod person click-and-deploy because that button is going to run a tested deployment script on a uniform environment. Ops people are not required for this. Suddenly the environment owner can do it. You can have multi factor authentication there. You can have more than one product owner required to click various buttons. You know like three buttons to be clicked, only then deploy. No problem. But you don’t have to now wait for two weeks for an ops team to be ready with a third party tool, which, which doesn’t have a true appreciation of the tech stack. Right? So segregation of duty is necessary. But the way it is implemented, once one does a bit of rationalization and reasoning, you can come up with much better automated processes to figure out how to do a better job of it.

Henry Suryawirawan: [01:17:32] Hmm. Thanks for clarifying and explaining about the segregation of duty. So for me coming from like a software development practices, obviously these kinds of things is a good thing for me to learn as well, because there are other perspectives from where enterprise is seeing the need of this segregation of duty, multiple roles that is required before an actual software is being certified and deployed to the production.

Consulting & Imposter Syndrome [01:17:55]

Henry Suryawirawan: So switching topic a little bit. So you have mentioned several anecdotes stories about your engagement with clients. I know at this moment as well, your role is more of a consultant. So can you explain a little bit more about, what does it take to be a good consultant?

Sriram Narayanan: [01:18:10] Parts of it has been slightly easy for me, because I had to run my own businesses and learn to ask that question, “What is the customer’s need that they want to have fulfilled? And can I fulfill it? Right? I would say the top thing as a consultant is to understand, “What is it that the customer needs?” As a consultant, to understand what is it that the customer needs, right. And then figure out, can you fulfill it, or tell them how to fulfill it, or link them with the right people who can fulfill it. This I would say is one of the top things we should be able to do as a consultant.

Let me tell you this Henry, what I said can also be true of a solution provider. Solution providers have people who consult. Here something that goes a bit funny. Okay. And this is especially in software delivery companies. Most of our audience will have something or the other to do with software delivery.

Depending upon the company, anybody and everybody is expected to be a consultant. Was this some people who are actually not interested in consulting at that point in their life, they want to just focus and deliver, right? Consulting by itself is way more complex, whether you’re called a consultant or not. If you’re a customer facing person and they ask you a question and you have to answer, you are consulting to them. Let’s, let’s leave aside some of the better definitions of that. This is what I have concluded. If you’re a customer facing person, they asked you a question, you have to answer, you’re consulting to them, you are a consultant.

My happy lesson, and this was from a book by Gerald Weinberg. Gerald Weinberg authored these two books. One is “The Secrets of Consulting”. And the second is “More Secrets of Consulting”. I would strongly recommend that people read this to understand what does it mean to actually be customer facing and deal with it all.

And in the first chapter, Gerald Weinberg of his book, Secrets of Consulting, he does his best to dissuade you from getting into consulting. It describes how horrible it is, how thankless it is. How rubbish it is. You’ll have sleepless nights, ungrateful colleagues and customers, and no one will know how much political and social maneuvering you have to do, you know, to nudge people in the right direction. And they will forget you the minute the deal is over and you’re out of the building. He gives all this horrible reality check. And then in chapter two, he asks, “Oh, you’re still here, is it? Okay, good. Let’s continue.”

I have found that it is rewarding to be a consultant. You learn to do these thankless things, because learning to do these thankless things, is a great opportunity. It is a great opportunity to stand in a room, hear a few people speak. And read the room and understand where they stand socially, where they stand in terms of their various needs. Those five questions I asked at the start, Henry. They’re all lessons I learned on my own. Those questions are a combination of diagnostics, as well as opening client’s eyes and giving them a reality check of where is it that they actually stand, including giving them that scenario of, are you sure you need to go live once in two months, and will you wait for two months to push a defect, or we should push out a defect fix within an hour. Right? Things like that. You learn this the hard way talking to customers.

So stakeholder management is a very big part of this. Learning how to influence people to directions that are good for them and for others is another very important thing. From a technical leadership point, it is even more difficult. And imposter syndrome often kicks in.

Here’s something, a lot of us who are employees, or even those who are running out of proficients. Let’s say you spend the past few years helping a client out in depth, with their Java Spring Boot app, which is using React JS on the front end. You have been dabbling with Node.js on the side for the past six months. Now this project gets over. You have to go to the next engagement where it’s all that Node.js. Once you actually start doing production level Node.js stuff you realize, Oh my God, there is a lot going on here. But client side people already have a bunch of folks who have been working with Node.js for the past two, three years, and since I’ve chosen Node.js, you know, Henry, we both know and everyone listening also, the JavaScript ecosystem, there is a humongous amount of tremendous amount of churn in that ecosystem. Libraries that are popular two years ago are not even known today for people who start with Node. Right?

So when you make such a transition, one of the things that hits you is, “Oh, my? I or my employer are charging the customer, you know, a bomb. And I don’t really understand all of this as much, but I’m having to kind of fake it till I make it to the clients. What is this? Am I not cheating the clients? Am I not, you know, cheating myself actually, right? Am I not fooling myself?” The answer is this, okay, it may seem unethical to have to do this. What clients are buying from you is not the answer for the day. What they’re buying from you is the ability to pick up that tech, to bring in all your engineering practices, to not get bored, and to be mindfully and willfully engaged on doing it, ignoring all other local politics and making sure that the delivery is met with the quality standards that they expected. That - they are buying that end outcome. They are not buying you for the day. The man-day rate and the man-hour rate and all that. That is a commercial construct. What they’re really buying is your ability to arrive at that outcome. So long as you can tell the client, “Okay, I do have parallels with another environment. Give me a few days. Let me figure this out and get back to you.” The first one or two times, usually people will be a bit civil and put up with you. If by the third time they see that when you ask for time, you actually come up with a production grade professional working answer, they will give you that time because you are now impressing on them that you have what it takes to meet the final outcome.

So as a consultant, you would be worried about the imposter syndrome, but remember that they are not buying you for solely your expertise in that particular tech, they’re buying you for your capability to deliver the outcome. If you ramp yourself up, if you diligently show and upskilling in yourself, they will be fine with it.

Henry Suryawirawan: [01:24:09] Thank you for your in-depth explanation about consulting and what it takes to do consulting. And I’m sure there are many listeners here who are consultants themselves, and I’m sure all of you can relate to this story. And thank you for that.

Also, I’ve read the books which you recommended me long time back, those books, “Secrets of Consulting” and “More Secrets of Consulting”. I must say that for all of you consultants out there, you must read the book. It’s very interesting, fun, and also in a way it teaches you a lot of in depth insights about what does it take to be a great consultant.

Stakeholder Management [01:24:40]

Henry Suryawirawan: So you mentioned a little bit about stakeholder management as part of your role doing consultant. What do you think are the key essential attributes that you should have dealing with, you know, managing stakeholders, especially the high C-level people or directors, or even some, some people who are so called the sponsors of the project?

Sriram Narayanan: [01:25:00] Goodness, Henry. We now get into the non-technical part of life. Okay. This has almost nothing to do with technology itself. One of the things that I have learned and which even Gerard and many other people like Alan Weiss, there’s another author called Alan Weiss who’s the author of “Million Dollar Consulting”. He’s another good author. There’s something that all of these have said, which I also learned the nice and the hard way as well, which is, there are certain implicit expectations on the consultant. There are reasons that we are brought in as the third party. Sometimes the customers already know what they want. They may tell it to you outright. They may tell you in bits and pieces. They may not know that they have to tell you, they will assume that you will know how to pick it up. But one of the expectations is in understanding that they are bringing you in to achieve certain outcomes. It will be called staff augmentation. It will be called to make us, help us deliver this program would be all of it. Often the person who brings you in is different from the person you actually interact with on a day to day level. So one of your first things to think of as someone coming in is, “Who brought us in?” The second is “Who are we actually working with?” So “Who brought us in, what do they want and need? What is success to them?” The second, “Who are we going to be interacting with?”, you know, which is the product owner, “What is success to them and what do they actually want?” You will have to lay these things out. The executive sponsor who gets you in - no matter how much we talk, and this is one of the top reasons that projects fail, right? Executive sponsors rarely attend showcases. They often believe their work is finished once they’ve gotten a very good consulting company and handed them over to a product owner.

So just to tell everyone what actually happens inside. What happens inside is, the executive sponsors are told by some board or by even higher up people that, “Hey, we need to get this so and so service offering out or so and so product out.” That person goes to the PMO. The PMO gives them a project manager or product owner. The executive sponsor works with a product owner and says, “Okay, take a few days or weeks. Think about what you need to have to make this happen and I’ll help make it happen.” Great. Product owner goes off, brainstorms a bit, comes back and says, “I’ll need such a development team. I need such kind of budget for environment. And you know, such support from security and ops people.” All right. That’s where the executive sponsor walks off, does all the social maneuvering to make a lot of this happen. And they go get a consulting company or, you know, an external software delivery company and drop them into this place and tells the product owner, “Here you go, I’ve ticked all four of your check boxes that you want ticked. Now make it happen with this team.” You see the product owner was not involved in selecting the dev company. The executive decided to do it on their own. So the KPI for the executive sponsor is - did they meet the PO’s needs? And will this product get delivered? That’s it. So the first half, they already met. For the second half, they’re going to keep grilling the product owner, because that was their equation.

Now we as people who come in from outside, because we’ve been talking to the executive sponsor, we expect to get to keep talking to them. Reality is - “No”. Once they get us in this, for them, their work is done. For us as outsiders having failed in other places, because the relationships are not managed well, we know desperately we should be working with these executive sponsors, but that’s where things often break down. The product owners have different KPIs. They have to just get things done with the team given to them. If things are not done, they’ll go to the executive and say, “Buddy, you get this team. It’s not working out.” This is where stakeholder management actually starts. We have to understand these equations. We have to understand what they are, how they talk to each other. What is their reporting hierarchy? And start surfacing reports and status in a way that makes sense through the whole hierarchy, to all of them. Because like it or not like it, even if the executive sponsor attends our meetings now and then, the client side people, the PO and the executive sponsor will still have their own internal meetings. At that time you want to arm your product owner with reports that give a status that you can back. Okay. I will not use words like that. Give the true status. You should be able to give the status that you can stand by, that you can back. Is there some reason something is not working? Not a problem. Put it out in a report, send it out. Is there something that you goof up in? Diligently, put it down along with plans on how you plan to remediate and then to spot it to prevent it. Put it down. Put it down and keep sending it out to the product owner so that they can take it and show it to the executive sponsor.

Very often, we as consultants will feel, “My God, no one is giving me the credit. The product owner is busy showcasing all these reports.” The truth is yes. They will do that. They should do that. For this overall success, let them do that. You know why? Because when the next engagement happens, that product owner is not going to be developing that software. You get to do it. Everybody knows that the product owner did not have to crack any whip in order to make you work at a level of efficiency, you just are efficient. They are merely exchanging their reports to check with each other, are things on track. So as long as you can show reasonableness, the ability to be Agile, that means to be able to respond to change. And so long as you can show that you’re upfront and transparent from your side and you invite their comment, they will come back to you and say, “Can we add two more requirements by the same deadline?” That’s when you should be able to say, “Tell you what, I can add those two requirements, not by the same deadline, but I believe in a short time after that deadline. So can we have incremental releases? And I will keep you updated if anything changes, I’ll let you know.” Once you do all this, right, with your regular reporting and everything, you should have bought their faith. Because all that they really need to know is, “Is a project on track? Will we be able to deliver it on time and in budget? Are there scope that we can or cannot deliver? And if there’s something that we cannot deliver, by when can we?” That’s what they know, because they need to know, because it’s a matter of cost, time, other business goals being met. Once you understand this, you can manage your stakeholders better.

3 Tech Lead Wisdom [01:31:15]

Henry Suryawirawan: [01:31:15] Wow. Such so much in depth explanation again from you. You know what? I mean, we can talk for hours, you know, talking about other stuffs as well, but I think due to time constraint. Normally I would leave a one big question for all of my guests, to share their wisdom to the listeners here. So, I have one question for you, which is, what are your three technical leadership wisdoms that you would like to share with the audience here?

Sriram Narayanan: [01:31:39] Hmm. So quickly to tell you. Number one, identify what is the problem to solve. I’ve given a number of examples over here. You know, what to approach when how, value stream map, infrastructure first, stakeholder management.

The second thing I would say is, identify what is it that the customer actually needs, and then figure out how to convey that to one and all. I have made my mistakes. I’ve had my successes on this. One important point over here, I would say is, as part of figuring out how to convey that to one and all, there is a difference between understanding what they need and conveying that to them versus being right in what you conveyed. I have lost one or two deals because of this where, you know, in, in my spirit, I went on to tell them, “No, no, no. I’m telling you, that’s what not what you need. You need this.” Whereas the better way to tell them is, “You are asking for that. May I tell you, it gives you those outcomes. If I were to just put on my thinking hat a bit, it seems to me, you may need these other outcomes, which can still be achieved by partially the same effort. What do you think? Please think about it. Let me know. You can get back to us in another few days”. Right? When you give people room and time like that, you figure out how to communicate to them, “what is it that they may actually need?” And who knows, they may realize how to communicate back to you better that why they need something else. It’s not always that you’re right. Often other people are. Yeah.

My most important thing is absolutely nontechnical and non-social, it is actually your own health and your sleep. I’ve learned the hard way. And you know, many people say this, you know, they, they are hospitalized or they fall ill again and again, and they can’t think, and they lash out at people. I’ve been one of those. My harsh lesson learned is figure out what it takes to fix your health and to get very fit, and figure out what it takes to get great sleep.

There are various sleep tracking apps. You know, there are, there’s this ECG based headset that I wear, Henry, I have shown it to you. There are all these kinds of things that you can do. Depending upon the app, there are some apps that say that you should have 8.5 or 9 hours of sleep for three days continuous. Right, it’s like a sliding window. There are other apps that say that you can fix all sleep debt with 7 to 10 days of proper 8.5 sleep. What I have seen, if I can sleep for 10 days for 8.5 hours, then the kind of thinking that I’m capable of is far, far higher than what I normally can think. Which is a scarier thing, because let’s say, I might have an IQ of 140. If my IQ level drops, my ability to think drops, up to some point, I will realize, “Whoa, I’m no longer able to think like I was thinking this morning, right? You will realize, “Oh, I’m fatigued.” Let’s say it happens over a number of days. By Wednesday you realize, “Oh, I’m not even able to think as clear as I was on Monday.” If this continues, by next Wednesday, would you even remember how good you are able to think on Monday? Would you even remember? You may not. Let me tell you from personal experience, you may not remember how good a thinker you can actually be. So sleep helps a lot. I’m sorry, I’m emphasizing this a lot, but I have lost a few deals. I’ve lost a few friends. And I have to bend over backwards to apologize and everything. And even then the relationships are not good. And there are enough problems that I have not finished solving on time because I was too sleepy. And this becomes worse when you have a very dedicated ops team with you. There is an XKCD comic on this, 705. It becomes worse when there is an issue, and everyone is standing around waiting to see how to solve it. No, that’s the worst thing to do. Half the people should just go away and make sure that they sleep. Because when the first team has not solved it, the other team has to come back, take over with a fresh mind and solve it. But if the whole group was there and they jointly become sleepy and fatigued and tired, my God, the problem’s not gonna get solved. So, please sleep!

Henry Suryawirawan: [01:35:32] Wow. Again, so much insights right to the end here. So I must say personally myself as well, I’m trying to improve in terms of this general health, sleep. Sleep is still one thing that I would want to improve. You know, I want to have continuous 8 hours sleep. It’s still a challenge, but yeah, I mean like the point when you mentioned sleep, right, if we are deprived of sleeps, there are so many issues, not just in terms of health, but also in terms of your capability, your so called intelligence could even drop. So I read a fantastic book by Matthew Walker, “Why We Sleep”, it’s actually one of the best book, if you want to understand why sleep is important.

So thank you so much Ram for your time here. There’s so many things that I think I would look back and, you know, learn so many from our conversations here and I’m sure the listeners here would agree. And again, I wish you great health and success in the future.

Sriram Narayanan: [01:36:27] Thank you very much, Henry. And I hope to soon share with you and the audience about my upcoming book, which I’m working on called “The Journey to Continuous Delivery”, where I am covering a lot of these with diagrams and explanations, checklists on what to follow and whatnot. Part of which I also want to cover what does it mean to aim for trunk based development? So, yeah, I hope to be able to… There I’ve made a public commitment and now I’m going to uphold it.

Henry Suryawirawan: [01:36:55] Right. I’ll be waiting for that for sure. Right. Thanks again. See you, Ram.

Sriram Narayanan: [01:36:59] See you, Henry. Bye.

– End –