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.