Get your Orgitecture Right to Enable Great Culture

Transcript

Shane Hastie: Hey folks, it's Shane Hastie here. Before we start today's podcast, I wanted to tell you about Q Con London 2024, our flagship international software development conference that takes place in the heart of London next April, 8 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.

Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I'm sitting down with Shobana Radhakrishnan. Shobana, welcome. Thank you so much for taking the time to talk to us.

Introductions [01:03]

Shobana Radhakrishnan: Thank you, Shane, for the warm welcome. Really happy and excited to be here with you today.

Shane Hastie: You are a senior director of engineering on Google TV, and -  actually I won't do the and. I'll allow you to tell us a little bit about yourself. What's your background? How did you get to this position?

Shobana Radhakrishnan: Sure. If I've given long enough, I could go on for hours, but I'll keep it brief. I greaw up in India several thousands of miles away and moved to the US to pursue higher studies in AI actually. I moved to Urbana-Champaign to pursue a master's degree in computer science, focused on parallel processing and AI work. After spending one winter there with all of the snow, if anyone knows anything about the southern coast of India where I grew up, there are only three seasons. Warm, hot, and hotter summer, and those are the three seasons. So it was a big contrast and in my mind I said, "The first job I'm going to get in the Bay Area, I'm moving." I was lucky enough to get a very exciting role in a search engine company called Excite. Some of your reviewers may remember Excite and Lycos from the pre-Google Days, and I moved to the Bay Area and haven't looked back since.

I've moved from really small startups, like 30 people through the several thousands to hundreds of thousands of employee companies. I've been fortunate to go deep in the tech stack with device drivers and also building backend and UI and just a part of the broad technical steps. I have had a lot of opportunity to learn a lot over time and at Google I'm responsible for engineering for a product called Google TV, as you mentioned, which brings the goodness of Google Search and Google Assistant into the content viewing experience on TV. Pretty cool stuff and a lot of innovation going into it, which I'm super thrilled about.

Shane Hastie: One of the things that I know from our conversation earlier is that you're really passionate about the importance of culture on teams. This is the engineering culture podcast, so possibly a good starting point for that is what is a good culture?

What is good culture? [03:08]

Shobana Radhakrishnan: The interesting thing is there isn't a single answer to that and here's why. Because I think the culture of the team, as you mentioned, I am very, very passionate about building great team cultures, and because the fabric actually matters for the outcomes from the team. Because if you have good interviewing practices, you know that you're going to bring the technically smartest people onto your team, which is critical in engineering. At the same time, what ties them together? What gets them all working together for the overall team performance and productivity may be different from individual performance and productivity. That's where the culture comes into the picture. Every leader has to think about their team, need to think about what is the culture I want to set on the team? For example, is it a culture of ownership? Is it a culture of innovation? Is it a culture of quality focus?

Maybe it's all of the above, but it's really important to think about what are the defining characteristics you want to set in your team? The reason there isn't a single answer is it sometimes depends on where in the lifecycle your company is, your organization is, which is why I didn't want to give a one line answer to the what's a good culture? But culture is critical and every leader should be answering that question periodically at least once a year, if not more frequently and constantly thinking about it.

There are a few core fabrics, so you do want your team leaders to be able to work with each other. They may disagree, they may agree, or they may have strong opinions, but you want a self-sustaining leadership teams at all levels who are able to work together and align on what the next steps are, how they move forward, and also the disagree but comment. Again, everyone has opinions and you want people with different opinions on your team, but every set of leadership team at all levels needs to be able to buy into the decision and disagree, but commit and move forward constantly. There's a few common cultural elements you do want and there are some things that you probably want to think about based on where you are in your journey as well.

Shane Hastie: Self-sustaining leadership, how do we create that safe environment that does become self-sustaining?

The importance of self-sustaining leadership [05:18]

Shobana Radhakrishnan: The reason the self-sustaining leadership is important is you want to go on a vacation periodically. You don't want to be the one sitting there and making decisions, and that's the reason you want that at all levels, it's not just only the senior levels. The strongest reason I believe self-sustaining leadership is important is because there are day-to-day decisions that your leadership team is making all the time, so you want there to be a common set of principles and themes and goals that they're bought into and a set of dynamics that they can work with each other on in an independent fashion in general, because it's not just a quarterly planning and annual planning that leaders make decisions or team members make decisions. They're making decision all the time in every meeting, in every discussion, and even when engineers are making implementation choices, they're making decisions all the time, which is why that self-sustaining element is important.

Now, in terms of how can you create it, I feel it starts with empowerment and knowing that they can own and they do own their decision making areas. It's both empowerment and the other side of the coin, which is accountability. You want people to feel like they can make the decisions within their scope or even working with their peers in a broader scope, they can most of the time make decisions independently. I feel like empowerment and accountability. Once people make decisions, then they're also signing up to be held accountable for those decisions and it has to happen at all levels. It starts with the person who's creating this culture as well, that they are transparent about their own mistakes, they are transparent about feeling like an owner and expecting their teams to feel like owners within their areas as well.

Shane Hastie: In that empowered accountable team environment, how do we overcome some of the challenges that we've seen in information technology and in technology teams in general, the built in bias, the lack of inclusion, some of the very visible culture challenges that are out there?

The core of good decision making is inclusion [07:21]

Shobana Radhakrishnan: A very interesting question, and I'm so glad you asked that because at the core of good decision making is inclusion. It is about making sure that all the voices are heard in the room. It can be in a small meeting making a small decision like a code design decision, or it could be a major, should we invest in this company? Should we acquire this talent from the startup? It could be any kind of decision, but making sure that voices are heard and people feel like their voices matter before a decision is arrived.

I think that's basically what inclusion means to me, and it is simpler to say it than to actually have a team culture that practices it. I certainly believe this actually comes from the top. The leader actually needs to walk the talk. It's not just about having a bunch of training, a bunch of online documents and saying "We have an inclusive culture." It's actually about everyone feeling like this leader actually walks the talk. When they are countered, even in a big team setting, the leader should be totally okay with it. They're totally comfortable and visibly being able to listen to a completely alternate point of view and reason about it and making sure that they're taking it, irrespective of the level of the person or the relative position of the persons expressing it.

This culture rubs off on all levels of leadership. Everyone feels like, oh yeah, this is great. This is probably how I want to run my team too. The more everyone sees leaders practicing that, then the teams themselves know that expressing actually does make a difference, so they start expressing their input and opinions and the communication just flows in all directions and you are definitely going to make better decisions. I feel like the two are very, very closely linked.

At the same time, there is the other balance of you want to be clear about who's the ultimate decision maker too. You want everyone to be heard, but oftentimes people can make the mistake of gravitating to decision by committee also, and then people feel like, well, it takes a long time to make decisions. I don't know who the decision maker is, and you don't want the team to drift there either, so it's a balance. I feel like being able to practice it in a practical way that works for your org, that's step number one.

The second big part is actually formal training and active discussions about these topics actually do matter. For example, in many of my teams over time we have had discussion about what does allyship mean? How can each of us actually play a role? We make it a discussion topic, and that puts everybody into the proactive brain space of thinking about it versus a passive training they receive and separating it from their day-to-day work. It's actually getting them to think about, are there any recent meetings where you felt like, hey, there was a good allyship practice here? Then having people share these practices and it just makes them internalize that it's an active role and not a passive support role. That's the second bit.

The third was actually getting feedback on an ongoing basis from your organization to say, "How is decision making working? Are you feeling included? Are we making the best decisions? What are the areas in which we could be doing better?" Constantly getting that feedback flow to establish that transparency in the organization and then playing back the feedback that we heard to the team saying, "We asked you for feedback and here's what we are doing well, here's what we're not doing well." The transparencies again goes back to accountability and then saying, "So we are committed to improving this, because we heard from you."

That's to me, the third element is really making sure that the feedback is flowing and translates to action so that organizations are always looking for how do I become more and more inclusive where everyone's heard and how do we always make better decisions and more efficient decisions?

That's what I believe.

Shane Hastie: Can we drill into that allyship? What does good allyship show up as?

Good allyship is proactive in the moment [11:09]

Shobana Radhakrishnan: I think good allyship shows up as proactive in the moment action, proactive and timely action. There can be different umbrellas. For example, you may be having a meeting with 10 or 15 people and maybe a couple of people are taking over the meeting or you see that a couple of people look like they want to contribute something, but they're not quite comfortable. You can tell from maybe the dynamics on the team. This is a small example of allyship playing in day-to-day environment, which is when you notice that, you just in the moment act on it and say, "Hey, it looks like you want to say something, let's hear from X."

Really internalizing it's a proactive listening and timely action role. You don't have to be the one running the meeting. You don't have to be the senior most person in the meeting to be an ally. Anyone in the room can be an ally. I think that's the second bit. So, to make these two together make for good and stellar allyship. I think this also can benefit from again, ongoing training, ongoing discussions about what's a meeting where I could be doing something? Just getting it into the active mode versus the passive mode. The best allyships are when someone took action before the person who was impacted by it even bringing it up. To me, that's the most beautiful form of allyship.

Shane Hastie: How are we doing as an industry in that regard?

Shobana Radhakrishna: I'm one of those people who is typically my friends call me optimistic in bucket half full person, but in this one I feel like we have 8 billion people in the world. Are we able to include everyone in our thoughts when we design products? Are we able to include everyone in decision making? People of all backgrounds, of all genders, races, socioeconomic backgrounds, family backgrounds, even that can make some people feel privileged, some people not feel privileged.

There's a lot of different types of allyship and privilege. I always feel on this topic, my career is almost 25 years now. Every year, I still feel like we have so much more to do, so much more today ever since I've been a student and probably in the 50 years if you ask me, I'll always feel like we could do more. That's me, but we can definitely do a lot more as an industry. I do feel we've come a long way, because a lot of people are much more familiar with the different nuances, different varieties of privilege compared to say 10 years ago. There's just a lot more awareness that I can see in all kinds of conversations. But this is one of those things where there's a lot more to do. I think each one of us should be thinking about it every day and making a difference happen.

Shane Hastie: The term that you used when we were chatting before we started recording is "orgitecture" and it just resonated with me. Tell me, what do you mean by "orgitecture" and why does it matter?

Designing Orgitecture for effective decision making [13:48]

Shobana Radhakrishnan: I hope they add it to the dictionary one day. As an engineering person, there's a part of you that only wants to worry about architecture and design and implementation, especially when I'm writing code that's all I wanted to think about and design and implement. Then there is the organization which then affects the who has to agree on the design, who needs to agree on the code approach, who needs to make a decision on the priorities or even something day-to-day, like who prioritizes how much of tech debt we have to pay off this quarter? What does tech debt even mean for us and so on? What I have noticed over time is the two are extremely interrelated, because effective organizations need effective decision making. Effective decision making, especially for engineering and technology organizations is about decoupling of what I loosely call tech stack, decoupling of concerns.

For example, in any typical high level architecture for a consumer product, you may have the user experience layer, which is visible to the user. There is a middle layer, which does the intelligence, let's call it, and there's a layer which stores the data and handles all of that at very, very high level. Every engineering leader who owns any part of these has to wake up thinking about how do I evaluate the complexity of when my team can deliver something or when can I give the plan or when can I close on the architecture? Who's the right person to work on architecture? The more cooks you have in these kinds of conversations, the longer these will take. That itself leads to unproductive deal over time and frustration for the engineers, the product stakeholders, and everyone. Being able to decouple the concerns of what should the architecture look like, what is the right estimate?

To the extent possible, there is never a perfect organization in the real world, but to the extent that you can decouple at least 80/20, there is a lot of efficiency to be gained for that from both the productivity of the engineering organization and productivity for stakeholders who rely on the engineering organizations to make timely additions and deliver. I have actually seen examples of cases where there's so much fine-grained ownership split that there are five different technical leads trying to make a decision on something that if there were one person owning it, they could have made it in a few hours.

That's why the term "orgitecture", especially for engineering and technology, the org structure as mapped to architectural ownership affects the pace of decision making and productivity a lot. This is something that I have tried to over time at least once a year or once in two years, just have a very transparent conversations with the leaders in the organization saying, "How are we doing on this? What's the pulse of? How's the decision making feeling in terms of pace of decision making efficiency?"

Then invariably queries and examples will come up where it's like, I thought three people are involved in this instead of one or five people, and it took so much longer. Then there's always that scope for, so how do we optimize for the next year? Are there some small shuffles we can do so that we keep aligning with that general principle? Because ultimately it's all about productivity and how agile your organization can be, no matter how large or small your organization is, that's what matters. That's what product and business stakeholders rely on engineering organizations to be on top of.

Shane Hastie: Looking outside of the engineering goals to business goals, how does that influence orgitecture?

Business goals should guide orgitecture [17:12]

Shobana Radhakrishnan: That's a really interesting one. I will say it's going to be a lot of art and some science in general, because it starts with engineering leaders also being very plugged in and paying attention to the business and product trends, at not just a quarterly or annual level, but at the multi-year level, just having a very close relationship with product and business peers to say, "Where do you want us to head? Where do you see us going?" Also getting that, again, two-way feedback of what is working well or what could I be helping differently or more? A lot of input starts coming in terms of, "You know what? This is where I think the industry is going and we need to create this innovation. We need to build this cool thing and showcase to our customers or partners," and then the wheel in the brain starts rolling for the engineering leader as well.

Okay, so this is what they want to do. I know that to do this, here's how architecture is well poised, and here is where there's going to be bottlenecks in the architecture that's preventing us from really leaning into x, y, or z. Because any engineering leader is always plugged into where are the tech debts? Where is the place where there is a lot of operational overhead to get something done? Or where is the knowledge and expertise the least within your talent?

You always have a pulse of that in general. As you listen to this, then the orgitecture starts evolving because sometimes it may be as simple as, I need to bring a senior person who's really familiar with this space, or I need to make sure that these two people are empowered to take on more because right now they're under resourced. We are not given a lot of resources in that area, but I see that my business leader needs us to move the needle there over the next couple of years or even few quarters.

That is on the pure organizational side itself. Then when it starts going into orgitecture is more of a, oh, I know that part always takes a long time to make changes, but it looks like for an upcoming business, that's where a lot of our functionality is going to have to be. I may think about proactively what's the kind of tech debt and architectural changes I want to bring in? Who are my best leaders to take that on now versus later?

Forming the thought process of what needs to happen now versus next month versus next year or beyond, and who are the right people to take it forward, by listening to the product and business stakeholders and digesting that. That comes with building again, a strong sense of intuition within your own systems and teams by connecting with the teams through direct one-on-ones, skip levels, sometimes leaders do round tables, so technical leads or engineers around the organization periodically. It starts with having a pulse also to be able to tie the what needs to change to what's coming? Really, having an open channel of communication, both with your teams and your business stakeholders. I feel like that mix always keeps them moving things forward.

Shane Hastie: Really interesting stuff. A large proportion of our audience are technical folks who are moving into leadership often for the first time. What advice would you give that person?

Advice for new leaders [20:10]

Shobana Radhakrishnan: This is actually a very exciting time for someone who's thinking about moving into a leadership or management role. I think the first step is to think about, do you want to actually manage and lead or do you want to lead? That is a question I've noticed that needs to be really asked to know what's your inner passion, inner motivation? Too often people haven't actually thought about that specific question, because managing people comes with a certain set of responsibilities and certain exciting things and leading teams, while continuing to remain an individual contributor because you can lead increasingly complex architectures all the way to fellow level in most large companies.

That's also a very, very good track, when you think about I want to lead people. Interestingly, both involve mentoring others. You don't have to be a people manager to be a mentor. If you enjoy mentoring and technical things, it's one track. If you actually enjoy the people management side, then you do need to do things like giving feedback, making unpleasant decisions. So, it comes with a mix. The first step I feel is asking that question of what's really my inner drive? What's the fire in me? The second is, what kind of things do you want to influence? If you're thinking about growing in your current organization and your current company, what kinds of things do you enjoy influencing? Or what kinds of things need a change or a pivot or an amplification in your organization?

A lot of times being able to proactively articulate that and bringing it up with your manager or other leaders actually opens doors for opportunities for you that you didn't know existed and they didn't know existed. Just reflecting on what do I want to influence differently? What is the change, big change I want to create? Or what's the big innovation I want to bring into my product, my team? Going into the conversation with those ideas just strengthens your position and readiness as perceived by your managers or leaders.

Also, it makes them feel like, oh, he or she has thought about so many more opportunities that I didn't even think about. It just opens the doors to a lot more paths for you. That's something that I have found to be a very, very good conversation that I see people from my teams also have come into conversation with me with those ideas. Sometimes, they have better ideas for opening the door to opportunity than you do yourself. It's always good to prepare with some thoughts like that.

The third is also being clear about what will be needed to succeed in that expanded role that I'm going to talk about or think about and being self-reflective a little bit first of what are the gaps where I may need coaching, I may need to grow? What are the areas I need my managers or leadership to empower me and make sure that I am set up for success?

Being able to be transparent both with yourself and the person who can empower you to take this broader role so that both of you can work like a team in setting you up for success. I feel like those are the three things I would say.

Shane Hastie: Shobana, thank you very, very much. Some great advice there. Some really interesting points for our audience. If people want to continue the conversation, where would they find you?

Shobana Radhakrishnan: I'm always happy to connect with anyone on any of these topics or the tech industry or media industry in general, or architectures and large scale systems. LinkedIn is a great way to find me and connect with me. I'm always up for a chat, but LinkedIn is probably the best way to get to me.

Shane Hastie: Wonderful. Thank you so much.

Shobana Radhakrishnan: Thank you very much. It was great being part of the conversation.

Mentioned:

• Shobana Radhakrishnan on LinkedIn