When you recruit an engineer on your team, you actually want to
make sure from their first day on you, give them the smoothest
entry into your company and help them and assist them in as many
ways as you can to become productive as fast as possible.
Hey everyone. My name is Henry Surya be Robin.
And you're listening to the tekhelet Juno, the show will be
bringing you the greatest technical leaders practitioners
and thought leaders in the industry to discuss about their
Journey ideas and practices that we all can learn and apply to
build a highly performing technical team and to make an
impact in your personal work. So let's dive into our Journal.
Hey everyone, welcome to the tekhelet Juno podcast.
I'm your host, Henry Surya. We are one.
It's really great to be back here again with another new
episode and thank you for spending your time with me
today, listening to this episode.
If you are new to the show, a warm welcome to all of you and
thank you for tuning in. Make sure to follow the show on
your favorite podcast app package, you know, is available
on most major podcast apps such as Spotify Apple podcast.
Just Google podcast and many more.
You can also find and follow the show on YouTube where I publish
the same audio content with extra additional playlist that
contain short clips from each episode, that I find
interesting, which you can listen to in a short amount of
time. Also check out technology on all
social media channels on LinkedIn, Twitter and Instagram,
and join a growing number of followers on each of them and
find daily contents that I post there.
And if you can help me to The post by liking and sharing them
with others. That would mean a lot to me, for
any of you longtime listeners, who would like to support me and
make contribution to the show. Please consider joining as a
patron by visiting technology. No, dot f / Patron.
Your kind support will tremendously.
Help me towards achieving the goals that I'm currently running
for the show. For today's episode.
I had an interesting conversation with Tanaka moot,
Aqua telecommute. Aqua is the VP of Earring at
names and faces and the founder of the tag leadership community
in South Africa. We started off our conversation
by discussing about the tech landscape startup scenes and
Tech communities in Africa, particularly in South Africa
where he is currently based in. Then we dive deep into
discussing about the best practices for onboarding.
New technical hires and developers into the team.
We cover the best practices ranging from technical aspects
such as tools and Knowledge. He's understanding the company's
domain knowledge and the importance of having soft skills
such as communication and collaboration.
Towards the end Tanaka also, shared with me his lifestyle
brand and movement that he has been championing called, no days
off, which has a mission to inspire people to chase their
goals and dreams consistently. Personally.
I think onboarding a new hire is one of the most important things
to get right in any team. And Company in order to
facilitate a smooth transition of the new people joining your
company and to start getting them to being productive as soon
as possible. In fact, from the new joiners
point of view, the onboarding experience can often tell a lot
about the company culture and quite likely, how enjoyable
their experience would be once they transition fully into
working at the company. So if you find something from
this episode on how to improve the onboarding experience in
your team or company, make sure that you give those best
practices a try in order to give your new joiners the best
onboarding experience ever. I hope you will enjoy this
episode and if you like it, consider helping the show by
leaving a rating review or comment on your podcast app or
social media channel, those reviews and comments are one of
the best ways to get these podcasts to reach more listeners
and hopefully they can also benefit from the contents in
this podcast. So let's get the episode started
right after our sponsor message. Are you looking for a new cool
swag package, you know. Now, offers you some swags that
Can purchase online. These works are printed on
demand based on your preference and will be delivered safely to
you all over the world where shipping is available.
Check out all the cool tracks available by visiting
technology, know that deaf / shop, and don't forget to break
yourself. Once you receive any of those
tracks. Hey everyone, welcome back to
another show of the technology. You know today.
I am so excited to meet someone from far away.
His name is Tanaka motagua. So he reached out to me through
social media. He's someone from South Africa
and has been active in the community in the technical
leadership community. And he's someone that is willing
to share his learning his knowledge and experience to all
of us here. So, I'm excited to announce the
Nakamoto Hawaii as my guest today and looking forward for
this conversation with him. So, the Maybe in the first few
minutes. Can you introduce yourself?
All of us to know more about you?
Thank you, Henry. Thanks for having me on the
podcast. Yeah, my name is Tanaka my
chakra. I am an engineering leader,
based out of Cape Town, in South Africa.
I'm originally from Zimbabwe actually, which borders, South
Africa, and I grew up there and did my primary school and high
school education. In Zimbabwe before, moving
across to South Africa, to study computer science at the
University of Cape Town. I'm and I've been living in Cape
Town for the last 12 years. So after finishing University, I
started working in the software engineering industry and I've
always lived in Cape Town. So I haven't left.
I enjoy living in the city and I love it.
Right. So Tanaka you currently working
in names and faces, right? The name itself.
Sounds interesting. So can you share with us?
What is names and faces? Yes, names and faces.
We are start up a technology startup.
Our businesses, we met Visual employee directory.
That is quick and easy to access and helps people at companies
know who's who are their organization and gain context
into what their fellow employees do and where they fit in the
organization. The ideas, its helps people get
more connected across a company by using the visual images of
their faces. So you can identify people more
easily, and we typically solve a problem for companies that are
getting a bit big, so, over a hundred to over T people,
basically, you don't know everyone when the company starts
going to that size and usually you need a tool that can help
you. If you see someone, can you
identify them in the app and see where they fit in?
Or if you recently joined the company, for example, you get
introduced a lot of new people at the company.
And the next day you come in. You can't really remember
people's names. But if you've got the names and
faces application, you can then take it out and just check out
who's who and what their names are where they fit in.
We make the application for us. Droid and iOS and we have a web
application. It's software-as-a-service
applications. So companies will pay us to have
the application running for them.
So Tonetta maybe in the beginning would you like to
share your career Journey so far?
Maybe you can mention some of the highlights that you have
towards your career and also maybe major turning points if
you have something interesting to share with us.
Yes. So as I mentioned earlier, I
studied computer science at the University of Cape Town.
So I would say one of the my first career turning points was
actually my final year at the University.
I applied for an internship, six-week internship at a company
called Alan gray, which is an investment management company.
So over our University vacation break.
I got the internship and I worked a long three other
interns and we worked with the company as software Engineers
for the company. We had to build a 360 degree
feedback tool for the employees of the company and it was my
first exposure to what I was actually, ID and what it meant
in the real world. And how real companies actually
operate in building software what it means to build a
production system, what processes, and our team's work
and everything like that. And at the end of that
internship, actually the company was happy with my performance
there and asked me to join after I finished University does great
exposure. I was happy with the company had
seen that, they had lots of good people and good practices and I
agreed to join them. So, I started as a graduate
engineer and I Grew From There into a Jew.
Junior engineer and mid-level engineer and ended up spending
four years. They thought was my Foundation
of my technology. Korea does my first exposure to
Agile development, agile, methodologies and how teams get
structured. And as I mentioned, our sort of
software gets released to production and everything.
The company had a very strong client focused.
So we really made sure. Everything we did was always of
a high quality. It was definitely a traditional
corporate structure the operator.
Thousand people at the company. It was a company that was
already doing well. So after four years, I always
had an interest in entrepreneurship and startups
and seeing how a proper tech company or take driven company
works. So I got an opportunity to join
a start-up. Then, after four years.
It was called Prodigy. Finance at that point.
There are about 20 people there. And I joined as the fourth
software engineer, and my goal, there was just to see how
companies start from being very small.
Knees and grow into big companies.
So I thought that would be a great learning as I joined Alan
gray earlier. It was really a big company, a
lot of things already in place. You're not quite sure how they
got to that place. And I thought that this new
startup I'd be able to learn about shaping or that and how we
grow into a big company. I actually got all that to that
startups experience because for years later, the company had
grown to over 200 people and had offices now in London and in New
York, and we're presence in India, to, at the time.
I left home. In that Journey at that startup
because I had been there from the early days and I had a lot
of context of how the systems were set up and how things
worked. I got an opportunity to Mentor
new Engineers as the engineering team grew and they joined.
I also was involved in setting up an internship program for new
interns that we're trying to support during their vacation,
the university vacations because I always thought that was
important when I did mine, so I thought it would help the future
students to also get that the company had some point wanted to
Do as it was growing, wanted new engineering managers.
So they opened up for people to apply to be engineering managers
because the teams were growing and we needed more engineering
managers and I applied for that role.
I got into that position and that was my first exposure to
management and take leadership at that point.
Initially. I started with five people
reporting into me and I started learning and growing.
My tech leadership skills. I always had an interest in GA
leadership and smile involvement in the internships and mentoring
people and also worth mentioning.
That the company had offered a leadership training program the
year before, and I had actually gone through that over the year,
where we had people who came and taught us, what the different
things you need to learn to prepare you to be a leader.
So, yeah, so that helped me grow and eventually I left party,
finance and moved across the names and faces, which I spoke
about a bit earlier that names and faces.
I was recruited as the VP of engineering.
So, with my role, they ensuring the engineering team or the tech
team is delivering and working. Well, we During we're delivering
software at a good speed and software of good quality my
role. They primarily focuses on four
main areas. I would say, when I always get
asked how I described it as I'm responsible for the people,
making sure they're growing their careers, and I happy at
the company and the environment, they're in allows them to
thrive. I'm responsible for the
technology teams processes. So how do we actually build and
deliver software? I'm also involved in the
technology side. What tech stack are we using?
And what risks can we Face? It all the different
Technologies and the systems we have what's our architecture?
Like I'm involved in that. I'm also involved in product.
So everyone in the company is but you're also involved as a
leader in. What's our product?
What features are we? Adding ways?
Our product going out, we sell it and everything, and I've been
at names and faces for a year and four months.
So, continuing my leadership growth and interest in small
startups, and high impact businesses, that's been going
well, and that's where I am at the moment.
So, in summary, that's Yeah, that's about my career Journey,
sort of straight out of University into a corporate way.
I got Foundation of learning, then into a small start-up That
Grew got exposed to leadership and then back to a small
start-up. But in a leadership position and
continuing on that Journey. Thanks for sharing that.
So you seem to have a very diverse experience from
corporate like big corporate and also in a start-up as well.
One thing that I personally don't know much about is the
South Africa or Africa technology landscape.
Maybe you can share a little bit How thriving in terms of the
technology adoption there or add a lot of tech startups being
built up in the Africa or how about the people skills?
Their do you think they have the sufficient capability to also
thrive in this technology industry.
Yes. Sure.
I can chat about that a bit. I think I'll start with South
Africa, then I'll briefly touch on Africa.
South Africa is obviously where I've lived for the last 12
years. So, I've got more context and
also having been working in the industry, the tech landscape and
industry has definitely grown, especially over the last 10
years. I would say, from the time, I
started working, actually. This is my 10th year working.
So now there's been a lot of startups that have been formed
and there's been growth in the tech, ecosystem, and Community
across computer science in itself at the University's is
also now a more accepted degree more.
People are going to study it, as they realize, they've never been
a better time. I think to be a technologist and
right now in the world, there is a high demand for engineers and
more than the supply that They're so people now realize
that it's also a viable job to actually be a programmer or to
be involved in the technology Community.
But in terms of startups, even a lot of startups that have been
formed in interesting areas. A lot of them were in fintech or
I in the fintech space actually people doing cardless payments.
People being involved in like where did you finance where I
work. That was order less loans for
international students studying abroad people involved in the
blockchain and the crypto space. So there's been a A lot in that
and a lot of opportunities for people to learn different things
and grow. And also we've had some
companies or startups that have had some exits or been purchased
or acquired in recent years that have also been proven that a
company can start in South Africa, in Cape Town and
actually go through the full journey of being funded and then
going through some exit of some sort.
What mentioning this is Luna. Which recently actually just
exited, which is an exchange trip to exchange for Bitcoin
mainly and there's Company called over, which was bought by
Go Daddy again very recently. And if we go on the Africa,
landscape itself, there is quite a bit of tech that's been
happening in Kenya, over the last 10 years to there's a lot
of innovation in that space around payments, Mobile payment
Technologies and a quite a number of startups.
Have also grown out of that race.
And of course Nigeria is always a big player in Africa for
anything and there's also quite a number of startups.
They that are formed more recently actually.
We a company called pay stack, which does payments is in the
payment Technologies was recently bought by stripe.
So, Africa, in itself, you wouldn't say, out of all the
countries, every one of them as a big thriving, Tech Community,
but I think South Africa Kenya and Nigeria would be the three
you would find. Most people are working for Tech
startups. OR tech companies would be
sitting, either will be working remotely for company.
That's based in one of those countries or actually move
across to those countries. Another thing worth mentioning
actually is for Uptown couple years ago, Amazon AWS actually
opened up Offices here and they did a massive recruitment Ryan
and they've got lots of Engineers.
Yeah, so they're easy to teams actually running out of Cape
Town. So it's nowhere near in scale,
like a Silicon Valley, but then there's a lot that's happening
and more and more is going to keep going because I think as we
know the technology, you all just keeps growing, there's more
opportunities. More people are connected, more
people are smart phones. The internet is also spreading
even further. Further.
So I can only see it expanding and growing.
And the last thing I'll touch on is skills.
They would want more Engineers so that we can meet the demand.
But we've got some really strong strong candidates and strong
people in South Africa. And Africa would say as a whole,
I think the very fact that Amazon could sit up here and be
able to recruit and run the ec2 teams out of ya shows that we've
got the skill levels. I think often what missed is if
people work in Silicon Valley or work at a company, a top company
in the valley, it can easily be In as though they are the most
skilled person and we miss out on very strong Engineers that
are based in Africa. And at the moment information is
the same, right? If you've got a good internet
connection, you can learn the exact same things that someone
whether in the states or anywhere else is learning, and
you can be as skilled as them. So I think the main mismatch is
actually more a case of companies that start in Africa
and then end up being global companies.
That's I think the more difficult battle we have from an
African Forest. - because our context is very different and
it's going to be difficult. So it's going to take time to
find a lot of startups. I start in Africa, and then they
expand and they are well known in the world like a Facebook
that comes out of an Africa or something like that.
But in terms of skill, I think we're on par.
So it's very interesting and sounds like pretty cool.
So Africa or South Africa itself is growing in terms of this Tech
adoptions and also the startups couple of times that a lot of
Industries or the startups around payment or maybe banking
digital banking blockchain. And things like that, are there
any other industries that are also thriving in terms of tech
adoption from Africa? Yeah.
I think there are few people doing things in farming and
Education Health. The people go out to help in the
rural areas and those agents collecting information and
pushing it back to some Central server of some sort.
There's definitely Innovation happening day.
They just haven't been many, big exits, because some of those
usually, then I'm very closely related to social projects and I
think people push or rush to the fintech or payments and
everything because it's money related.
That's where money is. So if you can make it there,
you're easily tied to money and funding also, which is something
we haven't spoken about access to funding is nowhere near the
scale. It sat in the states, in the
valley of Silicon Valley are stories of someone, who gets
funding from a slide deck of an idea.
They have, whereas in Africa. I think it's more than you need
to have the In this actually operating The Tick already in
place on some sort and some proven track record.
Have you worked for 20 years? Have you maybe started another
company before and who's your connection?
So the amount of capital available is limited but also
even in that Capital, the due diligence is quite strong into
like, we, they are willing to find and we don't have many
Venture capitalists or seed funders that are willing to push
out money. So that makes it also a bit
tricky. For some people have ideas and
everything, but they can't exactly experiment with them.
On the scale at someone in Silicon Valley, you would in
terms of the community itself. I know you run a Meetup or
technical leadership. How about the community itself?
Are there. Lots of you know Community
meetups or maybe sharing within the community for people to
exchange knowledge and information or maybe even for
example, sharing about their company or what they are doing
and the tech stack that they're building, are there.
Lots of such things. Yes.
So those have also been growing quite a lot lately.
I'll speak a bit about some of them and they're not expanding
to. Leadership Meetup, which I know
more of since I started it and I've been involved but they are
quite a number. There is a devops meet up which
is quite popular. So the devops engineers and they
talked about like infrastructure and how to get applications to
production and how they run in production monitoring and
everything of that sort. That's quite popular and has
grown. There is a Cape Town, Front End
developers meet up. There's quite a number of agile
meetups. So it's a scram Gathering of
South Erica. So there is quite a lot
happening in the community around sharing knowledge, and
people meeting and gathering together.
So, that's definitely there. Of course, we have the tech
leadership meet up, which I started and supported by two
former colleagues Benny and Roberto who I met with just at
the start of it and say that you guys keen on going on this
journey because I think there's a gap in the Cape Town community
or at least in the South Africa community and perhaps even
Africa's. All way immutable group or
community that comes and discusses.
Technical leadership, Concepts and helps each other grow and
take leadership. So, our Meetup is for new tech,
leaders aspiring Tech leaders, and even established ones.
It's just about coming together, sharing ideas and helping each
other, learn and grow, but also building friendships, so that if
you need help in the future, you've got someone else.
You can chat to you possibly met at a meet up and our hypothesis
is that if we can help these Tech leaders, who come to join
our community grow, and become better leaders when they go
back. To their companies do help make
their companies better places to work and as a result that helped
improve companies, take companies across Africa and
would improve the industry as a whole.
So that's sort of our hypothesis and our goal and we meet once a
month. First Tuesday, of each month.
We normally have a speaker who comes and joins us and shares
some lessons on leadership and then people can ask questions
afterwards. We've had other different
formats. Also, where people perhaps bring
questions or problems. They're facing at their Any.
And then they break out into groups and discuss these topics
and issues. They are facing and help each
other. It was very much in person until
the pandemic. So now we've been doing them
online, but that has also opened up the opportunity for us to
have invited speakers from outside Africa.
So, we've had a couple of speakers one from Berlin, one
from London. And they've also share their
story with us, and it's also allowed people who are not in
Cape Town only to attend. So, I think, after the pandemic
will probably have a mix way sometimes, We do an in-person
one and sometimes we do one online as we've been doing.
Yeah, so that's where it is. And I think we'll keep growing
that Community. One of the big things I learned
as I've been going through this software engineering journey, is
that a lot of the times technical leaders are not
prepared for the role. They are pushed into the role
because maybe someone identifies that this person is really good
at coding. And they say, let's make them a
leader or a manager, but then there's a big mismatch there.
Because management skills, leadership skills are very
different from the You have as an incredible code, is a lot
that comes with the management skills about communication,
helping to facilitate meetings, managing conflict between team
members, and some people are not prepared for that.
And when they then in the road and they get frustrated and they
become a bad manager and then their whole team is not happy
and ends up leaving. And it looks like they were
never a great manager. But what's missing is that they
were never prepared for the role.
That's part of also, why we say our take leadership Meetup is
for aspiring Tech leaders. So that if people want to start
learning about it and maybe a year or two later, they venture
to get into a leadership position.
They've been exposed to a lot of different things that take
leaders do or should do. I totally agree with you.
I find it very true that technical leaders.
Most of us are thrown into the role sort of.
We have grown in the individual contributor role for quite some
time. Maybe they is as someone who has
potential to lead and yeah, just like that one day, you become a
manager or become a technical lead and that's where I think
the and preparation shows that we also need to grow at
Particular skill as well by communication facilitation
resolving conflicts and things like that.
You have been working in a big corporate and you have been
working now as a VP of Engineering, in names and faces.
So coming to the topic that you want to share with us today,
which is about onboarding new software Engineers as part of
these topic. First of all, what are some of
the things that are critical for onboarding, a new software
engineer coming to the company? Let me go back a bit and say,
let's start at why do people recruit Engineers so, So when
you recruit an engineer on your team, or you put a couple of
Engineers on your team, your goal is that once they are on
your team, there's productive as they can be as fast as possible.
So that the team starts pushing out more things and you get your
value back because you're paying this engineer for the work,
they're doing and you get your value back from them in the
output that they are producing. So, one of the key things or one
would think, one of the most important things is once you've
hired someone, and you've gone through the whole hiring
process, you don't just end day and put someone in a room and
say, yeah. Go ahead and I'll start working.
You actually want to make sure from their first day on you,
give them the smoothest entry into your company and help them
and assist them in as many ways as you can to become productive
as fast as possible. So then coming to that, what I
look at is, what makes someone a good engineer.
And in my mind, these three areas that make someone a good
engineer. One is their understanding and
capability with tools and Technologies, programming
languages and Frameworks, and all the Supporting technologies
that you use at your company. They need to be good at that and
really greater that. Then there is the domain
knowledge, which is understanding what the business
is about and how it relates. The Technologies were writing.
How does the business make money out of the business function?
And how do we sell? What's our product?
And what are we building? And then surrounding those two
is in my mind, soft skills, because software is all mostly
often about collaboration. So most people working in teams,
it's real. Yes, you have it, but it's rare
to find people what? Being in isolation, especially
if it's a big enough product or bigger company.
It's usually in teams. So, you're collaborating with
Engineers on your team, perhaps with Engineers on other teams.
Maybe they've both the API and you're doing the front end, and
you need to interact with them. He also collaborating with
people in other departments that are not technologists.
And you need to be able to communicate with them in a
non-technical way so that they can understand what you're
dealing with the tech side and then perhaps you may interact,
depending on your company, you may interact with users.
So there's so many things around soft skills and managing.
Communication and facilitating and everything that comes to
that. So, those are the three key
areas in my mind is, like tools and Technologies.
A domain knowledge, which is understanding the business and
soft skills underneath each of those three things that you can
do when your own boarding, someone that can help them learn
each of those areas and you can help them fast-track their
knowledge and gain in that area. So, if we go back to tools and
Technologies and say, how do you help an engineer?
Who's just started have context? If your tools and Technologies,
and again, if I go back to us and technology is it could be
lets say your organization uses JavaScript as its main
programming language, and you use react.
As your framework, use get your code, is an AWS in the cloud.
There's so many tools and things around that.
And when someone first joins, one of the things that's
important to do is as quickly as possible try to get them to make
real changes to the code base. And the reason behind this is
even if it's such a small changes, just changing the copy
on a page on a View or something or just changing the text.
They need to do that. They need to be able to check
out the code base onto their local machine.
So then they start to learn about your Source control.
Where does your code live? How do I get into the machine?
How do I get it running on the machine because they need to run
tests and everything on your machine.
So they need to also learn about the chest run after they finish
the writing change making that change.
Don't need to push up the code and then it gets pushed to some
build servers. So white runs our build servers,
how does the code then get from his machine or their machine to
us? Aging environment, enter
production environment. So then they also see how the
structure is of the code coming from their local machine back
up. So it exposes people to the full
flow of your code, by just asking them to make real changes
to the code base as quickly as possible.
So that's the first thing that I would encourage, and if you can
get it to happen on the first day, that is a great thing.
Some people wait a long time until they actually able to push
a change, the other practice would be pair programming.
I would encourage new Engineers to pay program with existing
Engineers that were on the team. Before this helps on multiple
aspects, with the main one being just gaining context and someone
being available to answer questions for you when you get
stuck, someone who can navigate the code base, can explain
exactly what's happening and where things are.
And then also you get to know your teammates a bit more by
programming with them. Ideally you want to pay program
with different people on the team.
So you rotate so that they get to know the rest of the team.
And also you want to rotate who's actually doing the driving
on the paper gramming. So sometimes the new person Of
them with their familiarity. Sometimes they also just
watching you drive and they learn like the different tricks
that you have in your understanding of your code base.
Also, if you have any onboarding documentation, that would be
useful for helping people on board on the tools and
Technologies. If there's any documentation,
that's written somewhere else that allows people to quickly
read and say, oh I understand that's all the build systems
work or even if it's on a guitar, but GitHub repository of
how to set up the code base and how the architecture structured
that could be useful. The important thing with
documentation as always. Is to make sure it's always up
to date because sometimes it can be more confusing if it's not
updated. And if the new person finds that
some documentation is out of date, you should encourage them
to be the ones updated. So every new person always makes
sure we are on the latest version of how we are
structured. And then the final thing on
tools and Technologies is, as a company, perhaps keep a list of
resources that people can use for learning.
So whether it's books or online courses or blog posts that are
tied to the Technologies you use, It can really be beneficial
for someone who is new to learn. Oh, I need to learn JavaScript.
What are the resources? They need to look at then you
can just point them to some list that you have and if your
company has a good training budget or a good budget, if you
can create a training budget for all your software Engineers to
allow them to purchase these books and courses from the
company's finances as opposed to their own.
It also very beneficial because it encourages them to learn a
bit more. So I would say those are the
four on the technical side making real changes to the code
base paper. Programming onboarding
documentation and some learning lists or learning resources that
are back to the training budget that comes from the company on
making real changes. I totally agree that the first
thing. If any new hire that comes to
the company is able to make a change like what you said, check
out the code understand how to run the test and setting up all
the necessary dependencies on their machines and going through
the continuous integration or continuous delivery pipe lines,
if the company has it and see all the automation up to
production at That's really really a crucial in order.
To first of all, encourage them that they actually they can make
change within such a short period of time.
And the other is, of course, you understand all the processes and
all the Hoops that are person has to go through before they
can actually make the real change pair programming.
I think it's something that is quite interesting.
Some companies do adopt pair programming, while the others do
whole request code review. Do you have a view on that?
What Makes Her programming, much more efficient, or vice versa?
I don't see it as pay programming versa.
A pull request model, of course. I mostly agree with the idea
that Swift codes been written by someone.
Someone else should perhaps have a look at it before it goes to
production through a code review process.
And maybe if people are paid programming, then you had that
person looking at it. So you can still just approve
from the other pay. One person pushes.
The other one approves what I found works really.
Well is usually the team is more than two people anyway, so even
when people pay, they still create a pull request and they
still share it. The rest of the team.
So if there's other Engineers also, with the idea of a pull
request and sharing it with everyone else.
So this context is still there. The interesting thing about pair
programming versus when we, then compared on the case of pay
programming versus workers and individual push, and then
someone else looks as it is with pay programming, these instant
feedback. So you don't have to wait for
your code for like a half a day or a day.
Then you put up a pull request, then eventually someone that's
gives you feedback and then you go back and address that
feedback and then A day later, you put up another pull request,
then maybe there's more feedback and you are almost in this.
Pass it back and forth back and forth.
Whereas the pair programming it's like we're together so I
can give you feedback immediately.
You can give me feedback I can catch any issues that I'm stuck
with or errors that I've made quite early.
And also, if you get stuck sometimes something just is
baffling and you get stuck. But someone was sitting next to
you might know the answer and instead of then having to wait
for a long time. It's immediate.
So pair programming always, encourage collaboration both, In
code together, shared ownership of the code base as a team.
I would not enforce it. I know in the extreme
programming methodology. It's enforced in a way.
Almost on everything. You have to work as a pay, our
not enforce it and mostly allow the team members to decide as
they have working on stuff. Whether should we pay on this or
should we not what tasks make sense to pay on.
But I have a hypothesis that in a high performing team pair
programming and collaboration happens at a very Very high
rate. I can't give the number the
actual percentage but I would expect it to be on the high end.
So very very high end of a lot of people grabbing a lot of
collaboration. If you find a high performing
team, those two could correlate. Yeah.
I think I totally agree with you as well.
It comes back to the instant feedback.
Right? So the feedback loop is much
shorter and that's why you can't earn more things, either faster
or you can improve Stars also, in a faster way regarding these
documentation and learning resources and training, plans
and things. I like that in a start-up.
Sometimes I think these things tends to be neglected.
Especially, you know, maybe you are few people team.
There's not many Engineers that are being hired.
So, what's the balance here that you think we should spend in
coming up with a good onboarding, documentation and
things like that? Yeah.
I think it all depends on context.
As you say in a much smaller company, quite a number of
things actually in people's heads, but also access to them
then is easier because when you join us a new engineer that
other person who's got it in the Ada, It's probably always with
you. So that list may not be
explicitly written down. But if you did ask someone who's
just, I'd say it's a team of four people only, and you just
join us. The first person and you asked
to all the other four, guys. I wish resources.
Do you recommend? They could send them to you
within 30 minutes. So then perhaps not having the
documentation in that case could be fine because you still get
access to it anyway, but I would always encourage things to be
done earlier. In any case.
You just don't know when things start sort of breaking and
falling. The longer you hold onto things
and eventually, get to a place where perhaps like how to setup
a repository is not documented but then over a six-month
period, the company really grows and now only a few people know
how to do it and it becomes a key man dependency issue.
It usually doesn't take that long for some of these things to
be documented. So if someone spends like 30
minutes to an hour, just does it stay.
And it lives the, it's better than it's in someone's head.
But I do completely understand in a very small start-up.
Is specially very early stages. Quite a lot of things live in
people's heads and get shared by just talking but once it starts
growing, I think when you start getting to like two teams and up
which is quite a lot of organizations are much bigger
with 300 400 people teams and everything.
You definitely need some structure.
They and you want to have it in place.
My total take on that is that it's okay for you if let's say
you do your first or second higher, but once you get beyond
that, I think you need to start writing down the process or the
framework that you do. Sting right.
Like, the example, hiring the third person.
You would be probably spending some time in order to come up
with the onboarding document. So that the next person, the
fourth person that comes in actually has a proper
documentation process in place, and it gets updated like what
you said. So especially if the new
joiners, see something that is probably not, so, right?
They can take that chance to update it, and make sure that
the fifth higher gets the updated documentation.
So we have covered the tools and Technologies.
The next one that you mentioned is about domain knowledge.
Can you share a little bit on? On that.
Here are so domain knowledge. Like I said, is really about
understanding. It's very important.
It's really about understanding the business and the business we
are working for. How do we make money?
What's our project? How does the company work in
general, what to other people in other departments?
Do and others are technology that we are writing relates to
all this. And it's an important thing for
an engineer to have because you can have all the understanding
of the technology, but if you don't know what you're building
for then, To always be confusing and that context always be
missing and also Engineers can also come up with very bright
ideas for the business and solving business problems.
So the more they understand what the business is the are for and
what product, it actually has the more likely you'll be able
to also get ideas coming across from Engineers.
So, with domain knowledge, one of the ways is induction
training and by induction training, I mean being able to
go and understand what all the other people in the company, do
other. Ointments in the company, do it
something that is common in bigger companies.
So when you start at a new job, you will get exposed to at some
point. What's marketing department.
Like what's the sales department like was the finance department?
Like what happens there? Who is they and everything, and
a bit about what's the product and everything that we do in
smaller companies? Like you say, when we're talking
even about the Learning Resource and onboarding documentation.
Now you can get that sort of detail again from your peers,
whether One was that your manager or project manager?
If the team meridians are project manager in the, they can
give you a full overview of the company.
So it varies where you can source that information, but I
think the important part about the domain knowledge point is
understand how the business functions understand how we make
money and what product are you putting out there and then
relate all these back to the technology that that Engineers.
Right? So that's domain knowledge.
So yeah, I do agree with you. Sometimes we We tend to see a
lot of engineers in a software company tech company or even
like business companies. They seem to have a lot of
expertise about technology. They do care about the
technology, but they don't care about the business or what the
product is being used by the users.
So I think this is one of the major challenges in the industry
because people love the tech, but not so much.
The solving the users problems. I find that the problem is not
easily solved. I think it goes back to the
individuals. So from your experience, maybe
from your Looking different companies so far.
How can you ensure someone has a motivation to actually learn
about the business? Learn about the process on how
the company makes money, or even like how the product actually
solves the users problem. Is there any tips that you see
from your experience of her? Some of the things I would
suggest is I think one of the main causes of the lack of
interest is also how companies are structured and how they have
this separation of all, those are The Tech, Guys, put them in
that corner and then we are the business, guys.
And we are doing our own thing in this space, But at the end of
the day is one company. And I think one of the things
leadership has to do right from the top, is to make sure
everyone collaborates and functions as one unit.
And there's many ways to be doing that, but ensuring that
whatever technology is working on aligns, with where the
company is trying to go in the company's goals.
So that the technical, people can see the impact of the work,
they do relating to the outcomes for the company.
If people build a new system and it brings in a certain amount of
money for the company. Penny, there's more of a passion
of understanding. How's that system, bringing that
money and what impact can it make?
Then almost just getting told to just build that system and do
that and you're not quite sure why and everything, that's the
one that's bringing up alignment in the team's close eye on
everything and what they do engineers like to solve
problems. There's also a different
approach in which one of the main causes of this problem.
Again is where problems are then given solutions by just the
business people and then they throw in a danger nears to Just
build, almost making the engineers like code monkeys, you
know, I just write whatever Solutions we've come up with.
Whereas opposite approach is this is a big problem that
company wants to solve open it up to the whole company to say,
how can we solve this together? What solutions could you
possibly have and you start getting buy-in and ideas from
different people including the engineers and the again, they
align more to the problem. So yeah, I think those are the
main things is just this, that mismatch way is like us and
them, but we should be together and if you can break that, Us
and Them attitude. And I think that starts from,
like I said, from the top, making sure that we're not
treating Engineers or another Resource Center because then
they act that way in a way. It's like, okay we just do what
you need. We like to take will build
whatever you need but we're not concerned about our everything
else works. Yeah, then I think some
companies do expose their Engineers to the users and their
users problems, so then you feel a bit of empathy in the problems
users actually facing and you want to actually Address those
and then fix them and understand the business more.
There is many different sort of strategies, but it comes to an
engineer feeling. They have a sense of ownership
in more than just the check, but where the company is going.
Yeah. I completely agree with you the
silo thing, right? Like the business versus the
people on the tech. So that's why I think the whole
movement about age are bringing business and the tech closer
together, but one thing also that could help in my opinion is
that if you align both teams in terms of the same like before,
Okay, or some performance measurement.
It should all tie back to how the company either make money or
benefits to users. It could be the number of
Revenue number of prophets number of users adopting.
The products. I think you've both teams are
being measured on the same thing.
I guess in a way that Engineers would also love to learn how
they can help to actually bring the numbers up.
So, the other problem that I normally see as well as
Engineers is that we all love the shiny new tag, but we don't
actually understand the constraints that the business
actually is. Having, for example, these days
for people adopt new technology. We can simply say.
Oh, I want to adopt that new technology while at the same
time, probably the engineers don't understand.
Okay, we have some constraints in the budget timeline or maybe
the legacies that we're working with, probably not so compatible
with the new things. So in that case, as a technical
leaders, do you think that these people have a bigger role to
play to explain to the engineers that we have these constraints?
Yeah. I completely agree as you were
talking. I just thought that's quite a
lot related to a leadership problem.
The ship needs to solve that and Technical leaders.
And I think that's really about being transparent and open with
the engineers and with everyone, actually, in the company on, we
are we financially what we actually need right now.
What does this bring to us? We don't want to stifle
Innovation by not, letting people try out new things that
could actually break through. But every decision also needs to
be made in some context, if someone wants to spend time
changing the database, and it means for two years.
We might not release any sensible new feature because the
whole database overall was big then we need to look at.
Why do you want to change the database?
And what will it give us and how does that align to business
outcomes in the end versus doing something else?
It ends up always being about prioritization and outcomes.
The business is trying to achieve, but that's way, I
guess, as Leaders as take leaders, even as company
leaders, you're supposed to be stepping in and helping to
facilitate and align and see if things go along with this.
Did you have for the company and helping people understand when
you make decisions? Perhaps that don't go with what
they were thinking at least helping them understand that
they've been heard and their input and opinions have been
heard. But this is why we've had to
make this decision for the company sake, right?
I think it's greatly put and I do like that.
So moving on to the third one, which is something that I think
as an engineer. We don't like this thing soft
skills for if possible. I think most Engineers would
like to talk to machine to people.
Right. So, yeah, what is your take on
this soft? Skill.
Why is it so important during the onboarding?
I think I mentioned earlier in that soft skills in modern-day.
It's very rare that you work alone in isolation and soft
skills are all about how you communicate and you collaborate
and you relate to other human beings and how you present your
ideas and communicate them, in a way that makes sense.
And because people are not work in teams, and if you work in a
company, you talk to different people from different
departments. You may actually interact with
you. As you definitely need the soft
skills. And as you say, it's probably
the most neglected one in the tech industry because I think
there's multiple reasons. One probably comes to the
Grassroots of we're not getting tight enough about soft skills,
even at the school level. And at a university level, if
you are doing an engineering or technical degree, and then the
second one is, I think Engineers are probably wired to
communicate with the machine more because that's how we
person instructions and everything.
But the good thing though is, I don't think it's something that
cannot be built. It is definitely something that
someone can improve in and get better at it with practice
because at the end of the day, it's really about interaction
and communicating and facilitating.
So they are a couple of tips I have on how to help people
improve. One of the first ones is
actually letting the new Engineers, when your own
boarding them. Once they've settled down, let
them lead some of the team reviews or demos of the work
that they've just done whether that's to just the team or
across the whole company, if there's a company-wide demo it.
Is them. The ownership of we built this?
I'm going to present it and explain why we built it and how
it works. And also, it gives them
visibility to the rest of the company because then maybe
people have questions later. They might actually approach
that person and talk to them about the solution they reviewed
and demoed. So it's a great free opportunity
to allow someone to build those skills by asking them to
present, pair programming, which I mentioned earlier, also
facilitates for this because if you join a company and you just
throw it into a corner and you work, By yourself again, there's
no communication and teamwork and everything collaboration.
Well as pay programming by its nature.
You're going to have to be talking to someone, so it helps
build those relationships but also helps you to communicate
and you're pairing. Body may ask you, what are you
thinking? How you think of solving the
problem and you have to communicate that back to them?
So that's also a great team, building also help.
So just getting outside of our core day-to-day working grind
and starting to just learn more about each other as individuals,
whether it's like a team dinner or lunch or an activity.
It's a given that social activity that as a team or as a
company, you go on it helps you be out of that workspace.
But then you learn more about people and then you'll probably
find it easier to communicate and collaborate with them
afterwards to close off on soft skills.
I would say you want your company to have an open
transparent psychologically safe culture, where people feel they
can speak up or make mistakes. And they all may receive
feedback, but the feedback is in a way to try to help them
improve and grow verses. Has to try discourage them or in
a malicious way. Sort of good feedback that
paying someone. So if you create an open
transparent, psychologically safe culture, you also opening
up for people, softer skills, to improve and grow at the end of
the day. We are supposed to be able to
communicate. And so the solutions with both,
we're supposed to be able to communicate and explain
technical Concepts to non-technical people as
Engineers. Those are key skills that I
believe every engineer should have and I think amongst all the
things so Skills is probably the one I would say is the highest
rate when your onboarding people and if you can get the engineers
to have great soft skills, then the other things you can almost
get together much more easily, but the soft skills are in, is
the important one. And also, if someone doesn't
have them, the wine that you have to work a bit harder to
help them build and grow. Yeah, if I can add, I mean based
on my own experience as well, right?
There are few things that can help in this soft skill as well,
which is one frequent one-on-one with the technical lead of the
manager or someone senior. To the person frequent check in
frequent feedback or maybe ask questions because there will be
a lot of things that these new hire don't know about the
context of the company because they are new, they are not
comfortable enough with everything that they see.
Or if either the code base. It is a technical stack.
Either the automation, they can use this channel, the
one-on-ones to actually learn from the managers or the seniors
to help guide them to the correct way.
And the other thing I saw also working is that the having a
buddy system during probably the onboarding period or the
probation period, Some people call it having the body that is
like a peer understand each other maybe pair from time to
time or even just spend some time.
Go out for lunch or dinner and just chitchat about each other.
I think that also tends to help so that they are more immersed
in the culture of the company and they can ask some secretive
questions that maybe they don't dare to ask the managers, but he
can ask their peers who have been around longer than them.
So I think these are some of the things that I also learned that
might work as well to help in the soft skills area.
I completely agree with you. Both those things at both.
The last startups. I've been working at, I also in
place and I definitely key to supporting someone who is new
and just makes that transition easier.
When you join a new company. I was intrigued in the
beginning. When you say a lot of Engineers
probably do not get exposure enough about these soft skills
either at school or in the University of and they learn
about this technology degree. What are some of the resources
that have helped you in your career?
In terms of boosting your soft skills is it may be training or
books or anything that Find may be interesting for an engineer,
not to be solely focused on just talking to the machines,
instruct them to do whatever they want.
But also talking to people and collaborate and understand each
other here are so apart from the one I already mentioned, which
is taking the opportunity to actually step up and lead a
demo, or team review. I think putting yourself out
there in the communities to speak at meetups and to actually
just attend and ask questions and interact with other people
outside of being on a machine and the computer.
After I definitely helpful, I haven't done a public.
Speaking course myself, but I know some people do so, they'll
do a public speaking course or a Toastmasters sort of learning
thing where you learn how to communicate and speak and
increase your confidence in a public space.
So that's also useful. I know there's a book called
soft skills. I haven't read it myself, but
that's always highly recommended that people can read up and
understand. What does it actually mean to
have these soft skills. And then I think, if you
identify someone who's good at it and you are Link to get
better at your soft skills. Like, how is this person were
communicated? How are they speaking?
So, well, what do they do to prepare for their presentations
and everything? If they at your company, you can
reach out to them and ask them to perhaps Mentor, you in this
journey. Tell them I want to get better
at my communication and collaboration of people.
Why do I need to do? So that's also useful.
But yeah, I think in schools or universities, there's more of a
space for teaching people those public speaking skills, because
then you are, Still at school so it can be a course with you
actually need to learn and pass the course.
So that forces people to sort of learn and then maybe more group
projects at school where people work together and collaborate a
bit more. I think a lot of school is
individualized work. Then you get out of school.
You realize most work is collaborative work.
So if we did more collaborative work at school, who perhaps
would be more prepared for collaborative work in the real
world when it came out. Yeah.
I do a completely agree with that same thing here in Asia
where Probably some schools emphasize more on the individual
results, individual activities. I think having more group
projects might be able to help boost this soft skills for all
of us in the industry later on in the career.
So, thank you for sharing the onboarding.
I think it's pretty useful. I hope a lot of our listeners
here would learn a lot from it Tanaka.
I also saw some things that you do, which is called no days off.
Is it like a lifestyle movement? Can you share a little bit the
name itself? Sounds intriguing?
No days off. Is it like you're working all
the time? I get a lot of people will say,
do you not want to take a break? Yeah, no days off.
It's a Lifestyle brand or movement.
You can call it that. Which I started about eight
years ago. The main purpose of it is to
inspire people to chase their goals and dreams or they
Ambitions and help encourage them to pursue them and Achieve
them. And the idea of no days off is
to try, push out a message of consistency.
I believe that if you want to get really good at something,
you want to get good at becoming And practicing it or doing that
thing, if you can't even do it every day, that's even better.
So that's where that comes from. It's really side ASL or hobby
project at the moment because obviously my main focus is the
tech industry and my tech job, but I do make some clothing
merchandise. That's no days off branded.
And again, the thinking there is people usually wear clothes that
send out a message that they are aligned with or clothes that are
reminded of something they want to live by.
And I thought no days off would be a great way for people to
share the message that they are living for that brand with those
goals of being consistent and getting better at what they do
and improving everyday to close it off on no days off is, I
believe everyone in the world as a place.
They are trying to get to a place.
They Define as success. Some true notes that they are
looking to try, get to, and each and every day, we wake up and we
do different things. To try to move us towards that
direction. And no days off is really had to
help encourage. You in that Journey, regardless
of whatever you're trying to be, whether you want to be the best
CEO in the world, based software engineer, best football player,
or the best father out there for your children.
Nowadays of his day job inspire, you, and get you there.
So that's what nowadays office. I also enjoy it because that's
how I try to live my life and it exists because I'm living that
movement basically, truly inspiring.
I think I completely agree, like, for all of us here.
We should have something that we aspire to go to or to Old.
So it could be the North Star like you mentioned or the
definition of success, which is probably very different from one
person to the other. There's no 100% true goal for
everyone to aim for I guess. I think the movement here is
cell is just to come up with some of your dream, your vision
and be consistent enough to try and Chase that goal and maybe
make sure that it gets realized rather than one day.
You'll regret it. Okay, you haven't done anything
towards whatever that you want to achieve.
So from those eight years of, starting this movement, are
there any inspiration? Chanel store, if you have a
community of people believing in this no days off.
Yes, so the interesting thing is, it's actually grew a lot
amongst my friends. My friends started buying the
merchandise. And after I saw the merchandise
to someone, I would get a photo with whereby.
I've sold to holding the merchandise to say, welcome to
the new days of movement. And if I know the person or
write a little bit about them to say this person is currently
pursuing this degree and they want to become this at some
point or Over there, doing that can Inspire other people also,
and I'll check them and put them on social media.
What will then happen? The interesting effect would be
all their friends would see that tag and then a number of them
would say, I also want to be part of that movement.
I also want that t-shirt or that sweater and then they would come
and buy. So that's all a lot of sales
have actually happened. A lot of my friends have
purchased no days or merchandise.
They in one degree away from them.
They are friends. Have also, then come along and
purchased it and then there are people where it's some people
weren't as fashion. Some We'll use it as an.
Inspirational piece of merchandise.
I've had stories with a friend. Once told me he was pursuing a
master's degree and he told me from the time, he bought the
T-shirt. He said you would only wear it
on that day. He secures that master's degree
and that was his inspiration to keep going until you secure that
degree and we eventually got the degree.
It was just interesting, just to hear that story and they've been
many other stories of people who've been trying to chase
their goals and they just keep telling you that you don't
realize how much I was motivated by just being part of the
movement and knowing that I need to take no days off and keep
going, and I hope it keeps going.
Obviously, it's a side I saw at the moment, but the bigger
impact it can make the better and more fulfilling.
It would be for me to. Wow.
What a great inspiration. So for those of you listeners,
who are interested in these snow days of movement, make sure to
check out a link, which I'll provide in the show notes as
well. So Tanaka, thank you so much for
the conversation. I think we are going towards the
end of the episode here. But before I let you go,
normally I would ask. Question about three technical
leadership wisdom. Do you have those wisdom that
you can share with us here here? Sure.
I'm happy to share, three lessons or three pieces of
advice before. Wrapping up.
The first one in my mind would be that technical leaders should
keep learning. It's a never ending Journey.
You will never reach this point where, you know, everything is
your like, I've reached a peak of technical leadership.
It's like the same as when you go to the gym exercise and you
build your muscles, if you stop, then you lose your Fitness.
So even if it's things that you know, No, and you great about in
the past and you've understood, it's always good to refresh.
So, I would encourage people to consume as much content about
leadership as they can, to, always be seeking out.
Mentors, seeking out. Different experiences.
Understanding other companies are doing things and just always
have this hunger to learn. I read somewhere that there is a
big correlation between people will learn a lot about technical
leadership, and people were good, technical leaders, like,
people were constantly reading and consuming content and people
are good, technical leaders. There is correlation there.
So, that's one of the key pieces of advice.
I would leave. And then the second one is it's
all about people. So it's very important to build
good relationships, especially with the people that report into
you, or the people that you manage and Lead.
So building, good open relationships that have trust in
them who go a long way because it will allow those people to be
very open with you with feedback and also to be very open with
you when they're not happy about something, or when there's
conflict and also, So for them to trust you when sometimes, you
will make decisions that may not exactly aligned with what they
think things should be happening.
It's less personal problem thing.
But more I trust the leader to make that decision.
A lot of problems. Also arise from people issues.
So it's worth remembering that everything is about people.
And it's key to build these good relationships with everyone.
You work with someone might ask, how do you build good
relationships as many practices and everything that you can do
to do that, but I think at the fun, Enter level is just be as
human as possible. How would you want to be
treated? If you were on the other side
and treat everyone else that way?
And then the last one, which does happen that some leaders
forget at times is as a leader, you are measured on how well,
your team is doing not on how well you are doing by yourself
as an individual. So what's important is to
actually create an environment which your team thrives in and
as well from the moment you have made a leader.
You've been measured on how well, Well, the team or the
people here, leading? I doing.
So everything becomes about them.
You want them to grow your own them, to be happy.
You want their careers to be always on the rise.
Your job is to create that environment.
Everything else comes secondary. You can be doing very well as an
individual, but if your team is not doing well and people are
not happy and everything, then you are failing at your job.
So that's my last piece of advice for take leaders update.
Definitely. The last one was really cool.
I totally With that. Some leaders do tend to be
individualistic, what? I think we should aspire to be a
servant leaders people who as a leader who serve your
subordinates of people below you so that they grow and also being
fulfilled in their career together with you.
So thank you Tanaka for people who wants to follow you where
they can reach you online. Maybe there are.
So I'm on LinkedIn under my name.
Tanaka motagua, if people just search for me, they can connect
with me there. I'm happy to chat to people and
always happy to connect. I'm also on Twitter as General
mu taqwa. So General, then my surname
which Aqua also happy to connect on Twitter.
And then also like I mentioned earlier who got the tech
leadership meet up. So on meetup.com, if you find
take leadership Meetup Cape Town and you join that community
group also happy to connect a so, yeah.
Those are my social media channels.
Alright, so, thanks again. It's been a pleasure, talking to
you. We should good luck with
namespaces and all the things you do with the community and
also your no days off movement. Thank you.
That's really been working. To chat and share some
leadership tips and everything. We've been insightful.
Thanks for having me. Thank you for listening to this
episode and for staying right till the end.
If you highly enjoyed, please share it with your friends and
colleagues who you think would also benefit from listening to
this episode. And if you're new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It really, really helps me a lot
in order to grow these podcasts better.
You can also find the full show notes of this conversation on
the episode page, at Tech Legion of the death website.
Doing the full transcript, interesting quotes, and links to
the resources and mentions from the conversation.
And lastly make sure to subscribe to the shows mailing
list on technology know the deaf to get notified for any future
episodes. Stay tuned for the next
technique Journal episode. And until then.
Goodbye.