"Promotions are something to be celebrated. You get paid more, gain more responsibility, and it feels good. But the fastest way to ruin someone is to over-promote them. When you put a strong performer into a role where they can’t meet expectations, you turn confidence into anxiety. Instead of calmly doing their work, they start worrying about getting fired. Everyone depends on them, and they feel they’re letting others down. The extra money doesn’t make up for the stress of knowing your colleagues are disappointed in you." - Li Hongyi, Director at Open Government Products


"One simple mistake I used to make was promoting young, hardworking, capable officers too quickly. They were doing a great job, but sometimes it was luck, burnout, or timing when everything aligned. I ended up with junior officers outperforming seniors who were struggling and stressed, which was tough for everyone, including the team. Apart from performance, you must look at consistency and sustainability. If someone is performing well but clearly burning out, they cannot keep it up for years. Promoting them only locks them into a difficult position. Even if they insist they want the promotion, once they get it, they realize the stress outweighs the reward. Instead of operating comfortably and improving, they hover at the limit, and any small slip leads to underperformance." - Li Hongyi, Director at Open Government Products


"It is very critical to ask whether they have the right values. The people you promote as leaders will become the ones others look up to. If someone performs well but behaves in a way you wouldn’t want others to emulate, you should think twice before promoting them. It’s a difficult conversation to have—you might say, 'You’re doing great work, but I don’t think I want other people behaving the way you do.' It’s not that they are behaving badly, but maybe they make decisions too rashly or too conservatively. Maybe they prioritize optics over delivery, or focus on delivery without enough care. If you would not want others to copy their behavior, don’t promote them." - Li Hongyi, Director at Open Government Products

Li Hongyi, Director of Open Government Products, and Jeremy Au discuss how leaders can define, measure, and sustain real performance within organizations. They unpack why clarity of purpose matters more than ambition, how to design fair and motivating systems, and how to prevent burnout in high-performing teams. Their conversation bridges lessons from public service and startups, showing how structure, accountability, and empathy build lasting excellence.

00:56 What is performance: Hongyi explains that success begins with clarity. Teams fail when they skip defining what “high-performing” means before chasing results.
03:15 Why clarity matters more than profit: In the public sector, lacking a clear anchor like profit causes teams to chase noise instead of purpose.
06:43 Designing the right metrics: He suggests tracking three to five key metrics that collectively prevent failure while balancing usability, reliability, and cost.
12:44 Communication through signposting: Hongyi shares that being explicit with intent by saying “this is advice” or “this needs to be done” reduces confusion and builds trust.
14:15 Rethinking performance reviews: Self, peer, and manager evaluations should gather information for better decisions rather than serve as political rituals.
27:00 The danger of over-promotion: Advancing too quickly can destroy confidence and create anxiety. Steady, sustainable growth builds stronger leaders.
31:00 Burnout and sustainable success: True progress comes from building skills, not just adding hours. Leaders must create space for learning and recovery.

Jeremy Au (00:42) Hey, Hongyi, good to see you back again. We caught up for a sequel because you've been writing a series of LinkedIn posts about performance management, promotion, and I was like, "Oh, this is really good," and you stopped writing.

Li Hongyi (00:43) Good to see you too, Jeremy. I think I've taken the George R. R. Martin hiatus. You have ideas, but you need time to put them in the form that you're proud of.

Jeremy Au (01:01) Totally understand. So I was like, "Wait, where are the next chapters?" I thought this would be a good way to go through some of those posts, maybe from a bottom-up perspective, but also talk about some of it in our real lives as well. I think we will link in the description, obviously, the posts that you've done so that people can dive deeper. But I think we were about performance, measuring performance, promotions, and also to some extent, hiring and retention and burnout. All those different dynamics. Lots to dig in. I think that's interesting because everybody belongs to some organization that measures performance. At my job, I have to go through a performance review every six months, and then you're making me remember primary school, secondary school, academic performance.

Li Hongyi (01:43) The importance of the way performance is judged your entire childhood.

Jeremy Au (01:47) The worst part is when there's some dinner conversation, someone's, "So, what was your PSLE?"

Li Hongyi (01:51) I know, when you tell your foreigner friends that the government asks you for your PSLE when applying for a job, your primary school grades, they're like, "Are you crazy? Why does anyone care?". I know, I was not a model student.

Jeremy Au (02:00) I was just playing a lot of computer games. So we were hanging out at the time. Let's talk about it, which is obviously there's so much talk about all of that, but I think the first question that I've got to ask is a philosophical one: What is performance?

Li Hongyi (02:13) That is a good question. The most correct answer is that it depends on what you're trying to do. This is a seemingly trivial point that I found a lot of people miss when they're trying to run their organizations. If you ask anybody if they want their organization to be high performing, they will almost certainly say yes. But then when you ask, "Perform at what?", a lot of times they haven't thought about it. I think there's a kind of implicit, "Oh yeah, high performing organization. We're fast, we're efficient". But a lot of people skip that first step of really just defining what it means to be high performing. And once you skip that step, everything you're doing downstream is just vibes because you're not clear on this goal.

I'll give you an example: conversations with the product teams are about tracking metrics, and a lot of teams are like, "Should we track daily active users, monthly active users, total users? Should we track revenue? What should we track?". And my answer to them is, "What are you trying to do?". For example, let's say you're working on one of our AI tools. Is it to be the best damn AI tool for a government officer that it could be? The objective might be to not be the most powerful one, but just to be pretty simple so that a lot of government officers can get a very introductory usage of AI. Is it to fulfill a niche in the market that other AI tools in the commercial industry are not filling?. These could be reasonable objectives. Each would be a different measure, right?. If you're trying to be the best AI tool for government officers you could possibly be, then you would compare the performance of whatever you built versus Claude and ChatGPT and all these other models, and try to beat them. I don't think we should be in the business of doing that, but if that's what you're trying to do, that's what you're going to measure. Similarly, if you're just trying to get government officers familiar with AI, but not necessarily the pro tool that they eventually use for their whole career, then you're measuring monthly active users—people who are using it somewhat. And it doesn't really matter whether you use it 10 times a month or one time a month. You just want to build familiarity across the public service, which is a reasonable goal.

That is the root of where a lot of organizations fail, because the complexity of everything else you're discussing—how you do performance management, promotions, and your strategy—all this really comes to a disagreement because you never sat in a room and actually hammered out what it means to perform (it doesn't have to be a single dimension). I do think this is one of the challenges with why public service organizations tend to be less efficient than private organizations. Because in private organizations, even if you do not sit down and have a philosophical debate about what your company is trying to do, you have one default set for you, which is profit. Bottom line, if a company doesn't make money, it doesn't exist. The problem in public service is that because you don't have that bottom line—it's not that private companies are better at having these deep discussions—it's that for the public sector, if you don't have that discussion, suddenly there's no floor. Suddenly you're just chasing either what people are complaining about on social media, or what some of the bosses are upset about, or what your peers or staff are complaining about. There are all these different dimensions, and it's not that any of them are particularly wrong, it's that if you do not have that anchor, you get pulled in different directions and end up not performing because you've never defined what you perform at.

Jeremy Au (05:15) I totally agree, because I've done startups, which is do or die. You have to get revenue and growth. But I've also done social enterprises. And it is a weird mixture of both where you're like, "Okay, you want to have profitability, but you don't have too much profitability because you're a social enterprise," and then there's a huge argument internally.

Li Hongyi (05:30) People latch on to profit as the key determinant. But I think profit is just a clear indicator that is useful in environments where you don't have profit. As long as there's a clear indicator of performance, you get good organizations. Sports is a good example: you win games, you get money. Therefore, people try really hard to be very good at delivering on what is considered performance. One thing that always surprises me when the Olympics comes around is that even for sports which don't actually have that much money in them, and all the people participating are amateurs , when the measure is clear, you learn about all these weird, esoteric sports in different countries. The people doing it are really good at it, and they have figured out all these tips and tricks to perform better because it's clear when they do.

Another good example is speedrunning video games. Are you familiar with this? Yeah, of course. You have people who play video games normally, and then you have the people who are like, "I want to finish this game as fast as possible". Whether or not that is a good goal for society is almost irrelevant. The fact that there is a very clear and substantial measure—that you were the fastest at finishing like Super Mario Sunshine or Hollow Knight or whatever video game you're talking about—they will find every single trick and weird, esoteric way. At this time of day, if this particular thing lines up and you get the right RNG (Random Number Generator) you can jump and hop from this level. It's crazy what kind of efficiency they find out, but that comes about because, "Yep, we came to a common agreement that performance was measured by this, and we will just go all out for it".

Jeremy Au (06:55) So what I'm interested in, of course, is that metrics that are easily measured become the thing that everybody manages towards. For example, profits are easy to measure, so people manage towards it. I think other things, like budget or department costs, tend to be something that people manage towards. So how do you think people should think about defining the right set of metrics or approaches?

Li Hongyi (07:18) So I think you need to start with what is the story you are telling about what your success looks like. So put the metrics aside for a moment—they are important. In a paragraph, explain to your family or friends what you're trying to do. Are you trying to make all government websites really good? Remove paper forms from the government? Protect people from scams by putting a filter on their phones?. You need to describe in a paragraph what you are trying to do, look at that with a straight face, and say, "Yep, that is correct". Other people look at it and are like, "Yep, I understand".

Once you have that written down, you have a semantic objective. Then you can see what is the set of metrics that you think roughly represents that. I know there's a lot of focus—a lot of people talk about North Star metrics, the one number that you all chase, which I agree is very powerful if it lines up nicely. But what I've found is that in more complex environments, or rather with more complex objectives, it's very rare that you're so lucky that there is one number that measures what you're trying to do. I prefer three to five numbers. Hold yourself accountable for what you're trying to accomplish. I'll give you an example.

The way I approach this exercise is by thinking: "What's the obvious thing we need to track?". Then ask, "How can this number be really high and we're still doing a bad job?". Then you add something else. Then you ask, "How can these two numbers be really high and you're still doing a bad job?". Then you add something else. For example, Isomer is our website building tool for government. Our mission for Isomer is to make sure there are no crappy government websites. Crappy government websites are a well-known thing in every country all across the world. Our job is to try and make sure there are no crappy government websites.

So what's the first metric that you would look at?. The obvious one people would be like, "How many websites is Isomer on?" for example. Okay, so let's say this was really high. Let's say Isomer was on 100% of all government websites. How could this be the case, but you're still doing a bad job?. Are the Isomer websites any better?. If you've just replaced everything, but your website still sucks, that's no good. So you need to track, "Okay, do people find the websites usable?". Okay, let's say the websites are usable and it's across all government websites. Is that good?. Maybe, but maybe the websites aren't reliable—like they keep going down and there are bugs, even though they look very nice and they're very usable. Okay, so you measure something about the usability and then something about the reliability of the websites—uptime or bugs reported or things like that. And you say, "How can these three numbers be good and still be bad?". Maybe that's all true, but it's super expensive. We hire a million dollars of developers to pour over each website, and therefore, it's not very cost-effective. Okay, so you have to track cost.

This is a very fancy way of going about doing it. You're trying to find the high-order bits for data scientists. You're trying to find primary support vectors that describe your performance. You will never get to a place where you can handle every scenario, but you're trying to get to a place where if all these, let's say this collection of five numbers, are good, it is exceedingly absurd that it is doing a bad job. That's the way I think about it. You come up with your first answer. Once you get more than 10 different metrics, everyone just looks at it and is like, "I have no idea what to look at. It's all meaningless to me". The whole point is to give clarity to the team about what they're accountable to.

Jeremy Au (10:02) We're approaching a problem from two layers, which is that the individual and small team performance is clear, like what needs to be done. And from a leadership perspective, what are the top five metrics?. But at the organizational level, especially for large organizations, something gets lost in translation between small team performance to group performance, and then the North Star metrics also collapse by the time it reaches the small team. So it's almost like this blob in between that's confusing.

Li Hongyi (10:31) I think one of the mistakes people have about metrics is thinking that the five metrics you agree upon are the only metrics that you should look at. Those are more like a contract. So the way I put this is, in OGP, we've got about 40 product teams building different things. The five metrics for each team that I look at are what I, as a stakeholder who does not have time to dig into the team, say you deliver to me, and as a team, this is what you're ultimately delivering. But in order to get these five metrics, you have to have a deeper understanding beneath that about what you're trying to do , and I have to also have a broader understanding above that of what these five things are adding up to.

Does that make sense? So I'll give an example, going back to our website building tool for government. I care that the websites are online, that they're good, that they're cheap, and we have enough of them that we're making an impact. Now, that's what the team delivers to me, but the team should internally track things like server errors, security reports, things that they as the experts in their field know more about to deliver the outcome I care about. I think that's the first part, which is that a lot of times people get caught up, and when you agree on this, that just means that everyone only cares about this. I think this is the common interface that we go by, so that beneath that, the team knows that's where they start, and then they go down. I don't have to waste time micromanaging them because they agree, and that way they have the freedom to innovate, to figure out what are the right things to look at in order to achieve this objective. You have coupling based on outcomes rather than behavior.

It gets larger. For a line to be straight, you need two points. If I as a boss only tell you what you need to know, and you only tell this person what they need to know, if you were to take ice cream sticks and stick them together like this, mechanically it's flimsy, right?. Because the pivot point is very fragile, and yes, that's what you care about, but it can swing this way or that, and this one can swing this way, and this one can swing this way. So I think it's important—what I've found to be useful is what I call overlapping visibility. You obviously tell the layer below what they need to know , and they should tell them what they need to do. The person two levels below you should have visibility into what they're doing, and they should have visibility as to your goals. That way, instead of having this one-by-one flimsy pivoting chain thing, which can't have rigidity, you have overlapping visibility and an accountability structure like that. So it creates—it's not perfectly rigid, but much more rigid than single-point anchoring.

Jeremy Au (12:40) I think it's resilience.

Li Hongyi (12:43) They understand the thing they hold accountable to, but they also understand the human, common sense, "Let's check, is this actually achieving what your higher-level objective is?" rather than just flopping all over the place.

Jeremy Au (12:53) Yeah. Are there more effective versus less effective communication practices that help this cascading?. Lots of stuff gets lost in translation along the way.

Li Hongyi (13:03) I am no expert in communication. I would not say this is my particular strength. But the one tip that I found to be very useful as someone who is not particularly good at communication is just to be explicit. It's called signposting, right?. So it might seem a bit awkward, but I have found that if you are giving advice, say, "This is just a suggestion," and then you say the suggestion. Or if you want something to be done, say, "To be clear, I'm expecting this to be done". It feels a little bit contrived, but I found that it is far better to just assume low context and be explicit about what you are trying to do as opposed to hoping you are signaling in the right subtle way that everybody gets it.

So even when you're having a conversation with a direct report and they're trying to give some feedback that you think will help them improve, if you have a well-established relationship, you can just talk, and it's fine. If you don't have a very well-established relationship, the person will come away from that with all these thoughts in their head: "Why did they bother telling me this? Am I going to get fired? Is he not happy with the project? This is not supposed to be done". You can't stop that entirely , but if you think the project is going well and it's just a thing to improve, you'd be like, "Hey, to be clear, I think the project is going well. I think these things are going well, these things are good, and congratulations, but I do think there's an opportunity to do some things here". Does that make sense? I'm just telling you this because... while I think you guys are doing a good job, it feels clunky to talk that way. It is better than the confusion that arises if you don't. There's a lot you can go through in corporate communication structures, but I found that being explicit solves so many problems.

Jeremy Au (14:21) Exactly. One of the communication mechanisms is the performance review system , which is very structured, a set time point. There's a lot of stuff riding on it, like compensation, bonus, promotion. One of your LinkedIn posts dove deep into it. I think what's interesting to me, at least, was I think you also mentioned not only a top-down evaluation, but also a self-evaluation, a peer evaluation. You mentioned several other components like project metrics. I'm curious about how you think about performance review systems.

Li Hongyi (14:55) I think it is important to understand that for all the arcane mechanisms and rituals of performance management, ultimately all you're trying to do is make sure that one, you have the right information, two, your standards are reasonable, and three, you are applying them consistently across your team. Because at the bottom line, performance evaluation is not this weird, magic ritual where you get people to write the right words and you sit around and you mutter the right things and you talk about deliverables, and somehow magic pops out the other day. No, at the end of the day, the question is what does your organization want?. How much are each of these people delivering towards that goal? Recognize them accordingly. So if your organization needs people to be software engineers, great, then you see whether they're delivering their software engineering work and you track that. If your people need your software engineers to be much more user-centric and driven, then you measure that. Performance only makes sense in the context of an objective. Measuring performance outside of an objective doesn't mean anything.

People ask me, "Is this guy a senior engineer, a lead engineer, a staff engineer?". I think we get asked sometimes to evaluate other people's performance. I can give advice and two cents' worth, but fundamentally, you know what you're trying to achieve, and I therefore cannot measure people towards your objective because I don't know what your objective is. The end goal of performance management is: as an organization, I want you to be doing your best to help me achieve my organizational goals. As an individual, if you just do your best—you won't do it perfectly—but if you do your best to achieve organizational goals, you will get that performance recognized. Whether it's through compensation and bonuses and things like that, that's a separate matter. That's all it's trying to do. Everything else—manager writing the evaluation, peers writing evaluations, project metrics, self-evaluation—all of this is asking, are we making an informed judgment?.

If you as a manager are working with a small team and pretty much everything that everyone's doing, great. I think that's enough. You just look at that, give some informed feedback. As it gets larger, you forget, or have recency bias, or you remember the most recent project. So you just ask people, "Hey, just write all the things you're working on, so that at least I know what you think you're working on that I can take a look". As your teams get larger and people have to work with each other, you want to make sure that you as a manager have a view of what people are doing, and then you have your peers have a view of it, and then you have the project metrics. And you can choose how much effort to spend on each of these things, or how much time you want to spend doing each of these, because at the end of the day, all they are is just information for what you need to know to make a sound evaluation.

If the manager just makes a value judgment themselves, it's unsurprising that people will optimize for optics to their manager. If you have a self-evaluation, there will be less pressure to do that because people have the confidence that, "Okay, I don't have to have the manager have me on the top of their mind, but as long as I can document my work, they can verify it, that's good". If the team gets a bit larger, people might optimize for their own work and own deliverables, but at the expense of their teammates. If you get the peer feedback from it—because every manager obviously wants their team to work together and help each other. No one wants their team undermining each other—so you need a peer-evaluation mechanism so that when that happens, you have some signal. Now, obviously, you don't want your team to avoid conflict; you want people to have discussions and disagreements to make the right decision. But you need to have some signal to account for that.

As the organization gets bigger, anyone who runs a small company knows this: ultimately, you need to look at client feedback. Even if the team is really doing good work, and you think they're doing good work, you're happy with each other, but every client who they serve is not happy, there's something going wrong. There's a lot of different mechanisms you can look at. I think self-evaluation is important. I think peer evaluations are important. I think looking at the project metrics are important. But the end goal is just to inform your decision.

One trick we do is make sure people write their self-evaluation before we write the evaluations. So that the reviewers see the self-evaluation when writing it as a manager, instead of me having to fact-check every single thing written in the self-evaluation. If there's something completely—the person and the team knows that if you write complete nonsense in your self-evaluation—I think this is something we need to train out of people when they first start working for us, which is that most people when they write their self-evaluation in other companies have been trained that if you are not super self-promoting in your self-evaluation, you will not get promoted. It's like a creative writing exercise. But what I've found is that by having people write the self-evaluation first, and then when people have to write their peer-evaluation, they read the self-evaluation and then write their peer-evaluation. If there's anything dishonest in the self-evaluation, it gets called out. People writing the self-evaluation knowing this will happen are far more honest and far less likely to be bombastic about their impact.

Jeremy Au (19:06) Yeah, it makes sense. It's a bit of a prisoner's dilemma , which is if in a system where you get to boast of achievement, you'll be bombastic as well. Because otherwise you'll both—if I am factual and he's bombastic, then he gets promoted.

Li Hongyi (19:13) And it just ends up harmful. You can wag your finger at people, but you really need to design a system that breaks this down. I've found that peer evaluations are a good way of doing it. And then you look at project metrics just to make sure that teams are not just happy with each other , but are actually performing.

Jeremy Au (19:28) And I think the performance review cycle is a very emotional affair, right?. It's not just a writing exercise, a creative writing exercise, but even for myself, when I'm writing my own self-evaluation, I feel emotional. And then when I'm reviewing other people, it's very emotional, and there's a lot of subcurrents happening. So any thoughts about that?

Li Hongyi (19:48) It's one of the most important things you can do. I know why people avoid it—it's understandable—but not doing it is the fastest way for your organization to get dysfunction. This is something I had to learn the hard way. When we first started doing performance evaluations, my theory was that the government performance evaluation system wasn't particularly robust. It was the classic one where your manager gives you a rating for the year, which is okay, but it has all kinds of dysfunctions talked about previously. So we came up with a robust performance evaluation system. We did it every six months. You would write your self-evaluation, and not just your peers—we just got everyone to write their thoughts on everyone else, which was a lot of work. 30 people writing. The idea was to get information from the team. It took a lot of work.

One of the things is, if you ask people about OGP, they'll say there is a lot of performance pressure compared to most of the government, where people would say that most of the government doesn't really have that kind of high performing culture. The extreme performance pressure is a good thing. The challenge I had was that even my well-performing officers started burning out because being judged all the time melts your brain. It's not their fault ; it's just as a human that melts your brain.

I needed to figure out how to exert some performance pressure but not create the anxiety of people doing this all the time. So there are a few things I've learned. One, I think every six months, while doable, is very stressful for people because, practically speaking, it takes a couple of weeks, and I think it was just very expensive from an emotional perspective to do this every six months. What I've found is you may not have a formal performance cycle every six months, but you should have performance conversations early and often with your team. Avoiding performance conversations until the evaluation is painful. If every three months you have a sit-down chat with your manager about what you're doing well and what you're not doing well , and even going into performance review season, you have a rough idea as to how you're doing and what the pros and cons are. It dramatically reduces the anxiety. Firstly, people then feel like they have control. If I'm silent the whole way and then I give you a judgment, it is very hard to steer and be judged at the same time. Whereas if I have that performance evaluation outcome, and then in the meantime, I'd be like, "Hey, you're doing well on these things, but this is something you can improve," or, "Hey, actually we think you're underperforming, but it's halfway through the cycle. If you pick up these things, it'll be fine," people feel more empowered and able to steer back.

It's not perfect; there are still things we're trying to figure out. I'm trying to reduce the time people spend worrying about this as well. But I think it is an important mechanism, and what is more important is that it is not the evaluation itself, but the fact that there is going to be an evaluation at the end, and you know what it's going to be about, allows you to have conversations all along the way to get people on the right track.

Jeremy Au (22:24) One thing that makes it more loaded is its tie to promotion, compensation, or bonuses. The more money I get, or the better the title, the more value you're assigning to me as a person. What's your philosophy on that, the linkage between performance and compensation?

Li Hongyi (22:38) I want people thinking about, "Will this action help achieve our goals better?". As long as they do all of that, then they should feel the confidence that the compensation will be taken care of. There's a longer discussion about designing roles and structure and how they pay competitively. But fundamentally, you need to come up with some kind of stereotypical role that someone plays, calibrate to the market, and recognize when they do things beyond that role that are valuable.

Maybe I can share the core challenge I have with this and one of the mechanisms I designed around it. The problem is, almost every big company has some kind of career ladder—junior level, senior level, manager, director, whatever you got —and then they write descriptions for each of these levels. This is very valuable because it gives people a sense of direction as to what they need to be learning and where they need to go to. This is very constraining in that it makes you feel like if you don't fit the cookie-cutter mold, it's not going to be good. And actually, when you work in an organization where everyone's trying to fit their mold, it makes it hard to do anything. Trying to get someone to help with something that isn't explicitly in their job description is like, "Why would I spend time doing this? That's not what I'm going to be recognized for". So it's great that it gives direction, but bad that it soft-straightjackets people.

What we've come up with is a mechanism called Schema Plus. For example, if I have a designer, and they're a really good junior designer, but we don't think they're quite ready to be a senior yet. But they spent a lot of time helping the ops team. They took the initiative to learn some engineering, which let them work well with the engineers and help them deliver better. You can't say they're a senior designer because of the engineering work—that's nonsensical. But you want to recognize them. We made this mechanism: if someone goes outside of their role and delivers impact, even if it's beyond their current function, they will get recognized. Rather than calling you a senior designer, we will say you are a "designer plus" or something like that. So there's a means to some flexibility that you can recognize people for. Because that's exactly what you want. You want your people not thinking about, "What's my job?". You want people thinking about, "Where can I be helpful?". You want people to be able—you have a core thing that you mostly do—but if they do something slightly different, they first get assured they'll be recognized for it. Very importantly, if they keep doing it, that actually can become how you make new roles.

For example, we had an engineer who worked with us for a while, but he spent a lot of his time helping out with our community engagement events. He'd help organize meetups, he'd help guide the interns, he'd help do all these other things. These things do not make you a better engineer. I can't say you handle more difficult engineering tasks because of that, but that does make you more valuable to the organization. So the first few times this person did it, we just gave him a bonus, "Great job". You get a bonus as if you're outperforming in your current role. After a while, given that he was doing this fairly consistently, we turned that bonus from a bonus to an allowance. If he did it one time, and great, this was a one-off event, you don't feel obliged to keep having to do this, chasing this thing. You can just drop it and go back. Once it was clear that he was doing it consistently, then actually we knew there's actually a job here. But rather than creating a new job role and a whole new job title for him, you just say, "Yep, you're doing this, but with a plus on it". And that is part of your role that you're doing now. Even further, as this branch grew and he was doing a great job organizing and facilitating and getting events, that branches into a bigger role. Let that job grow organically rather than having to make a big corporate decision about whether or not you need a developer relations person.

Jeremy Au (25:48) That's like a level five bard who got to add one class as a fighter. I think other people would call it T-shape, right?. You have a spike strength and adjacent things you're good at. These people often struggle in organizations, right?. In a small team, everybody understands they are quasi-generalists with some minor spikes. But then once you become an organization, like you said, it feels like these people kind of get lost between departments. Or they're doing a good job, and people like them. The other departments like them because they're good to work with. But then in the core, they get dinged because the boss says, "You're too distracted talking to other departments".

Li Hongyi (26:21) Just to give you an example, some of the things I've seen be very weird is that I think on one of the teams I was working with, a lot of the junior designers kept trying to go for conferences, and I was like, "Why do you keep putting up requests to go for conferences?". I didn't understand, and then I went and looked into it, and it was that one of the criteria for being promoted to a more senior role was that you were more influential, and as an example they gave was like, "speaking at conferences". And so you put that down, then the people will read that and be like, "Yeah, they have gone through previous performance cycles and been told according to this rule...". And this is what I mean: when performance gets disconnected from what you actually want from the organization, it ends up being nonsensical. I'm very much against performance rubrics being written by people not running the team. I, as the person on my team, have a lot of things I need you to do. I want you to spend your time making sure these mocks are good, getting this thing pushed out, working with the engineers, building tooling so that we can automate some of this. There's tons of stuff I need you to do. And if I have a performance thing here on the side, it's just waving a carrot and getting you distracted. That's stupid.

Jeremy Au (27:17) I think there's an interesting component which is about design titles, and you started talking about promotion as well. And this is an example—a designer trying to get promoted, and then there's some sort of it breaking down. Can you talk about over-promotion?

Li Hongyi (27:32) Promotions in general are something to be celebrated. Obviously it's good: you get paid more money, you get more responsibility. It generally feels good. I have found that the fastest way to ruin somebody is to over-promote them. Because if you put them in a role where they are unable to meet expectations, what happens is that you take a good officer who's kicking butt at their current role, you put them in a place where there are higher expectations of them , and instead of them very confidently and calmly doing it, they are really worried they're going to get fired. Everyone's depending on them, and they're upset they're not getting what you need from them. Yeah, they get a bit more money, which is nice, but from talking to people in these positions, the money does not make up for everybody, all your colleagues, depending on you and being disappointed in you. Promotions are not just about paying more; they're about knowing who to give more responsibility to. Being given a responsibility that you're not ready to handle is the fastest way to ruin someone.

This is the framework: someone's performance is one of the key factors necessary to decide whether to promote them. But the key thing to recognize is that you give someone a bonus for recognizing the work they have done. You give someone a promotion because you think they are going to be able to do good work going forward. Past performance is not an indicator of future performance, but to some degree it is. So that is a key factor. But apart from that, there are other things to consider, right?.

One simple mistake I used to make was that young, hardworking, capable officers doing a great job, and I just wanted to promote them quickly. And I promoted them quickly. And then I didn't realize that, yep, they were doing a great job, but whether it was luck, they were burning themselves out, or the opportunity was like all the stars aligned. And I had junior officers outperforming and senior officers underperforming, and they were very stressed about it, and that was really tough for everybody, including the team. So apart from performance, you want to look at consistency. You also want to look at whether or not you feel it's sustainable. If someone is achieving a high level of performance, but you look at them and you know they are burning out and they can't keep this running for years on end, you should not do it. You are just locking them into a job for a long time. And while they themselves will say, "I really want that promotion". Actually, if you get the promotion, they will think they want it, and then you promote them, and they will get super stressed out. Instead of being at level and comfortably doing better, they are mostly at level, and if they slip up, they'll drop and they'll be underperforming.

So, apart from performance, you want to look at consistency and whether or not they're doing it sustainably. You want to look at whether or not they have the skills. Maybe in this scenario, they did well, but there are skills that you want to see for all people of this level because there are other scenarios in the future. And very importantly, the last one, I think, is very critical: Do they have the right values?. At the end of the day, the people you promote as leaders in your organization are going to be people that other people look up to. And so if this person is performing or behaving in a way that, even if it's very good, you do not want other people to emulate, you probably should think twice about whether or not you want to promote them. I think that's a difficult conversation to have: "You're doing great work, but the short answer is that I don't think I want other people behaving the way you do". Not necessarily because they are behaving badly —just maybe the way they make decisions—maybe they're more rash than you would like, or maybe they're too conservative than you would like, or maybe they are prioritizing the optics of it more than the deliverable, or maybe they're optimizing delivery without sufficient care. But fundamentally, you do not want other people to copy their behavior, so don't promote.

Jeremy Au (30:42) I think it's a tricky one, because, "Promote me, otherwise I might quit". "If he got promoted, I should be promoted".

Li Hongyi (30:49) I think in a lot of organizations, that behavior is trained into a lot of people: when you do not have a good performance assessment, promotions are something you grab on to. If you're not measuring, no one's paying attention, someone got promoted to director, and as long as they don't do anything obviously bad, they just float around in that role because you're not assessing them for performance. And I think for people who are in organizations like that, and for people who grew up in organizations like that, it makes a lot of sense to think, "If I make the sale, made a pitch, worked hard, I should be in this role. You get a promotion. I'm happy". In a high-performing organization, you need to continually assess performance. People see the upside of promotion, which is that "I've got this thing that I own," but they don't see that it actually comes with a lot of responsibility that you are now burdened with.

One of the things that we've been trying to do a bit more—I haven't fully fleshed out a rollout yet—is promotion options. Meaning, rather than saying, "I've decided you're promoted," we think you have the capability to get promoted, so you feel you have it, but you must acknowledge you want it and know that you want to do it. One of the things that I am thinking about, haven't rolled out, is instead of saying you must take this promotion now—"We think you're ready"—you can take it now if you want, or maybe the offer stays for a year or two. That way, people can feel, rather than grabbing onto something from a place of anxiety, they can really reflect on whether this is something they want to do, something more they want to take on.

Jeremy Au (32:09) I think that takes a lot of self-awareness, right?. For people to be like, "I'm ready from an organizational perspective, but maybe I'm not personally ready". You mentioned you noticed burnout in your teams because people were pushing themselves. Could you share more about that?

Li Hongyi (32:23) Burnout is a big topic for different places. What I'm sharing is just one dimension. A simple way to burn someone out is to give them a lot of responsibility and feel like they have no choice but to keep doing it. They come in, doing well as a junior officer, you promote them. They learn a bit, they're growing, you promote them. But at some point, they work harder and harder. I've had conversations with officers who say, "Hongyi, I am working as many hours a week as I can, but I'm not getting promoted. What more do you want from me?". For this officer, promotion means quantity of work. "I'm already doing maximum quantity of work. How come this is not reasonable?". And I had to explain to them, the fact is that if I promote you now, I know you're achieving good work and I know you're delivering well, but if I promote you, you are going to have to work these hours forever. What I actually want you to do is I need you to take a step back, build skills, get to a place where you can deliver similar levels of impact without having to max out your day. And that means you are going to take some of the hours that you are spent working on deliverables for me and focus on your development and skills, and then over time, you will grow. Because if every promotion means adding to hours to your work, they run out of hours quickly. The only way to grow is to build skills, but that means sacrificing some stuff in the short run. You don't want to lock someone into a position where they feel like, "I am working all the time. I do not have space to breathe to do different things, to build skills". They are locked in the short run. They made the time to build and grow skills, they eventually overtook in their ability to deliver, not because they're better, but because they had time and space to build skills. So I think that was one of the mistakes I made previously, which was I was too eager to promote officers because I thought they were doing good. I saw capable, excited, motivated junior officers I wanted to support, and I thought promoting them was supporting them, which to some degree is true. But then you lock them into this kind of, "I am firing on all engines" state, and your engines are eventually going to burn out.

So yeah, I think that was one of the challenges, and that's just for the individual, not counting the dysfunctional team. "I'm expecting this guy to be a senior engineer, but he's not performing, he's not delivering". And then this person gets very anxious, and then that creates more tension in him. I think that's a whole separate issue. This might seem obvious, but it is better to have a team of out-performers than under-performers. You want everyone to be at least comfortable, and maybe half or even 75% of them spiking up and out-delivering. Everyone's great, everyone knows what to expect from each other, and people are positive. Versus if you took those same people and then put them at this level, what used to be a very happy thing where everyone's out-delivering expectations is now a place where people start letting each other down.

The fact is that people's performance is not exact. You will have years where you do really well, and you will have years where you don't do so well. That's life. There will be cycles where you do amazingly and cycles where things don't come together. If I put you at your peak, you're going to spend all your time worrying about when you drop from there. If I put you at where you are solidly at, and you go up, that's why I think you have a much healthier team that way. When you tell this to officers, however, and tell them this philosophy while explaining that's why you're not promoting them, they obviously don't get very happy. But I have found that it's a discipline I need to keep, because otherwise when you promote everyone, everyone's very happy at promotion time, but then the team is not living up to the expectations. "This person's meant to be a senior product manager, but doesn't even know how to do these things". It's better to have a team of out-performers.

Jeremy Au (35:34) In your LinkedIn writing, you wrote about having to make a decision about performance standards. Whether it's better to set it too high or better to set it too low. I'm just curious how you think about that.

Li Hongyi (35:45) Standards are a mechanism. The thing people need to get away from—and that is very tempting—is to think there's no universal truth to what the right standards are. There really isn't. There is no sort of fundamental particle of software engineering. It's just what you and your organization need. Setting standards is a steering mechanism given what is available in the market. If you're a big tech company, you can look at market standards, hire people accordingly, and go from there. But even among big tech companies, they're all slightly different. You need to understand that what you expect from people is going to require some learning, some deviation, and some training when they come in. As you set standards, the question is not a philosophical one of what does it mean to be a senior engineer. It is a very practical one of: "I have this role, this role needs these skills". You want to call it a senior engineer, a staff principal, a junior engineer, whatever—that's not really relevant. "Who do I need? Who are the kind of people in the market who could be able to fulfill this role and bring them in?".

If you set the standard too low and you bring in people who actually aren't able to deliver what you need, that's obviously problematic. But if you set standards too high—and it's very tempting to be as an organization like, "Oh, I have very high standards"—and you can't bring in people, that's also a failure. The common term is chasing unicorns, right?. Maybe they just don't exist. You need to hire the best you can, but the "can" part is bearing a lot of weight.

What I've found to be a very useful way to think about this is, sometimes after doing this cycle a few times, you realize that actually this concept you have for a role is just wrong. It's too much to expect from a person. So I'll give you an example. We have a corporate team which does a bunch of stuff, including obviously HR and finance, but also people who just make sure the office is working and make sure the lights are on. I used to imagine there was this role of this person who would be responsible for our software and software support. Meaning their job would be to make sure that we had a good office, which was nice and cozy and well designed for people to come in and work and collaborate. But also make sure all our software tools that all the people on the team used were working very well—make sure that your Gmail was working correctly, our Slack was working correctly, your messaging and whatever tools were working correctly. And I was like, "Yeah, you have the production side of the house, which writes the software that we give to our people, and then you have the person here who's responsible for making sure that our own house is in order". Which makes sense. But practically speaking, finding someone good at office space design and enterprise software configuration is not reasonable. They'll try their best, but you need two different kinds of people for these roles. Obviously, it would be nice if designers could do all the design but also write their front end for themselves. And there are people who can do that, but people who are really good designers and front-end engineers are very rare. Designing your organization around assuming you can get a lot of them is just stupid. You need to design your organization with consideration of the availability of material.

So, yeah, you could write this fantasy description of a product manager who is a super good engineer, super good designer, super sharp with marketing and business development. You can write your fan fiction of what this would look like. But if they don't exist, that's all it is. I think that is one of the difficult parts I've had to learn trying to figure out. You want to scope roles up enough that you are putting the right pressure on people to deliver what you know is possible, but also make sure you're grounded in reality of not putting together roles that are just not practical to fill.

Jeremy Au (39:02) It's creating a system of checkpoints for performance—high performance, low performance. There's a story because sometimes we hire superstars; we expect them to be superstars throughout, but it doesn't really work out. You hire them, onboard, train them. How do you think about bringing in more diverse talent through this structured performance review, compensation, and optionality process?. Why don't we talk about people with different skills first? When coming in, are there situations where you're like, "Okay, this person is going to be a rock star?". How do you see that?

Li Hongyi (39:33) I think calling people rock stars and relying your strategy on rock stars is a mistake. Not to say they aren't very capable people who are very good at things, but if you are saying that they're just like that because they're rock stars, no, you need to be able to articulate what it is they are doing that lets them be so good at their job rather than just hand-waving it as "that guy's magic". First, understand at least in theory what is your theory of a well-performing team. If you don't have that theory, everything is lost. For OGP, our well-performing team theory is: you need one Product Manager, hopefully with some experience (fresh PMs tend not to do that). One designer still needs some experience, though it's not as critical as for the PM. You need one experienced engineer to anchor the team, and then you can have a few junior engineers under them—five people. That is as a stereotype, as a reference, like a starter product team which can run something in production without everything blowing up on you immediately. They may not be able to do super complicated products, but as a basic product running, that's about right.

Once you have that framework in mind, you start hiring. You're like, "Okay, a PM and a designer". Then you see, "Do I maybe need two designers? Maybe the space we're in is more design-heavy". In big tech, normally you have about one PM to eight to 12 engineers. For us, it's one to three. This is a much higher PM to engineer ratio. But that makes sense because our products are smaller, but we have a much more complicated bureaucratic environment to deal with. If I previously tried to have one PM to like 10 engineers, it didn't work out well for me, because you have all these engineers running around building things that you didn't really need to build. And then the PM wasn't able to support them and put enough things in front of them. And you just get blocked by enough bureaucratic blockers that all your 10 engineers get choked anyway.

We did this for a while, and then I realized as I applied it to FormSG—our form building tool for government—what started happening was that the PM and the engineers and designers started spending all their time answering user support queries and just teaching people to onboard. And they weren't able to do what they wanted to do, which was engineering product. When a team is small, engineers and PMs should help people onboard so they know their users. But once you've got 50,000 government forms on a platform and a thousand government officers making new forms every day, the team of five is just going to get buried in them.

We came up with a new role called product operations. It wasn't me who came up with it. We hired a couple of people onboard during COVID who were helping out with various things. They were just volunteering from agencies. I didn't even have a word for it yet. "That seems useful. Can you do that for this team too?". They were the first of what became product operations. There was this role that you could see forming. We put a person there, and that's how you came up with that position. We now have a couple dozen product operations officers doing this. And we had to hire people from very different backgrounds to come to this. You've got people from other ministries and other government agencies. You've got people from delivery companies and SIA. They all have very different backgrounds, but you knew what you wanted, and you were trying to form up the role. For the first year or so when it was around, it wasn't very clear; people were just helping out with it. But as time went on, you crystallized what you need and codified it. The whole point of that story is that it is a much more empirical, hands-on process to design these things rather than a theoretical one. I don't think you can sit in a room, meditate, and be like, "These are the five elements that we need to put together to form Captain Planet". You need to actually have some sense of the mix, go out, try it, and correct it.

Jeremy Au (42:38) It's really good because the crux of it is that we need to figure out what makes a team actually perform, right?. Rock stars are not independent of it, and we can't prejudge a rock star's trajectory.

Li Hongyi (42:48) Intelligence is important, but I put a lot less weight on intelligence than I do nowadays. I think if your organization as a whole does not really know what it's doing, and every scenario and every situation is very ambiguous and vague, then obviously someone with very high intelligence will go there, figure out this new puzzle every time, and do reasonably well. But the clearer you are around what you need to do, I actually found that you have some people who are really intelligent versus someone who's just really, really clear about what they're trying to execute with a team and really have the right values and are just trying to be helpful where they can, and they tend to do pretty well, too. There will obviously be people who are very talented as a whole, but if your entire strategy is relying on just generic rock stars, your organization's strategy probably isn't well defined.

Jeremy Au (43:35) And I think what's interesting is you mentioned right games and wrong games. Can you share more about that?

Li Hongyi (43:41) This is something I'll be wanting to write about, but I haven't quite crystallized it yet. So I apologize if it's not fully codified. You see a lot of organizations and teams where they want to be high performing, right?. And they'll try this strategy of, "Let's go really consumer-centric," or they'll focus on enterprise systems, or "Let's go to the cloud," or "Let's build platforms". And they'll keep fussing around at a strategic level where actually the problem is that they haven't invested enough in their capabilities to deliver.

No shade on Singapore, but I don't think anyone would disagree that if we had a Premier League team play against a Singapore team, they would destroy us no matter what strategy we played. Not saying our guys aren't good, but they are just way better. They can play 4-4-2, 4-3-3, they can play whatever, and they would probably just destroy us. The strategy is not going to make a difference if there's such a wide gap in capability. And then the question is, why is there a gap? The short answer is that because that's where all the money is. Because the English Premier League—there's a ton of money there. If you want the best soccer players, you go there to play for the teams. There's a lot of pressure and all the things to try and really get you to perform. It's there, and not to say that our team doesn't train hard, but the kind of accountability and support and pressure on that is literally several orders of magnitude different.

So when you view it this way, actually what I find is that for a lot of people trying to get their organization to perform, they're spending all their time thinking about, "Should we do this, should we do that?". And actually the problem is that they haven't built enough capability. And so they try to build capability, but it's tough because they haven't set up the right accountability structures. I've spoken to people trying to teach full-stack engineering, Agile development, or we're trying to teach people to change how they do product requirements or something like that. And you can try to tell people to train all these things, but without the accountability structure, without the pressure for them to do it, they're like, "Okay, don't get me wrong, that's nice, but of all the things I need to do, that's really not a priority right now". Because if my priority is not building capability, my priority is just doing whatever my boss is angry at me for most recently, then I'll just do that.

For different teams, I start from accountability even before changing anything else. I'm not giving any direction. I'm not giving any strategic shifts. Everyone just continues their work as normal. The first thing I'm going to do is just make sure I get visibility into what we're delivering. Then define a few metrics and a few goals in collaboration with the team: "This is where we are, I am clear on that now, and this is what I'm going to hold us accountable to". Once you have that, you are not expecting the team to dramatically improve overnight. Putting pressure on people itself does not suddenly make them transform. But that visibility over time then allows you to start saying, "Okay, given that we're not doing these things well, what do we need to fix?". Are we managing our deployments or testing before we roll out? We don't know how to do that. So when I say, "Okay, let's build those capabilities," because it's anchored in accountability, it sticks a lot better. And once you've got the accountability that lets you build the capability, then once you're comfortable having all those skills up, you can talk about strategy.

So to your point, it is not that you're choosing the wrong strategy, it's that you're playing the wrong game. You're spending all your time fussing around at this strategic level of, "Should we go consumer-centric, developer-centric, or enterprise-centric or whatever?". But do you have the capability to execute on that?. If you do, great, but if you don't, you need the right accountability structures in place. The reason there's so much talent in AI right now is because there is a lot of money in it. And not just a lot of money, but very importantly, there are a lot of measurement mechanisms to evaluate the quality of models. It is very clear when a model is performing better than other models, and there's a lot of money incentivized to do so. Therefore, all the talent who could do it and all the techniques and pressure to do it go there. And therefore, you have different strategies that they're playing, but only because you have those fundamentals.

Jeremy Au (47:21) Last question from me is we're talking a little bit about AI. Are there any AI tools you've been playing with or models?

Li Hongyi (47:28) Everyone on the team uses AI, quite organically actually. We didn't even have to push everyone to do it, just because if you're an engineer, you naturally come across this stuff; it makes the job easier. The designers are starting to use some tools as well. I was mucking around with Cursor, both for coding as well as for writing a little bit. I found that it's pretty good at very basic engineering tasks, but it tends to stumble on more complex ones, which makes sense. But for writing, it's basically useless. It can generate content, but the models are bad at writing information-dense material. I just gave up because I have to rewrite everything it does anyway. My view of it is that I think it's a useful tool, but at least my experience with my teams is that when the teams are very clear, when there's a lot of pressure and accountability to deliver, they naturally find tools to help them. I don't need to do anything. I think if you're going around just being like, "Everybody in the company is going to use AI because I say so," that's trying to force capability. But actually, the problem is that maybe there isn't the right accountability on the right deliverable. So that's why they're not bothering. If AI was useful, I found that it tends to happen quite organically.

Jeremy Au (48:34) Amazing. I love to wrap things up by summarizing the takeaways. Thanks for sharing about performance. A very good way of defining what is performance at an individual level, at a team level, at an organizational level, at a North Star level. But also how it gets lost in communication mechanisms or dynamics. Thanks for sharing your mechanisms and systems: performance review, promotions, financial compensation, levers to get the right outcomes and deliverables. To keep individuals alive, productive, happy, and not burned out. A good, holistic view. Thanks for sharing your learning journey. I like the part where you talked about the scope role. Having a perfect office designer and a perfect enterprise software manager—it's a difficult combination. But it was nice to hear some of that personal learning journey as a leader.

Li Hongyi (49:20) Thanks for having me. I find these things interesting to me, so I hope other people find them useful.

Jeremy Au (49:25) I found it interesting, and there are a few things I can tweak on my end as well.

Li Hongyi (49:27) Thanks for having me, Jeremy. Good to see you again.