Mastering Stress and Automation in DevOps with Vishwa Krishnakumar (Zenduty)

In this episode of the Ship Talk podcast, host Dewan Ahmed welcomes Vishwa Krishnakumar, co-founder of ZenDuty, to delve into the complexities of software delivery, from managing stress as a startup founder to the nuances of DevOps and SRE practices. Vishwa shares his journey from a young coder to a successful entrepreneur, emphasizing the importance of physical and mental well-being in high-pressure environments.

They discuss how ZenDuty emerged from a need to address incident management and the evolution of DevOps practices, highlighting the significance of timing and cultural shifts in successful implementations. The conversation also explores the role of AI and machine learning in DevOps, shedding light on how automation can enhance productivity and reliability without completely replacing human intervention. Tune in for insights on balancing manual efforts with automation, the future of AI in software engineering, and practical tips for maintaining sanity in the demanding world of tech startups.

Transcript

1
00:00:05.370 --> 00:00:10.850
Dewan Ahmed: Hello, everyone welcome to the ship, talk podcast where we talk about the ins and outs

2
00:00:10.890 --> 00:00:13.879
Dewan Ahmed: ups and downs of software delivery.

3
00:00:14.180 --> 00:00:16.089
Dewan Ahmed: And I'm super excited

4
00:00:16.140 --> 00:00:19.290
Dewan Ahmed: to be here with Vishwa Krishnakumar.

5
00:00:19.640 --> 00:00:22.450
Dewan Ahmed: co-founder of Zen duty

6
00:00:22.530 --> 00:00:23.769
Dewan Ahmed: and advanced incident response platform.

9
00:00:25.580 --> 00:00:27.850
Dewan Ahmed: I'm your host, Dewan Ahmed.

10
00:00:28.310 --> 00:00:30.740
Dewan Ahmed: So Vishwa as a startup founder,

11
00:00:31.090 --> 00:00:34.650
Dewan Ahmed: You are juggling 100 different things.

12
00:00:34.850 --> 00:00:39.570
Dewan Ahmed: How do you keep your sanity? What are the things you do to distress.

13
00:00:40.780 --> 00:00:49.360
Vishwa from Zenduty: 1st of thanks, Devin, for having me on your your podcast I mean, it's it's it's something that most founders

14
00:00:49.763 --> 00:00:52.670
Vishwa from Zenduty: face when they when they start a company, and

15
00:00:52.770 --> 00:00:57.930
Vishwa from Zenduty: you know, as as they build the product they ship it. They get customers.

16
00:00:58.586 --> 00:01:15.750
Vishwa from Zenduty: The the overall workload increases you. You know you, you, you set up your team, you hire more folks. You set up processes, and that pretty much takes up almost all of your time, right? And stress is something that I would say. It's it depends on who you ask and the way they they've been managing it. So I think

17
00:01:15.750 --> 00:01:30.180
Vishwa from Zenduty: folks who have worked in a a role that involved a great deal of stress. Right? I think, th, there are different ways of managing stress. For me, personally. I work out play a lot of cricket.

18
00:01:30.587 --> 00:01:36.469
Vishwa from Zenduty: In fact, there's a there's a it's it's it's a culture that we've built over the last 3 years within our own company, which is that we

19
00:01:37.570 --> 00:01:41.569
Vishwa from Zenduty: We have days in the week, about 3 days in a week where

20
00:01:41.590 --> 00:01:48.150
Vishwa from Zenduty: you know the team goes out for for sports. I mean, they go together. It's Badminton, or or cricket, and we just play together

21
00:01:48.473 --> 00:02:07.199
Vishwa from Zenduty: you know, let off some steam work out in the process that in this company I think we put a a high premium on physical and mental fitness, and try to endeavor. That. You know, all of our people are are fit mentally and physically. So I partake in those activities as well. And that sort of keeps me in in decent shape.

22
00:02:07.390 --> 00:02:19.289
Vishwa from Zenduty: and even from a mental health perspective, I think. You know, as and when the processes are in place, and it becomes more and more predictable right? I think that the peace of mind sort of comes naturally to to the founders.

23
00:02:20.010 --> 00:02:33.260
Dewan Ahmed: Yeah, that's that's a great answer. And we are knowledge workers. Right? So as as knowledge workers, it's our brain that's doing all the heavy lifting. So these like workout you mentioned like playing cricket or listening to music, these will actually

24
00:02:33.260 --> 00:02:55.820
Dewan Ahmed: increase the productivity like within the same amount of time we can, we can do much more work, or, to put it other way, there is lesser chance to to get burnt out so from from that. Now your co-founder of Zen duty. But how was your take care like, where did you start? How you have become the co-founder of Zen duty? If you wanna share with the listeners your carrier journey.

25
00:02:56.330 --> 00:03:06.810
Vishwa from Zenduty: I think. I started quoting when I was quite young. You know, right in the middle of school, probably when I was age 10 or 11, and it's it's something that I excelled naturally at.

26
00:03:07.311 --> 00:03:10.658
Vishwa from Zenduty: But you know, after I did my engineering

27
00:03:11.230 --> 00:03:17.120
Vishwa from Zenduty: I I ended up in consulting for for some God forsaken reason. Right? I ended up working with a a bunch of

28
00:03:17.608 --> 00:03:32.740
Vishwa from Zenduty: you know, global customer, a global sort of companies like like, like Procter and Gamble, and basically help them sell more, sell more units so there's a lot of statistical work, a lot of consulting work that I did the early on in my career. But then the heart was always in building more products, building products period.

29
00:03:33.307 --> 00:03:41.622
Vishwa from Zenduty: and you know me and my co-founder we met. He's actually a a friend of my brothers. We met together. We discussed a few ideas

30
00:03:42.090 --> 00:03:56.739
Vishwa from Zenduty: and in in about 2,016 ish, we sort of working. We started working on a product that was centered around chatups for the the the software engineering and production operations teams basically helping them

31
00:03:56.740 --> 00:04:17.160
Vishwa from Zenduty: manage their alerts. You know, it could be anywhere in your in your overall development lifecycle, right from a rational time. You know, a a task is cleared in Jira tiller time. It it gets shipped in your in, in, in Jenkins it goes into production, and then, monitoring production metrics through this chat board that resided in slack and Microsoft team. So we started off by building a Chatbot product for developers.

32
00:04:17.200 --> 00:04:36.290
Vishwa from Zenduty: And we ran that for about a year and a half about 2 years. But then we realized that we weren't really hitting, you know, a a specific pain point, and for it was more of a a horizontal platform, and therefore, from a Pmf. Perspective, we were not really seeing it, so we decided to sort of narrow and for our focus on a very specific problem that has not not yet been solved.

33
00:04:36.835 --> 00:04:48.120
Vishwa from Zenduty: And that problem was instant management. Right? So both me, me and my co-founder. Between us we have about 25 years of sre and devops experience managing, you know, complex environments and managing it at scale.

34
00:04:48.430 --> 00:05:13.569
Vishwa from Zenduty: So we thought that, hey, this is one problem that is not really being solved by any solution out there, right? So most of the solutions that we saw were mostly managing the meantime to acknowledgement there was, there was basically making sure that hit the engineer. See that if there's something something something goes wrong in production, right, but not really adding any value on the response side of things on the Mtr. Side of things. So we thought that was an opportunity. So we built and shipped Zen duty. In fact, it was. Zenut was a clone of the year on product.

35
00:05:13.630 --> 00:05:17.119
Vishwa from Zenduty: and was a very focused clone of the year on product which we shipped in early 2020.

36
00:05:17.290 --> 00:05:33.149
Vishwa from Zenduty: And I think from that point onwards, once Covid struck. I think our adoption just skyrocketed, and we finally, you know, found a group we we hit Pmf, in. Maybe I would say about 12 to 14 months. We were able to see definitive signs of pro market fit, and then from that point on which it was upwards.

37
00:05:34.180 --> 00:05:42.647
Dewan Ahmed: Yeah, that's that's a great to hear. And 1 1 point I'll I'll press down is even in my like previous company. And and even before that I've seen

38
00:05:43.000 --> 00:05:47.040
Dewan Ahmed: folks who have worked in consulting like working directly with customers.

39
00:05:47.150 --> 00:06:07.996
Dewan Ahmed: They have a much more like keen sense of understanding, real customer pain points, and many of them have like gone to to found found like successful startups. How have you seen, like your experience of actually like working as a consultant, to to be in the battleground, to to fix those

40
00:06:08.400 --> 00:06:11.340
Dewan Ahmed: like difficult devops and necessary problems.

41
00:06:11.670 --> 00:06:14.900
Dewan Ahmed: Transition into your role as a start of cofounder.

42
00:06:15.250 --> 00:06:25.475
Vishwa from Zenduty: I think my role is the consultant really helped me interface with customers and sort of get me? I mean it. It it opened up a different boy as to what metrics really matter, how businesses

43
00:06:25.810 --> 00:06:28.440
Vishwa from Zenduty: run or how business are run?

44
00:06:28.500 --> 00:06:31.110
Vishwa from Zenduty: What are the key business metrics that you know

45
00:06:31.270 --> 00:06:51.960
Vishwa from Zenduty: your your leaders really look at what really matters to them? How do you communicate value? How do you increase that value? Right? So I think, from from that perspective, I was able to sort of become a more polished it. It really helped me become a better salesperson. Right? So I was. I was. I was, I would say, before I started. Genuinely. I was a decent product engineer.

46
00:06:52.030 --> 00:07:04.519
Vishwa from Zenduty: and I got better over over the last, you know, 5 to 10 years, but I think from a from a product marketing perspective that that's didn't really really help me market it in a in a in a better, more polished way.

47
00:07:04.670 --> 00:07:09.330
Vishwa from Zenduty: And yeah, that that that that experience was quite invaluable out today.

48
00:07:10.360 --> 00:07:39.760
Dewan Ahmed: Yeah, for sure. Like, what good takes a good engineer to a great engineer is the the sales and marketing skills, I guess. So the last like 12 to 14 years or so. You have helped, like both startups and like big corporations and enterprises, to solve their devops. Sorry and platform engineering pain points. What would be your top? Few top 3 or top 5 like key lessons on where they struggle, and how a platform like zen duty helps. There.

49
00:07:40.690 --> 00:07:49.532
Vishwa from Zenduty: So, you know, it's strangely enough, I think in the last I would say in the last 3 to 4 years I've not really seen companies struggle with devops and Sr. Implementation

50
00:07:49.970 --> 00:07:54.240
Vishwa from Zenduty: mostly because when a company is ready to

51
00:07:54.850 --> 00:07:55.550
Vishwa from Zenduty: sort of

52
00:07:55.880 --> 00:08:06.650
Vishwa from Zenduty: bring in a dev a devops practice and a devops culture. Right? There's always an agent of that. That cultural change and the practice change right? They'll probably bring in someone who actually has a great deal of

53
00:08:06.680 --> 00:08:12.049
Vishwa from Zenduty: devops experience, not just implementing processes and implementing tooling, but also has a very visible cultural shift

54
00:08:12.090 --> 00:08:17.580
Vishwa from Zenduty: who's been able to bring in cultural shift in any organization that he or she may have joined. Right.

55
00:08:17.967 --> 00:08:22.879
Vishwa from Zenduty: So there I I have not seen companies struggle with either of these 2 departments.

56
00:08:22.990 --> 00:08:32.989
Vishwa from Zenduty: I would say that they probably might be guilty of maybe sub optimizing the processes, or maybe guilty of choosing a diff, a a tool set that make they may be more comfortable with, as opposed to, maybe a tool set that.

57
00:08:33.049 --> 00:08:34.619
Vishwa from Zenduty: you know. Give them a better

58
00:08:34.630 --> 00:08:37.739
Vishwa from Zenduty: return on, on, on investment, right?

59
00:08:37.770 --> 00:08:53.700
Vishwa from Zenduty: But by and large I think there is. There's so much material out there on how to set up a devops practice, how to set, how to set up an Sri practice that most of the folks that at least that are in my network are able to sort of. They're able to get it right to begin with, and they're able to sort of employees over over a period of time.

60
00:08:53.920 --> 00:08:55.220
Vishwa from Zenduty: But the

61
00:08:55.390 --> 00:08:57.620
Vishwa from Zenduty: some folks, I think, are

62
00:08:57.850 --> 00:09:11.371
Vishwa from Zenduty: might be, you know, if they, when when they look at bringing on devops or implementing devops, they'll probably just look at it from a tooling perspective and not really from a from a cultural mind. Shift perspective, right?

63
00:09:12.120 --> 00:09:17.180
Vishwa from Zenduty: and it's also about timing. Right? So devops at the end of the day is is is a is a

64
00:09:17.240 --> 00:09:20.779
Vishwa from Zenduty: is a practice that allows you to ship faster. And right now, I think

65
00:09:20.850 --> 00:09:25.750
Vishwa from Zenduty: in in 2024, it's it's very important that you're able to ship as fast as you can, right.

66
00:09:26.281 --> 00:09:30.810
Vishwa from Zenduty: And of course the Sig practices would would, of course, be there to ship reliably

67
00:09:31.270 --> 00:09:45.770
Vishwa from Zenduty: right, and to make sure that whatever you shift is running smoothly in production. The timing really matters. I think that's that's where I see a few folks, maybe mistakes around timing. They might be doing it too soon, but they might be doing it too late.

68
00:09:45.900 --> 00:09:50.669
Vishwa from Zenduty: And the if if you get the timing right that that might eventually

69
00:09:51.308 --> 00:09:59.089
Vishwa from Zenduty: impact your custom, impact your your company in a in a major way, right? It might be the difference between a mediocre outcome and a catastrophic outcome.

70
00:09:59.160 --> 00:10:04.220
Vishwa from Zenduty: So if you let's say, if you if you incorporate. Sorry, too late, into your journey where you have like, you know.

71
00:10:04.350 --> 00:10:13.408
Vishwa from Zenduty: a couple of thousands of customers right? And if there's a competitor that's more reliable than you that's able to deliver faster than you. Then you you're probably gonna turn customers to left right and center.

72
00:10:13.770 --> 00:10:30.339
Vishwa from Zenduty: So it's always important to time these practices. When do you set it up? I think most most companies, if they're already at, let's say, 3 Cdc. Or series a stage. That's probably when they bring in a devops team Srs are mostly at least at Series BC. Level. They they are internally promoted.

73
00:10:30.350 --> 00:10:33.339
Vishwa from Zenduty: or they bring in. You know folks laterally as well.

74
00:10:33.650 --> 00:10:40.449
Vishwa from Zenduty: So the the timing, more than anything, is what people get wrong. I think the tooling and the process is by and large. I've seen, you know, companies.

75
00:10:40.710 --> 00:10:41.510
Vishwa from Zenduty: Oh, up.

76
00:10:41.850 --> 00:10:46.719
Vishwa from Zenduty: get right. When when they decide to implement it, they're able to get the processes right.

77
00:10:46.810 --> 00:10:49.489
Vishwa from Zenduty: They probably just did it too earlier to to late, I would say.

78
00:10:50.490 --> 00:11:02.669
Dewan Ahmed: Yeah. For example, a a shift I've seen for many companies is the concept of Qa or Qa team. So in the past there were like dedicated Qa teams. Now.

79
00:11:03.040 --> 00:11:10.419
Dewan Ahmed: many companies. They're shifting that responsibly to the software engineers like, you are a software engineer. You're doing your own Qa.

80
00:11:10.630 --> 00:11:26.460
Dewan Ahmed: So how do you see that being transitioned to the role of devops like from traditional, a team of devops, engineers to you have an engineering team and devops. Engineers are embedded within those engineering team engineering engineering teams.

81
00:11:27.710 --> 00:11:30.189
Vishwa from Zenduty: I think there is a visible

82
00:11:30.270 --> 00:11:39.930
Vishwa from Zenduty: yep left shifting of on the left side that's happening in in most of the companies, and that model seem to be working for most progressive companies. Right?

83
00:11:39.940 --> 00:11:44.299
Vishwa from Zenduty: The more you sort of empower your developers.

84
00:11:44.520 --> 00:11:50.099
Vishwa from Zenduty: and if they're able to sort of shift if they're able to sort of build, test, and ship by themselves

85
00:11:50.170 --> 00:11:55.450
Vishwa from Zenduty: with as little intervention as possible. I think that is probably the best way to ship as fast as possible.

86
00:11:55.670 --> 00:12:08.960
Vishwa from Zenduty: Right? So devops teams, I mean, I've seen many different kinds of models across. You know all the companies that that I have worked with. Some of them have, you know, devops engineers who are part of the specific specific team. Some of them have a Central Devops team, right?

87
00:12:09.340 --> 00:12:15.100
Vishwa from Zenduty: So you know it. It completely depends on the organization structure how they end up implementing devops.

88
00:12:15.645 --> 00:12:25.544
Vishwa from Zenduty: But at the end of the day, you know, the the the culture story remains the same across all of these different kinds of models. Right? It has to sort of come from the top, and then it has to sort of

89
00:12:25.800 --> 00:12:34.719
Vishwa from Zenduty: be ingrained in every single team member. That's that's that's writing code that's testing code. That's shipping the code. And that's even maintaining the code in in production.

90
00:12:35.540 --> 00:12:43.469
Dewan Ahmed: Yeah. And and the same can go for for security engineering team as well. Like, if you keep adding blockers to your software engineering teams.

91
00:12:43.570 --> 00:13:08.349
Dewan Ahmed: Sooner or later they'll see you as a team who just blocks them rather than enabling them to shift faster in a safer way. So you break things, but not the things you don't mean to break. So same goes for Qa. Same goes for devops, engineers, same goes for security engineers. Yes, you need to put practices, but it can't be just. No, you can't do things. Period. There has to be like certain process and tape.

92
00:13:08.350 --> 00:13:17.339
Dewan Ahmed: I'll I'll shift gears towards like automation and manual. So, of course, like both of us, have been in the industry for more than a decade, and we have seen how

93
00:13:17.510 --> 00:13:28.679
Dewan Ahmed: teams have gone from manual to same manual, like a bunch of batch groups cobbled together to automation. So where do you see automations, sweet spot like what?

94
00:13:28.900 --> 00:13:32.909
Dewan Ahmed: Going full on automation and automating every single thing versus

95
00:13:33.060 --> 00:13:42.460
Dewan Ahmed: we do automation to have like to to to make our life easier. But there's some sort of toil that is accepted. What's your view on that.

96
00:13:44.350 --> 00:13:48.630
Vishwa from Zenduty: I think the faster you ship there is the the probability of

97
00:13:48.720 --> 00:13:52.300
Vishwa from Zenduty: toil. Accumulation goes up. I feel at some point right, because

98
00:13:52.731 --> 00:13:57.620
Vishwa from Zenduty: and it again depends on the stage that the company is in. I think at the earlier stages

99
00:13:57.700 --> 00:14:05.469
Vishwa from Zenduty: there is a fair bit of toil that creeps into the systems. And you know, the engineers who probably join a year or 2 later, are the ones who sort of clean up the mess.

100
00:14:05.490 --> 00:14:10.770
Vishwa from Zenduty: and and that happens in pretty much every early to sort of maybe mid stage company.

101
00:14:11.270 --> 00:14:13.169
Vishwa from Zenduty: over a period of time. Right?

102
00:14:13.892 --> 00:14:20.147
Vishwa from Zenduty: In terms of automation. I think there are. There certainly are limitations to how how much you can automate. And

103
00:14:20.530 --> 00:14:27.810
Vishwa from Zenduty: you know, testing. And Qa has to be a centerpiece of any kind of automation that you're able to bring in, at least from a

104
00:14:27.930 --> 00:14:30.410
Vishwa from Zenduty: from from a deployment perspective, right?

105
00:14:30.856 --> 00:14:41.299
Vishwa from Zenduty: There will be I I don't. I don't really see a complete lack of human intervention in the in the overall release process. Especially if you're a fast moving product.

106
00:14:41.590 --> 00:14:47.590
Vishwa from Zenduty: right? There has to be probably a human element, or there has to be certain processes that are human dependent, which.

107
00:14:47.660 --> 00:14:58.719
Vishwa from Zenduty: once the human sort of figure out what the process is, and then they sort of go ahead and automate all those processes that have been proven to be, you know, reliable. And I think I think that's pretty much how it happens in most companies.

108
00:14:59.990 --> 00:15:11.801
Dewan Ahmed: Yeah, absolutely. So the company I worked at harness. It has the products that enables you to deliver faster all the way from the Core Repository to the deployment with software engineering insights.

109
00:15:12.180 --> 00:15:34.769
Dewan Ahmed: For example, for a typical Cicd pipeline, we we you can automate the build all the way up to the deployment, but we have a a manual approval step as well within our ci. If you choose to do so, you can have a manual approval. You can have a service now, or Jira approval. And that that is something you probably do before you actually

110
00:15:35.670 --> 00:15:48.470
Dewan Ahmed: promote your artifact from your Dev and Qa to to your prod environment. So absolutely 100% agree that. Yes, you need automation. But at some point you you probably want some manual manual approval process.

111
00:15:49.040 --> 00:15:49.630
Vishwa from Zenduty: Yep.

112
00:15:50.240 --> 00:15:59.704
Dewan Ahmed: Probably a good time to to discuss the topic that everyone everywhere discusses. Ai machine learning

113
00:16:00.500 --> 00:16:04.889
Dewan Ahmed: So the the the topic is so vast that

114
00:16:05.070 --> 00:16:10.369
Dewan Ahmed: from from writing your email to all the way to to root cause analysis.

115
00:16:10.510 --> 00:16:21.198
Dewan Ahmed: where do you see the role of AI in in specific to the devops and Sri and platform engineering's landscape. And how do a lot of

116
00:16:21.680 --> 00:16:29.299
Dewan Ahmed: folks like ask on Linkedin like, Will will AI take our jobs. How can devops, engineers, platform engineers.

117
00:16:29.540 --> 00:16:31.829
Dewan Ahmed: have AI companions

118
00:16:31.990 --> 00:16:33.269
Dewan Ahmed: to speed up?

119
00:16:33.430 --> 00:16:34.860
Dewan Ahmed: Did their work.

120
00:16:36.821 --> 00:16:48.770
Vishwa from Zenduty: You know. Surprisingly, I think the it's it's still quite early to make any kind of predictions on the impact of aimlce. There are, there are already. There's already fair bit of Ml, that is.

121
00:16:49.388 --> 00:16:56.380
Vishwa from Zenduty: that is, that is, that has been allowed at least on the observability, instant management, monitoring side of things.

122
00:16:56.520 --> 00:16:58.460
Vishwa from Zenduty: Right? So a lot of the

123
00:16:58.933 --> 00:17:03.850
Vishwa from Zenduty: you know, making sense of all of this data that comes in whenever there's any kind of downtime.

124
00:17:04.257 --> 00:17:08.250
Vishwa from Zenduty: You know, a lot of companies are also invested a lot of time

125
00:17:08.838 --> 00:17:23.139
Vishwa from Zenduty: on figuring out how to correlate different kinds of alerts, how to basically map your overall. How to map services, how to map your overall production architecture and figuring out what a particular alert or what a particular signal means

126
00:17:23.240 --> 00:17:31.140
Vishwa from Zenduty: right? So those kinds of those kinds of problems are already being solved with them. And in fact, i i i and that's that's been happening for the last, I would say

127
00:17:31.250 --> 00:17:36.450
Vishwa from Zenduty: 5 to 6 years right? And it's really picked up by by a lot of the bigger players in the observability space

128
00:17:36.720 --> 00:18:02.410
Vishwa from Zenduty: that certainly did not replace any of our take up any of the the jobs of the dedicated Srs or the Devops engineers. Right? As a matter of fact, it. It really helped them. Detect those issues faster. It helped these production on, call engineers quickly diagnose these issues. And and and you know, figure out what the fix would be. And just, you know, deploy those fixes. So Ml. Has been around on in the in the instant management

129
00:18:02.620 --> 00:18:11.040
Vishwa from Zenduty: space for quite some time, and therefore I think it will only enhance the overall resolution. Time, you know, as and when different

130
00:18:11.286 --> 00:18:25.479
Vishwa from Zenduty: models keep the models keep evolving as and when you have more data as and when you are able to sort of make sense of the all of that, the production data at scale attached, you know, you know, in in a cheaper way, in a short span of time. I think it's probably just gonna bring down the overall

131
00:18:25.878 --> 00:18:36.069
Vishwa from Zenduty: the resolution time for any critical incidents that happen right? So it's only gonna make our make all of our products and all of our services more reliable in the long run

132
00:18:36.130 --> 00:18:36.935
Vishwa from Zenduty: and

133
00:18:37.790 --> 00:18:47.249
Vishwa from Zenduty: like, I said, the relationship between the Devops, society engineers, and all of these solutions that have a fair bit of Ml. Will only continue to evolve. And it's only going to be

134
00:18:47.790 --> 00:18:54.009
Vishwa from Zenduty: you know, to the benefit of any organization that adopts AI and Ml within their within their production operations.

135
00:18:54.800 --> 00:19:02.610
Dewan Ahmed: Yeah, yeah, absolutely. So as a developer advocate, I, I create a ton of demos. So one specific example I don't want to share with the listeners is

136
00:19:03.025 --> 00:19:07.989
Dewan Ahmed: when I look at a new code repository like how how it is I can do like a

137
00:19:08.010 --> 00:19:17.429
Dewan Ahmed: text, search direct for a keyword search, or I'll do a semantic search. So, for example, harness code repository it has built in a idea which is our AI Development assistant.

138
00:19:17.430 --> 00:19:40.819
Dewan Ahmed: and it'll show me like, where are the the errors defined? It'll show me like exactly which code is error defined. Now, if I go back to Vs code, I can say that generate a program that that does so. And so so before I do, a combination of Google search stack, overflow get the most trusted stack, overflow and try to run that. So this makes my life a bit easier, and also like a software supply chain like a as a bomb.

139
00:19:40.820 --> 00:20:05.660
Dewan Ahmed: If there is any vulnerability. Again on harness platform. The idea shows that these are the vulnerabilities. These are the issues, probably like some packages that are outdated, even like writing open policies like open policies and policies within harness platform. I can say, write a policy that checks all the elv's like, that are not used. Maybe maybe delete that. So all those things that a software engineer or device engineer would search

140
00:20:06.082 --> 00:20:13.919
Dewan Ahmed: stack overflow. Ask around th. Those. Those are the probably manual efforts that AI is taken taken care of.

141
00:20:14.450 --> 00:20:24.397
Vishwa from Zenduty: I would I would agree there. I mean, it's it's it's only speeding up a lot of the things right? It's it's speeding up your. I mean, it's speeding up instant management. It is speeding up development. It's speeding up deployments

142
00:20:24.983 --> 00:20:41.686
Vishwa from Zenduty: so it's only gonna make all of our processes faster. The reliability of AI is still sort of you know. It's still in question, in my opinion. We if if if it if it was not that it would have been used by every single person in every single organization. So I think you know,

143
00:20:42.030 --> 00:20:48.420
Vishwa from Zenduty: bring an AI in all of our sort of Sdnc. Would would. I would see. I would see that in the near future.

144
00:20:48.450 --> 00:20:55.050
Vishwa from Zenduty: Not not just quite yet. Right? So a lot of the manual efforts are definitely being sold by a lot of the AI assistants.

145
00:20:55.448 --> 00:21:06.839
Vishwa from Zenduty: And I think I hope that it it just gets reliable over a period of time. It gets more knowledgeable. And you know, you know, help help all of us. Just shave off a couple of minutes in in building, deploying.

146
00:21:07.760 --> 00:21:24.419
Dewan Ahmed: Yeah. And Jyoti, our our CEO, is one of the fantastic founder that have been following like way before. I've I've joined harness, and he recently wrote on Linkedin that the the In including of AI within the development workflow, has

147
00:21:24.480 --> 00:21:40.949
Dewan Ahmed: a has put developing in stairs like, now we are shipping more quotes faster than ever before, but it's creating a bottleneck on Qa. Like testing has has been the same. So now we'll see like a tremendous need for like Q, and adding, key

148
00:21:41.160 --> 00:22:07.159
Dewan Ahmed: AI and Ml. E in Qa. So the T within within zend duty, for example, like, How do you see this in in reality like, are you shipping like more coast than before? Are you seeing some sort of bottleneck on on testing all this code? Because you say that we can use AI for development, but there has to be check. We can't just blindly trust, all the things that we're AI is doing for us.

149
00:22:07.760 --> 00:22:21.269
Vishwa from Zenduty: I think here at Zendui we use AI for very, I mean from a from a development perspective. It is very limited. I would say, I don't think AI is writing any of our code and do it. And it's it's it's it's purely assisting

150
00:22:21.300 --> 00:22:34.620
Vishwa from Zenduty: in. Maybe in some teams, maybe not in. Not not all the teams. It's assisting folks to maybe write some of the the the boilerplate code faster. Because because we are in the business of reliability. Right? We.

151
00:22:34.690 --> 00:22:36.840
Vishwa from Zenduty: We put a lot of emphasis on

152
00:22:36.900 --> 00:22:53.540
Vishwa from Zenduty: making sure that you know whenever whenever any goership, the the, the testing process, the the the review process is very, very, very stringent in our company. But then, you know, we are always on the lookout for tools that that help us test faster. You're right. If if there is a mismatch between

153
00:22:54.202 --> 00:23:01.600
Vishwa from Zenduty: how AI is accelerating development and not really acts accelerating at the same pace testing.

154
00:23:01.860 --> 00:23:12.930
Vishwa from Zenduty: then these bottlenecks are bound to to, to to occur right, and the only probably, at least now the only way is to is to is to increase your your your testing bandwidth.

155
00:23:13.561 --> 00:23:20.838
Vishwa from Zenduty: I'm I'm I am guessing with, with, with, with with platforms like hardness, and and others we should be able to sort of at least.

156
00:23:21.150 --> 00:23:22.540
Vishwa from Zenduty: maybe maybe not

157
00:23:22.890 --> 00:23:27.050
Vishwa from Zenduty: automatically solve for all of testing via AI,

158
00:23:27.180 --> 00:23:32.119
Vishwa from Zenduty: but at the very least accelerated to a significant degree the way it's accelerating development. I think

159
00:23:32.150 --> 00:23:38.899
Vishwa from Zenduty: you know, we are here in the industry we are probably looking out for for solutions that are able to actually testing as well. So it's a good prompt to solve, I would say.

160
00:23:38.900 --> 00:24:00.655
Dewan Ahmed: Absolutely. It's a great, great problem to solve it, because it it makes the experience engineers even more valuable because they have the experience. And they have those eyes to see where things can go wrong. So yes, they're using AI and Ml. To accelerate their their engineering teams, but they also know where to put those checks and gates to ensure that we're not introducing

161
00:24:00.980 --> 00:24:10.880
Dewan Ahmed: any any errors or mistakes in in our development artifact. We started the podcast we're talking about like keeping sanity with

162
00:24:11.264 --> 00:24:19.410
Dewan Ahmed: with all the things you're doing as a startup co-founder. So I want to wrap up in in the same note that as

163
00:24:19.450 --> 00:24:31.060
Dewan Ahmed: other people are thinking that they want to start their own company, they're probably hoping to to be an entrepreneur. What would be your few tips, because it might seem daunting like.

164
00:24:31.410 --> 00:24:33.279
Dewan Ahmed: how would someone

165
00:24:33.390 --> 00:24:36.969
Dewan Ahmed: take such a big risk? Balance a bunch of things.

166
00:24:37.020 --> 00:24:47.299
Dewan Ahmed: get a good at you? You mentioned you were like a decent engineer, like a product engineer. But picking up those other skills. So what would be some of your tips for those.

167
00:24:47.970 --> 00:24:52.760
Vishwa from Zenduty: I think I think today the the risk of starting up is significantly lower than

168
00:24:52.860 --> 00:24:55.679
Vishwa from Zenduty: the risk of starting up. Maybe you know.

169
00:24:55.930 --> 00:25:01.660
Vishwa from Zenduty: 1520 years back. I mean, it depends on which geography you live in. By the way, in in, if you, if you've always been the Bay area, then

170
00:25:01.760 --> 00:25:05.310
Vishwa from Zenduty: the the risk of starting up. Is not that high?

171
00:25:05.480 --> 00:25:12.630
Vishwa from Zenduty: Right? So I mean, you know, most founders, if they have a fair bit of runway behind them to experiment, for, you know. Maybe

172
00:25:12.640 --> 00:25:22.340
Vishwa from Zenduty: if you have at least 2 or 3 years of runway, then you're you're easily. You can easily take a risk and and and work on a product and a work on an Id, or work on a problem that you truly

173
00:25:22.390 --> 00:25:27.220
Vishwa from Zenduty: believe in. And you're truly passionate about. And that passion can keep you going for the last, for the for the next whatever.

174
00:25:27.400 --> 00:25:32.019
Vishwa from Zenduty: 24 to 36 months before you, you know. Hit the market.

175
00:25:32.326 --> 00:25:36.479
Vishwa from Zenduty: you know. Talk to the customers. Get to some level of product market fit.

176
00:25:36.640 --> 00:26:04.139
Vishwa from Zenduty: So I think once there is, once you have a fair bit of runway, or you know, if you're if you're if you if you're able to sort of raise early on right and and a lot of lot of folks who are who have that that depth of knowledge. And if the problem is big enough to solve right, I think I think it. It's in into in 2024. Also it is, might be harder to raise, and in 2024 than in 2021. But it's still you can still raise if you're if you have a fair bit of expertise. And the problem that you're looking to solve

177
00:26:04.495 --> 00:26:09.889
Vishwa from Zenduty: and if you're able to raise, then I think that should that should ease a few things for you. Right? So the the the risk

178
00:26:10.080 --> 00:26:19.509
Vishwa from Zenduty: of starting up personally is not that high, in my opinion, in 2024, the risk of failure still remains the same, or the the the probability of failure still remains the same.

179
00:26:19.933 --> 00:26:32.529
Vishwa from Zenduty: Because the barriers for starting up has sort of gone down right. And therefore maybe maybe in the 19 eighties or 19 nineties, there might be 3 or 4 companies that might, you know, start up to solve a specific problem today, that number would be

180
00:26:32.570 --> 00:26:34.549
Vishwa from Zenduty: 30 to 40, right?

181
00:26:34.770 --> 00:26:38.510
Vishwa from Zenduty: So the while the barriers for starting up has has gone down.

182
00:26:39.370 --> 00:26:40.089
Vishwa from Zenduty: The

183
00:26:40.180 --> 00:26:55.030
Vishwa from Zenduty: and therefore the the the probability of failure has also sort of slightly gone up because it because we are, we are we at least in the in the dev tools space. It's not exactly fully gonna take all that that's gonna be. That's the kind of sort of trend that you see in B to C companies.

184
00:26:55.397 --> 00:27:01.820
Vishwa from Zenduty: But if you're if you're looking to build something in the enterprise space in the the cloud, the devops or Sri or install management space. I think

185
00:27:02.020 --> 00:27:05.160
Vishwa from Zenduty: I think if you, if you have that expertise, and if you are able to sort of

186
00:27:05.230 --> 00:27:10.000
Vishwa from Zenduty: rally customers behind your vision, I think I think you should take the plunge. Shouldn't shouldn't hurt you.

187
00:27:11.190 --> 00:27:19.401
Dewan Ahmed: With that motivation. We'd like to end the podcast and thanks so much. Vishwa, if you're listening to to this. Podcast and if you're looking

188
00:27:19.800 --> 00:27:25.850
Dewan Ahmed: for a platform for software delivery that has intelligence all the way from building development

189
00:27:25.940 --> 00:27:55.020
Dewan Ahmed: deployment and post deployment checkout harness, dot I/O, where we have intelligence baked in at all of these stages, and if there is any incident and you're looking for an advanced incident, response, platform, check out zen duty. Look up, Vishwa Krishnakumar ton of things to learn from his experience. You can obviously connect with him on Linkedin. I'm your host, Devon. Feel free to look me up on Linkedin as well till next time. Thanks so much for listening in.