T-24-004 : Tom George - Hardware Startup Engineer to Google Product Lead
You're listening to TRADEOFS, a podcast about the trials and tribulations of designing and manufacturing hardware. Each month, we sit down with founders, engineers, and other hardware professionals to understand the trade offs inherent in building a business that makes physical products. I'm Nate Padgett, hardware community guy and founder of Informal, a freelance collective that helps companies build and ship world class hardware.
Chris:And I'm Chris Rill, startup founder, engineer, and fractional CTO, where I help hardware and software companies build and scale their products. TRADEOFFS captures the best of these conversations so you can learn about the skill sets needed to successfully bring physical products to market.
Nate:For this episode, we're joined by Tom George, manager and product lead for Google's Sustainable Cities Initiative. Welcome to the show, Tom.
Tom:Yeah. Thank you, Nate. Thank you, Chris. I really appreciate this.
Chris:So just for kicking this off, introduce yourself, kind of what you're doing and who you're doing it with.
Tom:Yeah. So I'm Tom George. Work at Google, leading this team called Pebble. Been a hardware engineer all my life. And then moved more towards people management.
Chris:So for context, both Nate and I think know a bit about your story. Can you just walk through that transition into Google? Because I do think that is a really interesting one.
Tom:Yeah. So going all the way back, did my undergrad in India, electronics and communication, came to US to do my master's electrical and computer, focusing on signal processing. And my first job out of college was outside of DC, working in a very small speech coding firm. And we were making, and this is where I'm dating myself because the BlackBerrys at that time were text only, were running on the pager network. And they were like, what if you could just send little voice messages on a BlackBerry?
Tom:Like the concept of sending small voice clips to each other was novel. And so because we couldn't mess around with the BlackBerry hardware itself, we built a little BlackBerry case, which had a little processor chip and memory, and you connect through headphones, which were passing through to the BlackBerry, where you could record a little clip. We would compress that audio and then use BlackBerry's data network to ship that file over to the other side and decompress it back and play it on the other side. And so that was the product we're working on. You know, it didn't do quite well because it moved to cellular network.
Tom:And once it did, like a lot of these features, like, came through and it was just done.
Chris:So in terms of the company, was this a feature, a product, or a company?
Tom:This was a startup desperately trying to figure out what it needs to do because we had speech compressing technology. Essentially, were providing the speech compression for toys in China, But it was such a competitive market where we kept getting squeezed cents, 0.5 a cent, because it was a licensing deal, which means that every chip that got sold, you got a little cut off that. But those chips were getting cheaper and cheaper because they were going into toys. And so our cut became less and less. It was just not cutting it.
Tom:This is where I learned how every cent counts when you're trying to build product, and we realized that that was not a business. So we started to see what is the thing that we could use these speech compression technologies for, what can we sell here? BlackBerrys were the thing at that point. And we're like, what if we add voice to BlackBerrys? What a novel concept.
Tom:Didn't know anything about the scale, who to talk to. We didn't even talk to BlackBerry. We just like build stuff on top of it because we could. And I think even now, looking back at it, it was pretty clever for what we were trying to do. We built out the interfaces, we built out the connections, we built out pass through charging, the mechanicals of it, which was really interesting.
Tom:It was sort of a desperate attempt to find a market for the core product that we had, which was speech compression.
Nate:Sounds like that was just a huge learning opportunity. Oh, yeah. Just accelerated your understanding not only of product, but business.
Tom:Yep. That is where that switch from engineering started to happen. Usually you spend a few years just like core engineering when you come out of engineering school. Like year one, I was going to conferences to see, or I was going to trade shows. I went to CES in year one of my career because I was trying to see, is there anything out there that would need speech compression as a technology?
Tom:And immigrant sort of stumbling in English, trying to go to CES and trying to drum up a market for the product that we were selling. Only startups can do that because who else would send a 20 year old with no experience in sales or marketing or product to go figure out what you could do because there was nobody else doing it. So, you know, I went and did it. That was also my first time going to Vegas, is, you know, there's a whole bunch of, like, cultural things clashing at the same time.
Nate:How did CES go? Was it productive?
Tom:I attended CES for many years. I saw CES grow every year to become the behemoth that it is right now. It was productive. I mean, that's where we got a lot of these ideas. I mean, contacts with BlackBerry accessory makers and trying to use them as channel partners to try to build the product, sell the product, had enough excitement to be able to do a few runs of it.
Tom:We actually sold. I mean, it actually went to market as a product. It was just, you know, it was very quickly subsumed when BlackBerry changed. Then a friend mentioned there was a job in New York City that I should consider. It's a very small tech company called Maritime Broadband.
Tom:And the product was a VSAT, a 2.4 meter satellite dish, for cargo ships in particular, to be able to provide internet and phone access to the crew on the ship. And I mean, it was a quick jump in scale from making these chips that get sold for like 5 to 7¢ to making systems that get sold for like $75,000 or $100,000 each. So the idea there was there weren't already systems for satellite data communication for ships, but they were very expensive in the millions of dollars, which worked for like cruise ships. But cargo ships at that time had pretty much no communication for cruise. The crews, once you sail out, once you're out of cell range, you're just completely disconnected until you dock again.
Tom:And the shipping industry was having a major issue with recruitment because the young people were just used to being connected. But they could not spend a million dollars for a crew of 15 people. So you had to build a system under $100,000 and have low subscription fees. So that was the challenge. And the technology challenge was the fact that the ships are constantly moving and you need to keep an antenna pointed at the exact same direction all the time.
Tom:And so you just needed these stepper motors canceling out the movement of the ship. But you had to predict how the ship was going to move. It was like, you know, skating to where the puck is, and the ship moves erratically, but still has a pattern. So that was an interesting mathematical challenge. And yeah, learned a whole bunch of different things, building big systems, big, great manufacturing, BOMs, ownership.
Chris:BOMs, not BOMBs, right?
Tom:BOMs, bill of materials.
Nate:Yeah. Important verification. For
Chris:that system in particular, the price tag of this was, say, under $100,000 So I'm wondering, from a systems engineering perspective, when you looked at the cost breakdown, were you able to convert those problems from hardware problems to software problems because you know, you had enough compute on the platform? Or was it like hardware constrained and you're like, you really stressed out the software engineers? I'm curious about some of the trade offs that went into the design of that system.
Tom:Yeah, the compute was easy because, yeah, we could do a lot of computation and have a pretty powerful computer up there to be able to do all of this. The cost was in the electromechanical system. So even though the system was $75,000 the comparable system was $750,000 And they call it a radome, where actually the antenna is not exposed. It's actually enclosed within a big dome. So the trade offs here were we had to actually use a much cheaper stepper motor that was actually used for gears and cranes and stuff.
Tom:It was not a marine motor. So we had to go to the motor manufacturer and say, hey, can you shield it this way? So the interesting trade offs were more of like, how do we make it resilient enough and still be cheap enough? For example, do we buy all of the components? Because you can get mil spec components and just really jack up the price.
Tom:So you go through every component and get it to mil spec. But then can you actually invest more in an enclosure that seals really well and use cheaper components? And it's like, figure out what are the most expensive things. Maybe we can get the cheaper version or get the more commercial versions of those, but then design the enclosure to do this better. Can we enclose motors better?
Tom:How can we build this more efficiently? How can we shave cost off of that? And then you go back to the same thing of like, you deploy it in the field and it just fails spectacularly, like jams up, the motors jam up with salt immediately. And then you're like, oh, right, this doesn't work. And understood so many different types of tapes and things that they use in marine environments and how do you prevent things from corroding.
Tom:Every time you'll find out one other thing that corrodes in salt environment that you didn't think of last time.
Nate:Things software engineers don't have to worry about.
Tom:But like in Long Beach near Los Angeles, sitting on top of this gigantic 3,000 container mega tankers that they call it, mega container ships, sitting on top of that mast in setting up this antenna. But also these ships are so expensive that they have to be constantly moving for it to make any sense to be working. So they stop just to load and unload, and it's a whole process. It is just done so efficiently because they try to minimize the amount of time that the ship docks. And so that is the time you have to go in and make all your repairs and figure out all of the things that you need to figure out.
Tom:And it's like clock ticking, and it's usually like middle of the night somewhere. And you're sitting there with headlamps, you're just like, here's the list of things that have gone wrong from the previous doc to this doc. Figure out all of those things, document it, measure it, get everything, and then get off the ship before this thing would just leave in like five hours.
Chris:Yeah. My thought process was, can you just swap it out with something that you know works
Tom:so you could fix the
Chris:problems without those pressures.
Tom:Right, but the whole system, you need a crane. And if you want to just replace that whole thing, that needs another crane. And that's not easy. You can swap out the whole electronics box. I'm used to do that quite often.
Tom:But I mean, I think we went to market too fast and that tends to happen in startups. And I've seen that happen quite a few times. So there's that balance of you can stay in your cave and build and build and not be in touch with reality out there. And there is this thing of like, let's just go out and test it. And generally I've leaned towards, let's just go out and figure it out.
Tom:But there is a limit at which that breaks as well. If you go out too early and too fast, you'd lose trust out there. But the investor pressures, you have to say, how many ships are you deployed in? And you kind of know how well your system is working. And you're like, you should probably be deployed in two ships, but it's actually deployed in 20 ships.
Tom:So 20 of them are having a problem right now. And it's not just that. Then you have link budgets, and you have all of these agreements with these satellite companies to carry your signal through all of that. And then you have racks in the ground units, the base units, that you have to replace and fix as well. So it was quite a production.
Tom:And you need twenty four hours of tech support. And that was a new thing for me, like a full tech support team who's up 20 fourseven and setting that up.
Nate:Oh man, what a bear.
Tom:Yeah, so maritime broadband went under very quickly, ran out of money. We were all shocked. I had just hired an engineer onto my team and the next day we were all laid off. The whole company was shut down. To me, was like, people into the fold.
Tom:That was the thing that I learned because it felt very bad to be on the other side of it. But we found really strong bonds there. And the people that I hired there, I've rehired sometimes three times in my career later. And so I was on an H1B visa. I had to find a job in ten days.
Tom:I applied really quickly. And the first company that hired me was QuadLogic. And I didn't care what the job was, I was just getting in. But I was there for seven years. I built out the supporting engineer or sustaining engineering team, sort of evolved into that role.
Tom:Did that for a while until I felt like I was not adding any more value there. It sort of set up the systems. That's where I'd shifted into more of a process than engineering, like understanding that my value here is not engineering or technical solutions. It is more the process that the team needed. Then was a stint of, oh no, actually I went back to the second version of Maritime Broadband, which is called Broadband Maritime at that point, because they came back to life created.
Nate:Wait, they came back to life and just swapped the one?
Tom:Yeah, because the previous name they couldn't use for whatever reason, I think they lost it when they had shut the company down.
Nate:That's so funny. They probably were like, we could come up with something brand new or just play scrabble with the existing words. Right.
Tom:I went back there, but this time as VP of Technology. So I was sort of taking over the whole of engineering and setting up the team. That didn't last very much at all. And this is where, again, learning, understanding the capital structure of an organization is important, especially as you get senior into an organization. I didn't know what questions to ask, but second time the company runs out of money.
Tom:But this time it happens fairly fast. But I got the taste of being able to build a team from scratch towards building a product.
Nate:What happened there? Why did they run out of money so fast?
Tom:I mean, it was not capitalized well to begin with, the second round. It was not VC funding. It was private equity funding. And private equity funding is not great for early stage startups. So it had been pitched as a much more stable product than it was.
Tom:And as soon as I took over engineering, I realized that not much had been made in the seven years gap while the previous company had shut down. The product was pretty much where it was. And so private equity wanted returns very quickly. And I mean, we're all engineers. I kept mince words.
Tom:I was like, this is where the product actually stands. And if we pretend like it's not, it's just going to falter out there in the field. And I know what this field looks like. It's not like you can just go swap things out. It's a whole thing.
Chris:I think Startup might be producing product that would probably compete with this. Exactly. So I think there's definitely a need.
Tom:Yeah, yeah, yeah. There are ways to do it. Startup would be probably the best option at this point. Satellite phones used to exist at that point, but it was still like $4 a minute calling charges and stuff. But I know that Starlink has brought those prices down quite a bit.
Tom:I mean, every product has its little window of time when it's like perfect. It's not too early, it's not too late. And sometimes you hit it, sometimes you don't. And then our first kid was born. We had just bought an apartment in Forest Hills, so I just took a little time off.
Tom:And I'd really gotten fascinated with operations because I was doing process so much, I was just like, maybe that's what I want to do is process efficiency operations. Took a few courses online and I was like, I'm the operations guy. So I joined Lockpower, which is another startup in New York City. I'm working on building efficiency, energy efficiency stuff. That's where I got introduced to the ecosystem of startups because they were so plugged into all of the different startup networks in New York City.
Tom:And it's rich and it's vibrant. And I made so many friends in that process, All of the different streams from which you can get revenue, all of the different city solutions, because we were working very closely with the city. So then like New York City Department of FFS, or Mayor's Office of Sustainability, and all of them have funding streams and support. It was a whole system that I was not aware of. And so I was there for some bit of time.
Tom:And then QuadLogic that I had left had a big shift in management and again asked me to come join as their head of engineering, but essentially to remake the company from scratch. Like take it from like a meter manufacturer that has been in operation for a long time to sort of a IoT company with like building energy management. That was way too exciting. So back in New York again and worked there for a few years, building that out and got the company ready for a sale. And we were in the sale process when I eventually joined Tidewalk Labs to head up this team called Pebble, which is a sensor to detect if a vehicle is parked on top of it or not.
Tom:I was familiar enough with IoT and hardware, but transportation was not a space that I knew anything about. I had spent years at this point in building energy, but this was a whole new space of transportation and public policy and parking and all of that. So that was in April 2021, moved back to New York in August or September. And we were subsumed into Google in January of last year. And I found myself managing the same product and same team at Google.
Nate:Cool. And you are an avid attendee of Hardware Meetup. Yes. Or used to be. Used to be.
Nate:Gotta
Tom:come Yes. Attendee.
Nate:For those of you who don't know, I, Nate, in my company Informal, run Hardware Meetup, a monthly gathering of hardware professionals, founders, consultants, people who build hardware for a living that meet in cities all over the world. We're in over 30 cities, always adding new ones, and really look forward to meeting you at one soon. So keep an eye out and check out hardwaremeetup.com for more.
Tom:Yes, avid attendee of Hardware Meetup. I've actually hired people from Hardware Meetup.
Chris:Do remember what the first Hardware Meetup that you went to?
Tom:Actually, I don't know. My best guess I don't know if that was the first one, but the one that I remember, it was in the Microsoft location.
Chris:I want to say I went to, like, the first five or six meetups, and then things just kind of took off with Canary, and I didn't go back for years. And then when I went back, that's when it just exploded. You know, two hundred-three 100 people there every single month. It was just crazy. Yeah.
Chris:Wild.
Tom:I had attended the one in the Cyboc Labs office, which is interesting because the only reason I knew about Cyboc Labs was because of that meetup.
Chris:No kidding. Very cool. So in a way, you are at Google today because of New York Hardware Meetup.
Tom:I yeah. Yeah. I didn't connect those dots until now, but yeah.
Chris:So I'm sorry. Oh, man. That's awesome. Oh, that's too funny. Yeah.
Chris:No. I mean, I think I think that just speaks a testament to, like, the power of the community because you never really know what random element of that community is going to help you to where you are today.
Tom:And you, Chris, you've been a mentor to me. You've guided me through so many parts where I was totally confused as to what do I even do? What am I doing? What is my value to the society in general? And you took the time, sat with me, guided me through so many points in my career where I was stuck.
Tom:I'm like majorly appreciative of that.
Chris:Well, I hope that the folks that I talk to can make fewer mistakes than myself. So yeah, I appreciate that. Everyone has their own unique journey. And if you can just impart some wisdom on the folks, the world will be a better place.
Tom:Yeah. I remember you and I meeting at a place on 9th Avenue.
Chris:Yeah, I remember that.
Tom:And that was the first time, I think you had mentioned, Tom, you're less of an engineer now. You're more moving towards products. Have you considered product management? And I had not thought of that. I had not considered.
Tom:And even though I never became a product manager per se, but I knew that was the direction I was going. And it's just sort of clarified to say, I'm not doing engineering anymore. I'm doing other stuff.
Chris:If I remember that conversation, I want to say your role had expanded, and at that time you were wearing many, many different hats. And so I feel like you just needed permission to make decisions that weren't, like, in this the box that we call engineering.
Tom:Mhmm. Mhmm.
Chris:Yeah. And so going back to, like, that time when you were, you know, say, predominantly wearing, you know, an engineering hat, do you recall, like, that pivotal moment or those pivotal decisions where, like, you lacked clarity around kind of some of the decisions or who was making them or why that even prompted you to reach out?
Tom:Yeah, I think that at that point, I was leading a team at QuadLogic, mostly working on post sales stuff. So we were doing sort of the sustaining engineering while the R and D team, which was led by our CEO, who's an engineer himself, was more focused on the next generation of products. So there's definitely a cool vector of like, oh, the next stuff. But there was so much engineering work to be done to continue to keep the product that we had competitive in the market and continue to keep improving in it. But more importantly, what I had learned over time was that the engineering solutions to problems are the easy ones.
Tom:It's the structural problems that surround it are the more challenging things to solve. So it was less about the actual problem that was happening in the field, but more about the process that's around it, making that work. And so that was the time when we had that conversation, me understanding that what I need to create is the structure to be able to learn from what's happening in the field, incorporate that into engineering in a cadence that works and is repeatable and can be managed with the small team that we had. And once I understood that and just putting that into practice, it was actually a lot of fun. It was a learning experience for me, and it was very quick to see the improvements of what we were putting in at that point.
Chris:Was there a process in place before that?
Tom:No, it was ad hoc.
Chris:For context, like where was QuadLogic in its growth? Like, you know, was there a customer life cycle that was present before you fell into it?
Tom:Yeah, it was managed by putting out fires. What was happening at that time was, you know, the people in tech support were just solving the problem, hoping that R and D is going to take care. But no, R and D is focused on the next generation of the product. So there was nothing coming to support the existing product. And there were some really good engineers and tech support folks and just amazing people who were hitting close to burnout because they were just dealing with everything that was coming up and just fixing it and fixing it and fixing it, but not going beyond that to say, why is this happening in the first place?
Tom:There was this divide between engineering and post sales. At that point, the shift that I had made at QuadLogic was to say that R and D is not the only engineering for a product. And so for me to just take the ownership of that piece to say, no, there's a whole bunch of really good engineering we can do on the current product and keep R and D isolated from that so that they can focus on the next generation. That is something that I've learned and implemented very successfully in other places repeatedly, because that structure works, at least for me. You know, when you're a startup and you're starting out, the product R and D and supporting the product is all the same.
Tom:It's the same people, but when you get to a certain scale, it is good to separate that out.
Chris:From a scale perspective, in terms of the number of individuals or the number of products, when is it obvious that there does need to be a change in responsibilities? I'm imagining that it's very common for people to feel overwhelmed, to feel like the system that they are existing in is broken. So I'm wondering if there's anything that, like, given these signals, it might be time for you to reevaluate the system that you're in?
Tom:That's a good question. I don't think this is an exact science. I think that once your product hits product market fit, you should really start to consider new product development separate from managing the product. Because now your sales are ramping up and it's clear, and immediately all of the tech debt that you accrued in putting that product out starts to become apparent so quickly. And there are certain personalities that thrive in the innovation.
Tom:And if you try to suck them into solving the immediate problems, then they're not performing at their best. And the product is not performing at its best because it's just a big mismatch. So cut that loose at that point. At some point you need to realize that as an engineer, are you an innovator or are you a problem solver? And then you just need to divide the team out to say, Hey, you guys focus on the next product that's going to come out.
Tom:We'll feed you all the information. Here's what we're learning. Here are the things we're fixing and we'll fix it. And we have this timeline that the new product is going to come out in twenty four months, which means that every fix will get us to like thirty six months or so. Because by then we expect the ramp up of the next product to take over.
Nate:Yes, launch versus scale. Scaling is like a very different skill set in a lot of ways than getting the product out the door and really getting the first version out. And a lot of teams, to your point, the founding team is probably better suited in the R and D context. And you got to let the adults in the room kind of take over and scale the thing. Yep.
Tom:Yep. I personally enjoy the scaling bit more. Not that there's not that excitement of innovation, but it's also that healthy respect for both sides is important because you need to be able to feed the key points that you're learning from deploying the product to feed that into R and D very quickly, which is amazingly important so that they're building the right product.
Nate:Right. Do they have issue management and issue tracking set up? Like, they have a way of getting feedback into the product that would dictate the need for a separate engineering team just to manage that load?
Tom:No, issue tracking did not exist. Those are the things that I brought into the fray. It was, again, the company grew beyond a startup and the company had not realized that it had grown up that much. It had not realized that the product market has hit and you're now deploying to like 80% of the sub metering space in New York City. And so now you have a sales team and you're selling and things are getting out into the field, but the mindset had not shifted.
Tom:And I was part of that mindset shift. I brought in the issue tracking. I took the company through ISO 9,001. These concepts did not exist. And I was able to put them in place and make it work and educate myself in the process.
Tom:I didn't know any of that either. It was like, there's a problem to solve as an engineer. What are the tools that I have in order to solve them?
Nate:The beautiful thing about working at a startup, it's like a super collider of knowledge, you know, in a very short amount of time.
Tom:Yeah, I think my career progression has been engineering, sort of project management, deeply going into process because that's what was needed, Then understanding the limitations of each of them. So like start with engineering, understand the limits of engineering today. You need project management to be able to manage a project. Engineering doesn't solve every problem. Learn that.
Tom:Realize the limitations of being able to manage a project really well and still have limitations, which is where process comes in, because you need to be able to replicate it. And understanding process, then to realize that the limitations of process is people, and understanding people is what makes the process work, which makes the project work, which makes the engineering work. And now I'm fascinated with people. And I don't know what the next thing comes after that, but that's been sort of my journey through my career.
Chris:Very cool. On that topic of people, process, knowing what you know now about the big company cultures, I'm wondering, is there anything you've learned about the bigger companies that would have helped in the early days of some of the smaller companies? Because I think startups undervalue process and these systems for heroes and individual contributors being able to carve out that space and shine. So I'm wondering, there anything in a big company, highly dysfunctional system that can be brought to startups to help them be more efficient?
Tom:Great question. It's a very small percentage of my career that has been in this gigantic company. So I feel like I'm still learning. It's been some time, but I think some level of process is always good. It's finding that balance of where that process becomes onerous for the stage at which the startup is.
Tom:Especially at this level of scale, like Google or Microsoft or something, you have to think completely different. And it's not that you would say, oh, this one is better, that one is better. It's not better or worse. It's just that you just have to think differently when the scale is just so massive. And mean, I I'm a huge fan of the book Innovator's Dilemma, Clayton Christensen.
Tom:And he put it really well, so it's not really an original thought, but it is different when you have your product market fit and your source of revenue coming a certain way. Innovation is challenging because you cannot pick up this really small problem to solve because your system would just not allow it. Your cost basis is just so high that you cannot pick up that small piece. And everybody understands that that is where the next innovation lies. You just cannot, however badly you want to do it.
Tom:So you have to figure out different ways to innovate within the system, but it's a different type of innovation. So I think the thing that we can bring to startups is definitely some level of process. But I think the big thing to remember is actually caring for people, because I think sometimes at startups we get so obsessed with the product that we forget that it is the people that are making this. And I think at big companies, at least at Google, which is the only big company I worked at, there is that recognition that people are important and that people are in some sense fungible. Like the next challenge comes in, if you have the right people, we'll solve that next challenge as well.
Tom:That is something that I would bring back to the startups that I worked at to say, you know, let's obsess a little bit less about what we're building and understand what we're building really are these teams that can take on anything and solve a big problem.
Nate:You're in more of a people management position now, right? How do you see the way you're managing and the way that you're, I don't know, treating time off or something, I guess, previously compared to now? It can smell like this is the first time you're managing. It's just a different context of it and a different scale of it.
Tom:Yeah. I mean, this is part of maturity. So I don't think it's related to the fact that I'm at Google. I think that I would have managed it this way, whether I was at a startup at this point as well. Like really caring for the people's needs and understanding individual motivations and what is the right thing.
Tom:And like, yeah, time off or space. But I'm completely aware of the fact that I have this luxury of not having to care about, like in a startup, you're like, you have to make the next payroll. I've been through so many situations where you have to ship to make payroll. So I know that I don't have to worry about all that right now, and that's good. So you're like, Oh yeah, you want to take two weeks off?
Tom:Take two weeks off. So in some sense, it's actually creating that sense of urgency in a big company is the challenge, which comes very naturally in a startup because the urgency is real. But I think something that I've gained throughout my career that is not dependent on whether we're in a big company or a small company is just kindness and being kind to not just the team that you're working with, but to your peers, to your partners. In the startup ecosystem, it's not just you, it is a big ecosystem of partners that is helping you succeed. And equally as important, your competitors.
Tom:Be kind to them. They're going through the same kind of pains and trying to solve problems. Sometimes it feels like a zero sum game, but in a larger context, you sometimes go work with competitor and it's a good thing. So be kind to all of the people in the ecosystem.
Nate:Yeah. I've been thinking about this a lot lately and I like that you're describing it as an ecosystem, right? Because you're only really competitors when you think of it in terms of a market, right? But an ecosystem has a lot of different players in it going after a lot of the same pie. The saying of what high tides lift all boats kind cliche, but it's also not wrong when it comes to a business or an economic environment.
Nate:So I think that's a really cool point.
Tom:Yeah. Yeah, I'm with you. Definitely, I'm only now getting to appreciate all of this and finding myself in a place where you know, my identity has been hardware in some sense. My identity has been being a hardware engineer, like knowing each different scale throughout my career to this point where I have no hardware team or product that I manage. And so it has really challenged my identity and understanding that what that whole journey through hardware led me to in those stages was to get to be a people person and to be able to put teams together, create high functioning teams, that is the value that I bring.
Chris:Yeah, I would say going back to Sidewalk, you know, Sidewalk Labs was one of the three companies inside of Intersection. There was Intersection, there was Link NYC, and then there was Sidewalk Labs, right? So this fusion of really smart people trying to tackle, call it big city problem. But I'm curious, going back to your first week, of what was your first impression of what you were walking into?
Tom:Very, very smart people. That was the first impression through every conversation I had right from the beginning. Just exceptionally smart people, also very mission driven. I guess I've been in this, I guess I've beaten down by a lot of the startup y stuff, especially when I was in the real startup world where you're making payroll and going after VCs. It was a whole thing where idealism got into the background more and more, and you're just sort of in a survival mode.
Tom:To get to a place where there's very, very smart people who really care about what we're trying to do, which is to radically improve urban life for all. The whole concept of equity, which is very important, and how to actually make cities better. The premise behind Sidewalk Labs was that urbanists and technologists think differently and act differently and usually sit in different rooms. So we don't actually work together to solve problems. Both the sides think that they have the right solution and are not open to listening to the other side.
Tom:I mean, technologists were just like, let's go out, move fast and break things. And urbanists are like, no, you plan a lot because there are actual people living in these spaces. You don't go out and break things. And so the idea was, how do we find that compromise? And if you get really smart urbanists and really smart technologists together, we can just solve problems.
Tom:So that's the premise. It went through many different iterations of trying many different things, maybe as an incubator to start companies and actually incubated a bunch of companies. That's where we were talking about the three sort of sharing the space and all that. But it also created companies like Replica and Core that got spun off as like fairly successful individual entities, to working in Toronto, a, Waterfront Toronto was a big project for Sidewalk Labs and this- Oh, that's right. This sort of That ideal
Chris:was massive. Yeah, it was massive.
Tom:So that became the next thing to say, let's showcase how an ideal city could function and then use that to say, this is how technology could enhance life in cities. But this all happened before I joined. By the time I joined, it was to say, can we go back to that incubation level where it's like, we have products, we have ideas. This intersection of working with urbanists means that we have unique insight into solving big problems. Can we productize these things?
Tom:And that was definitely exciting for me.
Chris:What were some of the trade offs that you had to make as a leader at Sidewalk?
Tom:So a few things I'd learned. I'd botched this so many times that I've shown up as a leader at a place. And I'm just like, oh, this is how we're supposed to do. And I think by the time I got to Sidewalk Labs, at least I had the maturity to stay quiet and not talk because I realize that I know nothing about this and that everybody in this room is smarter than I am about this topic. And my goal is not to show what I am able to do, but to be able to help this team function better than it is functioning right now.
Tom:So, but being quiet, and I said, Invite me to every meeting that you have, but I'm not going to say anything. And I deliberately did that for, I think, two or three weeks until my team actually said, No, actually we would like to hear from you about what you think. So being in those rooms, I think the part that I picked up quickly was that for various reasons, we were going ahead with a product that was not quite ready for prime time. This instinct I've honed over time, as you can see from Broadband Maritime, from QuadLogic, it's the same story. The product is not quite there yet.
Tom:It has enough things to fix, but you're scaling it faster than it's ready to scale. So once I was ready to speak out, the choice that I had to make was, do we now just jump in and say, how can we fix this problem and continue with the same growth that we had projected? I was managing P and L at that time, so had revenue targets, we had goals, we had investors at stake. There were a lot of things at stake. Or is it time to say, We have to take a break?
Tom:So I don't know if that qualifies as quite a trade off, but
Chris:Well, I think there is a trade off. There's continue on the path and trajectory. At what cost? Or is there another path? And what is that code?
Tom:Yeah. I think that to me at that point, and this is something that I thought about recently, is that I think career is some, like first half of your career is honing your instincts, where you make a lot of mistakes and you learn from them. And the second half of your career is trusting those instincts. And so my instincts are saying, we need to stop the manufacture of a million more of these things. And I was like, can I trust that enough?
Tom:Because what that means is going into a boardroom and saying, you're not going to hit the revenue targets you were looking to hit. We're going to the manufacturer and saying, you remember all of those parts that you ordered because we ordered a million of those? Those all go to waste. And going to say, your P and L is going to be shot this year because you accrued all of these costs and you're not going to make any money. And these are all new colleagues.
Tom:I don't know these people. And to go in and say, the right thing to do is to just stop right now Because building more of this is just creating more problems for us to solve later. And I think the team knew this. They just didn't have a spokesperson to say this out loud. So for me, being able to step up to the room and say, hey, we're actually going to stop this was scary, but it actually garnered a lot of respect for me at that point to say, okay, this, and I think our CEO, Dan Docktruff, at that time said, do you trust yourself to do this because this is a big deal?
Tom:We have to go to investors and say Things are not happening. I said, I am very sure this is the right thing to do. I said, Okay, that's what we're doing.
Chris:I think that dovetails actually nicely into, you know, Google being predominantly like a software first organization, or at least that's what they're thought of as. I know through acquisition, they've significantly upped their game, both on the consumer side, but also on the B2B side. So going from very hardware centric roles, where hardware is an element of the product, to kind of where you are now. I'm curious for others to know kind of that journey and why hardware today isn't, call it, like a first class citizen in the solution space that you're going after?
Tom:So this is where these are my opinions and not Google's because I am I mean, I don't think Google has a public stance on where it stands on hardware. This is very much my little corner of the world here that I can talk about. But coming into Google, I have to learn to think completely differently. So all of my training before coming to Google, even at Sidewalk Labs, was that there is a problem out there to be solved. You have some piece of technology.
Tom:You can build the rest of the technology. You have a team. Now, what is the most efficient way to solve it? What is the MVP? What is the thing?
Tom:And being in the hardware space for so long, you learn a lot of humility, and you understand the amount of time that it takes to solve certain problems. But you go along in those directions. I love the fact that this podcast is called Tradeoffs because I feel like uniquely hardware engineers have to make these trade offs and also trust instincts a lot more than others because you don't get the luxury of testing things out. Yes, there's a concept of, oh, you can build a mock up, but really you're going on gut instincts on a lot of these things to say, yeah, we're going to pour two years into this and it's going to look like this and the market will still be there when we get there or the market will be there when we get there. That is the mentality that I sort of imbibed and grew up with, was that you go out and there's enough of a market to solve this problem.
Tom:You come into Google, that market is minuscule. That's the money that Google makes in a few minutes at some point. So that's not the value. The value here is a massive captive audience, a massive brand, and essentially a very large lever that even if you shift it a little bit, you can have a very outsized impact out there. So that's a different way of thinking about product development for me than I have had in the past.
Tom:So for a few months, was business as usual. We're continuing with the customers that we had and we were building. But it was very quick for me to understand that to be successful at Google, we have to leverage what we provide, marry that with what Google is good at, and be able to show value. So the whole team was built around Pebble, the piece of hardware. But coming into Google, what became apparent to me was think of the hardware as a piece towards solving a problem.
Tom:Hardware is not hardware for hardware's sake. What is the problem we're looking to solve? And how does hardware solve that problem? That changed in scale and scope within Google. So then the value is like, how do we change the way parking is done in the world?
Tom:And you don't get to think like that when you're at a startup. But you can think like that at Google. You're like, can we just completely upend the way parking is done? What kind of sensing would be required to do that? And so the first pivot we did once we joined Google was to say, we're going to go after working with cities, which we were not doing in the past, and actually lower the emphasis on hardware because we had proven what the hardware could do and bring to the market.
Tom:But to actually do it right, we have to go back to the drawing board. It was never designed for scale. And the scale now at Google is just way bigger than what we had imagined. So I wanted to give the hardware engineering team the space to go back so that we should work on innovation. We're going to focus on solving a problem with cities with loading zones.
Tom:So that was the first pivot we made. And the thing with big companies is also that scalability is very important. The story has to scale, because at startups, you could survive on a small level of scaling. But at Google, you at least need to have the story that you can scale into very, very big, very quickly. And the working with cities, actually, essentially signing contracts with cities is just a slow process, and you couldn't scale from like one, two, and then jump to 100.
Tom:It's a slow prodding process. So that was also not the right fit. So we had the second pivot where we completely walked away from hardware, and moved towards a solution where, you know, we're in the sustainability organization, and our goal is to reduce the amount of carbon in the environment, and our focus is on transportation. So what can we do working with cities in order to curb the amount of CO2 emitted in cities by helping cities change policy? Very different world from anywhere that I have been in the past, but I feel comfortable, mainly because, the team is awesome and they know exactly what needs to be done here.
Tom:And it's about building relationships within the organization, outside the organization, setting up the structures where everybody can thrive. So sadly we walked away from hardware, but I think the team is in a good place. We didn't lose a single team member through this process.
Chris:That's awesome. In wrapping this up, are you hiring?
Tom:Do you have anything to promote? No, no Anything? No plugs really. No. Google's a great place to work.
Tom:My team's not hiring at the moment, but I'm sure there are postings out there. But I mean, the only thing I would add is that if anybody out there wants to talk to me about any of these things, life experiences, I have been blessed with really good mentors and advisors, including you, Chris. And the least I can do is pay that forward. And so I would be happy to talk to anybody about life, work, career, hardware, software. Not that I know any of the answers, but I'm happy to chat and work through those things together.
Nate:Cool. You got perspective at the very least.
Tom:I've never had anybody so interested in my life, so thank you for that. It was very therapeutic to just talk about myself. You
Chris:know what? That's what we
Nate:thought initially for this, to be like, you know, hardware person therapy.
Tom:Thank you, Tom.
Nate:Thank you. Thank you, Brian.
Tom:Thank you, Nate. Thank you, Chris. I really appreciate this.
Chris:TRADEOFFS is hosted and produced by Chris Rill and Nate Padgett. Editing done by the illustrious Alex Michael. Our logo is designed by the talented pixel alchemist, Tanya Shika. If you'd to be
Chris:a guest on the show, reach out to us on our
Chris:website at tradeoffs.fm.
