David Chui, Tribe Lead, shares how he inspires engineers at ServiceRocket
Q: What is your name, what office do you work out of, and how long have you been at ServiceRocket?
A: My name is David and I work for ServiceRocket in Kuala Lumpur. At this point, it might be worth it to mention my surname too — Chui. It helps to stand out from the seas of Davids. Also, contrary to what Google may say about me, I am not working for the California State Assembly.
I’ve been with ServiceRocket for quite some time, even before it was called ServiceRocket. 12 years, and maybe a little more.
Q: What is your current role at ServiceRocket and how did you transition into it?
A: I’m currently a Tribe Lead of one of the engineering divisions in ServiceRocket — within my tribe, there are 15 engineers. My responsibilities are almost synonymous to an Engineering Manager. My job here is to help engineers grow while at the same time supporting the team to achieve business objectives.
I was a developer before I became Tribe Lead. I was coding (actually, still am) for many years prior to it. On the question of how I became — perhaps the company figured out I wasn’t much of a coder at all. Look up Dilbert’s principle.
But on a more serious note:
I still remember the day I was interviewed by our now CEO — the company was much smaller back then. I could recall the day I went to CustomWare (ServiceRocket) for an interview. Coming from a project based background, where I was helping to build one project, finish it and move on to the next project, I felt like I really wanted to see how a proper engineering team codes and manages products.
Robert Castaneda (who we call Rob) interviewed me that day. I told him what I wanted to do and he assured me I will definitely get that. Great — the deal is half done. Next thing is, how can I pass the interview? For a company like this, I was expecting very stringent technical tests. But all Rob did was to ask me to arrange a bunch of shapes on a table. That was how I got the job.
Was Rob a lousy interviewer? Probably. But it worked well for me.
Fast forward a few years later, through building and maintaining many apps that run on our partners’ platforms, I have become a better engineer. I could see, as an engineer, how each line of code I write can contribute to the success of a business — how it affects speed of development, maintainability, number of support cases, etc. It’s an incredible validation to see how effort was reflected on how well the products did.
When Rob presented to me opportunity to be part of a team to build a new platform for the company, Learndot, I took it. I wanted to take all that I’ve learned and see what I can do with it, on our own stuff. I was excited then, and I still am now.
However, building a platform is a very different beast when compared to building smaller apps. I realised that as an individual, my contributions to a platform were rather limited because the scale of the problems were much larger. The only way to do it — is to have a team of crack engineers working towards the same causes.
When the Tribe Lead opportunity was opened — I took it on. I wanted to help aspiring engineers, grow them and support them, so we can make significant positive impacts to the business.
Q: Given the number of years being in your current role as a Tribe Lead, what is the most important lesson learned that you would like to share?
A: I think for any engineer who is thinking of transitioning to a management role, I would like to highlight that it is not really a transition. It’s a total career reset.
You start from scratch again. You no longer get the everyday satisfaction of coming up with a piece of code and knowing you’ve done a job well at the end of the day. You will spend most of your days talking to people, often with people outside of engineering. You will context switch, a lot. You will have days when in one minute, you will talk about high level strategic items and the next minute, having to context switch to what engineers are talking at the line of code level. You will also have a lot of meetings.
Sounds like a deal breaker? Maybe, to some… and perhaps it’s better that way.
Management is not for everybody. It is not a career progression. It’s a choice of career. In ServiceRocket — we have room for growth for people who want to go on the technical or the non-technical track. Not one is above the other — you want management, it’s your choice. And with any management role — you are in charge, but you are not in control. Cliche, but true.
However, if you relish the moments when great results are achieved without you coding directly for it, and seeing how the engineers have done it better than you could yourself, this role may be for you.
Q: What is the most memorable experience that you share with teams that you work with?
A: There are days when you come into work and the teams share what they’ve completed. When you get to test or play with what they’ve done and you wonder in the back of your mind — “how the hell did they manage to do this?” — those are the moments I look forward to in my job.
One such example that I can share, is that one of our engineers figured out a way to automate much of the manual work we needed to do to bring a new customers’ sites up. The manual work included changing a number of configuration files meticulously by hand, hooking up with web services and more. As a result, what required at least a day was reduced to just minutes. Mind blown.
Getting to know about the tool that the engineer created was amazing enough. Little did I know then that the engineer actually created a video to show how the tool can be used — the execution and the follow through — speechless.
Q: What have you done / accomplished in ServiceRocket that you are proud of? When did you do this? What was the impact?
A: There are many things in ServiceRocket that I’m proud of. But in most of them, I don’t think I’m actually the one that accomplished them; All I can say is that I contributed to them, perhaps, at least, a little bit.
I’ve been very fortunate to work with some very talented engineers. Through working with them on many challenges, talking to them about many topics and recovering from many failures, I could definitely see that some engineers have grown. Some of them have become leaders themselves.
Of course, their growth are attributed to them, but having had the privilege to be part of their journeys and having seen how they’ve changed… These are some of the stories I would proudly share with others.
Q: How do you inspire engineers at ServiceRocket as a leader in bringing the best out of them?
A: At ServiceRocket, we have the structure and systems that allow any engineer to own problems and grow. One of the most effective ways, in my experience, to help engineers grow, is to empower them to own problems and their corresponding solutions.
When tasked with problems to solve, communicate to engineers how the end should look like. Let them decide how the problem could be solved, but along the way, challenge their ideas or suggestions. Make them think.
And don’t forget to let them know if they’ve done a good job.
Q: How would you describe the culture in ServiceRocket when it comes to handling successes, failures and setbacks throughout your career as Tribe Lead?
A: As a company, ServiceRocket is very honest with itself. We are a relatively young company, and we’ve transformed ourselves a few times since we were established. As a consequence, we realised there is so much that we don’t know, collectively as an organisation, down to each individual in the company.
We know we will make mistakes. We know that if we punish mistakes, we will not be the wiser.
In engineering, especially — the culture of continuous improvements is very profound. We openly discuss about things that went well and those that didn’t go so well, regularly. We acknowledge mistakes and we think about how we can prevent them in the future. In such rituals, we always ask why or how a problem occurred — we don’t ask who. When you’ve asked enough how or why, you will get to the culprit.
And yet, there is not one instance that when we do that exercise, the culprit turned out to be an individual.
Engineers see mistakes, and I mean it, as opportunities to make improvements. The improvements could be code changes, new tools, new processes and so forth.
Q: Over the years, you would have learned and adopted many different principles. Which of it do you live by till today? Why?
A: It’s true, that over the years, I, like any other normal human being, would’ve subscribed and unsubscribed from various principles. The one thing that really stuck to me, especially in recent years, is probably cliche, as well and I’m unsure of its origins.
No one wants to do a bad job, no matter what the intention is. If you’re a good person, you do the best you can. If you’re a wicked person, you do the worst you can. But nobody takes on a job thinking — “y’know what, I just want to suck at this today”.
By that, it makes me to think how I can position people for success. It by no means is an easy thing to do, but it’s when it gets really challenging that this will return and help to make the right decisions.
Q: If there is one thing you could do now to inspire and drive the teams you are currently leading, what would that be?
A: I think I could impress them with my excellent Street Fighter skills.
But in all seriousness, I don’t think I’ve left any avenues that I’m aware of, untouched, when it comes to driving and inspiring people. It’s not like I sit there holding on to an “ultimate” move, just waiting for the right moment. As a manager, you use all available avenues, all the time.
As leaders, whatever that we do and say will have a profound effect on our people. If you want people inspired, get inspired. If you want people to be motivated, be motivated yourself. Lead by example.
Q: What are your hobbies? Or what can we find you doing outside of work?
A: I am a car guy. In some of my free time, I read and watch videos about cars. In other times, I join some track days. It’s not the competition that I’m after — in fact, I prefer track days that would naturally have lesser participants. I really like going against the time.. Besides the rush, I guess I really enjoy the perfectable aspect of it.
On the track is, for me, one of the best way to experience systemic improvements — it doesn’t matter if you have the best tyres if the brakes are not up to the job. It doesn’t matter if the engine is highly tuned but it doesn’t have adequate cooling. It doesn’t matter if the car is setup perfectly, but the driver messes up the lines.
To get a good lap time — everything has to come together.
In the rest of my free time, I spend it “refactoring” myself. I find it strangely satisfying — that my email filters work better, that my calendar gets less cluttered, that my task lists are being emptied, my spreadsheets simplified and so forth.
