In the latest edition of the Full Stack Leader, we talked to Carl Moberg, co-founder and CTO at Avassa, about building teams and solutions.
In the interview, Carl discusses the challenges of creating innovative technology in a new category. He emphasizes the importance of proper measurements and feedback to guide development decisions. In his experience, working on category making solutions requires bringing various parties together to ensure that they are building the right thing.
Carl also elaborates on the concept of servant leadership, where a leader’s primary role is to identify and eliminate obstacles for their team. He underscores the importance of sharing specific feedback and celebrates success, and advocates for leaders to openly admit their mistakes, fostering an environment of psychological safety and growth.
Top leadership tips from Carl Moberg
Below is a summary of the top Leadership tips shared during this week’s interview. Listen to the episode to learn more about the thoughts behind these tips:
- Be a servant leader
- Expect people to understand the entire context
- Share success and be specific in your feedback
- Openly admit mistakes as a leader, be kind to yourself, and make sure to show it
- Do the “Swedish love hug”
We hope you enjoy the episode. You can find more Full Stack Leader episodes here.
Part 1. On the career and experience
Ryan: Hello, everyone. And welcome to this week’s episode of the full stack leader podcast. This week. I’m here with Carl Moberg. He’s a CTO and co-founder at Avassa. Carl. It’s great to have you here with us.
Carl: Thanks, Ryan, for having me. I’m glad to be here.
Ryan: Yeah, I’m excited. I know the days are starting to get a little bit shorter there in Sweden.
So it’s great that you could join me for this early evening.
Carl: That’s exactly right. So we have to have something meaningful to do here towards the end of the day. So, joining your podcasters is an awesome pastime.
Getting started with the Internet
Ryan: Okay. That’s great. So maybe you can tell me a little bit about how you got into tech and what led you to being a CTO. Where’d you start?
Carl: Okay. Yeah, I guess the short and snappy version is that the building phase of the internet saved me from higher education. I was working on my civil engineering studies. I was stuttering a little bit studying-wise and actually got a little bit of work for what I didn’t really understand at the time – they call it a service provider or internet service provider that allowed me to go work to actually build the physical foundation of what turned out to be the first large-scale Swedish internet network.
And that was the, yeah, that was exciting times, literally sitting in vans standing up routers and connecting cables and configuring routers and email systems and all that kind of stuff that then led me to actually want to build software to support those kinds of environments.
Switching to leadership
So I was part of founding a company in the late 1990s / early 2000s, and my switch to a corporate environment, let’s say from a building and operating environment, actually opened up my eyes to working with, let’s call it, generally, product management.
And that was the path to a set of roles that has always included a little bit of leadership. So I went from a purely technical role into more of a product-oriented role, and that opened up the opportunity to work with and for people, so that was the path. Then I’ve gone through a lot of interesting companies with a focus on building tools for others and mostly around automation and orchestration for infrastructure generally, and nowadays also for kind of the application layer.
So that’s, I guess, the short version of the longer story.
Ryan: No, that’s great. I know there’s been a lot of growth and extensive evolution in automation within the infrastructure – especially over the last decade. How has it been to be a part of that process?
On evolution of automation
Carl: The interesting thing is that in the early days of working for a service provider – an ISP, someone providing internet services- my role actually included, funny enough, when you look back at it, both server management, managing servers with applications on them, and very deep technical networking. So, at that time, it was really easy in the same team to think about how to consistently manage both, let’s call it “application workloads” and server world, as well as the networking.
So we could actually steal a little bit from both and cross-pollinate how to think about automation.
A little bit of geek history here. In the late 90s/ early 2000s, there was an emerging router company. It was a known fact that they had a Unix operating system on the router.
So we could actually start applying all the automation that we did for the server side, but also to the routers themselves. We could start treating the routers with forwarding planes as servers or server-style configurations.
Building good & stable abstractions
The benefits and the efficiency improvements were just staggering. I don’t want to be too cynical or historically mean, but the really hard pushback from the people who spent their days doing manual work was also proof that we were onto something. And that’s been the case, I guess, for 25 years now – to try and find some good abstractions for automation that we can apply to more messy environments, right? Think data centers pre-Kubernetes.
Today, I spend most of my days thinking about how we can build good abstractions for automating applications at what could be generally called the Edge – which, I guess, means when you have a small number of computers but in very many locations, which I still think is an unexplored area – how to think about that and how to actually build good and stable abstractions for it.
So it’s been fun. It’s been very interesting to follow what are some unexplored fields if you like, what are some unexplored parts of this industry that need automation, and try to make it so it’s been a really cool experience.
Ryan: That’s great. Maybe this is a good time to talk a little bit about how your company, Avassa, is actually approaching some of that and doing some of the container work and edge computing work.
I mean, give a quick rundown as to what the approach is with Avassa.
The Avassa approach: historical context
Carl: Sure. So the historical context was that before we founded Avassa, we were a group of people that I worked with at a company called Tail-f System, and we had focused really hard on building really good automation and manageability for network elements.
First of all, how do we build great protocols and command line interfaces for routers, switches, and firewalls? The progress step after that was how to build automation and abstraction for large-scale networks, like big backbones or very large enterprise networks, and after maybe 10 to 15 years of doing that, we could clearly hear the conversation with some of the large enterprise customers shifting to what would the same kind of automation approach look like for applications at the Edge.
We could clearly see that the kind of focus and the interest and the excitement were moving away from the infrastructure, right or wrong. That has been perceived to be done or finished. I don’t happen to think that it isn’t, but maybe the general sense is that it is moving towards the application layer. It’s a pretty violent and interesting – not “violent” in traditional terms, but let’s just say “severe” – switch in the problem space between networks and applications running on top of networks and mapping applications to the resources in terms of networks and hosts.
The Avassa approach: solving the problem
In our journey in networking, we realized the power of tree-structured data and schema languages and how to formalize what kind of configuration and state these boxes might have. And we found that the application layer could actually be helped by the same approach.
If we allow the hardware platforms inside of these Edge locations to describe in detail what they can do for applications, we can allow application teams to tell a system – like what we’re building at Avassa – that “Please run these applications, but only run them under particular circumstances.” And for, I guess, the emerging Edge field here, you can think of things like, “Here’s an application that does some sort of object detection based on our camera stream.”
Then, of course, the knockout requirement for that application is that there’s usually a camera, so there is no need to start this application unless there’s a camera. And maybe some of these applications require a GPU because it’s pretty heavy in terms of computation for object detection and object classification.
So maybe there are two knockout requirements for this application: a camera available and some GPU or a slice of GPU available. So building a system that can take declarative specifications of applications and the requirements and then map them onto the infrastructure, we think, will solve many of the fairly tricky problems you’re otherwise stuck with if you’re treating each location like a small data center and you manually start and stop and update computer programs in each of these locations. So, by applying the same general approach here, we think we can solve some of the hardest scaling problems with managing applications at Edge Compute today.
Building the right team
Ryan: Got it. Sounds like an incredibly interesting and complex problem. Sounds like you need some really good engineers working with you on it that understand some of the dynamics happening within the automation in the Edge world. How did you build a team to go after this?
Carl: So I’ve been lucky – I guess it’s the word. I’ve been lucky to work with a set of incredible engineers for a good 15 years now. And what I mean by incredible engineers and what I will give them full credit for is that, first of all, they have what could be called a “computer science background.” So they’re interested in the shapes of problems and identifying and classifying the problems we have before us before they apply the solution, and it doesn’t come as a surprise to people who have spent some time in computer science that most of the. No, most of the problems that we find are already solved in several ways. So, there’s rarely an opportunity or a necessity to actually do some fundamental or foundational research.
So what’s really cool about these people is that they are really good at identifying the heart of challenges or problems that we’re taking on and being able to map that to known solutions and maybe tweak those solutions a little bit to make them apply here because there are precious few unique and uniquely new problems popping up round about the IT industry.
It’s mostly variants of things that we have known of since, I guess, the 60s or the 70s. Maybe that sounds depressing, but it’s, in my experience, pretty clear. Yeah. So, that’s at the heart of what’s so cool about these guys and why I love working with them.
Guiding people towards solutions
Ryan: What are some of the challenges of trying to create something with this kind of complexity on a small team, and how do you guide them toward the types of solutions that you’re trying to get to?
Carl: Yeah. So again, another superpower, I guess, of this team is that at their hearts, in their core DNA, is a wish to have their software used in a useful manner. And what I mean by that is that they are easily bored. If we start building things that no one wants or no one uses, yeah, and so it puts the burden mostly on the rest of the group and not the engineers not so much to find people to use this because if we can find that virtual cycle- and maybe that sounds easy- to actually build something small enough that we can actually get some interest and then feed off that interest and expand the scope can actually build something valuable out of that. It becomes a very nice flywheel effect in terms of feature development and then feedback from users. And I guess the trickier part is to get the fundamental architecture, right?
I mean, we usually build pretty extensive platforms or platforms with some fundamental ideas on them, and you have to be a little daring, I guess, to make a couple of those decisions on what are some of the fundamental assumptions and then go out and just collect feedback and iterate from there. But having engineers that are real suckers for feedback and really, really long to have people use their software and maybe also a little bit to show the industry how it should be done and actually provide some new and thought-provoking and successful ways of solving known problems is usually the best mix.
The right way to give the feedback
Ryan: Yeah, that’s really interesting, and I think this kind of hypothesis-driven development is a pretty popular thing at this point and has proven to work really well.
But in this type of case, how do you feed the feedback back to the team in a way that they can digest it and use it?
Carl: the team right now. It’s small enough, and the personalities of the team now are that we literally bring them into meetings with the users and even with the commercial side of maybe the users or the customers, and that has a secondary effect that I think is really cool because of course I tend to gravitate towards being the outward facing conversation holder or conversation maker, and at times that can be challenging in the sense that it can actually be quite hard to come back after extensive meetings with users or meetings during trials or POCs and explain in enough detail to engineers to the engineers that I work with what it is that the customer wants and in the worst case it becomes Chinese whispers.
So, bringing them into the actual meetings, and I know this is particular to where we are in an early stage of the company, the team isn’t huge. Our user base is growing, but it’s absolutely manageable for a small team. So that’s the lovely part, I guess, of this early stage here is that we can actually invite the core engineers.
Staying on the same page
Ryan: I have an interesting question for you on this front. Given that it feels like the application elements of this can be pretty varied when engineers come into those meetings with, let’s say, maybe a handful of them and you, do you feel like different people hear different things in terms of what the customer might be providing feedback on, and you end up in a… I don’t know if it’s a struggle for approach, but like and maybe some bigger discussions on what was actually given?
Carl: Yeah, I happen to think that you’re touching on something really important, and something that I keep coming back to in the different contexts that I’ve been in is that, and what I would say is an underappreciated source of challenges is if you miss out on making sure that you have a joint view of the problem you have to, I’ve found it to be really valuable to spend a little bit of time to make sure that we as a team, see the same problem that we agree on the problem statement, because if you don’t that can be a long term, like you said, tearing at the cohesion of what you’re building, and it can also be a little bit of a morale killer over time because people keep talking past each other, so I think you’re hitting on something really important. to me, it’s just a matter of communication and coming up with ways and means of making sure that we trust, but check that everybody heard the same thing. And yeah, I guess what you’re also saying is that it can lead to pretty, let’s say, energetic conversations, right?
You have to go back and check with the source and say when you express this, was this actually what you were going after, right? But I think it’s very much worth it to go that extra mile to make sure that everybody- to the extent that they can- agree on a joint problem statement because that’s really at the heart of also, again, cohesive development and some sort of joint idea of where we’re going and why
When is the testing REALLY done?
Ryan: Sticking on the hypothesis development front. How do you and your team feel when you have a proper measurement that leads to a finalized decision on an approach? At what point do you say, “The testing is done over here? We’re going to move on. Let’s go ahead and expand to the next step of the testing.”?
Carl: Yeah, that is a podcast episode on its own. Let me try and see if I can make it brief. I think I’ve over the last couple of maybe 10 to 15 years. So my recent experience is from working with, let’s call it, category maker kind of problems. And what I mean by that is it’s what we’re building right now is not, let’s say, an improved version of something that existed before, at least not as far as we understand. It’s after having spent a couple of years here – what that also means is that at the heart of many of our conversations with users is that we introduce new ways of solving things, solving challenges, or approaching jobs-to-be-done that may not be something that kind of user has extensive operational experience with.
So it’s that aspect of making sure that you actually build the right thing that becomes a little tricky because if you build something in a well-known problem space and you can tap into people who have extensive experience from different ways of solving that problem, you can trust the check. I mean, you can literally make sure that you have a couple of sources that will tell you that you’re doing the right thing or you’re providing additional value.
This is a little bit more of a bet. So it is also – coming back to that cohesion and joint problem statement – about bringing several parties in our team- the product leadership, myself as a CTO, and some of the engineers -into the same conversation and making sure that we read the feedback.
Bringing new ideas into each conversation
This is an additional little nuance here: it doesn’t hurt to bring a couple of new ideas into each conversation. What I mean by that is that there might be a, like, for example, we talk a lot about monitoring and observing applications in a distributed environment.
I mean, monitoring a containerized application in 5,000 locations is wildly different at its heart than monitoring an application that’s running in a Kubernetes cluster. The definition of healthy is different. How to fetch the data that will tell you that applications feel good is different. And the expected behavior of the operational team, if you’re running 5 or 10,000 locations, is different.
So it’s also about leading with some ideas and some thoughts and trying to map that back into the day-to-day of the user and see how that lands and how easy it is for them to actually take that and make it work. Maybe this is a little abstract, but I’m trying to get to the fact that there are no straight and experience-based answers, so you have to really listen carefully, and you have to be a little out there, but not too much.
You have to go and have some leading ideas to see if the direction you’re taking holds water with these early customers or early users.
Bridging the inside and outside
Ryan: Yeah. And that’s a challenging problem when you’re doing truly innovative R&D and tech that has not been in the market before. I know you end up having to depend on getting that feedback to come back.
In order to know whether you’ve been headed in the right direction, what are some of the biggest challenges, though, as you’re creating a category for a product that you think a team faces as they’re maybe holding a flashlight in the dark?
Carl: Yeah. The way my roles, including the leadership side of it, have panned out. It has mostly been that there’s an outside of the organization that could be customers and partners, and there’s an inside of the organization.
And much of what I do is to try to come up with an efficient way of bridging those worlds. So, what can be challenging here is what you’re doing in a category creation situation. And, of course, there’s a lot of literature being written about this that you are convincing the first wave of users to trust that the ideas and the direction you’re taking are to their long-term benefit, and it’s a durable enterprise.
Convincing others that your solution is the best
And that is a pretty nuanced challenge that includes, of course, bringing in all the stakeholders, both from the inside and the outside, and allowing them, let’s say, to take, allowing the external users or the customers if you wish to trust that this is the right way in a fashion that doesn’t scare them.
That takes a lot of work, and it takes a lot of thinking about how to design the software in a way that doesn’t lead them down a path they can’t return from, so you have to be a little defensive. You have to have easy integrations, and you usually have to have easy extensions because there always has to be a way for, I guess, the end user to pivot in whatever direction they feel like they may want to go. So I think that’s at the heart of it. How do you build trust with the end users, and how do you design a system such that it doesn’t lock them down or in a direction that they may want to recalibrate or abandon over time? And then, of course, at the heart of it, like a good product person, I should say make sure that you have a laser focus on providing value. We’re constantly bombarded by obvious things like that. But, of course, that is the backbone of the whole thing.
Keeping things narrow and achievable
Ryan: As you’re creating that trust with the customers or you’re making an attempt to get them to buy into what you’re doing, do you feel like there are too many scenarios that are entered into the equation, or are you able to keep it narrow to something that’s achievable from the smaller team?
Carl: I really want to keep it narrow and achievable. And apologies for maybe some context-specific terms here, but if you think about platforms that will eventually be supporting operational teams day in and day out doing business-critical work.
One of the things that I think maybe the whole industry is underestimating and that I’ll be happy to share with your audience here is that thinking about what could be called day two and day three operations is very much an important part of building trust. In our case, I mean, the platform that we’ve built allows people to deploy containerized applications on a really large scale with some security features and some tenancy features and some generally making it easy for people to operate that.
And as much as I love showing the features when I show deployments to tens of thousands of locations and how they light up on the map and all that kind of stuff, what really resonates in many conversations is when we talk about how to integrate this with the operational staff.
How do you, how do we look at alarms? How do we make sure that if a site goes down, the right people are getting the right actionable information to impact mean time to repair or mean time to service? So, actually trying to think of not just the core, maybe while driving features, but also making sure that you hit everything that has to do with day-to-day work and the operational side of things, I guess my little secret suggestion to be building trust with the end users.
Choosing the best person for the job
Ryan: It’s a really great suggestion. I like how you’re phrasing it in that Day 2/Day 3 perspective because it is a part of the engineering that’s often overlooked because you’re like, “The software’s here, or we got the integration done. We’re finished.” Right? But it’s never that.
Do you actually put specific engineers on that problem? Or do you build that into the engineering ethos that everybody doesn’t just stop at the launch and go further? What’s that process like for you?
Carl: So, in this particular case, we actually have engineers that are really good at that. As a team, we have, again, in previous companies, built software solutions that manage a significant part of the public Internet backbone and other critical infrastructure.
So we’ve been on the hook for those kinds of features, and we work closely with very large operational teams that are very much on the hook for making sure that the internet doesn’t go down for people. So we’ve come to really appreciate that side. And also, actually, a funny side, one of my colleagues is – I only know of two people that have a PhD in alarm management – and one of my colleagues here at Avassa, Stefan, is actually one of those. So, we also happen to have uber-geeky people with academic backgrounds in signing alarm systems and thinking deeply about alarm management. So a combination of experiences is very helpful.
Two types of essential personalities
Ryan: That’s great. As you’re putting the teams together, are you looking for kind of these specific qualities early on? Also, do you have to think about it as it takes off scaling kind of these types of people if you’re growing?
Carl: Yes. Yes, very much. The specifics around my case are that I’ve worked with a group of core engineers for a good while now.
So, we know the talents of the foundational team – and maybe an angle to this that I’ve found to be very interesting as I’m working with these guys is that inside of this core set of engineers, there are also two characteristics or two personalities that are always needed. One they call the fearless coder someone who doesn’t actually fear just trying things out, just absolutely just hacking their way through a horrible problem or something really deep and hard to understand. In our case, we had to build a distributed topic-based published subscriber event logging mechanism for distributed systems, which is a mouthful just by describing it and can be terrifying for those who haven’t done it before. And so, there are two types of programmers needed for that.
There’s one that just goes ahead and starts. They just start doing it, and then there’s the internal, I call them the sweepers – that walk behind the Vanguard and make sure that the code is actually robust, that all the corner cases, all the edge cases are covered, that the test harness is actually covering the right amount of the features here.
Using both personality types to build solutions
And, I mean, you gotta have both. You gotta have someone who’s fearless and can just do it, but at the same time, the durability of that code is usually not good enough. So you need someone to go behind them or beside them and then actually just make it robust, testable, and useful. So we’ve really tried to scale in many directions by having both of those personalities and then, of course, building pretty technical solutions like we’ve done over and over again.
You need a really interesting and statistically unusual type of person that can be a little hard to find, which is they’re going to be easily described as developer-level techies, but with a passion for helping people use the stuff, if you see what I mean, it’s some people call the field engineers. Some people call them solutions engineers. That’s also been a very important part of the trajectories that we’ve been on.
How do we find people who can understand what we’re building down to the software architecture code level and, at the same time, have a passion for translating that into end-user day-to-day operations and user jobs to be done? So that’s been tricky.
Sweden VS Silicon Valley: regional differences
Ryan: Yeah, I think that’s a great bifurcation of those different types of engineers, but I know you’re currently in Sweden. You’ve also worked in Silicon Valley. How much does some of the location aspect of things play, and do you have people currently in different regions?
Do you look to staff some of these roles in different regions?
Carl: We do. We do look to staff from different regions. Right now, almost all of us are in Stockholm, Sweden, which is great in some ways because we can interact easily. It’s a bike ride for almost all of us to get to the office.
So that’s cool. But based on experience, we know that we’re working closer to a situation where we will benefit from having technical staff in various regions. Looking back to the roles that I talked about before, it usually starts with a field engineer systems engineer – someone who maybe doesn’t at least spend the entirety of their day committing code but may commit fixes and commit small pieces of code based on customer feedback and then eventually branch into having actual engineering teams in various parts of the world.
Again, for the type of infrastructure and technology that we’ve built, I guess North America, for some historical reasons, has always been fertile ground. There’s a willingness, I will say in general, to try new ideas and new ways of solving things that are harder to find, to be honest, in many different other regions in the world.
So, we tend to gravitate towards North America as a company and as a group of people for the next steps.
Cultural differences between US and Europe
Ryan: And I know that you actually lived and worked in Silicon Valley for a while. What’s the cultural difference like in North America versus Northern Europe?
Carl: It’s actually both pretty profound but also fairly similar.
I moved over as part of our first steps into North America when we had a company called Tail-f. And I did that literally to be a, let’s call it, a cultural bridge between the corporate culture that is the most common. I don’t want to be too sweeping. Of course, there’s a wide variety of types of companies and personalities in Sweden, too, but if I allow myself to talk about Swedish corporate culture, we know that in order to make a scalable organization in Sweden, we have to actually move a Swedish person or two over to the U S. So I moved first as the, as part of the Swedish team or Swedish family team. And it was really interesting.
There are many things to say about that because we eventually got acquired by Cisco. So, I left and moved to Cisco as a part of the product management and engineering team at Cisco. So, I got to not only work as part of a smaller Swedish team in the US, but I also got to work as part of a much larger organization in terms of Cisco.
Consensus-driven culture
And yes, the cultural differences have been pretty profound to me. To be honest, one of the more exciting things is that, having grown up in Sweden, it’s really hard to think of your own identity because it’s never challenged.
It’s a pretty cohesive and small country, but of course, moving to a country like the U S, suddenly you are Swedish, and you are being treated as Swedish, and you get to explore what that means. And it was truly a really wide range of ways ranging from the fact that we are seen as being maybe a little too kind and friendly, which is like on the softer side of things to, I will say, that’s one of the sweeping things to say about Swedish corporate culture, maybe even Nordic corporate culture is that it’s very consensus-driven. So, I was very grown up with having consensus as the decision vehicle, while, of course, in American corporate culture, that’s rare. Certainly, in large corporations like Cisco, I would say it’s straight-up unusual for leaders in many organizations to seek the absolute consensus of their teams. So those are two things that I found to be maybe at the edges, very different and very interesting for me to experience.
Sharing responsibility for the outcome
Ryan: Which do you think has been more effective in your perspective over your career?
Carl: I’ve had some spectacular success introducing “tempered consensus culture” in American teams. I don’t want to overdo it because that can terrify people, and it goes against deeper drivers. This is, again, my perception from one part of the US, which at times can be a little pathological. As you said, it’s San Jose or the Valley, actually, not only letting but forcing people in your engineering team on the hook to actually sign off on tough decisions and say, “Look, we’re going to do this. We’re going to make this decision as a team. We shall share the responsibility for the outcome. Don’t look to me as some sort of weird dictator.”
To do this and take the entire responsibility, but let’s share the responsibility, really has, at times, changed the game, and I’ve seen it uplift people to the extent that I never thought because it’s harder to be one-sided all the roles, all the traditional roles, maybe in engineering, actually in a company if left to the realm, they will create that little bit of a monoculture.
We’ve all read Dilbert. Bosses are pointy-haired people, and engineer engineers are just heads-down programmers. They don’t care about the rest of the world. My strong experience here is that by introducing a little bit of a consensus culture and pulling everybody into the major and overarching decisions. It’s just made wonders, at least in the teams that I’ve experienced.
Ryan: I can see it being really powerful on projects where you’re breaking new ground as well. And you are in the discovery process like you’re talking about really building that into the culture of working as a team to find answers.
This has been an incredible conversation. I really appreciate you and all of your insights. And I could go miles deeper just on what Avassa is doing alone in terms of the Edge Computing – the automation, but also how you’re working with some of these really interesting engineering challenges that are happening that are off the standard grid is very powerful. So, thank you for being here today. And I’m excited to hear your top five tips.
Part 2. Top leadership tips
Ryan: Welcome back, everybody. Again, we’re here with Carl Moberg today. We’re very excited to hear his top five tips and talk a little bit more in-depth about some of these kinds of hypothesis-driven engineering processes. Carl, it’s great to have you here. Maybe let’s start with tip number one.
Tip 1: Be a servant leader
Carl: Sure. And this is actually something I picked up or was introduced to me at Cisco, so kudos to them.
They had a term called “servant leadership.” It was fairly extreme, even for American companies. It literally said the number one task of a leader is to identify together with the team and remove obstacles. And that’s what we were measured on. How many obstacles have you removed from your team?
See how that almost dictatorial “You’re going to go to where I tell you to go” is gone from that, and you are now focusing on just leveraging on and just uplifting your team. I really like that. And I made it mine in many other contexts: be the servant leader.
Ryan: What are some examples of those obstacles you might be trying to work through in your current company?
Carl: for example, our operational engineers say, “We need to know more about the runtime environments that our customers already have,” right?
There’s no way we can make some of these decisions. You will have to go and find a handful of those roles inside of our users, inside of our trial signups, and get them and present them to us. And we want to talk to them or hear a couple of questions: “Go get that because this is holding us back from making a couple of decisions here.”
I love that. And that’s, I feel like that’s why I’m here. They’re stuck. They don’t have the contacts, and they don’t have the role needed to advance. And I’ll be more than happy to do whatever I can now in a prioritized fashion to unstick them and make sure that obstacle is gone as soon as possible.
Tip 2: Expect people to understand the entire context
Ryan: That’s great. Thank you. How about tip number two? What do you have?
Carl: I think as a leader, you should expect people -and I mean that not maybe in a passive-aggressive way, but actually openly- to understand the entire context around them. Why do we exist? Who is the end user for this? What are some of the subtleties between, for example, marketing and sales?
And how do we satisfy end users, even if you are a programmer? I don’t mean that they should spend their entire days understanding every detail and being kept updated live. But I found forcing people outside of maybe their comfort zone a little bit and helping them appreciate some of the complexities in the other parts of the grand machinery we call a company or a startup has really helped qualify the conversation and remove some of those barriers or maybe some of these unsynchronized problem definitions we’ve talked about before.
So, expect people to be able to understand the context.
Ryan: Yeah. It’s huge. Being able to see the whole picture is a big deal. Yeah.
How about tip number three?
Tip 3: Share success and be specific in your feedback
Carl: Share success and be specific in your feedback. I, at times, find it awkward when I’ve spent a lot of time traveling, and I’ve gotten some really cool feedback about our products, features, and the look and feel of the web UI because I really would have loved the people who actually did it to be with me in the room. So, at times, I feel like I need to invent a way to bottle up that feedback and share it physically with the team when I come back.
But I really try to make an effort to share that positive feedback and be specific in it to actually take notes. We really love the fact, You know, how this feature worked in detail in the web UI and then go talk to the UX teams About that, not just say to the entire team, “That worked well. User loved it,” but be more specific.
So share the success, share good feedback, and be specific in it.
Ryan: Yeah, sometimes that’s lost a little bit because you have to take a lot of information, pass it back, and then, in the midst of that, really feel like what’s going to inspire a team member. How do you keep that specificity when you hear it, when you’re out on the road?
Carl: Again, it’s, and maybe this is just because the teams that I worked with can fit them in a room. I usually know who to say this to, depending on whether it’s a singular little feature, singular detail, or something that kind of cuts through the entire system. I try to make sure to take note of who or what part of the team I should give this to.
So I literally try to make small – digital, of course, but notes on it.
Tip 4: Openly admit mistakes as a leader and be kind to yourself
Ryan: That’s great. Okay, how about tip number four?
Carl: Yeah, so this is maybe one thing that I also try to introduce to the US corporate culture: openly admit mistakes as a leader, be kind to yourself, and make sure to show it. I know the advanced term for this or the advanced term of the effect of this can be called psychological safety, meaning that it’s okay to fail, and it’s okay to really talk about the fact that you failed, that you understand that you failed. Make sure that you, as a leader, do that as well. I’ve seen pathological cases where admitting failure was actually a sort of a risk because the perception was that if I admit to failure, I might get fired or demoted or something like that.
That is, of course, a horrible situation and environment to be in. And as a leader. It’s really important to act like it if you want that more open and psychologically safe environment, so be kind to yourself when you make mistakes and show it,
Ryan: is there a difference between making mistakes? That helped lead to ultimate solutions versus making mistakes that were just not thought through.
Carl: Good one. Yes. Those are different. I mean, at their heart, they are miscalculations. One might be the latter, meaning that it is not really well thought through. Maybe the fix is internal.
Let’s say there are precious few people who can help you do that better, except to see if you can improve on yourself a little bit, maybe change your method or switch up your game in whatever way you think is good and all the former is something that you can approach as a team, is there a way we’re approaching this is there a way we’re working together that can minimize this risk?
Ryan: Of course, it’s easy to go off and start talking about post-mortem as a general approach. Can we discuss what just happened? And can we discuss how to make sure that the chance or risk of that happening again is smaller? That makes sense. All right. Great. And then how about tip number five?
Tip 5: Do the “Swedish love hug”
Carl: Yeah. So this is, this one’s for you and maybe a little more humorous. It’s built on the fact that, again, I brought some Swedish corporate culture to bits and pieces, small bits and pieces of the American corporate landscape. We have a colloquial term called the “Swedish love hug,” which is a pretty, pretty funny thing.
At times when you feel that you are going into a meeting or some sort of context where there will be a little bit of animosity, just being super constructive and super kind and super, I don’t want to say happy because that comes across as a little cynical, but just go in and be very open, very constructive and very passionate about the solution can do wonders.
I’ve seen meetings that could have gone south really fast, completely change in character if you go in with a Swedish love hug, and just make sure that everybody understands that ” I’m here. I want to make a great difference. I want to hear what you guys are saying. I think we can do this. There’s no need to spend any time trying to be combative here. “I’ve seen that change rooms over and over again. So, the Swedish love hug is a little bit of a secret weapon for everybody.
Ryan: I love that. That’s your final tip. And it’s also got to be the title of your memoirs, of course.
I think that’s a great one to end on. We appreciate all of your insights. It is really good to hear from somebody who grew up in a different culture of how technology is built than one that I’m involved in on a regular basis. And these are some great tips that we can always bring back to our companies.
Carl: Thank you.
Ryan: Thanks for being here with us this week. I hope everybody enjoys this episode.