‘Leading Tech Teams from 0 to 1’ with Peter Kristianto Widjaja, Co-Founder and CTO at Hubble.Build

Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. I’m back with another episode and a new amazing guest who’s an entrepreneurial soul from Singapore. He’s the CTO and Co-founder of Hubble.Build. And also, he is one of the youngest leaders so far on the podcast. Great to have you here, Peter.

Peter Kristianto Widjaja: Hi. Hi, Kovid. Hi, everyone.

Kovid Batra: All right, Peter. Thank you for coming on the show. And, as a usual format, we have this quick fireside chat with every guest of ours. And here, we would be knowing a little more about you personally. All right?

Peter Kristianto Widjaja: Sure. Let’s go. Let’s do it.

Kovid Batra: Perfect. Perfect. So, let’s get started. All right. So, tell us about your first production blunder.

Peter Kristianto Widjaja: Oh, hmm, okay. Well, production blunder…I guess it’s when the company was still small, right? So, it’s about 2017, 2018. We were running a very small engineering team, about three people. Everybody doesn’t know what’s a good engineering practices and we really prioritize speed over other things, you know? And, some of the points, you know, there’s some bugs on productions that happened. And as a CTO, obviously I have production access, I’ve root access last time to everything, and we tried to make a very quick fix for our customer because it was a business critical issues and it made things worse. Classic, right? And yeah, the customers scold us for a good few hours, the CEO has to hear all the customers making noise to us. And yeah, yeah, that’s pretty much, you know, and then we learn our lessons and then we know, “Okay, no more”! Right?

Kovid Batra: How many calls did you get from the customers that day?

Peter Kristianto Widjaja: How many what? Oh, oh, dude, don’t, I mean. I guess it’s just… okay, the good thing, it was, we’re still small, so it was just one customer, but it affects a lot of users within that customer. But, yeah, we have to say sorry for about 2,000 times that day, I guess.

Kovid Batra: That’s the best thing you could have done.

Peter Kristianto Widjaja: Yeah, I mean, but we managed to, I mean, we have backup. Luckily, we have backup, so we managed to sort of roll back things. But it took a while because everybody was not seasoned, yet at that point, yeah.

Kovid Batra: Sure, sure. I mean, I see that there’s a lot of energy, you’re young, but still, there must be some daily kick for you, daily source of energy that gets you through work I would love to know about that.

Peter Kristianto Widjaja: I mean, obviously the first thing in the morning is a cup of coffee. So, you get your caffeine kicks. That’s the first thing, the most important thing for all engineers. Well, I’ve been doing this with this company for about, six, seven years, right? Since it started. Obviously, you know, it takes a lot of things to keep it going. And, you know, sometimes you have just no motivations to wake up and like, you know, the same things that you were building a few years back, it was still at a stage, you still need to do something. But for me, it’s the people, right? So, we have grown so much that now I have a lot of people in the company, and you know we are doing great things. Everybody’s so talented in the team that it just makes you feel like, you know, it’s fun, right? Because everybody just heads down, talk about ideas and implementing it. Obviously, there’s the not so fun part about, like deadlines and all those things, but yeah, I mean it comes together, but it’s fun.

Kovid Batra: So, it’s people for you then.

Peter Kristianto Widjaja: Yeah, it’s people.

Kovid Batra: Perfect, perfect. All right. One last thing. What’s your favorite go-to video game?

Peter Kristianto Widjaja: Well, I’m an old-school guy. So, I still play Dota pretty often, and not that often, but it’s too often for my wife’s liking.

Kovid Batra: Got it. 

Peter Kristianto Widjaja: I should… You know, yeah, well, yeah. 

Kovid Batra: Well, great then! Great. Perfect. So Peter, this was great knowing you. These were some fun things that we got to know now. Now, moving on to some important substance. We know what Hubble.Build does, but for our audience’s sake, first of all, I would love for you to tell them what Hubble.Build does. 

Peter Kristianto Widjaja: Cool! So, Hubble.Build- we are a construction tech startup. We are based in Singapore. We are mainly providing a lot of solutions, B2B SaaS, especially for the different construction companies, here in Singapore and Southeast Asia. We’re looking into essentially digitizing, automating, and obviously at the end of the day, doing more of insights, for our customers. Yeah. So, it ranges different operation and verticals in the industries. 

Kovid Batra: Thank you. Thank you, Peter, for that introduction. So, now my question is, I personally have been an entrepreneur. I have seen that journey, but unlike you, I mean, this journey of 0 to 1, my experience is a little less than you. So, I would love to hear your experience, how it has been starting from a garage, because last time when we were talking, you told about this. It was just three members and now scaling it up, having around 40 dev members. So, this is definitely a journey and it’s almost been a decade for you into this, right? 

Peter Kristianto Widjaja: Yeah. Yeah. 

Kovid Batra: So, how has it been? Let’s start with some of your best experiences of this journey. The most challenging experiences of this journey. 

Peter Kristianto Widjaja: I mean, you know, as a Co-founder/CTO, starting with three people and now you’re leading about 40, the whole company is about 70, 80 people. It’s about that transitions of like, you gotta, I would say adapt, and your role keep changing as the team grows. You know, when, when we started with three people, essentially I’m an engineer, I have to code, right? Everybody, like me and my, one of the other engineers, we have to code and I have to go deep into the backend, the frontend, everything. Every day is about code, code, just keep developing and launching new products. When in which 10, it’s about being a team lead and a manager, right? So now, you have these 10 people and you gotta make sure they are happy and everybody is aligned with what they are doing. Now, you grow into 40, it’s a different ball game by itself. And, each transitional period needs a lot of self-reflections, and also just humility just to know that, “Okay, I’m not good at this. I gotta improve on this.” But, if you are the person that, say, likes coding, right? At, you know, 40, you’re not gonna code most of the time, right? So, you gotta be like, okay, you know, you pick your poison. Obviously, you still can code outside of your most responsibilities, but you have to understand that your main responsibility is not to code anymore, it’s to inspire and direct the vision of the team. So, I guess, I guess that is the most challenging part Yeah. 

Kovid Batra: Doing that transition from being an engineer to a leader is definitely a transition. 

Peter Kristianto Widjaja: It’s crazy. 

Kovid Batra: And, I think it doesn’t come easy, particularly with the engineers, right? They have this habit of just coding, being with their laptops and desktops. So yeah, it definitely is. So, let’s talk more about some of those incidents where you actually had to change your daily habits or behaviors while you were working as an engineer to a leader today. Let’s talk about those, some of those challenges.

Peter Kristianto Widjaja: Yeah, yeah, again, I guess the journey from 0 to 1’s and obviously 1 to 10’s is going to be very different between, you know, one community to another. For me, um, it’s when I think we reach, let me count, 1, 2, 3, 4, 5, 6, about 6 people in the engineering team. That’s when, you know, I’m still heavily coding and then what I realize is that people are just doing their own things, right? And, there’s a lot of miscoordinations with regards to what we are building, how we are building it, and somebody got to take charge, right? Somebody has to make sure that, you know, we do have product managers at that scale. So, somebody has to lead the product, talk to the CEO, most likely the CEO leads the product, right? But, you know, but the CEO also has to do sales and all the other functions. So, somebody got to step up and make sure that there’s a lot of coordinations and we are building the right things at a point in time, you know. I guess that’s sort of the trigger and like, “Okay, I can just keep coding. I got to, like you know, do something else, and should I hire someone to make sure that I don’t need to put that much anymore?” That question start to come to mind. And, you will realize that because you feel unproductive at the start, that’s what I felt, when you know, you’re not really code anymore, you don’t write anything, you’re not developing anything, but you’re just talking to people, writing some documentations, you know, setting up infrastructures, talking to AWS guys, you know, all these different people. 

Kovid Batra: Right. Right. 

Peter Kristianto Widjaja: And you feel like, “Hey, I’m not producing anything.” But, you realize then, your team actually is moving faster, because you’re building the right things, everybody’s on the same page, everybody’s happier in general. And that’s, I guess, I guess that’s a trigger for me. And they’re like, “Okay, I guess that’s how my role has changed.” Yeah. 

Kovid Batra: No, it makes sense. Actually, there is a point when you start leading teams, the motivation for you is to make them work without any friction. You start working as the oil for the team. So, your efforts start becoming the oil for the team and that’s what your daily motivation should be. So that’s cool. I think I can totally relate to it. 

Peter Kristianto Widjaja: Yeah. Yeah. 

Kovid Batra: Perfect. Perfect. All right. Apart from this, for Hubble, I’m sure that this journey of 0 to 1 involves this very important step, which we call as ‘product-market fit’, right? 

Peter Kristianto Widjaja: Hmm. 

Kovid Batra: So, back in that, like 10 years back actually, when you started this, what was the landscape like? Why did this idea come up and how did you figure that out that, “Okay, this is something that the market needs and this is what we need to build.” And, how as a technical Co-founder, you contributed there, because that’s a very important piece. A lot of engineers, a lot of technical Co-founders skip on this step of realizing that how they can drive the business impact. So I would love to hear that from you, how you did that in that 0-to-1 journey. 

Peter Kristianto Widjaja: Yeah, Well, it’s gonna be quite a long story, but you know, I’m trying to… 

Kovid Batra: No worries, we have time!

Peter Kristianto Widjaja: Yeah, I tried to make it, you know shorter for this. So, we started out actually just building different projects. The company was not building what we are building today. So, we are more of like an agency at the start, you know? So we’re building different things, right? And, one of it was for constructions, and that time was more for manpower tracking. We got this from a construction company, obviously. And that’s when, you know, as we’re building it, we’re realizing that, “Hey, the solutions in the market are not that great.” Right? There’s opportunities… I thought, you know, it was kind of, when I look at a product, I was like, “Hey, I think the market should have this kind of solutions already.” Right? It’s just natural. But again, construction is very backwards. Even until now, it’s sort of at the same level with agricultures, and like mining industries, and all those industries. So the adoption of new technologies is taking a while. So, it started with a real problem. So, we’re not inventing a problem, it’s actually a problem in the industries, and I was just making sure that the product actually solve that problems we are highlighting the values. And with that, we start entering the industry, we talk to more people and realize the bigger issues of things, like really there’s nothing that is automated, there’s nothing that is digitized, everything pen and paper. And, we can’t really do anything because there’s no data for us to do anything right? So, the first step is to collect those, create infrastructures for people to at least have a digital space and database of things. And then, we can start doing more things and enhancements on top of it, like analytics and all those productivity stuff. Yeah. 

So, that’s sort of how it grows. So, it’s pretty organic at the start. Again, we didn’t take venture fundings or like institutional capital funding at the start, until about 2020, that’s when we get our Series A. Before that, we’re just really reinvesting on our profits, so, we really grow organically by talking to the users. And, what we realized is that everybody got to talk to the users at the start, right? And, this is what I preach, or not I preach. This is what I sort of try to envisage in the company as well. As an engineer, you got to know what you’re building, right? 

Kovid Batra: Yeah. 

Peter Kristianto Widjaja: And it, it, it’s not, you know, we, when we hired engineers we take time to sort of make them realize that it’s not just about doing the tickets that the product managers create for you, right? A lot of people, when they come in, they will just like, “Okay, I have this ticket. Let me just do it. I read it. I’m done. Push it. Somebody reviews, merge and stuff.” But, it goes beyond that because you need to know a few things, right? You need to know who you’re building it for, who’s going to use the product. And, what is it for? And, why they need it? Because the way you build it is going to be different, right? And, my point is that, yeah, you can have your product managers, product designers, and you know, they all work so hard to figure out the user experience and all these things. But, as the engineers, you need to really understand what you are building as well by talking to the PMs and the UI/UX about what they have been writing and designing. And then you build it in a code, right? In our company we call it the ‘purpose-driven values’. It’s one of our core values that we always talk about. So, essentially what I did now is, I just do some random conversations with my engineers and I’m sort of, I ask them like, “Hey, what’s up?” “How are you doing?” “Okay, what are you working on today?” And then they will, like start explaining what they’re working on and I’m like, “Oh, why are we building that?” And, if they can’t answer, I’m like, “Okay, you go and ask your manager and you get back to me.” So, there’s a bit of, you know, just random checks here and there. The one answer that I hate, that I always tell them I hate is that when they say, “Oh, because whoever says I need to build this.” Or, “PM wants me to do.” I’m like, “Dude, okay, figure it out.” Right? 

Kovid Batra: Yeah. 

Peter Kristianto Widjaja: Yeah. 

Kovid Batra: No, I think this is really amazing. And, with all the previous conversations that we have had on this podcast, this has been highlighted multiple times. This purpose-driven building from the engineering teams has to be, like ingrained. That doesn’t come naturally in the dev team.

Peter Kristianto Widjaja: It’s not, yeah.

Kovid Batra: So, it’s a very good point that you understood and realized it as a Co-founder in the early stage and then you could actually, okay, preach actually in the teams and then make sure… 

Peter Kristianto Widjaja: Yeah. 

Kovid Batra: It’s, it’s kind of that only, and it’s really cool. I think this is one amazing thing which every tech Co-founder should keep in mind, and should make sure how things are proceeding ahead. Amazing. Amazing, Peter. 

All right. And now, there is something which I would love to know from the current scenario. So, now you’re 40-devs teams, right? 

Peter Kristianto Widjaja: About that, yeah. 

Kovid Batra: One thing you already mentioned that you are trying to bring in that value of purpose-driven development, right? 

Peter Kristianto Widjaja: Yeah. 

Kovid Batra: But, there are more aspects when you have to handle a 40-member dev team, right? 

Peter Kristianto Widjaja: Definitely.

Kovid Batra: You have to take care of their experience, you have to take care of their well-being, you have to take care of whether they are being efficient or not, because on day-to-day, even if you align them with the business goals, you give them those values. Still, you just need to like make sure how things are moving. 

Peter Kristianto Widjaja: Yeah. 

Kovid Batra: Are we really moving on the right track or not? Because sometimes you tend to deflect, right? 

Peter Kristianto Widjaja: Yep. 

Kovid Batra: So, in simple words, how do you measure the overall well-being of your teams? That’s my question 1. And then, how do you ensure that they are being efficient at the same time? So, that’s a thing that we would really need to know. 

Peter Kristianto Widjaja: Yeah. Yeah. I would say that’s a million-dollar question, right? You know, I mean there’s a lot of literature on that. I mean, the infamous literature from McKinsey, you know about it. It’s tough, right? Because we’re trying to measure something that is intrinsically hard to measure into something that is chewable as a management to just see. But in, in Hubble, essentially we are looking at a few things. So, one is obviously the team structure itself, you know, how we put the different middle managers and make sure that they’re not overwhelmed with, like 30 people, for example, like one person leading 30 people. So, we always keep it about 8, a maximum. Yeah, it’s about 8. Max is 8. Some people are definitely less than that. And, make sure that everybody knows that you can talk to this guy about anything. So, that’s the first one. Second, well-being… So, we have two approaches here, right? So, one is what we call the metrics and KPIs. And, second is the qualitative, right? So for qualitative, we do this thing called the 360 evaluations. And, this is obviously something that we built with HR in terms of like, “Okay, we need to have these routine checks, 360 evaluations of all the people.” So this is actually the only time for individual kind of measurements. And, when we talk about KPIs later, everything is at squad and team levels, there’s no individual metrics. Right? So, the only individual evaluations that we get is from the 360 evaluations. And, this is where people will, okay, how can everyone improve, right? So, the idea is not to rat people out that they’re not doing their job, but it’s more of like how each one can improve, what they feel they’re doing well, what they feel they need to improve, and what they feel they need to be stopped doing. Right? And it includes me. 

Kovid Batra: Can I ask you a question here? 

Peter Kristianto Widjaja: Go ahead. 

Kovid Batra: Sorry. It’s just that I’m too curious to know a lot of things. When you say that you’re doing this 360 at the individual-level, do these people know that when this feedback is collected, their names would be there along with that? So, let’s say, I’m one of the developers in the team. 

Peter Kristianto Widjaja: Yup. 

Kovid Batra: I give you my feedback around all the questions or survey questions that you ask. So, do I know that my manager would know that this is a feedback from Kovid? 

Peter Kristianto Widjaja: Ah, no. 

Kovid Batra: Perfect. 

Peter Kristianto Widjaja: Okay. So, the way, the way it goes is this. So there is the, what we call the manager feedback. So, the manager gives feedback to the team, the individual people in the team. That is obviously transparent because the manager has to say to the team. 

Kovid Batra: Ya, of course. 

Peter Kristianto Widjaja: And then, there is the peer review, which is between the team members. And then, there’s the upwards review, which is team members evaluate the managers. 

So, for peer review and upwards review, it’s all anonymous. The only one that knows is the HR, and then basically, HR will come up with this report, which is just the evaluations and the summary of all the different scoring and the qualitative feedback, but the names are not all there. Yeah. 

Kovid Batra: Got it. 

Peter Kristianto Widjaja: So, the idea is that, again, we want a very candid, very open. 

Kovid Batra: Exactly, that’s what the point is that if they know that this is going to be, uh, non-anonymous, then they would hide away the real facts, they would not come up with things. So, that’s what my concern is. 

Peter Kristianto Widjaja: The thing is this though, sometimes with the qualitative feedback, because you’re so close to your team, you know how they write. 

Kovid Batra: Ya! That’s definitely there. 

Peter Kristianto Widjaja: So, I mean, I was, I was reading my own feedback because I get my managers to feedback to me and I’m like, “Oh yeah, this is from this guy.” Like, I can really figure it out from the way he write, but again, like we established such a relationship that is okay. 

Kovid Batra: Exactly! 

Peter Kristianto Widjaja: Like, that culture has to be open enough that I tell my team, even like anyone can say, “Hey, you have feedback from me. Just drop me a message.” I’m okay. Obviously I can say that, but it’s still, you know, there’s so many of them, but… 

Kovid Batra: Yeah, I totally second that. 

Peter Kristianto Widjaja: With your direct reports, you’ve got to have that kind of relationship, because if not, there’ll be politics involved, and you know, people are not saying things that they really feel. It’s gonna trickle something. Oh wait, it’s sort of deviate from the question, but yeah. 

Kovid Batra: No, I think this is very important. This detail is actually important that even if you put in systems and processes in place to measure the developer’s experience or measure their well-being, it is important to understand that the underlying psychological safety in the teams is very, very important. 

Peter Kristianto Widjaja: Yeah. 

Kovid Batra: Otherwise, the truth will not come up and you will not be able to identify the problem. 

Peter Kristianto Widjaja: Definitely. 

Kovid Batra: So, I think this is a very important point. You have to, like promote it as a founder, as a promoter of the company, you have to promote this culture also within the team, so, that totally makes sense.

Peter Kristianto Widjaja: Yeah. 

Kovid Batra: Cool!

Peter Kristianto Widjaja: I mean, we have like, so I enforce the managers to have to go, have this thing the 1-on-1s with the team members, and there’s also skip levels whereby I can skip level to the seniors or, you know, there’s the different structures of skip levels. And, the thing that I enforce is that the skip levels, you are not ratting people out because, you know, when you do a skip level, somebody want to feedback about the managers, right? To you. 

Kovid Batra: Right. 

Peter Kristianto Widjaja: Now, you cannot say that to your managers and, “Hey, this guy says this about you.” And, you’re like, “Yeah!” That’s very confidential between, you know, the two people. 

Kovid Batra: It has to be. 

Peter Kristianto Widjaja: Even 1-on-1s. So, anything within the 1-on-1 stage, within 1-on-1s between you and your manager, it doesn’t go out to everyone else. 

Kovid Batra: That’s cool. 

Peter Kristianto Widjaja: Yeah. Well, so that’s the qualitative part, and from there, actually it’s more of the, again, the experience. Is people happy? Anything wrong with the pay or with the career progressions, with the challenges? That should be, you know, we can spot it up through the 360 evaluations and also the 1-on-1s. With regards to performance though, this is the very tricky part because people like to know, like which engineer performs better than which engineers, and then there’s like, oh, line of code written. No, not exactly! You know? And the key thing is this, when we sort of build this, we need to understand the engineering culture itself. And, with software engineering, right, it’s a very interdependent team whereby you cannot just do things alone, especially at our scale, because, okay, when you build this, it might impact another team, it might impact the frontend, the mobile end, you have to constantly talk to different people, right? 

Kovid Batra: Sure.

Peter Kristianto Widjaja: And, it’s a very highly collaborative environment. If you start doing individualized metrics tracking, for example, story points completed by a person, I can get that metrics, right? I know exactly how to get that metrics. But if you start putting that as the North Star, people will not help each other. And actually, that will become worse for your company or for the team. So instead, what we are looking is actually the full team, the whole team philosophies, right? So, I’m not going to trickle down to individual guys, I’m just looking at the whole team. So, within each of y’all, doesn’t matter. So, y’all figure it out collaboratively, who is doing what, who is better at doing what. And basically, the numbers I’m looking at is the squad’s philosophy, and this is owned by the EMs, right? The engineering managers, for this particular squad, right? So that’s one, you know, we’re looking at.. Again, I’m not, then I’m not comparing between squad one, squad two, squad three, how come velocity’s slower? What I’m looking at is your progress, your trends. If suddenly there’s a dip, you’re slowing down, I want to figure out why. And the idea is not to penalize you, but let’s figure out what we can improve on. And obviously, because there’s a lot of things, like the kind of problem statements that each teams are handling is very different, the number of members are different, so you can’t really put a benchmark, “Oh, everybody got to achieve like 40 story points.” Like, it’s, it’s very, it’s, it’s nonsense. Now, what we’re looking at as well is, because one of the values again is accountability. We are looking at the number of stories promised, or like putting into the sprint versus completed, because what we want is, “Okay, we are evaluating on overestimations or underestimations.” You know? And, making sure that when the PMs, say, or engineers are not doing their work, you have a data, all right? And, how to improve on that. We are as well looking at things like ‘backs per stories’. So, backs per stories is very interesting. It’s something that we just really built the infrastructures. It’s more of like, because we want to increase velocities, but we don’t want that to hamper the quality, right? And with backs per story, it’s very interesting because you know if people are rushed. So, that’s what we are looking at. So, if you are rushed, you tend to just quickly get it out of the way, hack things out, but you have like 2,000 backs, right? 

Kovid Batra: Yeah, correct. Quality gets compromised there. 

Peter Kristianto Widjaja: So, Yeah. So again, and it’s for the managers to say, “Okay, I’m rushing too much.” Right? So, let’s work with the PMs or with whoever stakeholder’s involved to like, “Hey, my team needs a bit more time. We’re not going to hit it because everybody start doing things very fast. There’s a lot of bugs being churned out.” And, obviously there’s a lot of miscellaneous things like, you know, code churn rate, at the macro level. We have code review durations, which is sort of like, we don’t, like, a lot of the blockers was like, “Oh, somebody’s not reviewing the code.” You know? And stuff. And then we, “Okay, tell you what, let’s have measurement on this and how to improve the process for code reviews.” Something that is very interesting whhich is developed by my previous VP of engineering was the ‘commit push time’. 

Kovid Batra: Okay. 

Peter Kristianto Widjaja: So, at which time of the day the commit is being pushed. So, what we’re trying to look here, and as well as the line of code changes distributions. No, so, basically what happened with these two metrics, is that it requires a lot of context of what’s happening with the team. So, you cannot just put a blanket context, and then just, oh, if you are like, who is, like the most, the highest contributors with the lines of code? It’s not like that. So, the idea is that what we want to look at is technically just distribution of work, right? If you see that the line of change distributions is heavily skewed towards a single person, first and foremost, that person is a ‘bus factor’.

Kovid Batra: Yeah.

Peter Kristianto Widjaja: Right? And, are you relying too much on this person because maybe this person is so good, and you just dump every single thing on him? And it’s not distributing to other people. That’s one. Commit push time is the same thing. If you look at your engineering team and some people just keep pushing at 2 a.m., 3 a.m.. Are you being sustainable to that guy, you know? Are you pushing that guy too hard? What’s going on? Right? So, but again, some people like to work at that hours, you know? We can’t say, “Hey, you cannot push at 2 a.m.” That’s not gonna work. But it’s more, again, that’s why it requires context, because the managers will look at this and figure out, “Oh, wait, this guy, why is this guy constantly pushing at like 2-3 a.m.?” Then, he can engage, or that person can, the managers can engage, like, “Hey, are you okay?” “Why are you doing that?” “Is it your style?” You know? It’s more of that.

Kovid Batra: I think that’s, that’s pretty amazing actually, how with these metrics where you are trying to understand the efficiency of your team. At the same time, you are being very considerate about that they are not overworked, or they’re not, like doing things like that. So, that’s pretty amazing. And that’s a new way to look at some metrics.

Perfect. I think, one question here I have when you talk about the distribution of the work, right? How do you ensure, like once you identify, okay, like, this person is the one who is doing the maximum amount of work in the team, and, that can be done from various ways. One of them could be like how many one is doing the lines of code and for the team, what is the ratio, right? You can understand that. But, let’s say, you identify, what usually are your next steps? Like, how do you make sure that this thing gets better?

Peter Kristianto Widjaja: Well, technically it’s this. Firstly, what we need to identify, is this even an issue, right? So, once is that, if it’s just because this guy is super fast, blazing fast, then we can’t follow, “Hey, you cannot do too much changes.” Right? Now, if it’s actually an issue, this is when the managers and me, we gotta figure it out. And, what some of the steps is that we look at when we do the sprint planning, like how is the task actually being distributed, right? So, we want to know, it’s more of like, are we, as a manager side, relying too much on this guy or not, right? And obviously, then talk to the teams and the rest of the teams, and being very proactive and very intentional when we distribute a task and make sure that he’s not, like skewed in terms of the distributions, and ask him to chill sometimes, that works too.

Second is that sometimes there are things that comes ad hoc without the manager being aware of what’s going on, and because, you know, everybody’s on Slack, some people, like some designers or even myself sometimes is a culprit of this, you know, just text one of the engineers that I know is very reliable, and like have been working with me for a while, I’m like, “Hey, I spot this. Can you help me with this?” And then, he was like, “Okay, done.” Right? Aand more of those might translate to, you know, again, we only have X amount of hours a day, if you are doing too much ad hoc works, you’re not doing the actual product strategies, and, you know, pushing product forward. So, it’s more of that. And, it’s tough, right? Cause at one point you still want to make sure that guy is producing.

Kovid Batra: Ya, of course.

Peter Kristianto Widjaja: You know? But, you have to be very intentional because you don’t want at the same time, say, for example, you have a feature, call it feature A, right? And feature A has a lot of parts. So, what you don’t end up happening is that guy in charge of, if it’s a big features, everything about that big features. So, you have to be intentional about, okay, you work for us. Okay, let’s build this one for you and then give it to someone else. The idea is that you want another engineer to have context about that as well, such that when he is, say for example, sick or he’s on holiday, you are not screwed, right?

Kovid Batra: Right. Well, I think that totally makes sense and it answers the question really well.

Great! I think this conversation can take really long and we have so many areas to touch here. But, I think we will take a stop here. And, I would really like to thank you, Peter, for sharing your insights and thoughts about how to scale from 0 to 1, and then how to manage teams at this scale. This was really amazing. 

Any parting advice/words for our audience?

Peter Kristianto Widjaja: Parting advice? Take care of your engineers and they will take care of your product.

Kovid Batra: Amazing! Thank you, Peter. Thank you so much.

Peter Kristianto Widjaja: Cool! Thanks so much Kovid for the invite.