 Hi guys, so thanks for joining the session. So I think, since you're here, you're interested to know more, but how do you work with engineers, especially rock-tied engineers? And for some of you, I think some are already working with engineers, or some are already, maybe previously, you're an engineer. So you kind of know how is it like. And a little bit about myself, how I got into product management. So I studied here in this SRE, information systems and finance. So a little technical, but also good business. When I first joined the workforce, I didn't expect myself to be a product manager. But I was interested to know about strategy, innovation, and stuff. But then I realized that when I joined this graduate program at Singal, I was rotated into different teams. And one of my coaches said, maybe you should try it for that management. There was my last rule, I said, as a mobile finance team, doing product development. And then, unfortunately, from Ninja Man team, I never think about joining a startup that early. But I thought, why not? And especially in Ninja Man, not many people know that Ninja Man is actually a technology company. And that's what I wanted to be. And outside of that, I also tried to learn a bit of Chinese, even though I look Chinese, and some guitar. So I think there are three takeaways I want to share in this session. So one is, how do you identify the rock star engineers? And another one is, what are the frameworks, or maybe engagement tactics that you can consider when you're used to work with a rock star engineer? And third is, some general tips that you can follow. Actually, you can hopefully walk out of this room, and then you can consider using these three things. So one is, how do you show quick wins? How do you use this strategy called push and pull? And why is it important to invest in this thing called social capital? And before we start, I would like you to take a step back and imagine this thing. So this is the work where I work. Yeah, but anyway, this is the work that I work at. So basically, anyone have you received any parcels recently, like from Lazada, or maybe even Airsoft, or like? So there are a lot of different experiences and different things. But what's happening actually behind all this thing, behind this one small box? What are the things that people do? And how do they actually eventually reach your doorstep, or even maybe your collection points? So there are actually a lot of coordination required, especially in terms of e-commerce. So there are a lot of real-time coordination between different personas, different people, different stakeholders using different platforms. Maybe they use mobile apps on the driver's apps, and they use web page on the operator's side to identify where your parcel is, where your wish driver should take it, or which route, or how do you assign which vehicles. And there are a lot of system integrations with various partners. So it's actually very technical, because you don't just integrate with your e-commerce partners, but also even your fleet partners, even your retail store partners, where you do collection points, and so on. And unlike transporting humans, parcels cannot actually speak. So when there's something wrong, they cannot tell or complain to you, like, hey, I'm lost. I'm damaged, or your driver is doing something bad. So we need a very stable and very scalable system that can identify the parcel. Technically, literally, every second where they are, and who is handling it, or if something goes wrong, who should be, maybe, who should take the responsibility, or if something goes missing, where's the point at the last point, and so on. And we are in Singapore, and we are in Southeast Asia. It's a logistics nightmare. Volcanoes, you have islands in Indonesia, thousands of islands in Indonesia, Philippines, and there are a lot of different kind of customer segments, different kind of expectations from different cultures. So you have to localize a lot of things. So a lot of companies want to, you know, like, the deal with this business can end up actually in a catastrophe. So luckily, it is not where I work from. So this is like a warehouse that collects, and even in a manual process, a lot of things can go wrong. So imagine when you try to automate a lot of these things, there are a lot of, you know, edge cases that you have to consider. There are a lot of failure points that might happen. And big companies actually try to automate a lot of things, but even some big names actually fail. In this project, DHL lost almost $700 million, and they just tried it off because they realized that, hey, it's just too complicated to automate. And yet, in Japan, we basically use technology to differentiate ourselves. Basically, we started in Singapore in about mid-2014, and we focused on the last mile portion of e-commerce. And we are now in six countries, 40 cities and serving almost 120 million people. And this is all by leveraging on technology. And we built all this on the microservice platform, which requires a little bit more of a well-rounded engineers because they need to know how to handle its service by itself. And we also use algorithms to optimize things like the vehicle routing, capacity planning, scheduling, and so on. And yet, we only have 36 engineers across nine nationalities. So it's a very lean team actually, and it's, as compared, for example, to companies like the transport companies of Uber, they have like 2,000 engineers just to build one app. And we have only 36 currently. So we really have to rely on people, like engineers. And as the product manager, this is where you really are, your interaction of business, UX, technology. This is especially true for the SaaS companies, but for, and in Japan, it's a little bit different. So we are also, there are a lot of human elements in it. There are a lot of logistics and operations in it. So we are technically in the middle of logistics, strategy, customer experience, and even outsource technology. And as a product manager, I think your biggest value is, of course, is to champion the customer, to champion the user, to find out what is the biggest problem, what is the most important problem to be solved. And of course, as an engineer, actually that's also something that they can do, right? Technically, it's just, I mean, I'm shooting myself in the foot here, but it's technically all just common sense, but it's actually also, as a product manager, we are, but as a product manager, we have the opportunity to talk more to the users, to do more research, and so on, that's how we bring value. But when you work with engineers, also the tricky thing is that you don't actually manage them. You are working in a cross-functional team. They might be reporting to the engineering managers. They might be reporting to the VP of engineering. So you have to, what they call, the influence without authority. And so how do you do it? And first, let me suggest that not every tech engineers is actually the same. They have, of course, they have the basic things like the personality, the culture, the experience, their interests, their habits. But in this section, I will want to focus more on things that is called the rock star engineers who are 10x intellectual capacity, intellectual 10x productivity, 10x motivation. So basically these guys are those who are, you give one ticket and then you're just expecting them to, expecting normal people to complete within like one week, but this guy is just completing like one day and then like you say, what's more? And so good product manager, sorry, usually start with Y. And this is a lot of, this has been emphasized a lot in different articles like Y as a PM, you should focus on the Y and not the how. But in today's session, I will want to highlight that great product manager start with who. Because you cannot actually lead your people, you cannot influence people unless you actually know who you are leading, what are their characteristics? So how? So you can use this two by two metrics. Actually, when you talk to engineers, you can classify them into these four quadrants. First is in terms of their competence, they're always in terms of their commitment, in terms of their work, how passionate they are. So I'd like to give some example. Let's call this guy M. M is basically a very competent engineer in my company, but yet he's kind of, doesn't have the most, he's not the most committed person because maybe he thinks that he is smart, but then maybe he's a bit poor at what he is doing. So he just put the hours as nine to six, and that's all. And on the other side, you have people like I, K, or T, and then vice. So people like them are people who are like very competent, but also they're very passionate about what they do. Sometimes you give them a problem and then they will not just do that problem, they also think about other things. Oh, what if instead of just building this button, you can actually send an email so that you can tell the customer. So there's this kind of mindset. Or what if instead of doing this kind of a prediction algorithm, you can actually suggest based on the location of the driver. So they are very innovative and they are very, they take ownership of what they're doing. And also there are people who is like, see, it's very hard working, but I mean, it's good, but maybe not as good as I, K, T, but in the case of this, it's definitely something who are available in your team because sometimes you don't always have the most exciting problems in your company that needs to be solved all the time. Things like customer support, like maybe it's not so technical, but you need a hard working person in your team because requests will always keep coming in and you know, complaints come in and there are always things to be solved, but sometimes you just require things like checking the logs, find out what's wrong and maybe just ensuring that, oh, maybe this service is not really functioning well and then in front of the other engineers, that's all. And of course there are some other people who are in the fourth quadrant. So like I give a question, exclamation mark. So it's not that they are, they need to be fired, sorry. Yeah, fired. Yeah, yeah, you can, but yeah, you can fire that and they are, but they are, yeah, but they still actually work for your company and bring value. So you might not want to fire them that easily also because as later I will explain to you, like these people can actually be moved around the different quadrants. And here is where the Rockstar engineers are. High competence, high commitment. So how do you deal with them? So there are actually four different leadership styles that you can actually use when dealing with people. And it can be further differentiated by two factors. One is how directive you are and how supportive you are. Being directive means like you are being very, you know, to the point. Being supportive means like you give more feedback. Sometimes you give more expressive to the guide. So let's take an example of asking someone to go for lunch. You see your engineers to go for lunch. So being more directive, for example, like, oh, let's go to this place. That's all, like, oh, yeah, you'll just know it. But being a bit more, you know, less directive means like, oh, you know, I like this place and I haven't really tried and I'm a bit hungry now and it's 12 p.m. So can I, can we go there today for lunch? And there's got things. And being supportive is giving a lot of support, being more engaged with him or her. Like, so if you take, again, the example of going for lunch. So you will give a lot of more feedback like, oh, you know, I like you, I know you like this. How's the food and oh, you seem to be cooking the food quite well and stuff like that. Instead of just saying, oh, good, oh, good job. Oh, I don't like it, that's it, right? So again, there are four things. Directing, coaching, delegating, supporting. So directing means you're very direct but you don't necessarily give a lot of support. You just say that, oh, so you just say, oh, let's build this feature because let's just build this tracking function on the website but then you don't really necessarily go into that engineer's explaining, like checking in like every day for example, like every few hours you ask him or how's the progress, how have you faced any difficulties and so on. Whereas in coaching style, it's you will tell them like, oh, this is what we need to build, please do what X, Y, Z. And if you are not sure, please go talk to that engineer. You basically give more direction and at the same time, you also check in like, oh, have you at 3 p.m. if you come in like, oh, have you talked to this guy, did you face any issue at 6 p.m. You realize that, oh, how's the update on the feature and so on. And supporting is where we have a bit less direction to just give them a problem now. Build this, but then it's up to you, like you can just figure out yourself who you need to talk with and so on. Yeah. Yeah. Is there a mistake in this like, should we delegate into Rockstar and the engineers and be coaching loader like? Yeah, correct, you got the point actually. So actually, yes, for Rockstar and yes, it's a bit reverse. So you need directing, delegating, coaching and supporting. So what I realized is that when you work with Rockstar and yes, you need more of a delegation instead of for example, because it's a bit counterintuitive in a way that for some people, because in delegation mode, you are actually a bit on the side of a low direction and low support. Basically you just give the task and then you don't really give them feedback or don't really, you know, in Malay called sayang or like sayang sayang, or you don't really give them special attention. Because some, yeah. I'm not sure I understand the low support. The low support means you don't really, you don't really have to keep engaging them in a way that you don't really need to. For example, if you have a high support, you have to keep accompanying that engineer like keep checking in and so on. Yes. Yes. So some people say that, oh, actually for Rockstar engineers, you need more of a supporting strategy because you have, maybe the Rockstar engineers want more attention because they think they're special and so on, right? So, but I think what I realized is that using delegating strategy is actually more effective because sometimes the Rockstar engineers actually know that they are already Rockstar so they don't need the constant praise and so on. And also, sometimes it can backfire because they know that they are really good, better than the rest of the engineers in the company, but then when you feed them their ego, right, then they'll start, you know, or think I'm very special, I need like special, even more special attention. So like, in a way, using delegating is better to manage the expectation. Yeah, any more questions? It needs less attention. Sorry? The gate needs less attention. Yes, you just give them the task and then let them figure out. Yeah. So, just now, Charlie used this diagram to explain a built measure of learn. So, actually, I would like to also use this concept called who measure of learn because as I said earlier, people might change, especially in terms of the level of commitment that they have to your company and sometimes also in terms of their capability because maybe they figure out about new ways of learning things, new ways of investigating things and so on. So, the trick here is that you don't just stick with just one framework, but you always have to think, I have this in mind, like, oh, you first know the who you are working with and then you kind of measure what you have been doing, like, oh, is that guy really a rockstar or is that guy really is using delegating strategy, really work with that guy because maybe there are some other things that is the X factor you don't know because maybe they have other cultural differences or like experience and then it's different, maybe they are more used to certain way of, even though they are rockstar, maybe they are more used to certain kind of engagement strategy and so on. So, that's why you need to always use this framework, like, who measure of learn. And not just for rockstar engineers, but this also apply to them is that there are also three engagement tactics that you can consider. One is, of course, to show quick wins. So, for example, I think if you have, have anyone read this article, like, I think the top things that you need to do in your first 90 days as a product manager or something like that? Oh, so basically it's like, there's this very good article thing by Ken Norton, like, it's one famous product manager in the US. Basically, one of the things that he asked for someone who just joined product or even as a marketing product manager who just switched a role in the new company or a new team, one thing that you need to do is actually to maybe set up a one-on-one session as much as possible with everyone in your company, including your engineers. So, for example, when I joined in Japan, one thing that I did is that I actually talked to each one of the guys there to find out what things they are doing, what are the problems they are facing, how can I, in a way, make their lives better? And it doesn't necessarily work like from day one. For example, I realized that there's one, this very smart guy in my company who is one of the rock stars, in a way. He's very smart. He works, like, technically from almost 24 hours. You just ping him at 2 a.m. and he's still awake and he is always suggesting things. He thinks ownership and so on. And very smart people, sometimes they tend to judge you also, like, oh, is this guy, this PM, is this really capable guy? Or is this some random, who is this guy trying to intervene me from the user and stuff like that? So by showing quick wins, not just knowing them, but also to let them, like, oh, hey, as a programmer, you bring value, you don't just give requirements, but you also challenge the stakeholders. You ensure that everything fits into the company's big picture overall strategy and so on. And from there, you can gain their trust or their trust. And another thing is, what I borrowed from my boss is actually push and pull. So it's a little bit more like a flying kite here. So sometimes when you fly a kite, as anyone flew a kite here before, you can't just pull all the way. You have to sometimes pull and then let go. You have to pull, let go, and then that's how you actually make the kite fly higher and higher. So basically, it's the same thing with engineers or actually even when you talk to people in general. Because sometimes you need to set a really high expectation, make them feel a bit more stressed in a way. Like, hey, just give them a challenge. Hey, this is this. I know you can only do it in maybe a week, but let's try to do it in five days because you need a little bit of a bath. So give them more challenge so that they're more motivated in a way. But then at the same time, once they're there, you can also gauge again from the whole major lunch framework that, oh, maybe it's now becoming a bit more of a too stressed and so on. And so then that's where you can come with let go strategy. Doesn't mean you let go of the guy, but more like you give more attention, like, oh, maybe buy him food or becoming more of a friend, tell Joe and stuff like that. So play with the pressure a bit like, oh, high pressure, then a bit lower, high pressure, a bit lower. That's how we can optimize the performance. And the last thing is what I cannot emphasize more is that in social capital. So basically, at the end of the day, we are all working with humans, whether it's engineers or product majors or like UI designers and so on. So knowing your employees or knowing your colleagues beyond maybe just as a colleague, but also as a friend, as a person, it's very important. Like, you know, maybe their hobbies, maybe they have some personal problem, or their interests, their ambition, or their even, and also helping people beyond their KPIs. Sometimes maybe things that is not in your job scope, maybe you need to, the engineers are also overwhelmed and then you need help with some tweaks in the email design. Then you can just help them do some HTML and so on. Yeah, sure, it's like a barter in a way. So like, you know, build trust and then also build some good working relationship. And that also worked with the engineers because like, what my CTO said that sometimes when engineers work with product majors, they like people who are technical, who can understand at least what they are saying, but so that you can influence them, which way you can connect with them. But sometimes, even without that capability, they are still willing to work with you as long as you are, you know, they think that you are a good guy to work with as long as they feel that, you know, they are not working with some guy who thinks that he knows the user the best and so on. So basically, by investing in this social capital, it actually can help you to move things in your company as well. So, yep, that's it for my session. Any more questions? Is there not much questions? I actually have a major disagreement. Oh, sure. I can go back to the slide when we have, like, a different kind of engineers. Yeah, so say you measure the capital, actually lie, it's not here. Your capital is actually here. And why so? So first of all, I think we live in, like, a lot of variables out of the picture. That's why it might work in some companies, but it actually, like, greatly depends on the personality of a person from this area. And you put in, like, all the eggs in the same box so you can be, like, in great danger if you rely on these people. One of the big problems with these people is if they're 10 times more productive. So if they go astray for half degree, because they're 10 times more constructive, they can go really far from what your business is actually needed. Right. So by relying on this guy and delegating to them, you're putting your business in a greater danger. So what is found in my experience is actually you want to rely on these guys and delegate to these guys. So it can be risky, but because they understand their position and they tend to doubt more and they're asking more questions. And what it creates is they tend to communicate more with these guys with this high competence. They're sitting guidance on technology and therefore the result they provide in here because of high commitment is as good as the result provided here. But because there are a lot of communication, there are less chance that they go sideways because when you're talking a lot, you have to be aligned. So one person can be misaligned. Five persons, it's unlikely. And then again, because they're doubting their competence, they're asking you more questions. So they're getting better at business than guys who already knew the task, just go and build it. So from my experience, you rely on these people and you actually don't need many people who understand their own high competence. You just need one as a coach or two as a coach, but you need people with highest commitment. Right. So what do they say? That's the bulk of your force, no? That's a very good point, actually. When I put this slide, it doesn't mean that I am encouraging you to just focus on these people. It's just that this is where the rock star engineers are. And as you've already pointed out, you actually need some people here, some people there, not just all of everything here because you have different kind of issues in your company. And my point was that you don't need many rock star engineers because rock star engineers tend to communicate less. They already understand the problem as they see and they can all go in different directions at the 10 times the speed of other engineers. Yeah. And that's where you're, as a programmer here, also you can always, by delegating, it doesn't mean that you don't actually check at all what they are doing or where they're heading to. And also, it just means that you are less directive, you're less prescriptive in what you're saying. But at the same time, because also you need, as a programmer here, also what needs to be assumed before all this happens is that everyone here in the company knows why we are building it in the first place. So sometimes, yeah, you don't need to be, I mean, as long as you're building a driver application and you are building this feature on how do you want to notify the driver when there is a new delivery. You don't need, for example, if there's rock star engineers, you just need to tell them that, hey, I need to inform the driver whenever there is a part added to this route. And for these guys, maybe they will come up with a solution or I will set up my own SEM service and so on. Yeah. They will come with a solution, but because they're not drivers, they will come with a solution that's suitable for engineers. And that you can only delegate to this point if you can replace all your drivers with your rock star engineers. Otherwise, they will invent something suitable for engineers and drivers. Right. And that's why I'm not talking about the development process here, but again, because we've used like LGL and Scrum, so before even they can even deploy to the production or before they start, what is also useful is to actually discuss the requirements a bit more upfront with him. But again, the way we discuss, we can let them come up with a solution, but then not necessarily implementing it right away without your approval. Yeah. May I ask, have your backlog replied, for example, with all your engineers who are always in high confidence? Backflow revised. Yes. When you have your backlog refined, you can just plan practice. Yeah. Do you ask all of your engineers to participate, or maybe just one of those data category? So usually, how I do it is I start with the lockdown first, because you need maybe one to one, or it's just a small thing. It's a small thing. Yeah. So that you just have to have a better idea. But then after that, you have to involve the rest also, because sometimes when these people are involved a bit too early, then they're just sitting there doing nothing. So it doesn't mean that we have where we are. But at the end of the day, we are still thinking whatever their inputs are. But yeah, starting with the roster versus this, I find it more effective. I can assure you it's a funny story in our management. It's like there are mismanagement. So there are two guys in two different teams actually building exactly the same thing. Oh. Let's have it. In one of the teams, it was definitely Rockstar engineer who knows business very well. One of the first engineers in the company, like definitely Rockstar. He knows everything technology. He knows business. Typical Rockstar. In another team, there was a guy from a group C, but really committed. But his competence is way lower. He's a good engineer, but he's just far away from Rockstar. So within the two-week sprint, the guy who's a Rockstar, he's done with his solution. The guy who's from group C is still working. But judging at this time, we decided to discuss the solution built by a Rockstar engineer. And we just gave a guy from a group C a bit more time. So I think this really shows that with Rockstars, you cannot really delegate. But actually, when you use crumb, do you use crumb as a practice? Sprints? Yeah. Because, again, in that process, I think that's where the daily standouts are coming into play. Because at least, yes, there might be some misalignment, but at least that's minimized by a day's work or work, by allowing everyone. And then that's where your sprint planning also comes into play. Because you also use JIRA and some kind of tracking tools. Because at the end of the day, we are still writing the requirements. We are still giving them the task. So that if you use this kind of tracking tools, we can ensure that at least no one guy is working on the ticket group. Because when that ticket is taken, It was different teams, different stand-ups, so we didn't even feel like it's finished to actually work in the same thing. Right. And both guys delivered it. It's just like by looking at the technical implementation, we decided to go with a solution from a guy C. Rockstar never used it. So we actually abandoned his solution, but that's what happened. Right, right, yeah. So yeah, again, I think the daily standout is where we can put everyone into play. Then as a parameter, you can also try to use a little bit of check-ins. At least you know what this guy is working on, this guy working on. And then you don't necessarily know that. Or maybe he's building this video by doing this AngularJS, whatever. But at least you know that he's working on this email function, for example. And then you can let me know that because this guy is working with them, and you can ask them to communicate with each other. So it kind of facilitated them in a way, yeah. So in cases like this, how do you actually stop a Rockstar engineer from being too clever and actually creating problems in the future for your company? For example, you delegate things to the Rockstar engineer and have an element of trust in them. And then the guy says that, oh, I'm going to implement this feature using this new programming language that I read about, this new database that I read about, using this new server that I read about. So he goes ahead, and then he does all that kind of thing. And then as a project manager, you don't know these technical details. You're just like, oh, the feature is delivered. But the problem is because the feature is delivered in that new language, new database structure, new everything. And then in the future, when you have your non-Rockstar engineers, or you want to hire more people to expand the feature, then you realize that it was a bad business decision because it was implemented in such a niche technology that you just can't support it. So in cases like this, how do you actually control your? Or are there any warning signs to see when the Rockstar engineer is rocking too much? That's a good point. Sometimes, because they think that the Rockstar, they just want to be using all the cutting-edge technology, or there's a new platform, and so on. But that's where the advanced planning comes into play. And also, knowing who you're working with, because you might know that you just got what it's like to do fancy stuff by yourself. So we can try to get some kind of engagement strategy by, for example, again, linking the ensuring that maybe you can agree with him, maybe you buy him coffee or whatever to ensure that he, and say to him, oh, maybe when you do this thing, you know that actually some of your teammates also need to work on this, and also pose him as a problem in a way. How do you ensure that beyond just you working on this, right? But my challenge to you is that how do you ensure that your peers can also work on this? So he'll come up with things like, maybe he still decided to use the new database or the new technology. But at least maybe you can ask him to do some sharing session, or constantly sharing what we did in Japan, for example. We just used like a RX Java or something. So it's a new Java, and not all guys know how to use it. So what we did is that when they first decide to use this, we have some bunch of the Rockstar engineers test them, like, oh, there's this special project for you that you have to research. And why not? What is this RX Java thingy, and how do you explain it easily to your other team members anyway? So there's a sharing session, and then we appoint them to be like the RX Java guru anyway. So whenever there is a problem, or whenever the C or the exclamation marks need help, you should know that, oh, you always go to that guy, and he's expected to teach you, or at least maybe prepare a program with you, and so on. And that's how you can do with it. So I guess it works if all your Rockstar engineers are actually nice guys. So it's like, if you ever had to make the decision on when you had to terminate a Rockstar engineer, because Rockstar engineer is like, they're very good, but maybe because they are there, they cause unnecessary friction because of their behavior, or because of the technical environment that they influence. Even though you have one Rockstar engineer, when is it you make the decision that I'm going to fire this Rockstar engineer so that my other engineers actually have room to grow? Again, you're knowing the who. But again, I think this is more of a cultural fit personally in a way. And we did have some kind of that issue actually. So one guy who is super smart, and when you give him a task or something, you know what I did in the past one month? I quoted him from one somewhere. He said that whatever I did in the past one month, no 10 Google engineers can do it. Just kind of a detail. So in the end, we actually try to, we still have to coach him in a way that still delegates tasks, but then you solely talk to him that, oh, you know, some people are actually a bit not comfortable with what proper you're doing, so can you adjust your style and so on? And yeah, but at some point of time, you realize that maybe it doesn't work with all people, and you have to actually let go. But yeah, you still have to give him a chance and you still have to, again, use the full material to at least identify, maybe try to understand why he is moving that way. Maybe it's because of ego issue. Or maybe he just don't know that, maybe he thinks what he's saying is something that is accepted in his culture, or maybe it's his, so is he coming out with how or why he's coming from and then you can decide whether you want to use, which route. I'm sorry about that. You can look for him afterwards. So let's all give a hand for Anthony in his talk.