In this and a number of successive posts, I’ve started conducting interviews with exceptional leaders that have a unique perspective on how to build and manage remotely distributed teams. To kick the Distinguished Leader Series off, I’m pleased to present my first interview.
Henrik Hussfelt, the Director of Engineering at Proxy
Jonathan Siddarth, Turing:
Welcome to Turing’s Distinguished Leaders Speaker Series, Henrick. We are conducting this session so that our audience, which is primarily engineering leaders at high growth startups and large tech companies, can walk away with tactical best practices, to be more effective as engineering managers.
So, Henrik, you’re Director of Engineering at Proxy. How did you get into engineering?
Henrik Hussfelt:
I started with LAN parties where you put a bunch of computers together and play games. I even attended Dreamhack a couple of times and helped up there. Then went into software engineering as an entrepreneur. So, my best friend and I started engineering things and building websites for people. We also engineered quite a few cool systems at the time, way back in the early 2000s, like website control panels.
We were pretty good engineers, but we were not so good at selling our stuff一the usual issue entrepreneurs have, especially engineering ones. Then, I went up to Stockholm and started engineering as a contractor for different people and companies.
I ended up in quite senior leadership roles early on, CTO kind of thing for high-growth companies. I was 24-25 years old. I worked a lot and went into startups, multiple ones. We were doing what we call back then Spotify for books.
Then I Bounced around EdTech, something that I still hold dear to my heart. After that, I ended up in a meal kit delivery company. I spent a bunch of years there, took another break. And then finally, found Proxy where we’re now residing.
Jonathan Siddarth:
It’s fascinating the kind of entrepreneurial journey you went through. I made many mistakes in my first startup because I don’t think I fully understood distribution and many other aspects of company building beyond writing code.
Henrik Hussfelt:
Right, exactly! The things that you learn from the most are your mistakes. So the earlier that you mistakes, the quicker you’re going to get better at what you’re doing.
Jonathan Siddarth:
Tell us what Proxy does and what your job entails, and then we can go on to the other questions.
Henrik Hussfelt:
Proxy is all about your digital identity in the physical world. We’re trying to build something that represents the digital part of identity and bringing that out into physical interactions.
Our journey began with solving the ‘access problem.’ So we built technology to both repair and replace and interact with already existing systems like access-control systems. Meaning, instead of walking carrying around access cards that look something like your driver’s license, you just carry around your phone. And when you approach a door, it magically opens for you.
We want to enrich the experience so that you can carry your digital persona and identity securely on your phone.
Jonathan Siddarth:
To me, it sounds like you’re walking around with a key in your hand, which is your phone. The key can unlock doors and unlock personalization, but the user is in control.
Henrik Hussfelt:
Yeah. Proxy is more about you telling the world what you like. It enables certain environmental things when the user explicitly shares certain identity sets to other peripherals around them.
Jonathan Siddarth:
I love that. Very, very cool. Now, let’s jump into our main topic of engineering leadership and engineering management. Can you tell us a little bit about how, in your view, managing a distributed team is different from managing an in-office, on-prem team?
Henrik Hussfelt:
In a sense, managing is about people skills and understanding. Like, you have a toolbox of tools, you have people. They know different things, and they’re good at different things. They also have different personality needs.
You can regularly pick up on these things when you’re at the office. It’s easy to see someone struggling with something and help them out. When you’re distributed, and you don’t enforce facetime—not meaning like FaceTime as in having a call with someone—you have zero interactions.
So, in a distributed environment, you need to make sure to engage with your peers naturally. You can do that by having frequent one on ones.
I make sure that I make time for my team, even if they take a whole day of my week every week. I make sure to talk to people about everything—from personal stuff to what they’re struggling with on their current task—everybody’s different and communicates in different ways.
Some talk about technicalities, others talk about their kids smashing their TVbecause they’re working from home.
But what I’m trying to relay here is that personal interactions are pretty important in a distributed environment, more so than they are in the physical one. You meet almost every day in a physical environment, and you pick up on these subliminal signals that people expose. In a digitalized, distributed one, you’re going to have to pick up all those in Zoom sessions. You’re going to have to watch every face and see how they receive your message.
You need to pick up the cues instantly they’re giving and talk to the person afterward, so it’s much more challenging. But it’s also easier because every time you have those one-on-ones and when you’ve been doing them for a while, it’s even more private than it is sitting in a meeting room with someone. They are in their home, you’re in yours, and it’s just you and them over a shared conversation.
When you’re doing a one-on-one at the office, you call someone into a meeting room, and everybody sees that person going into the meeting room, and they know that the one-on-one is going on, and it’s different. It can be much more personalized in this distributed way.
Jonathan Siddarth:
You’re spot on! What is your framework for running an effective one-on-one? Do you have any specific prompts or a specific structure that you follow? Or do you kind of let it happen more organically, besides blocking the time and ensuring the meeting happens?
Henrik Hussfelt:
So besides booking the time, I do like repeating meetings every week. We have our every Monday walkthrough where everybody talks about the weekend and the challenges they’re facing. Secondly, I use a tool to put their questions or anything they want to relay over the one-on-one. This way, I’m prepared.
You need to ensure that you build rapport and communicate with your peers.
Similarly, make sure that you take the temperature of the team now and then. Ask your people how they feel about the current projects that they’re all in.
So, both specific and generalized questions are essential. They help you in understanding how each team member is feeling.
Jonathan Siddarth:
That’s great, Henrik. You mentioned a tool that you use. What tool is it, and how long are your one-on-ones?
Henrik Hussfelt:
So, the length of each one-on-one is 15 minutes because I do them weekly, and I see these people regularly on other occasions as well. The tool that I’m using is called Get Lighthouse. I’ve been using it for somewhere between five to ten years.
Jonathan Siddarth:
So, for an engineering manager who’s about to manage a distributed team for the first time, maybe this is somebody who has predominantly managed teams working side-by-side in an office, switching to managing a remote distributed team for the first time.
What’s your top piece of advice to succeed at the job?
Henrik Hussfelt:
It’s not so different from an on-site situation. First, you need to identify your champions. Then, if you’re also new at the company, you need to ask many questions until you understand what you’re doing.
Starting a new leadership position is much harder in a distributed team. First, you need to be on top of everyone and catch as much facetime as you can. As a manager, you are always playing a puzzle, right? You’re trying to figure out which pieces go where. The only way to do that successfully is by interacting with as many people as possible.
When you come into something new, it’s better to expose yourself as you have no idea what you’re doing. So, being open and transparent is especially important. You can just say: “I need to know this, so you need to explain it to me like I’m a five-year-old. Do it until I get it. And I’m going to keep asking these questions until I get it so that I can do a better job supporting you.”
That’s how it works.
Jonathan Siddarth:
On that same note, Henrik, how do you approach onboarding a new engineer to your team? Is there something specific you do to ensure somebody you’ve just hired is set up for success and ramped up correctly? What is your advice on onboarding a new member to an engineer?
Henrik Hussfelt:
I think one of the best assets that I could relay here is how GitLab does it. They have a publicized wiki on this. I would just go and read that one. They’re very transparent with their onboarding.
Internally at Proxy, we don’t have enough people to expose these things, but we generally follow something similar. We have a wiki page with all the resources you need as an onboardee. In addition, we have a couple of meetings that everybody goes through so that the onboardees get to talk to multiple people in the organization.
We also have mentorship. The mentor is not supposed to answer all the questions, but he’s a gate into the organization. So whenever a mentee asks a question, the mentor refers the onboardee to the person who can answer it.
Each organization is different, so it’s all about finding the keys to success within yours. But transparency is essential. The more transparent you are with all the content you have—with good documentation, transparency on who’s doing what, where, when, and all these kinds of things—that I think is the key to success.
Jonathan Siddarth:
That makes sense. When somebody has joined the team and is ramping up, what do you do to create meaningful bonds and relationships between that person and others on the team to be much more closely integrated with the team and with the company?
And are these things that are easier to do when you’re in an office? How do you manage to do that in a distributed team?
Henrik Hussfelt:
I think it’s all about interactions and directing people to the right people with the knowledge they seek. For example, let’s say I have an onboardee, and he needs to get serious with this set of APIs that he hasn’t touched before.
We probably have someone who’s been there a lot. I would introduce them and say: “Go talk to this guy, and set up some coding sessions.” We do a lot of pair coding. And we always emphasize on the part that there are no stupid questions, just stupid answers.
So, ask a lot of questions. If you set that culture right from the start, then you’re going to have a much easier way forward.
Jonathan Siddarth:
Is there something intentional you do to make sure people connect beyond a need-based setting? Is there anything you do to have people interact in an agenda-free setting, where the sole goal is to build authentic, personal relationships?
Henrik Hussfelt:
That’s an excellent question. We can do this in the fun retrospectives we have. Now we’re growing quite large, so we have sub-teams, and they’re doing their retrospectives, but we were smaller initially.
I think that if you have a thriving culture, these things tend to happen by themselves. If you make sure to hire the right people and get them engaged, they tend to join on the same type of interests. And the more they collaborate and work together, the more joined they are at their hips, right?
So I think to answer your question, this is more about building successful teams and understanding how to get every person, being a cogwheel hooked together, and turning simultaneously with a joint vision. And of course, we do team events but now with COVID, not so much.
Right now, the little things tend to go a long way to make people happy.
Jonathan Siddarth:
What’s the strategy for you and your team post-COVID? What’s your plan in terms of in-office versus remote versus hybrid structure? What’s your opinion on what you’re about to do?
Henrik Hussfelt:
So as a company, Proxy is not fully distributed, and that’s our intent. We are working with hardware, so we need physical locations.
However, we consider ourselves fully distributed. We’re not going to go back to any kind of office. And to be very frank, I was among the first distributed people in the team. I was in Sweden and the rest of the people in the US, and then we built a distributed team.
Jonathan Siddarth:
That makes sense. You and Proxy as a company were ahead of the curve in embracing distributed teams, particularly among Silicon Valley venture-backed companies where the traditional mindset is: “Let’s build a team in Palo Alto, or let’s build a team in San Francisco.”
I think it was Proxy, Elastic, GitLab, and a few other companies that had embraced the value of distributed teams than it is now. So today, it’s shifting to a more mainstream model.
Henrik Hussfelt:
I think talent is everywhere. Of course, some talent tends to want to be in places like Silicon Valley. But there are many talented people out there globally, and they’re not willing to move.
Now, we’re seeing a change where these talented people can sit anywhere and work with anyone. And this is just the beginning of that shift. There are a lot of hurdles. People are afraid of IT leaks and hiring across the globe, but we’re going to get over those things as well.
There are time zone issues too. I guess we want to find a way to re-invent time zones, but frankly, that will not happen soon. So, having people working between Silicon Valley and Thailand is hard, and the same goes for China and Australia.
So, you need to ensure that people can collaborate on the right sleeping pattern. I think that’s quite important. The shift towards distributed teams, especially in engineering and any kind of work, will be the future.
Jonathan Siddarth:
Speaking of time zones, how do you get around time zones in a distributed team? What is your approach?
Henrik Hussfelt:
So this is a tough one. I think this is where, as a manager, you need to make a choice. Managing a distributed team across time zones requires you to work peculiar hours. You need to understand that if you have people in Asia and the US, or you live in Europe as I do, the only natural thing to do is get up early in the morning and work late at night. Now, you have to find your way to that.
As a manager, you can make sure that you have team members in equivalent time zones. So I think time zones are something you need to be aware of. And you need to pick your battles and make your own choices.
Jonathan Siddarth:
And for your team, is there a specific time zone that you set for everyone. Is there an expectation that you have agreed upon? Or does everyone work in their time zone?
Henrik Hussfelt:
No, everybody works on their own accord. I do not care if people work from nine to five, or three to 12, or split their day in half. Personally, when my kids are here, I’m always off between 4 pm and 9 pm. You can reach me if it’s an emergency, but other than that, I’m off. So trying to get people into the traditional working hours is going to be tough. Your team needs to collaborate on setting their standards. You’re not managing them into that.
I think the better choice is to tell the team that they are in charge of getting things through the pipe. This is the project. These are the expectations. The team’s job is to deliver. How they deliver is up to them. They need to communicate with each other and set their own rules.
Jonathan Siddarth:
Let’s say you have this globally distributed team making a systems design decision, which requires brainstorming with others on the team. How do you find time across different time zones?
Henrik Hussfelt:
The benefit of having flexible working hours also comes with the downside of finding a time that works for everyone. We’ve made sure that our teams are architecturally working on the same thing, so it’s easier for PST to work with CT. But, sometimes, someone needs to stay up late or wake up very early. That’s just the nature of time zones. So, if you’re a manager and you have the power to get people to work on certain things, then, for the love of God, make sure that you don’t connect the whole globe in one single team.
The teams just need to find their touchpoints to relay whatever has been going on during their day. If they do that asynchronously on Slack or in whatever medium they prefer, you’re good to go. But for intense teams scattered on all the time zones, it’s tough to push things through.
Jonathan Siddarth:
When growing your engineering team, what do you look for in an engineer who can join your team and make an impactful contribution? In your view, who is a great engineer?
Henrik Hussfelt:
That’s an excellent question. I almost always recruit on personality. It has to be a personality match with the team members that I already have. You need someone communicative enough that you can just put them into this environment that I talked about before. They need to ask their questions, and they need to be engaging with others and getting to the single source of truth by themselves because we’re all distributed, and nobody’s going to serve them what they need on a silver platter.
An engineer has to be self-sustaining and able to get the answers they need by themselves. I think communication and personality are critical because some people have challenges that you can’t manage away. It could be a personality thing or something that you can’t get rid of. If you have those strong warning signals, then I tend not to engage further.
So personality, communication, a positive attitude, and openness are things that I look for.
Jonathan Siddarth:
Can you talk a little bit more about personality traits? What personality traits do you and your team look for that you found to be an essential ingredient of a high-performing engineer?
Henrik Hussfelt:
That’s tricky! To create a successful team, you need different types of personalities to work together collaboratively. So you can categorize this in different ways. You have the grunt, they’re working in the background, they’re high performance, they see a task, they know what to do, and they just do it.
You have the more loose people who are more architectural thinking. And you need the people in between to connect the dots. You need to find the ones that can still communicate. And you need to be able to manage those people so that they communicate on a level that other people can interact with. There are so many different ways of looking at people; this is just one of them.
Whenever you have a team of five or multiple engineers, that’s when it gets interesting. You need to look at all of them to find the next one. And whenever you need to split them up, you need to start looking at which ones to put together. It’s not so much about looking for any kind of specific person, as it is about evaluating your current situation and finding the next hire.
Jonathan Siddarth:
That’s super interesting, Henrik! And I’m going to end with one final question. What are the elements of a terrific engineering culture? What does a high-performing engineering culture look like to you?
Henrik Hussfelt:
The first word that comes to mind again is transparency. You want openness. You want channels in which team members can talk about their issues and get help from everyone collaboratively. You want to set a culture where it’s okay to ask any question. This way, you’re going to have a much easier way to onboard new people and keep the information flowing. I think that’s the key to success.
Humor is quite important too. Having a positive attitude goes a long way. So, culturally, I think transparency and pushing that positive attitude downwards are critical points.
Jonathan Siddarth:
Your perspective is super helpful, Henrik. I think this is going to be incredibly valuable for all the engineering leaders and managers out there.
Image Credit: from the author and engineering vector; freepik dot com; thank you!
The post Turing Distinguished Leader Series: Henrik Hussfelt Director of Engineering at Proxy appeared first on ReadWrite.
