Creating Great Company Culture that Doesn’t Suck and Improving the Developer Experience

Transcript

Shane Hastie:  Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today, I have the privilege of sitting down across the miles with Shanea Leven. Shanea is in San Francisco. I'm in Ōtaki, New Zealand, so it is across the miles and across the days. Shanea, welcome.

Introductions [00:35]

Shanea Leven: Yes, of course. Thank you so, so much for having me. I'm very excited to chat.

Shane Hastie: Probably a good starting point is who's Shanea.

Shanea Leven: Well, currently I am the co-founder and CEO of CodeSee.io. We're a developer tool that helps developers to visually understand how their code works and collaborate effectively. I've spent the past almost 10 years in DevTools, working at Google, and eBay, and Cloudflare, and Docker. I studied computer science and business, spent most of my time in products because I love technology, but I also love people as well. We have a pretty big vision, so we're just executing on that every single day. That makes me become who I am.

Shane Hastie: What is that vision?

The benefits of visualizing a code base [01:21]

Shanea Leven: I guess I can start with, very quickly, I'm sure a lot of developers have found this problem where you have a bug or you are starting a new job or you're starting a new team, and that code base is just so massive and overwhelming. The only way that we have today to understand our code is to read it line by line. It is the most manual way that takes the most amount of time, and I think that's really dumb. I think that every other industry has visual tools or has summaries of how they understand things before they dig into details. And CodeSee is the manifestation of that vision for code. And so, I think once we can visualize our code, once we have the saying a picture is worth a thousand lines of code, if we have those pictures, so many things in our industry can change as a result of that.

Shane Hastie: Showing my age, I recall having to read through nearly a million lines of assembler code.

Shanea Leven: That's the same experience. It hasn't changed. The language is different, but that doesn't change.

Shane Hastie: Tell me a little bit about your background. What are you passionate about?

Shanea Leven: My background, as I mentioned, I studied business and computer science. I've always been in a technology industry. I actually learned to code after I was an analyst, and I was writing macros for Excel and client's programming. This is my passion. So, I was actually at Google when I started working in developer tools, and I was first working in ads as many Googlers do at first. And then, I got this role in Google developer product, and I could see an opportunity to help build tools for the people who build for other people. And so, by helping the engineers really build and change our world, it's like this force multiplier effect. You can help so many other end users by helping engineers. And so, that really is my passion, for not only helping them, but helping other people get into engineering, helping them to be successful in engineering, helping to create great companies where the culture doesn't suck so that engineers can thrive. As a result, I hope that our world is a little bit better.

Shane Hastie: Let's explore that: great companies where the culture doesn't suck.

Shanea Leven: Sure.

Shane Hastie: How do we build? I'd like to tackle as part of this, the diversity and inclusion question as well, because you're a woman of color. This is an industry that hasn't got a great diversity and inclusion history. I would like to think that we are working towards improving that, but are we, and how do we get better?

Building great companies where the culture doesn't suck [04:13]

Shanea Leven: Yeah, I do think we have a long way to go. I've personally experienced in the companies that I've worked at, every typical thing, that minority space. I think that, for me, I would love that to be better. I do think we have a long way to go. I do think that culture starts from the top, and it has to be a priority in leadership, and it's hard to do. I'm not going to kind of sugarcoat it. It has to be a priority and you have to work toward it every single day. Because particularly, as a startup, we're all trying to make a business successful. That's also very hard in and of itself. And so, if you're not working towards that goal every day, particularly as an early stage startup, it can get lost from some of the other priorities.

I think that in order to make that happen and work on it consistently, the founders or the leadership team has to really think about its culture as a product in and of itself. That's how we think about it. When you create a product in and of itself, you have to think about the vision of it, what success looks like, how to actually execute it, and then, actually properly execute it for processes on it to be able to scale it. All of the things that we do as engineers. And then, also create principles that like, what are your north stars to making sure that you're going the right direction? And so, I think, thinking about culture that way has helped, I think, us to try to create an inclusive and diverse culture from the ground up, as opposed to kind of bolting it on.

Shane Hastie: Given that culture as a product, what are some of the things that you have done at CodeSee to make that?

Thinking of culture as a product in and of itself [05:54]

Shanea Leven: I'm going to let everybody know that even though I'm talking about this, we've obviously made mistakes because we're all human. I think that that is actually the first thing is to recognize everybody's humanity in treating humans fairly and treating people with dignity and respect at a fundamental level. But at CodeSee, we have six core values. These are self-reflection, trust, humility, communication, transparency, and seek to understand, which is all about our understanding. Basically, it's another summary for curiosity. And so, we have basically put in processes to be able to scale that. Our culture goes from starting from the candidate's experience. So, everything from our job description, where we talk very specifically and at length, hopefully in an engaging way, about our culture in our job descriptions. In our interview process, we screen for those six values before we evaluate someone's technical skills. And then, we do an even deeper dive on those values after we do technical skills.

We are getting better at having processes over for performance reviews and that sort of thing. But we do have a culture of feedback and self-reflection and creating environments where people can feel safe, speaking up, pushing back, asking questions. I often say, "Hey, if this thing is really dumb that I'm saying, even though I'm the leader, just tell me. We can work on this together." And being able to support each other in that, and new people coming in, it kind of takes them aback that we're as open and supportive and giving feedback at scale as we do. But once you realize that, hey, I am actually safe, it makes it so much easier from there. And then, there are little things that we do outside of the standard. For example, we call our stand-ups up-ups to be inclusive of people who can't stand. Little things like that to recognize that we're all human.

Shane Hastie: Sounds like a fun place to work. Let's maybe delve a little bit into the work. You mentioned the visualization of code bases. I can certainly recollect the... I haven't coded in anger for a number of years, but I certainly remember the amount of time spent combing through library code and yeah, just horrifying. What does it mean to visualize a code base? What does that look like? What does that look like?

Visualizing a codebase [08:36]

Shanea Leven: Our product, we hope that it helps from the first time where you're seeing a large code base. So, we visualize all of the files. We then are able to show dependency lines. We're able to pull out insights that you might not be able to get some reason or information, where commits are happening, where all the hotspots are, and we're able to pull that out of the code automatically. So, the developer doesn't have to. And then, as the code changes, we also keep that visualization, all of the files, dependencies, all of those things up-to-date, so that developers don't have to do that on their own. And then, if you'd like, you can create and put any kind of architectural knowledge, labels, notes, features, tech debt, but anything, ownership on top of that map, and we will persist all of that information for you.

And so, from the initial browsing experience, you can then get kind of an understanding of, hey, where do I get started here? And hopefully, reduce some of those unknown unknowns. And as you go into writing your code, we can basically, once you spin up like a draft PR, we can visualize your change in the context of the rest of the code base. Personally, I can see like, oh, hey, does this code that I just wrote touch anything else, impact anything else? Is this looking the way that I imagined it in my head? If not, I can change the code and update the diagrams. And then, once that diagram looks exactly how I imagine that it should look, I can pass that along to a code review. So now, I'm passing those mental models off to my teammates, can collaborate with my teammate. I can get the feedback, go back and change the code until it's ready to be merged. And then, once it's merged, that diagram will update the original map and everything starts over again. It's really having a visual buddy walk-through from conception all the way up to merging.

Shane Hastie: I could imagine having that buddy sitting next to me would've been really nice.

Shanea Leven: We hope so.

Shane Hastie: We're talking here in the overall realm of developer experience, which is certainly a topic that's starting to come to the fore, I would say over the last three or four years. We've seen more and more recognition of the need for improving developer experience. What else can we do as an industry? Where do we need to go to smooth out this developer experience? And what does it buy us?

Removing friction in the developer experience [11:11]

Shanea Leven: Any time you can enable an engineer to feel a little less overwhelmed, a little less anxious. You unblock them a little bit faster. It unlocks so much value for your company because engineers are creators of the thing that is likely you're doing. And so, the more that we can enable them, the more the business and the company benefit. I think that developer experience is a very large term, and it can be used to understand the culture. It can be used to describe your in-app product experience. It can be used to describe your external documentation. It can be used to your support. And so, I think that companies, as best as they can, should invest in those areas, not only within your company, your internal developer experience, how you get code out the door, how you help train engineers, how they pair and collaborate with each other to produce more code. But then, also thinking about the developer experience, particularly a developer is using one of the products that you have, or tools or anything like that.

There are lots of points in the software development life cycle that can absolutely be improved. The one area that we like talking about, that I am super passionate about talking about is there is an entire point in the software development life cycle that's just not on the infinity sign, which is understanding. Usually, we start the software development life cycle at the build part where you write the code, but developers spend 60% of their time reading code before they ever write any. And so, we don't actually have tools to help them read and understand code a lot faster than actually the writing code. That's really where the hard part comes in. We have this metric that like, when do you understand code?

And that is when you have a plan, you know how to move forward. Once you do that, writing the code typically is easier than being like, "Hey, what are all the parts that I need to consider? How am I supposed to architect this? What are all the things that I'm missing? What are all the unknown unknowns that I don't know?" All of those things. And so, I think that that's a huge part of the developer experience that were absolutely just missing. And yes, we can try to tackle it, but I'd love to build an ecosystem around helping developers understand their code a lot better.

Shane Hastie: You've founded the startup, and one of the points that was made was that it's a husband-and-wife team. What's that been like?

Founding a startup as a husband-wife team [13:45]

Shanea Leven: I get asked this question a lot. It's great. I've been a part of small startups. I've been a part of big startups. Our marriage was intentional, the company wasn't. I was actually supposed to start CodeSee with some colleagues from Docker, and then, the pandemic happened. I was still kind of pushing through, talking to developers, talking to users, kind of putting together a product plan and what it was going to look like. My partner was just there, and he is a brilliant engineer. And so, we bounced ideas off of each other, and then, COVID happened and we were kind of stuck in the house together for two years. That's how that happened.

I think that we have a co-founder relationship, just like any other co-founder relationship, where I think it's actually a lot easier than most co-founder relationships from my perspective that I've seen, because we have very clear roles and responsibilities to who is the owner of which part of the business and who is the final decider. And then, one person can advise on those areas. But, ultimately, we know who makes the final calls in those areas. We have a level of communication that is deeper than most. Once you know someone’s deepest, darkest secrets, everything else is gravy to be able to talk about. And so, to be able to build the kind of trust that we have just allows us to execute much better.

Shane Hastie: How does that reflect into the teamwork practices for your teams, with people doing the work?

Teamwork practices [15:17]

Shanea Leven One, we tell everybody when they start, when they first meet us, some people kind of already know and they're like, "You have the same last name, but you don't look the same." And so, we start that, kind of tell everybody up front. But as far as how we communicate, I think that we communicate with each other exactly the same as we communicate with any other team member. When a new member joins the team, we ask them like, "How would you like to receive feedback? What are the things that will set you up for success?"

We have this culture around this amazing book that I highly recommend anybody to read, which is called Crucial Conversations. Both of us have already practiced having hard conversations, and we've had lots of hard conversations. If one of us needs to give feedback, particularly in front of the rest of the group, because we're co-founders and because we're married, we do. We know how to do that effectively, so it doesn't create any weirdness. Occasionally, a babe would slip out like, "Babe, this..." occasionally, but we try to remain professional, and we have our different hats, et cetera.

Shane Hastie: I'd like to explore a little bit more of the teamwork practices. This is the Engineering Culture Podcast. What are some of the things that you've done with your teams? You've spoke about that culture as a product and so forth. What's happening on the ground?

Culture design [16:39]

Shanea Leven Our team, the culture is really around those six points. The self-reflection, the humility, the communication, giving feedback, being curious. All of those results in deep trust. And so, it starts with that. Our team, basically, in order to work together, we pair. So, one person doesn't have one picture of the code base outside of our products. We all deeply can exchange those ideas and pair with each other, et cetera. We also have a very supportive team. So, if there are questions, if there are concerns, if there are pushback, people ask us. I am technically the product manager in addition to CEO. And so, we do weekly sprints, Josh and I, with the rest of the team. We're operating on one week sprints, because, one, of just the ease of using our own products, but, two, just the communication and just the talent we have on the team. And then, if you want to get into some of the stack things, I can also get into that as well.

Shane Hastie: A little bit about the stack would be interesting.

Shanea Leven Okay. We are technically writing things in TypeScript, although we do have some other things in a few other languages because our product supports multiple languages. We have push button deploys. We have not gotten to continuous deployments yet. Our team's a small but mighty team. We are mostly all remotes. Remote first, although we do have hubs of people in different places, but they're mostly West Coast based, those hubs, which makes the time zone thing not an issue, which I think helps us execute a lot faster as well. I mean, it's basically like any other team. We do our sprint planning on every Tuesday. We go, go, go until Josh and I do pre-planning on Monday, and we do a product review session on Fridays. Basically, whenever someone is finished, we do demos. We basically will shout demo demo, and everyone looks at that and supports each other with the things that they're building. That process continues. It's worked really, really well for us to be able to execute quickly and move and mitigate and change if customers ask us to, and I think two weeks is just like an eternity in the startup time.

Shane Hastie: As you grow, as you scale, how are you going to bring this culture to life?

Shanea Leven: I really think as we grow and as we scale, it's training the team right now, that's in place right now, to be better advocates for our culture than Josh and I are, because those people are going to be bringing in the next wave of people. At some point, it's going to get bigger than just me and Josh doing the hiring. And so, being able to protect that, being able to put scalable processes in that make the other people who are executing it successful, and holding managers accountable to that, I think that we have an idea around keeping the teams manageable in size. And so, putting proper managers in place who are trained managers to make sure that they are just as advocating for our culture as we are. I think that's how we scale.

Shane Hastie: Shanea, thanks for taking the time to talk to us today. If people want to continue the conversation, where do they find you?

Shanea Leven: They could find us on CodeSee.io. They can also find us on Twitter, CodeSee.io. Shanea Leven on Twitter. I answer all of my tweets. You can also email me directly, shanea@codesee.io.

Shane Hastie: Thank you so much.

Shanea Leven: Thank you.

Mentioned

• CodeSee.io
• Book: Crucial Conversations
• Shanea on Twitter