Evolving Responsibilities of a Technical Founder with Timothy Liu, Co-founder and VP Engineering

Name: Timothy Liu
Title: Co-founder & VP Engineering
Github: pseudonumos
Stack Overflow: timothy-liu
Hobbies: eating, cooking, bouldering, gaming, soccer, movies/TV
Favorite ice cream flavor: strawberry, Swiss Milk Chocolate (at Fenton’s Creamery)

Tim is a Co-founder and the VP of Engineering at Kloudless. Previously, he worked at IBM and NASA Jet Propulsion Laboratory. 

 

Going from a team of 3 to now 35, how have you seen your responsibilities change as the team has grown? 

As the team has grown, some responsibilities have stayed the same, others have shifted with regards to execution, and finally new responsibilities have appeared.

New: I have never had to manage others before, but over the past few years, I have had any number between 4 and 8 direct reports.  Hiring is also an enormous responsibility.

Shifted: Startups are all about execution, and the overall responsibility for the engineering/product team is to make sure we meet our deadlines and satisfy our customers. With a small team of engineers (dthorman, Vinod, and I), we all had to contribute to all aspects of the product life cycle from requirements, design, implementation, testing, and support. As the team has grown, we’ve delegated more and more of each aspect to the engineering team while we are still ultimately responsible for the success of the product.  I still contribute the most on both ends of the life cycle as requirements are often communicated across teams, and support often involve both the technical details and client needs.

Same: The responsibility that has largely stayed the same has been making sure that the company is moving forward.  I have always been particular towards numbers and determining the performance/effectiveness of individuals and teams.

 

Are there particular milestones that clearly marked the need for you to shift your role within the company?

A few milestones indicated the shift of my role within the company:

• opening up a Taipei office
• hiring a Director of Engineering for the Taipei office
• building out the sales and marketing teams

 

How have your priorities changed, if they’ve changed at all?

This has been said everywhere on the internet, but founders should focus on things only founders can do. Delegate the rest. We’ve focused on any of determining overall product and company direction, handling partnership conversations, deciding the leadership team, determining go-to-market strategy, and measuring the effectiveness of different organizations through metrics. A lot of decisions are made with incomplete information, and founders are best positioned to intuit decisions based on all of the inputs from the rest of the company. Personally, I would say my priorities are constantly shifting based on what the company needs at the given time that only I can contribute to and be responsible for.  Lately, I’ve focused on assisting with product direction, evaluating the current go-to-market strategy, and building out the metrics framework for the company.

 

What was the most challenging thing about this transition for the team? What about for you personally?

As one of the more process-oriented co-founders, the most challenging idea to tackle is scale. If you scale too early, you’re wasting time thinking about processes when you should be simply executing. If you scale too late, your team becomes inefficient (working on things that are of no importance), and people will eventually leave. Initially, I found the idea of coding less extremely unappealing. Often times I have to focus on the why rather than the how or what.

 

As you delegated, you’ve taken on a lot of management responsibilities. How did you develop yourself as a manager?

I can’t say if I’m a great or even good manager, but I do credit a lot of my development to my past experiences.  I have had many leaders, and I try to take something positive (replicate) and/or negative (correct) from each one. I competed in soccer and drumline when I was younger, which provided me opportunities to learn from leaders and to be a leader. I learned about teamwork and competing for the success of the overall team. I also noticed the benefits and pitfalls of an extremely disciplinary structure. In college, I was part of a Christian fellowship that emphasized discipleship (1-1 mentoring), and I’ve learned a lot from being a mentee and a mentor. College students can be surprisingly mature and immature at the same time, so I experienced many different situations in the realm of personal relationships. I also learned about different levels of sacrifice regarding time, effort, and resources.

 

What is your approach to engineering management specifically?

I find engineering management a combination of two overarching categories: project management and people management. There are many philosophies around project management, and I would say we’ve experimented with most like scrum, kanban, and scrumban for the engineering team and various forms of user testing for the rest of the product team (empathize, design, ideate, prototype, test, and repeat). The main takeaway would be to listen to feedback and keep improving the process. We’ve settled on scrumban and have developed our own user testing framework. 

A team of four, eight, twelve, or more engineers will also need different things to perform well. In the beginning, it’s easy to assign individual tasks and have everyone contribute to the project. Later on, we created better structure to allow for engineers to collaborate on multiple projects. Lastly, it’s always a good idea to have more than one engineer knowledgeable about a certain area so as not to create bottlenecks. Therefore, we hold “office hours” for engineers to present and transfer knowledge for others to learn. 

As for people management, I would like to credit the engineering team because they’re great to work with. However, I do go into more detail about professional development, which we highly value at Kloudless elsewhere.

 

When you’re coding, it’s easy to measure the progress you’re making. How do you know you’re making an impact as a manager?

Engineering management is a combination of project and people management. Project management is more objective, and the entire engineering team is aware that there are goals and deadlines we need to hit. We came up with a comprehensive performance evaluation that aims to be as objective as possible. 

If you see the engineering team improving the product across the board, that is definitely a success. There is no better feeling for an engineer than to see more and more customers love what you’ve built and want more. We also value professional development at Kloudless, so another success metric would be to see engineers improving themselves. Whether it means increasing domain expertise, taking on new responsibilities for the organization, or learning new skills, this is what we want each and every person on the engineering team to achieve. We evaluate engineers quarterly and are open to engineers moving across teams (full-stack, back-end, and devops). We also have a high success rate of internally promoting within the organization.

 

What are some of your biggest challenges now?

Go-to-market! This is always an ongoing challenge for any startup.

Management: On the engineering team, our reports-to-manager ratio is too high. We’re working to find or develop the next engineering managers that will help us scale the team.

Recruiting: I feel like at the end of the day it’s a numbers game. One thing that has helped a lot to recruit at least engineers in Taipei is setting a good “culture”. Most of the people who want to join a foreign company is for the culture.

 

A lot of your time is now devoted to managing the engineering team and setting others up for success. Do you still get to code?

No. I mentioned that this felt unappealing earlier because at the time I wanted to continue impacting the company the best way I knew how to by coding. By not coding anymore, I felt that my greatest strength was being taken away. However, I soon learned (and still continue to learn!) that there are many other ways for me to make a big impact on the company.

 

If you ever get back to code.. what are your favorite programming languages, framework, and development tools?

I still claim that my two favorite languages are C (for its speed and simplicity) and Python (for its ease of use). However, most of the problems I tackle at Kloudless are unsurprisingly unrelated to coding, so I don’t spend as much time keeping up to date with the newest frameworks or development tools outside of reading HN.

 

What do you do for fun outside of work?

Most of my hobbies are ways of destressing, but like many of my classmates from Cal, I enjoy bouldering. Bouldering has “problems” (the sequence of moves that a climber performs to complete the climb), which correlates well with a problem-solving mindset. Plus, it’s a great full body workout!