#24 - Best Practices for Your Developer Onboarding Process - Tanaka Mutakwa

Episode Introduction [00:00:50]

Henry Suryawirawan: [00:00:50] Hey, everyone. Welcome to the Tech Lead Journal podcast. I’m your host, Henry Suryawirawan. 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. Tech Lead Journal is available on most major podcast apps, such as Spotify, Apple Podcasts, Google Podcasts, and many more. You can also find and follow the show on YouTube, where I publish the same audio content with extra additional playlists that contain short clips from each episode that I find interesting, which you can listen to in a shorter amount of time.

Also check out Tech Lead Journal 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 promote the posts by liking and sharing them with others, that would mean a lot to me. For any of you long time listeners who would like to support me and make contribution to the show, please consider joining as a patron by visiting techleadjournal.dev/patron. Your kind support would 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 Mutakwa. Tanaka Mutakwa is the VP of Engineering at Names & Faces and the founder of the Tech 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 dived deep into discussing about the best practices for onboarding new technical hires and developers into the team. We covered the best practices ranging from technical aspects, such as tools and technologies, 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 NoDaysOff, 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 this podcast 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.

Introduction [00:04:52]

Henry Suryawirawan: [00:04:52] Hey, everyone. Welcome back to another show of the Tech Lead Journal. Today I’m so excited to meet someone from far away. His name is Tanaka Mutakwa. 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 Tanaka Mutakwa as my guest today and looking forward for this conversation with him. So Tanaka, maybe in the first few minutes, can you introduce yourself for all of us to know more about you?

Tanaka Mutakwa: [00:05:26] Thank you, Henry. Thanks for having me on the podcast. Yeah, my name is Tanaka Mutakwa. 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. 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.

Names & Faces [00:06:06]

Henry Suryawirawan: [00:06:06] Right. So Tanaka, you’re currently working in Names & Faces, right? The name itself sounds interesting. So can you share with us what is Names & Faces?

Tanaka Mutakwa: [00:06:15] Yes. Names & Faces, we are a startup, a technology startup. Our business is we make a visual employee directory that is quick and easy to access and helps people at companies know who is who at their organization and gain context into what their fellow employees do and where they fit in the organization. The idea is that it 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 100 to over 150 people. Basically, you don’t know everyone when the company starts growing 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’ve 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 & 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 Android and iOS and we have a web application. It’s a software as a service application. So companies will pay us to have the application running for them.

Career Journey [00:07:31]

Henry Suryawirawan: [00:07:31] So Tanaka, 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.

Tanaka Mutakwa: [00:07:44] Yes. So, as I mentioned earlier, I studied Computer Science at the University of Cape Town. So I’d say one of my first career turning points was actually my final year at the university. I applied for an internship, a six-week internship at a company called Allan Gray, which is an investment management company. So over our university vacation break, I got the internship, and I worked along three other interns and we worked at 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 studying 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. It was great exposure. I was happy with the company, a team that they had lots of good people and good practices and I agreed to join them. So I started there as a graduate engineer. And I grew from there into a junior engineer and a mid-level engineer and ended up spending four years there. That was my foundation of my technology career. That was my first exposure to agile development, agile methodologies, and how teams get structured. And as I mentioned, all sorts of software gets released to production and everything. The company had a very strong client focus. So we really made sure that everything we did was always of a high quality. It was definitely a traditional corporate structure. They have about 1,000 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 a tech-driven company works. So I got an opportunity to join a startup then, after four years, it was called Prodigy Finance. At that point, there were 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 companies and growing to big companies. So I thought that it would be a great learning. As I joined Allan Gray earlier, it was already a big company, a lot of things already in place. You’re not quite sure how they got to that place. And I thought at this new startup, I’d be able to learn about shaping all that and how we grow into a big company. I actually got all that through that start-ups experience because four years later, the company had grown to over 200 people and had offices now in London and in New York and we had presence in India too at the time I left. Also 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 that engineering team grew and they joined. I also was involved in setting up an internship program for new interns that were trying to support during their vacation, their university vacations. Cause 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 at some point wanted to, 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 tech leadership. At that point, initially I started with five people reporting in to me and I started learning and growing my tech leadership skills. I always had an interest in engineering leadership, hence my 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’d 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 Prodigy Finance and moved across to Names & Faces, which I spoke about a bit earlier. At Names & Faces, I was recruited as the VP of Engineering. So with my role there ensuring the engineering team or the tech team is delivering and working well. We’re ensuring we’re delivering software at a good speed and software of good quality. My role there primarily focuses on four main areas, I’d say when I always get asked how I describe it as, I’m responsible for the people, making sure they grow in their careers and are 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 with 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? Where’s our product going? How do we sell it and everything? And I’ve been at Names & 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, where I got foundation learning, then into a small startup that grew. Got exposed to leadership and then back to a small startup, but in a leadership position and continuing on that journey.

Henry Suryawirawan: [00:13:06] Thanks for sharing that. So you seem to have a very diverse experience from corporate like big corporate and also in a startup as well.

Tech Landscape in Africa [00:13:13]

Henry Suryawirawan: [00:13:13] 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 are there a lot of tech startups being built up in the Africa? Or how about the people skills there? Do you think they have the sufficient capability to also thrive in this technology industry?

Tanaka Mutakwa: [00:13:36] 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, till 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 universities is also now a more accepted degree. More people are going to study it as they realize, there’s never been a better time, I think, to be a technologist than right now in the world. There’s a high demand for engineers and more than the supply that’s there. 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, there’ve been a lot of startups that have been formed in interesting areas. A lot of them were in FinTech or are in the FinTech space, actually. People doing cardless payments. People being involved in like Prodigy Finance, where I worked at, was borderless loans for international students studying abroad. People involved in the blockchain and the crypto space. So there’s been 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 or in Cape Town and actually go through the full journey of being funded and then going through some exit of some sort. Worth mentioning, there’s Luno, which recently actually just exited, which is an exchange, crypto exchange for Bitcoin mainly. And there’s a company called Over, which was bought by GoDaddy, again very recently.

And if we go on the Africa landscape itself, there’s quite a bit of tech that’s been happening in Kenya. Over the last 10 years too. There was a lot of innovation in that space around payments, mobile payment technologies and quite a number of startups that were also growing out of that space. And of course, Nigeria is always a big player in Africa for anything. And there’s also quite a number of startups there that are formed. More recently actually a company called Paystack, which does payments, as 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 has 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 a company that’s based in one of those countries or actually move across to those countries.

Another thing worth mentioning actually is for Cape Town, a couple of years ago Amazon, it’s AWS, actually opened up offices here. And they did a massive recruitment run and they’ve got lots of engineers here, so their EC2 teams actually running out of Cape Town. So it’s no way 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 world just keeps growing, there’s more opportunities, more people are connected, more people have smartphones, the internet is also spreading even 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, I would say as a whole. I think the very fact that Amazon could set up here and be able to recruit and run the EC2 teams out of here, shows that we’ve got the skill levels. I think often what’s missed is, if people work in Silicon Valley or work at a company, a top company in the Valley, it can easily be seen as, “Oh, they’re 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 perspective, because our context is very different and it’s going to be difficult. Or it’s going to take time to find a lot of startups that start in Africa and then they expand and they’re well known in the world, like a Facebook that comes of Africa or something like that. But in terms of skill, I think we’re on par.

Henry Suryawirawan: [00:18:05] 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. A couple of times that a lot of industries or the startups are around payment, or maybe banking, digital banking, blockchain, crypto, and things like that. Are there any other industries that are also thriving in terms of tech adoption from Africa?

Tanaka Mutakwa: [00:18:27] Yeah, I think there are a 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 there. They just haven’t been many big exits because some of those usually then become 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’s at in the States. In the Valley or Silicon Valley, you hear 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 business actually operating, the tech 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 who they are willing to fund. 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 that someone in Silicon Valley would.

Tech Communities in Africa [00:19:54]

Henry Suryawirawan: [00:19:54] In terms of the community itself, I know you run a meetup for 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’re doing and the tech stack that they’re building. Are there lots of such things?

Tanaka Mutakwa: [00:20:14] Yes. So those have also been growing quite a lot lately. I’ll speak a bit about some of them, and then I’ll expand into Tech Leadership meetup, which I know more of since I started it and I’ve been involved. But they are quite a number. There’s a DevOps meetup, which is quite popular. So the DevOps engineers, and they talk 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’s a Cape Town Front-end Developers meetup. There’s quite a number of Agile meetups. So it’s a Scrum gathering of South Africa. 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 Meetup, which I started and I’m supported by two former colleagues, Benny and Roberto, who I met with just at the start of it and said, “Are 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 as a whole where a meetup or group or community that comes in, discusses technical leadership concepts and helps each other grow in tech 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’ve possibly met at a meetup. 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, they’ll help make their companies better places to work. And as a result, that’ll help improve companies, tech companies across Africa, and would have improved 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 of problems they’re facing at their company, 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 shared 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, we’ll probably have a mix where sometimes we’ll do an in-person one and sometimes we do one online as we’ve been doing. Yeah. So that’s the way it is. And I think we’ll keep growing that community.

One of the big things I learned as I’ve been growing through this software engineering journey is that a lot of the times technical leaders are not prepared for that role. They are pushed into the role because maybe someone identifies that this person’s 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 or leadership skills are very different from the skills you have as an incredible coder. It’s 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 are then in the role, then 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 Tech 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 eventually get into a leadership position, they’ve been exposed to a lot of different things that tech leaders do or should do.

Henry Suryawirawan: [00:24:00] 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 eye us 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 unpreparation shows that we also need to grow at that particular skill as well, like communication, facilitation, resolving conflicts, and things like that.

Onboarding New Software Engineers [00:24:26]

Henry Suryawirawan: [00:24:26] You have been working in a big corporate and you have been working now as a VP of engineering in Names & Faces. So coming to the topic that you want to share with us today, which is about onboarding new software engineers. As part of this topic, first of all, what are some of the things that are critical for onboarding a new software engineer coming to the company?

Tanaka Mutakwa: [00:24:45] Let me go back a bit and say, let’s start at why do people recruit engineers? So when you recruit an engineer on your team or you recruit a couple of engineers on your team, your goal is that once they’re on your team, they’re as productive as they can be as fast as possible so that the team starts pushing out more things and you get your value back. Cause you’re paying this engineer for the work they’re doing and you get your value back from them in the output that they’re producing. So one of the key things, or one would think one of the most important things is once you hired someone and you’ve gone through the whole hiring process, you don’t just end there and put someone in a room and say, “Hey, go ahead, now 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, there’s 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 great at that. Then there’s the domain knowledge, which is understanding what the business is about and how it relates to the technologies we’re writing. How does the business make money? How does 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 we’re mostly working in teams. It’s rare, yes, you have it, but it’s rare to find people who are working 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 built the API and you’re doing the frontend and you need to interact with them. You’re 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 at 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, it’s like tools and technologies, that domain knowledge, which is understanding the business and soft skills. Underneath each of those three things that you can do when you’re onboarding 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 of your tools and technologies? And again, if I go back to the technologies, it could be, let’s say your organization uses JavaScript as its main programming language, and you use React as your framework, use Git, your code is in AWS and 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 how the tests run. After they finish writing change, making that change, they would need to push up the code and then it gets pushed to some build servers. So what runs our build servers? How does a code then get from his machine or their machine to a staging environment and to a 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 their 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 pair 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 pair programming with them. Ideally, you want to pair 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 pair programming. So sometimes the new person helps them with their familiarity, sometimes they are also just watching you drive and they learn like the different tricks that you have and your understanding of your code base.

Also, if you have any onboarding documentation, that would be useful for helping people onboard 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 GitHub, a GitHub repository of how to set up the code base and how the architecture is structured, that could be useful. The important thing with documentation as always is to make sure it’s always up to date. Cause 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 who update it. So every new person always makes sure we’re 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’s new to learn. Oh, I need to learn JavaScript. What are the resources I need to look at? Then you can just point them to some lists 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’s also very beneficial because that encourages them to learn a bit more. So I’d say those are the four on the technical side, making real changes to the code base, pair programming, onboarding documentation, and some learning lists or learning resources that are backed with a training budget that comes from the company.

Henry Suryawirawan: [00:30:59] 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 tests and setting up all the necessary dependencies on their machines and going through the Continuous Integration or Continuous Delivery pipelines, if the company has it, and see all the automation up to production. I think that’s really, really 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 a person has to go through before they can actually make the real change.

Pair Programming [00:31:36]

Henry Suryawirawan: [00:31:36] Pair programming, I think is something that is quite interesting. Some companies do adopt pair programming, while the others do pull requests code review. Do you have a view on that? What makes pair programming much more efficient or vice versa?

Tanaka Mutakwa: [00:31:48] I don’t see it as pair programming versus a pull request model. Of course, I mostly agree with the idea that if code’s 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 pair programming, then you had that person looking at it. So you can still just approve from the other pair. One person pushes, the other one approves. What I found works really well is usually the team has more than two people, anyway. So even when people pair, they still create a pull request. And they still shared with the rest of the team. So if there’s four other engineers elsewhere, 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 pair programming versus work as an individual push, and then someone else looks as it is, with pair programming, there’s instant feedback. So you don’t have to wait for your code for like half a day or a day. Then you put up a pull request. Then eventually someone does give you feedback and then you go back and address that feedback. And then half a day later, you put up another pull request and then maybe there’s more feedback and you’re 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 as baffling, and you get stuck. But someone who is 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 encourages collaboration, building 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 where you almost on everything, you have to work as a pair. I will not enforce it and mostly allow the team members to decide as they’re working on stuff whether should we pair on this or should we not? What tasks make sense to pair on? But I have a hypothesis that in a high-performing team, pair programming and collaboration happens at a 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 pair programming, a lot of collaboration. If you find a high performing team, those two could correlate.

Henry Suryawirawan: [00:34:03] 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 churn more things either faster or you can improve stuffs also in a faster way.

Importance of Documentation [00:34:15]

Henry Suryawirawan: [00:34:15] Regarding these documentation and learning resources and training plans and things like that. In a startup sometimes, I think these things tends to be neglected, especially you know, maybe you are a 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?

Tanaka Mutakwa: [00:34:36] Yeah, I think it all depends on context, as you say. In a much smaller company, quite a number of things are actually in people’s heads. But also access to them then is easier because when you join as a new engineer, that other person who’s got it in their head, he’s probably always with you. So that list may not be explicitly written down, but if you did ask someone who’s just hired, let’s say it’s a team of four people only, and you just joined as the fifth person. And you ask to all the other four guys, well, which 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 apart. The longer you hold on to things, and eventually you get to a place where perhaps like how to set up 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, sits there and it lives there. It’s better than it sits in someone’s head. But I do completely understand in a very small startup case, especially 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 quite a lot of organizations are much bigger with 300-400 people teams and everything. You definitely need some structure there and you want to have it in place.

Henry Suryawirawan: [00:36:09] My total take on that is that, it’s okay for you if let’s say you do your first or second hire, but once you get beyond that, I think you need to start writing down the process or the framework that you do this thing, right? Like for example, hiring the third person, you would be probably spending some time in order to come up with the onboarding documents so that the next person, the fourth person that comes in actually has a proper documentation and 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 hire gets the updated documentation.

Domain Knowledge [00:36:44]

Henry Suryawirawan: [00:36:44] 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 that?

Tanaka Mutakwa: [00:36:51] Yeah. So domain knowledge, like I said, is really about understanding. It’s very important. It’s really about understanding the business and the business you’re working for. How do we make money? What’s our project? How does the company work in general? What do other people in other departments do? And how does our technology that we’re writing relates to all this? And it’s an important thing for an engineer to have, because you can have all of the understanding of the technology, but if you don’t know what you’re building for, then it’ll always be confusing. And that context will 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 there for and what product it actually has, the more likely you will 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 or other departments in the company do. It’s 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? What’s the finance department like? What happens there? Who is there? And everything and a bit about what’s the product and everything that we do. In smaller companies, like you said, 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 it’s someone who was like your manager or your project manager, if the team already has a project manager in there, they can give you a full overview of the company. So it varies of ways 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 we putting out there, and then relate all these back to the technology that, that engineers write. So that’s domain knowledge.

Developers Lack of Interest in Business [00:38:48]

Henry Suryawirawan: [00:38:48] So, yeah, I do agree with you. Sometimes 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 the 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 user’s 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 experience working in 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 user’s problem. Is there any tips that you see from your experience so far?

Tanaka Mutakwa: [00:39:37] Some of the things I’ll suggest is I think one of the main causes of the lack of interest is also how companies are structured and how there are this separation of, “Oh, 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, it’s 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 and 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, there’s more of a passion or understanding how is that system bringing that money and what impact can it make, than 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 bringing up alignment and the teams closer and everything in 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’re thrown at the engineers to just build, almost making the engineers like code monkeys, you know, just write whatever solutions we’ve come up with. Whereas the 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 we possibly have? And you start getting buy-in and ideas from different people, including the engineers, and again, they align more to the problem.

So yeah, I think those are the main things. It’s just there’s that mismatch where it’s 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 as, oh, another resource center. Because then they act that way, in a way where it’s like, “Okay, we’ll just do what you need. We like the tech. We’ll build whatever you need, but we’re not concerned about how everything else works. And then I think some companies do expose their engineers to their users and their user’s 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. But there’s many different sort of strategies. But it comes to an engineer feeling they have a sense of ownership in more than just the tech, but where the company is going.

Henry Suryawirawan: [00:42:02] Yeah. I completely agree with you. The silo thing, right? Like the business versus the people from the tech. So that’s why I think the whole movement about agile, 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 we call it OKR or some performance measurement, it should all tie back to how the company either make money or benefits the users. It could be the number of revenue, number of profits, number of users adopting the products. I think if both teams are being measured on the same thing. I guess in a way, engineers would also love to learn how they can help to actually bring the numbers up.

Understanding Tech vs Business Constraints [00:42:40]

Henry Suryawirawan: [00:42:40] So the other problem that I normally see as well as engineers is that we all love the shiny new tech. But we don’t actually understand the constraints that the business actually is having. For example, these days where 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 are working with probably not so compatible with the new things. So in that case, as a technical leader do you think that these people have a bigger role to play to explain to the engineers that we have these constraints?

Tanaka Mutakwa: [00:43:14] Yeah, I completely agree. As you were talking, I just thought that’s quite a lot related to a leadership problem. Leadership 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 where are we financially? What do 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 old database overall was big, then we need to look at why do we 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 the outcomes the business is trying to achieve. But that’s where, I guess, as leaders, as tech 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 the strategy 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’s sake.

Importance of Soft Skills [00:44:36]

Henry Suryawirawan: [00:44:36] Right. I think it’s greatly put, and I do like that. So moving onto the third one which is something that I think as an engineer, we don’t like this thing, soft skills. If possible, I think most engineers would like to talk to machines than with people, right. So, yeah. What is your take on this soft skill? Why is it so important during the onboarding?

Tanaka Mutakwa: [00:44:55] I think I mentioned it 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 now work in teams, and if you work in a company, you talk to different people from different departments. You may actually interact with users. You definitely need the soft skills. And as you said, 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 taught 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 to the machine more because that’s how we provide some instructions and everything. But the good thing though, is I don’t think it’s something that cannot be built. It’s definitely something that someone can improve in and get better at with practice. Because at the end of the day, it’s really about interaction and communicating and facilitating.

So there 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 you’re onboarding 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 gives 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 if 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’re just thrown into a corner and you work by yourself, again, there’s no communication and teamwork and everything collaboration. Whereas pair 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 your pairing buddy may ask you, what are you thinking? How are you thinking of solving the problem? And you have to communicate that back to them. So that’s also great.

Team building also helps. 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 a lunch or an activity. Even 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 will 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 may receive feedback, but the feedback is in a way to try help them improve and grow versus to try discourage them or in a malicious way, sort of give feedback that pain someone. So if you create an open, transparent, psychologically safe culture, you’re also opening up for people’s softer skills to improve and grow.

At the end of the day, we are supposed to be able to communicate and sell the solutions we’ve built. 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, soft skill is probably the one I would say is the highest grade when you’re onboarding people. And if you can get engineers to have great soft skills, then the other things you can almost get together much more easily. But the soft skills one is the important one and also if someone doesn’t have them, the one that you have to work a bit harder to help them build and grow.

Henry Suryawirawan: [00:48:39] 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 or 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 either the code base, either the 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 having a buddy system during probably the onboarding period or the probation period, some people call it. Having the buddy 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 chit chat about each other. I think that also tends to help, so that they are more immersed to the culture of the company. And they can ask some secretive questions that maybe they don’t dare to ask the managers, but they can ask their peers who have been around longer than them. So I think these are some of the things that I also learn that might work as well, to help in the soft skills area.

Tanaka Mutakwa: [00:49:48] I completely agree with you. Both those things at both the last startups I’ve been working at are also in place and are definitely key to supporting someone who’s new and just makes that transition easier when you join a new company.

Tips for Improving Soft Skills [00:50:01]

Henry Suryawirawan: [00:50:01] 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 when 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 maybe training or books or anything that you 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.

Tanaka Mutakwa: [00:50:30] Yeah. 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 a computer are 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 willing to get better at your softer skills. Like how’s this person were communicated? How are they speaking so well? What do they do to prepare for their presentations and everything? If they are 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 with people. What do I need to do? So that’s also useful.

But yeah, I think in schools or in universities, there’s more of a space for teaching people those public speaking skills, cause then you’re still at school. So it can be a course, which 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, and then you get out of school, you realize most work is collaborative work. So if we did more collaborative work at school, we perhaps would be more prepared for collaborative work in the real world when we came out.

Henry Suryawirawan: [00:52:16] Yeah, I do 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 these soft skills for all of us in the industry later on in the career.

NoDaysOff [00:52:31]

Henry Suryawirawan: [00:52:31] So thank you for sharing the onboarding, I think is 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 “NoDaysOff”. Is it like a lifestyle movement? Can you share a little bit? The name itself sounds intriguing, “NoDaysOff”. Is it like you’re working all the time?

Tanaka Mutakwa: [00:52:51] I get a lot of people who say, do you not want to take a break? Yeah, NoDaysOff, 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 their ambitions and help encourage them to pursue them and achieve them. And the idea of NoDaysOff 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 consistent at practicing it or doing that thing. If you can even do it every day, that’s even better. So that’s where that comes from. It’s really a side hustle 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 NoDaysOff branded. And again, the thinking there is people usually wear clothes that send out a message that they align with or clothes that are reminder of something they want to live by. And I thought NoDaysOff 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 every day.

To close it off on NoDaysOff is I believe everyone in the world has a place they are trying to get to. A place they define a success, some true North that they are looking to try to get to, and each and every day we wake up and we do different things to try and move us towards that direction. And NoDaysOff is really here 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, best software engineer, best football player, or the best father out there for your children. NoDaysOff is there to help inspire you and get you there. So that’s what NoDaysOff is. I also enjoy it because that’s how I try to live my life and it exists because I’m living that movement, basically.

Henry Suryawirawan: [00:54:43] 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 build. 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 itself is just to come up with so-called 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 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 inspirational stories? Do you have a community of people believing in this NoDaysOff?

Tanaka Mutakwa: [00:55:24] Yes. So the interesting thing is it actually grew a lot amongst my friends. My friends started buying the merchandise and after I sold the merchandise to someone, I would get a photo with whoever I’ve sold to, holding the merchandise to say, “Welcome to the NoDaysOff movement”, and if I know the person, I’d 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 whatever they are doing that can inspire other people also, and I’ll tag them and put them on social media. What would then happen? The interesting effect would be, oh, their friends would see that tag and then a number of them would say, I also wanted to be part of their movement. I also want that T-shirt or that sweater, and then they would come and buy. So that’s how a lot of sales have actually happened. A lot of my friends have purchased NoDaysOff merchandise. Then one degree away from them, their friends have also then come along and purchased it. And then, yeah, people wear it. Some people wear it as fashion. Some people will use it as an inspirational piece of merchandise. I’ve had stories where 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 he would only wear it on that day he secures that master’s degree. And that was his inspiration to keep going until he secures that degree. And he eventually got the degree. It was just interesting just to hear that story. And there’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 NoDaysOff and keep going. And I hope it keeps going. Obviously it’s a side hustle at the moment, but the bigger impact it can make, the better and more fulfilling it will be for me too.

Henry Suryawirawan: [00:57:03] Wow, what a great inspiration. So for those of you listeners who are interested in this NoDaysOff movement, make sure to check out a link, which I’ll provide in the show notes as well.

3 Tech Lead Wisdom [00:57:12]

Henry Suryawirawan: [00:57:12] 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 this question about 3 technical leadership wisdom. Do you have those wisdom that you can share with us here?

Tanaka Mutakwa: [00:57:25] Yes. 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 and you’re like, I’ve reached the peak of technical leadership. It’s like the same as when you go to the gym, you exercise and you build your muscles. If you stop, then you lose your fitness. So even if it’s things that you know, and you’ve read 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 how other companies are doing things, and just always have this hunger to learn. I read somewhere that there’s a big correlation between people who learn a lot about technical leadership and people who are good technical leaders. Like people who are constantly reading and consuming content and people who are good technical leaders, there’s correlation there. So that’s one of the key pieces of advice I’d 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 would 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 are not happy about something or when there’s conflict. And also for them to trust you when sometimes you will make decisions that may not exactly align with what they think things should be happening. It’s less a 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? There’s many practices and everything that you can do to do that. But I think at the fundamental level, it’s 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 does well. From the moment you are made a leader, you’re being measured on how well the team or the people you are leading are doing. So everything becomes about them. You want them to grow. You want them to be happy. You want their careers to be always on their eyes. 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’re failing at your job. So that’s my last piece of advice for tech leaders out there.

Henry Suryawirawan: [01:00:16] Definitely the last one is really cool. I totally agree with that. Some leaders do tend to be individualistic, while I think we should aspire to be a servant leaders. People who as a leader who serve your subordinates, the 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?

Tanaka Mutakwa: [01:00:38] Yeah. So I’m on LinkedIn under my name, Tanaka Mutakwa. If people just search for me, they can connect with me there. I’m happy to chat to people. I’m always happy to connect. I’m also on Twitter as @generalmutakwa. So General, then my surname Mutakwa. Also happy to connect on Twitter. And then also, like I mentioned earlier, we’ve got the Tech Leadership Meetup, so on meetup.com, if you find Tech Leadership Meetup Cape Town, and you join that community group, also happy to connect there. So yeah, those are my social media channels.

Henry Suryawirawan: [01:01:10] All right. So thanks again. It’s been a pleasure talking to you. Wish you good luck with Names & Faces and all the things you do with the community and also your NoDaysOff movement.

Tanaka Mutakwa: [01:01:18] Thank you. It’s really been good to chat and share some leadership tips and everything. Truly been insightful. So thanks for having me.

– End –