Relicans host, Ben Greenberg, and Engineering Manager at Orbit, Ulrich Sossou, talk about building diverse, dynamic software engineering teams at really fast-growing startup businesses around the world.

Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.

Do you have ideas about how we can make our show better? Or would you like to be a guest on an upcoming episode? Reach out to our #devrel team at devrel@newrelic.com. We would LOVE to hear from you with any questions, curiosities, and/or feedback you have in hopes of making this the best show possible!

Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.

Ben Greenberg: Ulrich Sossou is an Engineering Manager at Orbit, the solution for businesses to grow and measure their communities across any platform. He joined the company as employee number 4 and is now managing a team of 15 software engineers. Previously Ulrich was VP of Engineering at EtriLabs from 2015 to 2020, where he led the growth of the engineering organization from zero to more than 10 product engineering teams. Prior to EtriLabs, Ulrich co-founded several startups, including one exit from FlyerCo, a marketing solution for real estate agents.

Ulrich, it is such a pleasure to have you here on Polyglot. Thanks for joining us.

Ulrich Sossou: Thanks for having me. It's a pleasure to be here too.

Ben: I am so delighted for this conversation because you have had such a varied and interesting career, both as a practicing individual contributor as a software engineer on the ground but also as somebody who has built really diverse, dynamic software engineering teams at really fast-growing startup businesses around the world.

So that's actually where I would love to start our conversation is in that topic because I think that's something that a lot of us in engineering, as we start, either we get promoted into a role where we're managing teams, or we're asked by default to start building teams. What are some of the practices? How can we really do that in the way that is most effective? What are some of the things that you have picked up in that experience over the years?

Ulrich: I think the most important thing that I've learned over the years is that it's people who build software. So it's like the way you organize your engineering organization and the culture that you are able to create actually corresponds to the software that you build. So the software is just a reflection of that culture and the whole engineering organization. I think that's the most important thing I've learned so far.

And the second one is still related to the people but not the organization, just trying to have very passionate people who are able to go beyond the engineering or technical subjects to think about the problems they are solving and the mission of a company. And if the people you hire are passionate about the mission, you will have delightful software that a customer would like to use.

Ben: I think that is such profound insight. First of all, you shared many profound insights there. But something that really captured for me in the moment listening to you is that people build software. And if you have the right people in the room building the software, it will be reflected in the software itself, in the final product output. So can you say a little more what that means when you say that people build software? Because that is such an interesting idea, and I would love to unpack that a little more with you.

Ulrich: What I've noticed is when you build software, it is obviously to solve the problem of the customers. And there's a multitude of ways that you can solve the problems. So usually, depending on the people and the software engineer that you put on solving those problems, the software will have a different architecture.

So let's say, for example, if you put together a team where engineers are not very collaborative, so each one is in their area, you will have software with different pieces very different from each other and not put together very well. And if you have a team where it's very collaborative, when you look at the code of the software, it will be like it's just one person who wrote everything because they're able to just work as one person.

Ben: So what you're saying, and I've never heard someone say this before and it's so interesting, is that if you're a careful reader of code, you can look at the codebase of an application, and there are hints and ways you can see if the code is built by a collaborative team working in unison. Versus a team of siloed spaces where everyone's building their own thing like microservices that don't really speak well to each other versus one, perhaps you might say, one majestic monolith where everyone is building together. And you see a general direction going forward, even in the codebase itself.

Ulrich: Yes, exactly. That made me remember one of the most impressive engineers I've ever worked with. He was a junior. And then, when I brought him on the project, he copied the way I wrote code, and it was like it was me writing the code. So I didn't even notice that the guy was a junior. And that was really impressive.

Ben: That is really impressive. Because what you're saying is that your ability and where you are in the hierarchy, whether you're a junior, or a senior, or a staff engineer, is somewhat based on your proficiency technically. But it's also based on your ability to be part of the team and collaborate and build in a cooperative fashion if I'm understanding correctly.

Ulrich: Yes. Yes, that's correct. As engineers, we want to think that we are solving very difficult problems every day. But at the end of the day, I think it's maybe 10% or at most 20% of the time that we spend on difficult problems. So the rest of the time is mostly spent just doing the same thing again and again, copy-pasting code.

Ben: [laughs]

Ulrich: Looking at the software and looking at okay, how did the team solve this problem before? And just doing the same thing. So we want every engineer on the team to be able to not repeat for a while every time and be able to be productive right away. So even in a team, when you have some junior people, if the collaboration and the culture is good, those people will be able to contribute in a very meaningful way.

And for example, at Orbit, I noticed that. I think the person I'm most impressed with is our most junior engineer at Orbit. She's just able to work on very important projects. And it is actually the first time she's had a job as an engineer.

Ben: That, to me, speaks volumes when you take a person into the team, and you see them thriving right away. And it's a person who hasn't had a software engineering experience before professionally, and you bring them into the context. You can almost tell by that very act that the team is cultivated in a way that is welcome for success for all people across the various skill levels. Because if they can be integrated quickly and dynamically and they start proving their success to themselves and to others, it's testimony to the culture of the team is what it sounds like.

Ulrich: Yes, exactly.

Ben: It's funny when you said that 10% of software development work is solving hard problems. And 90% leftover roughly is copying and pasting. Have you seen the little gimmicky thing put up by Stack Overflow, the two keys, the Ctrl+C and Ctrl+V keyboard?

Ulrich: Yeah.

Ben: [laughs] It's almost that so much of our work is learning patterns and applying those patterns to existing problems and learning when to tweak the pattern when it's not exactly the right fit but understanding some of the basic underlying solutions that the pattern represents.

Ulrich: Yes, yes, that's correct.

Ben: So at Orbit, where you reference, and you're now an engineering manager at Orbit, you didn't start as an engineering manager at Orbit, did you? What was your first role there?

Ulrich: Yeah, I started as a software engineer. I started about 11 months ago. And then, I learned a lot from architecture of software, everything about the Orbit software, and contributed to very meaningful features. For example, I work on the Discord integration for Orbit. And then, since I already had a background in terms of being an engineering leader, I started taking on tasks related to organizing a team. And then, after seven months, I was promoted to engineering manager.

Ben: That's a pretty quick trajectory within 11 months from engineer to engineering manager. It seems like what you're saying is that you took on the roles of an engineering manager because it was like a natural proclivity of yours. And it led to the official title designation. But you were already in many ways doing the work of an engineering manager before you were formally given the title.

Ulrich: Yeah, exactly. Because before joining Orbit, I honestly didn't know exactly where I wanted to be. And since I left the previous organization where I was working as VP of Engineering, I didn't know if I wanted to be VP of Engineering or engineering leader somewhere else. That was actually the first time I was VP. And then, I learned about Orbit, and the mission was really aligned with my interests at the time.

So I joined as a software engineer because I like building software. And then, I noticed that I spent so much time managing people and building an organization. Because in my previous organization, in about three years, we went from 1 team to about ten teams of engineers and so about an organization of about 80 people. So I spent several years on that. And then at Orbit, when I started noticing things that could be improved in the organization, I was like, okay, it seems like I have more affinity with engineering management tasks. So I started just taking on those tasks, and then I was promoted.

Ben: Building a team. I want to get back to Orbit in a minute. But I also want to return back to that point where you said that in your last role, you built teams up to 10 in product engineering teams. With each growth, there becomes almost an exponential amount of complexity as you expand each team. There's a great book, and I'm sure you might have seen it, or if not, our listeners haven't seen it. It's called An Elegant Puzzle: Systems of Engineering Management. Have you seen this book, Ulrich? You're smiling.

Ulrich: [laughs]

Ben: Our listeners can't see your smile, but I see your smile. You've seen this book.

Ulrich: Yes, I've read it recently. I think for me it is the best book on the subject because it's very practical. I read several books on the subject. And for me, the challenge from my previous experience going into Orbit was from the previous experience; I wasn't...even at the time I started in 2015, there wasn't a lot of content in terms of engineering management and leadership. It was mostly technical content. So this book Elegant Puzzle helped me translate my previous experience and put words onto them and put some structure around this experience.

Ben: That's exactly the same thing that I'm experiencing. I'm in my first role personally as a lead technical role. And in that role, I'm helping to shape a bit of a team as well in the developer relations space. And I found this book gave me a lot of concrete frameworks of how to approach the topic of structuring engineering teams.

And I bring it up because the author specifically talks about how every time you add more structures, you're growing more product engineering teams. You're also increasing levels of cognitive and organizational complexity. So how did you go from 0 to 10? And what were some of the strategies that you incorporated as the VP in that context to mitigate or to address, to reconcile, you know, pick your verb, to deal with those increasing levels of complexity? Because you probably did that in a pretty quick fashion from zero to 10. So I'm curious to hear how you managed some of those issues.

Ulrich: I think the most important thing was for autonomy of the teams because it's just difficult to know what all these people are doing. And it starts even getting to the point where you notice some people with whom you've almost never talked to in the organization.

So I think, to start, what made us successful was when the team was small, we built a fairly close team, very strong culture. Even now, at Orbit, there are five people who we've hired at Orbit who are coming from that very first team. And there's been a lot more who applied, and I didn't tell them to apply. And so that was something really great for me.

So I was saying having this very core culture, very strong culture was, I think, the most important thing that allowed us to have the foundation for growth. And then after that, what we did building out our team was taking people from very a small team and then building a new team from those people. Those engineers would bring the culture from the core to other new small teams. And the autonomy, as I was saying, was very important. Because when you create the structure of how one team works, and then you duplicate it across other teams, it works very well.

Ben: I think those are two very fascinating ideas. One is using existing strong team members as kernels for the creation of new teams as you're growing because they will be the advocates for the culture of the team, the culture of the organization as they start growing these new pods. I think that's a fantastic idea and takeaway.

And the second one which I want to spend a little more time on talking about, too, is the question of autonomy. And before we get there, though, you've referenced a couple of times Orbit and the mission that drew you there. So I think we'd be remiss if we didn't spend a minute talking about what that mission is and what drew you there.

So what is Orbit? You said you built a Discord integration for Orbit, which, if people don't have context, might not make much sense. So give us a little walkthrough of what Orbit is and what was so compelling for you that brought you to the organization?

Ulrich: What Orbit is we like to say that it is mission control for your community. So it's just a solution where you can connect it to everywhere you have your community, so Discord, Twitter, Slack, and everywhere else. And then, it brings together the data about this community so that you can measure the impact of a community on your business. You can identify your champion and monitor how your community is going, find a way to automate all the work that you do as a community manager or developer advocate, and just create a stellar experience for your whole community.

Ben: So it gives you the impact measurements of all your community efforts across all the platforms that your community exists on, which is why you built a Discord integration, for example.

Ulrich: Yes, exactly. Not only the impact. We started with the impact, but we are more and more adding some tools for building workflows for community advocates because we've noticed that there are just a lot of manual tasks that they have to do, and we want to make it easier for them.

Ben: And as an engineer, you don't like the manual tasks.

Ulrich: No, not at all. [laughter]

Ben: So let's go back. Thank you for that. I think that provides the necessary context for our conversation. Let's go back to the question of autonomy for engineers on teams and maybe for the teams themselves. And I think it's important to frame this conversation by a bit of how far-reaching are the teams that you have worked on and the team that you currently work on vis-à-vis that level of autonomous working culture?

So you, Ulrich, live in one part of the world. And there are people on your team currently at Orbit who live in all other parts of the world and across time zones where you may only overlap synchronously for a couple of hours of the day with some of them. And yet you find ways to be really productive and work really well together.

In addition to the time zone, which is one thing we'll talk about, there's also Orbit intentionally hires across countries and across cultures, so people from different working styles, people with different language proficiencies, people with different ways of communicating are all coming together in this organization to really thrive.

So I would love to hear from you about how that happens in the engineering context, both how you'd be productive across time zones where you're only sharing a couple of hours maybe of a day and also how you remain productive and happy together across cultural and communication differences as well.

Ulrich: I think the most important is when you bring people from different cultures together, for example, sometimes I will say something, and then they'll understand something else like we're not talking the same language.

Ben: [laughs]

Ulrich: So what we had to do is just having a common culture that we can build together. So at Orbit, the culture is just, I would say first, just being kind to each other. So let's say, for example, I understand that someone has said to me something that's not very good.

So instead of jumping to conclusions, I will go and ask if it's really what they wanted to say. And other times, it's not that; it’s just cultural misconception. So I think that's very important if you want to build a culture where we have people from all over the world talking to each other.

And the second one is this autonomous, like just being autonomous because we have people from different time zones. And it's just not practical for everyone to be working in the same time zone. So we need to have async communication in place. So we just have a very small window of about two hours to three hours per day where we can have some video meeting and work synchronously. But all the time that remains, we're not on the same time zone.

Something very interesting that allowed us to do is that everyone works on their own time. So if you are an early bird, for example, you can work very early in the morning. And then you have this two hours period where you just need to be online with everyone else. And if you want to work very late, you can work very late. I have, for example, some colleague in Europe who works very late. So we are almost at the same time zone as the U.S. East Coast.

There's also this culture of learning from each other because we're just people from different experiences. There's a lot we can learn from each of us. And I think that's one of the most important things from the Orbit culture.

Ben: I think those are all really, really good points. And I really want to call out that idea that you said where if somebody says something to you that felt offensive, to take a moment and reach out to that person and make it explicit and ask, "Did you mean to say how I heard what you said?"

Because oftentimes, especially with people who may be speaking a language that's not their first language or even if they are speaking a language that it's their first language, they may apply it differently in their cultural context. You may or I may, or someone may misunderstand what's being said. So taking that moment to clarify and just make everything above board could go a really long way.

I do want to ask you a bit about how you, as a team, maintain that asynchronous knowledge share when you only have a couple of hours in the day where you are overlapping. So what kind of tooling do you use to make sure that what happens in someone's working day, that knowledge or things that need to get imparted get imparted to the person that's just waking up and doesn't overlap at all without doing a host of synchronous video meetings? So what kind of asynchronous tooling are you using for that?

Ulrich: We have a lot of documentation. There is an engineer who joined recently, and he said our Notion documentation is one of the most organized he's ever seen. And so obviously, we're using Notion first to document everything that we do because we combine not only engineering but everything else, the meetings, just everything.

And then after that, we have Slack that we are using more and more, but before, we weren't using it a lot. I think someone joined maybe three months ago; I don't remember who it was. But the person was like, "Okay, I don't see any communication in Slack. Where is communication happening?" And it was just because we were documenting a lot of things and just sharing those documents around. And now that there are almost 30 people, we can see a lot more communication in the channels.

Ben: So when do you use Slack which is now, I guess, from what I heard, a more emerging communication tool which shows the dynamicism of organizational change? But putting that aside, when do you use Slack versus when do you document in Notion, or is there a lot of overlap between those two?

Ulrich: So I will say for the day-to-day work, we try to document everything in Notion. There is obviously communication happening in GitHub and other tools that engineers need to provide code. And in Slack, it's mostly for asking for help, just that. But we also have a very interesting structure in Slack where we wanted to avoid distraction for everyone.

So what we did is that we created some channels per team so that each team is just not distracted by everything else happening in the company. And then besides that, we have a few shared channels when, for example, we have someone on support, and that person helps to ensure a customer's question goes into that channel and ask a question. So it's just when we need help mostly that we use Slack. And also, we have a few random channels for sharing music and cute images.

Ben: [laughs] But it sounds that even the way you use Slack, which is mostly temporaneously as in there's an issue that needs to be addressed in this moment, and I'm asking for help or social sharing, even there you've thought deliberatively around how to structure the Slack channels to minimize the constant flood of information that can oftentimes be a challenge in really active Slack environments.

Ulrich: Yeah, exactly. Because companies that are non-remote companies are very deliberate in terms of how they structure their office. When everyone is in an open-floor office, the interaction is very different from when each team has their own home. And even in the way which home is closer to another one makes the collaboration between the teams very different.

Ben: Exactly.

Ulrich: So what I've noticed is that it is almost the same in Slack. The way we structure our Slack has a very big impact in terms of collaboration between team members and team. So we've been very deliberate about it. It's something that we have evolved. I think the past year, we've changed the structure with Slack maybe three times to four times.

Ben: [laughs]

Ulrich: And then, for the past five months, we didn't change that much. So I guess we found some balance over there.

Ben: And yet, you're probably at the same time in a state of readiness to reevaluate if needs change. I think that's probably striking the exact right balance, which I know a lot of companies strive hard to find in these constant channels of information and sharing that Slack and other platforms like it present. That's really well done.

Are there any last words of advice you want to share with us? We've covered so many topics today, Ulrich. We went through so many pearls of wisdom that you have offered. Is there any last idea that you think our listeners would really love to hear from you at this time?

Ulrich: Yeah, I think it would just be the first one that software is built by people. I think for me, it's something that's very dear to me because I've seen how some very bright engineers are not productive when they're not in the right environment. And I've seen how just building the right environment and the right organization can make even some juniors almost as productive as senior engineers, just that they lack the experience for some of the most difficult tasks, but they are very productive.

So for me, it will be the last word. Software is built by people. The culture of the organization is very important. And it's also important that you gather together the people who are most passionate about the company mission to build together software that customers love to use.

Ben: I think it is quite fitting that we end this conversation with where we began that software is built by people. Because from what you've said and from how I've known you over the time, you are an engineering manager that exemplifies that idea, putting the people you work with first and foremost. And I think the software that you build reflects that quality. So thank you, Ulrich, for joining us on Polyglot. It was such a pleasure to have you.

Ulrich: Thank you for having me. It was a great chat.

Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.