Google Director Spills the Beans on Working for a Mission Driven Vs. a Business Driven Organization

The Developer Nation Broadcast brought to you by the Developer Nation Community is a podcast that aspires to shed light on the journey of developers that have set the bar high by pursuing impressive career paths. In this first episode, we welcomed Lars Bergstrom, currently Director of Engineering at Google, following an impressive career in companies like Mozilla and Microsoft. Lars is navigating us through his career path, sharing his experience and offering helpful advice and inspiration to software developers as they plan their coding journey.

Ayan 

I'm really excited to have you here. We just started this podcast and having you as one of the few initial guests is really amazing. I can feel right away. So, thank you for doing this. Tell me about what things you have been up to and a small introduction about you and what you have been currently doing.

Lars 

Thanks for the opportunity to be the first speaker here. So, My name is Lars, I'm Director of Engineering here at Android and I work on basically supporting the teams that build the compilers, the tools, and the runtimes that you use to both build the Android operating system, as well as build applications that target Android. So, I've been here for a little more than two years now, officially, and it's been a great new gig to get started on.

Ayan 

Oh, that's amazing. You have worked with some fantastic organizations and companies and amazing projects. You're working for Google, but you have spent many years at Mozilla. 

What would you say is different in the working style of entirely open source organizations like Mozilla versus Google, which does have a fair bit of open source in every project that they have been doing? How do you feel working for Mozilla and working for a company like Google differ?

Lars 

Yeah, it's really interesting, because Mozilla was, or is, also not just a corporation, but it's actually a nonprofit. So, it's a very mission driven organization, where, you know, Google is definitely a business. And we both work on open-source projects, but with kind of very different goals and very different work styles. 

Right at Mozilla, one of the sort of hallmarks, there was radical transparency and openness, in a way that I was not used to, because I'd been at Microsoft before that as well. And so, the idea that not only would the code be open source, but the plans were open-source, our bugs were open, what companies were working with our long-term goals, sort of even how the business made money was very open.

And that kind of transparency was really interesting and difficult, you know, was a challenge for me, because you get feedback very early on in the process, right, you're just sort of throwing thoughts and ideas around thinking maybe we'll change it like this, maybe we'll change it like that. 

And a lot of the private iteration you usually do in private companies is actually out in public, for people who you know, and even after 20 years in the industry, you never get rid of that fear of like, oh, my gosh, is someone going to notice that actually, I'm an idiot, that I was wrong here that I made some horrible mistake and getting comfortable with the idea that you're going to be doing this work in public, and you're going to get feedback from a lot of people.

And, you know, the big nice thing about that is that it builds trust, it brought people in early, they felt like they had been part of the conversation. They were part of the journey. And even if they disagreed with where you went, at the end with the final decisions for the product, they felt like at least they were part of that conversation and journey. 

And it's very different at big companies. And you have a variety of projects, as you mentioned at Google, I'm fortunate to work on Android where most of what we do is open source, but it has a very different feel, right? Mozilla is trying to get a lot of public contributors from individual developers working on open-source projects to contribute. 

With Android, we want to do that. But really, the key thing is we have over 1200 vendors who build on Android, who want to build commercial products, and they want to participate; they want to contribute, but they don't necessarily want to share their long-term product plans publicly with it. And so it's a very different structure of the organization where you're still open source and you still want to contribute you do as much as you can in public, but you also have to respect the privacy of these companies that are trying to build new products and market and many of these companies are competing with one another.

We as Google want to support all of them, and try to encourage them, like; Hey, I know you're making these changes, but could you put it upstream, like, we think this will be beneficial for the whole ecosystem, and it would be less work for you if you did that. 

And so they both, even open source projects, there's just so many different flavours of them. And as you said, they're different at different companies. And it's been an interesting journey for me to get to learn about how this works, and how you encourage participation, because that's the key part of open source, right, you're making an open source, there are some discoverability aspects, but really, you want participation, you want other people to come with you on this journey, to build products. And how you do that, and how you structure it to make that happen, is really interesting based on your business's goals. 

Ayan 

I'm sure that working on the Android operating system, you still want contributors, like you mentioned, you still want people to have that sense of contribution to an open source project, but at the same time, you still want features to be part of the mainline or upstream, and they really would make some value to the operating system. So, is it something along those lines?

Lars 

Yeah, and you want to be respectful of the pace with which people can bring these products to market or adapt these changes, if they're, in an open source project, you might just push the change out and say; “Okay, we're changing the new API, there's going to be new requirements or something else, and we're just going to land it in the tree, and we're going to make this happen”. 

And there's much more of a conversation based on product or business needs; this might not be the most important feature, our vendor ecosystem might want to do the work, but they might not be able to do it for one year. And so, can we make it optional for a bit? How long do we need to keep the old version around? How do we migrate people? 

And it's really thinking about that story of evolution. And not just technically, how can we do it, but how can we ensure that our vendors can go with it, that our application developers can pick it up in time? How does that whole story work together, and that can be very different from open source projects where you just land a new API change, and as long as it isn't too breaking, you can just sort of keep rolling forward with it. It's much more like a consortium there. And then to be clear, we still get the feedback from our vendor partners as well, where they'll say, Lars, that's a terrible idea. Like we absolutely can't do that, what are you thinking, but it happens in private, at least.

Ayan 

So, going a little deeper into your role at the Android project and Google, in general. So, what would you say is like your day-to-day roles? Are you still involved in programming? Or is it more like decision-making and project management? And just in general, like, what sort of things have been doing lately for Android? And what does your usual day in a workload look like in terms of technicality when it comes to managing such projects?

Lars 

Yeah. So unfortunately, in my role, I don't get to read a lot of code anymore. I try to take some time, usually around the new year to go back; I'll do advent of code, I'll try to do a commit or two in the project because I think it's important at all levels of engineering management to really understand the tools that your team is working with. And not just the language, but also the CI system. 

What do they have to do when they check in? What tests get run? What do the portals look like? What happens when things break? How do they track down these bugs, it's very easy, particularly as you get an engineer, to have this kind of memory of how everything was, 5 or 10 years ago, back in the days when you were slinging code, and that can lead to this disconnect between you and the team where you think it's super easy to get a change. 

And then the team says like, no, you've forgotten their privacy reviews, there are 2.2 million tests that run before you can check in your first change. And so, I do try to do that, but to be clear, I don't go on any piece of code, my name is not on the owners' file, and I don't get to look in the headers there. 

Most of my day-to-day work is really focused around either management work, technical work or strategy. So, on the management side, I'm a people manager. This is why I'm in the role. I often joke about management, I can fix anything else, like everything is tactics and management, they have to like seeing people grow, and you have to be personally invested in helping people get better at their jobs, seeing them grow, seeing them possibly go far beyond you, and get into new roles that are beyond where you've gone and that takes up a lot of my time. 

Whether it's in coaching people, whether it's in hiring, whether it's in dealing with organizational structure and making sure that people have a good career path and everyone's being well supported. That takes up a good portion of my time. 

My job as a manager will really depend on the time of the year for where we're kind of at in the product cycle. And then finally, the third bit I mentioned was strategic, which is where we're trying to have multi-year initiatives. It's very easy to just get caught up in the one year of Android and everything else is the infinite future. But there are some things that I work on, like adding support for new kinds of hardware, or new hardware features, or driving new programming language adoption or new tools. And those can take 2, 3, 5, or even 10 years. And so, my job is making sure that we don't forget about them, that we continue to march them along, that we're making progress every year. So that when it's ready to ship, we're ready as a platform for its adoption.

Ayan 

I’m sure you're doing a lot of operating system kernel and middleware stuff. But I just want to understand from your perspective, when do you think a project gets mature enough so it can start having different projects that support itself? For example, like in iOS, the application development used to happen on Swift, and it was Java for Android for a very long time. But the application developers and application flux were so high that they wanted to make it easier. So, iOS moved to Swift and Android moved to Kotlin.

Lars 

Yes, so I've been through many language changes over the years, right. I was at Microsoft during the .net revolution, where C sharp came out. Now I'm going through Java to Kotlin, I'm going through a lot of the C++ to Rust. And of course, on the website, the evolution that's happened over there has been tremendous. And I think when you look at it, it's not about language features, right? It's coming back to sort of the analogy we're making about how our users use the application, it's about the demands changing for what has to be done with an application. 

So whether that's with Swift, there was also a new UI framework that was coming out that Swift happened to be much better at programming. And so while Swift is a great language, and in many ways, you can say it's better than Objective C, if there hadn't also been a corresponding set of framework changes that were much easier to express and faster to author, I don't know that we've seen would have seen the same pickup of Swift that we have. 

And it's the same thing for Kotlin with jetpack compose. Jetpack compose plus Kotlin is kind of the magic; it's not just Kotlin, although some of the things with nullability checking and async. And a lot of the features that really have not yet made it to Java, that innovation has really landed there and driven the adoption of it. And we see it with Rust as well that, just moving from C++ to Rust, people wouldn't have done it, if it weren't for the changing security landscape and some of the dynamics there. 

So there has to be this kind of convergence, like a language on its own really can't win on the basis of better places to put the semicolons or the curly braces or syntactic sugar, those things are easy enough to backport into previous languages, backwards compatibility accepted, there has to be some other thing that's tied to it, that's going to solve some problem that developers are facing or make them more productive that really at least when I've seen languages be successful in my career that's really been it, is that the language had a name, but there was some set of tooling that came along with it that made developers more productive, that solve real problems for them that caused that or that drove that change across the ecosystem.

There is more in this interview - you can check out the full podcast here.