Being Opiniated About the Engineering Culture you want to Build

Transcript

Shane Hastie: Hey, folks. QCon London is just around the corner. We'll be back in person in London from March 27 to 29. Join senior software leaders at early adopter companies as they share how they've implemented emerging trends and best practices. You'll learn from their experiences, practical techniques and pitfalls to avoid so you get assurance you're adopting the right patterns and practices. Learn more at qconlondon.com. We hope to see you there.

Good today folks. This is Shane Hastie from the InfoQ Engineering Culture Podcast. Today I'm sitting down with Viraj Mody. Viraj is the co-founder and CTO of Common Room. Viraj, thanks so much for taking the time to talk to us today.

Viraj Mody: Thanks for having me, Shane. I'm glad to be here.

Shane Hastie: My normal opening question is who's Viraj?

Introductions [00:55]

Viraj Mody: So, professionally, I am co-founder and CTO of up-and-coming startup called Common Room. And then outside of work, obviously I have a beautiful family and a couple kids and I try to play the best dad and husband I can. And prior to my time at Common Room, I spent a bunch of years early on in my career at Microsoft and then a tiny startup of my own with a couple other co-founders that ended up being acquired by Dropbox. So spent a few years at Dropbox, that was a wild ride. And then I was really curious about how marketplace software works and so worked at this company called Convoy, which was a trucking marketplace and then ended up reuniting with one of my previous co-founders, but also a couple other brilliant folks I bumped into in Linda and Francis to start Common Room.

Shane Hastie: So, tell us a little bit about what Common Room is there for?

Viraj Mody: Common Room is an intelligent community growth platform that helps organizations deepen relationships with their customers and their community wherever it exists, with the end goal of helping to build better products and drive business impact. So, you can think of Common Room as bringing together community engagement, product usage, customer data and business context into one single spot. And then from there provide realtime intelligence to various people in your organization, a more holistic context about who they're interacting with. So if you're on product and engineering, you not only see how somebody's using your product, you see what they're saying about it, where they're talking about it, what they like, what they don't like. If you are in sales and marketing or go to market, you can get context right alongside your CRM platform that then ties into all of the other surfaces where your community exists already.

Shane Hastie: One of the things that attracted me to having this conversation was your focus on developer experience. What makes a great developer experience?

What makes a great developer experience? [02:57]

Viraj Mody: I guess there's internal engineering culture aspects to developer experience that I spend a lot of time thinking about, as well as external like developer, customer relationship and developer experience as it relates to customers of your company. I think both of them are equally important. You can't get one without the other. And in many ways, one reflects the other. So, I am a customer of many other companies' APIs and developer platforms. And similarly, many other engineers are customers of my developer platform. So I think the number one factor for me is a deep empathy with the people you're serving and building APIs for. As we work on exposing parts of a platform, whoever it is, not just Common Room, deeply understanding what the customer needs and what pain you're solving for them, is probably the place to start. Instead of the goal of, "I want to publish a platform," or, "I want to have APIs," or, "I want to build something that helps me build relationships with developers." Like that's a means to an end but not the end in itself, if that makes sense.

Shane Hastie: So that's one part, the deep understanding of the problem you are looking to solve when making something available for developers. What about the cultural aspects?

Being opinionated about building the culture you want [04:16]

Viraj Mody: Earlier in my career I had a very different approach to what good engineering culture looks like, and I'll probably focus on the internal culture within a company, but I feel like you can derive from that. Over time though, I've become more and more convinced that opinionated engineering culture is the way to win. And I think it's a direct function of the team you've built. And so being opinionated about the team you're building, who is part of it, how you recruit, what are the characteristics of individuals that would be a good fit for your team, and on the flip side would not be a good fit for your team. And then using those to build an efficient and high velocity engineering organization. Now it's easy to think of this as homogenous, that's very different. I think there's still room for a lot of diversity of perspectives and views and experiences and backgrounds while still building a culture that is convicted in how it operates. Happy to dig deeper into that, but that's a pretty high level, maybe full of buzzwords answer.

Shane Hastie: Yeah, let's dig deep. Let's go down. So opinionated, when you say an opinionated culture, how does that show up in the world?

Viraj Mody: So for us at Common Room, it shows up across the stack all the way from our technology choices that we make. One example of a very opinionated approach for us is boring technology is good technology. We're all fascinated by new developments in different parts of the tech stack. Everyone's keeping track, there's mind-blowing new capabilities that you see every day, but we're building a business that serves real customers, has real SLAs that we need to go fulfil, and so tried and tested technology is what we'd bet on. That way we can move fast, we have good ecosystems we can rely on, we have good documentation tooling. A similar principle we use for opinionated tooling is just simplicity. When you work with really smart people, they can handle complex problems and they can deal with complexity. It takes even more layer of experience to realize that here's complexity you want to avoid or look around corners.

And that leads to sort of the next opinionated approach around how we've built our team. I was a new grad with starry eyes once upon a time thinking I knew everything about everything, clearly I was wrong back then. But our team today is mostly made up of people who've been in the industry and have had experiences at various companies of various types in the past, and that's very deliberate because of how we work. I think we would not be a great environment for somebody who doesn't come with a bunch of experience because honestly for our size and scale, we haven't invested in what it would take to onboard and make successful a new grad version of me. But with the team we have and the processes and tools we have, we are able to move extremely fast. We have a lot of guardrails in place, we have a lot of support in place, but it's all geared for the kind of individuals we have. So that's opinionated in terms of hiring and recruiting. Yeah. Does it give you a little bit of a flavor for what I meant?

Shane Hastie: So you touched earlier on and the risk here is the monoculture. How do you make sure when hiring in this opinionated way that you are, the buzzword term at the moment is hiring for culture add rather than culture fit?

Hire for competency and culture add [07:57]

Viraj Mody: That's a great point. So my approach to that is thinking in terms of competencies and realizing what competencies we have a weakness in or have blind spots in and helping close those gaps. And a derivative of a lot of those competencies is the experiences that people have had to be able to develop those competencies. So your classic infrastructure, heavy experience engineer probably has a spot on our team, but you get a couple of those and you're good enough and then you realize, "Look, now we lack competency in, I don't know, front end." And then on front end again, once you sort of marry the desire for the expertise you need along with the principle, the how you work, you end up creating a pretty clear picture of the kind of skill that is needed, the kind of person that might be a good fit for how you operate.

So a lot of times when I think of culture fit as you mentioned, it's more about does the person's ability to operate line up with how you operate? I don't think it's too much more than that, kind of reductive way of thinking about this is to break it up into components that are easy to stereotype. But if you stick with principles around scale and competency and ability to operate in a certain environment, that helps you keep a lot of the biases off the table. And then obviously making sure that the interview process is structured to extract maximum signal. Another opinionated approach if you will is, I want to hire people for their strengths, not for everything that may not be great about them. I'm sure all of us are great at a few things and terrible at many, many more things.

If we start looking for the things people are terrible at and then use that as a reason to exclude hiring them, that's a pretty slippery slope to get down. And so once you have a clear picture of the scale and the kind of operating background or the ability for people to execute the way you want to, you can work into a pretty clear process that helps you evaluate their strengths that line up with those. So, I don't know if this is infallible, but it's been our approach and it's helped us build a pretty good team that people from diverse genders, diverse backgrounds, diverse skill sets. And the bonus that I've observed over the last few years is we learn from each other because we come from a very similar place of how we work, but our experiences and skills are so different that that's where we focus on how we learn from each other.

Shane Hastie: So that learning, engineers are by nature, broad generalization here, are curious, are interested in learning. How do we make space for that learning in the pressures of building a startup?

Support people to grow in areas they are interested in, even if it’s not their core competency [10:43]

Viraj Mody: You can try and aspire and often succeed and sometimes fail, that's been my experience. So transparency I think is the baseline in terms of being transparent with your team about what you can and cannot offer them in terms of experiences and opportunities, and then expecting transparency from your team about what they want to learn and what they want to experience. And once you have that as a baseline, then it's very easy to make those connections and open up opportunities for people to do stuff. A simple example, we have engineers who haven't been exposed to the business side or the customer facing side of companies in the past, and they express the desire to learn more about those aspects of what it takes to build a company so that in the future if they want to do their own startup, they obviously have the technology side of it covered. How do they learn more about running a business?

Once you know that it's very easy to make that opportunity available to the team because in the back of my mind I know it's like, "Hey, we have this customer call coming up, this one particular engineer is really curious about how that works. Let's get them on the call." And at our scale it's really easy to do this. There are very few silos, very few boundaries. And in many ways, Common Room, the product aspires to do this for companies at various types of scale. Because I remember from my time at Microsoft I learned a lot because it was my first job but I never interacted with the real customer other than myself. And that was really bizarre now that I think about it, it was just impossibly hard. I'm sure it is at other large companies too, to really speak with customers because there's layers upon layers of product managers and product marketing and sales and who knows what, customer service.

But the ability to directly interact or hear from or see the raw words that customers are saying about stuff you've built, about stuff you are tasked with building can be game changing. Going back to your original question around building developer relations and that empathy component, when it's filtered through different layers, it's always hard to tell what the raw feedback was, what the raw sentiment was. But if you see it and you have the capability of seeing who said the thing, in what context, where and what were the exact words, that just helps you solve for their problems in an exponentially efficient way.

Shane Hastie: So let's segue and talk about community. What does community look like in the developer experience world?

What makes a community? [13:17]

Viraj Mody: I feel like people try and silo that into a single platform or a single program or a forum or whatever is happening on your community.company.com domain. I think community encompasses everyone who's engaging with your organization or your product or your APIs or your platform. Everywhere they're engaging with you, it's made up of your product users who are current customers, it's made up of your biggest champions and fans, it's made up of your detractors, it's made up of people who may have heard about your product but aren't using it yet.

And more importantly, it exists even if you don't know it exists. I feel like that's the one thing I see most over the years, is organizations or companies feel like they have to go find and develop a community but one exists already. You just have to start with it. You just have to discover where it is. There's people talking about you on Twitter, there's people talking about you on LinkedIn, there's people talking about you in forums, there's people trying out your product and leaving reviews. All of those are part of your community, whether you know it or not.

Shane Hastie: How do you tap into that community?

Viraj Mody: Well, ideally you would use Common Room as a starting point. Yes, I'll stop shilling for my own product. But no, I think that is really the key question. I feel like today it's incumbent that you understand your customers and build for them, otherwise you're bound to fail. And if you try and bring your customers to a particular place, that's not going to work. People are where they want to be and you have to meet them where they are. And I think that's the big challenge of discovering and interacting with your customers today because the ecosystem is just so vast. Social media has made it possible for anybody to have an opinion, anybody has a blog, you produce a YouTube video criticizing a product, praising a product, tutorial on a product. And I think that is a key challenge that is emerging for fast growing companies is how do you keep up with all of these platforms?

It's just physically impossible to have somebody watching everything. And then even if you are able to do that, how do you at scale separate noise from signal? I'll give you an example. We have customers who have the craziest fans in the best way possible producing content on YouTube and writing articles on blogs or tweeting out tips and tricks on how to use products more efficiently, which is great signal. But at the same time you have a bunch of people retweeting that stuff that doesn't really count because it's already something you knew about or some bar producing spam of some sort that just happens to match keywords that you might be listening for, it can get overwhelming. It's really tempting to try and want to keep up with everything and have this massive spreadsheet where you paste in a link to every tweet and every video.

But even if you're moderately successful that thing's not going to scale. So I think you're correctly highlighting one of the biggest challenges I see is keeping up with what your community is saying where they're saying it, while resisting the temptation or trying to funnel them into one spot. Right? Someone could very reasonably argue that the right strategy is no matter where I discover people talking about my product, I'm going to try to pull them into my forum software or my Slack channel or my Discord server. And I believe that is doomed to fail because in 2022, people expect to be where they're comfortable versus trying to be forced to communicate with you in a certain place.

Shane Hastie: Shifting focus, you've got a solid career of building companies in that tech space. What advice would you give the new leader in a team? The recently, I was the best technologist and now I'm being promoted into the team lead role. What should that person be doing?

Advice for new technical leaders [17:05]

Viraj Mody: A few things. One that I suspect most, literature already goes into depth about for such transitions is understanding that this is a career shift instead of a progression. Being a great engineer and leading a great engineering team are two very different competencies, require two very different sets of skills and strengths. Just because you may be great at one does not automatically imply that you will be great at the other or you may be great at the other. So having that awareness, I think is important. Everybody including me, this is a transition that may or may not work, and knowing that is I think important. That will be probably the first piece of advice I'd give someone contemplating this. I would probably have more textbook advice that I'm sure people can go look up. So I'll probably give a hot take version of it.

I think it's important to believe in your instinct and your conviction once you've understood that this transition is for you. Because ultimately, you are still leading a team of engineers. And assuming you have the skill to be a leader and a manager, you still are a damn good engineer. Switching into this role does not make you any less of an engineer than you were before. I feel like there's this trope in the industry that engineers should not be writing code and engineers should not engage in technical discussions, leave that to the tech leads or the engineering managers. I think that's not the right way to build a company or a highly technical organization. If you are an engineering leader, you're an engineering leader, not a manager. And therefore don't fight your instincts about good engineering intuition. I see that as something that's been propagated more recently in the industry.

As you know, a manager is a manager and they're here to run processes and project manage and deal with career progression. Sure, but they’re s still engineers first. So don't hesitate to lean into your intuition and your technical strengths, would be another one. And then I think this is again generic but worth repeating for anybody considering a transition like this, your gratification model has to change when you are an engineer, you know, write code, you ship, it works and that's how you get gratification. There was a bug, you solve it, you fix it, it's no longer there. That's your gratification. When you're leading an organization or a team, you are a couple of degrees removed from that instant gratification cycle.

An engineer on your team fixes a bug and feels good about what they've done and somehow that has to translate to you feeling like you did your job, or people on your team solve problems and succeed in their careers and are successful. And that has to result in you feeling gratification for you doing your job. So the time delta between you doing a good job and you recognizing that it was effective, is much, much bigger as you transition more into leadership. Getting comfortable with that and recognizing that I think is important. And to the flip side, some of the more terrible managers are the ones who do not understand that and try to either steal glory from their team or deflect blame to their team, because it cuts both ways. You seek gratification from their success, but if things don't work out, you've got to be the one on the front lines for it.

Shane Hastie: Thank you. Looking back over your own career, what's the thing that has given you the most satisfaction?

Reflection on career satisfaction [20:40]

Viraj Mody: For me, knowing that I can take risk that's appropriate to the reward without the fear of taking the risk, is probably the thing that I have seen myself do best and learned to really appreciate over the years. I have made a bunch of career transitions that many people would consider too risky to do, and my calculus has always been based on some understanding of risk and reward and over time that keeps getting more and more sophisticated.

So there's obviously, I could speak loads about technical details or things I've learned or grown there, but I feel like a really high level representation that applies both to career things, technical things, leadership things, is just understanding what risk is worth it and what risk is not worth it. Again, this is very subjective, it's very personal. Different people have different tolerances based on their life circumstances, based on their experiences. So yeah, I think knowing when to back convention if your gut says it's the right thing to do, and then knowing when you know what, others may be doing a thing, but that's not for me.

Shane Hastie: Viraj, thank you very much. If people want to continue the conversation, where do they find you?

Viraj Mody: I am on Twitter as @Virajm and email at virajmody@gmail.com. V-I-R-A-J-M-O-D-Y@gmail.com. Happy to chat with folks wherever.

Shane Hastie: Thank you so much.

Viraj Mody: Thank you.

Mentioned

• Common Room
• Viraj on LinkedIn and Twitter