A Convoluted Path From Individual Contributor to Leadership

Transcript

Shane Hastie: Hey folks, it's Shane Hastie here. Before we start today's podcast, I wanted to tell you about QCon London 2024, our flagship international software development conference that takes place in the heart of London next April, eight to 10. Learn about senior practitioners' experiences and explore their points of view on emerging trends and best practices across topics like software architecture, generative AI, platform engineering, observability, and secure software supply chains. Discover what your peers have learned, explore the techniques they are using, and learn about the pitfalls to avoid. Learn more at qconlondon.com. We hope to see you there.

Today I'm sitting down with Chandler Hoisington. Chandler is the Chief Product Officer of EDB and comes to that role through a VP of Engineering background in a couple of places. So Chandler, welcome. My starting point is often who's Chandler?

Introductions [01:14]

Chandler Hoisington: Thanks, Shane. It's great to be here. I'll start at the beginning. I actually started as a engineer at a small database startup back when sharding was still really cool. We were actually doing MySQL sharding, and I actually started as a Java engineer at a database startup way, way back in the day. So from there, I got into some management roles and I got a really great role at a good company called RMS in the Bay Area there. And RMS did catastrophe modeling for the reinsurance and insurance industry, so they would model the effects, especially the financial effects of a hurricane or an earthquake against an insurance portfolio. And so it was really interesting, big data challenges, and it was a really interesting time to be there. It was right when containers were coming out and it was at the end of the Hadoop era and the beginning of the Spark and Kafka era, and there was a whole bunch of new DevOps practices and containers, like I mentioned, were just budding out.

So from there, I actually ended up running product and engineering at Mesosphere, which was a really great company to be at as well. And worked on Kubernetes challenges and Mesos challenges and containerization challenges for a few years before joining AWS as the GM for Kubernetes for their hybrid and edge products. And then now I've landed at EDB as the Chief Product Officer.

Shane Hastie: That's a convoluted journey from an engineering perspective. What are some of the big gotchas in that career journey that you can share with folks?

Chandler Hoisington: Yeah, honestly, I think my first two jobs out of college, one being a backend developer for distributed systems databases, and then my next job was actually at another startup. We were building applications against the Facebook API at the time, but I was in charge of all their backend development along with standing up their infrastructure, which we did on AWS, and it was very, very early days at AWS. And so those two first jobs defined the rest of my career. It was a combination of the distributed systems in cloud. I ended up working on a lot of distributed systems and then ended up solving problems at AWS itself, which was a really great experience. So that's how I would say my career has evolved itself. Not really on purpose, but just slingshotting off those first two opportunities and continuing to ride that wave of cloud and distributed systems.

Shane Hastie: So Amazon, interesting place, everyone looks at them as amazingly successful. From inside, what did you learn in your time there?

Lessons from working at Amazon [03:47]

Chandler Hoisington: Coming to EDB as a CPO, I was able to actually take away a few things from Amazon that I really enjoyed. Just like with anybody working at a big company, you might not agree with all the operations and processes that exist inside that organization. But at Amazon, I think they really figured out the product process, especially with how they run their product working backwards documents. And I'll explain this for those that don't know. It's very awkward when you first get to Amazon actually because you sit down in a meeting. In fact, my very first meeting was like this at Amazon. It was like 8:00 AM on a Monday, my first meeting ever. And we sat down and this is during COVID, so nobody was in the office. We're all on Chime. That's their version of Zoom. And we're sitting in a meeting, everyone's cameras are off, and I'm like, am I missing something?

Five minutes goes by, six minutes goes by. Are people going to turn on their cameras? What are we doing here? Nobody's talking. And my boss is like, "Oh, hey, I didn't see you there. Yeah, we're all reading this doc." And so it's like a study hall for the first 15 or 20 minutes of every meeting really at Amazon. Most meetings, not every meeting, but I would say 80% of meetings are run this way. And you are reading a doc. This doc happened to be a weekly business review doc where we went over all the metrics for that service, the revenue, the new customers, support tickets and issues. And you're just reading, it's a pretty dense doc at times, but you're going through all that data. They usually keep those docs under six pages just so you can read them in the first 20, 25 minutes.

But then whenever it's done, they start coming on camera as you're ready. And then we have a discussion. And Bezos famously says that he likes a crisp doc and a messy meeting. So he wants the docs to be very, very, very crisp. He wants the data to be well-understood and thought out, and the author of the doc has a lot of responsibility to really do their homework and bring a very well-thought-out doc to that meeting. But then he encourages us the meetings to be what he calls messy, which really means asking a lot of hard questions, trying to find holes in the strategy that you've laid out in your doc, finding the key things that people should be following up on. And this is how Amazon ran most of their meetings.

And for their product process, they applied a similar philosophy, but they had another element to it, which was they really encouraged you as a product manager or a business owner to be what they call working backwards from the customer. So what that means is instead of jumping straight into code and starting to write a bunch of code and prototyping rapidly on code, which there is a bit of that that's done at Amazon, the process that Amazon encourages people to first think backwards from what kind of value we're going to be releasing for the customers. So that's done in the way of writing the press release actually. So you write a one-page press release as a product owner or manager, and then you have a couple pages of PR FAQs associated with that press release. And it's a really interesting process. It took me a minute to get used to, we were starting a new service when I joined, so it was one of the first things I had to work on was one of these. It's called a PR/FAQ doc, is the abbreviation for it. Press release with an FAQ.

And it was one of the first docs I had to work on. And it's actually quite challenging to define in one page an entire product that you want to release. And there's a specific format. A problem paragraph, a solution paragraph, some supporting quotes, things like that. And every sentence is scrutinized. And what this process is intended to do is it's a go slow to go fast process. Let's make sure we're conscious of all the hard decisions we need to make now so that after we get into this, we're not eight months into the code and it's like, actually we need to refactor the whole thing. We think we took the wrong approach. So that's one big reason behind it.

And the other reason is ensuring that you're thinking backwards from the customer pain and actually solving problems for the customer. So thinking from the customer's perspective, and not necessarily from the engineer's perspective writing the code. So as soon as we nail that PR/FAQ process and it goes through a litany of reviews, many, many reviews depending on what you're doing sometimes all the way up to the CEO of Amazon, depending on what you're launching, it might go through months of reviews. And that's the go slow process. But then once it's decided, the teams move very, very quickly to go and execute and build on those things. This is a long way to answer your question, but like I said, I didn't love everything at Amazon. There's a lot of things I did like and this was definitely one of them. So when I joined EDB as the Chief Product Officer, I said, "I'm going to bring this with me."

And that's what we do now at EDB. We've rolled this out over the last year, and again, when new people join, it's awkward for them. They're like, "Wait, are we going to be talking in this meeting?" But we spend the first 10 to 20 minutes of every meeting like these, not every meeting, with the meetings that we do doc reviews in, reading a doc and doing study hall. And then we have a discussion, and I think it's worked really well. I think it's something I'm going to use wherever I go now in my career for the rest of my career. It's something that I've gotten a lot of value out of.

Shane Hastie: As an engineer, the last thing I want to do is read a document.

Engineers and documents [08:49]

Chandler Hoisington: I don't know. You engineers write docs all the time. You're writing design docs. And honestly, I think the engineers, I don't want to for all of them, but I do think they also appreciate having a north star reference point for what they're building. I think a lot of times engineers and most of the time almost every time engineers have the best intentions for what they're doing. They're trying to solve problems for customers. They're looking for ways for product managers to steer them a lot better. And the nice things about these docs is that they're not done in a vacuum. It's not just a product manager sitting in their office and then be like, "Hey, I have a doc I want you all to read." They're very collaborative even to get the first draft done. So they're often done with the engineers who are going to be working on the project, with the architects, with engineering leaders. And so it's brought as a collaboration between product and engineering to the group and then eventually to leadership.

It's not the end all, be all document. From there, we take that document and we write essentially design docs and we break it down into user stories and design docs from there. But it stays as our north star to help us get the group aligned. I know your audience is mostly engineering, but I also use it to help engineering communicate to the rest of the company what they built and the value of what they're building. And I think that's another thing. I'm sure you see this all the time, but there's lots of great engineers who build really great products that no one ever hears about because the product marketing and the marketing and the rest of the organization doesn't do a good job communicating it to the customers and the rest of the world. And these docs help us really distill that value down into a single page, and we're essentially handing it off to the marketing department. It's like, "Here you go." It's gift wrapped as a press release.

And oftentimes, they don't use our exact language, they pretty it up with marketing words, but it definitely sets them on the right track for how to talk about often pretty technical products. So I think that's another big benefit to the engineering community for these things.

Shane Hastie: Shifting tack a tiny bit, your experience leading engineers. A lot of our audience are people who are stepping into the engineering leadership role sometimes for the first time, some of them technical team leads and so forth, and choosing to go down that leadership management path. What advice would you have advice for those folks?

Advice for new leaders [11:06]

Chandler Hoisington: Yes, the advice I almost always give to new engineering leaders is don't feel anxious about making that jump too soon. Don't feel like your career is going slower than appears, or you need to get into management in order to keep advancing your career. I know from my experience, the technical knowledge that I got as an IC essentially became the foundation of my technical knowledge for the rest of my career. And that's not to say I can't learn new things in a leadership role, but your pace of learning new things, especially at the detail that you learn them as an engineer, is much slower. You're often looking at new technologies from big boxes in architecture. You're not hands-on implementing things and really getting that understanding at the same level.

So what I usually tell people is don't do it too soon because that set of technical knowledge, you need to be a really good engineering manager, the pace of which you add to it is going to slow way down once you get into leadership, and really everything you've learned before getting to leadership might be 70 or 80% of your entire foundation of technical knowledge going forward. So it doesn't hurt to get exposure to more things as an IC before you make that jump into leadership. And I know some companies, I have a friend who worked at a company, DuckDuckGo, and they have a very different style, and from my understanding at least of what he told me secondhand is he was doing a lot more leadership and hands-on implementation at the same time, so he was able to continue to do IC work even as a leader.

But I think for most companies, once you make that jump, it's a hard cutoff, and now you're just managing people and projects and working on a different set of problems, but with the expectation that you can dive in and go deep on technical issues when needed. And so that's my biggest piece of advice for newer managers is don't feel like you need to make that jump too soon. Especially at the FANG companies or whatever we're calling that nowadays, the big companies, from a comp perspective and career path perspective, it's a different game nowadays. You don't have to go into management to keep making more money and to get better and better titles. They've really laid out a pretty clear path on the IC role as well.

I think you can get all the way to the same level as a VP at Amazon as an IC. I don't know if they call it distinguished engineer or I forget what they call it, but it's some very high-ranking engineer. And so you have a pretty clear career path on both tracks, so I think that's another thing to keep in mind nowadays. It's a little bit different than maybe it used to be

Shane Hastie: In that leadership capacity, you've come in new from outside, senior leader coming into an organization. There's inevitably the new broom sweeps clean feeling, and everybody in the organization is going, "Oh no, not again." One, from your perspective coming in as that new broom, why? And for the people who are sitting there going, "Oh, no, same thing, different day. Oh, not again," how should they tackle this?

New leaders joining an existing organisation [14:13]

Chandler Hoisington: Yes, I think there's definitely truth to new leaders coming in and wanting to bring their own style. They're used to operating the organization a specific way. Just like when I joined EDB, I just came from Amazon and said, "You know what? This doc thing we're doing here is really cool. I want to bring that with me." And so I changed a lot of ways that the team was working at the time. And I've also had a lot of bosses get swapped out on me as an executive myself over the years as well, so you have to figure out how to adapt to new styles and people. My best advice here is to be flexible. You have to understand that changes in leadership are made usually for a reason. Either investors aren't happy with the direction something is going, whether that's been communicated throughout the entire org or not, that could be one of the reasons. Or it could be something much softer than that. It could just be someone's retiring or they're moving on for family or health reasons or whatever the reasons they have is.

But I think in a lot of cases when you're bringing in new executive, it's often because they want to make some kind of change. And so to be in an organization where that's happening, you have to realize that flexibility is really important and you have to put yourself in the right mindset. There might be a lot of things that you've done well over the years and you don't want to lose that, but you also have to be open for executives coming in and bringing a new style and a fresh perspective, because that's almost what they're being asked to do. And like I said, in my case, I brought in a whole bunch of new processes. It looks like a very different org than it was before. And I also brought some new people as well that I've worked with in the past who I knew could roll out that process and new way of working as well.

So there's definitely some change that you have to be comfortable with, but I think it's felt usually less as you go down the organization. So if you're an individual IC you might not feel it as quickly as just an individual developer as you might feel it if you're a VP or a director reporting into the CTO or the CPO or something like that, so it really also depends on where you're at in the organization.

Shane Hastie: What's the biggest mistake that you've made and how did you recover?

Learning from mistakes [16:16]

Chandler Hoisington: Oh, good question. I think we all look back at our career and you can say, "Oh, I should have done this differently," or, "I should have done that differently," one thing or another, but I'm actually happy where I've landed. So I think for most people, it's a positive perspective to have to look back and say, "The jobs I took and the experiences I had got me to a place where I am now," so it's almost like the butterfly effect. I don't know if I would necessarily change anything. But there is one thing I wish I had learned sooner, and that was to listen more and to assume positive intent in most cases. I think some of my early jobs, you're eager, you want to show leadership that you're capable of being the leader that they promoted you to be, but at the same time, you don't want to leave any bodies behind.

And so I think it's important to figure out how as a leader and an executive, once you move into that position, how to move to a place where you can be effective in the organization. You can drive change and the decisions that your team needs you to do, and you're not just going to go up to these leadership meetings and roll over on issues that you think are right. But at the same time, you don't end up using so much political capital on small issues that you don't save any for the really big issue that you care about. One example comes to mind, I was at a company, we were trying to decide what cloud we wanted to pick, and this was back in the, I can't remember exact year, but this is when AWS had a pretty sizable lead on most of the competitors. And even before I joined AWS, I was an AWS fanboy, so to say, as people say. And I was a big fan of the services they had built at the time and all that kind of stuff.

The other clouds have caught up quite a bit, and they also have really good offerings now, and it's not just an AWS world anymore, but at the time it really felt that way. But some of my leadership and my colleagues were looking at potentially going with a different cloud provider. And as the VP of Engineering, it really affected the way I could deliver products because we wanted to use services, database services, container services, whatever was available at the time, storage services that were the latest and the best and the most mature and the most hardened, et cetera. So my architects and engineers was telling me, "Don't let them pick a different cloud."

I went into those meetings with the same vigor and passion and enthusiasm that I did in many other meetings, and that's where I think it would've been helpful to save some of that for when I really needed it. And I learned this early on, and sometimes it can be hard to do because a lot of us are passionate people and you come in and you want to speak passionately towards issues, but in this instance, I wish I had saved some of that in the tank, kept some of that gunpowder dry, so to say, so that I could have used it for some bigger issues that I ended up losing where I felt like it was the right decision. So I would say that would be my biggest mistake, most likely, looking back on it is just if you can call it a mistake, but just learning that lesson sooner could have benefited me, but it was a good lesson to learn nonetheless.

Shane Hastie: Chandler, you've been in the industry a fair while. You've looked across a number of different organizations. Where do you see the trends, the things that the engineer at work today should be looking for on the horizon, or maybe it's closer than that?

Trends to be aware of for the future [19:25]

Chandler Hoisington: Yes, throughout my career, I've been watching a couple, I don't know how you describe them, maybe sub-industries in tech. I was big into the container space and the Kubernetes space for a while, but also in the data space, and that's where I am now. And looking at the trends in data is really fascinating. We went from in the 2000s being on single big databases, single machines. Oracle and MySQL started coming out. I started getting some open source solutions, and Postgres was always there. To this NoSQL craze with really fit-for-purpose data engines and RDBMSs. And then you had the big data craze along with that, with the Clouderas of the world and how do we handle data at scale? And now I think AI has really stepped into the picture. I don't think there's a single CEO or CIO in a Fortune 5,000 company that hasn't been either asked by their investors or leadership or by their customers to deliver an AI product at this point, or an AI strategy.

And so with that comes a lot of new data that's going to start needing to be handled similarly to how all this data of the past is handled as well. So that means we need governance of that data. We need the same security controls. We need the same scrutiny around regulations for EMEA and federal and health regulations like HIPAA. And so there's a whole slew of challenges that come along with these new systems that are coming on the market to manage this AI-specific data. And honestly, I see the trends really focusing more on how do we take the existing systems that we've hardened over the last 20 or 25 years and make them work for this new world versus building brand new systems for this specific data and trying to apply 20 or 30 years of learnings, like let's call it day two features, learnings to new systems.

And so time will tell how the market shakes out, but I'm very optimistic specifically around where Postgres is and the new evolving AI trends. I think that's one example of an open source community doing a really good job of sticking to their vision and mission around just having a very performant and reliable and hardened database. And then you can see really great projects like pgvector coming out where people can start using extensions for Postgres, and specifically vectorized extensions, for building applications against these new LLMs that have hit the market. So I see the trend's really, rather than going towards new data systems, I see people looking at their existing systems and saying, "Hey, instead of adding one more thing to our stack, one more piece of complexity that we have to manage and patch and buy support for, could we just use Postgres or can we just use these systems that work today?" And I see those trends really continuing to evolve and take shape over the next few years.

Shane Hastie: A lot of interesting points and some good advice in there. If people want to continue the conversation, where do they find you?

Chandler Hoisington: You can connect with me on LinkedIn. I'm slightly active on Twitter. I like more Denver Nuggets, the NBA basketball team, posts than I do technology sometimes. But I have had some technology conversations on Twitter with folks, so I'm there as well. C_Hoisington. But I'm more active probably on LinkedIn. You can find me there and all this stuff we talked about with Postgres. Obviously I work for the number one contributor to Postgres and you can find out a lot more information there as well.

Shane Hastie: Chandler, thanks so much for taking the time to talk to us today.

Chandler Hoisington: Great. Thanks, Shane.

Mentioned

Chandler Hoisington on LinkedIn