Bobby: On this episode I talked to Bjorn Freeman-Benson. Bjorn was most recently the CTO of InVision, which aside from being a breakout hit product, also uses a completely distributed model for its 800-plus employees. A truly unique environment to learn from. Prior to InVision, Bjorn was the SVP of engineering at New Relic, where he grew the engineering organization from three to 300 engineers through the IPO.
Bjorn has also spent time at both Microsoft and Amazon, and it's interesting to hear his take on the engineering cultures at both.
I'm sitting across the table here with my guest looking out at downtown San Francisco with an unending stream of cranes and construction. But without further ado, I'd like my guest to go ahead and introduce himself.
Bjorn: Hi, I'm Bjorn Freeman-Benson and I have done a wide variety of software companies over the years, including open source and closed source SaaS companies. I have some interesting claims to fame in my past, including being one of the national winners of a Baskin Robbins ice cream dessert creation contest.
Bobby: And that's definitely one of the key reasons why you came here, Bjorn! Thank you so much for coming. I think a lot of folks don't know, but Bjorn's based in Portland and he flew down for this podcast and I'm sincerely grateful. I'm also grateful because I think this might be my mom's favorite podcast of any of the ones I've done.
Growing up she was a fan of Bjorn Borg, the tennis player, and also the band Abba that has a singer called Bjorn. So I feel that the moment she'll hear your name is Bjorn. This is like gold. Your, this is gonna be a hit.
Bjorn: And when I was young, people couldn't pronounce my name cuz there were no Bjorns. And then Bjorn Borg became famous and thank goodness people learned how to pronounce the name. And now people can actually say, oh, hi Bjorn.
Bobby: Yes. And ask you about how you won those five Wimbledon titles.
Bjorn: And I can tell them in great detail.
Bobby: Thank you. Thank you so much. I feel that when we're talking about someone's journey it helps to start in the beginning.
I was doing some research for this for this episode and looks like you studied at the University of Washington and you studied computer science. So the first question that comes to mind is what made you when you went and did that is that a major you knew you were gonna do before you even started, or is that something you discovered once you got there?
Bjorn: Yeah, I was into computers even when I was in middle school. I actually built some of the early computers that were out there and I've just been into computers all along. And so then when I finally made it to university, I was like, yes, that's what I'm going to do. And I immediately set off to study computer science, and I got all of my degrees from the University of Washington.
Bobby: What made you keep going past your undergraduate studies instead of just starting to work after you got your bachelor's?
Bjorn: Yeah. I love this stuff. I was just having a great time, university of Washington at that time and I'm sure still is a really nice school. A lot of smart people there and interesting things.
And so I just love doing that and I wanted to keep doing it. The other thing is that I was considering being a professor. In fact, I was for a number of years before I went back to being a commercial engineer. And I realized that in order to be a professor, you have to have a PhD. And if I was gonna do that, I needed to do that before I made any money because if I ever started making money, I would never go back and get my PhD.
Bobby: It's like a self-limiting thing. So one of the things I really like about Bjorn is like me, he really shares a kinship with humor and that you can see that in a lot of things that he does professionally. But I was looking, and you can all look at his LinkedIn profile and in it he says, from years 1991 to 2009, I did many interesting things in many interesting places and leaves it at that for your imagination.
So I thought since we have you here, you could maybe embellish just a tad on some of those and some of those interesting places that maybe our listeners would know about and relate to.
Bjorn: I worked for a wide variety of companies over the years and like I said I was a professor of computer science for a while and loved doing that until the university politics dis and I disagreed about the future and let's see, and then I worked for startups that both succeeded and failed.
I worked for a very interesting startup that was building reconfigurable hardware for cell phones. So the basic idea is that in your cell phone you could either have a general purpose processor with lots of transistors in every clock cycle. The transistors change state and they use up a lot of power to do that.
But you can compute any algorithm or you can have special purpose chips that do things like filtering functions and searching for signals in the air, but they use up a lot of silicon even though they're very power efficient. So we had designed a piece of silicon that could run about five of the standard algorithms.
So it was not completely general purpose, but also not completely spec one purpose. And then the idea was, How much could you compile onto that chip from writing C code? So my part in that particular startup was writing the c compiler a team of people, and we all write the C compiler so that you could write a normal C program or c plus program, and then it would extract out the algorithms that would run on the special purpose chip and then take all the rest of them and run 'em on the embedded arm.
That was a really cool project. Too bad the company didn't go anywhere, but it was a really cool project. The increase in battery technology basically made that unnecessary Yeah, in the future. Yeah. Interesting. I've worked at a variety of companies, big and small. Worked actually at Microsoft for a while. Worked at IBM for a while. Big companies, worked at teeny companies.
Bobby: What era were you at Microsoft?
Bjorn: Let's see. I'm trying to remember. That was in the ‘90s, so I think it was in the late ‘90s. So Bill Gates was still CEO.
Bobby: Yep. Got it. And I think you'd mentioned, I think there that you also had worked at Amazon. Is that right?
Bjorn: Yeah, so a after my stint at on Microsoft, I went and worked at Amazon back when they were just transitioning from books to books and other things. So that was many millennia ago.
Bobby: So is it true that they at Amazon they when they started the company, there was this culture of being frugal and that there were these wood-like desks that you would get from I think Home Depot and then over time to maintain that culture they still had those desks. Were those desks a thing when you were there?
Bjorn: Oh, definitely. Yeah. So one of the, one of the great things about that company, and there, there are a lot of great things about that company, but one of the great things about that company is they really understood the value of money.
And so every company I've worked at has had a guiding principle behind it. And the one at Amazon was other people's money. And so one of the things that Bezos just really drilled into everybody was, how do you grow the business using other people's money? So for example, the reason that he started out with books, at least this was the story I was told, could actually be true is that you could order the books from the from the middleman, whatever they're called. The wholesaler. But not pay for them for 60 days. And so because of his computerized ordering systems, somebody would order online, he would order them from the wholesaler, ship it to the customer. The customer would have the book for 58 days and Bezos would have the money, or Amazon would have the money for 58 days before they had to pay the wholesaler.
And so they made money on every sale that they made. It's just part of this. And so one of the lessons that I learned out of Amazon is the value of capital and other people's money and how to take the best advantage of that when you're building a business.
Bobby: Yeah. They're, and they still continue to maintain that culture, I think, and it's taken to super great heights and Jeff himself.
Just exploring those two behemoth companies both in Seattle, Microsoft and Amazon. What are some things that struck you about how those cultures were different, the engineering cultures?
Bjorn: Oh let's see. So Microsoft was a much older company at the time than Amazon was. And so Amazon was very much a startup: Let's just do whatever we can to get things done. And in fact, when I joined, they, like I said, had just moved from books to books and music and books and music and toys. And the way they got that done at the time was they just cloned the entire stack.
And so the bookstore was a complete copy of the code. The music store was a complete copy of the code, and the toy store was a complete copy of the code, which was expedient, but of course, increasing technical debt like there's no tomorrow, right? Whereas Microsoft at the time was a much more mature company and had a very solid engineering process behind it.
And even then, they were doing some amazing things around gathering crash reports from all of their tools out there because they had so many users they could look at all that data and figure out where the problems were in the code, in ways that nobody else could. And they were taking advantage of that.
But that was a much more mature engineering process than Amazon had at the time. Now, Amazon it's what been 20 years since then. And Amazon is an amazing engineering culture of its own now.
Bobby: And so this was when you were at Amazon. Was AWS a thing?
Bjorn: No, in fact AWS started just about the time I left. And in, in fact, it, at the beginning, the Amazon code base was just one giant c plus program. And so they hadn't, you hadn't even moved to services.
Bobby: Interesting. So when you were working at Amazon, do you remember in that Seattle area for recruiting, what was going on in terms of what types of candidates or what types of aspirations people were going to Microsoft for versus going to Amazon for?
Bjorn: At the time, everybody was going to Microsoft. Even then everybody was going to Microsoft. Amazon was having difficulty recruiting people cuz it was a tiny startup with no future, right?
Of course how wrong we were then. But, the only sort of people who would go and work for a startup, or the same sort of people who go to work for startups today are people who are willing to take a greater risk. The people who wanted a more stable corporate software life, went to Microsoft. Now you could go to any one of those places.
Bobby: Do you think that the, these years later, if you were to think back and—you're still very plugged into the Pacific Northwest tech scene. Has it flipped where everyone is going to Amazon now?
Bjorn: Oh yeah. Everybody's going to Amazon or Google.
Bobby: I guess Google has a big presence up in the Pacific Northwest.
Bjorn: Yeah. Google in Seattle has three offices, maybe four offices now, and then they're building one, another one right next to Amazon, which I think is hilarious. It's their Google Cloud office, and it's literally across the street from Amazon.
Bobby: Can't imagine why. Very interesting. Okay take us to that moment when you are, tell us how you get to the start line at New Relic, how that comes
Bjorn: about. Yeah, so I had, like I said, this interesting career of working for a number of different places. And I had worked my way up from being just a software engineer.
And we all started there being a junior software engineer. And I'd worked my way up to being a tech lead and then being a manager of a few people and manager of a few more people. And by the time, for instance, I got to that hardware startup. I was a director and I had people who had people, and so on.
And I realized as I was moving my way up through the management chain and having larger and larger projects that I had reached the limit of my ability to manage with the particular management style that I had been using, which is a very commanding control style. It's the one that we all learn if we watch television shows or something where the guy comes into the room and says, now people, everybody's gonna do X, and so on.
And of course, without any formal management training, that's what I had picked up as the way to do things. And I'm a very gung-ho guy. And so of course I'd done that and I reached the limit of it, with the size team that I was capable of running with that style. And of course, eventually you irritate people enough with that style that you're not as effective as you could be.
And so I saw that in myself and I said, if I'm really gonna be more successful in software and software management, I need to learn to manage through indirection, through delegation and less through command and control. And so at that time the Eclipse Foundation was just getting started and Eclipse being a giant open source project has no command and control structure at all.
And so I took a job with the Eclipse Foundation running the Eclipse community. So I was responsible in some sense for the annual releases of Eclipse but not. I didn't write the code. I coordinated all of the various teams that did write the code. Lots of smart people wrote the code, so I'm not trying to take anything away from them or all the things that they did.
My job was to coordinate all those pieces. So in some sense you could say I had 700 engineers working for me, but of course none of them worked for me. I could only affect them by influence.
Bobby: And for some people who may not know, just to catch people up, tell a little bit what the Eclipse Foundation was.
Bjorn: The Eclipse Foundation, which still exists, manages the Eclipse open source projects. The biggest one is the Eclipse Java, IDE. Which was an outgrowth of some work that we had done for IBM in the in previous years. And so it's, it's still quite a popular IDE, although I happen to use Net Brains instead, but it's out there and people still use it and it was quite significant.
Anyway, so we had something like 700 volunteer contributors who were either vol complete volunteers or they worked for other companies, so they actually had bosses. And so my job was to corral all of this and get us to the finish line every year for our annual releases.
Bobby: And it was probably at the time that you were doing it, I would guess, top five open source project behind Linux.
And I can't think of ones that were much bigger at the time.
Bjorn: Yeah. And very significant too. It fundamentally changed the IDE marketplace. And so it was great. And through that experience, I believe that I learned how to manage more effectively without telling people what to do.
And so when I'd gotten good at that, I was looking around for what to do next. And a friend of mine in Portland had just joined this little startup New Relic. And at the time New Relic had I'm guessing on the numbers here, that I think it was 12 people. And the reason that's a good number is cuz it makes me number 13.
But anyway, it's about that size. It might have been 14 people and I was number 15. But anyway, a very small little company. And it had started in San Francisco. Lou Cirne the CEO had started it in San Francisco and had never intended to have a Portland office. But he was having trouble finding a developer to join the effort.
And he'd known Bill from a previous company and Bill was in Portland, said, oh, I'll do it, but I'm living in Portland. And then little by little we gathered enough people in Portland, we decided we were just gonna build all of engineering in Portland. And so we ended up with all of engineering in Portland and all of the rest of the company in San Francisco.
Bobby: And so what what position did you join them in as employee number 13?
Bjorn: Yeah, I joined as the first engineering manager. There were three engineers and then me. So that's silly that they needed a manager at that point, but we were already anticipating growing to a much larger size.
Bobby: So the three other three engineers were in Portland? Yeah. Okay. Interesting. Talk a little bit about we should first just for listeners who don't know what, at that time, what did New Relic do?
Bjorn: Yeah, so New Relic was a Ruby Performance monitoring tool. And so the idea is if you'd written your application in Ruby on Rails and you wanted to get application performance metrics about it the New Relic plugin plugged into that, instrumented all the Ruby code automatically, and then gave you data about how your application was running.
Bobby: So when you got there, had they, did they have a shipping product that customers were paying for?
Bjorn: Yeah, we had just gotten our first set of revenue. So I didn't join pre-revenue, I joined pre any significant revenue.
Bobby: Do you remember what round of funding they were at by the time you got there? I don't remember what round of funding it was?
Bjorn: So I was there for seven years and I grew that engineer organization from three to 300 people. And and during that time we went through an IPO and I got the thrill of standing on Wall Street and, Lou rang the bell and was all very cool with the IPO and so on.
Bobby: So I think that the thing that a lot of listeners would love to ask you if they were here is trying to drill into trying to break up that journey from, managing a team of three to 300, into a couple of like milestones in terms of size, perhaps say, three to 20, then to 200 and the different challenges along the way so we can do this in real time since.
I'm sure it's difficult to do that, but maybe give us some thoughts on the major milestones.
Bjorn: So the interesting thing about this is at the rate that we were growing, we were basically doubling every year. The company was doubling every year. Engineering was sometimes doubling every year, sometimes a little less than doubling every year, but at doubling every year, that effectively means that you have a different job every year.
So if you break that up, it's, there was what it was like in year one and there was what it was like in year two and what it was like in year three and so on, and it was effectively a different job. The job of managing three, four engineers. I wrote a lot of code. And then, the next year that got big enough that we started having teams that had maybe their own managers, or at least their own technical leaders, right?
And then, the next year there were a bunch of those people. And then the next year, I had started adding a second layer of management in there, and so on as it went up. And so every year, I'd have to sit down and think about next year I need to find by this time next year, I need to find somebody to do the job I'm doing today so that I can take the next job up the chain. So I was constantly out looking for not only how do you build this organization with all these great engineers who were doing fantastic work, but how do I find people to take the job that I'm currently doing and enjoying so that I can take another one.
Bobby: In that early phase growth at what point, let's say in terms of roughly number of engineers, did you dramatically stop writing code or doing coding on a day-to-day basis?
Bjorn: Yeah. I don't remember. I do remember that we needed we had just done the ruby from the beginning and then we had, Saxon had done the Java agent and was doing the net agent, and we needed a PHP agent.
And to write the PHP agent, you had to write a bunch of C code, which I love doing. So I just wrote the PHP agent during the day and did my management job during the evenings. And that, that was a, that was your typical startup, a hundred hour week sort of period of time. Wow. And after that was over, I had hired a couple engineers to do the coding that I was doing, and I don't think I wrote any significant code after that time, but that was, maybe 30 or 40 engineers by then.
Bobby: I think you laid it out quite nicely. You started off with managing three engineers, more engineers, then you started managing managers, and then there was two levels of managers eventually that you had to manage. How many of those leadership situations had you experienced in the past?
Bjorn: Prior to New Relic, I had been a director, so I'd been a second level manager. I had, I was a director, I had managers under me and they had engineers under them. Okay. That was the largest organization I had run before that. And so then at New Relic, I ended up with three layers of management by the time I left.
Bobby: Do you remember at which place you were given the first time opportunity to be a manager and the first time opportunity to be a manager of managers?
Bjorn: So the first time I was a manager was way back in the past. When I worked for a company called Data IO that was building proms programmers back in the days when you had proms.
Bobby: And then when did you get the opportunity to be a manager to managers? Cause that's a step function difference in kind of management complexity and what
Bjorn: you're doing. Yeah. I went from, just managing to the next level would call it one and a half layers where I had team leads who had teams, but they weren't managers of those teams.
So the difference is that they were responsible for the day-to-day activities, but they weren't responsible for writing reviews and doing that sort of thing. So it's a half step in management, and I think that was a good thing along the way because I didn't have to go just from being a first level manager to a second level manager all at once.
And there I worked for a company called Object Technology or National. When I had that I had about, It's about 20 people working for me through that mechanism.
Bobby: So what's always interesting to me is how folks have picked up the skills to, to do those jobs that you did on that say, new Relic journey.
And it sounds like you had these opportunities before, but were there any of those prior experiences where you felt like you got better or useful education or training to, on how to do this job versus just learning
Bjorn: on the job? Yeah that's one of the the disappointments in my career is that I haven't had anybody who helped me get better at the job all along.
And so all of the things that I did, I had to self train on and self introspect and so on. And so I've been slower about making that journey than I would've liked. If I'd had assistance along the way. And I've made more mistakes along the way, which, is both personally disappointing for making mistakes and I also regret all the mistakes I made that.
That caused people pain along the way. Because I was learning along the way, right? As we all do. As we all do. But so as a consequence, I've tried very hard with all the people who worked for me to provide them with that training that I didn't get. And so I worked very hard with all of the managers and directors and eventually VPs who worked for me to provide that extra level of training.
For example, at New Relic we had an annual, I call it annual technical conference. We got all the engineers together once a year and talked about what we were doing and what we were planning to do and so on. And that first year with three or four people was really easy. We just had it in the meeting room.
The second year we had to have it in the large meeting room, by the end, we were renting a particular property in Portland called Edgefield, which is a former either poor house or insane asylum. I don't know which story you go by. And we had hundreds and hundreds of people attending our conference.
But one of the things along that journey is that as we got more and more people in that annual conference, it occurred to me that we were gonna spend a lot of money, both in terms of time and mostly lost opportunity costs to get people together. And so it needed to be a really good conference, not just your average technical conference where you get together, but we had to make it worthwhile.
To spend the time doing that instead of building the product that we needed to succeed, right? And so to that end, I worked on making sure that everybody knew how to give a good technical presentation, who was gonna give one. And any one of the people who worked at New Relic at the time, and they still do this even after I'm gone, they do lots and lots of practice talks.
You had to do at least two, three, or four practice talks of your full talk before the event itself, so that when the event came around, every one of the people who was on stage speaking was a worthwhile, valid, useful presentation about, they knew the technical material. That wasn't the question.
The question was how can you present it? Nobody teaches you how to present these things as an engineer. They just say, oh, now you go and speak at that O'Reilly conference. You're like, Ugh, I've never done that before. I like these engineers have never done this before. Let me provide a learning opportunity for them.
And so I set up a training program for all of them to get better at doing technical talks so that we would have a good outcome. This is the sort of thing that sure wish people had done for me. So you learned the hard way? Yes.
Bobby: I definitely paid dividends cuz I actually first met Bjorn at a CTO conference and it was, I thought, one of the better better presentations.
So it seems like you had just put in your reps in time and it was a great payoff. I think that's, I think that's great. Talk a little bit about how you go like towards year seven of New Relic, what your mind frame is like in terms of what takes you from that to your next stop on the career trajectory.
Bjorn: New Relic had gone through its IPO and all companies after they go through an IPO sort of change a bit. And it changed in ways that, eh, I wasn't as happy about. And so I was thinking about what do I want to do next? And I thought, I've done this and I've done this and I've done this other thing.
And so what happened? I done, and these in the recruiter for InVision came around, they'd hired some recruiting firm and they called me up. And it sounded like the same job that I'd just done. So I'm like, eh, I'm not that interested. But then they said, this company is a hundred percent distributed.
I'm like, Ooh, that's interesting. Every company I had worked for before was an in-office company. And in including New Relic where the engineers were all in Portland and the headquarters was in San Francisco, but it was still, there was a. 300 people in Portland. Or object Technology International, where we had many offices around the world, but we still had offices.
Yeah, but here at InVision, there were no offices. Everybody works from home and in fact, the company is now 700 and some odd people and everybody works from home. That's amazing. And it's an interesting thing, I thought, that's something that I don't know how to do. So I would like to join that company and build the same great engineering culture that I built before, but in a distributed fashion.
And so that was the challenge there. And then I also liked the product. The InVision product is a fabulous product. It's the market leading product. They, people love it. And it's an interesting crowd of people that I haven't worked with before. If you look at my history, it's all been engineering tools for engineers.
And this was in, building tools for designers. And designers are interesting, artistic people, and it's really fun working with them.
Bobby: Yeah. And it, it is very much loved and we use it a lot. And I can see your attraction to it as well. The, so the first thing, there's a lot to unpack there that's super interesting.
But let's just start with some basics. So when you arrive at InVision, How many engineers are in the team that you're running roughly?
Bjorn: 'm trying to remember exactly, but I think basically the numbers are like 60 when I arrived and 260 when I left. Completely distributed as you said.
Bobby: Were there any pockets of geographic concentration for those?
Bjorn: So the company does have pockets of geographic concentration simply because there are certain areas of the world where there are more people who are better at software or design. So for instance, New York City, there are a number of people, San Francisco, there are a number of people, London, there are a number of people.
But even the people in San Francisco, just that they either work out of their house or they go to a WeWorks. And not even the same WeWorks. Cause there's many WeWorks in San Francisco. So you know, here we are in San Francisco. There might be maybe 40 or 50 in vision employees in this city, but they probably rarely actually encounter each other.
Bobby: So you arrive and 60 people is, it's fairly established, but it's all distributed. How were how was, communication organized in terms of standups and engineering team meetings, and what did that look like for this distributed team that might be a little bit or a lot different than an in-office team?
Bjorn: So when I joined the reason that they would hire someone like me is because the previous thing that they were doing wasn't working. If it had still been working, they would've just kept doing that and not hired someone like me. And so what had happened was that the company had this original product and it just became this incredible hit it's exactly the right product for designers.
And so it just took off like a rocket. And so they just started hiring people to handle the demand of the features and the maintenance and the operations and so on without putting in place the management structure for that. So when I showed up, there was no management structure in engineering.
It was very flat organization and it ran in I'm trying to, I'm trying to say this in a nice way. You can imagine that an organization that grew very rapidly might have a number of problems and none of the problems are due to the people. Just the fact that it grew really rapidly without organization.
And it just wasn't time to and so I came in to establish that organization and structure. And so that's what I did for the three years I was there. As I put in I organized as a set of teams. Every team has a manager. The teams are collected into, we call them zones of different Different emphasis, and there's this zone that does collaboration.
There's a zone that does the studio product and there's a zone and so on. And then, there's VPs above those and it all rolls up that way. And then organize the code base as well to match that same organizational structure, the inverse Conway maneuver. So that in going from a single monolith that everybody was attempting to modify at the same time into each of the teams owning their own vertical structure of services and then interacting through APIs and a Kafka bus on the back end.
So the combination of, in putting in place an organizational structure and an underlying technical structure that matched that organization allows the company to just move at a rapid pace.
Bobby: I just feel like those are super necessary conditions to get the most out of a distributed team, and it feels to me that the demands for being very good at that kind of process and layout are greater the necessity for them are as greater in a distributed team than an office team, where I feel that some of those things you may not do as urgently because you can get away with it with other in-person
Bjorn: time.
Yeah. So there's a couple things I learned from doing this distributed company thing. One of them I would say that I knew in advance is that the larger team gets, the more positive communication you have in the team, right? This, everybody knows this. And so you try and keep teams relatively small to compensate for that so that you don't have to have a lot of meetings and so on.
And it struck me when I joined InVision that it was necessary even more so in a distributed company because communication is expensive. And so one of the goals in the organization I built was to keep the teams very small so that then you wouldn't have this problem of having to have lots of meetings or too many layers of communications and so on.
We have modern communication tools. We used Zoom, we used Slack that are quite good, much better than we had, say, 20 years ago or even 10 years ago. But the problem is, even a Zoom video meeting has a couple, has three flaws to it. And trust me, zoom is great, but it takes time to set up. I can't just wander by your desk or your office and say, Hey, Bobby.
I have to set it up and that extra effort of having to set it up causes me to have fewer communications than I would if I could just wander by. That's one problem. The second problem is all of these communication mechanisms basically restrict you to a single speaker. So if it's a one-to-one conversation, I'm speaking, or you're speaking and it's all good, if we have a meeting with five people, Typically in a meeting with five people, I might be saying something and you might be going, Uhhuh.
Yeah, I like that. I like that. Or the opposite. But in a video meeting, you can't do that because of the technology. The speaker will flip over, will latch onto you instead of onto me and will stop, it'll mute me like the technology just doesn't support that kind of meeting.
And so the types of meetings you have change in a video meeting. And so you need to keep the teams quite small to keep that from happening. And then the third thing is, even in a video meeting, you're on a two-dimensional media instead of a three-dimensional thing like we are sitting here in this room.
And so while you can see my expressions and you see my hand motions and I talk a lot with my hands. And you saw that when I was on stage at the at the summit. And you see some of that in the Zoom. You don't see that as much as you do in person. And so the types of communications are it's almost like black and white versus color.
You get the same thing is there, but somehow it's harder to see. And so the meetings are a little bit more difficult. So knowing all those things the organizational design in my point of view was to minimize the size of the teams, to limit the, basically the friction that those things bring to the table in a distributed context.
Bobby: And the, I guess what were, what did you find that you didn't expect in that distributed situation when you arrived? What were preconceived notions, positive or negative that turned out to be not true based on that experience?
Bjorn: Oh goodness. One of the things I found was that it was much lonelier than I thought it would be.
And E even for instance, in Portland, we, there were, I think in the end there were 35 InVision employees in the Portland area. And but we weren't working on the same project, and so we rarely met each other. Whereas in an in-office company, you bump into people all the time because you're all physically in the office, or you talk to them a lot because you're on the same project and you like meet in a meeting room or with a whiteboard and you talk about something.
So there's a bunch of human social contact that you don't get in a distributed company. Just this casual casual isn't quite the right word, but this ad hoc contact that you don't get. So you replaced that in a distributed company with other contacts. I spent more time with friends of mine and so on, but it wasn't the same as working with people.
On the other hand, the flip side of that, the positive flip side of that is what do you get time to focus? Nobody drops by your desk just to say hi, which, is one of the classic problems of working in an office is that you go, oh, I just can't get anything done, so then I have to work late when it's quiet to get things done.
In a distributed company, all the times are the quiet times, and so you can get a lot more done when you sit down and need to focus on things. Yeah.
Bobby: So I'm a big believer of distributed teams, as and one of the things I'm constantly trying to experiment with and do better with is that I think is much easier in an office situation than distributed teams is building camaraderie.
I think there's this, like this as you talked about, ad hoc benefit you get when you see someone, and I think one of the positive side effects of that ad hoc-ness is you build. Mutual goodwill, which helps teams perform better in difficult situations. I find, and I think when with the distributed team, especially with the new person joining, it's harder it's harder to build that up.
So I was just curious, like over the times that you were envisioned, what kinds of things did you do that found that work well to build camaraderie with these teams?
Bjorn: Yeah, I didn't really have a magic solution that, the magic solution that I wanted to do, what we just couldn't afford to do was each time someone knew join would be to get the whole team together for a week or two to welcome the new person and introduce the code and get them all working together. That would've been perfect. But at the rate we were growing, we just, we simply couldn't afford that much travel. Both in terms of dollars and in terms of time.
The company was growing. It still is growing at over a hundred percent per year. That's a lot of new people. So we just couldn't do that. So we defaulted to getting together a few times. At every, I wanted every engineer to bump into every other engineer at least once a year if not more often than that.
Was that always in the same place, or did you move around? No, so we just chose. Whenever we had a team that we wanted to get together, we would find the best place for all of the flights. My, my goal was that everybody should be able to have a nonstop flight to the location. And then because we're distributed, we could choose a location anywhere.
So we choose one with good weather. Makes
Bobby: sense. So you talked about these pockets of geographic concentration. You had San Francisco, Portland, obviously and New York. Were those the 80% of the geographies and time zones that you had distributed team members in?
Bjorn: So engineering was more distributed than the rest of the company.
But yes, we tended to have more US employees than non-US employees. Who knows why that, every time we hire someone, their network would. Typically be US based Sure. And so that we'd reach out to those people or our recruiters were really good at, because they're US based recruiters at finding other people in the US or something.
But, so we tended to be US based, but we didn't restrict ourselves to that. So we had, we have some really excellent people in our Argentina got lives in Columbia, Lisbon a little group in Prague and just all over the place. We tended to, as a company work east Coast Hours, so it limits the number of time zones you can go in each direction and still be effective.
And so we tended not to go much farther west than the west coast of the us simply because the time zones don't work so well. And typically not much farther east than Eastern Europe again, cuz the time zones don't work very well.
Bobby: Gotcha. And so did the folks that were working in, Lisbon, did they work sort.
East, New York, east Coast time, business hours.
Bjorn: Yeah. Everybody we had the idea in the company of from the very beginning of having core hours east coast time. And so everybody tried to work those core hours, which meant those of us on the West coast had to change from being normal engineers who get up late to people who get up early.
Which has fundamentally altered my biology, I think. And now I can't get up late anymore. But after a while you get used to it. Yeah. You get, you're more productive too.
Bobby: Yeah. Cuz nobody bugs
Bjorn: you. No way.
Bobby: It's so true. Did you organize the team around those as best you could, time zones and NGOs so that, the people that were working on one particular bit of InVision were clustered in one particular time zone
Bjorn: or that would've been a good idea.
We didn't and like I said, we, it would've been a good idea, I think that some of the teams might have been more effective if we had tried to keep the time zone spread less broad on 'em. But we were growing so fast and we had such a need for these specialized talents that we were looking for, that when we found 'em, we would just hire them.
And so that ended up with teams that were spread across more time zones than, in an ideal world, you would've wanted to have. Yeah,
Bobby: no, I could see that. But still, it feels like you contained it within certain parameters, so it was still manageable and over you could get that overlap with that core East Coast time, it
Bjorn: sounds like.
Yeah and I think it's working quite well. The engineering team is very productive and people all seem quite happy about, like I didn't get any complaints that, oh, I never get any time to talk to those people in Prague because the people in Prague had shifted this way and or this way.
And the people in the west coast had shifted this way.
Bobby: So how it, it sounds like you organized the engineering team into a certain functional, or they're working in different parts of the pro, logical product. So how would the whole process of requirements being created by, historically a product management organization and that then getting over to their engineering counterparts for questions, clarifications, estimation, and prioritization.
What, how did that process work for this distributed team versus, your traditional in
Bjorn: office? Yeah. We tried to use the same process that we've used. Elsewhere and every successful startup that I have talked to all the ones that you work with. Use, which is that, the product manager works with the team.
It just, they happened to not be in the same physical location, but nobody was in the same physical location. So it wasn't an extra handicap for them that, when I was at New Relic, some of the product managers were in San Francisco and some of the engineers were in Portland, other product managers were in Portland.
The product managers in Portland were much more effective with the engineers than the product managers in San Francisco because the company as New Relic as a company hadn't worked out how to have a distributed team. For example, we had all these meeting rooms with giant TVs on the wall, and you would have, the team would go into the room and you'd dial up the TV and you'd have the one remote person.
It's just not a model that works. Whereas at InVision, even if we were in the same WeWorks, We would have separate rooms and we would all call into the meeting as if we were separate so that nobody was advantaged or disadvantaged more than anybody else in the meeting. Yeah, so for example, one of the best product managers we had at InVision, Anthony, is here in San Francisco and one of the best engineers on the team that he works in is also in San Francisco.
But they would never, they would always dial in separately onto the Zoom so that you couldn't tell that they were perhaps even in the same WeWorks location.
Bobby: Yeah. It levels the playing field of that communication dynamic and friction you talked about. It's equal, right? And you don't get any unnatural imbalances.
Bjorn: And so then, once you take that into account, every one of these teams had three to five engineers. It had a, an engineering manager, it had a product manager. And at InVision, cuz it's a design company, a designer, every team has its own designer. At least one, sometimes more than one, right?
Which is unusual. Most software companies you'll find, maybe seven to one ratio of teams to designers or something. But InVision being a design company, lots of designers. Cause it's important, right? Yeah. And so every one of these teams was, that tried to be self-sufficient in terms of where the product's going, how it works, how to build it, how to operate it.
Bobby: Did you guys operate on Using an agile sprint methodology?
Bjorn: Yeah. So when I started building the organization, I basically let every team decide which agile process they wanted. Some of them used sort of a Kanban process and some of them used a scrum like process. In shortly before I left, we decided we would move everybody over to the same regular sprint cadence just cause it was getting big enough and it was getting disorganized enough that we needed some sort of regularization across the organization.
Bobby: So how long were the sprints? It was two week sprints. Got it. So for folks especially, founder CEOs that were thinking about starting a company or our starting company and hiring a PPP engineer, it may be useful just to hear it from your voice of, at least in, in this last, at InVision, how you set up that process of product manager has an idea concept for something they want in the product, and how that gets from that ideation into a scheduled sprint.
Bjorn: I hardly feel the expert on this because we are just using both at New Relic and at an InVision and even in Eclipse before then, we're just using the same process that sort of everybody uses, which is you sit down and you talk about that, and you figure out what the priority list of things that need doing are.
And the engineering team says how long that's gonna take, and the product management team knows what the market needs and the designer knows what the product needs to look like. The key in all of that is to make sure that the designer, the product manager and the engineering manager or technical lead have a good conversation.
It doesn't work if it's a waterfall. Because then you end up with things that are potentially very expensive to build and you end up spending a lot of effort and time building something that there could have been a cheaper alternative to. So you the product manager might come and say we need feature X.
And the engineering team looks at that and goes feature X, that would be expensive. That could be like a three month project, but we could give you something like X minus. And X minus, we could do that in three weeks and it's 80% of what X is. Is that good enough? And if you can get the team to have that conversation so that it's not a waterfall of you will do exactly this to this is what we're looking for.
What's the fastest thing you can get that's like that? You get a much more productive team. And I'm talking about the team, not just engineering team, the man, the product manager and the engineer and the designer altogether working together.
Bobby: Did you use this notion of, pods or squads with a constituent from design, a constituent from product management and engineering?
Bjorn: Yeah. Another thing that companies vary with is if you look at. A 12 week period. Some people are able to cram in six, two week sprints. Others have a certain number of two week sprints, and then some sprint zeros in between for planning and estimations and, cleanup from the previous sprint or prep for the next one.
Bobby: And how did that work or you guys?
Bjorn: Yeah I'm pretty rigorous on if it's a two week sprint, it's a two week sprint and you don't have fake time in between. I hear a very strong opinion from me there. And the reason why is that those iteration zeros or the fake time or whatever, are hiding work that is actually necessary that you should be taking into account.
And so as a result, your estimates for that you're coming back with are artificially low. And you're basically not actually getting good data to make good decisions, especially if you're the ceo you're not getting good data because we're hiding behind these iteration zeros where we're cleaning up from the work that we did before.
No, the cleanup should just be part of the work. It is part of the work. And the estimation is part of the work and the operational maintenance of the system is part of the work. And if you just can't pretend that it's not there by putting it in a separate place. So the model I came up with for a while and it was working for a while and then we moved to another model which also worked.
But the model was that we divided the engineering time up into two buckets. There was product work and engineering work called the PW and ew. And product work was anything that the product manager had asked for and engineering work was anything that the engineering manager had asked for. And so engineering work would be things like fixing operational scripts that were causing us to spend a lot of time on call, right?
The product manager isn't gonna say, oh, we should do that. It's just not something they're thinking about. But it's work that's needs to be done. And so we would break that up and we tried to maintain about a 25%, ew, 75% PW split on the teams. And if we had that ratio, adjusted right then we felt we were balancing the two aspects of the work correctly.
Bobby: And things like bug fixes estimation work for future sprints, all of that.
Bjorn: And bug fixes are a great one because often people say, oh, bug fixes, that's definitely ew, engineering work. I'm like, no, it's not. It depends on who asks for the bug to be fixed. If the product manager says, our customers are complaining about this bug, I really want this bug fixed.
That's product work, right? If the engineering team says, wow, we're being called every day, every night at 1:00 AM, 2:00 AM 3:00 AM and 4:00 AM on call. We're sick of doing that. We want this bug fixed. That's engineering work, right?
Bobby: Yeah. So it truly depends on the messenger and that process. So one of the things that I loved about the previous time we met where you gave the presentation was you talked about end number of things that went wrong.
And there was like a really funny story in each of the cases, and I forget what the number was, it was 17, 17 things. And so we don't have time for all 17, but and it's been some of our months now since you gave the talk. So from memory now, it'll be interesting to see which ones struck with you.
If you were just pick like the top three, what would those be that you. Always came to think about or that you enjoy talking about?
Bjorn: Oh goodness. The top three things, let's see. The title of the talk I think was 17 Things That We Should’ve Known But Didn't. That's right.
Bobby: This is the Venn diagram of the top three of those.
Bjorn: I'm not sure that they're the top three, but so one of the classic ones that that people keep suffering from is forgetting to put indices in databases. And so it works great. And your test cases on your laptop, right? And then you put it in production under load and it just the system falls over.
And it's just, it's one of the classic things that you should remember to do and people forget to do. I a more interesting one was the fact that in the very first version of the New Relic databases and the InVision databases is that we use the MySQL auto increment for row IDs.
Which is fine as long as you have one database, but it breaks down when you have more than one database. And so at InVision we, we have a product called Private Cloud where. Companies can have a private instance of the InVision stack for themselves. And so we want to move the data from the multi-tenant site over to their single tenant site.
And of course when you do that now the IDs have to be different. And if you ever wanna move them Mac, you can't move them Mac if you've been using the auto increment IDs. And it's one of those things that seemed convenient at the time, but really we should have used your IDs for all the foreign keys. And that was one of the stories that I told there.
Bobby: I remember that was the one, I wrote some notes around that particular one.
Bjorn: Yes. It allows you to do all sorts of things and it's one of those things, and in hindsight, yes, we should have known that.
But for expediency, we chose not to early on and then it later came back and bit us. And so there are, I think there are a lot of things like that in doing a startup where you have to make a technical decision about something that you can do something either in a really fast way or a way that you actually know is better.
And I'm not talking about Hacker News engineering, where you just go out and find the latest, fancy thing and you're gonna do that thing. But you actually know, because you've done this a number of times before and you've seen other people do this times before that, that it would pay off to take a little more time to do it the right way.
And that's a challenging trade off for a founder CEO to make because, he is burning through cash and trying to get customers. And boy, that getting it out as fast as possible might be something that you really want to do. But you have to make that balancing act between, if we do that now, I know that later we're gonna pay for it.
And if we don't take into account the fact that we're gonna have to pay for it by maybe hiring another engineer to clean up after this engineer or whatever it is, then, eventually it's gonna do you in. And I've met a number of people who founded small companies who were done in by their technical debt cuz they simply couldn't recover from a bad decision.
I remember know there was one startup I worked for, this was way, way back when I was just in college. In, this was back in the dark ages of the days before Microsoft Excel. We were building a spreadsheet for mainframes. And one of the things we had to do was decide how to paint the screen because we didn't have the video displays and so on.
And we had made a expedient decision to paint the screen from top to bottom. And it turns out that is a bad decision on a VT 100 terminal. And we should have painted it from left to and it eventually was so slow that it basically cost us the business.
Bobby: I think it's an interesting balance that is more art than science. And I'd be curious to know for that particular balance that we're just talking about, what your thoughts are on how much of that is having a good artist at the helm that understands that balance and how much of that is a certain degree of technical debt can be forgiven by immense product market fit and demand for the product that you're building.
Bjorn: Oh, definitely the latter, right? Basically growth solves all problems, right? And Facebook is a fantastic example of that, right? The original Facebook was all written in PHP for God's sakes, right? And yet look at how successful they are, right? And they overcame that debt of that thing to, to get to be successful.
So as long as you've got that a hundred percent per year growth you can take on a huge amount of debt because you can pay for it with your future revenue basically. The trick is paying for it before that growth slows down. Because every one of these companies, the growth slows down except maybe Facebook.
But anyway every one of them goes through this s-curve where for a while when you found the company, you don't think anybody even knows about you and nobody's using your product. And all of a sudden then you get into this massive acceleration curve where the first derivative is positive and the second derivative is positive.
And as long as the second derivative is positive, you just keep shoveling cash into the machine and you keep growing like mad. And then at some point, that curve levels off into a more rational growth rate. And so when that second derivative starts going negative, you better start paying back that debt because all of a sudden you're not gonna have that massive growth to pay off the decisions that you're making.
So I think that's really the decision that you have to make, is as long as your second derivative is positive, you can make any number of mistakes, right? When your second derivative goes negative, then you have to start running your business differently.
Bobby: Yeah I definitely see it that way. But I think a lot of people don't necessarily look at those particular dials until it's too late.
Bjorn: Yeah. I strongly recommend looking at that dial.
Bobby: It's giving you good information. One thing that's near and dear to my heart is onboarding new members of the engineering team so that they're productive as quickly as possible and effective members of the team.
And the team itself is, the output has gone up. Were there things given the ad hoc nature of meeting in person was not possible in a completely distributed team did you find that it envisioned you had better onboarding process because it was just a demand you had?
Bjorn: No I felt that we had a not as good an onboarding process as we did at New Relic. At New Relic. We actually hired people to do nothing but make the onboarding process good. And we could do that because all the onboarding was happening in one facility. Okay. And so we could have a specialist in that facility to do that.
And the goal at New Relic, and my goal at InVision Two, which it didn't achieve, but the goal at New Relic was that you should be able to successfully commit code to production on day one. Interesting. So that meant you had, we had to build enough infrastructure to set you up, get you a ticket, get you all the permissions to deploy that build and deploy that ticket.
And we would give you some ticket, like there's a spelling error. Sure. We wouldn't expect you actually know the code. But the idea was that all of the mechanism would be set up so that you never had to worry about it again. Okay. And so we, we had one guy, maybe more than one now.
His job was just make sure that mechanism was in place, and if it ever took more than a day, had to write some more automation to make it take less than a day. And InVision, because we weren't all in one location, we never quite achieved that. And it took people a while to spin up.
Bobby: But do you think it's an achievable goal in time or there are always gonna be inherent kind of constraints with that distributed angle?
Bjorn: I totally think it's achievable goal, right? You should be able to, you should be able to have all the infrastructure necessary. Now, maybe you can't fill out the HR forms and all those things, right? Who knows I'm not part of the HR department. I don't know what, what's needed there. Go through your sensitivity training and all the things that happen and when you get bigger, that might take more than a day.
Yeah. But but we could still get you on day one. You could just make it so your tools are docker images that you put onto your machine and fire them up, right? There's all sorts of mechanisms that we can do to make it possible to put that infrastructure aside. We got to the point at New Relic where we were giving new engineers Macintoshes that had been pre imaged with all of the tools that we used so that you didn't have to install all the tools.
Big time saving right there. Exactly. But couldn't do that and InVision, because for a while people went out and bought their own laptops and then got reimbursed. Got it. So we didn't have a central place where we imaged laptops and sent them out, but it
Bobby: feels like a solvable problem if it's so
Bjorn: thought about.
Yes. I think that if you put some energy behind it, you could solve that problem. And if you're growing at, as we were in New Relic, a hundred percent per year that means that every year, half the organization, actually more than half, because a few people leave and so you have to replace them and, so more than half the organization is new people.
So you're taking a huge productivity hit if those new people aren't efficient. Early on, like over half of the organization. So when you start looking at numbers like that, it becomes really important. Now, if you're at a slower growing pace, like I have a friend who has a startup that's growing at 30% per year.
Heck, if my paycheck grew at 30% per year, I'd be a happy camper. But, he's considered a slow growth startup, so they're only hiring a few people. Every now and then, you can get away with having a less efficient process because it doesn't hit you that often.
Bobby: But now that you've spent years leading a completely distributed engineering team and you've done it the more traditional way also for many years would you recommend the fully distributed engineering team to others?
Bjorn: So here's the interesting thing I'm glad you brought that up because I wanted to mention, the other thing I learned about running a distributed organization is that I think the job of management is n plus one harder in a distributed company than a non distributed company. And this presents a number of problems.
One is if you wanna hire a second level manager, like a director at a distributed company, you really should be looking for somebody who was a VP at a non distributed company. And for that level of skill is what you need for a director and a distributed company. Interesting. At the size we're talking about within vision.
So that, that presents a number of problems. One of which is how do you get first time managers. Because if it's an n plus one hard problem, you really should be looking for somebody who's got the second level management experience to do that first level job. There's, it's very difficult in a distributed company to bring somebody up from not being a manager to being a manager in a distributed company.
And I think the reason that it's, and this is my argument, the reason that it's n plus one challenging in, in a distributed company of this size is because you can't go and just meet people face to face. So for example, if you and I are having a nice conversation, maybe we're having a one-to-one, and I happen to say something which really pisses you off and, but you're a polite guy, so you don't actually let me know that.
And you walk out the door. If we were an in-person company, the next time I walked by your office and I glanced over there and you glared at me, I would think that's odd. Bobby never does that. And then I would stop by and I'd say what's going on? You would say, oh, you really pissed me off.
I'm like, oh, that's not what I meant. And we'd work it out. In a distributed company, what's gonna happen is I've pissed you off. I don't know about it. The next thing I hear is I get a resignation letter from you that you're going off and working for Google. I'm like, what happened last time we talked? It was so good. Everything was fine. And so the skills you need as a manager are greater in a distributed company because you have to compensate for the fact that I can't just walk by and see that you were unhappy. I have to find other mechanisms to learn that about you.
And that's a, that's an n plus one level skill, right? So I think in a larger distributed company, you have to hire more experienced managers to make that company work, right? Now, in a smaller company, you're talking 10, 20, 30 people, I actually think the distributed model is the way to go.
I think I don't understand how anybody can start a company in San Francisco these days, right? Just like the cost of living is so high here. How could you get five people to, do the apple startup in a garage thing? You couldn't afford to not be paid for six months while you're building your product because, all the subway rates are already occupied by homeless people.
So you couldn't be one of those people while you're building your product. Exactly. So the only I think, way to succeed is actually to build a distributed company and get great people from all over the globe in your small company to join and get together, people that you've worked with before and so on.
I just think that at a certain point you then have to think about is that fully distributed model, the right model as you grow larger and larger? And my current thinking about that is that in fact, instead of the fully distributed models, you get larger and larger, you should use what I've been calling the pod distributed model, except I'm sure there's a better name for it, where instead of having everybody work from home, you have little pods of people around the world.
If you and I wanna go into business together, maybe you have a few engineers here in San Francisco who work with you and I have a few engineers up in Portland who work with me. And then I get, and then we make sure that the project that I'm working on in Portland, Is completely contained in Portland and the project you're working on San Francisco is completely contained in San Francisco.
Maybe you're the front end and on the back end. And then I get to work with the engineers and we have a whiteboard and we bounce ideas off each other so we get all those advantages of the in person. But we also get the advantages of being able to hire people anywhere in the world, because if we now find somebody in Austin who says, yep, I wanna join you, you're like, great, let's start another pod cuz you're so fantastic.
We'll have a pod in Austin.
Bobby: I just feel that is, again, I'm biased just folks who know me would contest. But I I think the world is moving that way for the scarcity and recruiting challenges that you talked about. I just, people are, there's gonna be an infinite amount of ambition to start companies and for the foreseeable future that's gonna require software talent.
And for the foreseeable future, that software talent is very difficult to come by in cities like these. So something has to give.
Bjorn: And then, another thing we found at InVision, which, in, in hindsight of course is obvious, is that it's very difficult to hire junior people into a distributed company.
Because if you think about the experience of being a junior person just coming out of university or maybe coming out of a code school and coming to join a company, you get lots and lots of advice and assistance from your colleagues sitting next to you the people on your team, and you're like, oh, I can't remember how to reset my gi after I've accidentally checked in a file, how do I do that?
I just turn to you and say, Bobby, can you help me out? And I don't feel so stupid because you're sitting there. Whereas if I'm remote you slack that I slack that, then I feel dumb. It's in print and interrupting you and Right. And so just the nature of being a junior person is much more difficult in a distributed company, and as a company gets larger and larger, you need a diversity of people in the company.
Not just diversity in terms of men and women and minorities and that sort of thing, but a dessert diversity in ages and talents. One of the problems that we had at New Relic is as we grew, we e we, we focused on hiring senior people. Because we wanted people who could go in and modify the virtual machine of Java and, all these hard technical problems and deal with more data coming through the front door than you can ever imagine, and really hard technical problems.
And we realized as we got to a certain size, I'm gonna guess about 50 engineers, that there were a bunch of, let's call 'em grunt work problems that needed doing, that nobody was doing. Because first of all, the senior people didn't really wanna do those. Cause they did them back when they were junior people.
And secondly, they were way too highly paid to be spending time doing those jobs. And so they just weren't getting done right. And I was like, oh, I see. I haven't been hiring enough diversity. And so I started hiring more junior people. Yeah. And so every team would have this range of things all the way up from distinguished engineer type problems through down through senior engineer type problems, all the way down to, first year junior engineer type problems.
And it's important to have that. And it was more difficult to do at InVision, because it's very hard to hire a junior person into a fully distributed environment.
Bobby: Interesting. And it probably has different recruiting dynamics also, I would say, because of that. I think you're not, obviously you're not gonna have a university recruiting thing as your foray for filling the pipeline.
Bjorn: You certainly could. I mean InVision doesn't, but it could. But then you would've, the problem with having all these junior people, right? The problem that we had in InVision for recruiting is that we didn't have a building. Like here in San Francisco there's Salesforce Tower, and then I was walking around and there's LinkedIn on a sign over there and and so every day when you commute back and forth to Bart, you see a Salesforce tower and you see the LinkedIn sign.
And then one day when you get frustrated with your job and you're like, I'm gonna get another job, you're like, where should I apply? Oh, I remember LinkedIn. I could just go over there. So you just, it's this constant marketing of who you, of that you're out there. InVision doesn't have that, cause it has no buildings.
Yeah. Like in no locale doesn't have that now it has a great brand. And so in fact, InVision has a plethora. Of designers wanting to work at that company. Oh yeah. And so as a result, as fantastic designers at that company, because you get to pick of this infinite stream of talent coming in.
But much harder time recruiting engineers because InVision doesn't have a brand as a place that you go to do interesting engineering, even though there's a lot of interesting engineering going on there. New Relic has gotten to the point where people go, oh, there's interesting engineering going on there.
But it's known for that. Even though it doesn't have a sign in downtown San Francisco. But my point is it, I think the distributed company is actually a handicap in recruiting in some ways because until you have that brand people don't think about you.
Bobby: Yeah. I think building up that brand early and I think trying to find pockets of talent where you can get access to people in the local locations.
Bjorn: You just can't. And so that's why I think this pod remote is the right thing to do. So you, you hire somebody great in Salt Lake City and they go out to the local meetups and they say, Hey I'm doing compilers for this startup and we're doing fun stuff and ah, people go, we're one work or that, and then they'll join you. And you don't get that if you're completely distributed.
Bobby: Yeah. So I think, so that's, that really resonates with me because that has, I stumbled across that, but then discovered there was a pattern for why certain centers were doing well and certain centers weren't. Which is, I think when you go into this role remote model, it's very important.
You understand, you must have senior leader slash champions that can really network and run that local area for you.
Bjorn: Like the local version of the company.
Bobby: Exactly. And that's what you're replicating in that scales.
