Raghav Chandra, Urban Company

Welcome to another episode of Breaking Changes. I’m pretty excited today, I have Raghav Chandra from Urban Company with me. Urban Company is Asia’s largest home services platform, and he’s come today to talk to me about their microservices and their approach to building their company over the years. So welcome.

Hey, Kin, thanks for having me.

So I want to learn a little bit more about Urban Company first. What value does Urban Company bring to the community?

So we are your platform for local services. These would mean services such as plumbers, electricians, beauticians, fitness trainers, all brought into the houses of the consumers through a simple touch of a button. We’ve been a six-year-old company, we’ve been operating across different countries, and it’s a fairly deep, full-stack marketplace.

What countries are you operating in?

So outside India, we’ve been in UAE for a few years, Australia, Singapore, and Saudi Arabia.

Nice. So what does expansion look like for you? Is it just further strengthening those countries, or are you going to keep growing to other regions?

I think the space we’re operating in is a fairly global problem. While at inception we were mostly attracted by the depth of the India problem statement, in a few years of execution we realized that consumer households across the globe struggle with just maintaining their homes and maintaining their personal lives, and as we experimented through a few countries we realized that while solutions might be a little different, the root problem is very similar, which is all households, all consumers struggle with having a decent way of managing their households. So I think it’s been for us an experiment, and we’ll probably keep adding more cities and countries as we grow. The journey is very long, I think it’s still on day one.

Makes sense. Why do APIs and microservices matter to all this?

APIs and microservices, if I can be a little meta, I think the thought of APIs and microservices is not just about doing APIs and microservices, it’s about structuring. For any company, it doesn’t even have to be a tech company, how internally the teams get structured, how the company is structured, is what dictates how quickly a company can scale, how quickly a company can knit. And I think APIs and microservices, the debate at the heart of this, whenever you discuss this with anyone, it all comes back to how are you splitting things. Microservices, it’s all about boundaries, where you want to draw those boundaries out. I think that’s why I really love this whole debate on APIs and microservices: how do you really decide what is ownership, how do you decide what’s the right boundary for a team, for a piece of code, for a company.

Before we dive into that, because I want to unpack that a little bit more, I’d like to get to know you just a little bit better. What brought you to Urban Company, why start a business like this?

So I’ve been an engineer in my past. I went to Berkeley in the Bay Area, I did my software engineering there, worked at a couple of very interesting places. I was at Yelp as an intern, I was at Twitter around their IPO days. I think I got a lot of my engineering grooming from those days. But what really motivated me after a certain point was solving some tough problems, and for me tough problems were problems that regular people would be facing in daily life. That’s when I decided to pack my bags, come back to India. It didn’t matter if it was mine or someone else’s, but what I didn’t realize after moving back was, things which are broken, you just have to throw a rock to figure out another big space, a whole closet of problems. And I think this is my second startup-building journey, so I was 23 when I moved back, I started Urban Company, and then there was another startup before that which got started then. I think it just so happens that what we’re doing here happens to be one of the top problem spaces that I feel very passionate about. And if I can just list them, it’s unemployment, healthcare, and education, and Urban Company is all about employment, figuring out new ways for gig economy workers to be right. Broadly, that’s what prepared me to start what we’re doing here. There’s a consumer story to this as well, but there’s also this partner story, which is, can we figure out a new way to create employment, not in the traditional sense, but maybe there’s a better way to employ the masses of skilled professionals and so on. That’s what got us started.

Nice. So have you always known you were an entrepreneur, or was there a moment where you were like, this is what I’m going to be doing?

I think for me, problem-following has been key. It’s not mattered beyond a point who’s the boss. Hence my definition of entrepreneurship is a little more generic. I think regardless, you don’t have to start your own company, you could be in any company, but having the spirit of entrepreneurship for me is essential, which is the spirit of identifying problems, obsessing over them. There’s a certain paranoia. I think that’s what I enjoy, that’s what I thrive on.

You use the phrase “backyard scientist” in your bio. What does that mean, how does that fit in?

I think the last year has been a pretty amazing year to discover myself. As a science student, as an engineer, I was schooled in a certain way, but only recently has the fascination of science dawned on me. Through the last year, because of the fact that the pandemic, we spent so much time at home, I found myself enjoying all kinds of projects. I’ll maybe share just one of them. I got super obsessed with this thing called hydroponics, which is how you grow plants using just water, and I, as a science guy, obviously over-engineered things. So for growing four tomato plants, I had a whole automated system running with a timer and an automated mixture. So I think that’s what classifies me as a backyard scientist, and that translates well into the startup and trying to solve problems and iterate and provide solutions over time.

Well, back to the microservices conversation. So you said microservices are all about boundaries. What does microservice mean to you, what is your definition of what a microservice is?

I would actually start by saying that it’s very hard to come up with a common definition. Everyone has various ways, and the easiest way I think of it, I’ll actually use a softer term, I would use “modules” as a way to establish what I’m trying to say. I think modules is very important, when you try to split those boundaries, and there are different layers. Your code could be separated by certain boundaries, right, separation of code itself could perhaps be one version of microservices. Along with code you can add infrastructure separation also to this. So if there’s a certain module and it also has its own hosting, its own database, its own data tables owned by that service, that could be a definition of microservices, where your deployment also starts to change. And I would say it can go as far as even teams. If you imagine a company as strictly microservices, your code, your infra, your teams are all aligned in the same box. Your team members are also the boundaries of separation, are very similar. That could be microservices operating at a company level. I personally like that definition, the last one. It’s not very technical, but there is a reason why it’s important for companies, and for me it comes from, teams and companies should be viewed as capabilities, and capabilities are formed by people, by code, and the tech stack below it, and I think all of them align and form the perfect microservice.

Makes sense. So one dominant API pattern that has influenced the microservices movement is REST, a resource-oriented way of approaching the design of your APIs. Do your APIs follow RESTful patterns?

Have they grown for micro? RESTful patterns, I think it’s been six-plus years for us, when we decided to move on to microservices, we, like any company, we were a big fat monolith with all the goods and bads of it. Before we moved into our first microservice, we actually created a microservices platform, and we decided to go with RPC, remote procedural calls, which kind of removed the requirement for being RESTful. And I think fundamentally why that made sense was, I at least personally feel REST belongs to the web 1.0 era, where these nominal expressions of what’s POST, what’s PUT, what’s PATCH, DELETE, and all of this, a very typical CRUD, mattered a lot. But in today’s world, I think these interfaces, the clients have become so complex, that there is one area that can’t be classified purely as a GET or a create or a POST and so on. So that normally just lost its meaning beyond a point. So for us, inside our RPC we still use HTTP, and we actually use POST calls, but the name comes from elsewhere.

So within all of that, if you’ve embraced the full microservices approach, one pattern that’s emerging out of groups doing it at the scale you are is what’s considered event-driven. So I would say what you said about REST, you outgrow REST pretty quick, I think a lot of folks have hit the limits of what REST is capable of. You did that early on. But another kind of limit folks get with it is they need to respond to events that are happening across the infrastructure, not just make procedure calls or make requests to resources. So have you embraced the event-driven approach?

Yeah, absolutely. As you rightly put it, there’s a very typical journey of any company, whatever stack you start. If you look at the way your code communicates, it starts off with code communicating using just functions within a single repository. Then it evolves, because complication comes and you want microservices, your teams get better, it evolves into network calls. But very soon even network calls become very hard, so you need another way to communicate, which is through publishing. Because fundamentally, the simplest microservices are still based on full requests. You’re requesting someone for information, and then they’ll send it back. Events flip that model: I’m just going to publish, and whoever’s interested in what I’m sending can listen in and get that information. And I think that becomes important when there’s a certain size and scale, when teams become large enough, when services become complex enough. I don’t want, and there are a lot of dependencies on a single service, if you don’t use async events your service then has to integrate every single dependency into itself because they want information, and I have to push that. We absolutely use microservices along with events, or asynchronous.

So how does this translate to the customer, the end-user experience?

I think events become very important when you are doing a lot of real-time processing in your company. So if, based on a certain behavior on the app, I want to quickly get back to a consumer and recommend something else, the only way to do that is, as consumers are doing actions, you use events to index, process, figure out, is that event useful or not, and then you use that to push it back to the consumer. Technically, when you send your SMS or push notifications to a consumer, that’s also a push event. The consumer using the app is your traditional way you’re pushing information with them. So this whole asynchronous paradigm translates to consumers as well. But these would be some examples. We do a lot of processing based on events, a lot of our data systems rely on asynchronous events and not the typical microservice procedure calls.

Yeah, no, definitely I can see how events really translate into what’s meaningful to the end users, what’s going to matter to them. So there’s a lot of microservices, a lot of events firing across these different domains or boundaries that you have set up. How do you keep track of all of it, how do you know all the microservices that you have?

Back in Twitter days, I remember we used to have this massive printout of all possible services that are happening. It was a printout, there was no other way to visualize that, and it was a mess. We used to call it the spiderweb. I think that’s a good way to summarize most companies’ struggles. Most companies start off microservices by just allowing teams to do whatever they want, because, hey, microservices, now you’re independent from the rest. The problem there is, very soon you run into this problem of standardization, because you have so many different versions of how microservices could be done, and every team is empowered to choose their own tech stack and figure it out themselves. It’s very hard to drive a certain amount of sophistication into the stack you build internally for yourself. One of those symptoms is, tracking is actually a very hard problem in a distributed world. If there is an error which happens, you want it to be traced across the full length of all the microservices, and that requires everything to be standardized. So what we did, and I think what we are very proud of, and something which has been our learning experience, we actually standardized the stack very early on, and as a result we were able to build in a lot of sophistication, because every single team, every single microservice, has the same systems underneath it, and they’re using the same things, and that allows us to put anything at a platform level directly without even bothering them. So if you want to upgrade our tracking systems, or change our networking protocol, if you want to go away from HTTP to something completely different, you can change the serialization from JSON to protocol buffers, no engineering team gets disrupted. That’s the magic for Urban Company engineering, and that’s allowed us to do a lot of beautiful things on top. And I think one of the most interesting things when it comes to tracking is how we visualize our whole world. So we have a live dashboard that you can go on and click on, and it shows every single microservice and the databases that are running, and how each service calls the other service. So you have the whole dependency graph mapped out live. And we also put rules. So we’ve classified microservices and databases into tiers. You have your core, business, gateway, and there are certain rules where a core can’t be called directly from a gateway, or certain dependencies are bad, cascading and circuit breakers are also very important constructs in microservices. So without getting into jargon, you basically want a lot of rules enforced in your microservices world, and it’s very easy for us because it all gets tracked automatically, and it’s the same system running, so it’s very easy to standardize anything.

Yeah, I would say a lot of folks I talk to have embraced observability, but observability tends to begin with just monitoring and uptime and status of services. But it sounds like observability to you involves traceability, dependencies, and much more.

Yeah, I think anything you could observe, pretty much everything. People expect the bare minimum to be observed, like performance metrics and stuff, but I think there are a lot more interesting things you could do in this whole theme. You can trace, and tracing might be something which engineers would know of, but it’s not just about tracing an API call, we are able to trace business nomenclature as well. So I as a user will have a user ID, and if my API calls are made across different microservices, I don’t need a transaction ID, I can quickly use my user ID and see where all my requests went. And this is very helpful, because when you’re debugging you actually know my user ID, might know my device ID or something, but it’s hard to get a secure transaction ID. I think there’s a lot of depth you could go into by just observing systems much better. We’re able to trace costs at every microservice level. So our hosting environment, our database costs, even our costs for event queue, we use Kafka, and there’s an environment at every service level, which is great, because then it’s very easy to get teams to realize their costing and performance.

Wow, so you’re not just tracing problems, you’re tracing the business and the cost of your operations. Wow, that’s pretty impressive. I haven’t come across too many examples of that when it comes to traceability, but that’s pretty key, because it’s complex like you said, and to be able to understand the business implications, the cost, the scope of what you’re spending, and teams are able to observe that. So that’s a whole other dimension of observability. Wow. We’re probably going to have to have another conversation down the road on that one, because that’s pretty sophisticated, I’m impressed. So how do you communicate across your teams when it comes to observability? Do they all use this dashboard to stay in touch with what’s going on, or are there other ways that they communicate and work together?

It could happen for various reasons, and they could happen at various levels. You can observe your business, now that’s outside the scope of microservices and APIs. Any feature you will basically put metrics on, and that allows you to observe how things are doing. But more at a technical level, you’re observing how interactions between different services happen, that’s one purpose of observing, and you can go one level deeper and look at costing and performance and so on. So for the functional part of engineering, I think how easy or difficult this gets is totally dependent on how much companies have been able to standardize. Given we are standardized, it gives us a few very interesting perks. We have centralized dashboards, so if you want to measure, you do have some centralized dashboard where you just take the microservice name and it will give you pretty much all metrics around it, and if it’s linked to other microservices, you just click on it and you’re looking at another microservice. Similarly, it all logs onto the same environment, and the logs are structured in the same way, so it’s very easy to debug things, because now when you have bugs or queries and you want to deep-dive into system logs, it’s almost like a language, and your log files can talk on. You can communicate with your logs by asking a very specific question, and it won’t break because it’s standard. I can very specifically ask for all logs generated by ABCD user ID, and it will give you a list of, here are the five microservices, this is when the logs are called. I can even look at parameters, so whenever there’s a bug which happens in any service, we actually are able to track, if there is an error in the service we will log the parameters, the API parameters by which it was called, why, because it’s super helpful for an engineer to know under what conditions did my code fail. And engineers don’t have to work towards this, because this is a guarantee for everyone working on our stack, and this will happen by default. I think those are some of the pretty nifty perks of standardizing stacks which you start to juice out.

Yeah, so you mentioned several times, in the context of boundaries in your business, you kind of alluded to, I’d like to dig in more about the structure of your platform. So how did you organize your company and your platform to operate and maximize this and standardize how you deliver microservices?

I’ll talk about it at two levels. I’ll first talk about the more obvious one. Very early on we created a platform team in engineering. So while the rest of the engineering teams are more focused on what you might call product or business-facing problem statements, there is a full vertical in engineering called platform. We started early here, and that’s how we were able to invest very quickly in building some of these. So the secret here is not fully creating a team, the secret here is top-down mandate. I think the top leadership needs to be very passionate about standardizing a few things, because just a team itself is not able to drive some of those. The team gets stuck, they’re not able to actually drive a cross-team initiative. But there’s a platformization which also happens one level above for us, at a business level. So our business, as I’ve talked about, is structured as categories. You have beauty services, you have home services, you have cleaning services, and the natural thought that comes into someone’s mind is, well, then the engineering teams must also be structured the same way, where you have one engineering team focusing on beauty, another focusing on cleaning, another focusing on homes or appliances. But that’s not what we do. So what we’ve done is, while our business is structured by categories, our tech teams are platformized, meaning they have centralized capabilities. So we will have one team which will focus on growth, and this team will build capabilities or features which will power all business units. I think that helps build a certain amount of standardization in our company, and that standardization is what drives high degrees of sophistication. So you’ll see this even in engineering, where your different teams, your growth, supply, marketplace, and then your platform, and because we have one platform team, it’s able to actually cater to all engineering needs, versus every team having their own DevOps, having their own tech stack, which just reduces the speed of any team working. So for platformization, we do it at a business level, we do it at a tech level, they’re all platforms.

Yeah, now you got a few of my other questions there. I was going to dig into what a platform means, but you kind of nailed it for me. So when it comes to standardization, you talked about everyone does RPC, you have common patterns there. What else, can teams choose their own programming languages? You seem to have an opinionated approach to how things should be done. What else do you define at that level?

Actually that’s the word I use when I describe platforms, and it’s a little counterintuitive, because people imagine platforms to be things which are customizable, but inside the company, the way we look at it, when you’re able to gain as a company, we subscribe to the opinionated philosophy. And the reason is, let me actually walk back a little bit. There’s a school, an interesting debate in physics, of speed versus velocity. Speed is you’re just being fast, but velocity is, it’s not just enough to be fast, where you’re heading is also equally important. Now, in my opinion, company building is a very similar battle. You can hustle your way by being very quick, but oftentimes the boldest and most interesting leveraging happens whenever there’s very clear direction. You don’t want to explore every path, you want to go in with a sharp focus. It’s fine to fail as long as there is an opening. I think that’s where the debate for platformization in our tech becomes important. We have consciously preferred having strong opinions for whatever we do, and that will include things like our tech stack. And the reason, first the reason is simple, we want our engineering teams to obsess over customers, their problem statements, so that they can build this futuristic world which will help our company grow. But if an engineer is bottlenecked with, how am I going to do this deployment, how do I scale systems, oh gosh, there’s this new tech stack in the ecosystem, why don’t we use that, then he’s not actually solving core strategic problems, he’s solving pure tech problems which might not matter. So given this philosophy, we introspected very early on and said, you know what, a lot of these things don’t matter, we will have one team which is constantly thinking. We are not opposed to innovation, but by default we are going to have sharp opinions. We will have a sharp play on a tech stack, as long as the tech stack is stable. You don’t want to optimize, there is no perfect tech stack, you have bad tech stacks, but there is no perfect tech stack for you, it’s all about how companies use it. And using that philosophy we basically standardized. So we have a Node.js shop, we use TypeScript for everything. TypeScript is our programming language, in fact our scripts run on TypeScript, our backend deployable code runs on TypeScript, our client code runs on TypeScript. So for an engineer it becomes very easy, we truly can have full-stack engineers, because every part of code is now on a very familiar stack for them. So cutting a long explanation short, we do have a standardized programming language, and because that works for us, it hasn’t given us a struggle, it’s scalable for the foreseeable future, and it’s fine. That’s not the only stack, we have a few other stacks as well, but for our data team, which is a much smaller team, they use Scala, DevOps will use probably a little bit of Python and some system languages, but for the vast majority of teams it’s just one stack, so that they can focus on business.

Well, it sounds like it’s not just opinionated, you’ve done your homework on why you’re opinionated in this way, and it makes sense from an infrastructure standpoint, and you touched on the velocity piece. So what else have you done? Because this is, I would say, one of the main concerns for folks trying to get a handle on microservices: they want to move fast, they want to be able to respond to changes in the markets, they want to grow into new markets. So what other types of investments have you done to enable velocity?

I think if I could teach a man how to fish, the answer is you have to be very close, you have to be very proactive in figuring out what the junior members of your team do. And as a leader, if you are in good touch with how their life is, how productive they are, you’re probably automatically going to figure out how to improve things for the better. One thing I see in a lot of companies is, as you become senior in engineering, become a manager, you’re outsourcing every part to junior members, and you do stunts with reality. The problem is, hence you’re not able to come in with the right opinion, the right changes. The reason why a lot of companies don’t have such a sharp opinion on services and stuff is because, again, leaders are not as involved at the ground levels. I think this is one process which will fix it. But more tactically speaking, something which worked for us, one was standardizing a microservices stack, and I think it started with standardizing the programming language stack itself, because we realized it’s a waste of time. Our choice works well, so let’s not care about optimizing, let’s not be too cute, you know, can you go live? Those stacks also have their own problems, so it’s not like those teams away. Then we built on top of that. We realized the most popular choice of scripts, and every engineer’s nightmare is, whenever you have issues, especially in early days, you love to run scripts which will do massive data migrations. The trouble is, I’ve written my code in Node.js or JavaScript or whatever, now I have to migrate databases and rewrite some parts of my validation where I write my scripts, and most times it’s Python. So for most companies, your scripting stack is Python and your regular microservices stack is whatever language you’re choosing. And that’s why scripting becomes like that dirty secret, the dirty laundry which no company or no engineer wants to share, because you actually don’t care about anything, you don’t test those, they will have errors, no one cares about them, but it’s a concern for a lot of things. So what we did was, because the primary stack of JavaScript is actually conducive, it’s a lightweight thing, it’s similar to Python in terms of ease, we migrated our scripting stack also to our primary stack. And the reason was we did it in a way, not just, I think the beauty is not that people can use JavaScript, that’s okay, you can use Python, although that was the reason, the beauty is scripts and services now can share code. So if I’m writing a script, I can literally pull a function from my regular microservice which I’ve written, and it works, so I don’t have to rewrite the validation, I don’t have to rewrite the translations and so on. So that was a hack which we pulled out which was very helpful. I think some of the more recent things which we are doing, not per se related to microservices, when you look at client engineering, your app world, your web world, we often don’t look at those ecosystems and say microservices, because microservices are for backend, but the same problems exist over there as well. Code is not well separated in those ecosystems, there are also monoliths. So the equivalent of microservices in the front-end world is something which we are working on today. I can’t prescribe that, because we haven’t cracked that problem, but we are attempting at standardizing the stack on React Native, so that we don’t have Android, iOS, web, we have just one consolidated stack, and we’re platformizing that, so that there’s a way to even structure your code, so that engineers know how to structure things, and some of those design patterns get solved by just giving a guideline on how basic code needs to be written. So those have been some of the hacks which we’ve been able to pull through.

I like it, opinionated all from the front end all the way to the back end and back again. I like that. So as I was working through your site and reading blog posts and a lot of what you posted, you have a phrase that you use called 10x engineering. What does that mean?

I think it’s a rhetoric, but it’s very popular. It’s been used time and again by generations to describe how there are certain teams or certain engineers who are out of the norm. I think it started back in the day when genuinely you could have certain languages be much better, but I think in today’s context, 10x engineering has become a phrase we use to signify really high-output engineering teams versus an averagely good engineering team. And 10x for me is the impact. Are there some teams which are able to create compounding impact, so that when you look back, you’re able to say, hey, we actually pulled in levels, and today they are able to do 10x better. So for me, 10x engineering is all about how certain engineering teams are able to make more impact.

Yeah, but as you said, I think you have to think of all of that and the junior developers. It was interesting to hear you say that your velocity is really rooted in how fast your junior developer is, not just tech velocity, it’s people velocity, it’s organizational velocity. So I think you have a really healthy view of the landscape on what the business impact of all of that’s going to be, not just the highest-performing teams but the actual junior levels. So moving beyond the tech of this, where’s your passion, what drives your passion behind doing Urban Company every day, what keeps you going? Is it just the startup hunt, what is it that drives you?

It’s the multitude of problems which keep me occupied. I spend most of my time, of course as a founder you’re looking at general business, but most of my time goes to engineering, product, design, data, and not just me, anyone at Urban Company, what excites us is just so many problems we get to solve. That’s what keeps us happy. It’s a meta question, what’s the purpose of life, and I think for a lot of us it becomes, as long as there are problems which we’re solving, that satisfaction of solving deep problems is what I live for. So that’s what keeps me busy. I think there’s also a certain paranoia of quality, so it’s not just about solving a problem, it’s solving a problem really well, and outdoing yourself in terms of expectation. I think it’s that self-benchmark which actually makes work a lot more fun than you would imagine.

So how do you stay up to speed on what’s happening at Urban Company and what’s going on across these teams?

There are two ways. There’s a structured way, where you’ll have meetings and conversations, and any leader or manager who structures work where you’re planning and then meeting with different stakeholders, either you’re meeting people, you check in based on that person, or you’re having meetings on projects, but those are more understood constructs. My favorite way to figure out what’s happening is skipping all the management layer and going straight to the root of it. For example, it is fairly known in our team that, not always but sometimes, I’ll go and just open up a repository and look at it, and that’s the easiest way for me to understand how well things are getting engineered. Is the design done well? Are people understanding things? It’s very evident to figure out faults when you’re looking at the actual outcome. So I look at code, I will, as a consumer of a product, look at any features we’ve launched, or how business is doing is best expressed by me being a consumer. I will do calls with our partners or professionals to understand their pain points. So I think it’s a very popular saying, trust but verify, so trust is the structured stuff, and what I’m describing is the verification process, where I want to jump straight to the grassroot level and really get a sense of, are our plans really solving the right problems, emotionally get charged about how our impact is going, and I think that’s what gives you a lot of confidence on what needs to be done, what doesn’t or should not be done.

Nice, I like it, makes a lot of sense. It really allows you to have your finger on the pulse of what’s happening and not just rely on your VP level to give you your information. So how do you do this outside of Urban Company, how do you stay in tune with what’s moving and shaking and what’s happening in the tech scene, or what’s maybe just a trend and something you shouldn’t worry about?

I’ll be honest, I’m not very good at that. That’s a hard one. There are certain ways you could do it, and some people get really good at it. I love to talk to people. I think the easiest way to understand what’s happening is having conversations. Even this conversation, I’ll have a few things which I can take away from what you’ve said and how you’ve addressed things. I think just talking to people is a very healthy way to gather information. A lot of reading helps. You can be reading books, you could be reading online articles. In today’s world reading can be compensated by watching YouTube videos. I really like YouTube videos or audio podcasts, that allow you to do things on the go, it’s a little crisper, you can do things while you’re busy taking a job or some of those. I think those are some of the good ways to be obsessed with other things. But I know that there are much better ways to go about this. It’s all about discipline. I don’t think you need innovative ways to find new things, it’s more about discipline. The simplest of techniques will work wonderfully if you’re disciplined about them, like exercise. So if talking to people is your way, you have to be disciplined, you have to find the right people to talk to, you have to do it as a habit. You probably want to know everything, but yeah, that’s my big spot, and a lot of what I learn is actually from my own team members when I’m conversing and I throw in ideas, and they push back, hey, what have you heard about ABCD, and I haven’t actually, let me research more on this. So that’s my way.

Yeah, well, I would say my world is, I spent the last decade being an analyst, kind of studying how to surface everything and stay on top of everything in the world of APIs and microservices that’s happening out there. And I felt like, having had a 20-year history before that of owning production and having my hands in operations, I wanted to find a way of balancing that. I don’t want to own production systems anymore, but I do want to understand how things work, and so Postman for me is my vehicle to do that, and I get to have conversations with folks like you, but hopefully I get to help also share, because this is a podcast and other folks can listen. But I get to peek inside some pretty interesting companies like Urban Company and others. I’m going to be doing eBay’s next, then I’m doing Ford. So it’s interesting to see how people work inside, and then I get to pay attention to the bigger picture and have conversations with you. So how has Urban Company changed your life, would you say?

That’s a hard assessment to make, because my adult life has all been Urban Company, so there’s no benchmark which I have. It was hardly two years after leaving college when we started this, so this has been life for me. I think some interesting things which I reflect on will come to my mind. As an entrepreneur, I was very obsessed with ideas when I was young in my journey. I have a fantastic idea. I remember the day when I moved back to India to start my first company, I already had a product made, and it was using, I think Firebase was the rage back then, it was just launched, this is back in 2013, and you know what, I can make an Uber-like app on a web page and you can use Angular, and wow, amazing stuff. And the day I actually launched and tried to get my first customer, I realized that’s all irrelevant. This tech which I’ve built is not going to matter so much. And I think when I reflect and see my journey through the years, those big learnings in life have been not to focus on solutions. There are hundreds of ways to solve problems, but it’s very important to focus on problems, identifying these problems. And the funny thing is, I’m so obsessed about this that I use this not at work only but also in my personal life. So if you talk to my parents, they get really frustrated with me, because I’m asking concepts like, what’s the problem, don’t jump into the situation, guys. My sister, who is also a product manager, jokingly pulls my leg, because I have been heard, I obviously wouldn’t claim, but I have been heard using terms like OKRs in my family meetings. So I think how Urban Company has affected me runs deep, and sometimes it’s hard for me to figure out how it has.

Oh, I love that, family OKRs, parental, I really like that. That’s an interesting way to, I mean, I’m glad your sister can relate with you, because I’m sure she thinks of the world in similar ways. I can relate, I live and breathe APIs, and to be honest I’ve been doing this for about 12 years now solid, and before that I wasn’t really that good at much else, and I’ve been pretty good at APIs, so I kind of live and breathe it too. So I can relate, it becomes your life, it definitely can take over. So what do you do to take your mind off of work? It sounds like you’ve got hydroponics and growing. What else do you do to take your mind off all this?

Yeah, I have a lot of passions. I don’t sustain a passion for too long, but I do get really into something. To name a few, my most recent one has been tennis. In fact, just before this podcast I had to put a one-hour break in the middle of the day, hit a few shots on the wall. This has been a more recent love of life. I was obsessed with ukulele, so I put a whole blog on chords and chord theory, and I’m no professional by the way when it comes to music, so it’s just the depth of research and the interest I had just made me write a very technical summary on that. So those have been a few things. Cocktail-making has also been something which I got introduced to earlier this year, so I was very fascinated by margaritas and how to make them at home. And if you know me well enough you would be like, boss, cocktails is not my thing, I hardly drink, and it’s very weird that I found this, but yeah, lots of having passions, every month is a new flavor.

Yeah, it sounds like once you pick something up though, you commit and you go all in to understand what it’s about and experience it, and then you’re happy to move on to the next thing as well. I like that, I think that’ll keep your mind healthy as you get older, as we get older, because you’ll always be curious and always be diving into something else. Well, this is great. I have to say, how I learned about you, I was just doing a leadership meeting at Postman, and our integrations team is run by Abhijit Kane, who is one of the co-founders of Postman, and because I’m the Chief Evangelist and I focus on APIs we meet regularly, and I was explaining to him what I want Breaking Changes to be. I don’t want to deep-dive into the tech, because we have DevRel that works with our developers and our developer community. I want to speak more to business leadership, CXOs, product managers, engineering managers, and I want to find people who are practitioners. I’m tired of talking to folks who just talk about APIs that don’t actually understand why we’re doing APIs and microservices. He’s like, I know someone, and you came to mind, and he recommended that I reach out to you. So I have to say, it worked out well, it was exactly what I was looking for, just hearing how you went through your thought process, your opinionated approach, the attention to detail, and going through microservices. I hear a lot of opinions about microservices, but they’re rarely as precise as what I heard from you, so thank you. I got what I needed out of this conversation, I hope you did as well.

Yes, you’ve been very kind, and I think these are all journeys. And one thing I don’t want to share about Postman, I have shared this publicly as well, very few products are just so essential to an engineer that you just expect that to be, I mean, you code, so there are certain tools you just take for granted. Back in the day, as a young age, Postman happened to be one of those products which I think every engineer, I don’t know if every engineer, but when I was growing as an engineer in college and stuff, it was the de facto tool to explore the world around. And I was super psyched and happy to find out that there’s a connection. I think the best products are products which are just so organic that they feel that they’re not products, they just are the de facto, and I think Postman fits right in that bucket, and I think that’s also been why it’s been doing so well.

Yeah, I think you described it well, exploring the world, because APIs and microservices are so abstract and hard to see sometimes that you need help exploring that world and being able to see how it works and play with it and understand it and tweak it and mess with it. So yeah, that’s definitely why I’m here, I couldn’t think of a better place to be. Well, this has been great, I really appreciate your time today. I would love to reach out again in the future as we keep going with the show. I think we’re going to reach out to past guests, it’s coming up to Postman Galaxy and our other conferences, we’re going to invite some people back to speak and be part of that. But same on your end, I would love to just learn more about what you guys keep building and how things are going. So I really appreciate it, thanks for your time today.

Thanks for having me, it’s been a pleasure.