#115 - Senior Engineering Leadership & Scaling Engineering Teams - Manoj Awasthi

[00:01:24] Episode Introduction

Henry Suryawirawan: Hello to all of you, my friends and my listeners. Welcome to the Tech Lead Journal podcast, the show where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. If this is your first time listening to Tech Lead Journal, don’t forget to subscribe and follow the show on your podcast app and on LinkedIn, Twitter and Instagram. And if you’d like to support my journey creating this podcast, subscribe as a patron at techleadjournal.dev/patron.

Time goes by pretty fast, and we are fast approaching the last month of the year. So far in this year 2022, Tech Lead Journal has delivered a total of 45 episodes, including this one. Thank you for always being a loyal listener, and I hope that all the episodes this year have been useful and inspiring for all of you. This current episode you’re listening to is the last episode of the year, as I’m planning to take a break in December, and I’ll be back with a new episode in early January 2023. So please stay tuned for the new episode. During the break, Tech Lead Journal will resurface some of the best episodes in 2022. So if you haven’t had a chance to listen to any of those, make sure you also check them out during this period. And now back to today’s episode.

My guest for today’s episode is Manoj Awasthi. Manoj is currently the CTO at JULO and previously the SVP of Engineering at Tokopedia. In this episode, Manoj shared engineering leadership lessons from his recent experiences. Manoj started by describing the role of a senior engineering leader before then explaining some important aspects of engineering leadership, such as scaling up engineering team, hiring engineers and engineering managers, creating culture alignment, putting in place engineering governance, and maintaining engineering productivity. Towards the end, Manoj shared some of his important lessons learned before ending by sharing his tech leadership wisdom.

I really enjoyed my conversation with Manoj, as there are many insights from this conversation related to engineering leadership, which are highly applicable if you are also in the same role within your organization. And if you find this episode useful, please help share it with your friends and colleagues, so they can also benefit from listening to this episode. I always appreciate your support in sharing and spreading this podcast and the knowledge to more people. Before we continue the conversation with Manoj, let’s hear some words from our sponsors.

[00:05:09] Introduction

Henry Suryawirawan: Hey, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I’m so excited to meet someone who is nearer to my side this time, which is in Southeast Asia. My guest is Manoj Awasthi. He’s currently the CTO at JULO, a financial tech startup based in Jakarta. Before JULO, Manoj spent around six years in Tokopedia, helping them to scale, to becoming one of the largest scale-up company in Indonesia and Southeast Asia in general as well. Manoj today will be sharing a lot of his lessons learnt, maybe from Tokopedia experience. Looking forward for this. Happy to have you here, Manoj.

Manoj Awasthi: Thank you, Henry. Happy to be here.

[00:05:46] Career Journey

Henry Suryawirawan: So Manoj, I always like to hear first thing from the guest, which is to share about your experience, your career journey, any kind of highlights and turning points that you want to share with the audience.

Manoj Awasthi: Oh, sure. So I come from India, and I was born and brought up in northern part of India. So from early on, I developed some interest in physics and mathematics. So engineering was like a very natural course for me. I was very fortunate to actually get some very good teachers who got me interested in those subjects very deeply. I developed some serious interest in programming in college. And I got introduced to C programming. I got introduced to this operating system called UNIX.

It was 2000 era. Dot-com crash was just about to happen. So we were basically working using a dumb terminal. When I say dumb terminals, basically these were like terminals that will connect to very high-end servers. So whatever command you type in, basically they will go to the server and you’ll get a response back. So it may sound like a very primitive at this time, but they were very exciting even then. Particularly, throughout my college time, I enjoyed tinkering and coding more than other subjects, the academics as such. Apart from C, I learned Java and there were like applets and servlets. I don’t know whether you remember them, know them or not. So it was a very interesting time.

In 2004, I got my job placement done. I joined a huge software system in Delhi, India, as a software engineer. This company was basically a telecom software company, and basically built all that stack that is probably getting used in this podcast, for example. It was this IP telephony stack. It was some really exciting work that I got exposed to in that organization. And being the first job, I was really lucky to actually get that exposure. The perspective of the code that you get when you read good code it actually sets you for future. We really learn a lot by reading other people’s code.

In 2005, I moved to a smaller startup called Solidcore. So this was basically into B2B security domain. They built a product which was, basically, a real time white listing solution. Initially meant for installations on ATMs, for example. You do not want any vulnerable software to actually run on the servers. You kind of lock down the server. So for that, you’ll write a module or a system which sits in the kernel itself. So it was easier done on Linux and I was part of the Linux team. But I got to work with people who were working on Solaris product, which was not open source then, on Windows, which was not open source then, and not open source now. They knew so much. They were reverse engineering stuff, reverse engineer binaries. When I was working with them, basically I’ll see them disassemble and go through that disassembly code and figuring out, okay, this is a linked list traversal, or something like that. This was really fantastic, and I really built my Linux expertise in that phase of my career.

In 2007, I moved to Adobe. Until this time, in a real industry setup, I never worked for a consumer company, consumer product. It was mostly command line, protocol stacks so far, right? So I wanted to actually gain that exposure as well. And Adobe was a great choice for that. Thankfully, I got this opportunity. I was assigned to a product called Adobe Photoshop Elements, which is a consumer version of Photoshop. The interesting part is that this product actually shared actual code from Photoshop. So you are working on the same code base, in a sense. I worked on that product for multiple releases. Again, reading code from real experts, people who actually wrote Photoshop version zero. I mean, a lot of them were actually still there. Reading that code and seeing how the performance is actually a key factor while writing software, and how quality actually becomes so critical. You get very different perspective on quality when you move from companies like a startup into a bigger organization like Adobe. Because now you have to ship a code. That time, we were actually shipping CDs. So there’ll be yearly release. There’ll be CDs burnt and later on, it will actually went to a cloud-based software and so on.

But the idea that, okay, when you’re shipping, you have this huge responsibility of shipping it. It cannot break. You do not have an option of patching it all the time. And you do have an option, but I mean, it’s a very costly process for the company. It has all changed in the web era, but still, it was very interesting experience and I got a different perspective on quality how do you do that. So after multiple releases for many years where I worked on the product flows, image algorithms and so on, I also got some interest in computer vision.

Year 2012, I moved within Adobe. I moved to a different division, which was Marketing Cloud division. This is when I kind of reconnected to web technologies written in Java mostly, and Java itself had evolved since I tried it in college. Other than build web services, I got to work on some very exciting stuff like big data. And I also got introduced to a very exciting area for machine learning. Basically, we were deploying a random forest to solve some problems.

In 2015. I was basically at a juncture where I thought, okay, I want to explore the startups again, moving from Adobe. E-commerce was growing a lot in India and basically, I was looking out for opportunities. But at the same time, I got in touch with Tokopedia.

Two things excited me a lot. So one was the business model itself. Before this, I never heard of a marketplace which does not charge any commission from the merchants, because that decision itself, and it did not also believe much in the cashback, and it was able to scale. I could imagine that, okay, if you go with this approach, what kind of scale you can actually attract in the business? So that was one. The second was when I came to Jakarta just to meet the Toko team. There are a lot of systems that should be built, they have not been built yet. I think that was a very attractive opportunity for me. I will not find a similar opportunity to go and rebuild many of those systems in India. That basically got me moving to Indonesia, pursuing Tokopedia opportunity.

When I came here in 2016, we were already on a journey, just beginning. So it was basically a monolith written in Perl. That was the e-commerce website. It was all implemented in the Perl framework developed by the team here. We were basically in the process of breaking that monolith piece by piece into services, and those services were all written in Golang. We chose Golang for its performance, its concurrency support, and it was a modern language and it’s very simple to learn. I mean, case in point, is that, okay, all the Tokopedia team basically was well versed with the Perl, but they did not know Golang. But we all learned it on the job. So when I came, it was already in progress and I joined Ads team. Basically, solving the scalability problem for ads.

And then later on, I joined as an architect, but I picked on like many roles. Putting a different hat depending on what do you want to get done. Helping the merchant team as well. Moving search platform from Solr to Elastic Search. Doing lot migrations of, initially, we were on-prem, basically, a local data center called Biznet. Then from Biznet, we moved to cloud. First moving to AWS. Later on, also moving from AWS to Alibaba following the Alibaba investment, and there were like a couple of other reasons as well. So over time, over six years, I mean, it has been very, very exciting journey. And later, I was basically leading the marketplace team in Tokopedia and data science and data engineering team.

Over time, I think we grew a lot. Leadership actually also grew a lot. Later part of Tokopedia, I think we were able to attract some very good talent from Valley who actually helped shape Tokopedia better and transforming it into a world class organization. So benefited a lot from all those experiences. It overall has been a very fulfilling journey, I’ll say, starting from a small startup to IPO, which we went after our merger with Gojek and Tokopedia into GoTo. So it was a really, really great journey.

After spending like 6.5 years in Tokopedia, I had this personal ambition to go again and work in a smaller setup. I kind of thought that, okay, this is the right time. Let me actually do this now because I’m already turning 40. If not now, then when? I’ll only get older. So I joined JULO as a CTO recently, just two months back. JULO is a fintech startup, as you just said. This company is into consumer lending. Three things excited me.

One was the mission and vision of JULO itself, which was basically to enable access to credit for all the consumers in Indonesia, especially the ones that do not have access to the traditional means of credit. Unbanked population, underbanked population, and so on. If that access is not provided to them, two things happen, right? So one, either they cannot get out of where they are. Sometimes they need money for paying school fee for their kids. Sometimes they want to purchase a bike so that they can actually join Gojek as a driver and improve their financial prospects and so on. I think this mission and vision was like very exciting for me. The second was, basically, the founder, Adri, who’s the CEO, he’s a very persistent individual, and keeps at a problem for a long time. He started this company six years back, almost the same time when I actually came to Indonesia. Somehow I got in touch and I was moved by that. The third thing was, despite this being a very large market, a very crowded market as well, I like the focus that the team actually has, the management has on the core of the business. So those things actually excited me as well, and I’m here leading the technology team at JULO.

Henry Suryawirawan: Thank you so much for sharing your rich experience. One thing that I could see, the core stays the same. In engineering, you started with very hands on, from protocol, maybe some device and operating system, and go to Photoshop, which is a lot of algorithms, I believe, that you have to look at. Now moving into startups and Indonesia market and now becoming leadership, senior leadership.

[00:15:02] Role of Senior Engineering Leader

Henry Suryawirawan: Maybe let’s start from there. By becoming a senior engineering leader, what do you think a role of a senior engineering leader should be? What’s the responsibilities or what are unique about being a senior engineering leader?

Manoj Awasthi: That’s a great question. So as you, I don’t like that word, but as you rise up the ladder, rise up the position, couple of things happen here. So one is the responsibilities increase. The breadth increases. So when I say breadth increases, I mean now your scope actually becomes larger. One thing that also increases is the ambiguity and the expectations from your role increases. So now you do not know very clearly what is expected of you.

To give an example. There is this phrase. When you start your career, initial few years when you’re at software engineer or senior software engineer, you are told what to do and you are also told how to do and you have to go and do it. As you go further, maybe senior software engineer to principal engineer and so on, now you’re told what to do but not told how to do. You need to figure that out. But as you go further, I think you’re not told even what to do and how to do. You have to figure it out. You have to figure out what to do and how to do. So that is what happens here. But for senior engineering leadership roles, there are a bunch of things that are very common.

As you move into a managerial ladder particularly, I’ll talk for that at first. One thing is a given, right? So you will be spending a significant part of your time in the people management, managing people. Yes, it can change based on the organization’s size. For example, it’s a small startup, less than 10 people. You, as a CTO, will also be bearing a certain responsibility of writing code, etc, etc. But when startup actually goes beyond a certain size, for example, it’s a 300 people startup, you will rarely do so. But people management remains too, even for a smaller startup.

When I say people management, what do you mean by that? I mean, for example, hiring or even like before hiring. Writing the job description and looking for people. Partnering with your recruitment team, ensuring healthy pipeline. Hiring those people, onboarding them, building the processes for onboarding. Growing, providing a clear career path for each of them. Coaching them, mentoring them, and all those actually become part of the people management, I believe, you have to do. It’s a very important part of your job description. You need to partner with the HR team or People team in your organization. Take care of the organisation, ensuring the right policies are being built, and they’re helpful in the knowledge industry. Sometimes there is this conflict that, okay, a lot of HR folks coming from, say, traditional background, they will actually put a policy that does not apply to the IT as much. Doing the performance appraisal effectively, and that’s also like a kind of a black art. And then participating in tech branding, for example. So all these other people aspects. So that is one.

The second aspect is that now you have a team that you have built, and that team is actually well taken care of. Second important thing, and probably this is the most important function of our technology leader, is executing on it. Enabling the business or product through that execution. So there is a vision that is set by the founder, by the product team, the business team, that they want to do certain things. Engineering team is the one that will actually make it real. So that execution is super, super important. As you execute, as you build those products, release them, test them, monitor them, there’ll be bunch of things that are spoken, right? So for startups, I think speed matters a lot. How fast can you actually do this? But in addition to speed, quality matters a lot. So whatever you are doing, you have to do it in the right manner. If you don’t do that in the right manner, then although you are able to churn out products or code very quickly, it is not helping the customers. So you have to ensure that the speed is with quality.

Third aspect is often forgotten, and that is where the technology part comes in, is the agility with which your team can actually react to the changes and the requirement or changes in the business and so on. This requires, fundamentally, a great architecture. That is where all these technology companies need to understand that they’re technology companies first. Then only on top of that you build the business and product. So that is the second part. So first part was the people. The second part is the execution, and the third part of the technology leadership is building a tech roadmap. When I say a tech roadmap, so as you get into the cycle of churning out products, building things and so on, and as you scale from, say, first 100 users, 1000 users to 10,000 users, to a million users to 10 million and so on, you will accumulate tech debt.

And what is tech debt? Tech debt is basically that you have taken a decision in the past, which was good for the past, but not good anymore as you scale further, or you took a shortcut in the past, but that shortcut needs to be fixed. Basically at that time, you said, oh, I will fix it tomorrow, but tomorrow has already become yesterday. Obviously, you need to go and pay that debt. So proactively designing or redesigning the architecture to ensure that platform is ready for future scalability requirements. That is another responsibility that this team actually has. And when I say tech roadmap, it does not only mean the pieces that were part of the product. It also means infrastructure. It means security. It means the data protection. It means the back end. It means the front end. It means the QA practices or automations and so on. All those things. So those three things. People, execution, and tech roadmap. I think as you become a senior leader, that will be important.

One last piece I will say, which is a general requirement as you go into, especially the executive management level, is having or developing the right business product mindset. Because what I feel is that unless you actually have a great business product understanding, you cannot even build the right architecture or design, because it has always to be in the context of the current requirement or the local context, basically. There are things which are basically kind of a playbook for scalability. Okay. You should actually have a replica for our database. You should actually use caching to scale your database, you should do many things, horizontal scaling or vertical scaling and so on. But in the end, great optimization results will actually come from leveraging the knowledge of your business context. I tell often to individual contributors, the architects, that you need to understand and design for the current context. The better you understand the current requirements, more optimization you can actually go and code it. So yeah, I hope that answers the question.

Henry Suryawirawan: Yeah. Yeah, definitely. I mean, this is great, right? So for those listeners who are in senior engineering leadership, maybe it’s like Head of Engineering, VP of Engineering, Director of Engineering, or even CTO themselves, I think there are a lot of gist here from your experience, from history. I personally like your what and how framework. So when you’re a junior, you are being told what and how. As you go up, you’re told nothing. You didn’t even know the what. You didn’t even know the how. And you have to come up with both. So I think that’s really insightful for me.

[00:21:31] Scaling Engineering Team

Henry Suryawirawan: Throughout time, I’m sure in Tokopedia or your journey, you’ve seen a lot. In Tokopedia, in particular, you grew like an engineering from 80 to 2000+, I guess, right? That’s really a rapid scale. Maybe can you share some of the growing pains or maybe the hiring, challenges, like how to scale the team from a small size to bigger size? Maybe some of the insights you can share here.

Manoj Awasthi: Tokopedia team actually grew from 80 to 2000 people now. As you scale, I think you need to work on revamping a lot of the ways you work. For example, your hiring process will need to get revamped. Onboarding process has to be revamped and improved from time to time as your team size increases. And your cultural integration process has to be revamped. Why this is important is because, especially in a hyper growth kind of phase, when you actually hire many people, these people are coming with their own background, their own ways of work, their own cultures, and they can be very different. And when I say culture, culture is basically a shared set of beliefs.

Now, how do you integrate them into your culture? Because this is a very important part often forgotten that end of the day, unless you actually integrate them in your culture, get them to your values, your teams will be very heterogeneous. They do not have the shared beliefs, and that is a critical requirement for teamwork. So you have to ensure that. A more tactical part of that is standardization of the stack. If you do not focus on standardization and do not have some governance in place, you might end up like being there are 20 teams and they’re using their own stack. And that is okay. People can actually debate both sides, but I think it’s not going to be very beneficial for the team. Because I mean, you cannot actually have sharing of the knowledge. You cannot have people moving from one department to another, and so on. So a lot of things actually can break. Sometimes, it may also happen that there is no governance in place and people are just using different choices. And you have, for example, five different kinds of queues in the system. Seven different kinds of databases. And that becomes operational, I think, disaster.

When I say onboarding process, what I mean is that, for example, having a clear documentation of what systems are in place. How we work a clear onboarding checklist? When an engineer comes or a leader comes, they already know what to do in my first few weeks. How to actually familiarize myself on this company’s way of working? Also, having bootcamp kind of training, and this was a very useful thing in Tokopedia. For example, I learned there was like a couple of days of bootcamp training for every newcomer that joins. That basically sets them up for, okay, how we work? What is our tech stack? What are our products? Who are our customers? What things we are building? And what our values or DNAs and so on.

As you scale, another thing that I want to point out is that you cannot keep your organization flat forever. When you start small, like 80 engineers, they can all be reporting to the CTO, it’s fine. I mean, even that is like too much. But once it becomes like 200 - 300 and more, I think you need to actually set an organization structure in place so that better management can actually happen for the team. Those are some of the things that I think is important when growing the organization.

[00:24:28] Hiring Engineers

Manoj Awasthi: On the hiring question, for example, when I’m hiring engineers, I look for engineers who can, I mean, coding is important, right? So definitely, they must be able to code. They must know their hard skills. So language is not important, but they must be able to problem solve. So that is one thing that I look for.

The second is the attitude. This is a very critical thing. There is always this discussion between will and a skill, by the way. So if people do not have a will and do not have a skill, of course, please don’t hire them. But if they have a skill and they don’t have a will, then you can hire them. But because they have a skill, they do not have will, you’ll have to motivate them. You need a leader who can actually motivate them to actually have the will. If somebody has the will, but they don’t have skill, it’s a easier problem to solve. In my opinion. If their base level done, they can always be upskilled. You need to train them and so on. And if they have both skill and will, I mean, amazing. You have a rockstar there.

I recently told my team at JULO what good engineers qualities are. It may sound a bit rhetoric. I feel that good engineers, I’m not talking about 10X engineer that used to be discussed on Twitter, yeah, so I’m just saying good engineer, I think, that they should be pessimists. They have three qualities. So first is being pessimist. They should understand that whatever can go wrong will go wrong someday. They are basically people who believe in writing as rock solid software as possible. So they’ll probably go and check every error that is happening cause that error is being returned for some reason. You must actually handle it and so on. I give an analogy to my JULO team, for example, good engineers are those engineers who build bridges which can stand there for hundreds and thousands of years. And that is because they have taken care of everything that they can that can go wrong. So they have taken care of, oh, this can go wrong. Let me actually take a backup, or this backup can go wrong. Let me take a backup of backup.

The second quality of a good engineer is they’re also optimistic. They know that whatever they’re building will basically not only see the light of the day but also grow in the number of users that use it. And hence, I need to actually think about the architecture and design very seriously. Third thing is that they are also realistic, like pragmatic. As in, yes, I know that okay, I want to build a perfect software, but there are all kinds of constraints here in the currents. So if my users are only 10,000 users, I should not go and try building a system for 10 million users, yeah? It does not make sense from the economics perspective. So I think good engineers are those people who actually take all these things in consideration.

Henry Suryawirawan: Wow. Really interesting perspective on how you hire engineers. I like the will and skill attributes. And also sometimes like contradictory, right? Good engineers, pessimistic but also optimistic and also realistic. So it’s like a different spectrum altogether.

[00:27:06] Hiring Engineering Managers/Leaders

Henry Suryawirawan: How about specifically for engineering, maybe, managers or mid managers or the leaders. Are there anything different on top of what you have shared just now?

Manoj Awasthi: So for engineering manager and leaders, there is one entire new dimension that goes on top of it. One is, yes, I mean, details are important. Engineering leaders should not shy away from details. I have seen that happen often early in my career. Engineering management is a very difficult job, because as an engineer, I think when you come for work, end of the day, when you leave from work, you feel very satisfied. Oh, I solved so many bugs. I wrote that algorithm. I improved this performance and so on. Engineering manager does not have this kind of pleasure. They come to the job, end of the day, they ask themselves, Oh, what did I accomplish today? I just did this meeting, that meeting, and so on. But those meetings are very important.

When I look for engineering leaders or engineering managers, I’m looking number one, that they understand this motivation. What is the purpose? So they do their management well, which means ensuring that work is being managed. At the same time, people are being taken care of, and at the same time, there is a long-term vision that is in their mind. Another thing that they must do is they kind of become the guards of the values that company believes in. So different companies actually have different value systems. Ensuring that we are aligned towards a common goal. So those are some of the things that I look for when hiring leaders. People aspect is one. Details are important. And they must know how to manage that ambiguity.

Henry Suryawirawan: When you mentioned about guarding the values and goals, and you touched on a bit also just now, about building a culture that aligns together with the scaling of the people. Because when you hire a lot, obviously, the way of working, the perspectives, the values are different from all those new joiners.

[00:28:47] Aligning Culture

Henry Suryawirawan: Maybe let’s move on to the culture, right? How do you actually align? Try to align people to think the same, value the same, ways of working are the same. This can be challenging when you grow into hundreds, thousands of engineers, right? Maybe share some tips on this.

Manoj Awasthi: Oh, definitely. Before I jump to answering your question, one thing that comes to my mind. Tokopedia has been very successful in generating more and more leaders who grew organically from within the organization. So if we can grow from within the organization, we should actually definitely grow. And there is no glass ceiling, irrespective of which geography you’re coming from, what background you’re coming from. There is always a career path for every single individual in the organization. So that helps a lot. But, again, it takes a lot of effort. It takes a lot of coaching, trust, building those competencies, and so on.

So coming to your question on the culture. Every organization has a mission, a vision. Every mission actually has a certain set of values. So living those values is super critical. Even as an engineering leader, you must ensure that number one task that you have to do is, you are living those values. You’re talking about those values on every opportunity that you get to talk to your team. It should actually become kind of a day-to-day affair. This helps a lot in alignment. Whenever there are decision making, probably you can align to your values and see and make the decision easily. There’ll be less confusion. For example, Google is actually known for their values of say transparency and innovation. Amazon is known for their, like, 14 leadership principles. And they actually become kind of a guiding force, a guiding light for you for making your decision. So that is one.

The second is, building a strong tech culture requires you to actually have a focus on tech as a core part of building products. That means people realize that those tech platforms are very important. You’re not taking shortcuts, but if you’re taking shortcuts, you’re actually relying on your tech leaders to go and solve those problems, and you get that support from entire organization. Second is, I mean, enabling your architects or ICs to become kind of guards of your design and architecture. When I’m saying that, it does not only mean that, okay, you give them the responsibility for becoming the guards. You also make them accountable and ensure that this is publicly shared. So the business and product, you just know that they have to ensure this aspect. Then celebrating not only product releases but also technology improvements, which may not show up directly, but are always adding to the customer experience, is also very important. So some of those are the things that we can actually do on culture aspect.

One more thing is innovation. We find many companies talking about innovation a lot. I feel that innovation cannot happen until you deliberately go and prepare a ground for innovation. Basically, innovation is you are motivating your engineers to go and find or invent a better way of solving a problem. The problem has been there, but strive to actually find a better solution, a more novel solution to solve the problem. Now, this cannot happen if they’re actually rushing from one sprint to another sprint, barely able to finish the story points. So they have to find some slack. Your team should actually kind of achieve that state where they’re shipping so many products, they’re taking care of their tech debt, and they still find some time to kind of be at themselves, do some free thinking. That is the only way to actually foster that process of innovation.

Henry Suryawirawan: So sometimes, these innovations can be challenging, especially when you grow very rapidly from a startup to become a scale-up. So everything is about product features, building more things for the products and business. But yeah, I mean, slack time is definitely probably a luxury for some of these companies. Thanks for reminding that sometimes when you want to breed innovation, you need to deliberately prepare the ground, the environment and the culture so that people are not afraid to give it a try. The key is probably slack time, not just focus on just doing delivering work.

[00:32:25] Engineering Governance

Henry Suryawirawan: Also, another thing that I want to touch on, you mentioned about governance, standardization of tech stack and things like that. So maybe there are some lessons learned from you. What kind of engineering processes or maybe some kind of governance that people like senior engineering leader, they should be putting a discipline on? So we touched on a little bit, but maybe are there any other areas for engineering leaders, what things to standardize or govern in terms of engineering process and best practice?

Manoj Awasthi: I think I made a bunch of solutions for engineering leaders. I think governance is very important, especially on the standardization stuff. Tokopedia did it very well, from early on, centralizing some of the things will actually help. I mean, this may come with some pain. Our team wants to try this fancy new database and then also a risk item is that will you actually become closed to the new ideas, new developments and so on? So, it has to be balanced, and there has to be a process. So it’s not about closing something, but rather just building a process around how will you introduce a new technology in the stack. What are the pros and cons of that? Do you have enough expertise on those technologies? Or you think that you can build enough expertise in time to come. If you actually go through the process, I think we’ll actually have lesser pains in future. So that is what I believe.

But then, there are a couple of other things that are helpful for engineer leaders that I want to share from my own experience. In fact, as I graduated from Tokopedia, I received a thank you note from one of my leaders, and he also shared some feedback for me. Those feedbacks were so apt, because they were also in my notebook as a feedback for myself. For example, delayed decision making. Sometimes you get into that conundrum that, I want to make a right decision, but the right decision is not so easy to actually come to and you basically delayed that until I get to know what the right thing is. I just delay it. I think it hurts more than it helps here. As an engineering leader, I think a lot of people will be blocked on you. They will actually be waiting for you to actually take a call and maybe you are just kind of not arriving at a decision, and that is hurting the organization, not helping them.

So I will suggest that for engineering leaders, and it is a note to myself as well, take decisions sooner than later. I mean, every decision will actually have pros and cons, but taking that decision will only fasten the process. You can always go and learn. The only thing that will be an exception to this is a fatal decision. But if that is a final decision, then you should actually go and reach out to other stakeholders and take help from others. The third one is that not asking enough questions. The cost of asking a wrong question is literally zero. In the worst case, people may laugh at you or they can basically correct you. They can say that, okay, that question is invalid and so on. But that is a zero cost. We should not take ourselves too seriously. But the cost of not asking questions, especially important questions, is very high. So we should definitely be asking more questions rather than not asking enough questions.

Last point that I want to share is that sometimes we underestimate what can happen by having a non-work setting for building relationship with our team. I mean, getting that team out for lunch or dinner or outing or whatever. So sometimes what happens is that your one-on-ones, however good they are, they’re not able to capture the trust as much as it is in the non-work settings. Those are like bunch of things that I would like to suggest based on my journey so far.

Henry Suryawirawan: So I think I like the perspective of not delaying decision too long, especially in engineering. A lot of things are, like what you mentioned, tech debt, it was just lying around, waiting for things to happen one day. I think normally when the day happens, it’s probably too late and it will be quite chaotic from the engineering point of view. Thanks for sharing that.

[00:35:58] Maintaining Engineering Productivity

Henry Suryawirawan: One last aspect that I want to touch on from your expertise and experience as well, it’s about engineering productivity. So we talk a little bit about engineering productivity, like when you grow and scale, we build a lot of features. How do you ensure things are still moving fast? Because what tends to happen as the organization grows is that engineering velocity is deemed to be slower and slower. Maybe from your experience, what key things that you probably control or maybe you improve in terms of how engineering can be always delivering values in a constant stable manner?

Manoj Awasthi: I think to answer that question, I mean, one, I personally do not believe in measuring developer velocity or productivity as a number. I don’t think there’s any way we can actually assign a number to people that, oh, you are productive at this number, etc. That is very hard and I think it’s a futile exercise, honestly. We can definitely find out ways to actually move faster. As I said earlier, speed, quality, and agility. Those are things that we want to aim.

Like in Tokopedia also early on we adopted some kind of organisation structure. The way we organize ourselves, it was based on tribe system. It is originally coming from Spotify. There are tribes. There are chapters, and they actually work together as mini startups. So every tribe will actually consist of representatives from tech team, the product team, and the business team, and they work together. So it becomes a mini startup, which has a similar mini vision to launch the product that they’re working towards. They work in a fashion and they can adopt a process from Agile world like Scrum. That is one way to actually go and put in place a very deterministic, a predictable setup for the teams to actually function in. So that has worked well in my understanding.

Most of the time, when I found that there are release delays, I think one of the root causes is always communication. It’s not communicated well enough. So communication is one thing that has to be solved at a significant priority. Now when I say communication, there are two kinds of communication. So one is a verbal communication. It is important, but it should be generally written communication that should be mandated. As you go towards that you’ll probably find that a lot of these problems of misunderstandings, they go away. One company that I respect a lot, and we can actually all borrow a lot from, is Amazon in that aspect. They have set up a writing culture, which is worth emulating for most of the companies. So I’ve spoken to ex-Amazon people from Seattle, from India, and I find similar kind of culture. So Amazon really has done a great job in establishing that culture across the geography.

And then, how can you actually make it further better? Automate like crazy. Things that can be automated must be automated as soon as possible. In Tokopedia, in fact, there is a team itself which is the engineering productivity that works on building tools that can actually help us have a sustained level of quality whenever we are making releases, which is test automation, but also having, say, a stress tester automation to ensure that we are actually reliable at a higher load. Then there is a tooling for developers to be more productive.

Henry Suryawirawan: Thanks for sharing some of the tips. So automate like crazy. There are so many things that can be automated these days. There are so many tools already built, in fact, offered as a SaaS product or maybe open source tools. So yeah, you should probably always find innovative ways on introducing automation.

[00:39:12] Sharing Lessons Learned

Henry Suryawirawan: So maybe throughout this journey, any kind of mistakes or expensive lessons that you have learned along the way, if you can share some? Is there anything that you can share, Manoj?

Manoj Awasthi: I think I already shared that as part of my addition to engineering leaders. Expensive mistake? I regard that only at the delayed decision making. It has been pretty expensive, I think. We could have just taken a call and proceeded rather than waiting for that.

As you become a leader, and especially working in an organization which has multiple functions, communication is another key that you need to get a hold on for being more effective. For example, in 2018, Tokopedia started this shopping festival. And this was first time us doing it in Indonesia, and there was no other company doing it. This was basically like a replica of Singles Day in China. We were going live on TV. We basically prepared our systems to scale well, and we estimated that, oh, our target will be like 10x traffic, 10 times what we receive at the current peak. The traffic that we got during the event was more, not 10x. So our systems were failing, and I was like really in shock. Later on, when we did the root cause analysis for that, basically it was bunch of things. Including one was misestimation, of course. Since then, of course, teams have started working on how can we better estimate the business impact? What kind of traffic will we attract when we do this or that?

The second was basically having more and more transparent communication between product, business, and technology. That is very beautiful thing in Tokopedia now that I see. All the teams actually sit together in one meeting and there’s one communication happening. A lot of processes were introduced after that. For example, we introduced very regular kind of a load testing, which is called BLT there. Huge effort on auto scaling and huge effort on automation that happened. Those are some of the learnings. And since then 2019, 2020, 2021, 2022, we have done the same event at the same scale or larger scale, and we have not faced any trouble thanks to the leadership at Tokopedia.

Henry Suryawirawan: Wow. Couldn’t imagine myself as well, like when you predicted 10x, but it turned out to be more of 10x So it’s wow. It’s really challenging.

Manoj Awasthi: It’s a good problem to have, honestly. So at the end of the day, I basically spoke to a leader that we are so sorry. I mean, we mispredicted. But this person from business said, Oh, no worries. I’m so excited because this tells us how big the opportunity is to serve people in Indonesia.

Henry Suryawirawan: Thanks for the plug, because, yeah, I think during this kind of like crisis situation, the empathy from leaders, right, not blameful kind of culture. I think that’s really key.

[00:41:39] 3 Tech Lead Wisdom

Henry Suryawirawan: So Manoj, it’s been a pleasant conversation. Unfortunately, due to time, we have to wrap up pretty soon. But I have one last question that I normally ask for all my guests, which is to share your version of three technical leadership wisdom. Think of it like advice or maybe something that you want to tell to the audience from your journey or your experience.

Manoj Awasthi: So I essentially told my leaders at JULO as well. These are all things that I learned over time. The first one is that done is better than perfect. Don’t wait for the perfect solution. So perfect is the enemy of the good. That’s another way you can quote it.

Second, is that the more you sweat, the less you bleed. During peace time, generally, people think that, oh, we can actually delay our tech debt. Nothing is breaking right now. We’ll actually pay it later. That is not an approach that you should take because one day there’ll be time of judgment. Karma is a bad bitch there. It’ll bite you when it hurts you the most. So, instead of that, especially when you have some peace time, you can actually focus on strengthening your platform.

The third one is that teamwork is the ultimate competitive advantage. This is what I’ve seen time and again. The winning teams, even if it is not comprising of A players, they will win against A player team if they have better teamwork. That I’ve seen time and again. So you’ll find this in sports, you’ll find it in industry as well. Teamwork is the foundation of all the success. Teamwork cannot come without trust. So that’s why I believe that, especially engineering leaders, they must actually work on establishing that trust amongst their team members and aligning them towards one common goal. So those three things there, Henry.

Henry Suryawirawan: Thank you. I like the way you explain it, right? So done is definitely better than perfect. Sometimes, engineers tend to want to build things perfectly, right? So you will think about all scalability patterns, architecture, there’re complex microservices in hundreds. So sometimes we should not go into that perfect mode. Just build good enough for the current context.

It’s been a pleasant conversation, Manoj. If people want to continue this conversation with you, is there a place to reach out or maybe interact with you online?

Manoj Awasthi: Oh, definitely. I’m available on Twitter and on LinkedIn. How can I share that with you?

Henry Suryawirawan: Yeah, I’ll put it in the show notes later on, don’t worry. So yeah, thanks again, Manoj, for spending your time in this podcast recording. I really enjoy this conversation. Hope you feel the same. Good luck for your next venture.

Manoj Awasthi: Thank you so much. Thanks for having me here. It was great talking to you. It was great conversation.

– End –