02 December 2021 / Last updated: 02 Dec 2021

balenaLabs Residencies: our quest to improve onboarding at balena

Onboarding is more than learning your new role and meeting teammates. It’s also about managing your own expectations, that of others, and finding a way to get as much context about your new role and company as possible.
balenaLabs logo
Here's how balena used the feedback and observations of new joiners to try a new way to onboard new teammates and put them on a path toward success.
I remember my first day at balena in early 2020. I opened the lid of the shiny new laptop, powered it on, accessed my personal email account, opened the "Welcome to balena!" message, and logged into group chat for the first time. Immediately, I was met with a multitude of chat rooms, bustling with activity as clever people discussed hard problems, from all over the world. My "balena buddy" dropped me a message telling me to ask him any questions I had, and gave me links to the company wiki and some videos of presentations given at past summits. And then it was time for me to onboard myself.
I was very lucky, in that I joined the balenaLabs team. Labs is our research and experimentation team, and at the time it was being led from the front by an ineffably kind and capable Hardware Hacker named Chris Crocker-White. So I had a great role model to help me find my feet as a balenista, and yet I still found "onboarding" a worrying and stressful experience.
There was so much to read. So many chat groups to try and follow. So much context to absorb. So many people to try and meet. And how on earth was I going to do something impressive and prove to these people why I belonged at balena?

What we noticed about people "onboarding"

My experience is not unique to me, nor unique to people joining balena. It's common for people to start a new job and to take time to get up to speed with what they are doing. There are lots of things to learn, people to meet, and processes to become familiar with. Balena works in a way very different to where the majority of new joiners have worked before, which may compound the issues further. This was especially true for me with my "big corporation" background.

What’s so different?

At balena we structure the company around information, not job titles and hierarchy. We don't work in siloed teams, but in feedback loops. And we don't perform specific jobs or complete assigned tasks-- we self-organize and build products.
I spent a week watching presentations and reading the company wiki, and I thought I understood the principles, but I didn't know where to start trying to live it.
Since balena hires smart people to solve hard problems, everyone who joins is driven and eager to contribute. They may, like me, have come from very competitive, corporate backgrounds, where you start at the bottom of a reputational ladder, and need to continuously prove yourself better than others in order to climb.
And so often people have a real need to contribute straight away, feeling the need to prove themselves worthy.If, again like me, they suffer from a degree of Imposter Syndrome, this need is felt even stronger. And so they find a way to contribute immediately. They may go off and make something (that our users may or may not need). Or, find a business process and try to change it (whether we need it or not). They try to use something that made them successful in the past, and recreate it at balena. But without having slowed down and given themselves time to absorb context, ask questions, learn the culture, how on earth can someone successfully contribute straight away?
Balena solved all the easy problems they set out with, and only have hard problems remaining. So, it has been known for new joiners to jump into trying to contribute, misjudge things, and end up with a negative experience. This feeds their need to prove themselves all the more.
It becomes a costly cycle, which can lead to burnout and opportunity costs along the way. It was clear we needed a better way for newcomers to “learn the ropes.”

A better way to onboard

So how do we help people join a new company, encourage them to take their time and absorb context, learn the products, and meet the team in a way that feels organic? At balena we think the answer is through fun, play, experimentation and creative freedom, supported by a team of enthusiastic balenistas. We call this method a Labs Residency.
Everyone who joins balena, after a few days of making some accounts and working out the group chat, starts a residency in balenaLabs. They think of a project they would like to work on, and spend the next month doing just that. They take a technical project, which uses balena products, all the way through from ideation, to design, to building, testing and finally publication as a project or fleet on balenaHub.
To cornerstone their residency project, they write a public post on this blog. During this month their sole focus is working on their project. They can attend any meetings, like all balenistas, but they do no other work tasks than progress their project.
The resident has total control over their project, but they are far from on their own during it. They are supported by a cast of people from the team:

The project Sherpa: guide & number one fan

This will be an experienced balenista, preferably from the resident's future team, who will act to guide the resident through their project. The two of them have regular video calls, to chat through ideas and progress and give the resident that "go to" person when they are not sure how to proceed.
This sherpa may be able to help with technical questions, but more so their role is to guide the resident in how we work at balena. They'll encourage and exemplify how we work in the open. They'll unashamedly ask questions when they lack knowledge themselves. And they'll work using first principles and collaborative sense-making to help the resident solve hard problems.

The balenaLabs team: a family of enthusiastic product builders

I'm utterly biased, but the balenaLabs team is the most fun, most supportive, technically gifted set of people around. They are at the beck and call of every resident throughout their time in balenaLabs. Any questions the resident may have, from getting ideas for a project, to advice about hardware, help with coding, testing and writing a blog, the balenaLabs team is there to help.
Since everyone who has ever spent time in the labs, including past residents, is considered to forever be part of the balenaLabs team ("once labs, always labs") this pool of experts is constantly growing.

The Outreach team: helping spread the good word

We also have a team of people to help anyone who wants to make a video or write a blog post. So when it becomes time for a resident to write a blog post about their project, all they need to do is put some words down in a document, and the outreach team work their magic. At the end of the process, the resident has a well-written post, still in their own voice and accompanied by beautiful illustrations and diagrams.

What makes a successful project?

Here's an example demo project of a voice-activated mood tracker by a Labs Residency graduate.
So you may be wondering what constitutes a viable project for someone to spend a month doing? Surely balena want something they can use or make money from, for that time, right?
Not necessarily.
What we want is for the resident to make something, using balena, to solve a problem that they find interesting or really care about. It can't use any special access or privileges from working here.
So, it must be something that any other user of the product could have made themselves. And at the end of the residency, we want to put the project up on balenaHub, and let other people make use of it. It can't be something like a code example or a proof of concept. It needs to be a working project that solves a problem.

Here's another Labs Residency graduate project: smart curtains that help improve quality of sleep.
Here's some examples of past resident's projects:
SPECIAL NOTE: Massive shoutouts and props to Julia, Peter, Eduardo, and Andrei for being our first graduating class. Your journey and feedback paves a smoother path for our future residents! We appreciate you all.

How does building a project help you onboard?

On the face of it, it might seem like folly to spend the first month of a new job building a project that opens your curtains or waters your herb garden or tracks your heart rate. But at balena, we think it's the best way to spend that time.
Building a project immediately puts a resident into the situation of being a builder of products, which all balenistas aspire to be. They need to find a problem they want to solve, and then use the way we work to solve it. They need to work in the open, ask questions and work with others to make sense of the solution space. To map the problem and their proposed way forward. They use feedback loops to inform their work and "course correct" when needed.
Building a project also puts a resident into the situation of being a user of balena. They now have a problem they want to solve, and they need the products to help them do that. They get real-world experience of using the product and learning all of it's surfaces. They read documentation, try examples, build things on top of our base images and use functionality from our balena blocks. The residency is akin to conducting field studies in the balena products.
During this process, residents may find things they didn't understand, identify documentation that was out of date or didn't make sense, or discover areas that added friction to their project building. They can provide that invaluable feedback straight into the balena team, and advocate for any improvements to be made. A project to care about gives new joiners immediate "skin in the game."
Building a project necessitates using the balena team for collaborative problem solving. What better way to meet people within a company than to work with them to find and solve problems? Sure, social events are a good way to chat, but a lot of people find those tricky at first until you have some shared experiences to chat about.
When you have a cool project, but you can't make your balenaFin change the color of its LED, you organically hang out with the balenaFin team and hack on some code. They turn out to be a cool bunch of hardware guys who then tell you about something else your project could do.
A personal project gives you something to chat about, and start to create those shared experiences. After all, a cool project is a cool project and people here always want to hack on those!

What about less-technical people joining balena?

We believe that working on a technical project in the labs residency is the best way for a new balenista to integrate into our culture, even for those that are less technical. Someone joining the company to work on the business’s background operations and processes would, in theory, be able to do that without having built a labs project first. However, it's our belief that they'll do an even better job, and find their feet even quicker, if they've spent a month gaining context about the users that those operations and processes enable.
If the person is non- or less technical, their feedback and experiences are all the more important for the rest of us to hear. Technical people are used to assimilating product documentation and learning how to use a piece of software. Technical people may accept friction to their project development, because they are used to working around bugs and missing features. But non-technical people may be more likely to ask "why" something doesn't work, or is non-intuitive.
We don't want balena to only enable deeply technical IOT edge developers. Our mission is to unlock the potential of physical computing, and the more people we enable to build solutions to problems they perceive, the better. We must learn how to enable anyone to use these technologies.
A non-technical hire would be placed with a very technical Project Sherpa, to give them that comfort of capable guidance. However, we think the real answer is to give non-technical people enough tools to enable them to create solutions to problems for themselves.

Examples include

Base images: we work hard to ensure our base images, the bottom layers of a containerised application, provide features and remove friction wherever possible. They make it simple to get started with a programming language, installing additional packages and debugging things when they don't work the first time.
balenaBlocks: packages of functionality all wrapped up and ready to drop into any project. It's completely possible to build a project solely by combining blocks like mixing ingredients to make an IOT cake.
Being technical or able to write code shouldn't be a barrier to solving problems with balena. And having fun making projects shouldn't be limited to technical hires.


Onboarding to a company can be a dull and stressful procedure, and can cause negative experiences for some. At balena we think that letting new joiners choose and work solely on a project of their choice, is the best way to gain context, learn the balena culture and put themselves in the role of our users.

We often stream our IoT Project Clinics where we live hack, answer questions, and hang out. Our working theory: the team that plays together stays together.
We believe that people come out of a balenaLabs residency with more product knowledge, more organic team relationships and much more of an idea of how they could successfully contribute to the balena mission. Plus, they have a project that they care about, and can continue to work on whenever the need takes them.
More than anything, we think people joining balena get to avoid the stress of "getting up to speed" and concentrate on having fun. Make a robot. Make a geiger counter. Make whatever you want, and become a balena product builder while you have fun doing it.
Think we’re right? Wrong? Wanna discuss? Let us know your thoughts in the comments below.
by Phil WilsonCTO and co-CEO