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.