MMS • Mingxi Wu
Article originally posted on InfoQ. Visit InfoQ
Subscribe on:
Transcript
Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today, I’m sitting down with Mingxi Wu. Mingxi, thank you so much for taking the time to talk to us. You are the VP of engineering for TigerGraph. The useful starting point is who’s Mingxi and who’s TigerGraph?
Introductions [00:39]
Mingxi Wu: Thanks, Shane. Hello, everyone. This is Mingxi Wu. I’m currently a VP of engineering at TigerGraph. So I graduated from University of Florida with a PhD specialized in database and data mining. Both topics span my research area. I stay six years in University of Florida, and then my first job is at the Oracle headquarters and I worked in the query optimizer group for three years. And my main job is to fixing optimizer box and creating new features for relational database optimizer. And after that stint, I joined a startup called Turn, and it’s a advertisement startup managing online users. And there, I used Adobe and Spark to manage big data. And after three years at Turn, I joined TigerGraph 2014 and I have been with TigerGraph for six years. And TigerGraph is the market leader in managing graph data and providing real-time insights for connected data. That’s my background.
Shane Hastie: Thank you very much. Now, in your role as VP, one of the things we were talking about was the engineering culture that you have built at TigerGraph. You want to tell us a little bit about that, please?
The TigreGraph engineering culture [02:00]
Mingxi Wu: So at TigerGraph, we really value engineering talent and we really think the engineering culture is first before TigerGraph can get any visible success. And we spend a lot of time to make sure our culture is correct, and we have our company core value published on our website. And also as a engineer leader, I make sure that I provide a full transparency and learning environments for our engineers so that they can continue learning and contribute back to the product.
Shane Hastie: One of the things that you mentioned to me is that through the pandemic, you managed to actually double the size of the team. How do you do that in the remote environment and maintain the company culture, the values that you’re trying to build?
Manage agreements to empower people [02:51]
Mingxi Wu: That’s a very good question. So when the pandemic comes, we just start hiring more team member. Most the position are created to fit the pandemic dynamics. So most engineers hired remotely and they spread out in the country and across the globe. And it’s really a top priority for me and for the company to help the new hire to integrate into the productivity and integrate into the team contribution. And also don’t feel isolated on their home working environments. So what I found is working during this transition is I really focusing on managing agreement instead of managing people. So I do value people. And once I start managing agreements, I found people empowered and they got my trust and they also got a clarity on what they are expected to accomplish for the next quarter. And this mentality really help us to work collaboratively, distributed across the globe. That’s the first thing I did to manage agreements.
Shane Hastie: So let’s delve a little bit further into that if we may. What does it mean to manage agreements rather than managing individuals?
Mingxi Wu: So we actually define a project for each team and the projects are centered around each team’s mission. So, the team crystal clear about what are the top three mission they want to accomplish this quarter. And those missions are written down and across the team shared PowerPoint slides. And then around the written down missions, the manager and the engineers will define or refine the projects, the concrete deliverables. And we write down those concrete deliverables as agreements between managers and engineers. And then we have a process that deliver particular projects. So we start with stage one. So each agreement need to have a design doc and the design doc need to be reviewed by the team.
And then once the project pass the design review, then the engineers and the teammates are working on implementation, sprint , and then they show progress after each week. And then in the end, they will give a presentation and the user document to the technical writer as the final stage. So this agreement across three stages works really well. And engineer are very clear on what the expectation and the product manager and the technical writer understanding what going to be delivered. So this is how we manage agreements.
Shane Hastie: So one of the metaphors that you used when we were talking earlier was the driver versus the passenger mindset. How does that play out?
Driver vs passenger mindset [05:49]
Mingxi Wu: So, this is related to my personal experience. So my first job is at Oracle and Oracle is established database company, and it’s been there for many, many years. So when I first joined Oracle, so my daily job is fixing box and I’m really having a passenger mindset. So whatever my manager asked me to do, I will just accomplish that. But beyond that, I don’t have any extra contribution to the company and I feel very comfortable. So work and life is very balanced. And then coincidentally, I joined a startup world. So ever since I joined my first startup and then TigerGraph is my second startup, my mindset has shifted. So I realized I was sensing urgency every day. And even though I stay at TigerGraph for eight years, my sense of urgency is staying with me for the past eight years, it never fade off.
So I sit back and I realized that I have shifted my mind from passenger side to become a driver and driver means there is no established business there, and there’s no established product there. And at a startup, you are establishing a new market and you are creating a new product that people has not seen before. There’s no established model that you can copycat. So that’s why you feel, oh, there are new issue popping up due to the new product release and there are no new issue to fix. And there are new difficulty that you never encounter until your early adopters share with you. All these challenges accompany you every day. And then in order to take the startup to the next stage, you have to keep a driver mindset to drive the scarce resource at hand, to solve the competing priority, new challenges every day. So that’s what I observe in my past eight years at TigerGraph.
Shane Hastie: So how do you motivate this driver mindset in the people in your team and your engineers?
Motivating the shift [07:58]
Mingxi Wu: So most people, I think including myself, joining a startup with a mindset I can make a good fortune when the company go to IPO. And I joined TigerGraph when I was younger and I was thinking, “Oh, if this hypothesis works, then I can make a million bucks and maybe I can retire.” So that’s really was my mentality eight years ago, but later, my mindset shifted and I see more and more Fortune 100 companies are relying on our technology to maintain their operation, daily business operation. And I feel that what really drive me to full of energy to come to work every day is to really build a sustainable business that benefits and impact people’s life with new technology.
So my mindset shifted because the environment change from a hypothesis to see the concrete deployment of TigerGraph on the people’s daily life affected business, really make me think bigger and think longer. And I share the same mindset journey with my teammates. I tell people that we are coming here to build something last and really improve people’s life. And the IPO, the stock equity rewards will come naturally. So that really make bigger ambitions, but really a good vision that people buy in and then feel proud to contribute.
Shane Hastie: How do you, in your leadership role, get close to your engineers and build trust?
Practical advice on getting close to engineers and building trust
Basically, I found it’s very necessary to have persistent and continuous weekly one-on-one with you, direct report. And I have, I think, 10 direct report now. And I have either in-person one-on-one or remote one-on-one every week on my calendar. And what I did is for people who are not residing on the same city with me, I use Zoom to have recurring weekly meeting with them. And in the weekly meeting, I maintain a shared Google doc with my direct report. And each time before the meeting, the meeting participant, me or the other party, can write any questions, or suggestions, or discussion points in the Google doc. And when we meet, I can open the Google doc and discuss with the participants to solve the problem and reach agreements. And this Google doc will also record a journey of weekly what happens between me and my direct report.
And I found it’s really important to do it consistently throughout the year. And at the end of the year, when I review the Google doc with my direct report, we really accomplished a lot together. And besides a weekly one-on-one, the second thing is I do travel a lot and I travel to different city where we have engineer teams and I meet them quarterly face-to-face and to discuss what’s their project progress, what their suggestions, improving our current product and what’s going on in the other team. So it’s really important for me to travel to different engineer locations to meet them quarterly.
Shane Hastie: How did you achieve that when we weren’t able to travel?
Mingxi Wu: At the beginning, when the airline shut down, I just use Zoom, but once the vaccine roll out and the situation gets better, I travelled. And I do get COVID during one of the travel, but I found that I recovered within three days. So it’s a limitation, but I think the current COVID situation still permit me travel quarterly. If I cannot travel, I just use Zoom weekly.
Shane Hastie: One of the topics that you mentioned again in our conversation earlier was this concept of a role org chart that you said is very different to the HR org chart. What is a role org chart and how does it help in terms of accountability assignment?
Role org chart rather then HR org chart [12:10]
Mingxi Wu: One of the inventions, I call it invention because I never saw it from any textbook, any other warfare book or management book. So what the challenge I met when we got the headcount to build a global technical support team, the question HR asked me is how many people do you need in order to support hundreds of TigerGraph customers across the globe? And we expect to double the customer base and this simple question, how many headcount do I need, stuck me. And I don’t have a answer for that. And then the only resource I have is one technical support manager. And he has three direct report at that point. And I discussed with him on the one-on-one meeting and he said, “Hey, Mingxi, I don’t know if you let me do the ratio calculation. I can calculate how many technical support we need based on our customer count.” But obviously, we know that naive solution will not work.
And then I sit down with him and said, how we divide the function work for TSE? What are the components? What are the roles that you need in order for the technical support team to operate? Then we draw on the shared Google doc and we need how many team function unit for on-prem customer support. We need another team for cloud support, and we need a manager to review weekly tickets. And we need another manager to build a training material and continue to educate the team with the new product release features and so on and so on. So we build a role org chart and each role has a particular well-defined function that role is responsible for. And then we drew that role org chart on PowerPoint, and then we start assigning job description on each role.
And we look at this role org chart, we know it’s organic operation model. And then we estimate how many employee we need for each role. And then we provide an accurate prediction of the head count. And once we work out this role org chart and provide an accurate forecast, we start hiring, and then start writing job descriptions. And then we extend this role org chart methodology to our quality engineering team and also to our development team. It seems to works really well and people in startup come and go, but the role stays, the business operation model stays and the job description stays. And sometime we adjust the role org chart a little bit based on the variation of the business involvement. It really provides clarity and efficiency across HR and our hiring needs.
Shane Hastie: And for the people in the team who receive these role descriptions, how does that help them align their work?
Engaging new people with the role org chart [15:08]
Mingxi Wu: For each sub-engineering team, on their first day, we share the role org chart for the team that the new hire is going to join. And she will get understanding how the team operate and when she needs help, who she can ask for, which role is the right person she can ask for help. And also, she will explore different role description and put their hands in wet on one of the role. And after three months or six months, they can talk to their manager to switch roles. And it’s also provide career opportunity for the engineers and also provide clarity across the engineers.
Shane Hastie: What else do you do to build your team’s cohesiveness and sharing of knowledge?
Providing sustainable learning environments [15:58]
Mingxi Wu: So, one thing that my personal experience I got lost is after I got out of school, I feel I don’t have a guidance what I want to learn, besides doing my daily routine to fix box or some features. I feel a little bit getting lost, because I get used to work curriculum and see my milestone of learning knowledge. And entering the industry does not have that luxury of guidance from school professors. So I want to provide a sustainable learning environments for new graduates, as well as for veterans. And the technology landscape is changing every day. And no one can say their past knowledge will be enough for doing advanced startup job. So what I did is I create a weekly knowledge sharing team meeting, and every Thursday, 9:30 to 10:30, I will fix that timeframe for my engineering team. And one engineer will prepare and then talk about one trouble within technique, and talk about one algorithm complexity problem that they solve, or talk about one research paper they read that can help our product.
And I have been doing that for the past two years. And I think if I’m traveling and I will have substitute host, never miss it. So that persistence got really a good investment on the engineer side. I try to aggregate knowledge of 70 people into the knowledge and sharing cadence and everyone participates. I build that also as part of the personal development KPI. So everyone need to present at least once every half year. And I ask each presenter to share the slides before the meeting so people can get the background, what knowledge they are going to learn, and they can really digest within that one hour where live questions. And this learning environment is part of the investment to the engineer knowledge building, and also help engineer to learn how to present deep technical results to their peers. And I found it’s very effective and people really love it, including our interns.
Shane Hastie: Thank you very much. Some really interesting topics there. If people want to continue the conversation, where do they find you?
Mingxi Wu: They can connect me on LinkedIn, search my name, Mingxi Wu, or they can email me mingxi.wu@tigergraph.com. So my email is just my first name.my last name@tigergraph.com.
Shane Hastie: Thank you so much.
Mingxi Wu: You’re welcome and thank you for providing the opportunities.
Mentioned:
.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.