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

Before we start today's episode. I'd like to announce our lucky winners of the jetbrains giveaway contest that ended a few days ago. Thank you so much for all of you who have participated and sharing your feedback your learnings and your kind support either on LinkedIn or even directly to me. I really, really appreciate all of that. And I do hope to grow this community, even bigger going forward.

And I need your help to share this podcast to your friends colleagues and others who you think would benefit from it. So, the three lucky winners of the contest are Our Prime sunde Eliza and Jerome. Congratulations for winning the jetbrains. All products pack, personal license, and thank you again for participating. So continuous integration, when you are integrating the day over there, 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 continuous delivery is when your code, isn't a Deployable State and functionally, correct. Hey everyone. My name is Henry sura, one. And you're listening to the

tekhelet journal. The show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hey everyone, welcome to a new episode of the tekhelet journal with me Ojos Henry Surya with Robin.

Do you know that tekhelet journal provide comprehensive episode show notes on its website at technology on o.f unlike majority of podcasts available out there. Pecola Journal provides full transcript that you can use to follow the discussion or even such favorite parts of the conversation that you would like to go back to for deeper understanding the show notes page also provides. Ides. Interesting quotes that are

personally. Curate, and also the list of links and resources that are mentioned throughout the conversation. And if you are like me, who listen to podcast 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 technology on our website at technique Journal. Deaf. It is my mission to provide the best possible medium for all of you to consume the podcast

content. And I would To hear from you. If you have a good story on how you're 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 Shri Ram, Narayan on 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.

ROM is a principal consultant at thoughtworks Singapore, helping customers on their Ernie 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. History 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 touch 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. Mine in, probably get some coffee to enjoy this episode. Let me know how you like the conversation and don't forget to

subscribe to technology. You know, if you have an eye you start up in software development Which is less than five years old. If yes our sponsor at jetbrains have a 50% startup discount offer, which allows startups to purchase multiple products and subscriptions for up to 10 unique licenses, over a period of months to find out more search for jetbrains startup discount off. Are you can check out the link mention in the show notes? Hey, everyone. Today.

I'm very excited to meet one of my mentors in my career. So I met three Ram, Narayan in thoughtworks Ram is one of the thought leaders in the industry around continuous delivery, a gel 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 wisdoms. And Jesus of his career that we all can learn and apply for our career as well. So without further Ado, welcome

rum, thank you very much. So from looking at your career, I must say that I'm pretty stun in terms of your progression from your 14 15 years journey in part works, you gradually shift from like being a junior developer up to a principal consultant up to. Now consider one of the thought leaders within the region. Can you probably share with us? What's your You like and what are the major turning points in your career? That could be shared with all of us here. Thank you, Henry, for their

generous. Praise. The truth is I've been really fortunate. I have been very fortunate to have had the right kind of mentors and support in my journey at what works. And you 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 am the

stupidest person in the room. I've not gone through all that much of 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 fifteen and a half to 16. I had to go start partly my own businesses, partly work for the people.

And when you just kind of finish 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. Woman on a day-to-day basis, you know, especially when you're that young, you are not going to be a high-flying consultant with a fixed guaranteed, minimum

salary or month, right? These are all the small jobs or jobs that you get to do and what 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 exposure to businessmen who would freely share with me what our strategy is and then make me be part of it as they executed make money. When you're really young people. Don't mind sharing a lot of things with you.

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 business is run computer, training institutes and in mice, to assemble, and sell PCS. I even had my own aquarium fish

business. I have done a variety of things like that, you know, some things related to IP something, it's not, I have to shut it all down, and go and become an employee full-time employee at it. The term I got the chance to work with very good. Small stalkers. It's to my regret that I do not become very, very good at small talk. But I got to learn object-oriented design from some of the best mole tacos in the

world. We are talking about people who are architects of things, like visual aid, Small Talk, amazing object-oriented design principles for you. I the only really good people, so that got me through understanding. What is it take to deliver. Then, I had to, you know, again, economic downturn, yet, again, they have to cater to the India market still.

There are fewer catering to the Global markets and I had to again, you know learn what is it mean to go make a call to a customer and tell them we are very good skill software professionals. Is there some problem for you that we can solve that one sentence which is identifying, what is a 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 what works. My interview was good. It was an interesting interview at That time I felt it up with not so great because I came from a very small town, very small company.

And these were people who were used to working with the global pool of very, very skilled developers with a frame thought, work software development Network and they have full International exposure. So the kind of problems that I used to solid leads to Stronger very different. So, for example, in my interview, there was a mild amount of hostility at one point even wear. One of the guys said, hey, you know, we don't believe in just sit in creating all these Frameworks, these solve actual

problems, which was correct. Because at that time, they would These large muscle framework accompanies who just keep churning coat after coat after coat and not only shown in value, but thought was being very agile, was all about showing value right from day one. I have not really understood that that is what they are doing, which is what I was also doing because when you're a really small company, you don't have the luxury of resting on your brand but I did understand it.

Then my immaturity so I wrote out it back to them that they have you written some. Let's have you use spring when they said, yeah. I said, yeah, people like me right 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, think and go

very bad, very, very rapidly. However, they did take to their credit to, you know, both my colleagues Deb later became my colleagues. I became the contrary to their credit. They actually prove the bit saying, what do you mean? And I went on to talk a lot of energy of Tomcat and House of let's work. And what is Peekaboo, JSP generation and whatnot. And we dove into a bit of deeper technical or stuff over there.

It actually went well. My final interview was also really, really good RJ RJ Guru, you know, IG have. And another colleague called wishing for my final interview was very, very pragmatic business questions RJ. When he heard that I enjoy cam programming with Visual Basic. Whoa, he Deep dive into it. And I really enjoyed those things with a discussing tlps and interfaces. And what is it? Take to align. Code in memory. Wow, that's when I said, oh

right. If I have very good Tech colleagues like these, this is a place I wanna work at. So I joined thought works that way. Yeah, that's around Fourteen and fifteen 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 is another very good. Colleague of ours are thought work. You know, him Henry, SRI Ram,

Narayan, right? The same name as me and a very similar surname to mine, and he tells me that then it's just a clerical error because of It just different places. We actually have the same surname. So this Freedom who only, he was my mentor. Then he still is my mentor and party and all of it. He identified very soon enough that I come from a small company, and I do not understand all these large company setups but was uses. 120 people at that time, but for me, it was large

coming from a six-person group. So he taught me that a consultant can influence the story card when they're pairing with another person. A senior consultant is usually one who can influence their team in terms of feature or story directions. Without needing the supervision

of a technique, right? The end up becoming defacto techniques and Lead consultant, which is the next hierarchy of thought works 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 the officially appointed techies. It gives a client requires such a Tessellation and principal. Consultants, of course should be able to influence Gaeta 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 it. Please to build as far as to even engage myself. Does the company of me a promotion just because I've spent certain tenure here does the company only or promotion just because I've helped, you know, in certain engagements, or am I already performing at that level where it's just very naturally said, here you go run.

Here's your promotion. You are now here by. So, and so very, very very insightful thing. And it really set the direction. I would also say that in the middle of all this briefly about As we can between and you know, I had a two-year campaign to ask him a company.

Why am I not yet? A principal consultant have I not influence this have a mountain 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 the clients and indeed. This is what now when jr. Thought workers asked me. Hey Ranma, how do I get promoted? What should I do this? That I'll be very candid and say, half the time they asking, is there any system to game?

Honestly, there might be, I don't know because I have 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 will 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 caliber.

So I just gave up on all these designations and hierarchies because I had got a 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 run after designations.

Like I said, I was weak in between I did none of do 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 are a prank on. 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 mopping, and not II know that the Fang of kind of somehow naturally or why coordination figured out come up with Drop it levels. So someone from Netflix of 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 that 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 customers needs? Can you made sure that you identify and eliminate?

Good quality issues and completely reduce the turnaround time from requirements to go life. 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, hmm. Thank you. I mean, it's very insightful,

obviously. So one thing I also realize your progression is not just linear in terms of row, right? You basically, Really, I think started from like a sysadmin row and then gradually move on to become a developer and gradually move on to become more like a gel. Devops consultant. All these are very interesting, very very amusing. You bring it up Henry. The thing is, I actually joined what works as a developer in the

company. I also had earlier, I was a developer for about six years and then I joined what works. Also as a developer for about a year of full-time for the next six months. I became what we now call devops. These are used to take care of build and release engineering first year as deaf second year as build and release engineering, and then a giant tap me and he pulled me out of all of this and got me to his assignment team. So I worked there for about five

and a half years. As one of the sustainment support works. I Was Made It manager and everything but I tell you when you're working with sysadmins of a particular caliber who I used to sing 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 Tricky situation. Once when I HR lady, she came and gave me a letter and said, congratulations Ram.

You are now a lead consultant. We are mocking or 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, you know, meant it would have never called 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 cloud formation and something and, you know, hey, I'm a divorced guy, you know, Jenkins, pipelines, or whatever. Sorry, that's not the real obstacles that you just learn to use certain apis, but actually working with Ops people understanding, what 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 snss admin because many people have seen me talk. A lot of sysadmin ish things. In fact, I used to be known as I as ROM. Means information system strong right now that used to be my nickname Henry now, in Southeast Asia, you know this in India, if that's what everyone called me. And there are entire Generations. Who don't know that actually write code.

By the way. I was also known as Solaris, ROM because there's a lot of stuff I used to do that. So anyway, yeah, Henry, like I said, at the start, right, I have been very fortunate, the exposure that I have got, which is I got to run my own business has non-id and ID. I got to work in a very small. All company with, you know,

Swiss and German banks. Then I go to work in Port works, are said there for a year where I had some of the best experiences at sriram, who took all these hierarchy things, out of my head. I had our colleague sukhna, maheshwari, 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 Nike who Henry, you know, asthma he's still in. Talk about Singapore and Maher.

Taught me in about 10 minutes. What it means make If you have continuous integration and 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 to do it operations, where again, thanks to our agenda, kind of autonomy that he gave all of us. I got to become the it manager.

I learn to set up a data center. I learn to it was my inspiration at that time that I should be able to place purchase orders of a ten thousand US Dollars. Talking about ten thousand dollars. As a month is a very big deal but to his credit RJ, trusted me and one or two other colleagues to set up entire data centers. The company, backed us. They putted 300,000 dollars, 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, Santiam of virtualization team, you know, you have people then who will be Operating system Specialists, right? They'll be a whole separate security team out there Venice

when we were at that time. At what works are is team was just 12 or 14 of us around the world because I was in Bangalore and it's a major Del V Center for a lot of our projects are used to get onto the call with customers. So they would say I'm from Saint. I'm from hypervisor am from switching. I'm from Network. I'm from security this that and then I would say, I am wrong. 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 that I can tell you in the eye. Tirol, 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 a mode SD, or on 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 worked my sleep and everything, right? So I can just share if Esther Dyson. Woke up at four am very grateful for how my life has been so far for my good health, and my income and my pains and, of course, all these learning opportunities. So, yeah, Henry, that's how it is beam. And I can tell you, I'm very, very, very fortunate, very fortunate really. So you mentioned something about one of your colleagues.

Mahara, right? Who explains your continuous delivery in 5-10 minutes, right? Maybe you can share with us as well. What is actually continuous delivery sounds good Henry, so just to clarify At that time, he had not had the buzzword of continuous delivery. Yet. My I 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 a child. And it means so many things that

are people who think that. If you have jira conference on that last rinse week, they called a child. There are others who say, if they do that 3,000 on the scrum certification. I don't know how much it cost that you become a giant or whatever. You have an agile transformation officer. So same way, right? And the way it has always Or diluted and with your interpretations that develops.

Also the same thing as happened with the acronym CD in V. So CD in cic D, right, the CI over there is continuous integration. The CD, honestly, depending on who you talk to can be, continuous, deployment, or continuous, data field. There. Are those who say that? Oh, I'm sorry. We have CD. That is confused deployment. Therefore. We must go live. There are those who say, oh, you know, because we ought to have a bunch of gatekeeping checks. We can't have CD that is 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 the day of 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 I be a branch for a

feature or a story? Should every individual have your own Branch. The truth is in a subversion days, right? These were all a little bit of an issue. Yes. It's abortion also copies achieved but with get it is cheaper. The thing that get is When you have a local copy, what an entire separate? Repository, never mind having to subtract. You got ahold repository of your own local, right? So essentially or integrating with various repositories.

That's what Master means. So continuous, integration is, when all the deaths, 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 punch. That is continuous integration and if you do it with Best of efficiency you can reach trunk based development. Eventually continuous delivery is when your code isn't a Deployable State and

functionally, correct, right. That is continuous. Delivery. Continuous deployment is, when you realize, hey, look about all these gatekeeping checks. They are all automated. Everyone is happy with their respective gatekeeping checks and we all feel that, you know, if the the gatekeeping checks have passed, we agree with this artifact being good enough for us. That's Go live with it. So if you have that, then you

have continuous deployment. Actually, the owner of the environment, the product owner, the system Zona, 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 gate, keeping checks, then go for it. Otherwise don't just push continuous deployment and then, you know, sabotage yourself. Hmm. So I can see their love important things that you should have in a continuous delivery. Very 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? Wonderful, wonderful can be, so just instantly 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'll just tell you the end. Goals, okay, the end goal should be that. Your code should be Deployable and functionally, correct, Now, jazz humble. Dr. Nichols Force, grin and Gene Kim, right? They all work on the dura metrics develops, research agency, right? They came up with the Torah Matrix where the expert level and Adora Matrix is you should be able to from commit to go live in less than an hour. This is where you should aim for so where you get started is

literally that do you know? Is working and what action do, you know the versions of your artifacts that are in production? And you know, the version of code that they are tied up to? Okay, let's split this in two parts where you get started and how do you know that you have the good continuous delivery in place? Right? So when customers call as in and they say, look we've invested in all the rights, eicd tools. We have done this and that in everything in my head.

I grown-up it. Because when I hear CI CI, 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 a cheetah, you know, they'd of forced a bunch of divs to write a few tests and all of it, and they will say that we will have ABCD environments. And with this, we're going to go life and nowadays. The new thing is, if you want to do all this you better have

microservices and kubernetes. Okay, too many 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 a Okay, my second question. Do you have an automated test Suite? Yes, we have an automated test. We 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 ready to answer to me because they don't know why things are going on. Hey, not a problem. And that's when I tell them, look, treat me like a doctor. If you go to a doctor seeing a sprained, my ankle and they laugh at you and say hi. Ha, you can't even run. Look your spraining an ankle. What's the point of them being a doctor? They they need people who have made mistakes. They meet people who do not make a mistake and things just happen to them.

Right? So that's what I tell Cosmos, please. These are not supposed to embarrass you. They're just hard questions. You want 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 try out your defect and understand? Why did that defect happen? 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 identify the defect and fix it. How do you know that you do? Not undo anything else that was already working, right? That's my next question. Usually, they don't have an unsightly. 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 through all your gatekeeping checks into broad, again, tell

you Hindi at this. When people, you know, they they they realize the more major of the managers, the realize. Okay, it does. Look like there are opportunities for improvement. Then they asked me hey, what is the industry best practice when it which is when I tell them about the Dora expert level, which they say. Oh, you know what? We need to go live only once in two months. We don't have to go like once in

an hour. You don't, we don't have no requirement to go live with the Nano, which I said not a problem. I'm with you. I'm sure you have to go live once it too much because of integration and partnership agreements know. Problem, but if there is a production defect, can you always afford to push all that 6? 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 decimal answers to these things then they ask 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. Aunt does not take away defects your code. Okay, it does not guarantee that from the time you start your diplomatic will actually finish nor does it guarantee that.

Whatever you're finished deployment, will actually be defect free, which is why in my definition of continuous delivery. I saying the code has to be in a Deployable and functionally, correct. Stay. 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 of what is, you know? There is more to all of this pain just having a Jenkins or

Vegeta, right? And and let me just add one other thing, because I brought up the face eicd 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 on the, 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 or either. So, it's as I keep explaining to customers, I make, they realize the need for For a test Suite, they realized I 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 updated as they learn all this. They realize that there is more to this than just CI and an agreement to do a continuous

deployment. That's when I tell them, let's stop saying see ICD, 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 base development with devs, merging on trunk in a most efficient, merging they are merged on trunk, but you get an artifact which is going to save their for the next two months while every Gate Keeper goes through guard, won't process of promoting it ahead.

Right? There's your continuous deployment. It's not happening. So that's how I work people away from the phrase CI CD, which is limiting to them towards the correct phrase, which is continuous delivery. Hmm. I see. 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 a 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? We're at, right? So, is there any like, maturity level, for example, a small team with few developers they want? Implement this, obviously, they won't be able to achieve everything and 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. 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 made, sure and come to terms with. The fact that people will take a small, a 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 the stock. If it actually ranges from this to this and have had to deal with both the sides and all things in between. Here's what I do.

So one is Henry as you saw in the Windows File questions. Our code should be in a Deployable State and functionally, 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 at? This is a very good question. Where do you start in Greenfield projects? That means very these start from scratch.

This is easier, you know exactly what to do. We set up a CI will agree on trunk key start test. Driving and life is great. What do you do? When you are a team who already has code, you already actually understand the domain. In fact may even have working stuff in production for maybe even a few years. Now, you go through these five questions and realized my God. I don't have really honorable answers for these and I have a 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. I 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 and prod, this goes from prod environment, composition? That means how many VMS or servers and all of it? Who are you connected to 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 word 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 that in entries. Can you force your confirm say that? No one has made any changes on prod often? We cannot see that. You do not know that.

Did you go and Hot Patch or you know, to any config file or a code file to apply a patch or a fix and 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. Things that includes talking to security teams and understanding what are the settings that they have applied. Some security teams are very secretive, but I can tell you gently, all security.

Settings are usually based on the sea is 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 Aging starts, and I'm using these words carefully here build scripts and package and because for example, someone might use Gradle you just come up with a word file, but they might choose to repackage that word file and digitally sign it using somebody else's script. You know, the property might give a script for that or some other products. T might say, okay, here you go, run this RPM.

We will take your hold, 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? Make sure you have an energy conversion control. Then the third step would be, can you recreate those broad artifacts? Will you meet? These are such interesting and painful things to go through, you know, because you will realize that they're only

specific machines. And when certain compiles, go through their 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 the energy of that. Also. Now, you It 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 Rod all the way back to them, which includes the security settings.

It includes the OS versions and patches. Then you come up with your second track of activity, which is how are we deploying? This can be use the same deployment scripts to deploy in rod, and and Dev so that you have consistent deployments. The third thing is, can we have consistent configuration? And we configure in-depth 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, am I, and the VM up, but beyond, that is your responsibility. So, that's not a time to say, why is a 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, reconfiguration 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. And 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 very natural. There are people who say is Si T, green. Is that are working in Q&A. If you are T read today, or is it Greed, for how many days as you ATP internet? That's all nonsense.

You know, what does it mean actually for an environment to be read? And environment is a composition of the physical infrastructure. Let's take it right up to Virtual. Also the Deep 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 are all of it. It's all of these things together.

So there is no such thing as saying is you a tea green or ssit Greenock. You agree. Know, is that build working in that environment to remove the variable and unpredictability? First, get the environments uniform but you get consistent with deployment configurations and balloons, right aging. Once you get to this, it removes a variability of it works on my machine. It works on cue. I don't know why it's not working on Unity. Once you get them all uniform

and certain things consistent. You're good. 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 automating tests in place. Thank you, which kind of brings me to this topic about testing pyramid, right? Yes. I'm just 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 First and that.

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 and Patty, creating an inventory of your production figuring out the Version Control trying to sort out the bills, you know, making sure that your build machines are recreated build these. All of these activities can happen in parallel and it is fine to happen in parallel. In fact, it's great time-saving. It also gives ideas on others on what else they should be

checking for. Once you have these things sort out Henry. When we can actually start leveraging the test, the automated tests, which. 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 of their Dairy companies. We all know them who have entire testing offerings, are 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 kind of companies, you know, there, they'll take your coat. They've take your artifact. These are testers, who check as far as the test cases, what are the valid and invalid State Transitions and which of these valid and invalid State 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 it's going through a spreadsheet and declaring or you know, your app doesn't match these 400 out of these. 500 different test cases. I've got each other's Rose in an unfortunate spreadsheet. The real question is, how do you arrive at that spreadsheet? One of the things you do is go to a state transition plan.

This is what you have to do. When the devs do not test drive, which is what gets us to the test parameters. I think it is a waste of people's time eventually. Okay, and, 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 4 plus 3 should equal 7, there is no fun and damn validating 4 plus 3 is equal to 7 and every buildups given to them. You should actually automate that. This is where these are the kind of test that we should automate. So Mike cone, you know, who do the test parameters. Martin, Fowler blog about it, and I used a diagram, a lot in

my conversations. I use a test parameter to say, Two, doctors, tell us or automated tests should help us understand what Fields where it failed at. Why it's sealed, which various tests been used by various people. So the vote 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 do not work, but I could search for an item and argue to the shopping cart. Very nice. Where did it fail?

That's when integration test comes into play. It says that other shopping cart service, with some other Our team. It turns out that when we made an API call to them, they gave a response code and it failed, right? And integration tests will tell you that a unit test. Tells you, hey, I am using that shopping carts, a stub service. We are supposed to pass three parameters to this API call. We are passing only two, so it's given me a test error or test says 4.

Plus 3 is 7 4 plus -3 is also 7. Sorry. There's a problem. Unit tests will tell you things like that, right? Because 4 plus -3 should be one. Correct. So four plus three is seven is an acceptance criteria. For plus -3 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 card and check out is another acceptance criteria, but you will see that these are all at various degrees of granularity from a triaging point of view from a knowing something broke the Double test could not at work, got is great. But from knowing why it broke the fact that you passed two parameters. Instead of 3 is what actually lets you try your shoes 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 then I'd work with experienced developers and make them understand that what we are following his release according to specification. So when you go to Ocean 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 a unit level and you keep working your way up words, you will find that you will have a massive amount of unit tests. Some amount of integration test and an even lesser number of function tests, right? The adding something to account, right? Or clicking the check out button. So once you look at all of this and you spread it out, it becomes like a pyramid,

humongous number of unit. Some amount of integration tests, even lesser number of function test. Once you do this, you can spare your Q&A from having to, you know, like a drone teeth. Clicking search for an item added to our clock. Click it. Check out 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, who by the CI CD medicine here just declare do, everything has to be 100% automated and And they will thump the table and demand at many things, which cannot be automated testing should also be tested and, you know, it just becomes a Missouri game. So no fun. They're no fun. The, the point of the test parameters also, to tell people that just because you have a QA team does not mean that every particular code flow path in your app should be tested by you.

I that may not be the case. For example, there are I have been an e-commerce setups what they have said that I want every product. Degree variety to be added via the UI and tested. I don't care that you have, you may, or may not have lower level test. But testing team, I'm paying you to write this group better, right? It's all these kind of, you know, UI test. I can tell you, Henry.

I have been in situations where I've seen some 6,000 .ui Tesla, and then we were able to work it out with the client and show that the same code paths and a variety that's happening on the UI, level is already being tested at a much lower level. So if we cut down the ui's, Our test Suite size from 6,000 to just 30 or 50 that frees up that UI testing devs. It, frees them up, you know, coding testers. It. Frees them up to automate further other things or if they're actually excluded

itself. They can do that. So it's a bit of a journey and you have to show this to customers. There are tests, 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 am coming and saying, cut out your 6,000 test and replace them with He's totally. 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 66 thousand tests. And now I'm Throwing It All Away in double quotes, you know, Throwing It All Away to just remain with her teeth. 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 we losing of their safety net, that we paid for. You're 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 at sometimes. I would even say testers who are 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 starts search for something.

Add. Thing navigate, now we can navigate check out. Let's say this takes 10 seconds in those 10 seconds. You might have as well run some three to four hundred unit tests depending upon the computation code over there, right? And humongous, number of UI paths that people would want you might as well tested at a much much, much lower level and finish your whole Community.

Will Matrix over there. What is really required is to show the costs of maintaining such humongous test Suites and the course of not performing a Exploratory tests. And also the cause of breaking one's head and trying to achieve 100% automation of all conceivable, usage scenarios eat one of the ratio test. Whereas you could have just said, okay. These are things let's just manually verify them and move on.

So these are the things that people will have to do because no one answer but these are the kind of things you. I would pay attention to these days Technologies move so fast. So rapid, in fact, like every few other days, 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 much younger in terms of professional experience, which is sometimes 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 do you think about that? How should people approach these so-called buzzword driven development? Yahoo!

34 so one of our colleagues, you know her Stella, so Stella and Ivy ran a few continuous delivery pipeline workshops, and he thought Works 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 team city is very good on it.

They don't call it build Partners, they call it will change because that's what they are. One of the interesting when Stella and I were putting together. FAQ right. One scenario that I threw at her as, hey, Stella. Let's say it's a company of just you and me, both of us, writing codes sitting side by side. Do we still need continuous delivery. Good question, 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 look rather long holiday. Also, the tip in her absence. I don't want to call her an instructor, but there is a particular defect, a client has reported. I fix it. And now that client says, Whoa, you fix this. Do you think it will undo that

other feature you built for me? I have to know authoritatively, without calling Stella. This fix that I did did not undo something else. So if my code is, has to be functionally, correct. It's not enough that I just have a CI where in the code went in the thing went green and I have an automatic deploy, an app to shoot it to, you know.

Amazon will ever know. I have to have the right test Suite that says these are all the functional acceptance criteria that we had and run value made this fix. Did you break some of the existing acceptance criteria? You do? I relate that acceptance criteria? Fulfillment. Yes or no, so I should be able to tell the client come buddy. I know Stella's not around and you're worried about it. Here you go. Here's a test video 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 sole operator, right? It's just me writing my own cool internet to no sensation. No problem. If there is a paying customer and this is one of your startup fears, right? This things happen that when suddenly there is one heavyweight customer for whom 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 have better have the right test Suite which tells you oh, if you do this, you are going to be disappointed. Those are the five customer. So continuous integration right? Is not just that a CI system to check out your code and compile it and keep it ready right here. Also means that the known acceptance tests at least a functional acceptance test, to the extent, possible are automated, and they are captured, and they're 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 Steam and your automated deployment, you The client decide when they want to deploy, you want to continuously apply go, that's just a flag. That's a flag that says, if this pipeline past, I'm happy, you're pushing it. Don't want to do an 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 collect so much young. I would just say he's exposure to various blog posts and whatnot. And they hear continuous delivery, continuous deployment, and a thumb, the table and say we better deploy continuously. No problem. Problem. You can deploy continuously if You know that your 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 opens 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. Some people write who are confused with all his hands at even my contrarian views.

What's on the market? I would say, look, let's accept that accept and acknowledge that it's a 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 buzz word, or no buzz word. 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 yours. Years of experience because the maturity that it takes to arrive there under wisdom, you will gain from making mistakes. The really serve your purpose. Mmm. 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? My goodness? I think one of the better decisions have taken in my life is to regularly. Keep diversifying. Don't stagnate keep the opposite. Fine.

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 service side, some service apis and a database. Let us also further assume that they are going to be deploying this on Google as your or AWS Zone. 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 or there's now the mern stack o python is gaining popularity. Look look, look that AI company just got funded 20 million dollars, man, and they're doing everything with Google Kara's and here. I'm stuck with the springboard. Oh God. I'm outdated dinosaur already, right?

It's a difficult but 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 updated? 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. All, if the kind of close to completed 15 years at thoughtworks by now still, every do audios. 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 down 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 loved it. I'm using kubernetes now. No, no Mom. That's not how to succeed. So my suggestions would 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, see and Unix, that's what I used to teach them. And I thought I'm gonna learn this that and everything but just learning C and units itself was a lot for me at you. Then one day. I got the opportunity that some other senior faculty who was teaching Windows programming. You just quit and went and these small institute's, right? You don't have too much of professionals and 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, just come in a few years ago relative to my time then. And it was an 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. We did not really have computers at home.

So go to 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. Oh, 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 am now, the new risk guy and I'm sure our audience will identify with this, because once you become good at your text, and you can churn out code in a day one.

It is new, guy comes in and install something Visual Basic 5. It blew my mind. The stuff that I will take about two to three hours. He just click to three buttons and had an executable out. My God. I was outdated every sort of doing it, right? And that time all these months that had poured me just disappeared, man. I thought of this will not do and I was just some 18 or 19 years old at that time and I use someone in my locality who was a

union officer, you know, work. Union officer eyes are. I'm sure these people have a protested to management and all and saying remove computers room. All these people 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 it never comes. I said, oh I want to be violent. If you stop the only guy who knows it, how about you become the next guy, who knows it and know it better than him. I got Henry. I'm telling you my life changed from that day. I have made sure that I don't just use a technology. I find out how and why it works. I'm good. It's plumbing. And I go on from there.

The reason I gave this example is you will always get Addicted. But you have to dive in a bit, understand a bit of the fundamentals and then you know what, the fundamentals just translator JavaScript Frameworks at the end of the day. It's a single threaded text track, all that it is going to do is just omit some HTML, no matter what Million number of

JavaScript libraries. You pull in at the end of the day, accomplish certain activities, if you write and that much switching from one message to likely to the other, should not take too much time. If you understand the notion that node. Is single threaded, whereas the jvm is multi-threaded, that can teach you a bunch of stuff that you can and cannot do. Hmm, yet. Again, Henry, I gave this anecdote for a reason.

Some years ago. We had that the table stays 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 Said, Rommel ask you an archery based analogy. His scenario was, he is working for a king whose employing archers.

The enemy King is having people with much more powerful crossbows. So, here, it 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 then with a crossbow, but with the crossbow, that the velocity and the points that it packs is like three, four times that of an Archer. Okay, and I have a crossbow in India, and I know How awful it can't be. Yeah, so just to share 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 show to your peers and show it to your king. Tell the King. This is what we can do with a crossbow. And this is what we are up against O King. Also going to adopt the crossbow. If your king is Going to add up the crossbow. Then my dear friend, give the archery 10 and go to the

crossbow tent. Wow, interesting, anecdote. Yes, it's fine to, you know, deep dive into Tech. It's going to do a lot of due diligence and your visual for the client and the team and be sincere, but also do not get siloed. Do not a bank or a government or a particular company. Specialist. Do not because you never know when you get so typecasted or suicide. Load that you actually cannot add up to something new right that you can't do it at that.

Stick into a 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. Mmm, right. You are not here as a technology, specialist. You are here as an outcome specialist. Great job before. Wanted to be Java 8 entropy Java 12, but then One Fine Day growl comes in. What is that mean for you?

Right? Because there is 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 their leverage girl dead 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 or no, because they will VMware, is not sticking to VM back. Even VMware is expanding out. So, why are you being so loyal? Mmm, 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 applied in your own career as well. So coming to my next question, right? You mentioned a couple of rolls like developers infrastructure

Engineers, right or devil. What people call these days and then you have this Q&A or testers, then obviously, there's this security people as well. So, where do you see? Security comes in the sea ICD 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 to separate people or role to actually certify the builds. Wow, very, very, very

interesting question. So Henry, Ford, Of the, where do we start is also once you understand a lot of these things is also to draw the entire process tree from the time. Someone decides. We need this project till the time they say, yes, we are the live for three months and we are busy enhancing features. What does that entire cycle of that? Right? There? Is 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 time? So you have process a which takes 5 minutes, then you wait for one hour, then process B, which takes half an hour and then be fails. So you go back to a and 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 screen door and iteration till

that time that it goes live. So you have the devs committing code data, take that time to commit code any of too much, then you have to merge with the master Branch or 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 bill passing sailing, not getting deployed correctly. Then Q is rejecting that to three times. Then it goes to uat environment or their psyche, whatever you want to call it goes to the uat

environment users rejected. They say, oh, this is not what I asked for or sorry. It looks like you miss this requirement or oh, you know, some business circumstances have changed. We need to change the requirement, right? And from that day. Then you keep it ready for brought. But then the prod off, steam says, the next deployment window is two weeks from now. You'll have to wait till them. Meanwhile, there are the security terms will come the day

a gatekeeping checks. They'll be the karate. Be guys who come and say, sorry. I can't let you make these schema changes on. This is not allowed of that will cause a performance issue. Then, you know things go back there for you. Learn the hard way to create huge checklist and get sign of some people. And then, you painfully go live only to find that your users are reporting certain death. 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 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 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 ways 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 simple plain Pipeline and Jenkins and declare. I want to do left shift. No, you have to actually do a value stream map to understand

what to shift left. So what you shift left first, assuming that, you know, our environments are uniform, our deployments and configurations are consistent and we have S, Now, what you start left? Shifting our, how comprehensive are these tests and these stairs, by the way. Now, no longer have to be just by the QA team. They can also be addressed by the users.

They can be. Now the checks that DBS book in which is where you go to DBS and say, guys, look, we traditionally keep coming up to here and you keep kicking as back. Can you please just discuss with you early on? For example a conversation with a debate team and say can we discuss with you early on? What schema should we be using? You, what are you fine with, right? These are the requirements coming in. Can you advise also on this?

Let's have a calendar date. When you meet a twice, whatever. And you tell us what index is to create, not create what we should also look for the perfect testing or whatever. No problem. Suddenly. You have your database admins gatekeeping checks with you. I have found that it is socially more advantageous to approach and get a database checks than operating system and other

people's checks, right? Because you can then then go to the operating system people show your due diligence by saying, we have done this functional. Validation, here are gatekeeping checks. We are working with the database team. We are listening to what they're saying and making those checks for of a 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 with 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. What? Or will they be checking for? Mostly. They will tell you stuff like it. Being hardened, production, OS, environment, sounds good. Tell them, you know, what, you wanta Q environment to be harder, like, production. Give it to us, if it doesn't pass into, 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 as a searching and making changes. And that QA environment is the same as prod. You can now say the security folks have given us, they are gatekeeping checks. We have codified. These here is evidence that we have not changed the code. Here's a evidence will not change the Target and we have successfully left shifted broad 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 will 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 to us letter, take it just as a start, please bear with me. It is better that instead of half and our and repeats for four days.

Or even two to three weeks. It is better that half, not takes two hours with a guarantee that there will be no repeat. Once you're able to do this. You can then start figuring out. How do I reduce the individual process X, right? So for example, do we have to apply the security checks as part of the deployment? Or can we break the security

settings into the? Am I I'm using Amazon terms here, Henry into the am I and never change it because then suddenly the whole All, you know, OS installation, and security hardening, and all is nekton. Then you only focus on deployment and configuration suddenly that process time cuts down. Then comes to other things like weights. Just to give you an example of weight, 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 ask them. What is it that you do? It turned out that they had a bunch of checks of their own and Long time ago, the Deads 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 their targeted with the right messages, right? There were a lot of lot of things like this. So what these CI trigger in guys would do at night? Is they look at all the effort come up at all of it. Create a manifest document and say this build is related to all of these stories. So you might normally last, 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 that there's folks with all our stories. Let's start committing. It linking to the story card number and I worked it out with the CI triggering people and then suddenly they change the whole CI to be triggered at a polling interval of every 1 minute. That's it. Since of, raising your ticker 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've read The process time itself, and then you figure out. Why do you have waiting time in between, what can you do to eliminate it? So once you qualify checks, and once you understand other people's needs and all of it, right? This is what it takes to arrive at and optimize and the best auto optimized value stream map.

And then you can say, I am now going to certify a build and not an environment. Hmm. So hearing from what you explained just now, right? So the way I see it is that yes, there is still some kind of segregation of duties. Atiba, instead of being explicit. Now in 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 or 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 seems 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 that techies. Right, so, that gets us to the topic of segregation of Duties. See a lot of us right, as devs.

We know what it takes to compile code, even nowadays with a lot of cloud and occupation. We know what it takes to production and environment. I will 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 the startup or the private sector, where you're Your Own Boss or where, you know, Early high speed is the essence of the are. You can annoy you a lot. When suddenly, you know, the company appoints achieve infosec officer. They come up with an auditor

team. They'll be you know, security officers at every step of the way for every piece of infrastructure and they will live until you know, you are only allowed to keep a build artifact. Is this third-party artifact storage system that they bought without even Consulting the dev team or thinking about the suitability. He will just declare. Oh, you must place it there. Then and we will decide you know how to deploy them. Actually.

These are unfortunate things because there are several things are pointed out over here. What happens if someone goes and procures and artifact storage system without consulting The Depths often devs are treated on a need-to-know basis and told you don't need to know all this because a moaning prod. Now, look, here's the truth. There is this phrase called segregation of Duties. Okay, would you be comfortable with a situation where you will learn that your bank has given

out a software contracts. Some Outsource company, those devs implement the software and those deaths. Just went ahead and push that build in production and no one from the bank called the opportunity to review that bill and inspect it for back doors or four functional correctness of a Regulatory Compliance. That means this bank, which had this kind of Liberty given to the deaths 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 accounts. Siphoned off to this other account that 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 others know that such kind of engineering is possible is just coding after all, would we be comfortable with this? The wouldn't right? That's what the banks are here

to watch out for. So the principle of segregation of Duties says that the person who writes the code should not be the person deploying. So this is the principle, this is the intent. Actually, let me refine The real intent is more than one person should be aware of what is happening. Right? So, even in our outsourced Del 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 backboard. The bank should not be held hostage to situations like this. So segregation of Duties, 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 us? Situation, dense, do devs know how to write code and deploy. 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 a road sweeper. So what is ended up happening over the years is, it's become a kind of a norm who deploys pops deploys and involves. You. People are told they have two diploid, a will buy tools that they understand to store an artifact and to deploy, they will go to that text a company and say, sell us some Of schooling that you can agree to. And if they don't ever go to any other company, why do they do

all this? Because those people do not know how do I mean, mostly are they do not know how to write a proper deployment script which is predictable and consistent. They don't know this. So they just go and buy some artifactory, some random Urban code, whatever have you which has nothing to do with what the devs relieved, prescribed for this and things go very, very bad Henry. So, the real thing that I have started to make sure clients Understand is 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, deployments cryptos of whoever write a script and let's use that to them. So now you can still have segregation of Duty whether there's and the Q&A, get, collaborated the test Suites have passed. The product owner has seen it in uat environment. Product owner, goes to the broad

deploy button and click deploy. There's nothing wrong in a Opossum Creek and deploy because that button is going to run a tested deployment script on a uniform environment or 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, click 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 Duties is necessary. But the way it is implemented, once one does Albion of rationalization and reasoning, you can come up with much better. Automated processes to figure out how to do a better job of it. Hmm. Thanks for clarifying and about the segregation of Duty.

So for me coming from like software development practices, obviously, these kind of things is a good thing for me to learn as well because they are the perspectives from where a little prize is seeing the need of the segregation of Duty. Rose that is required before and an actual software is being certified and deployed to the production. 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? What you guys been slightly easy for me? Because I had to run my own businesses and learn to ask that question. What is the customers needs? 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 in whe what I said can also be true of a solution provider. So Shouldn't providers have people who consult hear something. That goes up it from? 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 expected to be a consultant versus some people who are actually not interested in Consulting, at that point in their life. They want to just focus and Deliver Me Consulting by itself, is way more complex whether you're called a consultant or not. If you are a customer Replacing

person. And they ask you a question and you have to answer you are Consulting to them. Right? Let's let's leave aside some of the better definitions of their, this is what I have concluded. If you are a customer facing person, they ask you a question. You have to answer your Consulting to them. You are a consultant, my happy lesson and this was from a book by Gerard, Weinberg Jared, Wayne book or third.

These two books. One is the secrets of Consulting and the second is more secrets of Consulting. I would strongly recommend that people. This to understand what is it mean to actually be customer-facing and deal with it all? And in the first chapter Jared, Wayne of his book secrets of Consulting. He does his best to dissuade you from getting into Consulting. He describes, how horrible it is, how thankless. It is rubbish.

It is, you'll have sleepless nights, ungrateful colleagues and customers and no one will know how much political and social maneuvering you had 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 The building he gives all this horrible reality check and then in Chapter 2. He asks who 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 Anglers. Things is a great opportunity. It is a great opportunity to stand in a room. Here, 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. They're all lessons.

I learned on my own. Those questions are a combination of Diagnostics as well as opening clients 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 lie once in two months and will you wait for two months to push a defect or will official portrait or defect fix and 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 in two 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 impostor. Syndrome often kicks in, you hear something, a lot of us who are employees or even those, who are running our own professions.

Let's say, you spent the past two years, helping our client out in depth with your Java spring boot app, which is using the react.js on the front end. You have been doubling with node.js on the side for your past six months. Now this project gets over. You have to go to the next engagement where it's all with 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 clients, had people already have a bunch of folks who have been working with node.js, for the past 23 years. And since I've chosen not just, you know, Hindi, both know, and everyone listening also the JavaScript ecosystem that is a humongous amount of tremendous amount of churn in that ecosystem, libraries that are popular. Two years ago are not even known to Today, for people who starts

with node, right? So, when you make such a transition, one of the things that hits you is O Mine. 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 with the clients. What is this? Am I not cheating the clients? I'm not, you know, cheating myself. Actually, right? I'm not fooling myself. The answer is this, okay. It may seem unattainable to have

to do this. Blinds are buying from you is not the answer for the day. What they are buying from you is the ability to pick up that tag to bring in all your engineering practices, do not get bold and to be mindfully and will fully engaged on doing it. Ignoring all other local politics and making sure that the deliveries met with the quality standards that expected that they are buying that end outcome. They are not buying you for that day. The man day rate and the man are

rate and all that. That is a Will construct more. They are 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 the two, if by the third time, they see that when you ask for time, you actually come up with a prediction grade professional, working on Sir. They will give you that time because you are now in pressing on them. There 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 are buying you for your capability to deliver the outcome. If you wrap yourself up, if you diligently show, and upscaling and yourself, they will be fine method. 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 Alton's 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 are secrets of Consulting, and more secrets of Consulting. I must say that for all of you Consultants out there. You must read. The book is very interesting fun. And also, in a way teaches you a lot of in-depth insights about what does it take to be a great consultant?

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 sea level people, or directors, or even some people who are so called the sponsors of the project goodness Henry. We now get into the non-technical part of life. Okay. This is 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 ways. It does another author. Other base was the author of million dollar Consulting. He's another cannot. 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 only 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 you out, right? They may 22 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 expectation 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 could be all the free. Also, 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? How, what is success to them? The second? Who are we going to be interacting with? 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 they are worth is finished. Once they've gotten very good consulting company and handed them over to a product on. So just to tell everyone what actually happens inside, what

happens inside is there. Executive sponsors told by some board or by even higher a people that hey, we need to get this so-and-so service offering out or so-and-so product out there. That person goes to the pmo, the pmo gives them a project manager or a product owner. The exhibit is sponsor. Works of the 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 sees, I'll need such a development team and need such kind of budget for one moment. You know, such support from security and not speaker. All right, that's where the executive sponsor walks off. Inner does all the social maneuvering to make a lot of this happen and they go get a consulting company or even and external software debris company and drop them into this place and tells the product owner. Here you go.

Abdic all for. If your check boxes that you want it. Now, make it happen with this team. You see the product owner was not involved in selecting the dev company, executive decided. To do it on the phone. So the kpi for the executive sponsor is, did they need the POS means and will this product get delivered? That's it. So the first half they already met for the second half. They are going to keep grilling the product on them because that

was the our equation. Now, we as people who come in from outside because we've been talking to the executive sponsor, the expect to get to keep talking to them. Reality is know. Once they get us in this for them. They are work is done for us as out. So does having sailed and other places because relationships are not managed. Well, we know desperately we should be working with these executive sponsors, but that's where things often break up. The product owners, have different apis.

They have to just get things done with the team given to them. If things are not done. They'll go to the exhibit of Bones 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 The reporting hierarchy and start surfacing reports and status in a way that makes sense to 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 said people the PO and executive sponsor will still have their own internal details. At that time. You want to arm your product owner with the reports that give a status that you can back. Okay. I will not lose 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 as some reason,

something is not working. Not a problem. Put it out in a report, send it out. Is that something that you goofed 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 the overall success. Let them do that. You know, why? Because when the next engagement happens, that product owners not going to be developing that software you get to do it. Everybody knows that the product owner did not have to crack any rip. In order to make you work at a level of efficiency. You just are efficient.

They are merely exchanging their reports who check with each other are things on. Track so long. As you can show reasonableness, the ability to be a gel 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 feet because all that they really need to know is is a project on track will be able to deliver it on time and budget are their scope that we cannot cannot deliver. And if there's something that you cannot deliver by when Kenzie, that's what they know because they need to know. Because it's a matter of cost time other business goals in mind. Once you understand this, you can manage your stakeholders better. Wow. Such so much in depth

explanation again from you. You know what? I mean? We can talk for hours or you know, you're talking about other stuff as well. But I think due to time constraints. 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. So, quickly to tell you, number one, identify. What is the problem to solve?

I've given a number of examples. So like here, you know what to approach men. How can you 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 far as 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 can be. I have lost one or two deals because of this, where, you know, in my spirit I went on to tell them. No. No, I'm telling you. That's what if 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. Was her mother do this, 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, you know, my most important thing is absolutely non-technical and non-social. It is actually your own health at your sleep. I have learned the hard way and you know, many people say this, you know, they are hospitalized or they fall ill again and again, Again, and they can't think and they lash out at people have 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 base headset that I've ever had. We have shown it to you. They're all these kind of things that you can do. Depending upon the app. There are some apps that say that you should have eight and a half, our nine hours of sleep

for three days, but - right. It's like a sliding window. There are other apps that say that you can fix all sleep debt with seven to ten days of proper eight-and-a-half. See what I have seen. If I can sleep for 10 days for eight and a half 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 see. I'm had an IQ of 140. If my IQ level drops, my ability to think, drops up. To some point.

I will realize As vo, I'm no longer able to think. Like, I was thinking this morning, right? You, you will realize, oh, I'm fatigued. Let's say. It happens over a number of days by Venice. You realize, oh, I'm not even to think that's clear. 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. Lost a few friends and I have to bend over backwards to apologize and everything. And even when relationships are not good. And there are enough problems that are 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 the 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 have the people should just go away and make sure that they see. Leap because when the first team has not solved it, the other team has to come back. Ache over with a fresh mind and solve it.

But if the whole group was there and they jointly become sleepy, and footing and tired, my got the problems are going to get. So so please speak. 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 these General Health sleep. Sleep is still one thing that I would want to improve, you know, I want to have Continuous eight hours sleep. It's still a challenge.

But yeah, I mean like the point when you mention 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 social intelligence could even drop. So, I read a fantastic book by Matthew Walker. Why we sleep? Only one of the best book if you want to understand why sleep is important. So thank you so much rum for your time here. There's so many things that I think I would.

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. Thank you very much Henry. And I hope to soon share with you and audience about my upcoming book, which I'm working on called a journey to continuous delivery where I am. Covering a lot of these with diagrams and explanations checklist on water follow, and what not, part of which I also want to cover.

What does it mean to aim for front page development? So yeah, I hope to be able to derive made a public commitment. And now I'm going to help. Hold it, right. I'll be waiting for that for sure. Alright. Thanks again. See you around. See you agree. Bye. Thank you for listening to this episode and I hope that you learned something from this conversation. If you find this valuable, please do me a big favor and share this with your friends and colleagues. Also, if you haven't, please

subscribe and follow this. Show on your favorite. Podcast app tekhelet Journal is available on all major podcast apps such as Apple podcast Google podcasts and Spotify, and please leave your rating and review so that more people can find this podcast and learn from the available episodes. Thank you again, and I'll see you next time.