Homelabbing for Engineering Leaders

Homelabbing for Engineering Leaders
Fortepan / Rádió és Televízió Újság (1954)

I’m so grateful for this recent discovery that I want to share my experience and thoughts about the topic. For those who don’t know what homelabbing is (like me 2 months ago), here’s a short AI-assisted definition:

Homelabbing is the practice of setting up and maintaining an environment at home where one can explore and experiment with different technologies in software and hardware, outside of a professional environment. Typical examples of services one might run in a homelab include: media- and file servers, websites, finetuned local network, home automation, game servers, etc.

It’s not like playing with a server at home is new to me, I’ve been running Plex for about 15 years by now. But if you’re a follower of my newsletter, you saw how I recently discovered a lot of developments in homelabbing. Tinkering with my setup made me realize that not only is this a lot of fun, but also how it helps me train skills valuable to my Engineering Manager role — and similarly, these could benefit strictly technical leaders too.

So here’s a list of why I believe every Engineering Leader should play with a homelab project (and be proud of it!):

🧑‍💻 Starting with the obvious: you refresh and extend your concrete technical competence in an area. It can be anything from virtualization/containerization, networking, shell scripts, or hardware setup. Some of these are directly transferrable to a work context, though that’s often not the case. Still, they give a useful foundation to have an up-to-date understanding of how networks, containers, and general security work on a small scale. For example, I recently learned that to expose parts of your home network you don’t necessarily have to open ports on your router and set up forwarding: in most cases, it’s safer, easier, and more reliable to create a tunnel to an external service like Cloudflare that handles everything for you.

📚 Homelabbing by definition covers a lot of different areas. This variety will increase your T-shaped knowledge: you’ll get a comfortable high-level understanding of multiple different domains while digging deep into very few. Getting this broad knowledge is useful for both Engineering Managers, who can extend the number of areas they are comfortable with; and strictly technical leaders, who are often prone to deep expertise in only a few smaller areas.

🧑‍🎓 In a more general sense, learning about something new is exercising important skills about how to approach an unknown topic as a beginner; how to balance the depth and breadth of knowledge to reach a sufficiently high level of understanding; how to apply the knowledge you’ve just learned in your specific context; how and where to take notes so they can be found later; and eventually, how to share this knowledge and help others.

🧑‍🚒 Being the sole owner of a service having to provide 24/7 on-call support teaches you great incident mitigation skills that are directly usable in a professional context too. Bringing down the wifi with two children at home is arguably comparable to the stress level of a production incident, so you learn from experience that mitigation is the immediate priority, and a proper resolution can wait until after the user’s pain is stopped. Another good learning is how important frequent and clear communication with stakeholders is during incidents.

🧠 The process of fixing something is surprisingly similar in both contexts. Not necessarily the bugs themselves, but the critical thinking skills required to find pragmatic solutions to complex problems. How you work on isolating the faulty component, how you examine what changed in the environment that could’ve caused the issue, how you’re iterating step by step from a previously functioning state to try and replicate the problem — and once solved, what monitoring and testing you put in place to avoid it happening again. All very useful high-level skills in your work context too.

🤹 When you work on your homelab, you’re wearing the Product hat too, not just the Engineer. There’s no question about who owns what, it’s all you. You will be the one to choose which exciting products you'll try, and balance the options taking into account constraints like cost and time. Furthermore, you’re responsible for building a good experience for your user: also you (and possibly your family). When you put together a dashboard, it’s UX- and Product Development that you’re practicing, and this experience is great for increasing your empathy when working with PMs, Designers, and UX experts in a professional context.

⚖️ More specifically, balancing tech debt with feature development is a very familiar problem in software development, but arguably it exists in a homelab setting too. After a while, you’ll know which parts of the system you rather not touch because it’s a wonder it’s still working… but at the same time, you’d like to try a new toy that just came out and seems to solve all your problems. How do you balance where you spend the little time you have? The solution can often be similar to what is advised in software development: do small refactorings and cleanups with new features. Adding a new docker container? Clean up your compose file while there. Setting up a new VM? Create templates or playbooks, or just improve documentation. Still, the theory is always easier than doing the practice, and having a safe-to-fail, small environment to get familiar with this dilemma and grow the discipline in keeping tech debt at bay is a useful experience for every Engineering Leader.

⌛ The nature of homelabbing means you'll often have multiple projects to choose from. To get things done, you have to plan, execute, monitor, and close projects effectively. This can help you improve your time- and project management skills – both critical in a professional work context too.

💰 Understanding what free and open-source alternatives exist to popular SaaS products and getting familiar with how mature the offering is is something engineering decision-makers can use when weighing pros and cons in a build vs. buy question.

💬 There are opportunities to hone your communication skills: The time comes pretty fast when you’ll need to ask for help, and being able to concisely and precisely word your question, including all important context, but omitting everything unnecessary, is an art that will serve you well at work too.

🌐 Homelabbing, like most hobbies, comes with the gift of an enthusiastic community of similarly interested geeks. Joining meetups, being active in online forums, and contributing to open-source projects can build a solid, reliable network of like-minded people that you could eventually rely on in a more professional setting too.

🧘 Finally, building something concrete, immediately usable, solving an existing problem, or just improving your life is extremely rewarding! Our jobs are increasingly abstract, and people managers especially are used to the feeling that their actions have delayed impacts. Homelabbing is the opposite: you build something, and you immediately know if it works or not. Instant feedback, all in a safe environment. Perfect for frequent experiments and embracing failure, both of which should be a part of your professional life too, but often you have to work on them.

It’s not like there’s anything wrong with pursuing a hobby just for fun! On the contrary, it’s part of a healthy and well-balanced life. Still, I hope I could show how homelabbing experiences can also be useful for Engineering Leaders.

The web is full of good guides about every aspect of setting up a homelab, so I’ll only give two points to help start the journey: The homelab subreddit has an intro for new users, and awesome-selfhosted is a mouthwatering list of readily available software to play with. Go wild!

I usually write about topics more directly related to Engineering Leadership, specifically, managing engineers. Sign up if you want to get notified of my next article.

Subscribe to my newsletter

I write about engineering leadership topics.
Sign up to receive new articles.