Updated: Sep 22, 2021
I joined the Found team back in September, and it has been a wicked ride since then. We have been working on something very exciting, having recently completed a bunch of research and design. However this post is not about that (stay tuned though!) This post is about how the team at Found has built a culture where going from onboarding to full product delivery can be achievable in a mere month.
It starts in the hiring process
My experience applying to Found was unlike most companies I have interviewed at. If you’re in tech, you probably know the drill. You get invited to an interview, put on a suit and tie, get grilled by a group of managers on your tech knowledge, then code a binary search algorithm or a solution to an obscure string processing problem. Finally, spoken with the enthusiasm you might expect from someone who skipped breakfast and regrets organising an interview just before lunch, you hear those immortal words, “any questions?” This is not the worst interview experience someone could have, but it is all too common. Found showed me it could be done so much better.
My first interview at Found involved a conversation with our COO, Jenny and our CEO, Lance. They made the conversation as much about my desires and aspirations as the company’s. It was clear from the outset that this was not an oblique test of my character and skill set, it was a candid dialogue about whether I would fit Found and Found would fit me. There was no judgement. This allowed me to speak freely and enjoy the interview. The first discussion concluded with a request to review Found’s tech stack and provide suggestions to improve upon it.
The second interview was scheduled at my convenience so that I could deliver the best presentation possible. Given I’m writing this blog you’re reading, you can probably guess what happened next 😉. All this is to say that even before I entered the role, I was made familiar with the work I would be doing. The process avoided abstract examinations of my ability to construct an algorithm and instead focused on my drive to deliver a product to market.
Invest in making onboarding easy
Soon enough, I made my debut at Found. On the first day, Jenny approached me with a plan for how my first week would go. It detailed my introduction to key people I would be working with, a list of all the accounts we needed to set up, an explanation of how and when I would be paid, and most importantly: a run through of the product roadmap. Throughout this I was considered an equal. I was not here to take orders, but offer my thoughts and alter the trajectory of the products and my career at Found.
Tech also plays an important role in onboarding. Each manual software installation and every “you’ll only need to do this once” step in a readme document takes a toll on the incoming developer. Fortunately, I encountered a tech stack that wasn’t overcomplicated, so most of the setup I needed to do was as easy as running `npm install`. Engineering teams frequently forget their role in welcoming a new member of the team. We forget that supposedly one-off, manual tasks should be counted as technical debt, especially when that team is looking to scale soon.
Onboarding is so much more than setting up single-sign-on and sending a few emails. Your business should recognise that changing jobs is a big shift for that person’s life, and every little thing you can do to ease that transition is a kindness they will repay in their work.
Know what you’re building
Before my arrival, the team had already put together a strong product roadmap. By the time we started to plan our first sprint, I had caught up on the vision for Purchase Protect and was ready to apply my technical knowledge to forging a great backlog. Without the clear direction that the rest of the team had prepared, I would not have been able to dive into development in my first week. Along the way, I was able to get the support I needed to deliver the best implementation I could because we all had a shared mental model of what Purchase Protect should look like and how it should work. The whole team understood the benefit to the customers and the business of offering an easy way to protect valuable purchases, as you buy them.
Jumping headfirst into an unfamiliar tech stack was a daunting prospect. Plenty of things can go wrong when an engineer is not careful. However, my team had given me their trust which made me feel comfortable building new CI pipelines and rolling out the product, safe in the knowledge that they’d have my back if something went wrong. Found could have spent another month analysing the codebase, deploying to 10 different pre-production environments, and grinding through an arduous release management process but that would have just placated our anxieties. Risk is an innate part of software delivery, and by accepting it, we were liberated to spend our efforts on automating deployments, improving user experience, and preparing Purchase Protect to scale.
Ultimately, we released Purchase Protect to our partners successfully and it’s looking great. If you like the idea of making sure your customers’ valuables are protected and want to become a Purchase Protect partner (earning some sweet incentives along the way) get in touch!
Although this sounds like a roaring success, we definitely encountered issues along the way. Those struggles can help us learn, but without sharing and documenting the lessons, we’re bound to repeat mistakes. That’s why we conducted a proper retrospective after our delivery. Thankfully the positive, supportive atmosphere built up over the weeks prior meant that candor was easy to come by. Whilst we mapped out the obstacles we faced in detail, we remained focused on generating actions we could take and behaviours to adopt which are crucial for the team’s growth. In time we’re looking forward to expanding our tech team. To do that, we need not just to create a fantastic culture, but make sure it persists in our organisational memory.
Which is why I suppose it’s good that I wrote this all down in this post you’ve just read.