Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I’m sitting down with Cassie Shum. Cassie is in East Coast, USA, New York. Cassie, welcome. Thanks for taking the time to talk to us today.

Cassie Shum: Thank you for having me. This is exciting.

Shane Hastie: My usual starting point in these conversations is just who’s Cassie?

Introductions [01:11]

Cassie Shum: Yes, let’s start with that. So hi, everyone. I’m very excited to be on this podcast. My name’s Cassie and I have been a technologist for almost 20 years now. And so one of the things that I really love about my career is the different people that I’ve been working with, the different mentors that I’ve had over the years. I give a lot of credit to Thoughtworks where I was for about 12 years of my career as a software engineer, so engineer at heart. And then throughout the years, dabbled into quite a few areas like cloud infrastructure. I did a little bit of a foray into mobile applications because I thought I was going to be a millionaire from making one app. I was wrong. And so I went back into looking more into different enterprises and really driving enterprise architecture for quite some time.

And then quite recently, about a couple years ago, I started looking around to the next area of my career and I was very excited to meet my CEO now, Molham Aref with Relational AI. And I just got super excited about the product. And I am one of these people who really like looking at what the future of technology looks like given my history, working on the tech radar at Thoughtworks and the Doppler, and really looking at the tech trends. When I heard about the product that we were doing around the data-centric architectures and how this was going to affect enterprises at scale, I had to jump on the opportunity to come and see what that was like. And it’s been just a wonderful journey, actually. Very busy and very exciting. Startup land is a bit different than my consultant background, but yes, it’s been a great journey.

Shane Hastie: This is the Engineering Culture Podcast. What are some of the key elements of an engineering culture that you’ve exposed through your career? Some of the big learnings in that space?

Multiple levels of empathy as a key element of engineering culture [03:02]

Cassie Shum: I would say I think I’ve been very, very lucky to be on multiple teams as a team member when I’ve seen very good culture and then being able to lead some of these teams in future and taking some of those learnings. So I distil it to a couple of concepts, and there’s probably a lot that you can bring out of it, but the biggest one for me that I talk about a lot is empathy. And empathy for me operates at multiple different layers. So empathy, of course, within your team in itself, how are you empathizing with your team members? How are you empathizing with your leadership? And then also how do you empathize with your customer as well? Because at the end of the day, as engineers, we are building products for a customer of some sort. That customer may be an external customer that you’re building a product for, or it may be an internal customer if you’re working on developer portals or developer tools, your customers are the engineers and the developers.

So being able to think in the shoes of who you’re developing these things for is actually quite important. So I think empathy is a massive theme of mine, and I think if we can start at that core, a lot of things trickle out from that. And so the trickling effect leads to transparency within a team, a very healthy feedback cycle within a team in itself because with that empathy, you want to know how other people are working with you and how you’re collaborating together. And then at the end of it too, if you start removing your own ego and you start thinking about how do we be successful as a team and you empathize at a team level, then if everybody does that, then, again, I think that would be a perfect culture from an engineering perspective. Now, as we all know, in reality, we have a lot of different things and constraints in place, but I think if we can get some of those core fundamentals in place, then it would be good.

Shane Hastie: Moving from a group of individuals to a well-jelled team, as a leader, how do you encourage that? How do you enable that?

Helping teams become high performing rapidly [04:57]

Cassie Shum: I would say I wish we had a lot of time in the world because then we think about the norming and the storming and really getting to know each other and things like that. I actually more want to talk about when you don’t have the time and you have to quickly iterate. As me being in a startup land right now, time is usually not on our side. So I think really to think about moving from a group of individuals and moving into a team, it’s really about an aligned goal and aligned purpose. At least if we can actually focus from a team perspective or from a company perspective, however big that group you are focusing on, everyone needs to align to some purpose or goal that you’re driving to.

And so the way I like testing that is, yes, you can say, “Hey, as a team goal, this is what we’re doing.” But repetition is a very, very useful tool in my opinion. So with many of my teams, I always say, “So what do you think our team goal is?” And I need people to repeat it back to me as well. So it’s one aspect of saying, “This is our team goal.” It’s another one everybody really embraces it to their core because then everybody will be working within their own skill set and whatever their specialty is within that team, aligning to that one goal. So I think that’s usually the core area where people are misaligned from the beginning, but we don’t fix that. We just say, “Okay, we put in another smart person and we’ll figure it out together and this will happen.” But keeping that repetition of repeating goal and what we’re trying to drive towards and what are we measuring towards is really important as a fundamental.

Shane Hastie: As you say in many organizations today, there’s not necessarily the time to go through the form, storm, norm, to get to perform. So that focus on goals, and I love the empathy, transparency, feedback, some powerful stuff there. Shifting focus a little bit. Relational AI, VP of field engineering, what’s your job?

Aspects of the VP role that enable high performance [06:57]

Cassie Shum: It depends on what day you ask me. My job actually consists of a lot of different things right now. I would say when I came into the organization, and it still holds today, is my focus or what I would say my success criteria as a leader of field is customers. So how are we pleasing our customers with our products and with our wonderful field engineering team to really hold the hands of some of our early adopters in our product and really drive to those business successes, the business criteria for the customers. So that’s definitely, I would say, a key component of my role. But then, of course, that is everybody’s goal in field engineering. But one of the things that I then focus on is the team aspects. So how do I align the field engineering teams around customer centricity? How do I work with the teams to work with each other, work with our customers, and also work with the product engineering side to really tighten all the big feedback loops.

So a really wonderful way we go about this is if we’re going in front of the customer, our teams will be there solutioning with our customers, understanding what their business use cases are, and then implementing our product within their ecosystem. And as we both know, every type of ecosystem, it can be a different ball of wax, so being able to get that really, really beautiful feedback loop from the customer is really important to improve our product. And so there needs to be close collaboration, close communication from our field to the product engineering team as well, so we can actually give them feedback to strengthen our product that is very applicable in front of our customers.

Shane Hastie: Thinking about engineering teams, developer experience is a big topic today. Dare I say, it feels like finally we’re giving it the attention it needs. What are some key points that organizations should consider when they do want to go into improving that developer experience and why would they bother?

Ways to improve developer experience [09:04]

Cassie Shum: We could dedicate an entire podcast to this topic, but I think I could give some high-level of thoughts that I have. I am very excited, first off to agree with you that developer experience is now something that organizations are really putting their focus on. I do think that if we focus it on the wrong way, it could actually lead to something not so great for developers and engineers. So I’ll double-click into what I mean there. So essentially if we think about measuring developer productivity or developer effectiveness, I think if the leaders don’t really have a true understanding of where their developers are spending time, where the actual churn is, and I have seen some anti-patterns where it’s like, “Oh, how many lines of code are you writing?” Or, “How many commits do you have?” And we’ve even talked through from a Dora perspective, what is the time to commit, what’s the time to release, time to fix bugs and things like that. So I think in principle, a lot of these different metrics can be useful, but they cannot be the only metric that you measure developer productivity on.

So one of the things that I think about is how do we measure end-to-end all the way from the beginning of incepting a story from a product sense, how that formulates into code and QA, and then how does that get right in front of your customer for that instant feedback, continuous delivery loop. And so measuring that churn is actually really important to think about in the holistic area of developer effectiveness. So I’ll quote a little bit around Martin’s blog recently has had a whole series around developer effectiveness from Tim Cochran and team at Thoughtworks, and they talk about things like micro-feedback loops. What are the small things that happen in the developer cycle that’s creating a lot of churn? And so a lot of people like to measure the big things that stop developers, but what about those little things that add up? We call them death by a thousand cuts. So if my build time takes 40 minutes versus two minutes, once you do that repetitively over and over again, you can actually start measuring how much churn your developers are going through and things like that.

So that’s another area where it’d be good for folks to really focus on what that actually looks like. In order to make developers more effective, you have to make them happy, and being happy means that they’re productive. And so it kind of feedbacks onto itself as well. So there’s a lot of material there, but I am very excited that this is a focus now. So if I relate this back to Relational AI in a lot of my teams, one of the things that we want to look at is how much time does it take to actually work on something, get feedback from the customer and actually get feedback from the product and really iterate on those kinds of things. The tighter we can make those loops, the more excited our engineers and developers will be, so yes.

Shane Hastie: So what are the biggest bottlenecks for development today in your experience?

Bottlenecks to development [12:00]

Cassie Shum: I think the biggest bottlenecks right now is communication, actually. So a lot of the bottlenecks comes with miscommunication. Essentially, there’s a lot of assumptions that are usually made when you’re picking up a story or picking up pieces of code to develop. And, again, going back to how do you collaborate with your team? How do you empathize with a customer and your team members? That’s why I think it’s so fundamental because if you’re thinking more in the scope of what does Cassie as an engineer want to code and not think about what it’s being used for, then I might be coding something and my lack or miscommunication with a customer or the product team will actually lead to a lot of churn. It may lead to a lot of code that is actually not useful in the very end, and now we’ve taken long feedback loops in order to solve some of those problems. So I think that’s a huge bottleneck, is being able to have communication cross-functionally across teams and really understand what business value we’re trying to drive or use cases that we’re trying to drive.

Shane Hastie: And without being obvious, how do we fix that?

Cassie Shum: I think it’s really around processes… Not even processes. So it’s more about practices around these foundational things that I’ve talked about earlier. One of the things that I would say is, when you’re moving so fast, it’s so easy to forget about the team bonding. It’s so easy to forget about sitting together with your team and actually really understanding each other and what you’re trying to accomplish and things like that.

And then aligning on those goals that I discussed earlier, I even found that going to Zoom world as we have for the past couple of years has made that even harder in some sense because we may think that we’re being a lot more efficient because I don’t have to travel to work, and I’m actually on Zooms and we’re communicating a lot, but it’s really about the right kind of communication, not the amount of communication I’m doing with someone. So I think from a fundamental point of view, going back to the roots of what builds up teams and what builds up that trust between teams is really what’s going to make teams go a lot faster. So we just all try to do things on our own, then, well, that is the obvious statement, is that without that alignment, then we’re not going to really accomplish much, so yes.

Shane Hastie: Changing direction a little bit. When this podcast comes out, will be after QCon London this year, but you are the track host for the Architectures You’ve Always Wondered About track.

Cassie Shum: Yes.

Shane Hastie: Tell us a little bit about what’s going to be in that track, and by the time this is published, the conference will be over, but listeners will be able to access some of the content on InfoQ.

Architectures You’ve Always Wondered About at QCon London [14:36]

Cassie Shum: The theme of this track is that architecture happens at multiple different layers. So you have infrastructure architecture, you have data architecture, you have application architecture, and how do those things all work together? So the way that I’ve designed the track this year is getting a snippet from each of those horizontals, which is actually very antithesis to how I normally things in, in the cross-functional way, but I wanted to have talks that really talk about how these things interact with each other. So how does your infrastructure architecture impact the customer and what does that actually mean when we talk about tying to building features, for example. There’s a whole talk around data architecture and a bit of the use cases around data mesh, and what does that mean, that impacts the customer as well?

So all of these architectures we can do in silo and say, “Oh, I’m infrastructure, I’m data.” But really the whole theme of it is how is this impacting your customer and how are you working across all of these different horizontals in order to drive business value, especially in large scale organizations. So there will be some case studies discussed. I’m excited. We have folks from Spotify who are going to be talking about their developer portal and the plugin architecture that they use for their marketplace. Yes. We have a really wonderful talk from Duolingo and they talk about how they scaled for a big event that they had recently, which I’m not going to give too much away until they give that talk, so yes.

Shane Hastie: We’ll include the links to the conference and to the content on InfoQ for this.

Where are we going as an industry?

Cassie Shum: Big question.

Shane Hastie: Big question.

The impact of LLMs and GenAI on development [16:16]

Cassie Shum: Where are we going? I mean, I think the obvious thing that’s happening right now that’s affecting everyone is the rise of the LLMs and GenAI. I think that is a very interesting and exciting pivot. I don’t want to say pivot. I think we were always leading up to something like this, but to be able to change the way that we think about, I would say even as engineers. As engineers with co-pilots and all of these different technologies, how are these things making our lives easier? How are they assisting us in terms of making us more productive as we talked a little bit earlier? So I think there is a shift to how we have been doing things and to now we have a whole slew of tools and technologies that could really assist us in going much, much faster.

However, I think we have to look at those kind of things with a grain of salt. We have to use them pragmatically. We have to ensure that as engineers and as people who are writing code, is that we don’t lose some of the fundamentals that we have when we’re learning how to actually write code and write business use cases and things like that. So being able to utilize these tools effectively I think is going to be a big focus for a lot of folks in engineering.

Shane Hastie: One of the concerns that I have from some of the stuff I’ve seen that I’d like to get your opinion on is the use of these LLM models is I’ve seen them make good programmers better. What I’m not sure is, are we losing the basics and how do people new to the profession, in any profession that is utilizing these tools, where do they get the basic knowledge? Or am I just being old fashioned and do they need it?

Open questions about learning pathways [18:03]

Cassie Shum: I’m going to agree with you on here. This is what I’ve struggled with a bit. And, again, maybe I’m being old fashioned myself, but I think a lot of where good architectural patterns come in, good design patterns come in, are from some of these foundational and fundamental things that we learn when we are starting our career in engineering. So I do question this. I don’t also have the answer to this as well, but as I think about how say co-pilot, for example, really helps with a lot of the commoditized code, like the building up of different things here, I think it’s really good for speeding up productivity for more experienced engineers who they know that’s going to happen. They know that that’s how it’s going to be built, and I’ve just saved many, many hours doing that. But yes, I am questioning what that means for the next generation of engineers.

And so do we need to find a different way to teach those types of fundamentals. Or do we need to think about a different way to teach how to design systems or how to be a systems thinker and things like that. So I’m going to answer your question with a question. I don’t know, but I’m looking forward to seeing what this holds. And I’m keeping a strong eye on it too, because as we are all as leaders building our teams, we have to watch out for these things because it’s different from me hiring five years ago to hiring right now. So something to think about for sure.

Shane Hastie: And to ground us out. You said you’ve been in the industry two decades, you’ve got a lot of experience, you’ve moved through your career. A fair proportion of our listeners are people who are fairly new to leadership roles. What advice can you give them?

Advice for new leaders [19:44]

Cassie Shum: Oh, so many. But at the core of it, one of the things that I learned when I transitioned more into leadership roles is that you’re not going to get it right the first time. You’re not even going to get it right the second time. And so ask for help, reach out for help, talk to people about what leadership actually means. I have been very lucky, and I encourage anyone who’s listening to me, as well is find a mentor, find some leader that you look up to that you want to be like and go and have discussions with them. So I know earlier, Shane, we were talking about Rebecca Parsons, who was the CTO for Thoughtworks. And during my career there, I was very lucky to have her as one of my mentors. And so because she was someone that I looked up to as wanting to be a leader like her. So being able to surround yourselves with people on who you want to be is, I think, a very important advice for me.

And then the second one is really, as I said before, you’re not going to get it right the first time. It’s okay to make mistakes, but make mistakes fast. Don’t dwell on mistakes for a very long time because those rippling impact can be much, much bigger. So if you make a mistake, fail fast. The same thing with engineering, the same thing with coding. We want to fail fast very quickly and fail safely. And then each of those failures are learning to make you a better leader on the next iteration and on and on.

Shane Hastie: Cassie, thank you so much. A lot of good points, great advice in here. If people want to continue the conversation, where do they find you?

Cassie Shum: LinkedIn. I’m mostly on LinkedIn. Yes. So definitely feel free to ping me and add me. And yes, I’m very, very excited to have joined this podcast and excited about these topics. This is the big passion of mine is culture around engineers, so yes.

Shane Hastie: Thank you so much for your time today.

Cassie Shum: Thank you, Shane.

Mentioned:
•    Martin Fowler blog on Developer Experience
•    Architectures You’ve Always Wondered About track at QCon London
•    Cassie Shum on LinkedIn
•    Relational AI