Driving product mindset and engineering excellence at scale (with Vinay Ram)

Speaker A: Hi, and welcome to the next edition of Engineering Leadership Excellence podcast by Productboard. Here's Robin Pokorny, senior staff engineer at Productboard. And with me today, I have a very special guest and, um, I would say rather recent addition to Productboard team, and that's Vinay Ram. Hi, Vinay.

Speaker B: Hey, Robin. Great to be here.

Speaker A: Yeah, we finally got you. Uh, Vinay is closing his first half year here at Product Board as vice, uh, president of, uh, engineering. Uh, Vinay, how would you introduce yourself to people?

Speaker B: Uh, I'm, um, Vinay. I grew up in India. Uh, I got my bachelor's in computer science in India. Love technology. Starting early teens, um, built my computer from scrap, scrappy rams here or there and like, you know, built it together. Uh, it came naturally to me. I was not great at studying other subjects, but somehow computer science was just very natural because it was logical. It made sense for me. Uh, you could easily find the flow. Uh, went, got my bachelor's in computer science. Then I went to the US to get my master's, uh, in University of Florida. Uh, Microsoft came and recruited a bunch of people from Florida. It was one of the places that the age used to recruit a lot of college hires. So I got to Microsoft. That moved me to Redmond, right across the country. Uh, and I was in Microsoft, uh, for about eight years. I became a manager at Microsoft, and I'm very thankful for becoming a manager at Microsoft because I learned how to. There were so many trainings and so many guardrails for us. And then I basically took a year off. Me and my wife, we quit our jobs. We took a year off, uh, and we traveled for a year, uh, and then I came back, uh, and joined a startup called DocuSign at that point.

Speaker A: Nice.

Speaker B: It was a small company.

Speaker A: I heard about that.

Speaker B: Yeah, yeah, it was only 30 engineers, and I think now they're like about thousand, 1,500 engineers. Crazy, crazy. Uh, so it was, it was a fun journey. Uh, I learned a lot there. Grew, uh, the team there from almost like I had two engineers when I started to about 50 engineers. Uh, and it was a wild ride. Uh, it was very fun. We saw the company grow, uh, customers grow with us. So it was definitely a fun ride. And then I continued my spirit of taking breaks after working, uh, because I like to work hard and play hard. Uh, so I took a year off again. We traveled a little bit. I dabbled on building a company for myself. I started a company for consulting and I was consulting and I was helping early stage startups build their engineering teams. And, uh, then I worked with a CTO, previous CTO of mine at SurveyMonkey, for improving the developer experience. Uh, and then I took a year or so off. Uh, and then we actually built a cabin up in the mountains.

Speaker A: Nice. Yeah, we heard about that. I saw the pictures of this beautiful cabin.

Speaker B: Yeah, it was blood, sweat, and tears. Like, we actually physically built the cabin. So we spent about a year and a half building the cabin. Uh, it's still in construction, some parts of it, but, uh, we're having fun.

Speaker A: I want to ask about this later, but, like, uh, when we are there, uh, you know, what's the biggest difference? When you have this physical build where you can see how things, you know, change, improve. Like, you know, the elements, how it's. Like how it's together, and you compare it to software engineering, where you don't have that.

Speaker B: Actually, it's funny that you ask because of the, of the. Of the difference. I find there are actually a lot of similarities.

Speaker A: Okay, okay.

Speaker B: And for me, it's like, it's. It's. So when I first bought the property, it was just barren land. So it's like Greenfield. You have nothing. Right. Then you put some infrastructure and you put that, you put a well in, you put the septic in. You got to get the things ready for building what you have to build, and then you build a foundation, you build a platform, and then you build a house on top of it. So I see that it's similar when you don't have everything when you start, but then you start putting pieces together and then you see your dream or your vision come true. And I think there's a parallel to that on software also. You can't have everything all of a sudden, even in software, you have to improve it slowly. It's the same thing. We actually moved into our house, uh, six months ago, but it was still work in progress. So we can actually ship software to customers, which can be work in progress.

Speaker A: That's actually true. Yeah. Uh, that's a good farall. I see it. I always thought this is different because with buildings, I always thought you have to have much more planning.

Speaker B: You do have a lot more planning. Yes, for sure. We have to get the. The permits and et cetera, et cetera. So there is a little bit of planning aspect, but you do get curve balls, just like how you get in software. You have bugs as you're producing things. You have to redo some of the things. So I mean, we had to go through all of those. Right. And I kid about this is as we were building. So we started off building our cabin as a uh, 30 meter square cabin.

Speaker A: Okay. And it's a tiny cabin.

Speaker B: It's a tiny cabin. That's uh, basically what we started off.

Speaker A: Okay.

Speaker B: But then scope creep happen. It is more than 170 meters. So just as software sometimes even building scope creep happens and then you have to adjust.

Speaker A: Yes.

Speaker B: Wow.

Speaker A: Okay. I don't know about that. Cool, cool. Uh, I wanted to ask about your management, uh, style. You said that you became manager at Microsoft, so you were Microsoft manager. Hopefully not micromanager. No, we don't know. Could you maybe talk about what do you, you know, you were helping grow teams, right? Like what's your, what's your style? If you had a readme about for you as a manager, the way that

Speaker B: I look at, at, at management is uh, you got to be an enabler. That's basically you have to build a team that you trust that you can actually build and grow. And your job as a manager is to, is to show the business the value that the team is bringing for the business and show how actually things can get done and trust the team to deliver. And if the team is not delivering, then show the team on where they can actually fix things to actually deliver. So my management style is usually hire great people. They'll build awesome things for you. Right. Like so things that you can, uh. So my, my whole goal is always to hire people who are better than me. Yeah, that's basically my goal.

Speaker A: Yeah. Okay. Which can get tricky I guess at one point, right?

Speaker B: Uh, maybe, maybe. But yeah, yeah, I mean I don't think it gets too tricky because like as you hire smart people, uh, they actually are self organizing. And I see that at product board as well. Like, I mean a lot of the teams are actually self organizing, which is lovely for me, that they can actually produce results by themselves.

Speaker A: How do you build trust? How do you kind of create this environment of trust?

Speaker B: It is, it's a very good question because I think every place that you go to it's because the environments are different. Right. Like so, uh, it's always harder as a manager to go in and build trust because you have to actually make decisions. People need to buy into those decisions and you have to have the trust. So uh, I always recommend new managers to always be managers in the team that they have been part of because it actually makes it easier because you actually are a good engineer. So the trust is already systematically built around you. And when you become a new manager, it's Easier for you to manage a team. Whereas if you go to a new company and become a new manager, you have to build that trust, and it's a harder problem to have. But the way that I look at it is as a manager, you have to make decisions. As I come into a new place, I have to make decisions. But I try my best to understand the picture first before I make any big decisions. So, uh, I'm observing for the first two, three months, and then I start making decisions. And the way that I build trust is If I get 80% or more decisions, right, I'm in the right track. If I'm not making 80% or more, then I'm on the wrong track and I need more feedback and I need to course correct. Personally, I'm very open to feedback. When people tell me that things are going in the right way or wrong way, then I get the signals and I can course correct. The thing I like about Productboard in particular in Czechia is people are very honest. It's one of the reasons that I actually took the job is when I was interviewing, people were actually giving me honest feedback about what's broken, what's working, what's not working. So it actually, because I'm honest as well, it actually makes it easy for me to actually function and get that feedback. So, uh, it's been great.

Speaker A: That's interesting. Uh, I see what you mean. I think it's fair to mention now that you moved to Czechia for this job, right?

Speaker B: I did.

Speaker A: So, I mean, your cabin is in Washington. Uh, state. Washington. And you moved to Prague. Can you tell us more about that? Like how that move?

Speaker B: Yeah, for sure, for sure. So it's kind of related to that trust part that you were talking about. Like, most of the engineering team on product board is in Prague and in Czechia around. Uh, and I think for me to be successful, I need to be able to build that trust quick. And that's one of the reasons I feel like the closer I am to the engineers, the more I can actually understand the product and the more I've been able to understand the product. Uh, I don't think I would have been as successful in getting onboarded if I was in San Francisco or my cabin. Uh, just getting the personal touch, just being able to smile with you and talk with you here is, I think, priceless. Uh, whiteboarding with engineers, with staff, Uh, I think, yeah. So just having one on ones with them, talking to them face to face and understanding them more and also understanding the culture more. Right. Like, it's to getting to know the culture on why people do what, uh, is also important. And I know there's definitely differences between San Francisco, Seattle, Paris, Czechia.

Speaker A: I would like to know more, like when you compare this, like, do a general vibe that's in San Francisco, like the core of, let's uh, say modern engineering, and Prague here, for example, what did you observe?

Speaker B: So in San Francisco we have about like 10 to 12 engineers and like we have about 60 engineers here. So there's definitely, it's a team that's forming there, whereas Prague is an established team. Uh, so I think there's definitely differences in that. Um, but also in the mental model of how the Silicon Valley works versus how uh, Europe works. I think it's like Silicon Valley is more of the mindset of we can go fast, try and break stuff and we'll fix it quickly. And the mindset here is we like to build good software, make sure that it's working well, and then we'll be proud about shipping it. Right? So there's an aspect of that which is very important, especially in the enterprise software. Whereas the quick iteration and trying to try new things is very valuable. When you're starting a new company or you're getting into a space like AI, where you actually have to quickly iterate, quickly, think about new use cases, try it, fail, rip it out, build again. So there's a push and pull on that part. And I think it's healthy for certain use cases and certain places. And I'm not saying that there's people in Prague who like doing that as well. Like, you know, who are like loving that the new AI build, the zero to one engineers. I mean this company was basically built in Prague. We have those engineers who are still here. We have like people like Zuse, who's been here for 10 years, Scovi. Eight, nine years. There are a lot of people who have been here for a long time and they have that in their DNA. So like it exists here. But I think overall as a mindset, I think that there is an aspect of caution which is important. And uh, I think we just need to be able to extract the right value from the right place.

Speaker A: Maybe connected to this is the fact that Productboard is a product company and we really value. We uh, talk about it and we even have conferences about how to do, uh, product management. And we recently took it once a third. And now everybody in engineering has the words product in their title. So, uh, my title is like Senior Staff Product Engineer. And you are VP of Product Engineering.

Speaker B: Yeah. I thought of correcting you when you started off. I was like, this context is important. Yes. So we've made that change recently to call our engineers product engineers, our product managers, product managers, our designers, product designers, our marketing, product marketing. Uh, and the reason is because I think we want to be close to our customers. So, like, we want engineers not just to build software, but to build solutions for our customers, to understand our customers, to understand the business, to understand the value that we as engineers are providing. Because it's easy for us to just build what someone tells us, just ship it and not worry about it. But I think for us now to actually take ownership of the start to the finish, to delivery, and to see the return on investment on the features that we're building. Like if you can put your hat on a feature and say that generated $1 million revenue for the company, that is such a more fulfilling value add for individuals, for people, than saying, I shipped 10 features and you don't know what happened to it. So I think that's basically where the difference I see as a product engineer and a, uh, software engineer.

Speaker A: For example, we had a talk about this with cloudoo a few episodes back, also talk about product engineering. But, uh, it is like right now we really took it, uh, to the heart and we changed everybody's titles.

Speaker B: Yes. Which is awesome.

Speaker A: I mean, it's both. I think that's what you need to kind of remind it to people all the time. Uh, and we are like, uh, also changing other things. Right. We have this framework, we call it Product Excellence.

Speaker B: Exactly. We want to build products that we're proud of that solves actual customer use cases. And we're actually changing our methodologies on how we actually deliver that product for our customers. And we want to be the poster child on how products should be built.

Speaker A: Yeah, exactly. Do you expect some resistance to this? And maybe how can one kind of explain this to people? Because I think it's something that I believe has to click in a way.

Speaker B: Yes, yes, 100%. So I think change is always hard. That's where leadership is important, like to manage things through change. Not just in a company, not just in engineering, in life, in countries, in your own society as well. Like, as things change, you need to have good leaders who can actually manage the change for the community that they serve. And in this part, like, we have to actually manage the change that actually makes sense. Be able to communicate why this product excellence is important for us and for our customers, which is also, again, coming back to the customer value that we are adding, uh, that's why we're here. We are here to add value for our customers. And that's the key part. Uh, and I believe that our model and how we actually embody product excellence will show that it actually is impacting how we actually deliver things for customers. And I think it will. Click.

Speaker A: This brings me to topic of engineering culture and how do you, like, steer it? Let's say. So are there some things that worked for you? And, uh, for sure, yeah.

Speaker B: Yeah. I mean, it comes back to this. Product Excellence, Part 2. We need to be actually thinking about as an engineering, not just solving the problem for the customer, but also as engineers. We have this responsibility to build something that lasts for a long time. So we need to build up the right platform, we need to pick up the right architectural North Star to actually drive our whole systems towards this North Star architecture so that when you're actually building new features, new value add for customers, it becomes easier for us to do it. So it's also important for us to keep track of what our velocity is on, how fast we can build things for our customers, what are the things that are blocking us from going faster, uh, to add that value and start removing those obstacles. Uh, so for me, for the engineering culture is we need to have that voice that we can actually tell the business that why something is important and why we have to build this, and we need to add value while we build that.

Speaker A: I remember reading Marty Kagan's book and he talks about that engineers can be a great source for product improvements. You know, they're close. They can see these, like, long hail hanging fruit that maybe you miss as a product manager. So what you say really resonates with this idea that engineers shouldn't be waiting to be told what to do, but they should actively seek what is possible to move the company. But they need to know what the company wants to achieve. Right? They need to know.

Speaker B: They need to understand the business 100%. They need to understand the customer, and then they need to understand the systems that they're working on and see what they can actually deliver. So I think you touched this point, but I just want to put a plug in here. We're actually having a hackathon, uh, in two months. And that's basically the whole reason. Understand the business, see what's available, see what we can actually hack together in a week and show the value to the business as engineers. Hey, we can build these things and we can build them quick. I'm very excited about that and I'm Hoping we'll actually get some creative ideas, uh, that drives the business forward.

Speaker A: Yeah, uh, that's always fun. So I'm looking forward to that. Uh, we also have guilds here. Right. Which I think are also a great enabler of this, let's say knowledge sharing maybe or like alignment between the horizontal alignment. Right. You've been here for a few months. How do you feel about the guilds?

Speaker B: Yes. So this is the first time I'm actually running a team that actually has guilds and I'm very happy that it exists because the first time I came here I was like, that's amazing because in the past what I would do is, is save certain member team members time to do these work. Right. Like, it's basically like I would have to work with product managers saying like, hey, I'm just going to like save some time. And it was not formalized like how it's actually formalized here. Here. I think it's a great opportunity for engineers to show the value that they can bring across the whole organization, which happens in the guild. Like we have an architectural guild, a front end guild, a kotlin guild, a hiring guild. It's not just technology. It's actually the architecture of the hiring part is actually we're trying to improve the organization in multiple ways. So I think uh, it's a great way for us to actually make a difference to your own society. I feel like it's a community that we have here of engineers and how do you actually make their lives better? And that's basically how I see the guilds actually operating with their expertise. They're basically making the community better.

Speaker A: I remember when I was reading about agile back in the days and then I saw some of the um, realities. I was always puzzled how to kind of combine this agility when you move fast, but then you want to plan on a bigger scale. And we see that with enterprise customers you want some kind of predictability and you want to, I don't want to say promise, but like at least show what you're working on and they kind of count on that. Right. And my question is, how do you balance this? Like, how do you stay somehow flexible, nimble?

Speaker B: It's a very, it's a very good um, thought process. Because I mean the way that I look at it is there's a set of customers who want to go fast and there's a set of customers who want to play with the latest and greatest and they want to actually experiment that like, hey, you got capacity planning, throw it over me. I want to try it. Right. Like, so I think we need to be able to enable those customers. And then we have these large enterprises who have documentations on top of product board saying click here, click here and do this. Right. We're actually embedded in their workflows intensely so. And they don't want too much of changes. Right. So I think there's a way to actually satisfy both of them. Uh, so the thing that I like about productboard is like we actually ship whenever we check when we merge into Master. It just has a CI CD pipeline that just goes into production, which is awesome. Companies dream about getting there. And I was so happy to come here and like, hey, here you go, you have it. Ah. And then we have LaunchDarkly, which actually we can actually use that.

Speaker A: Yeah, there's a feature Flex service feature Flag Surface.

Speaker B: Exactly. So to actually control what gets shipped to where, right. So we can actually use that LaunchDarkly feature flag system to actually give the greatest and latest to some of our customers who want to play with it and control like, hey, we can give it to them monthly or every other week. We can actually give some features to enterprise customers and then you can actually control the cadence. But then we also get feedback from the customers who want to play with early and then like we can actually incorporate that feedback for the enterprise Maybe

Speaker A: one thing that surprised me about probably Board in this regard is that we kind of have feature flags inside feature flags. What I mean by that is that as you said, like, some companies really don't want to move. But even as you develop a feature, we are able to kind of just show it to a really small number of individuals. Right. So you, you have a bigger initiative, you work on it, you want to enable it for some of the people. But even inside that, the cutting edge is still in the production, uh, under different feature flag. And you can have a very valuable conversations with real customers who can maybe try just, you know, maybe you enable it just for a day, you know, so you play with it. But they, they, they can see that, they can touch that and they can provide the feedback, which is, I think,

Speaker B: uh, you know, maybe it's super valuable. And we actually turn it on, on our space and product board earlier so that the whole company gets to play with it. So we actually get like validation that the actual feature is working before our customers even see it. So which is pretty awesome.

Speaker A: And we do proper duck footing. So we use whiteboard and we use all the, like, most of the cutting edge, uh, feature flags which can Be sometimes, you know, interesting. But uh, yeah, you get a feedback.

Speaker B: Exactly.

Speaker A: Let's talk about a, uh, question that was about build versus buy decisions and in general what uh, you think about that and then we can talk about what we did at ah, Proctor because we recently also made some decisions in this regard.

Speaker B: Yeah, yeah, for sure. Sure, sure. I mean my philosophy is if it's not the core competency of the company, if it's not the core IP of the company, and there's a company that actually is a core competency and core ip, we should look at doing that. Uh, that's my general philosophy. Right. And uh, I think that way we can actually focus our product engineers on customer problems that our product, our customers are facing versus building something that already exists in the market that we can just reuse. And like a very good example is authentication. We actually used a company that was up and coming also. It was like we took a bet on this company and they're doing really well now. Ah. And it saved us from building our own system. It was easy to integrate. Uh, they're available in all regions so they're solving the problem rather than us trying to solve the problem. And the other example was like we're using noc, which is a notification service. Instead of building our own, we're just using a service and we're just bringing the service provider in and just having uh, a layer for us to interact with.

Speaker A: I feel that also private board, uh, has advantage. We did build the first versions ourselves. Let's be honest. The company is 10 years old, so the very first versions will be like, oh yeah, we can do notifications, we can do um, uh, permissions and all of that. And I think that this experience also shows you how complex things can get and pretty fast.

Speaker B: Correct, correct. And the thing I like about building these interfaces and then actually having a third party buying it versus building it is like sometimes things get better. They're actually making it better. So you get these features for free and you can actually integrate those parts into the system too. Or sometimes you can also do multi company as well.

Speaker A: Have you done that?

Speaker B: Yeah. Like for the past, for Slack Notification, you could use knock services. But like for emails which are a lot more, you can actually use AWS services, which is much cheaper. So you can actually just fork those and use whichever one makes sense, uh, for the team and the company. Right. Interesting.

Speaker A: Yeah, yeah, you can.

Speaker B: So, so it's interesting model. I love it.

Speaker A: Yeah. But then you still have some things you want to build even they are kind of not the core in the world, ddd. You have the supporting domains as well, right? Which you want to maybe have some control or maybe you think it's easier. Do you think it's okay to start trying to build it yourself? And only when you discover, okay, that's much more than we expected.

Speaker B: So bringing it back to the kind of culture that I want to build, I want to actually build an organization where we actually prototype stuff. Right? We're trying to figure out a workflow engine, right. We can try building a workflow engine with an open source code as a prototype. We can actually go buy or prototype with the companies and try out. And the best part about prototyping is like you find out the pros and cons earlier before you actually ship and you're committed to it. So that actually gives you the experimentation earlier on without having to commit. Uh, so yes, it is possible. Sometimes it's easier to build, uh, especially if you have custom requests and custom requirements.

Speaker A: When you said that, I immediately had this idea. What we want to do in our architecture is that you want to have these blocks, you want to create a boundary and then you can swap them. Um, but you need to make sure that these are not too intertwined with the rest because then that would be useful.

Speaker B: So I mean, I want us to get to that North Star architecture where those are building blocks. So we have multiple building blocks. And like I said about the notification service, you could actually have multiple blocks in the same block itself.

Speaker A: Yeah, it's great. It's a blockception. That's how it works. Yeah. Okay. Okay. When we were talking about these build versus buy now we also have AI, right? And there's this general feeling that you might be able to build things faster and more tailored to your needs. Uh, what are your thoughts? We all heard about the example of Clarna doing some of that and replacing some of the software with, uh, their own version. How do you feel about this trend?

Speaker B: So I go back to the example of us having our own data centers. Like 10 years ago, everyone had their own data centers. And then cloud computing came on. Most people were like, eh, ah, we're not going to move to the cloud. Our customer data is too important. We don't have the security. There was all these, uh, parts. But now moving forward 10 years, I don't think any company is going to be building a data center from scratch anymore. Right. We have a team of five infra engineers. You can't imagine building a company of this scale with infra engineers. Uh, ten years ago, but does that mean infra engineers don't exist? They do exist. They're building the data centers in aws, they're building the data centers in Azure, in Google. Right. And I think it's going to be the same thing with software as well. Uh, we're going to have software, engineers, systems, the AI, ah, things like copilot and cursor are going to enable us to do more in a lesser amount of time. There's going to be certain tasks which they're going to be good at. But I think a lot of the thinkings and a lot of the architecture and a lot of the plugins are going to be very much human focused. But I think it's going to be a productivity booster for sure.

Speaker A: You know you had your breaks, right? We talked about at the beginning

Speaker B: what

Speaker A: it's like to have a, I don't know, several months break between jobs.

Speaker B: Yeah, I think, um, personally I think it's one of the best things that I've done in my life is take breaks between jobs. And the reason is because I've planned my life in a way that I can actually take those breaks. And the great part about it is I can give enough time for the team that I'm leaving to ramp up a new leader to set up the team for success before I head out for my break. And the other part on the other end is even coming into product board now I'm super fresh, I have a lot of ideas, I've had time to contemplate what's next and be able to come in with high energy, uh, is very valuable. And I think we are in this industry where burnout is real. Right. Like, I mean when you get into the problems day in, day out, it is very real. And it actually helps me to have the cut off and not have to think about like another job where I'm thinking about other problems. Uh, so it's been very refreshing.

Speaker A: How many months before you stop thinking about, uh, work?

Speaker B: That's a good question. I think it's changed over different, different breaks that I took because the first break I took we were traveling for a year. So you were like, I was on the go. So there was like so many different new things. So it took me eight to nine months to get bored to get back.

Speaker A: Oh, wow. Okay.

Speaker B: Uh, and then, uh, the next break I started, I started building something in three or four months myself. And then this break, we were just building the house. So it was, I see 15 hour work, physical work, building a house. Uh, once I start building the house. I found a job.

Speaker A: Oh, I see. Okay. I see. Because, you know, my naive, uh, idea is that you would have, you know, you have time, you would be able to read and work on the side projects. But, um, I also spoke with some people who did this, and that's not usually how you do that. Right? It doesn't go like that.

Speaker B: Yeah, it's, uh, surprisingly, your time gets filled up really fast when you actually have time, uh, because there's so many things that you've been waiting to do that you haven't done that when you find the time, you just, uh.

Speaker A: Then I have, like, last question about this topic, I guess, is how do you know that it's time for a break? Like, when would you recommend it? Like, you know, I guess you shouldn't take it after your first internship. So when do you feel be like, a good time to get this break?

Speaker B: Uh, yeah, I think first internship might be hard. And I think also, like, I mean, between your first job and the next job might be hard as well.

Speaker A: Yeah.

Speaker B: Uh, I think you need to have enough jobs that you've moved that you feel confident that you're good at your job and you're actually going to get a job as well next. So you have to build that confidence first because that makes it much easier to take the job, take the break. And the other part, I would say is if you've actually been working too hard, pushing yourself too much at a workplace, at least take a month break before you join the other.

Speaker A: Oh, I see.

Speaker B: Interesting. Like, it's easy for you to negotiate a month.

Speaker A: I see.

Speaker B: To join and then, uh, like, take the break, come back fresh. You're doing yourself a service. You're doing the next company that you're joining a service as well by coming fresh and not burnt down.

Speaker A: Yes, yes, that's a good point. That's actually a good point. Uh, my next question is actually about growth, uh, opportunities. I think even inside the one job, you can still grow, you know.

Speaker B: Of course, of course. Of course.

Speaker A: You talked about Microsoft and how you grew there. Can you maybe share more about it? Like how it went?

Speaker B: Yeah, yeah. So at Microsoft, it was an annual review process like most other companies, and we have that here as well. They had a specific career ladder, which we also have here as well, which is. Which actually defines what you need to do at each level to get to the next level. And it was almost like a game for me. Uh, when I actually saw the career ladder, I was like, okay, I need to do that to get there. Okay. I'll go do it, and you start doing the things that are there in the next career ladder for me to actually do them well. So I started learning more about what's there in the next career ladder. And I got promoted pretty fast at Microsoft, um, by just like, almost gamifying it. Right. Like, it's like, actually I'd go talk with mentors, I'd talk with people who have been promoted. Right. Like, and what they did, how they went about it, and learn from them, and then just go do it. So I was very eager to advance my career. Uh, and that's how I got to where I got at Microsoft fast. And, uh, I really enjoyed that part. And then when I joined DocuSign, I didn't have to chase the promotions.

Speaker A: Uh-huh.

Speaker B: Because the company was growing so fast.

Speaker A: Oh, I see. Yeah, yeah, right.

Speaker B: And there were like, so many. There weren't too many people there. So it was like whatever I wanted to do, I could just do it. Like, I just had to make things better, and I was making things better. So as I made things better, I got more things to do better and I could just pick and choose and like, that just automatically got my career going further. So I think, uh, uh, in an established company, you need to figure out what's the things to make you grow. But in a startup, and even like in product board, we have problems that need to be solved. If you pick it up and run with it, you'll get more problems to solve. You'll get more interesting problems to solve. So, like, the opportunities exist. And I think that's the important part of a good, healthy organization is when you actually see people grow.

Speaker A: In this podcast, we often talk about staff plus engineering. How do you see this relationship with, uh, manager and their staff, uh, engineers, Maybe also on this other VP level or director level, whatever. How do you evaluate this step by step?

Speaker B: For me, the main part of the engineering organization is not the VP of engineering. It's not the management chain. It's actually the staff. And staff plus Engineers is basically the core of the engineering organization for me. We are here to enable the engineering. Org. The way that I look at it, the way I look at my role is I'm an evangelist for all the engineers that are there in my organization. So I need to be able to be the voice on what they're actually doing to be able to amplify the voice. Uh, and for me, the reality check comes from staff engineers and staff plus engineers. It's one thing to dream up a beautiful system. It's another thing to actually build that. And actually that's where when the rubber hits the road, that's where the senior staff, staff engineers actually are going to call your bullshit. Or like, hey, is this possible? Is this not possible? Why is it not possible? What needs to be done to make it possible? And then if that's what the business needs, then it's our job to unblock those roadblocks that exist by funding it right? By making it right. To enable it. So for me, the voice of engineering is from the senior engineers that exist in the company. Wow.

Speaker A: Okay, that sounds great. Um, and then the same question asked every manager, stepping into management, big step was this for you? And maybe as a related question, was it what you imagined it will be? Did you have enough information when you step into role, what it means?

Speaker B: Yes. Yes. So that's why I was very lucky at Microsoft. So, uh, we had this internship program at Microsoft and every employee, any senior engineer could get an intern, uh, if they just raised their hands.

Speaker A: Okay.

Speaker B: Right. So they had such a big pool of interns because they'd go to college and hire the smartest and brightest.

Speaker A: Yeah, yeah.

Speaker B: Because they have the name.

Speaker A: Yes.

Speaker B: Right. So all I had to do is like saying, hey, I need an engineer, uh, an intern. And I would get an intern. Right. So I did that for I think three summers.

Speaker A: Okay, nice.

Speaker B: Right. So I did it for three summers. I had interns working, reporting to me. So they basically give you an intern to report to you, and then you have to manage the intern, manage their day to day work, review them, give them feedback, grow them, and your goal is to actually hire them into Microsoft so you have to actually make them an eligible employee.

Speaker A: Wow. Okay, I like that.

Speaker B: Yeah. So I was lucky that, I mean, of my three interns, two of them made it okay and one didn't. So I had the experience of like giving the hard feedback on why they couldn't make it.

Speaker A: Yes.

Speaker B: Or what they needed to do to improve it. So I had the good and the bad of being a manager, uh, with the training wheels on.

Speaker A: I see.

Speaker B: Nice. And then a position opened up in the team that I was in. And this is where I was telling you that like, I had already built the trust that I needed in the organization. And so it was easy for the VP to say, hey, we should tap into Vinay to be, uh, leading the team. And I was able to lead the team and lead the team successfully. Uh, and the way that I left Microsoft, I basically promoted someone in my team to be the manager.

Speaker A: I see. Yeah.

Speaker B: And everyone else got promoted, and we hired the intern to the position, so everyone just moved out.

Speaker A: Yeah, that's great.

Speaker B: And everyone had a growth opportunity to grow by me leaving, so it actually was fulfilling for me to see that as well.

Speaker A: Uh, that's a beautiful thing. Thank you. That's a great, uh, ending for our chat. Thank you again for coming. Uh, thank you.

Speaker B: Amazing. Amazing.

Speaker A: Yeah.

Speaker B: Thank you. This was a wonderful conversation.

Speaker A: Yeah, I enjoyed it, too.

Speaker B: Yeah, I enjoyed it.

Speaker A: And I mean, if you want to enjoy more conversations with Vinay, you know, that's, uh, an easy way.

Speaker B: Just like. And subscribe.

Speaker A: Like and subscribe. Uh, but yeah, like, check, uh, our carrier page. We have several all roles open. Uh, you can hit us up and ask questions and be happy to answer them as well.

Speaker B: Thank you.

Speaker A: Thank you very much.