Julian: Hey everyone. Thankyou so much for joining the Behind Company Lines podcast. Today we have AshokSivanand, CEO, and founder of Integral, a digital transformation firm thathelps businesses with embedding a technology d n to their culture, processesand experiences by collaborating to build delightful products and highperforming product teams.

Ashoke, I'm so excited to chat with you,not only about your background, your experience, but this whole. Digitaltransformation movement, which, I think obviously your company's really focusedon it, but a lot of companies in, in various industries, I feel like are movingto a more digital, whether it's infrastructure, operations or, even from like aproduct sense, they're really integrating, really new and it's fast.

And honestly easy to technology thatsays in terms of the weight also of, of, of tech debt. It's becoming less andless. So I'm excited to chat with you and seeing what, what you've beenworking. And the companies you've been chatting with, but before we get intoall that, what were you doing before you started the company?

Ashok: So before. I, I've gotto move around just a little bit. I I've always kind of had some kind of drawto manufacturing. Yeah. One of my first real jobs was a forklift driver. Andthen I, I was in engineering school at the time. I got to work at a, a GMSuzuki plant and built software for the plant.

And then worked at a startup. In asuburb of Toronto called Shop Logics, where we built software formanufacturing. Yeah. And then. I changed all of that and got got to go work ata company called Pivotal Labs where it was building software. I wanted a littlebit of a break for manufacturing and automotive, and the cool thing was that Igot to learn a lot of how the manufacturing processes or the Toyota productionsystem was put into play.

For how to build software. So I wasalways like in the manufacturing world, building software. And then now I wasin the software world using manufacturing principles. I had this big like humblingmoment where I was like, oh, I never thought to apply. Yeah, these principlesto how the software was built in itself.

So I got to work at this really coolcompany. Pivotal unfortunately it doesn't really exist anymore. They were kindof transformed into a platform company. I was always a services person, so asthey were kind of transitioning away into platform going public I decided tostay in services and that was kind of some of the origin story about startingIntegral, the services business.

Julian: Yeah. And tell, tellus a little bit more about the types of companies and types of industries thatare looking to find more digital solutions and, looking to, to partner with acompany like yours to be able to, whether it's I, I don't know, upgrade theirtechnology. What in particular, what types of companies and what are they,their requests, what are they building internally that, that we don't see?

Ashok: Yeah, I think the typeof companies that we tend to work best with or are happiest to know that weexist are folks who are. Kind of on the bleeding edge or like, the first 30% ofthe innovators, if you will. And those folks know that off the shelf productsand customizing those don't necessarily give them that advantage over theircompetitors, whether it is changing the way they engage their, their customers,or even their internal operations and employees.

And. . And then the other thing that Ithink folks like hearing about us is when they go from transitioning to, Hey,we should use technology more or building technology more to, mm-hmm. , Hey, weneed to change the way we think. And that's where this DNA component comes inof like, it's not just engaging customers and employees, it's about what kindof new business models can we do now that we can.

Powered by some form of technology orhave more automation in the process for things that used to be manual. Now it'snot a matter about automating everything. There is a needle to be thread aboutsome things are best done by humans and where you should give those humanssuperpower so that your customers or your employees, whoever's using thetechnology or engaging with your experience has.

The best of both worlds. Then it getsinto capital allocation. We work in, we're, we're based outta Detroit. Imentioned a lot about my auto background, and usually when you're building anew car that's a three to five year thing, right? . And you have, you've been,like a lot of the car companies have been doing for decades, centuries even.

So you have a pretty good idea of likehow to do that three year project to, to get a car out the line. But whenyou're allocating. capital for software. You can do that in like six weeks at atime, if even less, to go test ideas out before doubling down into like a big thing.So I think like even like the CFO's office and, and then even like the, thehead of talent, right?

The chief people officer, whether it'shiring and organizing talent, you're transitioning towards hiring at differentand competing for a different segment of the labor. and and so that's alsoanother place to think differently. So I think the folks that we tend to servebest are ones that kind of know that, hey, we need to change things at more ofa foundational level of our business, not just in terms of what products we'rebuilding, but actually how we think and how we can really compete with thecompanies on the coasts that way.

So that, that tends to be the, thetarget audience that, that likes us.  

Julian: Yeah. And thinkingabout just, you mentioned manufacturing principles and. Back to my curiosity.What are those principles and is it I guess, yeah, what are those manufacturingprinciples? Just to start, and then I, I'm sure I'll have more questions abouthow you've integrated that within the software development process and, and howthat's been effective to the company, the cu, the customers that you work with.

Tell us a little bit about thoseprinciples and how it's, it implements well with, with your, your.  

Ashok: Yeah, certainly. I, Ithink a couple of the key things that come to mind that I got to learn in themanufacturing world are the Toyota production system and. Yeah. And leanmanufacturing. And the second thing was theory of constraints.

So for the manufacturing or operationsnerds out there, the Toyota Production System book is pretty big. And then forTheory of Constraints, it's a book called The Goal, and it's oftentimes like atextbook in like MBA programs. By written by someone named Eli Goldratt. Andthose were some of kind of the, call it the Bibles that I would study when Iwas working in manufacturing cuz the, we had to empathize with the people wewere building for and they had been studying that mm-hmm.

So for me to write the software, be aproduct manager, be a salesperson in that world, I had to learn it. And then alot of the basis of this on the lean side are really to minimize. , right? Andthere's different kinds of waste that show up in the manufacturing world. Andit's similar in the software world too.

Like if you're building features, For aproduct and no one's gonna click on that button cuz no one will ask for it inthe first place, or no one finds value in it. Then all of the lines of code,all of the effort and coordination that went into getting that feature outthere, it's almost like building a stack of widgets that a customer was nevergonna buy or no one ordered.

So it's very similar to what you mayhave heard of like just in time inventory. not carrying a whole bunch ofinventory, but instead optimizing the process so that when a customer orderssomething that you have it, yeah. Your process can adapt really quickly to thatorder. Yeah. Versus having to place a lot of assumptions and build up a bigwarehouse of inventory that Right.

May never get sold or things may changeand it may become outdated. It's very similar to be able to compare thosethings to software. So, and then, so that's kind of lead in the first bigthing. And then Theory of Constraints is the other one where, there's usually abottleneck to any. Just like in, in a manufacturing line, it's usually theslowest machine, and it doesn't matter if all the other machines are making abunch of noise and doing a bunch of work.

If the slowest machine's not doinganything, then if you zoom out, then you're shipping fewer containers outtayour factory at the end of the day that that heartbeat of the line is the thingthat sets the pace. So in the same way, if you look at the bottleneck of asoftware team or a software system of.

Something goes from ideation to delightfor a feature. There are different steps along the way. Different frictionpoints, different points along which there's little bits of waste are frictioncreated. And knowing wherever that is in your system at all times, and goingand solving for that as a higher priority from an operational standpointcompared to just looking at, Hey, there's a lot of engineers.

Hammer wear a keyboard. We must bemaking money is a very unsafe assumption to make versus looking at, Hey, where'sthat critical point that tells us that this is meeting the business outcomewe're set out for? So those are kind of couple of the main things that I thinkI was really beneficial to see.

Yeah. In real life as things were beingmade in the manufacturing world, so that I could kind of translate into animagination or into a dashboard or something when it comes to looking atsoftware teams shipping. .  

Julian: Yeah. And thinkingabout just like implement for the other founders out there who are, one thingthat you said is being an, almost understanding your team to where the, wherethe bottlenecks are or where the time constraints are, where any constraint is.

How do you kind of think about that whenyou're running a software team, running an engineering team and, and makingsure that they're creating a process, like as you said, when there's an inputor when there's something that needs to be built, it can be built and, In, inalmost like a predictable timeframe because software is so difficult to, toactually predict, when, when it's gonna be completed.

The timelines for projects obviousoftentimes get extended or even get completed more quickly. Ba you know, basedon the, the. Many different factors, but how do you understand more so wherethe bottlenecks are on your own engineering team? How are you setting up? Is itsystems that you have in place to track developers?

Is it understand or is it coming to, tomeetings? And kind of going over the critical information, how are you able tounderstand more about your engineering team, where the bottlenecks are, and howto create a more well-defined process? Anything come to mind?  

Ashok: Yeah, I think. , one ofthe things that we are really lucky to have is that we didn't have to write thebook, right?

Like I came in from the manufacturingworld thinking, how do we apply these principles? And then there are folksbefore us that have done some large scale experiments. So there's a book calledExtreme Programming Explained, and this kind of subset of agile softwareengineering that has some fairly prescriptive engineering practice.

and then you can combine that with otherschools of thought that are based off the same kind of first principles, likeLean Startup is one, human centered design combined with Lean, combined withAgile. There's a very similar kind of first principle that expands the three,and I think we've been able to inherit and iterate on a process that Yeah, putsthose.

Three roles or three problems intolockstep. And the three problems are, hey, what is it that your customer wants?What is it that's worthwhile for this business to further invest in and pursue?And what is it that we can feasibly actually build as an engineering team? ,right? Yeah. So oftentimes I think what happens is that the folks who are maybeon marketing that are responsible for the, the kind of customer facingexperience, the folks who are on the strategy side or maybe on the financeside, that kind of allocate resources and funding, and then the technologists,they don't oftentimes play well together at companies.

Yeah, at big companies, like for somereason. They're in different buildings different countries. The, the marketingteam all and the strategy team have better snacks in their building for somereason. Right? . So it's just like different cultures everyone's operatingunder and you're trying to compete against startups, which are like four folksin a garage.

Who are turning over and constantlyunderstanding what the vision is, understanding and, and sharing context onrisks and goals multiple times a day. So like that context sharing and nothaving alignment in vision and the goals and the risks, I think is like onemajor factor that just. is like startups who can't afford to have that.

Those silos just don't have them. Yeah.And the enterprises who have better distribution, maybe not the same level ofinnovation, have to overcome it. So that's kind of the, the startups versusenterprises are competing which each of their strengths. So we tend to we havelike a, not just an engineering team, we have also a product team and a UXteam.

Yeah. And we've kind of designed itintentionally so that we can bring together, Those three different problemsets. And by extension, a lot of our clients will bring together folks frommarketing and strategy and technology all into the same room. And we'llinitially be the bridge of helping get them aligned and seeing the same thing.

And then once they see the same thing,whether it's in terms of where we're trying to get to, what's in the way, howdo we measure success? , then we can get into a weekly cadence where we drageveryone together and then they start slowly speaking each other's language. Soinitially a lot of our work is like the orchestration, making sure that stuffhappens because these are all pretty skeptical folks coming to the, to roommaking time in their calendar for us and on top of like what it costs to workwith us and, and everything else.

And so that rigorous process isdefinitely pretty important for us to gain that predictability. Yeah. Youtouched on something in interesting that I think. Probably a hot topic. A topicthat has, has caused some level of strife is around like predicting developmenttimes, right? Yeah. Yeah. And I think predictions like I've, I've kind ofworned the different hats.

I've been an engineer before who's beenasked for the estimates. I've been a product manager before, who, who, who'sasking for the estimates. And you see both sides and you realize, hey, theengineers are making a guess. And if you don't take that with a, with a grainof salt, that comes with a guess. Yeah, you're, you're setting yourself up fora false sense of predictability when there's actually a lot of uncertainty.

Right? So embracing that uncertainty isprobably like the common thread of like, Hey, we don't know as much as. Wethink we know what we're doing and, but at the same time, we need to have ahigh level of conviction that what we're doing is probably right. And if we canbalance those two things of like, Hey, we're probably onto something big, butwe could be wrong, and you can manage those two things at a very foundationallevel, then a lot of the other stuff.

tends to fall in place, but human natureis not really like, we tend to want predictability in our stuff and, and, and,and clinging towards good news and like our slow to respond to bad news. And ifwe were different, we wouldn't need the systems and processes. But since we'renot getting these processes in place end up being really helpful for wow,identifying where those risks can be and mitigating them really.

Julian: Yeah. Thinking aboutthe expectation piece, I'm sure you've worked with so many customers at thispoint. Now what, where are the common missed, missed expectations when theycome in to start building technology? If they haven't already had an in-houseteam, or if they've maybe had a bad experience or what, what have you, what aresome of the common missed expectations that companies come to you with and howare you able to realign them?

Whether it's like the process tobuilding their product vision or the what kind of is gonna be incorporated inthe development process. What are some of those missed expectations? How do youkind of alleviate those when thinking about development and thinking aboutdoing this whole collaborative motion and building this process?

Are you able to kind of mitigate thoseexpectations or, or realign them?  

Ashok: Yeah, I think, youknow where. We, this tends to, this, this type of process tends to work likereally, really well in the scale up phase, right? Yeah. And so, you're afounder, you know this, I'm sure a lot of the listeners know that as you gothrough different phases of maturity for your market and for your business, youjust have to kind of rewrite the structures and operating system of yourbusiness, right?

If you put a lot of process in the earlydays, then you're investing a lot for resilience for an idea. May not have legsin the first place, so you end up like burning a bunch of funding. But when yougo from like a team of maybe seven engineers to now have to scale that to ateam of 70, you can't rely on the same level of high bandwidth context that youshare when you're grinding away in a garage.

And folks are working crazy hours andyou have to transition to where something a little bit more predictable. Andthat's almost. . Yeah. The proactive versions are the folks who kind of seelike, Hey, my joints kind of hurt a little bit. Let me start taking somesupplements. Yeah. And then the reactive version is the doctor telling youlike, Hey, you gotta stop eating bacon, right?

Yeah. So whichever way people end up there,I think that's one thing for founders to consider is that like, as your teensgrow, you need to. Come up with like a different operating system to respondto. Yeah. How to gain the most amount of efficiency from your team that'sreflective of the phase that you're in and, and you gotta kind of be savvyabout where you are there.

I think the other things are, in termsof not clarifying what the vision is. And, and that could be like the strategyteams themselves, not necessarily doing some level of primary research, which Ithink is pretty important. There's a lot of industry context out there, andprimary research can, can be done fairly.

quickly and fairly cost effectively, andit gives the whole team an additional sense of, Hey, who are we solving thisproblem for? What's the problem we're solving? How bad of that problem it is,how would they describe it in their own words? So that when you come back toideating features and prioritizing things, that you've got a pretty good sense.

What the customer wants here. And thesame thing with the business, right? The business may be starting out here andconquering this hill, but over time, like the war looks very different. Andunderstanding from the strategy team, like, Hey, initially we want to go hereand after that this is where we think we're going.

We don't know for sure. This is whatwill help us understand what to revalidate the strategy. Yeah. Again, like whenyou're thinking about it from a data analytics standpoint, feedback from the. ,all that context is really helpful. And then for the business folks tounderstand like, Hey, what is it that's really challenging about the technologywe're trying to build?

If it's just a bunch of forms that we'regoing to apply some light level of logic to it, there should be, it should befairly predictable. Now you start to do things that you're expecting the userto respond in a certain way, or you're integrating with some core technologythat maybe hasn't been integrated with much.

there, there's a series of risks thatcan come up, or you're building some kind of model in house and that modelhasn't been validated. Those are things that I think. Going back to what I said,we tend to assume a high level of predictability around mm-hmm. based onestimates and assumptions people are making.

But we forget to ask what assumptionsthey made, or we forget to ask what the criticality is of the implications ofthe assumptions are wrong. . And it's not to say that they should slow youdown, but I think having a better informed team can help you prioritize how togo after mitigating and de-risking is the word that comes up often on ourteams.

Right? And the risks tend to be in threeareas, right? It's those three things we're trying to bridge. Does the customerhave a problem that this solves? They want it, is it usable for them in thecustomer side? Is this viable? Is this worth the investment in the long run? Ifour assumptions are correct, and what are those assumptions around how muchmarket adoption we have, which regions we're targeting, et cetera, and then theamount of investment that goes into the technology and how much we want it toscale.

I think if we put those things intandem, the chances of those missed expectations come down. And the other thingthat I like to co our customers to do is instead of asking the dev team howlong something's gonna take, change that question to what can we done, get doneby this? Right, right. Give them as much context and then let them solve andcome back and like, Hey, end of q1, I need.

And in that way, you just know, okay,you're not moving this deadline, but you can be a little bit more flexible onwhat you build or how robust you build it, depending on how big of the audienceyou're going after. And the more niche you go, the less features you have tobuild and also the less scale you need.

But. It's a high amount of feedback and,and information you can get back, and so getting in the room together andhaving really good facilitation to have these conversations that are at somelevel of a common language so that the engineers and the business folks allkinda understand each other. I think those are ways in which you can pretty easily.

At least get aligned in terms of whatwe're up against and where we need to go so that we can, yeah, it's our risks,not engineering's risks and designs, risks and and so forth. Right. So I thinkthat's that's another thing that often comes up for us. .  

Julian: Yeah. And thinkingabout just the building process or building software and building technology,what and, and, and what you've seen in the market, what are some of the techthat's being used?

What are some of the technology that arebecoming more and more popular and, and why are they becoming more, morepopular? Whether it's a certain type of language, like commonly we see Reactbeing used because part of the JavaScript framework we see React native beingadoptive, to build native applications on both Android and iOS to kind of.

Time, but also have such flexibility andadaptation. What, what technology have you seen becoming more and more popularand, and why is that? And, and, and is it pretty predictive based on theindustry or that, that your client's building in?

Ashok: That's hard to say. Ithink, things like we tend to do a fair amount of work in, in the enter. Andthings like Spring Boot are, are, are definitely adopted a lot compared tomaybe something like Rails, which if you're an engineer and you look at the usecase, you'd think like, Hey, this should be perfect even for an enterprise usecase, but for reasons that that, that adoption never happened.

We we're seeing that kind of transitioncertainly from. , a lot of the other frameworks like angular into more thingslike react type script and so forth. There is a fair amount of backing in theopen source community, I think, and it's being used for some, like Facebookstarted it, right? And it's being used for some fairly complex things, and sothere's a lot of eyes on it.

So anytime you embrace open source from.that's built that's, that's initially started or largely funded by a, aninstitution that has a level of funding like a Facebook does. But it was alsolike competing day in and day out for eyeballs, like Facebook is. There's a lotof flexibility I think. I think what we're seeing, what we saw about a fewyears ago was in this concept of microservices where instead of building yourservice side application all as one, you build it separately.

you can deploy them separately, test itseparately, and enables a lot of efficiency and speed. That's coming to thefront end now, where as companies are getting, as products are getting biggerand you're trying to distribute your teams. M and a activity means like theremay be parts of some new company that you bought that you want to integrateinto your ui.

There are, there's this new pattern ofmicro front ends. It's relatively new that's come out that I think is somethingelse that we're gonna see more of and different tooling associated with helpingwith the orchestration of that across the teams. Those are a couple of things.Of course, there's a lot of buzz with the chat G P T API and what you can dowith that.

I've, until a few years ago, wheneveranyone said they wanna build like a chat bot for their customer service myinitial reaction is like, why do you hate your customer so much? And I think,like, I'm gonna peel back that answer a little bit now because, This, the, thenew tools, this new generation of tools is definitely going to be a lot more ora lot less painful to work with.

Yeah. It's gonna be hard to ever replacethe humans on the other side, but if you can give the same number of customerservice reps, just the ability to go a lot deeper and a lot broader and helpreduce wait times and, and also create a fair amount of self-service. I thinkthere's a couple of things that are gonna come around the corner there.

So yeah, those are some of the, the keythings on the tooling side. On the process side, I think some of the thingsthat lend really well to the going fast that I talked about before on theengineering side are looking at things like your, your, your test automation,right? Yeah. Like really relying on your engineers to be accountable to thequality.

For a large part, and if you have a QAteam, you're using them more for exploratory testing or or consulting to yourengineering team on, on what to look out for in the tests as opposed to having thisbig gate at the end of your development cycle where QA needs to go through allof it before you can go out.

That's a huge amount of time loss and ahuge amount of manual effort that has like massive propensity to be automatedthat I think are things that folks aren't necessarily looking at. Continuousintegration. Alongside these tests, I think is another piece like a lot offolks I find tend to use continuous integration just for building theiterations of their application and having a place to check in their code andintegrate into their repos, but not using this like really available option ofhaving tests.

Yeah. Gate the integrations where whenyou're an engineer and you're checking a piece of code, you know right awaywhether you broke something or not. Right. At that point. And if you did,that's the cheapest, fastest time to fix something is right after you broke it.Yeah. And, and before you push it, before anyone else knows.

So I think going back to that, that,that idea of unit testing all the way up through other higher levels of testingand then having, , your, your team integrating that. I think those are somethings that are, they're kind of like eating your vegetables. It's hard todevelop the habit. Yeah.

But once you get there, you're reallythankful. And a lot of the engineers that even kind of graduate, our alumni goaway and they're like, yeah, there's no way I wouldn't like test drive my codeeven if I'm not working in consulting anymore. And, and we hear the same thingfrom our clients. Another thing is, have you ever heard of pair programming?

Has that come up in  

Julian: Yeah, it comes upoccasionally. Yeah.  

Ashok: That's another part oflike extreme programming, something that we find really useful, both for havingan extra set of eyes on the code and, and driving predictability around thereadability and quality. But more so I think for us it's the. Fastest, mosteffective way for us to take a smart engineer from our client that has maybeworked on more traditional technologies.

J two E. E or or, or, or something kindof more more internal focused and then make them an engineer that can buildlike consumer grade applications that Yeah, whether it's your employees or yourcustomers, they're expecting like, Facebook, Instagram, level of UI and, andresponsiveness and pairing allows for us to get really deep and play with Yeah,our client engineers and then we've, we've taken it from engineering and alsoextended into pair design, pair product management.

So, someone who used to be a projectmanager or business analyst at a client, but what is interested on the otherside, we can pair with them and coach them on how to go from becoming a projectmanager to becoming a product manager and kind of changing their careers, butalso changing the trajectory of what that talent force looks like for theclient.

So I think these are things that. folkstend to, they're kind of very operationally focused things, right? Sure, yeah.And they're not kind of like the latest and greatest that folks tend togravitate towards, around the front page of of, of kind of the, the tech.Magazines or editorials, but they're the try to tested things that if you cando with discipline, it's like sleeping, working out, eating a lot of vegetables.

There's nothing new about those things,but you know that your chances of longevity and the resilient life are a lothigher. So those are the things we tend to be really good at, and we want toteach our folks how to do or teach our clients how to do. .  

Julian: Yeah. And it'sincredible to think about the, the efficiency and the operational likemechanisms behind running, not only, an efficient engineering team, but alsogetting the predictability to a certain point level of confidence.

But, and, and also deploying differentapplications, seeing them, testing them and iterating them quickly andefficiently. It's a hard process to do, and there's so many differentcomponents to be able to actually measure the success of a lot of the things thatyou deploy. And it's awesome to. , kind of your level of knowledge and yourlevel of sophistication and, and consideration at each piece.

Because a lot of times companies will,will partner with, with, a company like yours, and the outcomes are a littlebit, there's like, they kind of miss those expectations, but hearing how you'vekind of defined it and, and, and hearing them, the manufacturing kind of,principles integrating here.

It's so cool to see what it does foractually the. The production level and the efficiency of building products. AndI'd love to, for you to share to the audience. Tell us a little bit more aboutthe traction. How many customers are you working with now? How many customersare you looking to continue to work with?

What's not only excited about thetraction you've seen in the past, I think what, five years, but also what'skind of in the next stage of journey for Integral and, and what you're doing..  

Ashok: Yeah, for sure. We areusually working with a handful of appliance. We've got a team, our, our totalteam, including like back office folks like myself, is in the low fifties.

Yeah. So there's only about five toeight engagements concurrently that, that we're working on. I think what'sinteresting for us, if I look at the future, One thing is we're just gonnacontinue getting better operationally, ourselves. Yeah, yeah. And, and gettingmore efficiently, allowing more accessibility for to our services, for ourclients and.

and, and continuing to kind of chip awayat the new technologies and incorporating them into the system. I think from abusiness model standpoint, something that we're scratching at the surface on,we worked with a client that was kind of a little bit more mid-market. We'vedone a lot of enterprise work with big, big auto companies, big lendinginstitutions, like the biggest in the states kind of level.

We got to work with a private equitybacked company that just has fewer players at the table on their board to makedecisions and. They're remarkably more entrepreneurial. Yeah. And I think forus to do joint ventures and co-investments with our clients is the next thingaround the corner for us. Yeah.

Of, Hey, we validated this and, and, andmaybe like this tool that we've built as an internal tool for you. Could besomething that you can spin out and make available to your partners, yourcompetitors even. And it's gonna be really hard for you to grow that withinyour current organization. So how about we carve it out and go to market togetherwhere we are the product and technology and you are the, the strategy andcapital and share the risk and reward.

And so if we continue along that, 10years from now, it'd be really great for us to be in a place where, We onlywork on things that we invest in and we invest in all the things we work on.And I think having both a product and engineering team allows you to thinkthrough both the strategy and execution really well.

Yeah. So that we can evaluate thosethose product ideas and investments alongside our clients and, and kind of putour money where our mouth is. Yeah. Yeah. Rather than being purely a strategyor purely an execution type of type of services.  

Julian: Yeah. And, andthinking about whether it's external or internal, what are some of the biggestrisks that Integral faces today?

Ashok: I think the techlayouts certainly have like a lot of the, the, the factors here, at this Yeah.Specific time and place that we're in interest rates going up means folks arerethinking some of their investments that they had earmarked for the year.Yeah. And so in the short term, I think we're gonna.

come up against some headwinds withrespect to demand. And, and the tech layoffs also mean that our clients havethe ability to kind of bring in some talent faster than they thought. Mm-hmm. ?I think some of our clients are realizing that it's not just a matter ofheadcount bringing folks in, it's a matter of putting them into a good systemand culture and, and.

Getting some help over there can help themget there faster. So those are some things that we're doing to, to mitigate. Ithink if I think more long term, cuz I, I know this is gonna be a temporarything. If I look back, I think it's going to be Kind of not being able to getout of our way or Yeah.

Or getting to ha get, getting to likewhat they call fat and happy in any specific phase. Sure. Of the adoption curveof what we're delivering versus looking at other options of how we bring in amore global workforce to help our clients, whether it's helping them hire themor using them ourselves, where we're kind of mostly North America centric rightnow and and, and we've gone to hybrid workforce.

I think there's a lot more that we canlearn to overcome time zones, take advantage of other efficiencies there, butat the same time do it in a careful way where you're not introducing a lot ofthe risks that come from offshoring your software development. And that, we'vebeen, we've learned a lot more about in the last 10 years or so as an industry.

So I think being able to be nimble and,and respond to those changes and kind of check our. Is a is something that Iworry about often. Yeah. And something that I'm constantly running experimentswith my, with our team. It's nice to have a product team in-house who, who arereally rooted in experimentation.

So they, they hold me accountable tobeing somewhat structured in terms of the things we're trying and, and, andevaluating the vi. .  

Julian: Yeah, I love that. AndI always like this next section, I call it my founder faq. So I'm gonna hit youwith some rapid fire questions and then we'll, we'll see where we get.

First question is, is just to open itup, what's particularly hard about your job?

Ashok: So I think I am wiredto be a lot better at sort of a bridge between. The strategy and operations orstrategy and execution side, maybe a little bit more lean towards the strategyside. Yeah. And so, day one it was basically myself doing everything. And thenas we kept hiring folks it is delegating different things.

Yeah. And so, Focus and priority is thething that I'm constantly just going back to the drawing board and remindingmyself why we're doing things, checking if it's still relevant, checking ifthere's someone else that I should be bringing along and delegating this worktoo, if it's gonna be big instead of, there's always a thing where you get toolate where you're like, oh, I should have delegated this to like a long timeago, and here we still are.

So that's a really hard part. I think.Another thing is, I've, one of my superpowers was sort of in-person one-to-onenetworking, which was really helpful when we were smaller and also before thepandemic, when there were just a lot more in-person things to, to do. And now Ithink we're kind of slowly building our way back into in-person events and alsofor me to have to teach a lot of that skill around.

why we're here. Who we serve. What wesolve. Yeah. Yeah. How we play and, and, and, and teaching more of my team howto. tell that story so that it's not, I'm not the bottleneck to that anymore.Yeah. So I think oftentimes it's looking at what am I getting in the way of,and how do I get better at delegating that?

Those are, those are kind of some of themain things.  

Julian: Yeah. And we didn'tget a chance to touch on it yet, but tell us about Integral Detroit. Tell usabout what you're running, the, the, the community you're building and, andalso the outcomes that you're really. To share with the audience. I know you,you've been doing a lot of work around diversity and inclusion and, and gettingpeople to, or, or, or working with engineers, working with the teams to kind ofbridge the, the technology gap and, and within this big technology ecosystem.

Tell us a little bit about integrateDetroit and, and what has you excited about the, what you're working on. .  

Ashok: Yeah, thank you. Ithink integrated Detroit, we started it, depending on who you talk to, like notearly enough or too early in the life cycle of our business. Where it was at apoint where I was running two things as a first time founder without knowinghow to run either of 'em.

Yeah. And the goal always was to, evenin our, in our day jobs and Integral as a services business, to have a placewhere people can come and do their best work and, and grow. . Right. And Ithink it's got, and and personal development, professional development, I thinkis. A barrier that we can remove to having our talent gain accessibility to thenext thing they want to go do.

And I think, so not just looking at thealumnus, but looking also at the intake. We realize that it's, it's generallyreally hard to hire talent. When you look at the challenges associated withhiring a well represented group of talent in a city like Detroit, that's 82%black. But it's probably the inverse when you go inside any of the corporateoffices.

Sure. It's a very. Problem that'sstaring you in the face, not just about race, but also in gender. And we knowthat things like pair programming are gonna help you learn how to code muchfaster. We know that things like test driving code, simplify code to read andto write, and, and these are kind of.

Hidden tricks that we have that areavailable to everyone, but no one all seems to want to know . And then thethird thing we know is that the tech ecosystem is going to be one where youdon't really need a degree anymore. Yeah, right. So if, if you're building myhouse or building a bridge in my neighborhood, I would really have engineerswith degrees.

that have certifications, but if you're,there's a lot of code that needs to be written where you don't necessarily needthat, those kind of degrees. And I think tech is also such a fast moving pacethat it's. hard for educational institutions to change their curriculum as fastas the industry's changing.

And so there is another inefficiencywhere like there's this really lucrative industry and career and then a lot offolks trying to get there, but this like very expensive university systemthat's in between it. So we create an integrate Detroit as kind of a finishingschool for bootcamps cuz you realize we can hire bootcamp grads ourselves.

And so we, we started out as a reallyimmersive program. and we're still finding exactly where where we fit in theplace there. It's, it's not for profit and, we, we, we fund it ourselves and westarted out with some income share agreements for our students and now it's alittle bit of an introduction to tech and helping folks kind of consider whatrole in tech to go into.

So if you know someone that is debatinga career switch into tech, check out integrate detroit.org. We put on a numberof workshops, clinics. There's one-on-one mentorship and other thingsavailable, and we've got new stuff coming. So get on that mailing list, come toour events, and we're just here to help people get into tech.

And I think one part we didn't talkabout as much as I started out as an engineer, like I needed one of myengineering managers to sit me down and tell me like, Hey, I love that you cantalk to the CTO and like when you come back and tell us what his vision islike, we seem to understand it a lot better.

You seem to like talking to marketingand sales. None of the engineers like doing that. We love reading your tests.We love reading your documentation. We don't love reading your code though,And, and so I was kind of like forced or someone else made the decision for meto go become a product manager.

And then that, let's say like reallygreat career for me. Like I went from product and then when like pre-sales,engineering, like sales before coming back into product and delivery. And sothere's a lot of folks out there I think. Maybe think that engineering is theonly way and writing software is the only way to build a career in tech, andyou're not necessarily wired to have the same level of patience or focus.

And and you might have like a, anotherbreadth of skills that can come into play where there are other careers thatare adjacent to tech that can be almost, or if not more lucrative withouthaving to write code as much. a little bit of foundation and writing code isalways helpful. So that's another thing that we tend to help folks with is likeidentifying where their skill sets might best align in a tech career withoutlike writing code being the only option.

As much as it's certainly the safest betin many ways.  

Julian: It's, it's amazing tosee kind of how you're, you're using, it's almost like upskilling, but in areally in a really natural way in, in terms of identifying someone's skillset.Leaning into to that, that individual skillset, identifying where it fitswithin this ecosystem.

And also the beauty about startups is ifyou're an individual who's. , a, a jack of all trades, but not necessarily anexpert. It's almost like a, it's almost like a personality like benefit becauseyou're able to be so adaptable and be so, Integral for different parts of thebusiness rather than, trying to define a niche.

You're trying to, trying to be very muchlike, focused in one particular avenue and, and gain value there. It's likeeverybody has their own skillset. So it's awesome to see the work that you'redoing, to hear about the way you're going about it, and, and. I can just seethe benefit naturally as, as someone who goes through the program kind ofthinking about what their skills are, how to lean into them and, and how, howto gain value in different companies and organizations.

I know you mentioned a book earlier, butI'd love to ask you this question because I love how founders, kind of extractknowledge from anything that they ingest. Whether it's early in your career ornow, what other books or, or people have influenced and impacted you the most?.  

Ashok: Yeah. I think the goalwas certainly one that I mentioned earlier.

Mm-hmm. , I think if, if you're afounder, like understanding your systems and systems thinking is prettyimportant. And this is like, it's one of those books that's written like a, anovel and has a story. So it's, it can be kind of a fun read and you'relearning some stuff along the way. I was lucky that someone gifted me alinchpin by Seth Goden earlier in my career, and that kind of talks about thesame thing along the lines of the sort of jack of all trades concept ofthere's, there's different things that you're doing every day that you can bereally good at.

You don't have to be good at just one.You can be good at combining a couple of those things and making yourselfindispensable. So, folks who are younger in their careers, the book's a littlebit dated now, but I think a lot of the same, same principles that apply. Andthen I don't think I would've gotten into, like, jumped into entrepreneurshipif it weren't for four Hour Work Week.

And yeah, it's got a very cheesy title.That sounds like very unrealistic. But if you go past the book, the title andactually get into the book, I think there's a lot of mental models and. And,and challenging of assumptions in the book. And then now, like if Tim Ferrishad a church, I would go every Sunday.

I, I'd listen to most of his work andI've kind of followed his journey from being like very efficient at work tovery efficient at learning, to now being more emotional and spiritually mindedand, and kind of learning. Things that require a little bit more of a leap offaith. So I've, I've been able to kind of follow his growth and been thankfulfor the content he's putting out to be able to, to kind of learn from all thefolks that he gets to surround himself with.

And, yeah. So those are some of thethings that come top of mind of things that I, I tend to follow, listento.  

Julian: Yeah. Incredible. I, Ilove, like I said, I love asking that question because every founder hassomething similar, something different. And if they read the same books, theyextract different things.

So it's always, it's always exciting tolearn more about what you've ingested and, and how you've kind of taken thelessons and, and implemented them. Last little bit before we go into yourplugs  

Ashok: actually, oh, goahead. Sorry. Sorry to interrupt you. There's one that I, I find myself rerecommending to founders outside the Midwest a lot.

Yeah. And that's, it's, it's calledTraction by Gino Wickman, and it's part of like e os. And. I am surprised. I, Ithink it's, there's some level of Midwestern nest to it. Mm-hmm. and I feellike folks on the coast are like too cool for it or something. But it's gottareally, it really simplifies like how to run a business, how to operationalizeyour business.

So yeah, if you're a first time founder,it is totally worth checking the book out. And then you can go real deep, youcan hire consultants, come and help you implement it and everything else. atleast just get started by getting some of that primer on, like how to run abusiness. What are the core parts you need to think about that, that book,traction By by Gino Wickman is one that I find a lot of folks come back andthey're like, wow, I had no idea this was here.

Yeah. And it's usually folks in thebigger cities that tend to think that, they've got it all figured out that havethe biggest, like, humbling moments after reading it. So for the founders, Iwould definitely have have them check that one.

Julian: Amazing. I love that.I'm adding that to the, to the reading list.

We always kind of promote those and Ilove, I love that different type of knowledge, and, and what founders bring tothe table, so I appreciate you sharing that as well. The last little bit beforewe give you a chance to give us your plugs, your websites and LinkedIns and allthe, the areas we can find you, is there any question that I didn't ask youthat you wish I did or that you would have liked to answer before we move tothe last little part here?

Ashok: man, I think you werereally well prepared. I think you covered a lot of the stuff that I thought wemight hit, so yeah, I appreciate that.  

Julian: Of course, of course.Ashok, it's been such a pleasure chatting with you. Not all, not not only justlearning about your entrepreneur journey and your experience, but also how youthink about building, how you're implementing systems within your clients and,and really creating a, an amazing ecosystem around technology and, andupdating, kind of not only the.

The infrastructure within a company, butalso the ways that they're building what they're building, the testing process.And I'm always excited hearing that more companies are building more coolthings because that means at some point it'll affect me in my day-to-day lifeand whether I can see it or not.

So it's so exciting to see that the lastlittle bit. Give us your plugs. Where can we find you? Where can we supportIntegral? Where can we find you and support you as a founder? Give us yourLinkedIns, your websites, your Twitters, anywhere where we can be a supporterand, and even a fan, and maybe even a customer of, of what you're working onand what you're doing at.

Ashok: Yeah, I, I'm lucky tohave a relatively unique name, so Ashok Sivanand on LinkedIn, on Twitter are acouple of places you can find me. Our website is Integral.io and I think ifyou're, if, if you're a technology leader and you are trying to balance betweenhaving, scaling a discipline team while also meeting.

Increasing demands of your business.Yeah. With, with smaller budgets and looking to make some, some changes thereschedule some office hours with us. We are totally happy to just nerd out withyou. It's totally pro bono and, and point you in some directions. And if youlike what you see, we can, take things more formally.

Same thing if you're a product designer,product manager, software engineer, or you like doing data. Yeah. Check us out,check out our career page. We've got our working agreements and values andstuff published out there, and give you a sense of what it's like to work withus. And that's all@Integral.io.

And then as I previously mentioned, ifyou're looking to, if you're looking to do a career switch into technology andyou find it overwhelming and you could. Some more humans to come pro solve someproblems with, do a workshop with or, or have someone on one chat, go to integratedetroit.org, get on the mailing list, come to one of our events and and we'llsee you there.

If you're in Detroit Integral Detroitmeetup is something we're bringing back after the pandemic. We're having ourfirst one April 17th, so that's another place that you can come out and meetsome of our.  

Julian: Amazing Ashok. It'sbeen such a pleasure having you on the show. I hope you enjoyed yourself andthank you again being on Behind Company Lines today.

Ashok: Hey, thanks a lot forhaving me. Cheers.

‍