balenaLabs Residencies: our quest to improve onboarding at balena

Learn more about balenaLabs Residencies and read a reflection on how balena used the feedback and observations of new joiners to improve onboarding and put new teammates on a path toward success.

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.

Summary

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.


Posted

in

Notable Replies

  1. That’s a great article Phil, I so identify with the issues of onboarding you discussed and think the idea of building a project as part of the process is really excellent. I work for a large governmental science organisation and have found it hard to get established in scientific software or monitoring systems teams. I got through it but it took a lot out of me and could have been a lot better.

    Actually for the team I now work for, when I joined I latched on to a problem I could see they had and did my own project (using Balena) to produce a solution that I could demonstrate to my manager and team. This quite shocked them as they aren’t used to individuals doing projects – normally they have lots of meetings, project managers, solution architects etc. !

    At least it showed them what was possible and that I could contribute with the skills I had (as well as being perfect for me learn about Balena), but I must admit I still find it an eternal struggle when it becomes obvious that a lot of the corporate and technical thinking is stuck in the past. A lot of the people in my team don’t have very up to date technical knowledge so half my struggle is trying to explain concepts to them. Oh well sounds like Balena is great company to work for.

  2. Thanks @markysparks , and good to see you here again. :slight_smile:
    I’ve used your posts about your temperature sensor project in several talks about balena blocks, and I’ve been wondering how you and the project are getting on.

    I work for a large governmental science organisation and have found it hard to get established in scientific software or monitoring systems teams. I got through it but it took a lot out of me and could have been a lot better.

    Exactly: people do get through, but at a cost. The traditional thinking seems to be that people have to do a job to learn a job. Whilst there is an undoubted element of truth to that, we feel that it’s probably the thin side of the 80/20 rule. Onboarding by making a project gives you 80% of what you need, such as learning the company processes and culture and brings you into contact with colleagues.

    normally they have lots of meetings, project managers, solution architects etc.

    Ooof, you’re bringing back painful memories of past jobs! :laughing:
    We don’t do all of that at balena either: The Methods & Motivations of Balena’s Organizational Structure (substack.com)

    (TLDR: we don’t have organisational hierarchies, or siloed teams, or rigid job descriptions, or meetings in the traditional sense of the word. We turn meetings into a game called ‘brainstorm’ :slight_smile: )

    I still find it an eternal struggle when it becomes obvious that a lot of the corporate and technical thinking is stuck in the past.

    For sure! I spent ~15 years in the biggest of big corp’ until I couldn’t take it any more.
    I don’t think the balena way is for everyone, but it sure suits me. :blush:

  3. Hi Phil – the temperature sensor project is moving along … very slowly! I’ve had a setup on test for ages, and its been working absolutely fine, but getting it out to a real world site seems to involve so many people and so much planning, then you have people leaving and COVID…

    Then I was asked to produce a version without a display to put on site initially! (yet the display was one of the main features…sigh…). Of course when you have so many people and teams involved this is what happens, people start to overthink things before you’ve even tried it out. I will just keep plugging away, hoping to get a unit out on a real site this month.

    I’ve been very happy with the setup itself, the only slight issue I had was WiFi connect failing to reconnect on occasions but haven’t seen a re-occurrence of the issue for sometime (could have been external issues). I want to see how far I can push the spread spectrum radio link to the sensor but think it will be good for 1 KM which is way more than I need. The Grafana dashboard looks great.

    Another project I’ve been working on involves collecting multiple sensor data from a Campbell Scientific data logger via a radio or RS485 link and using the Modbus protocol. The collected data can then be processed and sent on to multiple online services. I’m using MQTT internally on the IoT device and have a local Grafana dashboard etc. It shows some promise but they’re not ready for this just yet… :joy:

    The Balena ecosystem, blocks etc. makes it so much easier to try out this sort of stuff :+1:

  4. Hey @markysparks

    getting it out to a real world site seems to involve so many people and so much planning

    Prototypes are easy, production is hard .” — Elon Musk
    :laughing:

    I want to see how far I can push the spread spectrum radio link to the sensor but think it will be good for 1 KM which is way more than I need. The Grafana dashboard looks great.

    This sounds amazing! I’d love to learn more about how you are doing this, and what else we could do with the project. Do you think it would be possible to put this functionality into a block, to make this easy to recreate in other fleets?

    @andrewnhem and I would love to get you onto a YouTube stream and chat about your project! :grin:

    Another project I’ve been working on involves collecting multiple sensor data from a Campbell Scientific data logger via a radio or RS485 link and using the Modbus protocol. The collected data can then be processed and sent on to multiple online services. I’m using MQTT internally on the IoT device and have a local Grafana dashboard etc. It shows some promise but they’re not ready for this just yet…

    This sounds cool too! I’m currently working on a new version of the connector block , which is a complete rewrite using dapr.io
    My hope is that it will auto-wire any services running on the device with the block, but also be super easy to wire it up to cloud services. I might ping you a docker image reference when I have a beta version that needs some friendly, compassionate testing. :slight_smile:

  5. Well the two radio units connect via RS232 to the sensor and via USB to the Raspberry Pi (they show up as USB serial port), so that bit is quite simple and just acts like a serial cable replacement. Collecting data from an RS232/485 serial interface (that many industrial sensors use) would be nice to have in a block but the problem is manufacture’s all use different commands and data formats when communicating using ASCII data so no standardisation. I suppose this is why protocols like Modbus and SDI-12, NMEA were developed. I could see the value in having a Modbus block where, say you specify a Modbus address and holding register address to read a sensors value. Something I will think about when I get time. Python’s Pymodbus module is a full Modbus protocol implementation that I’ve been using (but not for the temperature sensor which is just ASCII data).

    I also have a small Python Flask web application running that enables an end user to configure the sensor (calibration coefficients etc.) to make things easy when the time comes to replace it. Of course this could easily be done via the Balena dashboard using device variables but that full featured dashboard would be too overwhelming for the people who would be doing this.

    Ideally I would say use the Balena dashboard and then the new sensor settings could be updated remotely, no need for an end user to do this. This has got to be the best way and how things should work, however I have to convince people to use and pay for Balena dashboard and show them how it could replace their current workflow. I can see the advantages and I know it would be far more cost effective in the long term for all sorts of reasons, but I have to try and win people over stage by stage. I’ve got my work cutout! but I’m hopeful that eventually we will move towards this solution. At the end of the day though I have to say to the end customer, here’s my solution and let them decide.

    Happy to chat about this if you like…

    I had to look up dapr.io, must read up more about it but on the face of it sounds really interesting and useful for this kind of stuff!

  6. Hey @markysparks – sorry for the late reply, I’ve been off for a bit.

    I could see the value in having a Modbus block where, say you specify a Modbus address and holding register address to read a sensors value

    This would be great, and reminded me of some work that @rmorillo24 is doing on a personal project:
    Build log: Detecting if the main water pipe breaks – Show and Tell – balenaForums

    I also have a small Python Flask web application running that enables an end user to configure the sensor (calibration coefficients etc.) to make things easy when the time comes to replace it. Of course this could easily be done via the Balena dashboard using device variables but that full featured dashboard would be too overwhelming for the people who would be doing this.

    This is another thing that we have thought about, and there is some work surrounding. We have been calling it a LocalUI, and the basic premise is to expose configuration and device management features on a UI served by the device itself. Any services on the device could also augment this UI with it’s own UI, such as balenaSound surfacing the controls for volume and multi-room config.
    Again, you’re ahead of the curve here, but we have heard the feedback for this need, and we are working towards it. :slight_smile:

    @andrewnhem and I would love to get you onto a YouTube stream and chat about your project! :grin:

    Happy to chat about this if you like…

    I will be in touch! :grin:

Continue the discussion at forums.balena.io

Participants

Avatar for phil-d-wilson Avatar for andrewnhem Avatar for markysparks