Bharat Mediratta is the first Coinbase Fellow. Previously, he was a Distinguished Engineer at Google, CTO at AltSchool, and CTO at Dropbox.
Apple Podcasts | Spotify | Google Podcasts
We focus this episode on the role of a senior technical individual contributor in a technology company and contrast that with the role of a technology executive (like a CTO) in a public company. We talk about how to explore what the right position is for someone, what drives their success, how to drive impact as a technical leader, and the trade-offs that have to be explored by both senior individual contributors and leaders.
Highlights
01:00 - The story behind switching from a CTO back to an individual contributor.
08:00 - What does a director/VP/CTO’s day look like? How do they drive impact?
14:00 - If a manager has to make effective decisions and has input from individual contributors, why do they need to have a computer science background? Why do tech companies frown on hiring non-technical (MBA) leaders?
21:00 - A manager is certainly thinking about business priorities, and a senior technical individual contributor also has to think about business priorities. But how much? What’s their approach in driving towards business outcomes? How much backing does a technical leader need from management in order to be effective?
28:00 - When should Heads of Engineering think about hiring senior technical individual contributors? At what stage/what shape of problems should they be dealing with?
32:00 - The initial transition from senior engineering at Google to CTO of AltSchool
47:00 - For the next person exploring a move from IC to management: how to go about exploring the move? What should they keep in mind?
Transcript
Bharat [02:00]: Yes, Hey, thanks for having me back. I enjoyed our first podcast, it just reminded me of so much fun that I've had in my career doing great things, especially when I was at Google, and it's nice to be back. And yes, and thanks on the role, it seems maybe like an odd turn, I think, to go from being a Senior Executive Organizational leader at a big public company to being an individual contributor. But in many ways, for me, it felt like a very natural transition, and in fact, I know a lot of other people who have done this. I think to understand, like, what's going on here, you kind of have to wind the clock back a little bit, I spent most of my career doing this kind of arc where I would join a company as an engineer, I would become a technical lead, then I would become an organizational lead of some kind at the line manager. And then I would realize that I just didn't enjoy the things that I was doing on the organizational leadership side. And I would always be trying to steal time to work on the technology, partially, I think, because I was more comfortable with it. But also, I think what was clear is that it gave me a lot of joy and energy.
And I would just then get to a point in these companies where I didn't want to keep going on the trajectory that I was on, but I didn't feel like it was acceptable to go back to being an individual contributor. So when I got to Google in 2004, I also once again joined as an engineer, and I committed myself that I wasn't going to become a manager, I wasn't going to become a team lead. And that lasted actually for about three years but I am not good at ignoring a vacuum or ignoring problems and at Google, there was this amazing opportunity to take on a team that was important to the company and lead it. And so I thought, I'll try it again maybe I've grown up, maybe things have changed and I'd say in 2008 2009, it put me onto like a 10-year trajectory of becoming a Senior Engineering Leader. And there were a lot of parts of it that I was pretty good at, I'm a humanist, I think relationally, I enjoy people, I enjoy getting to know people and understanding, I enjoy that aspect of organizational leadership.
But there are also a large number of challenges to that role that Co-Op as your team gets larger, that take a lot of your time and energy, your primary tool stops being your compiler and your editor, and your primary tool starts being like Google Slides and email and meetings. And over time, I found that as I got better and better at being a technical organizational leader, I just found that I was enjoying my day-to-day less and less, and at first, I thought this is just [05:00] par for the course, this is just what you have to do to have a big impact and I felt like I did have a big impact. But I got to the point where I realized it used to be that I enjoyed my job, I didn't feel like I worked, I was blessed to be getting paid to do something I'd love to do and would do for free. And I kind of shifted more towards a model where I didn't love everything I had to do every day and in many cases, there'll be entire days, but I loved very little about what I did. And it was important and I felt the need and the value in it but I also was feeling myself slowly getting more and more demoralized, or less and less enthusiastic about the mission I was on.
And after I left Dropbox, I did some soul searching; I thought to myself, well, why am I doing this? I'm at a point in my career where I have achieved many of the career goals I set out to achieve and I'm just not enjoying myself as much as I would like to. And why is that? I didn't feel like I had to do something, even though I didn't enjoy it anymore, kind of reached that level where it's okay to not necessarily work every day. And so I decided to myself, I will go see what I enjoy doing when there is no pressure and no structure and no money, but only time. And I started working on things that I was passionate about and I found myself diving into finance and I found myself advising a lot of startups and startup founders, and I found myself learning about financial instruments and learning a lot more about cryptocurrency. Now I've been a cryptocurrency enthusiast, since 2013 or so, when I bought my first Bitcoin on Coinbase. And so, I spend a bunch of time at the beginning of this year learning about DAX, and DeFI and how SciFi could shift to DeFI, and ultimately, I started getting attracted to some of the missions of some of these big cryptocurrency companies. And when Coinbase reached out, the conversation with them was kind of awesome, I chatted with Manish Gupta, the VP of engineering there, and he and I had a great conversation where he wanted me to come in and be an engineering organizational leader.
That's where his need is, it's one of his significant needs. And we had this great conversation about what his calendar looks like and Manish is a very important, very influential figure Coinbase, in his calendar is wall to wall craziness. And I was like, look, Manish, that's not what I'm looking for right now and he's very smart guys he's like, well, what are you looking for, and when I told him was, I want to show up and learn from some of the best people in the industry who've been investing in this space and I want to understand how Coinbase is strategically increasing economic freedom. And I want to increase my skill set and then I want to find some hard problems at Coinbase and go apply myself there but I want to do it without the day-to-day burden of organizational leadership, the day-to-day burden of a stack of meetings, I want to be able to go back to my roots as a technologist and go find some big problems, and where better to do it than the company that's at the forefront of how these crypto exchanges are working. And one that's so innovative, and so together Manish and I hammered out this role and the role description, which for me feels like something which will bring me joy every day, and will give me time and space to go investigate.
And it's funny I have been talking with lots of CTOs and SVPs events over the last few months as I head into this role. And every single one of them, when I tell them, this is what I'm doing they all get that look in their face and go like, wow, that would be so nice. They'll be like, so great they like, lay down my burden of what I'm doing I was just talking to a guy yesterday, he just like, wow, and that sounds like so much fun. Because when you're in it, when you're running a big org, it's big, and it's meaningful, but it's also so strategic, it's hard to accomplish anything on a day-to-day basis. It's hard to feel that tactical win, it's hard to be close to the technology, and you’re just getting pulled so much into the corporate strategy, the organizational leadership aspects of it. So this for me is a welcome break and a return to my roots and an opportunity to go learn from a great team and get to apply my skills towards something which I think does have a big meaning in the world. And do it as an engineer again, which is some of the things that give me energy, and who knows where it leads few years down the road. But for today, I'm excited to be there working on this.
Utsav [09:39]: It sounds like a lot of fun. And the first question that I have is around for ICS like me who've never stepped into a management role. We can understand or empathize like what a line manager does, but what is a director, what is an SVP supposed to do? Why are their calendars full of meetings [10:00] every day? How are they supposed to drive impact were just like meeting people? I know that that's how they drive impact but what does success look like?
Bharat [10:08]: Yes. Well, I think from the fundamentals, if you look at it, and you say, hey, let's say you've got a big company that spends $100 million a year on product engineering design, let's just simplify, let's just say you're spending $100 million in engineering. You'd want that 100 million dollar to go into the pockets of engineers, and you'd want those engineers to build great things but whatever that's like, 400 engineers, that’s a lot of engineers. And those engineers need guidance, career coaching, they need a little bit of hand-holding, they're going to be at different levels of experience, and they need to be aligned, and they need to be focused. So, they all need line managers, so if every line manager is having reports that are like 12%, or 13%, of your team then automatically goes into management. And then you still have like 50, to 60 managers then and they need managers, so now, again, rule of seven, and then you're still going to have like 20, directors and they need managers and the VPS, and so on. And so at every level, the line manager has to understand how to marshal engineering talent and get them focused on working the right way so that the majority of their work leads to a result. But if you go up a level, and you have a director, whose primary tool is a series of line managers, and the director’s roles to get those managers aligned, you've got these groups that need to work together.
And for the most part, they're all heads down in their area so someone's got to work on that broader alignment. And so now you've got a director who has seven line managers, these line managers send in reports, you've got about, 60 70 people reporting up to this director, and then you have a VP who has five or six of these directors, and each of these directors is now wielding a pretty large amount of work product, roadmap influence, and you've got to get those directors aligned, and the farther you go up, the different the problem becomes. Now, your director is making sure that you're operating efficiently and reasonably aligned, so at Sun Microsystems used to say, tightly aligned, loosely coupled, so that everyone's headed in the same direction, but they're not current always jostling with each other because they're crammed in there. So, that's a different skill set at the director level, it requires you to be very thoughtful about how do you achieve this broader set of goals with this group of people, and you're always dealing with the problems that are bubbling up to you or the problems that your best leads under, you can't handle. And you handle the ones that you can, that you pass the rest up the chain to your VP, now your VP is not like, three 400 people. And the toughest problems there are bubbling up and your VP is now dealing largely with directors.
And so your VP has a very kind of images that you're like, trying to play chess with boxing gloves on, you don't have the kind of fine-grained control, you have to be much more like, Hey, move this set of pieces over there, move that to the pieces over there, you can't reach in past the director, past the line manager and influence an individual, you have to be thinking and kind of these broad movements, and it just goes up and up enough. So you can kind of imagine how the skill set of a line engineer is very specific in their domain, the skill set of a manager is a completely different skill set around relationally, helping engineers develop and cultivating them to become increasingly better and growing. And then, of course, the skill set of a director is different, it's strategically getting larger organizations to work effectively together to achieve company-level goals. And the director has to sit in this zone where they understand what every line engineer is doing but also understand what the C suite members are saying when they start talking about business goals, someone's got to bridge that gap, and they tend to sit in that middle spot. Then you've got the VPS above who are essentially strictly organizational leaders, it helps that they're very technically if they have a good technical underpinning, but they are around figuring out what organizational ships do I need to make? What key goals do I need to set? What top-level decisions do I need to make to get the team to move effectively? The further up the chain you go, the more your job becomes to be an efficient decision factory.
As a line engineer, your job is to produce code quickly. As you go up, you have to make tougher and tougher decisions and that's a very different skill set. So over time, people, I think get opportunities to move into management to apply some [15:00] of these things, but not everyone loves it because you have to make some tough decisions. And the decisions are generally along the lines of deciding what you're not going to do. It's very easy to make a non-decision and do a little bit of everything but that way leads to mediocrity and failure. The toughest thing for a leader to do is to hold a line and say, we are not going to do this, I know what's attractive, I know it looks lucrative, but it's not what we're doing, we may come back to it later, we are instead going to marshal and focus our energies on this set of things over here, which are small and focused, we can get it done and it will move the needle. So, as you think about people moving up that arc, they have to accept that their primary tool will change, their majority motion will change, it'll stop being you talking to the computer, it'll be you talking to other people. And then their primary set of outcomes and accountability will change too, because it will shift more and more towards what the business needs, versus what the technology can deliver.
Utsav [15:58]: Yes, that makes a lot of sense. And how in-tune do you need to be with technology itself? Like, we often say that there has to be somebody with like a serious background and stuff to be all kinds of like managers, directors, VPS, but they're going further and further away from technology. But why is it still important for them to understand, as the technology or is it important?
Bharat [16:21]: I think it is important, because they say in the army, when you become a general and you get that star put on your lapel, it's the last time people tell you the truth. A friend of mine, the USGS final telling me is similar and leadership in different ways, the more you go up the leadership chain, the more levels there are between you and the engineers in the ground, the more the messages from the engineers in the ground are filtered and interpreted for you. And they kind of have to be because the engineer on the ground doesn't have the necessary broad context. They just see like, hey, this thing is working this thing isn't and they may be complaining, hey, we don't have enough resources to finish this project and this projects important. But you as a leader might know that while that project is important, it's not a business priority, and you're going to defund it and D prioritize it, you're going to make a tough decision. And so you have to have some level of filtering but the problem is sometimes the real signal is thrown out in that filter. So as an engineering leader, it's helpful to know the base level technology and the fundamentals, such that when a message comes up to you, you can give it the sniff test, does that sound right? When people are talking about procurement or Dropbox, we've talked about procurement for hard drives. When you know, the size of the hard drive? And then you ask yourself, well, if we're trying to store zettabytes of data, why do we need 5x petabytes of storage?
Well, then you need to start like that's the kind of thing whereas a senior leader, you have to start thinking about, okay, well, how much of it is lost to the operating system, how much of it is lost to shredding, and redundancy, how much of it is lost to disaster recovery, etcetera, what's a reasonable multiple? So you have to have some sense of it in your head so you know, that 3x to 4x is reasonable, but 10x is unreasonable and so the more that you understand those things, the better. That doesn't mean that you have to be like, a hard drive firmware software developer somewhere in your path, it does mean you need to commit to understanding the fundamentals of the space that you're in. So, I would say that it's a bit of a false dichotomy to say that you can't be a good engineering leader unless you have been an engineer in the past, I would say, for you to be a good anything leader; you need to understand the fundamentals of the domain that you're leading. And when you go further and further up in the chain, you tend to start taking on things that are related. So for example, I was an engineering leader at Google but then I took on capacity planning. Now, capacity planning is related to engineering but it's a very different field where you have to understand supply chains and fabrication cycles and duty cycles and capitalization cycles. And so there are a lot of things to learn and I found that when I took that on, I had to go hit the books and learn a huge amount of stuff to like, be effective. And I think that's just par for the course, that's what you have to do.
Utsav [19:22]: Okay, yes, that makes sense. Now, you mentioned the job of, a director or a VP is just being an efficient decision factory. You're making tougher decisions at every level and you can also see how that's immediately impactful. Somebody's doing a project but you decide that you're not going to fund this project; you're going to fund another project because it's a higher business priority and that makes total sense. Now, when you transition to being a senior IC or when you are a super senior IC, how do you make a similar amount of impact? And is it even possible to make a similar amount of impact [20:00] what changes, at least in that impact sense?
Bharat [20:05]: Yes, it's a good question, one argument is that to have a big impact, you have to do more than what you would do with your own two hands, you have to marshal a team and that usually speaks to leadership or management. But in the technical realm, I think you can have a very large impact by setting technical direction. If you think about the role of a CTO, it is to understand the arc of the world, the understand the needs of the business, the arc of the business, and then to figure out where those things intersect, where do the challenges of the world? How far out do we have to go for our new technology to satisfy that? There's an intersection point out in the future where you're like, hey, if we proceed along this trajectory, with this many people building this technology, then by this time down the road, we solve that world problem, it becomes monetizable, it floats the business, we're in a good place, and the role of the CTO among other things, to find that intersection and figure out well, how can we bring that in sooner? How can we do it six months, sooner, or a year sooner?
Because in many business contexts, being able to deliver it six months sooner is all the difference between a successful business and that is carved out, no real market niche, and the business in second place that just can't quite keep up. So, you kind of need to understand how all those pieces fit together to do this, and very often, that requires you to be deeply invested in technical strategy, and setting the technical direction. So, in a large company, like Google, or Coinbase well, there are large companies like Coinbase, massive companies that Google. There's a lot of opportunity for impact by being a technical leader, who understands how all these pieces fit together and can start setting technical strategy that accelerates the business towards where it needs to go. And especially for companies Coinbase scale, I think there's just a lot of opportunity still to focus on this, you get to the scale of, say, a Google or an Amazon or Microsoft or Facebook. There are a lot of things that are so big and so deeply entrenched, that it's quite difficult to like, make big technical changes. So, one of the things that excited me about Coinbase is there's still a lot of time and room and space to make that happen.
Utsav [22:31]: Yes, I think that makes sense. And as somebody who's setting technical direction, how much are you thinking about the business priorities? You probably are, but how much do you weigh that in versus other things like organizational alignment?
Bharat [22:47]: It's a good question. Well, it's an interesting question, because I'm kind of going back to this role after a long hiatus. So, one answer would be like, hey, ask me in a month, two months, when I've had a chance to find my footing. I think that what will likely happen is that I will partner with the organizational leadership, so I've got the time and the boots on the ground to go understand some of the technical challenges, I do not have the double-edged sword of organizational leadership which will simultaneously give me the autonomy to go do some of the work myself, but also would come with the drag of having to maintain that organization and lead it. So my sense is, how this will work out is I'll partner with Manish and I'll keep him informed of what I'm seeing. And I'll start making suggestions and proposals and shifts and adjustments to what we're doing now because he will have the ability to shift the organization in certain directions but it's a little too soon to tell.
Utsav [24:00]: That makes sense. Is it generally true, it seems to me that as senior IC, you need some kind of air cover and backing from senior management to drive maximum impact, you can have all of the ideas in the world, but unless they get funded, or they're discussed, and there's somebody who's saying, you know what, we should fund some of these ideas. There's not that much impact we can make.
Bharat [24:29]: It is always beneficial to be able to bring leadership along with any decision that you make, I would say it's not just leadership, it's the whole organization. No engineer is in a vacuum, no engineer has the kind of authority and frankly, it takes time to build trust and credibility. I'm stepping into a space where there are a large number of very smart people who worked [25:00] hard and understood the complexities of the problem space. Most systems are sophisticated solutions to complex problems and it's easy to mistake that sophistication for unnecessary complexity if you don't understand the problem. So step one in all of these cases is to go understand the problem, go get a sense for what they're solving and why, go understand the solution, and then try to understand where is it correct in terms of its sophistication? And where it could be adjusted, where it's maybe a little too unnecessarily complex? Or maybe it could be simplified? Or maybe we can re-evaluate the invariance of the system? What was the design for? What is it solving? Are those things still true? Are there ways to make shifts, and in all cases, that's a dialogue, that's a understand frame out the problem, get people into a room, and have them understand it?
And my sense is generally, the right solutions, there are emerge it, you converge it and the things that hold you back, are essential when it's just going to be prohibitively difficult, or maybe people have invested in certain areas, and it feels like too big, correction, there's always a level of change management to get from the trajectory or on to a different trajectory. I'm not so worried about that, my sense, and one of the reasons why I've enjoyed the process of getting to know Coinbase is that I've found them to be the folks I've talked to, and I talked extensively to folks in the team before I joined. I found them to be very open to this and very humble and very excited about the prospect of making some changes and looking to bring in some DNA from the outside to go focus on some of the challenges they have. And frankly, I'm excited to just get people to collaborate with on this. So, I'm not too worried about that, I'm not worried that, I'll show up, I'll have a bunch of great ideas, and no one will listen. I am honestly more concerned about getting the time to be able to invest in learning and understanding the great work they've done already. So that when I get to the point where I'm thinking about changes to make I understand the problem and the solution.
Utsav [27:26]: Okay, I think that makes sense. And when you step into such a role, is there a particular team that you join? Are you reporting to the same line manager that other engineers are reporting to, how does that work? And what do you think makes sense, I guess?
Bharat [27:42]: So, I begged for a bit of an exception to the normal case where you would join the team and work on that problem. And the reason why I begged for this exception is that I felt that one of the advantages to bringing in someone as a more Senior Technical IC is to give them the time and space to go make their assessment. And so that, I asked for that it's a privilege and I appreciate the consideration that Coinbase offered to let me go have a little flexibility to make my assessment. And then I will be in a position to have a real discussion with the leadership team about what's the right thing to work on, I've found, Manish, and the rest of the team to be very thoughtful about creating that space. And to be honest, when you're stepping into a company that's been doing work like this for eight or nine years, it's difficult to be able to figure out this stuff quickly.
If even people way better than me, and there are people way better than me could come in and figure it all out in a couple of months, then they haven't gotten nearly far enough. For a system this large, this complex, it's a $50 billion company, that's one of the top crypto exchanges in the world in an emerging space, that's been doing a huge amount of pioneering and is aggressively moving. There's a tremendous amount of sophistication that solution they have, it just takes time. So, I sense that if I was going to do a more conventional roll out of the gate, I would just be picking one thing now and going and focusing on it but I asked for their indulgence to let me take a step back and look at it from altitude. And spend the first quarter or two doing that, so that I could be more productive down the road and I view this as a long-term engagement so, and so there's Coinbase. So, it makes sense to carve out some time upfront, because it becomes a very small percentage of where I and hopefully many other people who follow the same path can add value over time.
Utsav [29:50]: That makes sense. Let's say that I'm ahead of engineering and I'm thinking about, okay, I have a bunch of line managers, let's say it's not a large company. Like [30:00] 30 engineers, 40 engineers. At what point should I be thinking about bringing in or even having, technical leaders or Senior Technical IC, does it just not make sense until you have an extremely complex application? Does it not make sense until you have 200 engineers? What's the framework you should be using to think about this?
Bharat [30:23]: What is the value of Senior Technical engineers? Well, they're experienced so they've kind of, they have seen things that work and don't work in the past; they have enough understanding of the fundamentals of prior different situations. Very often, one of the real roles of technical leadership is deciding what don't do now what you do, like pruning bad paths from the decision tree, which saves you a ton of time. And so I would say that if you're the head of engineering, and you're the work that you need to do, and the operating specifications of it are well defined, you may not need, you may just need people to go execute against your roadmap, and which is, by the way, hard enough to find in today's industry. And that's not to say that you're not getting a talent, you can always use a talent, I think you should always be aiming for a talent. But it's more in a situation where you're trying to do growth into an unknown area, you're trying to go up by an order of magnitude, you're trying to move into a space, where you don't necessarily have the skills in house, most companies, if they 10x, a couple of times rapidly get into a space where they simply don't have the engineering talent in house to do this. Because when you take a product and you make a 10x, larger, at Google, we always used to say, when you make a problem 10x larger, it ceases to be the same problem, it becomes a very different problem it becomes about the scale that you're moving into.
So, if you're a company that's trying to grow rapidly, or pushes into new domains, or understand things differently, it's helpful to have a deep bench of senior technical talent who can go off and investigate, building complex systems. That's not the kind of thing that you would normally conventionally put on the roadmap, you need people who have the time and the space to go explore and come up with new and innovative ideas. So I do think that like, it also depends on, are you a product company? Or are you a platform company? Are you a technology company? So for example, Google fundamentally was a technology company. And so they invested in technologists to go explore all kinds of spaces and then they were good at recognizing odd this will be useful when we 10x again, this will be useful when we 10x again, let's keep these things, let's double down on our investment, some of these spaces. As a result, Google was always well prepared, when we grew, our systems and our technology could keep up. Many companies when they grow in the scale, it's hard for their systems and technology to keep up because they don't have that deep bench of people who's already been kind of ranging out in front, fairing out new things to do. And so then when their growth kicks in, they wind up in a scramble to keep up with that growth. Dropbox was great at Dropbox grew fast in you know, early 2010, 2011, 2012. And they had a world-class technology team that was able to stay ahead of that growth curve, which is not easy, and an event investing and a lot of people to go build large scale systems ahead of the demand. The problem is if you build those large-scale systems ahead of the demand, and the demand doesn't show up, then you've wasted that investment. And if you don't build ahead of that curve, and the curve does show up, then you're going to fall over so it's a tricky calculus.
Utsav [34:02]: I think the whole idea of you have to think about how much ambiguity you have in your roadmap and that helps you inform that decision makes a ton of sense to me. Could you share publicly the kind of things you'd be thinking of at Coinbase? The kind of maybe projects not specific projects, but just the kind of work you're thinking about, like infrastructure work, exploring new things, you think it's just off the table?
Bharat [34:33]: Well, I want to be respectful to Coinbase and not divulge any of the cool things that they're doing behind the scenes. So, let me just say this I feel comfortable with a pretty broad charter and I think all of those things are on the table for things that we could talk about. They're all areas where Coinbase I think, is growing rapidly and innovating and so, I currently I'm not trying to narrow [35:00] my options down right now. But let's talk in a couple of months after I've gotten my boots in the ground, and then we could see what I could share with you.
Utsav [35:10]: Cool. What does it mean to be a CTO of a small company or start-up when you started with old school? That's such a different role from being a super senior IC Google and what mindset shift did you have?
Bharat [35:26]: Well, it's tricky, because an old school we're solving a humanity scale soft problem I think it's deceptive to think that you can solve these types of problems with technology. Technology can help but technology is the tool, and technology has a wide range I mean, like, banging, flint, and steel together in the woods to light a fire is a technology. Rocket fuel and fire to put a rocket on Mars is also technology but if you're lost in the woods, you don't want to Falcon nine, you want to Flint and Tinder and steel, you want the right technology for the job. So, part of the role at old school was, well, what is the right technology for the problem and a lot of what I did at old school was understanding the problem to get a technology solution that made sense for where we needed to be over a certain period. And I would say that, unlike many Silicon Valley companies, the old school was technology second or maybe even technology third, after the pedagogical model. And after the curriculum design and the content design, and the operational model of running schools, then you have the technology, it's kind of scaffolding and a structure and a utility, that helps make things easier.
And so, for a CTO of a small company, I do think you want to be thinking very carefully about what is the problem to be solved? Where is the correct place for technology to be injected, such that technology supports and drives the mission and the business? And then how do I Marshal the correct team to go get it done efficiently? And very often, that means, a buddy of mine just joined a very small company, the CTO, he's probably going to start by looking at the problem assessing where it's going to be say, the scope of the problem today. Let's say you have 10,000 users today, and you think that 18 months from now, you're going to have 100,000 users, and three years from now you're going to have 300,000 users? Well, you don't need to build a system anytime soon that can support a million users. So don't go chasing massive scale efficiency, start thinking about, well, what's the operational characteristic of your users? Are you high transaction volume? Is it okay to be lost? Some systems care, a huge amount around integrity, some systems care, usually around response time. You start thinking to yourself, what are the different decision points you can make? And then you can start getting into driving decisions like, well, okay.
Are we a product or a platform? I was talking to a CTO recently and my big question for him is like, if you cannot answer whether or not you're a product or platform, you don't know where to marshal your resources. So very often, what the early-stage CTO has to do is to go figure out, okay, what are we? And what technology do we need to have? And what characteristics do we need to have by 18 months to 36 months out? And how do I build out an architecture that is neither too much nor too little, that achieves the goals of the business in a way that makes sense? Some businesses need to be high volume, very fast response time, some are pretty low volume and can have a reasonable risk, medium response time some can be heavier, some to be lighter, some need to be models, or you could iterate quickly, we need to be able to push a feature every couple of days. Some of them are the types of systems where you don't want to push features every couple of days. Your users want stability, they're like, utilities, they expected not to change all that often, and they prioritize stability over rapid injection of features. So very often, the CTO needs to decide, okay, once I know what those characteristics are, then I can make architectural decisions, then I can start thinking about what frameworks or technologies I need. Do I want to be native on mobile? Or do I want to be cross-platform on mobile? All of these decisions, I think an early stage CTO should be thinking about in the vein of where are we today? Where are we going to be before our next rates? Because very often, what you're trying to do is get to the point where you raise the next round of money.
Now, if you're the kind of business where you [40:00] don't necessarily need to raise a bunch of money, and you're looking at a longer-term arc and you're thinking, okay, well, we are going to run this, and we are very confident that we're going to get to 100 million users, which is a large number. It's not a billion-plus user, like at Google scale, but most companies have to get to 100 million users or over the million static 100 million users at a certain transaction volume, you got to figure, how many actives you're going to have? How big does your serving stack need to be, etcetera? So very often, the early-stage CTO is, got to be thinking about it in terms of stages and tears, and figuring out at every stage what you need, and then building out a roadmap to get there. So, we're going to do these architectural decisions in the early stage, and then when we start pushing past some of these thresholds, if our users get more active, or we get more users, or we're trying to monetize, then we're going to make this series of different decisions, and we have some decision points. And that's hard that requires discipline, requires hygiene, it requires a lot of careful thought, on the part of an early-stage CTO, and you know that CTO is also probably coding, and probably working very closely with the engineer and understands all the engineering challenges and solutions. And that CTO is also working closely with the CEO and their other peers and business partners to make sure that they understand where the business is heading and what's coming. That way, the CEO is not off selling products that engineering can't build and engineering is not building the wrong things, because they didn't understand what the CEO's vision for the company is. So, you kind of sit in that spot and it's tough, you spent a lot of time as an early-stage CTO, running around, dealing with a bunch of fires. But you wind up being probably the only person who can translate what's happening in the business down to the line engineers.
Utsav [42:04]: That makes sense. One of the distinctions you spoke about was being a product versus a platform, why is that important for a CTO or even somebody like an engineer joining that company to know?
Bharat [42:17]: So imagine you're the CEO, and you've got this app that you built, and you're going and selling it. And your customers like, this is awesome we would like you to build a version of that app for this slightly different business. The CEO is like, well, great we've got this one app, we have a team that's built it, how hard can it be, I'll go make a deal to sell it slightly differently to this other adjacent business. Now you go back to the team, and the team has two choices. If the team has built the app like a product, they don't have an easy way, the app is very tightly tuned, they've made a whole bunch of assumptions about what they're building the domain, and those assumptions are valuable. Because by making assumptions, you simplify your code, your code does not have to have a lot of abstractions, it does not have to be super flexible, it does one thing and it does that thing well. But now if you want that code to do something different, it's quite hard, because you have to go and find all the places where you made those assumptions, which are time-saving and you'd have to generalize them, you'd be like it could be this or that, and then you start getting into really weird edge cases. So it's difficult to take a specific product, and then transfer the value of it over into another specific product, you kind of have to rebuild the new product from scratch. But if you build a platform, then most of the value is in the platform and the app itself is merely a conduit to the value in the platform, using, say API.
Now the downside to this is if the CEO comes back and wants to add a feature to the product that can be harder because you've got to go add the feature to the platform, then you got to come to add the feature to the product, you've got to plumb between the app and the platform to get it to work. And it's probably not exactly what the CEO wants, because the platform itself has to be generic enough to be flexible and the app is kind of doing a translation there. So, you lose a little bit of that like hyper-specific, amazing app specificity but if the CEO then goes and makes a sale into an adjacent space, you're then writing a new app, which sits on top of the same platform, and you get to translate much of the platform value over into the new app. So if things like identity, and storage and networking and configuration, and basic UI modules, all those things are part of your platform, then reassembling those Lego pieces into a whole new beast is not so difficult you can do it quickly. It will also be not as hyper-specific, but it will also be a lot more stable and reliable and you get a lot of reuse in your engineering team. So, you're [45:00] always making some of these tradeoffs and it's important to know which ones you're making at any given time because that way if your CEO is about to go into making a sale, you want them to understand, how difficult will it be for your team to achieve the result.
If you build the product, and the CEO is now excitedly selling that product in a way that was not designed to support as the CTO, you want to be able to give guidance and yes, we can do that, if it's good for the business, we'll do it. But because of certain assumptions we made along the way, it will take you a non-intuitively long period to make that happen. And that's where the CEO needs to understand, okay but if I shifted a little bit and sold something slightly different, instead of selling to this customer, I sold to that customer and I got similar value, but much easier, lower hanging fruit in terms of cost, then I get a huge benefit that way. So, very often you as the CTO become the translation layer and that's why it's important to start asking yourself these questions, so if you're a CTO upfront, I would be talking to the CEO, what kind of sales model do you want? What things are we willing to trade off, explaining to your partner CEO, the difference between a platform and a product important, so that you can kind of co-create the solution together? You can say, okay, yes, we're going to be a platform because we anticipate having to be flexible about our domain and we're willing to trade off some hyper specificity in our app, versus saying, hey, no, we're going to be an app, because we're going to be a product because we don't believe we're going to shift domains and we want the hyper specificity in our product and we want to make a bunch of simplifying assumptions upfront. But these are all things that you need to negotiate with your peers so that you don't wind up kind of making bad assumptions going down a path and then finding that the business needs necessitate you doing something which you kind of ruled out based on early assumptions, and then you have to go back and do some very heavy lifting to get back on track.
Utsav [47:12]: That makes sense. And in fact, I feel like it can be applied to things within the app, parts of the app could be more platforms is that you can easily make shifts there.
Bharat [47:21]: Right. And by the way, it's a very common issue among engineers, when they don't know what they're going to be asked to do to build more generalized systems. It's like you're building your first app, and you have to build an authentication system. One approach is to do something very, very specific, hard code everything because this is the only time you're ever going to do it. But very often, people are like, well, I might get called on to reuse this in some other way so, I will bake in an abstraction layer at this moment. And when you bake in that abstraction layer, you are future-proofing the system, but it comes at the expense of a bunch of additional work every time you use it. And so, you potentially win big under certain circumstances, but you pay a tax every day that you use it. I am in favor of don't pay the tax, do the dumbest thing that can work, let the business needs evolve, and then once you understand truly what the business needs, go re-architected as necessary because that way you don't waste time upfront but you know that if certain business decisions are made, you have a set of work that you're going to have to do. And that's not the worst thing in the world because you can plan for it, you can make a series of decisions down the road that says, okay, if and when we cross this threshold, and we make the sale, we need to hire a team to go do this large scale refactoring, and pull our identification authentication system under separate cover, put it behind an API, rebuild the thing from the top down and by the way, clean up a lot of stuff in the process. That's a reasonable thing to do and it's better to do that in a more top-down way approach, than to kind of back your engineers into a corner where they're defensive all the time in every area.
Utsav [49:12]: And maybe as like a final question to wrap up, let's say that you are like an IC who's thinking for the first time, should I be transitioning into management? I'm not so sure whether I'll actually like all of the work that is in management, but I feel like I can go up my career have a larger impact. As someone who has made this transition to and from multiple times, what is the first thing that you would recommend? Is it just explore it, try it, see if you don't like it come back. Is there anything else you would tell people to think about?
Bharat [49:44]: You know, it's funny, I've had this conversation so many times with different people and I think a lot of people go into management for different reasons. So, whenever someone comes to me say, hey, I wanted to be a manager. My first question to them is always why? What motivates [50:00] you to do this? And a lot of times people what they're saying, pretty much very few people come to me and they're like, I love management and that's just what I want to do. Very rarely do I get that answer I'm sure there's a lot of people who feel that way but I don't get that very often. Mostly, what I get is people saying look, I want my career to progress and all the people who I think are succeeding are in the management of some kind. So, therefore, I must be in management of some kind and once I'm in management, then I will be succeeding. And the tricky thing is that it's not like engineering flows into management, it's not like it's the next stage in your career. That's saying work hard as an engineer, and then you become a manager, it's like saying, work hard as a painter, and then you become a ballerina, and they’re completely unrelated in so many ways. There are different motions, different skill sets, they require you to care about different things some people like it, and some people don't. So, the only way to know is to get some exposure to it and there's a lot of ways to get exposure to it. One of the ways to get exposure to it is to talk to a lot of managers, what do you like? What do you not like? What is your day like?
Walkthrough the calendar, a lot of times I dissuade people from management merely by showing them my calendar. Let's look at my calendar, let's see what I'm doing today, okay, today, I have eight hours of meetings, by the way, right now, they're all on zoom. And that might be 10, to 14 meetings, a lot of 30 minutes one on one, some breaks, each one of them, has a certain amount of context for the individual. Here's what I'm trying to achieve in each of those meetings, here's like, is it relational? is a strategic? Is it transactional? What's going on in that meeting, what am I trying to achieve? And then you look at it like day over day, week, over a week, month, over a month, quarter over quarter, and you're like, okay, here's what it's like to be a manager, here's what I achieved, here are the goals and you're the outcomes and here's what I do to get there. And I think some people look at this, and they're like, I don't think I would enjoy that and some people look at this, and they're like, I don't think I'd enjoy it but I have to try it to know because it feels like the right way to progress. And it's a very personal choice, a lot of people don't know till they try it. The challenge is that because management seems like a step up and a large number of organizations do kind of glorify their management team so it feels like a step up.
Very often people don't feel like they can go from a management role to a non-management role, without leaving the company. And so one of the things that I would say, it's not so much for the people who are leaping, it would be for the company, I would say, listen, make it clear that management is not the route to success, doing what you do well, and having an impact is the route to success. You can switch between a management track and a non-management track, but that's not the relevant piece. It is taking what you're great at, and getting to do that as much as you can in a place that has access so, that people feel comfortable trying it without having felt like they have to leave the company, once they don't like it. That makes it I think, easier for people to find out if they like it if they're good at it. And the other thing I would tell people is when you realize that it's not for you don't keep doing it, go talk to your leadership team, have a candid conversation, and say, okay, I tried this and now I need a break for a while. And a good leadership team will recognize your value proposition, and we'll find a way to make that work. So that you're not so ugly tied up in the like, well, I got promoted to being a manager and if I don't keep managing, it's going to be a demotion, even though I don't like it and I don't want to keep doing it and I'm doing it poorly, and I think that's the trap a lot of people fall into that I see.
Utsav [54:02]: Yes, I think that makes sense it should be a lateral move, and it should be super easy to transition back. And that's what we'll even have the organization give bad management away, especially people who are not motivated about it.
Bharat [54:14]: You know what they say, people leave good companies because of bad management and stay a lot longer than they should because of good management, people's relationships to their managers are paramount it's important. And anyone who goes into management should take a lot of management training. There's just a lot of things that are not intuitive, and you don't want to learn it on the job you should be trained in it it's important.
Utsav [54:43]: Well, thank you so much for being a guest I feel like I've again learned a lot.
Bharat [54:48]: Thanks buddy. It was fun I enjoyed it.
Utsav [54:50]: Yes, and I'm excited to hear about your role in a few months.
Bharat 54:56]: I'm excited to dive in; I think Coinbase is a great company. So [55:00] I'd be happy to give you an update once I can answer some of those questions.
Utsav [55:06]: And congrats again.
Bharat [55:09]: Alright. Thank you.
Software at Scale 30 - Bharat Mediratta: Coinbase Fellow