From senior to lead (Part 1 of 2)

For many designers and software engineers in the tech industry, career progression almost always involves the idea of switching lanes to some sort of a management ’track’. The thought of doing less technical work puts off many people who have dedicated their lives to craftsmanship and delivering high-quality work. In this article, I’ll share my opinion on what I think the core ingredients for being a lead are, and shed some light on what the work of a leader entails. This piece was first drafted in October 2025, and took roughly a year to finish as it comes straight from my heart.

Needless to say, a lead is already a senior as a baseline. Many ideas in ‘Growing from mid to senior’ apply to being a lead, so read it again for a refresher. One good way to begin thinking about becoming a lead is imagining yourself in a group of peers, all of whom are equally capable and experienced. How do you pick someone from within to lead the entire group?

What defines a leader boils down to the ability to choose your team’s focus. You’ve probably heard of this phrase a lot:

Doing the right things, the right way.

Being a leader is all about choosing what those right things are, and committing to them. The bigger your team, the harder it is.

Point of view

The act of choosing requires a perspective on where things are going, and an opinion on what to do about it. What should your team be working on for the next 3, 6 or 12 months? That work has yet to be defined, and no one’s gonna hand it to you on a silver platter. More importantly, what is it that you truly believe in and want to focus your team on, regardless of what anyone says, or even if anyone says anything at all?

As a leader, you can’t let other people dictate your team’s portfolio where your expertise is concerned. Strong seniors tend to struggle with this because they have gotten used to helping others, working horizontally, collaborating and being rewarded for it. They got to where they are because of their craft and have succeeded in delivering value that way, which feels good. As a result, their next year’s plan is either dominated by a backlog of requests from other people, or a todo list completely derived from OKRs trickled down from the top. Year in, year out.

Absorbing leadership’s plan and requests is not the problem here. There are times when it makes sense to do that when all hands are on deck, and the entire business needs to pivot. I get it, but that’s not what I’m talking about. You can be aligned with direction from the top and have your own point of view at the same time. What you need to be careful of is mistaking someone else’s opinion for your own. Your boss’s point of view is not yours.

You are the expert here—you should be driving the conversation around what your domain could bring value to the business. You are managing upwards and telling leadership what outcomes you can promise.

Be careful of borrowed conviction

When leaders take the stage and address their teams, they’re speaking from a position of authority. As a listener, you don’t have certain information that they might be privy to, and it’s easy to just accept whatever they say. We also know that they are smart; that’s why they’re there. All these things add up to lend the impression that they have perfect information and are in the best position to make decisions. And so, when your boss asks you to jump, you instinctively ask “how high?”.

Your boss strongly believes that your team should do X and Y in the next year, and you nod furiously in agreement. Everyone has the best intentions here, there’s no malice involved, the arguments sound correct, and the goals look aligned all the way up to your CEO’s hair strands. You relay the OKRs for the coming year to your team enthusiastically, and this is exactly the point where you failed your boss, yourself, and your team. You’ve become a carrier pigeon, or a ‘meat proxy’ in today’s internet lingo.

It is one thing to work on things just because “management asked for it”, and another to do them because you’re already going to do them anyway, and management just happened to be aligned with it. This is a simple (but hard) problem to solve. Do your homework beforehand and envision the future before anyone tells you what it could look like. Your boss should also be taking your conviction as input into their plans, not just the other way round.

And to know what the future looks like, you need to study and do a lot of homework. A shit ton.

Know a lot of things… and people

You need to know the business well, how it’s doing, where its competitors are, what customers need and where it hurts. You also need to know where the company is going, where it wants to go next, which then trickles down to where your department is going, what other departments are trying to achieve, what other teams in your own department are thinking about, where the workflow and process gaps are… basically every single external force that can impact or influence your team’s trajectory.

So first, master the skill of gaining access to information, and not just that, but also how to maintain continued access. Build trust, reputation, connections and relationships, raise social capital and your standing, exercise those “soft skills” that are often neglected by technical folks so that you can maximise the number of inputs into your plans and your chances of success.

All this information will help you gain clarity about the company’s problem spaces and perhaps put some shape to potential solution spaces. Your domain expertise is the extra information that helps you see them. This is the beginning of deciding where to start from, and where to go next. A to B.

Make plans, many plans

But knowing is not enough. Knowing things does not equate to having an opinion, it is merely the prerequisite. Synthesise the information you have, and make many plans. Then make plans for those plans. You don’t have to reveal everything at once, but you want them in your back pocket because things can change on a dime and the next thing you know, both your boss and team members are looking to you for direction. Commit to the finish line, but be flexible on the way to get there.

While you may only be focused on one thing (or two to three at most), be prepared for multiple ways to achieve the same thing through different means. In fact, don’t count out partial achievements; some things might take a bit longer and it’s not wise to reject a plan just because you can’t achieve it in the ideal sequence you have in your head. Also, don’t just execute one plan at one time; be multithreaded and let multiple approaches play out at their own speeds. Prune the dead ends, and redirect your focus onto the most promising plans.

Reading between the lines

Side note here. We all know that actions speak louder than words. If you full commit to a direction which heavily depends on another team or leader, your future is kinda held hostage by them.

Sometimes, you’ve got to read between the lines, interpret situations accurately and hear what is not said. Do collaborators or sponsors actually have skin in your game? Did they commit resources and budget, or did they waffle, deflect and postpone? If you don’t master this skill, you will—emphatically in Singlish—die also don’t know how you died.

What it looks like in action

Let’s end Part 1 with a real-world example to visualise better. In our Design Standards team, adoption and governance are key measures in our OKRs. Getting every single project team to use our UI libraries correctly and keeping them updated is incredibly challenging, as it’s difficult to coordinate release timelines across international and regional markets, onshore and offshore teams.

My then-boss, Leo, whom I admire and respect a lot, sought out a prominent frontend engineering leader and started building a relationship with him. It turns out that the challenges we faced were similar, which wasn’t apparent at first. Engineers struggled under a mountain of UI debt because business requirements drove the creation of custom UI variants, such as when a payment corridor requires extra work due to differences in countries’ infrastructure and regulations. As in Stewart Brand’s pace layers, our DLS library is not moving at the same speed as what product requires, hence a general resistance to adopt it.

Our solution was to unite our teams and be seen as one governing body. The central frontend engineering team would offer to publish and maintain shared UI libraries for the entire bank, on the basis that only changes coming from the standards team are entertained. Together we provided a paved road, a path of least resistance for business teams to increase their go-to-market speed if they were to use more of the central library as opposed to creating custom UI. We can’t stop you from doing it; we’ll just make it much faster for you if you use the DLS library.

What we did wasn’t something novel or even complex, but that’s expertise bias speaking and a common pitfall designers fall into. It’s so simple and obvious to any designer in the world. “Just have one team and one library lah”. You can create the library, but what if nobody uses it?

What is not obvious is all the work behind the scenes: getting senior leadership’s buy-in (why would they even care about a small UI library?) and to put their weight on it, inserting ourselves into various forums to sell the idea, stepping into estimation exercises to tell teams it could be cheaper, getting business folks to understand why custom UI is expensive, getting QA teams to look for semantic token names instead of raw hex values, telling our product designers that we cannot change a core component tomorrow because it would break someone else’s UI…

That’s what you use those “soft skills” for.

Continue reading in Part 2.