Like if the the transition from individual contributor to
managers, a challenging one manager to exec is brutal.
Like everyone's talking an alien language.
I had to rapidly learn there that even though my title was
tech, I now no longer worked in the tech team.
And that took the whole concept of cross functional team for me
to completely understanding. The businesses work, how are
they growing? How do they make money?
The highest value activity you can do for any organization is
the people that you bring into that organization.
If you don't invest time in that, the cost of getting that
wrong is just ridiculously high. More often than not, people's
hiring practices are usually designed to prove that people
aren't good enough. What I often do when I'm working
with teams that are hiring is like, try and rewire that a
little bit. As a leader, you need to create
an environment where people aren't working in a state of
stress or fear or panic, and that's how you're going to get
the best out of the group of people that you've got.
Whereas before, you know, early in my life, fiery Scotsman, you
say something I don't like. You got an answer Just through
practicing meditation. I feel like I've just got a
little bit of muscle in the middle of my brain that when I
receive information, I can take a pause and go, huh, all right,
how am I going to choose to process that?
There is also a lot of other practices around how you
declutter your life or how you basically eliminate stress or
how you improve sleep. Personally for me, I feel like
I'm more relaxed. I feel like it can be a better
leader to the people that I work with.
Whereas previously I would have just been go, go, go, go, go.
Like, you know, we've got to get results as quickly as possible.
So. And that's what my values change
for me really. Hello, everyone.
Welcome back to the new episode of the Technical Journal
Podcast. Today I have with me Norman
Noble. He is the CEO of Mindvalley.
Mindvalley is a company that I followed for a long time and it
has been transformational for my personal growth and personal
journey. So I'm really excited to have
this opportunity to speak with one of the executives from the
company, right? So, Norman, welcome to the show.
Thank you. Right, Norman, maybe let's start
in the beginning by asking you to share a little bit about
yourself, maybe some career turning points that you think we
all can learn from you. I originally am from the
northeast of Scotland, but I lived in Australia for quite a
long time and then I live in Asia.
So I've got this mixing up accent that people often confuse
for Irish. But yeah, I mean, in terms of
career, you know, I started out quite early.
I was one of those kids that was always playing around with
computers at a very young age, lucky enough that my parents
supported that and that helped me, you know, get into that.
And yeah, I was actually thinking about this morning.
I think I probably did it for longer than most.
Just being an individual contributor was easily, you
know, the 1st 1516 years of my career.
And I did that without really having to think much more of it
than that. And then I obviously moved to a
larger company called Seek somewhere along the line.
And that was probably the first point.
I'd worked at a company that was at really large scale.
And that was really where I got my first opportunity to look
after a large group of people. And that wasn't even by
deliberate design. You know, it was kind of, I was
happy doing what I was doing. There was a big transformation
project going on. And, you know, a large part of
that is you have to convince people and you have to get
people on board and you have to kind of bring them along on it.
But, you know, so there's a huge learning curve around people.
You know, up until that point, I'd been solving problems
primarily with software and programmed hardware and, you
know, reasonably predictable stuff.
But then when you move into the domain of people, it's very
different. You know, you're dealing with
people's self identity. You're dealing with people's
emotional responses versus logical responses.
You're dealing with people's own, in many cases, their own
career ambition, their own, you know, fears.
So initially it was kind of scary.
And then, you know, I, I, I remember the first couple of
meetings thinking I am way in over, I'm way over my head of
this. But then I just started to
really enjoy it. Like, I realized that, oh,
actually this is just problem solving with humans rather than
with, with computers. So I kind of went deep in that
area and started reading as much as I could about psychology and,
and behaviour and, and incentives and leadership and,
and the more I went down the, the track of people, the more
interest that I got in. Well, OK, we've got people.
How do we make sure that people were bringing the organization
of the right people? So, you know, I kind of went
deep on hiring. I went deep on career growth and
development and spent a large amount of time with Seek
revisiting how we hire, building a grad program.
That was arguably one of the most fun things to do was
building a grad program. Really enjoyed that.
And you know, all that work just led to eventually there was an
opportunity came up. Seek as a business was growing,
there was a bit of a reshuffle in Seek and it was like, OK, we
need to consolidate the business and unify our product set and
then be faster. So, so that was another key
inflection point. We, we thought we were settled
in Australia. We were going to live there
forever. And then, you know, I had to go
to my wife and see what do you think about living in Malaysia?
And you know, initially it was just meant to be, you know, they
call it a 2 + 1. Like you're here for two years
and there's a possible one year extension.
I came over here thinking, right, this is a technical
people transition job and I'm going to help here.
But then I think I've been here for about 6 months and the CTO
of the company at the time, a guy called Daniel Walters was
moving back to New Zealand. So, you know, it gives me a
message one day, hey, I'm moving on.
You're being pulled into the the Seek Asia exec team as my
replacement. So that was another inflection
part. I was like, OK, I'm going to
look at this differently now. And again, that was just a
completely different world. I had to rapidly learn there
that even though my title was tech, I now no longer worked in
the tech team. You know, I worked in a
commercial team. There was marketing, there was
sales, there was HR that that was my primary team now.
And you know, that took the whole concept of cross
functional team for me to a completely new level.
But what that allowed me to do is that allowed me to just move
in a new space of just understanding commercial, you
know, like why businesses do the things that they do, what, you
know, how they're trying to grow.
That was just a whole new problem set for me.
It was like, you know, we, we've done the technical, we've worked
with people and now it's like this new interesting world of
how do businesses work? How are they growing?
How do they make money? How do they move into new
markets? That was really good fun.
Seek as a company that was going through a lot of change at the
time. And there was as a new CEO came
in, there was a reshuffle of leadership.
And that's where I, I, I jumped off into Boost at the time it
was an E wallet and it was transitioning into a digital
bank. Boost as a company was owned by
a telco. So a lot of cultural
differences, a lot of differences in the way that
companies operate. When you work in companies that
are regulated, there's a lot of different things, things that I
would consider normal, like moving really quickly and
deploying frequently, really panic to things.
So, you know, you really had to adapt and think about that, but
differently. So we were considering moving
back to Australia at that point. And then just quite
accidentally, I came across mine Valley, the team that I met
there honestly did the most amazing job of convincing me to
come work with them. Like I got a sense very early
on, this is an awesome team and I'm going to have a lot of fun
working with these people. So that allowed me to transition
from Boost into to Mindvalley and and yeah, I've been there
for the past two years. So, you know, it's, it's kind of
been a bit of a journey. Do you need to scale your
engineering team or find specialized talent quickly?
Finding good and experienced developers is hard, even for
seasoned engineering leaders, and I've been there myself.
The usual hiring cycles can take months, while critical features
sit in the backlog waiting to be implemented.
Here's an alternative for you. Check out lemon dot IO.
Lemon dot IO is the go to platform for hiring top tier
developers from Europe and Latin America.
They can match you with experienced developers in just
48 hours or less, offering a fast, reliable and efficient
hiring process. Lemon dot IO vets all their
engineers through a rigorous process that involves 100% human
check on every stage and that's why only 1.2% of all candidates
are on boarded and listed on the platform.
And here's the interesting part, you work with Lemon dot IO on a
monthly basis with no pressure to commit for long term
contracts. So go to lemon dot IO to find
your experienced developers. Now you can search by role or by
skill and they will find a match for you from within their
thousands of vetted developers. And you can get 15% off for the
first four weeks of work by mentioning techni journal when
you reach out to them. So stop burning money.
Hire developers smarter with lemon dot IO.
Thank you for sharing such a comprehensive journey, right?
Sorry that that was the the tightest way you could explain
it. A lot's happening, and a lot.
Of turning points that I think we can cover in the episode,
right? Because we were talking about
what we could talk about and transformation as a leader,
right? I think it's really critical,
right? Just also like Mindvalley
transformation, personal growth is something that everyone, if
they want to aspire to be an engineering leader or whatever
leaders, right? It's something that they have to
go through. From what you shared earlier, I
think there are three key kind of like transformation that you
went through, right? The first is, you know, like
from university, you went into, you know, software programmer,
right? It's software engineer for the
long time, maybe like 15-16 years, you said.
And then afterwards you change into like managing people.
This is like quite common in many engineering managers,
software engineers who turn into leaders or managers, right?
And then after that, you stop working just for, you know,
managing people, but you also work as part of the executive
team, getting to know how the business is run and all that.
So maybe let's go through this important turning points because
I'm sure many people can relate to that experience because if
they want to aspire to become leaders, this is the thing that
they have to go through. Sure, let's start from the
transformation from a software engineer, just pure IC software
engineer into managers. What do you think are the key
traits or key things that make you success back then?
Yeah. I mean, you know, I can think
about my own journey in that space.
I can think about the journey that I see people going through
whenever they're making that transition.
And I'm not going to lie, it's it's a tough one.
Like you, you literally almost have to like just park
everything, you know, at the door and realize it's now just a
fundamentally different job. And I think that I certainly
struggled with this and a lot of people struggled.
I see struggling with this as well as when you're in IC, all
yourself identity, all the value that you think you contribute is
all about what comes out of my fingers and what what I can code
and produce. But when you move into these
roles, there's a fundamental shift where your value isn't
that anymore. Your value is how do you create
and run high performing teams. And it's a really difficult
transition because you've just got your comfort area.
You know, when you feel like it's going well, that's great.
When you feel like it's not going well, you have a tendency
to lean back into the things that you do feel comfortable
doing. And also when you're working in
a leadership role, like when you're programming, it's very
simple. I do this, that happens like
it's very, you know, it's very easy.
You see, I do one thing, something else happens.
But when you're working with humans, it's different.
Like you do things, you're like, and then something happens.
You're like, all right, how much of that was because I said
something or did something or how much of that would have just
happened anyway? You know, so you do have to in a
sense kind of become comfortable being uncomfortable.
You know, you have to sort of be OK with the fact that you might
be getting it really good one day and not landing it
particularly well the next. And as long as you are just
thinking about how am I continually improving, how am I
reflecting? You know, as long as you're
being aware of where you are, that will help you transition
through that period. But yeah, it is a really hard
transition because fundamentally, even though you
still have all your technical knowledge, your ability to do
that, your role has fundamentally changed.
Yeah. And you also shared in the
beginning, right, that you actually had to learn a lot of
psychology related books, right, and had to catch up how to deal
with people. Maybe tell us this experience,
right? Or do you think everyone here
should also learn, you know, about psychology, about
management books and things like that?
Yeah. I mean, look at.
So I don't think it's something you have to do, but certainly it
was very beneficial for me. So I was very lucky when I took
my first management job, the guy that I was working for at the
time was just like he read so much books and he would just
leave books in my desk and I read that, you know, I think
you'd find it interesting. And I think the first one he
left for me was kind of I Feeling Lucky by Douglas
Edwards. And he was employee number 5 at
Google or something like that. And like up until that point,
you know, my reading consisted of like Red Dwarf, he took his
guide to the Galaxy, like just things like that.
So, you know, this is the first time I ever read a book that was
kind of like a biography of somebody in a Silicon Valley
company. And it was just fascinating.
So I read that and said, OK, what else can I get?
And I kind of got onto this train of, I can't even remember
how I got to it, But there was a book called Happiness Hypothesis
by a guy called Jonathan Haidt. That was really an interesting
book because it was, you know, fundamentally about happiness,
but it was all about thinking styles and thinking preferences.
And I remember at the time reading about it and then just a
light bulb going off in my head. You know, he was talking about
conservative versus liberal, for example.
Like, you know, people that are highly conservative tend to have
these behavioral patterns. People that are liberal tend to
have these. And I remember thinking at the
time, oh, jeez, that I can apply that here.
There's conservative developers and there's liberal developers.
You know, the conservative developers are the ones that are
like, Nope, we're doing it this way.
This has always worked. We're just going to stick to
what we know, whereas the liberal, the liberal ones are
the ones like, no, we're going to change.
We're going to use a new framework every single day.
And once I kind of got that concept in my head, I was like,
OK, now that I know that these personality types exist, what
does that mean for how you choose to compose teams?
If you have a team that's overly liberal, you're going to have a
lot of innovation, but you're also going to have a lot of
chaos. And if you have teams that are
overly conservative, you're probably going to have a lot of
predictability and stability, but they're probably never going
to really change or move. So, you know, it was just
through reading stuff like that. And I think one part is reading
it. The second part is actually
contextualizing it to the environment that you're in.
So, you know, you can read a book on general psychology or
you can read a book, say, for instance, Dan Pink's Drive, an
excellent book as well. You can read them.
The important part is actually reflecting on what does that
mean for the environment you're in and the people that you're
working with. And yeah, I mean, to answer your
question, yes, I would wholeheartedly recommend that.
I think that, you know, reading will give you such an advantage
in terms of what you can learn, how you think about things.
So yeah, it's about understanding the area you're
in, the domain, and just trying to consume as much knowledge as
you can and contextualizing it to the environment you're in.
I did see people that read a lot but struggled with the second
part. You know, they would read a book
and they'd be like, oh, yeah, that's interesting, but So what?
And you know, they just didn't do that second part of, well,
take everything you just read from that and then think about
how that would apply to the environment you're in and what,
what would you think about in those aspects.
So that's as important as consuming the material as well.
Yeah, that's a very good point actually.
I think many people read books. I personally also read a lot of
books that sometimes we forget a lot less well after after
reading it. So I think applying it,
contextualizing it, reflecting to where you are at the moment
is something that is key when you read anything, right.
So the other thing about programmers like you mentioned,
right, typically it's very important that they know what
they do and the results straight away.
You can see this kind of like a feedback loop when working with
human. Definitely this is something
that is more ambiguous. So what do you think?
Like for a developer, if they want to become a successful
manager, what things they should maybe let go or maybe forget
what work in the past right and try to become a better manager?
Yeah, that's a great question. I think a challenge I see a lot
of the time. So as a manager, I find like a
huge part of your job is helping distill and guide people, you
know, So developers generally tend to want absolutes, you
know, they want clear requirements.
They want to know exactly when this needs to be done by like
they, they, they want certainty a lot of the time.
And the reality is you, you a lot of the time you just can't
give certainty. You know, things just aren't
concrete. So as a manager, you're kind of
taking ambiguous and trying to translate that into as much
certainty as you can. I was an engineer in thinking
about, you know, a career path that involved leading and, and
looking after large groups of people.
It is really kind of letting go of of the need for certainty.
You know, it's getting comfortable with ambiguity.
It's getting comfortable with the fact that maybe everyone
above and around you haven't got everything ironed out and know
everything. You know, you might see this
amazing CEO who talks brilliantly all the time, but I
guarantee you that person has not got every IO of the strategy
ironed out. There's a huge chunk of stuff
that they don't know. So when you move into these
roles, you just have to be comfortable with that.
You have to accept that. And you have to realize that
your job is to kind of catch that and process it and
translate it as best you can to keep the people that you're
working with as comfortable as possible, knowing that they
really like certainty and they really like clarity.
I like that, you know, transforming the ambiguity into
more certainty. Yeah.
I think that's a really important job for the leader.
Absolutely, Yeah. The other thing you mentioned is
here, you think that managers but first responsibility is to
build high performing teams, right.
So what do you think are critical when building a team,
right? How can we assemble a more high
performing team and where? Where are the areas that we
should look at as a manager? Yeah.
I mean, look, one of the things I probably see going most
commonly wrong is people often look at what they've got and
work out how to get the best out of what they've got.
Yeah, like, I've got a team of five people and they don't do
this. How do I make them the highest
performing version of that? But really, I think the people
that really do well are the ones that can kind of almost
compartmentalize that and put that to one side, say, OK,
that's what I've got. Like, you know, that's fine.
That is one variable. But in order to achieve the
outcome that I want, this is exactly what I need.
And it's almost like sitting doing an exercise of a mental
exercise of what's the architecture of the perfect team
for me. If I just had a blank piece of
paper, how would I design the perfect team?
Once you've got that model ironed out in your head, it is
then a case of, OK, back to the group that I've got.
How do I transition that group to that model?
Yeah. The people that do really well,
the people that I think, you know, whether they explicitly
say they're doing that or not, like that's what they're doing.
The people that struggle a little bit are the ones that are
like, kind of looking at what they've got and they're like,
OK, how do I make this incrementally better?
How do I nudge this, tweak that move that they can, they will
improve it, they will make things better.
But the ones that do a great job are the ones that sit down and
think about the architecture to start with.
Wow. I think I really love that as
well. So creating kind of like the
architecture of the teams that you want, right?
And transitioning people there, right?
Because I think, yeah, sometimes we are lucky.
We are given, you know, smart people who have worked maybe
really well together. But sometimes you have to
assemble a team which probably, you know, the morale probably
slow because of the transformation and things like
that. And we have to, you know, nudge
them into a better place. Sometimes it's hard, especially
if the people don't have the skills.
But I think knowing the architecture, the blueprint,
what you want, the outcomes and transitioning people there is
really important. Sorry, I was gonna add to that.
Obviously, that's the first part.
The second part is then really understanding your team.
Where are their strengths, where are their areas of development
and how do you align that to the architecture you've designed?
An example I've been using quite a bit recently is I think about
high performing team. Like I'm a huge football fan, so
I think about the Real Madrid team that won like consecutive
Champions Leagues year on year and you can look at the teams
sheet for that. You can see that Ronaldo is here
and all the other players are wherever they are.
And then the example I saw I showed people is like, OK, take
that exact same team and just jumble all the players around,
put Ronaldo in goals. But these players here, do you
still think that team's winning consecutive Champions Leagues if
you played them like this? Like that's really understanding
the relevant strengths and and development areas of the team
you've got, making sure it's assembled the architecture that
makes sense. Yeah.
So I think the other key point to that is hiring, right?
So let's say you want to assemble a team, you probably
feel there are some skills lacking or you just need to grow
the team, right? So that means you need to hire.
You also have a lot of experience here and especially
you work at sick before which a core job is actually to find
people and candidates. So tell us about the off hiring
philosophy, right? How do you think we can make
hiring much better? Yeah, I mean, that's a really
good question because everywhere I go, every company I joined the
Volve of their, their different views of how they do hiring.
And one common thing I find amongst most companies I work
with is you join and they're like, oh, hiring's really hard.
We just can't find the talent that we need.
We've been aggressively hiring for months.
We're only getting like 1 developer a month or something
like that. And it's like, OK, and you know,
in Australia with Seek, we had that challenge when I moved over
to Asia, one of the first things there was said like you just
won't find enough talent in the market.
We just cannot get enough developers.
But what I've always found quite interesting is when you join a
company and you sit back and critically assess how they're
hiring and remember the, the, the outcome you're trying to
achieve here is get good functional people performing in
a role into the business. And you look at how they're
doing that you think the process you're following, the things
that you're doing aren't going to get that outcome.
Like more often than not, people's hiring practices are
usually designed to prove that people aren't good enough.
It's kind of like that's the first sort of line.
You know, this person is good enough.
This would be the problem. So you know, what I often do
when I'm working with teams that are hiring is like try and
rewire that a little bit. Like let's just, OK, let's just
make some base assumptions here. And most people we're probably
talking to are probably going to be pretty confident.
They're probably going to be good.
They're going to have skills, they're going to have
experience. How do we get the best at these
people? How do we create an an interview
process that allows them to demonstrate the best possible
version of themselves rather than one that puts them into a
state of fear or panic and shuts down the critical thinking parts
of their brain? You know, if you pull somebody
in an interview and hand them a pen in a white board and say
design A fault tolerant, distribute whatever, you know,
unless that person is very experienced and very comfortable
doing that, most people are going to saw us get they're
flustered. So, you know, when we look at
how we hire and certainly the companies I work with now, we
try and work out a couple of things.
We work out well. Let's just first of all go with
the base assumption that most people that are applying for
this process are capable of doing the job.
Let's work out what areas we believe that they would excel at
without any intervention or without any support day one.
They would be really good at these things.
And then let's work out the areas that they would need
support and development and what that support and development
would look like if they joined. And then let's make sure that
we've got the capability to provide that.
And if you kind of just shift that around a little bit where
you, your base assumption is most people we talk to are
actually good enough to join the company.
Most people have enough skill to be contributing on day one.
We probably need to set up support structures that do
ABC123. Then you find that the pool
opens up dramatically. And it can be something as
simple as, you know, you just create a boot camp.
Like when people join the company, they just go in a four
week boot camp and like they learn all your tooling, learn
the languages, learn the processes, you'll rapidly get
them up to, you know, it means they don't necessarily have to
have that experience on day one, but they can get up to speed
within 4 weeks. And I think when we kind of
adopted some of these principles in Seek Asia, when I joined,
when I joined, they were hiring like 1 developer a month and I
think at the peak we got that up to like 19.
So you know, you really can open up the pool, find great talent
and if you set it up correctly, these people are genuinely
awesome. Like there is no talent
shortage. It's just more of a the way that
we're looking at it artificially creates a lens.
There is a town charge. So that's the perspective I take
on hiring. Yeah, I mean tricked by the
point that you mentioned, right? Many people when they do
interviews, they try to prove the candidate who is applying
not good enough. Yep.
So how can we switch this? Because now that you've said it
right, I think, yeah, maybe in practice in engineering
especially, right? So we try to prove the engineers
who are applying, they are not good enough maybe in terms of
algorithm, in terms of whatever knowledge, experience that they
didn't have before. So how do you think a better way
of interviewing engineers in terms of getting people the best
out of them? Yeah, I mean, So what I always
push for, there's a few things you can do.
Like we did one an exercise that was really interesting where we
got like, say 5 or 6 engineers and we gave them a pile of
resumes each. And we said, right, there's a
yes pal and a no pal I like, and you have to put resumes in a yes
pal and a no pal. And we got all six engineers
give them the same resumes and they did their sorting.
But then when you looked at the end, they all disagreed.
Like some were saying yes and some were saying no.
And it's like, well, put them together.
Why did you say yes? Why did you say no?
And then they were like, oh, well, I interpreted it this way.
Oh, no, I interpreted it this way.
It almost got to the point like they're all yes, like they're
all these resumes are yes, because, you know, somebody
agrees that this person is worth looking at.
So we kind of de emphasized that part.
You know, we basically looked at if they got some key things in
the resume, that's fine. Like we'll take them in and
we'll look at them closer. And then for the actual
interview process itself, I mean, I remember back when I was
an engineer, it would be things like, tell me, how does this
work in the Entity Framework? You know, you get all these
really weird questions like that.
What we've shifted to now is what I push for is how do you
simulate an actual working environment?
Like how do you give them a challenge to work on that best
represents how they would actually work for the
organization? So what I like to do is create
challenges where basically we can have a coding challenge.
You can go pull it down from GitHub and it will be something
like, here's a independently deployable something.
It's got one really bad bug in it.
It's got one kind of really shoddy feature in it.
So fix those two things and find some way to improve it.
Like what would you do to fix this code?
So they'll do that on their own. And then the follow up part of
that is come in and do a pair programming exercise and
actually sit down with an engineer and go through it
together and work on it. And like, what would we do?
What would we change? And I find that that's much more
valuable because the the engineers are actually getting a
sense of, you know, the interviewees getting a sense of
what it's like to work in our company.
And our engineers are getting a sense of what it's like to work
with this individual. And that's way more valuable.
Like I'm not grilling them on their ability to regurgitate
knowledge in a certain framework or language.
I'm actually sitting down and like, would I work with this
person? Like, do I enjoy working?
Do I enjoy the way that they think?
Do I enjoy the way they solve problems?
Do they think about things in a way that's helpful and useful
and contribute to the team? And I think that's just a far
more effective way of finding people and also lets people show
their best self. Yeah.
So I think it's worth for everyone to give a try, right.
So simulating what you have in your working.
Environment, yeah. I mean, the pushback you'll get
from people is it's time consuming, you know, like we
gotta do all these pairing exercise, you know?
Yeah, but you're investing in people that are going to join
your company potentially for the next four or five years.
So, you know, give them that time so they can understand you
and you can understand them. Sure, you might come across a
bunch of people that aren't a good match, but that's good.
Like you've worked that out, you've spent an hour doing that
rather than, you know, the next two years working that out.
So it is more of an upfront investment, but long term I
think it yields much better results.
Yeah, so I think that's a really good point, right?
Because sometimes we don't want to interview too many people
simply because we don't want to waste time.
But actually, when we hired wrongly, the time that it takes
to kind of like bring the guy to the correct path is something
that is more time consuming. I.
Say it doesn't matter whether you're a programmer, you work in
finance, like the highest value activity you can do for any
organization is the people that you bring into that
organization. So, you know, invest the time,
like if you don't invest time in that, the cost of getting that
wrong is just ridiculously high. You know, that is something I
would also talk to anyone who's transitioning from individual
contributor to manager. Get good and really start caring
about that. Like really start caring about
interviewing and bringing people into the organization.
It's one of the highest value things you can do.
Right. So the other transition point
that you have is moving from management into something more
like executive role, something that you are currently doing,
right. So that's where you are exposed
to the business, right? How the things work, how the
sales work. So tell us about this inflection
point and how can someone, maybe they have become a good manager,
they want to become a better executive?
Yeah, I mean, look, if the, the transition from individual
contributor to managers is a challenging 1 like manager to
exec is brutal. It is, you know, you, you, you
move from a world where you're reasonably familiar when you go
from engineer to engineering manager.
I mean, at least the domain is the same.
You know, you're all still talking the same language.
You're talking about similar sort of concepts and constructs.
When you move into the executive world, it like you can find for
the first longest time, it's like everyone's talking an alien
language. I remember joining and I had no
experience in marketing whatsoever.
So when people start firing things that you like Truro ass
and LTV and CAC and like what it is like, what are they talking
about? So you know, there is a really
challenging period like when you you migrate from one the other,
the hardest version of that is just when you're thrown into it.
You know, you literally move from you might be head of
engineering or an engineering director and then you know, you
become an exec and you just throw it in the deep end synchro
swim. It's up to you.
A better version of that is when a company is very supportive and
recognizes that you're not an exec.
You know, you are transitioning in this role and you can get
assistance and support and coaching.
You get dedicated time with the other execs to sit down and
learn their domains and understand what they need from
you and how you can help them and vice versa.
But yeah, I mean, it's a huge transition.
Like you have to, again, leave behind everything that, you
know, your job is now. Well, actually, you still have
to do that part. You still have to look after a
large group of people. But now there's a whole new set
of value that you have to understand and how do you
contribute and assist the team that you're in and how do you to
make sure the technology is aligned to the business
direction and the business strategy and, and align all that
up. And yeah, I, I, I don't think
there's any, it's just a tough transition.
I don't think there's any shortcuts.
There's no cheat codes. If you can, I would always
advocate if that isn't part of your career ambition, I would
always find ACTO that's willing to work with you and shadow that
person for as long as you can kind of go the, the Jedi pad
one, right? That's probably a way to do it a
little bit easier. But yeah, it's it's a tough
transition any way you look at it.
And you have to care fundamentally about different
things. And you move into a position
where previously your manager, like if I was a head of or a an
engineering manager of a group of people, the person I'm
reporting to is most likely technical, like will be the CTO.
So we talk a similarish language, you know, they
understand me. When you move from into the CTO
position or whoever the leadership and you're reporting
to either ACEO or ACEO, you talk fundamentally like unless you
luck out and that person really understands tech, then you're
talking a completely different language and you have to adapt
to them very rapidly. You have to understand how they
see the world, how they interpret things, how they like
to think about things. I've worked with CEOs that, for
example, didn't necessarily really understand product,
didn't understand what the product role was at all and
assumed that was me, you know, so I, I'd get phone calls and
like, you know, why does our app not work?
It does not have Bahasa as a default language choice.
I don't know. You have to talk to the product
team like that, that they make decisions around that.
So, but you know, on reflection afterwards, like, oh, right.
He thought that was my job to, to set that direction.
So there's an adaptation period, there's a learning period, but
it is challenging, I'm not going to lie.
Yeah, something that I find many engineers probably struggling a
lot is about that, you know, transition from tech engineering
thing to the different domain. It could be how the business
works, right, where they get revenue, where is their focus.
And especially if you talk to different departments, then you
need to start knowing about their domains as well.
So I think this is probably one of the big challenge that I
find. What will be your tips, you
know, like in the spirit of letting go what you know?
Yeah, from the manager engineering aspect, letting go
some aspect to become, I'm a better executive.
What will be those things do you think?
Well, I mean, probably the thing I'd probably touch on 1st
actually is what you mentioned there about just engineers.
And from my perspective, if I reflect back now on what I did
and didn't do and the things that I would do differently,
there is actually nothing really stopping engineers learning more
about this stuff in their role as an engineer.
You know, there's nothing stopping you being curious.
You maybe don't necessarily need to reach out to the CMO to learn
about marketing, but you can reach out to somebody that's
sort of a peer level in marketing.
And how do I understand more? What can you tell me about
what's going on in the environment and you're always
hearing about engineers need to understand customer more.
They need to be more connected to customer.
And I like completely agree. And I'm aligned with that.
But I also think that there's a lot more to it and that
engineers also have to understand how the company
works, where the money comes in, where the money goes, how it
works. Look, you will, you'll have
access to a certain amount of information, more so than
others. But there's really nothing
stopping you being curious and trying to learn as much as you
can and understand as much as you can.
And if you're an environment that's really good at sharing
that information, that that's a great environment to be in and
that will help you grow and develop and be a more rounded
engineer, which should make these transitions easier as you
as you go through the organization.
But to answer your question in terms of what do you have to let
go, I think when you move into the exact position, similar
principles apply, it's just at a different level.
So one of the things I heavily rely on is the fact that my
technology leadership team are great.
Like, you know, and I was very lucky.
Like I keep telling people when I joined mine Valley, I kind of
won the the lottery in terms of the team that I inherited.
But you know, if you've got a good technology leadership team
structure and you've got clarity around what you're trying to
achieve as a business and you can convey that clarity to them
that you can actually let go of a lot.
There's areas that you know I would be comfortable working in,
like say for instance, product engineering.
I love that space. I'd be very, if I allowed
myself, I'd slip back into having opinions and getting
involved in that space. But I've also got a really great
leader that looks after that space.
So I just have to, they've got that.
I don't need to get involved. I'm here for them if they need
me for anything. I can share my views and
opinions, but you do kind of have to know that you've got,
again, the right architecture of the team that you're looking
after. You've got good people that have
the skills required or they're on the development path of
gaining those skills. You need that confidence so that
you can turn your attention to the other team that you're a
part of to say, OK, well, what am I doing with this team?
You know, I've got an executive team.
They know where they're going as a business.
They understand strategically what's important.
I need to help them understand how technology's a critical
component of that, what that's going to involve in terms of
investment and what sort of time frames we're looking at.
So you know, you've kind of got your eye in two different
worlds. You're kind of like making sure
that that one's working and everyone's getting what they
need in that space. And then you've got your second
eye on this world, making sure everything's functioning as it
should. But you have to be confident
that that team can handle that in your absence.
And maybe the biggest test of that is you go away in a two
week holiday and like there's no major dramas.
You know, nobody's like panicking or you don't come back
to anything being on fire, I guess.
Yeah. So I think that's a very key
point, right? So knowing how to delegate well
to the team that you have built, especially if you have built
A-Team, right. But if you haven't built A-Team
and you're just kind of like parachuted in, I think that's a
different challenge all together.
So speaking about maybe Mindvalley, right, So I know
that it's an Edu tech, it's a personal transformation company
and it's quite rare in terms of culture and things like that.
First of all, maybe my question is how big is the, you know, the
theme of the company, personal growth and transformation?
How does that actually impact the way engineering and
leadership are done in the company?
Yeah. I mean, look, that's a really
interesting experience coming into Mindvalley, because one
thing I hadn't really thought about or factored and the the
company is all about personal growth and transformation and
like, you know, moving forward and making things better.
And what I hadn't really realized until I was maybe about
a month or two into the job is that when you have a company
that is built around that, it pre configures everyone to be
very open to change and moving forward and transforming.
So I was able to work with the the leadership team at
Mindvalley and probably get more changes done in the first six
months than I was able to do in two or three years of previous
companies. Whereas previously it might have
been like, OK, we're trying to do this as a business.
I think it's going to require these types of changes.
This is a bit different and, you know, it might be a bit
unfamiliar. Other organizations, people
like, oh, well, you know, you get a bunch of people like,
yeah, that's great. A bunch of people, like, I don't
know, we'll see how it goes. And another bunch of people
like, that'll never work. We've tried it before.
You know, in Mindvalley, almost everyone was on the side of
like, yeah, let's do it. They were just really excited
and proactive. I mean, obviously still one or
two people that that, that weren't aligned.
But I just find that's in the DNA of the company.
Like it's just they're all about learning.
They're all about moving, they're all about transforming.
They're always about being on the cutting edge as a
technologist or working with a technology team you couldn't
actually ask for culturally, you can ask for anything better in
that sense. So if anything, sometimes I have
to be the one that's like, slow down, slow down, you know, we
can't make that change just quite yet.
And I'm not used to being the one that has to say those
things. So how that translates to
Mindvalley? A group of really positive,
really helpful, engaging individuals, an absolute
pleasure to work with whenever we're thinking about doing
something new and interesting. You know, we're in the
continuous AI hype cycle at the moment.
There's always a new thing, new thing, new thing or that that
could be interesting for us. There's an engineer.
Oh yeah, I've already done a demo of that.
Would you like to see it as like, all right, the next thing
you know, we've got that almost in production.
So it is an exciting environment.
It's fast-paced, it is very progressive.
And yeah, I think that a lot of that comes from just the type of
product it is and the type of mindset that that attracts.
And yeah, it's fantastic to work with.
Right. And something that I know that
Mind Valley does pretty uniquely as well as they have people from
all around the world. Together.
Yeah. Yeah, we do.
Company, right? So we're talking about diversity
here. How do you think diversity play
a big part in the success of the team and the company so far?
Again, I mean, that is something that as a leader I was aware of.
You know, you always hear diversity is important and you
know, you understand that group thinks of that thing.
You want to get as many perspectives as possible.
But I'd honestly never experienced like such a wide
group until I joined Mindvalley. Like literally we circle the
globe. I remember when I joined, like I
have engineers in Brazil, like, how does that work?
And you know, there's just, there's so many different
personalities, lived experiences, backgrounds.
And really what that does is I really value thinking about
things like, you know, critical thinking.
If you have a solution, if you have a problem in front of you
and you have a solution, then my expectation is you tear apart
your own solution and you tell me why that will work three
different ways and then how you're going to deal with that.
And you know that that can be quite challenging when you've
got a small group of people with similar backgrounds, similar
perspectives, they tend to align quite quickly.
They tend to come up with similarities, similar
approaches, problems occur and they have similar solutions to
solving those problems. But when you have this like,
wide group that have just got different lived experiences, you
know, you're talking different ways of schooling, different
ways of family, different ways of what's going on in the
government, just all these different perspectives, What you
find is you just got this like, crazy array of thinking around
how I might address this problem.
And yeah, I mean, that's superb. Like Mindvalley literally has
people, whether it's an engineering or the leadership
team. And my executive team literally
runs from Malaysia. I think I'm the furthest.
I think I'm the furthest east all the way back to San
Francisco, and there's just all these points along the way.
So yeah, just that's been the first time I've really
experienced, you know, what real diversity means.
Like really, you know, you're looking at a global level and
not just through the lens of do we have a balance of male or
females? Do we have a balance of this?
And the other is really the full scape.
So maybe something that you have learned as well in Mindvalleys
like the other aspect, you know, like the consciousness, you
know, mindfulness and things like that.
So how do you think those things play a part into maybe like we,
we just come to the personal growth rather than engineering
related. So how do you think those things
play a part in our life and do you think we all should invest
more time in doing that? So things that are ways that
I've changed since joining mine Valley.
Look, I I would have always said prior to pray down the middle,
evidence LED show me the data. That way of thinking.
What Mindvalley has done for me is it's kind of opened up the
lens a little bit in terms of, well, yeah, you can look at
things that way. There's nothing wrong with
looking at things that way. But there are other ways of
looking at things that are helpful to people.
You know, not everyone thinks the same way you do.
Not everyone appreciates the same things that you do.
And something that may not resonate with me, that's fine.
Like, you know, as long as I'm happy and I'm getting what I
need from the things that are valuable to me, we shouldn't
discount or disclude the things that do resonate with other
people. And we should be open to looking
at them and sort of like trying to understand why it it does
things for people. And a thing that I didn't do
before that I do now. Like, you know, we've definitely
been on the Wii side for me. But like, you know, just a
simple thing like meditation. And arguably meditation is
becoming much more mainstream. You know, there is now much more
research behind it in terms of the benefits.
But you know, when you're in an environment where that's like
highly normalized, like mindfulness and well-being is
highly normalized and you maybe don't feel like an idiot sitting
in your office closing your eyes for like 10 minutes just to you
know, that you don't feel done doing that.
You know, that's fine. What that sort of stuff is done
for me is like, it's actually the best way I could describe it
is it's given me a 2 second gap between when I receive
information and how I respond to that information.
So whereas before, you know, early in my life, fiery
Scotsman, you say something I don't like you got to answer
just through practicing meditation.
I feel like I've just got a little bit of muscle in the
middle of my brain that when I receive information, I can take
a pause and go, huh, all right, I know I choose to.
How am I going to choose to process that?
Is that going to annoy me? Is that relevant or not?
And that was through meditation practice that probably wouldn't
have wouldn't really have thought about doing if I hadn't
been in Mind Valley. So, you know, that has
definitely been highly beneficial.
I think there is also a lot of other practices around things
that whether it's around how you declutter your life or how you
basically eliminate stress or how you improve sleep.
Like all these things, ordinarily, previously I would
just like whatever I'd like, you know, I'll get to that later one
point, but through Mindvalley being a part of that
environment, you take more time. And you know, personally for me,
I feel like I'm more relaxed. I feel like I'm more calm.
I definitely sleep better. I feel like I can be a better
leader to the people that I work with.
I can be more measured, I can be more supportive.
Whereas previously I would have just been go, go, go, go, go.
Like, you know, we've got to get results as quickly as possible.
So. And that's what my values
changed for me really. Right.
So I think we have covered quite a lot, right.
So maybe the last question here is what are the things you want
to also share from your experience, right, or maybe from
working in a fast progressive company like Mind fairly does in
terms of how we can do engineering much better?
Yeah, look, I think the part that I think about when I think
about Mindvalley, in that context, what I've learned is
you, you have to make space for thinking.
As humans, we do our worst work when we're panicked, stressed or
in fear. Yeah.
And in software environments with, like, crushing deadlines,
overbearing bosses, it is often easy to be in a state of panic.
I need to get this out. I need to get this done.
But the part you have to remember is that when you're in
that state, you're in a state of fire or flight, and you, the key
parts of your brain that are important for critical thinking
are shutting down. So you're making poorer
decisions when you're in that state.
So what this has really helped me understand is that as a
leader, you need to create an environment where people aren't,
aren't working in a state of stress or fear or panic.
You have to create an environment where they've got
the space to understand, they've got the space to critically
digest and, and decompose and look at things from different
angles. You have to create a space for
them to think about that and try things and make mistakes.
And that's how you're going to get the best out of the group of
people that you've got if you just simply look at them as, you
know, robots that produce code and like the more you give them,
the more they get done. It's kind of like a false target
if you like. So that's really, I feel like
that's something that was evolving in my thinking over
time. And then like moving to Mind
Valley just really solidified that.
It kind of just gave me the opportunity to say, no, this
actually, this is super important.
Like this is really helpful for me.
And I think that I'm seeing evidence of this happening for
the teams here. So I think that's a critically
important thing that I would always think about now,
regardless of where I am. Thanks for additional plug
there. So I think you're creating the
culture, right, making sure psychological safety is in place
for people, right? So not always in the pressure
and you know, deadlines, fears and all that.
So I think thanks for sharing that.
So Norman, it's been a pleasure conversation.
I have one last question that I would like to ask you, which I
asked to all of my guests, which I call the tree technical
leadership wisdom. So if you can think of this just
like an advice that you want to give to the listeners, what
would that be? 3 Technical leadership wisdom, I
think, look, I think these would just be just general leadership
wisdom like, you know, applied in the context of technology for
sure. But number one for me is really
know your team and know what you need to achieve with that team.
You know, so get to know your people as well as you can,
understand them as individuals, understand them as a collective
group, understand where they thrive and what makes them work
well and what makes them work less well.
The second part really for me is how do you make sure that
they're being fed the right information and they're being
given the right direction? I think we touched on that
earlier that, you know, there's a lot of chaos going on in the
world and a lot of ways that you can interpret it and a lot of
ways that people will interpret it.
So as long as you're doing a good job of capturing all that
noise and filtering it out and making sure they're getting the
signal, like that's a really key component for me as well.
And then the third and final part for me really that's really
important is how do you know and share that you're getting the
results, you're actually achieving the things that you're
trying to achieve in an organization.
And when you do that, make sure that people are getting
recognition and you're celebrating and you're saying, I
might feel like a lot of hard work.
Look where we were 12 months ago versus where we are now.
This is an awesome place to be. So, you know, just keep making
sure that you're investing in that side of things to make sure
that people understand that progress is being made and we
are moving significantly in the direction that we need to be in
The positive impact, that's how for the business and for the
customers. Those are kind of the three
areas that I would always make sure I've got lands on.
Awesome advice, definitely. So I think normally people would
like to continue the conversation or maybe they want
to ask you certain questions. Is there a place where they can
reach out online? Yeah, I mean, I think you can
just message me on LinkedIn. I think that's a thing.
I'm happy to share other contact details with you if you want to
share them, however you want to share them.
But I'm always happy to have a conversation.
I'm always happy to learn about, you know, that part of me never.
We're learning about new experiences and new areas and
new domains. So and I'm always happy if
there's out there in an area I can help somebody navigate, I'm
also happy to I can there as well.
All right. Thank you so much for your time
today, Norman. I really learned a lot from your
experience. Many people, I assume they would
also learn a lot as well. Thank you.
Thank you for the invite. Really, really enjoyed the
conversation. Thanks.