Amid a successful career at Amazon, Tiffany Jianto found herself deciding between another tech giant and Confluent. Below, she explains why she chose to join our team, how she supports her team members in both solving tricky technical problems and growing their careers, and what she and her new teammates are doing to encourage other women in tech.
I’m an engineering manager for Confluent’s Kafka Serverless team, which is focused on improving the experience of managing Apache Kafka® clusters for our customers. One of the main features we own is Self-Balancing Clusters—we want to handle customer workloads and their changes as smoothly as possible, so customers don’t have to worry about manually tuning their clusters. Within the Serverless team, we also want to make customers’ clusters more elastic, so they can seamlessly shrink and expand as workloads change. We strive to automate as much of the process as we can.
Day to day, it’s a mix of managing project work and operational work, helping customers with issues that come up, and attending a lot of meetings. I work closely with other leaders, and our colleagues in Product and other teams, to make sure we’re working on the right things and prioritizing projects correctly. And, I have seven direct reports, so I meet with them individually, and as a team, to make sure everyone understands the goals we’re working toward and that they’re happy in their jobs.
I started as a math major in college, because I liked it in high school. How many of us really know what we want to do when we’re 18? But math turned out to be too abstract and theoretical for me, and then a friend offhandedly suggested I try computer science. I took a couple of classes and really liked it, so I switched majors. After graduation, I joined Amazon Web Services (AWS) and was lucky to be placed on the team that was building out RDS Aurora, AWS’ in-house database solution within the relational database service (RDS). This was 2013, when distributed cloud storage was not common in the RDS world, so what they were doing was pretty revolutionary, and I learned so much. After about six years as an engineer, I moved into a management role, which I’d always been interested in. While I enjoy the feeling of completing a project or figuring out a bug, I’m also an extrovert and love working with people, so it’s exciting for me to help others achieve something they’re proud of.
After about a year in that role, Kamal Gupta, who leads Kafka for Confluent, got in touch. I wasn’t really looking to change jobs quite yet, but he’d led the Database Orgs at AWS, and I knew how amazing and supportive he was as a manager, so I figured, “Okay, why not?”
I was also considering a role at Google, and that would have been a very safe choice because it’s such a huge company. But I was sold on Confluent. It’s growing quickly and still has a startup feel—less structure, for sure, but that means there is a lot of opportunity to make an impact and do interesting work. I also wanted to step out of my comfort zone and challenge myself, because I think that’s when you really grow.
In one-on-ones, we always talk about how things are going with their work and what I can do to support them. It’s critical to build trust, so people know when they have a concern they can raise it—in fact, it helps me when they do. If they’re facing a challenge, we talk about what’s causing it and what we can do about it. Most importantly, we talk about the “why” behind their work. We all sometimes have tasks that might not be super interesting, but those tasks might also be very high-impact.
Beyond one-on-ones, we do lightweight quarterly check-ins to reflect on what went well, and to make sure we’re moving toward their career-level goals. I’m also part of a working group that’s focused on making career paths clearer and better-defined as Confluent continues to grow. Over the last year, we designed a career matrix for our individual contributors, with expectations for each level; we’re working on the same thing for manager roles now.
The cool thing, too, is that you have the opportunity to experiment here. Try something new and see how you like it, how your team likes it, and if you decide it’s not the path for you, you can always change back. I think that’s awesome.
The Self-Balancing Clusters feature is a big one. We manage customers’ clusters so they don’t have to, by detecting things like hot partitions, or when a broker is overloaded. Then we move things around accordingly to address the issue. It sounds simple, but under the hood it’s actually a really difficult problem to solve. There are lots of different metrics to evaluate and aggregate in order to find a good catch-all solution.
For example, a lot of customers have very cyclical workloads—which we can handle for the most part, but sometimes there are extremes. And when a cluster is at capacity and being used a lot, that’s exactly when we don’t want to go in and disrupt things. In the short term, we sometimes make adjustments manually, which of course comes with operational overhead. But we’re now collecting data and looking at patterns, and in the long term we have some ideas to improve our algorithms so they handle those edge cases more effectively.
When I was at AWS, a few colleagues and I started a similar group for the Bay Area team, and it ended up growing into a great community, both within the company and beyond. We had mentorship circles, and we were able to volunteer with groups like Girls Who Code to nurture and support other women in tech. When I joined Confluent, we already had the Women’s Inclusion Network, which is wonderful, but there wasn’t a group specifically for engineering. I think specialized communities can be really valuable because different areas have different sets of challenges.
We kicked off the Women in Engineering group a few months ago by talking with the community about what they’re most interested in; we sent out a survey, and there was a lot of enthusiasm toward career growth and mentorship. I think it’s been especially hard to build those relationships during COVID-19, when you’re not meeting people just by sharing an office. We’ve had a couple of virtual meetings already, and for International Women’s Day we had our first in-person event at headquarters. It was so exciting to meet everyone face to face.
There’s a lot we can do as we grow, including defining exactly what we want “serverless” to mean. We’re working with Product to understand all the different use cases for customers, what they’re looking to solve, and how we can ultimately make the customer experience completely effortless. And something I really like about Confluent is that Engineering has a lot of say in that planning process. At a larger company, things can be much more top-down; for example, on my previous team, the leadership and product managers were mostly responsible for these decisions, and the first-level engineering managers were more focused on execution. at Confluent, my entire team is part of the quarterly planning process. We talk with our product manager about the things we want to address, whether it’s a feature we think is important, or something that’s just operational toil taking time away from dev productivity. Then, I represent the team to the rest of leadership, and we come up with a plan to push those initiatives forward.
The advice I have for women who are early in their careers or interested in engineering is to go for it: Don’t be afraid to take on challenges, even if they seem intimidating, and don’t opt for the easy way out. I feel like it’s very easy to doubt or second guess yourself, especially when there are fewer women around or you’re surrounded by so many people who seem so different. But having a diverse team and different opinions is very valuable and brings a lot to the table. Ask questions, take challenges, and look for opportunities to grow.
Kamal is a senior director of the Confluent Engineering organization helping drive Apache Kafka and its ecosystem. Before Confluent, he worked at AWS for 13 years to help shape and define DBaaS industry.