4 Transformation Tips For Technology Leaders feat. Sachin Castelino, CSTO at In-Solutions Global Ltd

Show Notes

This week on the API Intersection podcast, we spoke with Sachin Castelino, Chief Strategy and Transformation Officer (CSTO) at In-Solutions Global Ltd. This company provides real-time payment services to financial institutions and is now expanding that to merchants, government entities, and education institutions. And–they are also a Stoplight customer! Sachin has been at In-Solutions Global for over a decade, participating in everything from Hr, project management, tech, and product. Here, he speaks on his four tips and lessons learned from his time as a transformational leader that other program leaders, transformation experts, and technology experts can apply to their own technology transformations across their organizations.

Since the recording of this podcast, Sachin’s team has since launched their payments and services platform. Be sure to check it out!

https://insolutionsglobal.com/ 

To subscribe to the podcast, visit https://stoplight.io/podcast

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here: stoplight.io/question/

--- API Intersection Podcast listeners are invited to sign up for Stoplight and save up to $650! Use code INTERSECTION10 to get 10% off a new subscription to Stoplight Platform Starter or Pro.

Offer good for annual or monthly payment option for first-time subscribers. 10% off an annual plan ($650 savings for Pro and $94.80 for Starter) or 10% off your first month ($9.99 for Starter and $39 for Pro). Valid until December 31, 2022

What is API Intersection?

Building a successful API requires more than just coding.

It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.

In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.

Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.

They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.

They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.

Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.

I'm Jason
Harmon and this is API intersection

where you'll get insights from experienced
API practitioners to learn best

practices on things
like API design, governance, identity,

versioning and more.

Welcome back to API Intersection.

So it's, it's funny,
over the course of the year

and change
we've been doing the podcast here.

I think our most common refrain is that,
you know,

these sort of big transformations
when it comes

to, you know, using APIs to maybe redefine

your company as a platform.

The hard parts, not tech, it's
quite often the culture.

So I'm particularly intrigued today
to talk with Sachin

Castelino,,
our guest from In-Solutions Global,

who is their Chief Strategy
and Transformation Officer.

So Sachin, thanks so much for
taking the time to join us.

Thank you for having me.

And my co-host, as always.

Anna, thanks again.

Pleasure to be here.

All right.

So Sachin, you're at In-Solutions Global

which I know in some sense

the “in” in In-Solutions is India
and there's payments and there's all kinds

of interesting global countries
the other end but tell me more about it.

Yeah so ISG, at ISG

we provide real time payment services

to two financial institutions
and now we're expanding that

to merchants, to government,

government entities
and to education institutions as well.

And as we go along, where we're further,
further trying to expand that

and I have been in the organization

now for the last for the last decade,
a little over a decade now.

And I've been in job rotation
within the organization.

Right.

So, so I've done, I've done work in h.R.

Project management, technology
and product.

And that's, that's where I got introduced
to, to understanding

product and all the products that we do
and payments

can, can get, can get very, very,
very complex, very, very quickly.

Right.

And the technology change
that is constantly there

is absolutely phenomenal.

But where I started to actually learn

how to potentially manage
these technology triggers

was when I took over in 2016.

I took over

doing our international business
and sales.

So so this was now more of a customer
facing role.

And I'd go, okay,
just understand from the customer

what is it
that they're trying to trying to achieve?

And because of my product background,
it was like,

okay, enough,
this is how we try and deliver it.

What I realized throughout that
is that while customers say that all

this is what we want actually,
because they don't know everything

that's out there, right?

So, so, so what ends up happening
is that there's an underlying pain point

behind those solutions
that we're talking about.

And looking at the underlying pain point

and then creatively coming up with
something is, is something that

ICI has been

has been working on the customer
centricity in mind.

So it's kind of remarkable.

You don't hear a lot of product

people that take on a sales role
or a business development role directly.

What did you learn from that experience
and what would you share

with other product people
who would be interested in that?

Yeah, so see, for me, I think

so when I was in in the product
side, right.

So what we, what we used to do initially
is saying calling it customer centricity.

We said do whatever
the customer said. Right?

So in a way what if what?

Because, because we,

we were constantly innovating with what
the customer is saying that we should do.

We always
then had a customer for whatever we built.

Right.

The the challenge that we face with that

is that sometimes adoption was not
was not there for for

like I said, it's there for one customer,
but it's not going across.

And and we weren't able to pinpoint
exactly why this is happening.

We're like, okay, this.

And customers
obviously are very knowledgeable about

what is it that they want and what is it
that they're trying to get built.

And we were just wondering as to
what is it that we're that we're doing

incorrectly, right.

So from a product standpoint,
we were always like running and running

and trying to chase deadlines
and trying to get get that done.

When I moved into sales, right,

that's when I started to understand

the app, struck nature
of some of these conversations.

Right? So so the customers

themselves
are just trying to figure this out, right?

So so they see a pain point.

Then they're like, Oh, okay,
let's try and find a solution like this.

Right?

And more often than not, as as us

tech or because that face of that,
oh, this is the solution that is needed,

we don't see that the thinking

that goes behind in trying to
to get to that solution.

From a sales standpoint,
I got like insight into seeing

how they talk about their pains
and how they they're like, okay,

this is what we're facing, a challenge.

How do we solve this?

So, so getting involved
in that conversation

and that conversation
with a product background

that helped me,
that that helped me massively.

And it is what is driving
a lot of my strategy and transformation

work throughout the organization.

There's two things in there

about the job of product
that I love that you touched on.

One is don't build a better horse, right?

Like find out what job

they're trying to do and and build
something that solves the problem.

Don't just ask what they want
because that often

is not as good of a result that it can be.

And two is talk to
your customers is shocking

how many product teams
never actually talk to a customer

and it's impossible
to figure out what they want

that way.

So the other thing
that you were touching on in there,

I think is is very simply that

that reuse

is one of the most important things
in building products.

And to your point,
it sounds like you're building

a lot of kind of more single use case
bespoke things for particular customers.

And to me that's like
the heart of building platforms.

So is that kind of, you know, been this
shift for you guys in platform thinking?

Yes. So I think

for us, yes, the the the

the doing what the customer says
sort of approach gave us sustainability

in terms of longer, long activity.

But we were obviously having a challenge
with scalability, right?

So, so our ability to scale across

the firstly across the nation
and then across the globe

without a platform for process

that that wouldn't come in.

So the mindset shift from,

at least from my perspective,
was to start to use models, right?

So, so there's,
there's a great communication model

that is the business model canvas and,

and all the things that are around
that, right.

The customer
proposition, value proposition

and then the entire
design thinking approach

which I have

started to now get all stakeholders
involved with it.

So is sales to product
to even developers and operations, right.

So, so everyone gets involved with it.

It's a common language
that we now that we now start to speak

and what we end up doing here now

is to is to ensure that product.

People ask seeking
the customers are understanding.

And if you've seen those canvases right
that ask specific questions that says that

okay have you identified the pins,
these are all the pains, have you done it?

It's a great checklist for any product
person to take a look at it

like, okay, I don't know this, right?

Do it

while I understand this is a solution,
but I don't understand X-Y-Z right.

And whether what I've understood
the job spans of games of a customer

that to me

is where understanding the customer

profile is what is a step forward
towards that platform.

Thinking where we where we say
we have an understanding

that now these are customer profiles
and stop going solution for us.

It's not just understanding this,

my customer profile,
this is what we're trying to solve.

And then from there to say that, okay, now
this is how we can build a platform

that is scalable
and and move forward from there.

Speaking Anna's language and product
marketing here,

all these customer profiles and.

Your.

SO well,

I do have a question about that
so you said you you have to make an effort

to get everyone to speak the same language
in prepping for this interview in your

your prep deck, it said you experienced

what you would call a threat
or people with the feeling of a threat.

What was it like encountering folks
who weren't speaking the language

and what have you done to help
get over that hump?

So I think

initially, right. So

okay, so so as an example, I can give
is this right?

So if a customer

if if we see in the market that there is a
which is happening today

where people want to start
building out their own view on us.

And so so when we talk about
financial institutions or other fintechs,

etc., they want a payments
platform at the back, but

they want to build their own undue access
because that's their USP.

That is what differentiates
them in the market.

Now, there are two ways of approaching
this, right?

One way is to just say that, okay,
the salespeople or somebody knows this

or the market knows this
and all they go to the product guide

and the development guys is
like, Hey, guys, good APIs,

right?

And these guys just really don't know why
they're building these APIs.

They're like, No, no, just build
the API and just get it done.

The second approach,
of course, is to say, Guys,

the the these customers
are looking for their own UI and UX.

They want it to be their USP.

What can we use to to achieve this?

And the answer can be API,
the answer can be BPM, etc., etc..

All right.

So that that can be various
technology tools that we come in,

that we can come in as a set and we can
and we can move this forward.

So the first style of communication
is, is abrasive.

It's a little threatening, right?

So it says that, oh, build API.

So then the UI UX team
looks and goes like, okay,

so are you trying to make us redundant
or what's going on?

And, and it's not clear, right, as to
why we're why we're doing this.

What I've

seen in my experience is that actually

embracing technology, all it means is
that people can do more, right?

So rather than saying that
they can learn more, they can do more.

So rather than saying that, oh,
I'm going to be redundant, the the

the piece of this customer centricity
is what galvanizes people together, right?

So I haven't met any operations
developer product person

that says that or I'm not going to solve
this customer trademark.

Right.

So, so they, they,

they don't want to build something
and keep it in their laptops.

They actually want it
in front of the customer.

And the simple thing for me is that,
okay, let's show them

that what challenges
the customers are facing.

As as our VP of Engineering

often says, you know,
if you don't enjoy solving problems

all day long, especially for other people,
then you might not be in the right

business of building software.

Yeah.

Yeah. I mean, change is hard, right?

I think that's what you're
kind of touching on here. And

it's like and of how to predict

what what is the future going to look like
for where we're going?

Like,
have you kind of seen that any sort of,

you know, defining vision
or being more transparent with strategy,

those sorts of things have made that
any easier?

I think it has made it

a little bit more scalable.

The people are now

open to understanding

why technology transformations are needed.

That's one.

Number two, one of the biggest
four processes that we are driving through

is that transformation
is there's no end goal for this right.

So transformation
sometimes an abrasive term.

It's it's it's an ongoing process, right?

So, so my goal and my aim within
the organization is to is to ensure

that there is a method for everybody

for now and in the future to think about

how things are

changing in the market
and not to be overwhelmed by it,

but actually just put it in a structure
and then say that, okay, so

today these
these are new things that have come in.

Leave that aside for 1/2.

This is a structure that talks about this.

The customer, this this is this
how we're going to solve the challenges.

Now, let's see in our tool kit,
in our tool set, which is web providers.

So providers like Stop Light

for, for example, providers like head of
this is yours, etc..

All right.

They want this so many,

so many organizations,
great organizations, all that help us.

But if we don't define that, define
what these challenges are

and how how we want to protect
particularly approach this

none of these
organizations can particularly help us.

Right.

So so for me,

the underlying

piece in a nutshell would be

is that keep the customer in mind.

And I really like, for example,
Simon Sonic's

way of talking about an infinite game,
right?

So, so there's this not a finite end
goal, right? So,

so we need to keep moving forward, keep
trudging forward and keep moving along.

And it always makes me think

we're ten manufacturing sector for a while
and it did

all this kind of lean manufacturing stuff
and we do these Kaizen workshops, right?

And likewise and the Japanese word
is basically constant improvement.

Right.

And I think the mindset that goes with it
that like it's

not that anyone's doing anything wrong,
we can just always do better.

And I think some of that kind of kaizen
spirit is in what

a lot of these transformation
efforts are all about.

You know,

I'll admit here, I think for listeners

that might be reaching the point of going,
this is a lot of fuzzy.

What is transformation, right?

Like what exactly are we talking about?

So like when you look at

especially in kind of engineering circles,
what are the kind of specific

behaviors or kind of changes in approach

that that you're looking for
or that you've seen work?

Well.

Okay.

I think the first thing is and
and if we if we

if we actually do an analogy
along with like systems, right?

An API is a great example.

Right? So, so APIs are

consistent
ways of communicating between systems.

Similarly
now if we take that into the real world,

having consistent ways of communicating
between people

is, is, is extremely important
because that consistency

and that discipline needs to be designed,
right?

So, so today, today
we take tech language as a

as something that is it's a given,
you know, English unknowingly.

So we're going to understand each other,
which isn't necessarily true.

So which is which is where for me,
from a transformation standpoint,

the first thing that
that I have to come in

and do was to see how people are
communicating across the organization

and whether there's a design
that there wasn't.

And and I've seen this across
a lot of organizations, right.

That the communication designs are

are pretty much nonexistent across
a lot of them.

Right. So

so the first thing that I, I worked

on was to say that, okay,
if we're communicating a business idea,

this is the format,
this is how you go about it.

These are the rules, right?

If you're communicating
like a service issue, this is the format.

This, this is this.
These are rules, right?

So the first thing for me was set up
a clear

communication design
across the organization.

Then the second thing is to
is to tell everyone that, look,

just because this word
transformation in my title

does not mean that every room
they're entering, I'm trying to transform.

So so
because I as coming to your point, right.

The people can think about this and say
that or am I doing something wrong?

Right.

And that's not the case.

It was it was fine for

when when you did it, it worked.

And that's the reason why we're having
this conversation, that we can be better

if if that person hadn't taken, let's say,
for example, certain shortcuts

or even in terms of technical debt,
like so taking on certain technical debt,

taking certain shortcuts,
even in product builds

for for that short term
to describe that business,

we wouldn't
be even having this conversation.

I So it's like I'm more than happy

I, I have work and I have a job

because you guys took those calls,

got the business in,
and now we're just trying to improve it.

That's it. So

I think that message
going out to everybody,

I start, we're fine,
we're just getting better and, and, and

structuring the language in

which with these messages go out,
I think is extremely important.

And I think would be the first thing
from a transformation standpoint.

This is the first thing that I did that
that I see working

that that I think

every organization should think about.

Another element I've seen before,
having been involved in some of these,

you know, transformational efforts,
is that any kind of

organizational siloing that cuts down
these communication channels, but

where the rubber meets the road
and the problem really emerges

is that code
isn't being shared effectively.

So I'm curious, you know,
sort of inner sourcing approaches

or, you know, just kind of different ways
of providing code sharing

and kind of cutting down
on duplication of effort.

You know, is this sort
of a practical theme that you've seen?

It's it's
something that we all want to aspire and

and get to.

Right.

I have

said so whenever I sit with a board
and see you and everyone goes like,

oh, this person's doing this
and this person's doing this.

Actually the same thing.

Like, yes, I understand.

But at that point in time,
they needed to get certain things done.

And this is what happened right. So

and to touch to your point
about silos, right?

So so my personal view here is

it depends on how the silo is structured.

So if the silo become self-sufficient

and we have those those pockets

within the organization, right,
where where there is the product,

technology ops and network security,
everybody's dead, right?

They really don't need anybody else.

And they can function and work
and they keep the customer happy because

deliveries are quicker,
everything moves faster

and they're able to move with speed.

So the way I look at it is silos aren't
necessarily bad.

There are pitfalls or risks or challenges

and so too so to touch.

Touching to your point

and this is what we're working on
and going forward,

which is where to say that, okay,
the idea is not to cut down on silos.

The reason

why silos start to become little dangerous
is when there's no communication.

And so the idea would be
is to is to try and target

how does communication
come out as quick as possible

from that one

little silo to the next?

Right.

So so we can potentially
then using technology.

And that's one of the main reasons
why something like stoplight

is, is we bought into that because

because from a structure perspective,
I'm more than happy for

for people to to be self-sufficient and,

and to be able to deliver
quick things out into the market.

Don't really believe
in a lot of hierarchies.

But at the same time

and given
today's technological world, right.

So we need to equip

and I need I working on equipping

the entire teams to be able to communicate
as soon as possible,

rather than to say that,
oh, I need to break down the silos.

So, yeah, so, so that, that is my approach

towards, towards discord sharing

and trying to avoid rework

as much as possible.

So I have to add, first of all, I haven't
put session up to put in the stoplight

plugs, you know, in a nutshell here, but

and I would also call out, I mean,
I think some of the things that you're

talking about, you know, you're talking
about kind of functions, right?

And there's nothing wrong
with being organized around function.

For me, it's like if
if a silo becomes like a power center

and that creates friction
with other power centers, right.

And kind of power dynamics
and just being honest

about the situation,
that's really like that's where things

can break
down and you just have dysfunction.

And to me it's like it's not, you know,
to product and engineers talk perfectly.

No, never.

Like you're never going designers
and engineers speak a different language,

for instance, right?

Like it's fine that we have functions
and that we have, you know,

kind of boxes that we put those things in.

But to me it's about breaking down
those kind of, you know,

weird power dynamics and getting everyone
to collaborating more.

I think it's just my take.

Yeah, fair enough.

Yeah, makes sense.

You know,
I'd also I'd like to thank you here for,

you know, sometimes I think, you know,
folks come on to the podcast

and feel like, you know, we need to show

how we've got it all together
and we got everything perfect.

And I really love that

you're being transparent about, hey,
you know, we're we're on a journey here

and there's a lot, a lot to do.

And some things. We're still aspiring.

We're still working on.

So, I mean, when you look at it
and I know you already said

this is a never ending thing,
but you know how far along the journey is?

Is this still early stages?

You know, how kind

of complete or comprehensive
do you feel like you are at this point?

So yeah.

So, so one thing about me is
that I'm never satisfied.

So constantly in my life,
I'm like, I'm I'm still on day one.

But we've, we've been we're
I think we've been embarking

on this journey for it's
been almost two years now

where where we
where we consciously took this decision.

Right.

So unconsciously things were happening,
right?

Like where, where we were saying
that, okay, we were being reactive to, to,

to market forces
and we were being reactive to

what a customer is saying
or what people are saying, etc..

Right.

But I think two years ago
we're just taking this call.

So this was right before COVID,
so 2 to 3 years now actually.

So we're taken with,

yeah, cocoa
just melted time a little bit. So

yeah.

So, so three years ago we had taken
this call and we said, look, we need to

consciously look at how we're doing this
communications.

We need to consciously
look at how we're approaching technology.

Right?

So because prior to that,
we had like these pockets, right?

So, so we had a pocket
that was working on flour.

There's another pocket working on someone
else, working on something else.

That was one
that was working on in memory processing.

Someone else was building their own

in-memory
processing stacks and things of that.

Right. It was, it was

like what I see take stock of like
the number of things people have done.

I'm like, we've got some really brilliant
guys who have like going to like try

to do things that that I wouldn't
even dare, like touching and saying that,

Oh, you've got to do this.
Like they've just gone and done it.

But yeah,

the approach was, it was,
it was slightly reactive.

So three years ago, like not we've got
to be a little bit more proactive about

what we're investing in and how how this,

this technology change will take place.

All right.

So if you've ever listened to the show
before and don't read,

don't assume that you have
the most common thing that will always

kind of poke at here is like, all right,
you got three years hindsight now.

It sounds like you got kind
of a lot of irons in the fire.

There's a lot going on with,
you know, trying to drive change,

you know, what kind of wisdom

would you pass on to other folks
in terms of someone listening going?

That's a lot like where would I start?

Where would be the most sensible place
to start thinking about

making a transformational change?

So so for me, I think the initial start,

at least for me, it was myself, right?

So just like sit down one day,
just look through my week

and see how much I was reacting to, right?

So how many things I'm reacting to
what's coming my way

and how am I doing this reaction?

Is it just off the cuff things?

Is it is it things people like?

Okay, very quickly, like, oh, no, do this,
do this, do this, like things on the fly

or how much of it is actually

it's so, so, so from a transformation
journey, I think the initial thing to look

at is, is the mindset that, that, that

we approach this transformation with.

Oh one example, right

while I was in product,

I was always thinking of everything
should be perfect, right?

Like system.

Once things are live,
it should just work smoothly.

There should be no challenges.

We will have the right team in place.

Anything happens, blah blah.

Right.

We all know in reality
that's not how life works.

And for me, accepting that was one of a
big transformation for myself.

Right. It's okay to have technical debt.

It is okay for certain people
to have taken the shortcuts.

This is the nature of the business

for me.

I have seen this with certain
other organizations,

the people who don't accept that, oh,

this there's this technical debt
and things that are needed.

They spend up, they spend a lot of time
admiring a problem.

Right.

So it would just be like,
wow, what a beautiful problem.

But and like, when are we going to talk
about solving this?

Right.

And this is something

for us.

We're like, I'm just much more happier
taking on that technical debt and taking

on those aspects
and that mindset shift to say, it's

fine, it's okay, let's move, let's move,
let's go forward.

That was one of my transformations
that I needed to do.

So I would say anybody listening to this,

just just think about like where is that
mindset shift potentially needed?

Maybe, maybe someone's absolutely perfect
and absolutely suited for the role

for me, I had to
I had to really introspect

before I started to talk
about how I can work

and help the organization. I love it.

It sounds like the 12 steps
of a transfer of a change junkie.

Right.

Like, have you

have you gotten to the part where you made
amends for all the past transgressions?

I'm just kidding. No.

Yeah, no. I love that, though.

I love the introspection and that

it's it is about the mindset.

And I think that's that's the bit that

I've certainly seen in a lot of, you know,
smart folks have talked about that.

It's like it's
how you think about problems.

Right.

And I love that you're calling out
that sometimes just admitting

there's a problem and admitting
that everybody has problems like this.

And it's kind of normal
when you're building software

and it's like what you do about it
that counts, right?

So super

personal.

It feels like a good place to wrap up.

Any other words of wisdom
or things you want to highlight for us?

Oh, well, I think

like, well, what if plug in a plug
in a lot about stoplights.

So what I would yeah.

What I would like to put in as well
is that one of the reasons why

this this journey and
we embark on this journey, we're actually

launching our platform payments
as a service platform

this September.

And we've got we've got a couple of large
financial institutions

that are going live, live,
but the ones already live.

And another one
this that's going live for that as well.

So so to your point about where we are
in the journey

from a platform standpoint
with very close, we're almost there.

So this is just the beginning.

Very cool.

Well, yeah, I think by the time

this actually goes live,
it'll probably be around the same time.

So we'll get the link from you by then
because I want ask for asking for it now

and how that goes. There's
probably a word for what the link will be.

Effect.

Go. Well, I really appreciate it session
and thanks again as always in.

All right thank you. Thanks for having me.

API Intersection Podcast
listeners are invited

to sign up for Stoplight
and save up to $650.

Use the code intersection ten

to get 10% off a new subscription
to Stoplight, platform, starter or Pro.

Take a look at this episode's description
for more details.

Thanks for listening.

If you have a question you want to ask,
look in the description of whichever

platform you're viewing or listening on,
and there should be a link there

so you can go submit a question

and we'll do our best
to find out the right answer for you.