How building a tiny home in a van made me a better lead dev

Last year I bought a big professional van that was used for house builders, with the idea to use it to build my own tiny house. It would be a way for me to work from basically anywhere in the world and start the famous “digital nomad” life.

That way I wouldn’t need a Google Meet background effect to see me in front of a beautiful beach while I’m having an architecture talk with my peers 😅.

As soon as I started on my tiny home project, I quickly understood that it wouldn’t be that easy.

I needed:

• small objectives to tackle, like milestones;
• an architecture plan, a water plan, an electricity plan, a gas plan…etc.;
• quality tools and materials;
• expert advice;
• to document each step in case something broke down in the future;
• to establish and maintain a budget;
• …etc.

You see where I’m going with this? 😉 — an obvious parallel with my current job as an engineer.

💁‍♂️ A bit about myself

I won’t bore you with an extended presentation about myself, but what’s important to note here is that I’ve been an engineer for several years now. What led me to this all my life were these two reasons:

• I’m a very curious person. I wonder about stars? I study astronomy. I wonder about music? I learn how to play guitar and how to compose music. I wonder about building a van? Well… you get the picture…
• I like when things are well done, well ordered, and yes, I’m a bit OCD 😬

What’s also interesting to note, to conclude my very small presentation, is that before last year, I was the last person you’d ask for help on any manual work...

But yet, here I am, me and my van at the very beginning, 1 year ago

🧑‍🎓 The biggest lessons I’ve learned

I might be stating the obvious here for some of you, but I don’t think it’ll hurt anyone to read these lines anyway 😉

📅 Setting a deadline before doing your research is the worst thing you can do

I convinced myself that it’d take me a year to finish my tiny home, so this was the deadline I set out for myself — without digging any deeper and researching beforehand.

Result: as you can guess, I’ve yet to finish. Because I set this deadline without putting much thought into it, I:

• 💥 made mistakes due to rushing things;
• 🤒 increased my stress levels, demanding too much of myself;
• 😴 lost a lot of sleep overthinking everything;
• 😒 stopped all my other hobbies because all of my spare time is dedicated to this one project.

This first lesson I’ve learned is that very often in my professional life I’ve been asked, or I’ve seen people been asked, to do things with unrealistic deadlines and I’m convinced that this results in:

• code done with little thinking, which often results in new technical debt added to the company;
• high stress levels for the team;
• putting other activities on hold to focus on a specific topic, which can generate boredom.

✍️ Documenting decisions is a must

When you’re on a long-term project, you’re sure to encounter some problems, find solutions, and make some decisions that you’ll eventually forget a few months down the road.

The question will surely pop up again or a team mate will question the way you did things and, since you didn’t document the process, you’ll have to go through the same process over again 🙄.

What a waste of time!

You can avoid reopening closed debates by documenting decisions made the moment they’re made 🧑‍⚖️.

I remember having the same debates over and over again with my family about how to do things in our future van:

• “But where will the 🐶 sleep?”,
• “Why not put the 🗑️ here?”
• or the famous “Are you sure about the dry 🚽? 😬”

I remember buying a folder and writing everything down, drawing every plan and calculating every surface so the debate wouldn’t pop up anymore.

It’s natural to forget things and it’s human to question the same things. But it’s also much more efficient to have something to refer to 📋 to justify all the decisions you’ve made.

So that’s what we did at work recently.

We introduced the concept of Architecture Decision Record so that every architectural decision we make at MANGOPAY is written down, always in the same format so that everyone at the company can take a look and know how things should be done ✅.

🚩 Goals are ok, milestones are better

Big goals are important because they’re what you work towards! 🥅

But they can be overwhelming and stressful (e.g. building an entire tiny house with 2 🛌, a 🚿, 🚽, a full kitchen, a desk to work…etc. with no experience in manual labor 🤯)

By breaking down your big goals into smaller milestones, you’ll:

• 🧘‍♂️ have a lot more small wins during your project and this will preserve your mental health
• 🚂 visualize your milestones in a shorter time span and this will increase your motivation
• 🏁 know exactly how to achieve your goals, whereas without them you can easily get lost

And it’s exactly the same at work. I’ve seen annual objectives or career development paths that are completely unclear or unknown. I’ve seen epic features or big technical projects without a proper split. And this is very wrong to me because then, the path is not clear enough to do things well.

So to sum up:

• 🎉 celebrate your (or your team’s) small wins. They’re important.
• 🆘 check how your team milestones are going. Don’t let your mates get lost. Be supportive. And it’s not about tracking. It is about helping.

💭 Two heads are better than one

Because of how I think, and because I wanted everything to be perfectly perfect, I started investigating every part of the construction that was waiting for me (electricity, plumbing, gas, carpentry…etc.). And with each new element, I faced new and more difficult problems.

I caught myself thinking ☀️ and 🌔 about them and my mental health kept declining drastically — until my wife stopped me and made me realize that I wasn’t even enjoying the process anymore.

At this very precise moment, I started asking everyone questions (my family, my friends…). I started sharing my day-to-day problems, and very logical and good answers came to me very quickly.

I understood that this is often not about being an engineer or about how much of a perfectionist you are, but rather how many 🧠 are working together on a topic that can make a difference.

That’s why at MANGOPAY I’m a strong advocate for pair programming, collaboration between teams, and regular communication. To me this is truly the key to success.

👥 You can’t control everything, you have to delegate at some point

This is linked to the previous point here so I’ll be brief with this one.

It’s not about how good you are or how much of a perfectionist you are. If you want the work to be done well and quickly, you’ll have to parallelize, you’ll have to delegate.

Then, it’s all about how you do so. To delegate efficiently you’ll need to:

• 👬 trust your peers. Yes, they can do it just as well as you if not better!
• ✏️ be explicit with what you expect.
• 👥 be readily available (for questions, resources…etc.).
• 🗣️ meet regularly to talk about how the project is going.

I remember being overwhelmed in my previous team with so many topics to think about and so much work to do that I decided to start delegating more and more responsibilities. The results were better than what I expected:

• 🔝 they provided great quality work;
• 🙏 they were grateful to be more involved in the processes;
• 🚄 we increased our delivery speed.

👨‍✈️ Sometimes having an expert to turn to for questions can be good

This is something that came up recently, as I’ve always tried to be my own expert in the fields I was studying — but in the end, this doesn’t work out neither at work or on my van.

When you have a very specific topic that requires deep knowledge and/or experience, you can’t expect to know everything instantly.

That’s why it’s more than ok to turn to experts for advice 🔬.

During a complicated moment this year when I was full of doubt about my van project, I paid the services of two professionals (Homnivan & Le Van Migrateur for those interested 😉) to help me answer a loooot of questions, clarify my doubts, consider other options, ask for supplier names, and so on.

I won’t go into detail but this was very formative to me because I understood I couldn’t know it all or learn it all 💡.

Currently at MANGOPAY we’re in several processes with consulting companies to ask our architecture questions, to help us get into the cloud, improve our security, etc. And it’s a really good thing because we’re gaining time here. So don’t be afraid or ashamed about that.

🗣️ Kindness and goodwill are often useful to maintain a good feedback loop

At some point you’ll need to get some feedback. Some will be positive and some might be negative. It’s part of the process.

More than that, gathering feedback is key in setting up a trusting relationship with your peers and in growing professionally.

For my van project, I’ve involved many people, family, friends and even strangers. And every time you need to maintain a good balance between:

• the milestone you want to achieve with their help,
• the quality of work,
• and the human side of communication to not hurt any feelings.

It was sometimes harder to communicate properly than to build the van itself 😛

But to me this is a key point at work. If I, as a professional, want to constantly grow and learn, I need to ask and receive constructive feedback.

Thus, I need to be able to give my team constructive feedback when it’s needed, whether positive or negative.

👷 Understanding the individual strengths of your team mates is mandatory to have a better work efficiency

Among all the skills you need to be a good leader, something that’s always been very important to me is knowing what everyone’s strengths are.

Some people are good with algorithms, others with communicating, and others with analyzing. And you’d probably want all these skills in your team.

So it ‘s important to be able to see where your peers’ strengths are, what they enjoy doing the most, and cultivate these strengths. To help a bit here, you can read about:

• Process Com
• DISC
• Ikigaï
• …etc.

These are not to be taken literally, but they can still help you understand people better.

💪 Believe in yourself, in your tech watch, and in your knowledge

I would like to conclude on this point that is one of the most important to me.

You have to know yourself, your skills, and keep a watch on tech developments to stay up to date on new technologies.

This way you’ll gain confidence in what your company needs to do, what needs to change to improve its tech, its performance, its scalability, and more.

You’ll have the confidence to take on new projects and propose new technologies.

I know my van is not done yet. But I’m working on it and it already looks amazing. And if I had cared about what people said (“this project is too big, too complex, too difficult…”), I wouldn’t be writing this text for you today.

⛳ Conclusion

Of course I have learned a lot more during this process but what I wanted to highlight here is : it is good to experiment outside of work and do the parallel sometimes. Every experience can make you a better professional if you take the time to digest the lessons you learned.

To conclude, build a tiny home in a van! Hopefully you will end up being a better person AND you will be able to travel, being in your home, all over the world 🌍.

PS: If you are interested in knowing more about the process of this tiny home in a van, you can find all the story in instagram @findoursoul