I had the opportunity to participate in an awesome webinar organised by MDEC. Although I’m unable to embed the video recording here, I hope the text summary would help any aspiring CTOs grow and lead their team to build a successful product.
04:30 – Speaker background
- Been in the CTO position throughout his professional career
- Started without any experience in CTO only technical background
- Failed at first with all the different culture. After the team scaled down and restructured, able to restart the leadership journey
- Experienced working with Youthsays (now Says), worked with MOL, and then moving on to Fave
06:50 – What are the expectations of a CTO especially for a startup?
- Expectations are different based on team size and business expectations
- Most of the time, founder of companies who tries to look for CTO are probably thinking of wanting a good engineer.
- Thus, you should be very clear what you want and what do you really need?
- The title at this point doesn’t matter. When you’re a team of two, you can name the position anything but most importantly, you know what you want in the hire.
- Need to understand that to be a good leader, you need to be a good follower. Only then, you know how to empathize and lead properly
- To be a CTO, it’s not going to be easy. Technical is not only the thing to think about. Understanding the business is crucial to have a grasp of the business and also leading people. Whatever decision you made will impact someone else’s life.
13:15 – CTO doesn’t mean you need to be a strong programmer.
- Becoming a good programmer is not the key skill set to become a good CTO. What’s important is understanding technology as a whole especially in the context of your startup and holistically understand how things work (people, product, business). As much as the technology is important, the operation is important as well.
- When you first started (team of 5), even though your role is a CTO, you are a team lead. You’re leading a team to focus on right technical directions and the processes around it and making sure people follows it. As you scale up (team of 50), the role of CTO starts to evolve.
17:50 – It is important to understand expectations of CTO and align them with CEO/founder
- Understand your role
- You may not have practiced your technical skills for a while and you might need to start hiring. Understand where you’re at, the stage of startup, what sort of things you need to deliver and where you should be within the company.
- Understanding the expectations of the business
- The initial goal during a startup is to figure steps to survive the business i.e. raise fund/seed fund, extend business run rate, make profit etc
- It’s not just about writing codes
- Once you understand the goal, then you realized you cannot do it alone and need to hire people. Hiring is always tricky. Whenever you hire, it may never be enough.
- The product that you plan to build will never have enough resource for you to build it. As your team expands, the expansion of your product is also expanding.
23:30 – Rules in hiring
- Don’t care about qualifications. Hire good engineers, less about their background
- They are those who really care about programming and care about creating good stuff. They don’t do it because of what they have been taught.
- So far, these people who’re hired based on my experience, tend to do more during their delivery and learn faster.
25:50 – Interview process
- Hiring the right people at the right time is very important
- What type of engineer you want right now?
Example when we first startup, we want someone who is jack of all trades. Even if they are not there yet, but there is someone to pick up all these things.
- As you grow, then you would want someone that is specialize in the role e.g financial tech
- You might want to hire someone who can grow and learn with you rather than someone who will tell you what to do.
- Know your business limitations. I would optimize to hire someone who has potential to grow rather than optimize for someone who’s been there done that and knows everything whom you can hire much later when you have better financial backing.
- Hiring someone with limited experience, it’s much easier to shape the culture. Compared to someone who has 10 years of experience, probably have different ways of doing things and probably will have a conflict.
- But if it’s someone who is like a mentor/coach whom you learn from them, then it’s fine.
30:00 – Management
- Engineering level – just to define what level you are as an engineer and a salary band ties to it i.e. E1,E2,E3,E4,E5…
- It’s hard to tell when you just startup but as you grow the definition of each engineering level will change.
- Once you grow, you need to pay people fairly, then having engineering level and salary band helps.
- As your team grows in terms of skills and experience, at this rate, probably your engineering level is too easy in terms of expectations. Then you start to expand the expectations for each level (increasing baseline)
- So, during hiring at least the lowest level, they are also at the higher level than last year. Of course, the minimum level shouldn’t move too big because you still want to groom people and hire the right potential. So, the middle level will expand more.
34:30 – Productivity
- How to measure engineer’s productivity? It’s tricky and hard because engineering is a creative process i.e. cannot measure how many lines of codes committed by engineer.
- Normally, measure the output of the outcome i.e. delivery, how good are you at estimation etc
- It’s fine to be slow as long they’re consistent in estimating. If they’re inconsistent especially in estimation, it’s hard to predict how fast you can launch something or when certain things can be delivered
- At early stage may be hard as the project just starting and are new, but as the team get used to it and a lot of familiarity, then you should expect more on their estimation i.e. 80% hit rate.
- Don’t make them do things that are less productive e.g. too many meetings. Be more objective and very clear during meetings. Be methodical on how to solve it like how you choose the technology to solve it, make sure there’s a framework around it. So that it becomes like more consistent and more productive.
38:00 – Managing remote team
- We try to introduce more asynchronous communication where we don’t expect immediate reply from anyone. We do more like constructive questions i.e. everything is detailed out.
- This can also be used as a documentation later on where if someone joins the company, they can almost feel all the knowledge of the engineers in one place i.e Wiki, Forum etc. More things written down rather than having calls where things are not recorded.
- Trust your team. Whenever hire someone, we start with 100% trust until proven otherwise. Believe in the people we hire. Believe everyone is doing things in their best intention.
- Rule is you can do whatever you want within this constraint, as long you are not a blocker to anyone.
41:58 – Silo
- Silo will happen regardless. We don’t expect everyone to know everything but we do expect everyone to know at least high level of how everything else works.
- Do sharing session e.g. every 2 weeks. Have everyone to present something or projects they are working on. Try to involve other teams in certain technical decision to get fresh eyes and knowledge transfer across different teams.
- Again, documentations have to be available throughout entire team. If things are written down even though not complete, at least there are certain knowledge that people can learn.
- We don’t try to fight silo, we try to work within it. Try to distribute knowledge as much possible
44:00 – Quality
- Quality is quite subjective. I would not try to assign a value to a quality, rather focus on the characteristic of the engineers that we hired to ensure that they always strive for better quality.
- Characteristics of people we hired:
- One who really care about the codes and take pride when they solved problems
- One who is really curious and really wants to understand how certain things work. That’s how you get things to be better.
- One who is more adaptable. Sometimes we question should we cut some slack where we do something that is not optimal in order to achieve the business goal. There are times the answer is no if the impact is throughout, sometimes it’s minimum impact then it’s fine. This person should be able to accept that, someone who is more realistic.
- One who codes for the future. When they code, they are think about the readability of codes 6 months down the road and maintainability. One who writes code for their team members.
- Characteristics of people we hired:
48:00 – Getting the team to focus/prioritize
- Prioritize as if you have a single engineer. If there’s only one person to run things, how do you prioritize it. You can’t run things in parallel, you need to choose from top to bottom, doesn’t matter if you have 3 or 5 teams.
- If you’re thinking of splitting things into each team, that’s not prioritizing, that’s just slotting it into teams where you see fit.
49:20 – Expectations of business board meeting
- What’s important to the investors/VC perspective are not so much about the technicality of things, they care more on high level things like:
- are we choosing the right technology?
- have we hired the right people?
- are we delivering things at the right time?
- You could also highlight certain incidents or amazing things you’ve done
50:50 – Working with others
- Allow engineers to join all meetings even without any invites
- Reason being, sometimes unless we’ve worked with engineers for a while, we probably don’t know what to ask. You probably know you have a problem but you don’t know how to solve it. And even if you know how to solve it, you may know how to solve it within your domain and not using the right technology or right tools
- So, you want engineers to always go out there and try to give values and help others to solve problems
52:00 – Keeping the engineers
- As a leader:
- You need to understand the aspirations of your team members i.e what they want to be, what are their goals etc
- What are you doing to help them get that? As much as possible you want to align your goals towards the business goals so then you are growing. When you are growing, the business is growing.
54:08 – Q&A
- 54:49 – What is your biggest mistake in your career and how did you overcome that?
My early mistake was not being honest with the team members. Honest in the sense if someone not doing well, they don’t know about it and eventually have to let them go. During the startup, most of the people I hired were my friends. When they make mistakes, I just casually talk about it, rather than explicitly mentioned these are the things to improve. This mistake leads to more toxic behavior within the team.
- 55:44 – What is your biggest achievement? How did you move about to achieve that?
People that I led, seeing how they grow from intern to team lead or someone who join bigger companies. Especially someone who worked with me before, left and then now we can talk at the same level as CTO rather than talking like a coach/mentor position.
- 56:40 – How do you rate Malaysian IT grads vs Foreign grads like Vietnam, India, Sri Lanka, or Eastern Europe? In terms of price, experience, productivity.
We worked with people from all over the place. I wouldn’t say there are groups that are better than others. But there is some certain biasness to certain groups. E.g. engineers from Vietnam, they are really technical. From Indonesia, they are more towards products-minded engineers. From India, they are hardworking engineers.
This is really contextual, different economic situations in different countries, ended up sway the salary cost. Wouldn’t say someone really good from India will get lower pay in Malaysia. Generally, IT grads we hire from Malaysia and for other countries, we hire someone with experience.
- 1:00:20 – Why do you think most of our engineer talent lack the entrepreneurial mindset/skills? What are your tips to change that?
I would disagree with that. Generally, it depends on your lens and focus. Most of the interviewees that I got have the strong entrepreneur mindship. Entrepreneur here doesn’t mean just in terms of business, in terms of like getting things done with their entrepreneur quality and not necessarily starting a new business.
- 1:02:00 – Top 3 metrics that you for to the individuals you hire
- Someone who can learn something fast
- Someone who can articulate things well
- Someone who is curious
- 1:03:15 – How to make the new hires understand their role and allow them to operate and think by themselves?
- Know how the team operates? Maybe they are not given enough autonomy to do things, hence they are waiting for things to be done. Maybe it is not communicated clearly to them or maybe they are not allowed to do all this thing.
- Have a chat with this person. Your level is not defined by your experience. Reflect back what problems you’re solving to show me what level you are
- Example, if you’re solving a specific problem e.g. build a login page.
- Higher level, how do I get people to login. There’s no right way of doing it. If you’re solving it you probably will be a bit senior or team lead level.
- One level higher than that, problem that is unknown. You look at the business, we don’t know what’s the problem, maybe this is one area that we need to solve. That’s operating more like leadership role.
- We need to start to have the conversation and see what’s going on and figure out why they have to behave that way i.e. is it the processes or they just couldn’t believe they could operate at that level, or maybe they are just incompetent etc
- 1:06:19 – Do you sacrifice security requirements for faster delivery? What are the things that are generally acceptable to take a blind eye to at the beginning and address it a bit later?
- Up to the company decisions to apply the risk they are willing to take
- Build a risk level i.e. what you’re willing to accept and what you’re not willing to accept
- Determine what are the criteria that the company care about and assign value to it. i.e. direct losses, reputations, lawsuits, mission/vision etc
- 1:09:40 – How would you handle a vaccine registration website?
- If the website can handle 1 million registration in one hour, it’s doing a good job there.
- What’s not fine is probably the user experience. We know limited about the backend of it, but we know about the user experience when using the website.
- Manage expectations well e.g. Mcdonald put them in waiting room, show numbers in queue etc give users a choice whether to wait or not.
- In terms of speed, you can manage better with better user experience. Not much technical can be done.
- 1:12:20 – Would you mind expressing your experience working with Joel?
- One good thing about him is lack of ego even though with all the success that we’ve done.
- He won’t be someone that will stick around just because he is the CEO and say you should do this. Even when he wants to do it his ways, he would convince each person and get their buy ins.
- He’s subtler in how he operates. He’s less about dictatorship.
- 1:14:00 – What kind of relationship you have as a CTO with the CEO in Fave?
- We are friends and I’m reporting to him. Almost the same questions how do you work with a friend. Knowing that line we shouldn’t cross between friendship and business.
- Communication is key. Things are always back and forth. We love to brainstorm stuff just to keep the spirit going, whether to build it or not.
- Challenging each other over time. You don’t want to assume he is right. He can be wrong multiple times too.
Last advice
As a leader, you are not a single track anymore. Technical is not the only track you should be concern about, understanding business, people, products, strategies, these are the tools and skill sets in order for you to become a good leader.
Last piece, it’s always about the people not just about you. Respect them, understand them. Treat them like human and that’s how you can go far as a leader.
