Justin Kitagawa is VP of Engineering – Platform for Twilio, a Communications Platform as a Service provider and Customer Engagement Platform. Justin began his career as a software engineer at various startups working through different roles such as tech lead, sales engineer, and product manager. He later started his own technical consulting firm working with companies throughout the Bay Area. Prior to joining Twilio nearly 10 years ago, Justin was an engineering leader at GoGrid, a pioneer in the cloud infrastructure service space.
Justin discussed what he enjoys most about working at Twilio and shared his approach for helping his team handle the complexities that come with scaling quickly. He also reflected on his personal leadership style and journey, shared what he looks for when hiring for his team, and offered advice for ICs who are interested in moving into engineering leadership.
What I admire most in any discipline — not just software — is the building aspect. For example, I love and follow film directors and music producers. I view them as creators and builders in cinema and music, respectively. I consider myself to be a multi-generational builder. My great-grandfather was a sushi chef, my grandfather was a carpenter, my father built gold and copper mines, and I’m in software. My mother’s side had builders too — business owners and such. I get really excited about the concept of having an idea and then seeing it through. I’ve always been very execution-oriented.
Earlier in my career, I was a trusted individual contributor who would get things done. I think that one of my fortes that I have is being able to see the forest from the trees. In other words, being able to define the vision and then drive toward it.
My leadership style is very much rooted in, “What did I like when I was an individual contributor? What type of manager did I most enjoy working with and how did they push me to do my best work?”
When I first had children, a family friend said, “Everyone’s going to give you advice. Take what resonates with you and make it your own.” I think the same is true with leadership — it has to be authentic. You can’t just read a book and suddenly become a good manager. It takes time to develop your own style.
I’m pretty self-motivated, I have a strong vision of what I want, and don’t like micro management. But, when I first moved into management, I was micromanaging. I was handing down solutions instead of handing down problems. I recall a moment when I was working with people who I consider to be good friends and I suddenly realized that I was mandating instead of just allowing them to have space to work. That was a big learning experience.
Over time, I got better at finding the right balance of trust, delegation, and verification. I think that’s a balance that a lot of leaders struggle with, and there’s no right answer because it’s situational.
I believe that having a community of leaders who you can speak to and learn from is invaluable. Sometimes there’s a nugget of information in an anecdote that sticks with you, and at some point you realize you can incorporate it and utilize it.
Over the last decade or so, I’ve really been focused on the management track. I think of this as not just building software, but building the factory that builds software — cultivating people so that they can go off and become directors and senior directors and making sure that we have a machine that can produce tech leads. Doing that gives me a lot of satisfaction.
Humans are beautiful and unique and so are their personalities. So managing people can be very challenging because there’s no one way to do it. Each person is motivated differently. There’s also the factor of whether your own particular style jives with what they want.
Each time I get a new report, I try to figure out what they need and also see if my style matches up. Over time, you develop a deep playbook of different ways to pattern match, like: “I’ve seen this before and I’m going to go try this approach here.” But, if it doesn’t work in that situation you’ll need to try something else. I find that it’s difficult if you just use one approach for everybody.
It’s been really interesting for me to just ride the Twilio rocket ship and learn how to build reliable, scalable systems. My org runs tier-zero systems and services — the API front door, the authentication and authorization systems that govern our APIs and consoles, the webhook systems that make Twilio programmatic, the platform for our console development. If any of these systems go down, it’s a SEV-0 incident — the company stops, and we stop bringing in money. That’s a whole challenge unto itself. Even things that you might think are simple become very difficult at scale.
Large programs can lead to complexity. As an engineering leader, I believe part of my job is to remove as much of that complexity as possible. How do you reduce entropy? How do you reduce chaos?
Ultimately, I view every single person in Twilio’s R&D to be a problem solver, but you also have to be a problem identifier. I think it’s helpful to have known processes for getting intake requirements, making sure people understand the work we’re doing, ensuring work is being tracked, and knowing what communication channels to use. By making it easy for people so they don’t have to search for stuff, you give them more time to focus on the harder problems.
When you’re on a rocket ship, there’s a lot of incoming requests. It can feel like a bit of chaos. I like to check the execution of things, and make sure we’re consistently following a standard procedure. The goal is to basically have a train that’s going out and is delivering incremental value toward whatever it is that we want to set our mind to.
We use SLOs (service level objectives). If you are constantly eating into your SLO budget, then that means you probably have to invest more in reliability work.
That said though, I definitely like to prioritize. I’m always thinking about impact over features. It’s easy to fall into a feature trap where you’re just delivering incremental features and not really looking or caring about why you’re doing that. What’s more important is to be laser focused on impact. One story that I think illustrates this is the idea that “the world runs on spreadsheets.” In 2000, I’m sure the folks in Redmond who were building out Microsoft Excel were like, “We’re crushing it. We’re adding more and more features to Excel.”
But if you look carefully at the Excel menu, 99 percent of people don’t actually use most of those features. So Google took the spreadsheet features that maybe 90 percent of people regularly use and added online collaborative functionality. I don’t know about you, but I much prefer to use Google Sheets over a downloaded Excel file. I think Microsoft was focused on adding features, whereas Google focused on impact.
We want to be a value factory instead of a feature factory. So, when we craft goals or review work, if someone says, “I’ve done something” we always ask, “Why is that important?” And if you can’t really answer why, then there’s a problem because that means you don’t have the context to understand why you’re doing it. You should know who your customer is and what value you’re delivering to them.
I’m also a big adherent to creating small incremental streams of value constantly. I despise hearing that a project is going to take two or three years. It might take us three years to complete something, but I want to start seeing value now.
How do you get end-to-end functionality that delivers value as soon as possible? You want to see steel threads that go all the way through. If you build the backend, the API, and the UI sequentially, it might be months of work to see value. Instead, go end-to-end — take just a sliver of the problem and build the frontend, middleware, API, and backend end-to-end so that you have something customers can actually use as soon as possible. Then, expand work on breadth and scale and work out from there.
First off, I think you always need to embrace change. Especially if you’re in a growth-stage company, because if something is static it’s not growing! The tools and systems that we had five years ago are already obsolete. So there’s a balance. You want people to care about the systems that they build, but also be ready to throw them away or just let them evolve. You always need to be thinking about how you’re going to build the next generation.
The day-to-day can be very tactical — filled with fires to put out, requests to fulfill, and issues to address. I try to give my leaders space to rise above all of that and reflect on the last month or the last quarter and figure out what’s been working well.
One of our core values, which we refer to as Twilio Magic, is “We are Curious.”I think it’s important to foster that curiosity. In addition, in my org we have an emphasis on two tenets: “addition via subtraction” and “crossing the river.”
Often as you’re building a new thing, you start adding on top of something that already exists. Over time, if you don’t really analyze it, it can become a sort of Rube Goldberg machine. I think that it’s good practice to constantly challenge the way we’re doing something. In some cases, we may be able to simplify the thing we’re building by subtracting first and then adding on. That’s addition via subtraction.
The other tenet is crossing the river. This has to do with embracing the change that exists in the world. When we build a new thing, we need to shut down the old thing. If you’ve got V1, V2, and V3 out in the wild, that’s a lot of burden to maintain.
Also, when you’re looking at performance and such, you want people to demonstrate a growth mindset. You want them to be able to tackle new opportunities without thinking that everything needs to be static and fixed.
There are some things that I believe are probably universally applicable. For example, can you problem solve? Are you able to treat people like humans?
I like to think of a company’s needs as a spider graph, and people also have their own spider graphs of needs. The trick is to find graphs that fit. In addition to being a good culture fit, there are a few other facets. Are you capable of doing the work that is necessary for your role? Do you have the energy? Do you have the desire?
Even when someone is a good fit in terms of culture, performance isn’t always constant. Someone may be a high performer in one arena and when they switch arenas they realize it’s a different sport than the one they are used to playing. They may be able to grow into the new role, but first they have to acknowledge it. An important part of a manager’s role is to give people feedback and actionable insights, and help them understand where the deficits are so that they can improve.
Going back to the core value of curiosity, one way that I keep up on things is just that I have the desire. For instance, I have software projects that I build out at home. That forces me to sometimes use different toolkits.
In terms of blogs, I like The Pragmatic Engineer by Gergely Orosz. I’m also a big fan of Ben Thompson’s Stratechery. Those are a bit high level, but I really enjoy them.
I’m a big advocate of thinking of a career as a pyramid instead of a ladder. With a pyramid you can establish bases that lead up toward something bigger. For example, early in my career I wore many different hats, rather than just staying in software engineering. I worked in sales engineering and product engineering in order to learn how to elicit requirements, build prototypes, sell product vision, and demo products. As a technical product manager, I learned to identify core issues, frame problems, and quantify value. I managed remote teams, and also started my own consulting firm. Finally, I reached a point where I had to decide if I wanted to be the person defining the product or building the product, and I’ve always felt more inclined to be a builder.
It’s important to stay curious and look at the whole broad spectrum of what’s available to you. And, if you find that you don’t want to go down a certain track, that’s okay. You do not have to become a VP of engineering or go down the management track to have a successful tech career. There are also deep IC tracks you can take that can be very fulfilling.
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Compare Prisma and Drizzle ORMs to learn their differences, strengths, and weaknesses for data access and migrations.
It’s easy for devs to default to JavaScript to fix every problem. Let’s use the RoLP to find simpler alternatives with HTML and CSS.
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
Bypass anti-bot measures in Node.js with curl-impersonate. Learn how it mimics browsers to overcome bot detection for web scraping.
Learn more →
