Experiences of varying ownership

When you’re interviewing for a new role at any company, you’ll likely be asked some version of the question “What are you looking for in your new role?“. As someone who’s recently switched jobs, (and interviewed with quite a few companies in the process), I would say it’s come up in pretty much every single one.

I generally don’t prepare too much for interviews like these as I usually don’t feel I need to. I enjoy having conversations with people, and these non–technical interviews are generally more conversations than interviews. Regardless, I find myself answering questions like the one above relatively consistently. I know what I want and on the top of that list is ownership.

It’s one of those things that I think ticks a lot of boxes for companies when you mention it. “This one wants to own things”, I imagine them saying when the meeting is over, “that means he is a driven and trustworthy individual”. But regardless of how it reflects on me, that’s not why I mention it. I mention it because I truly believe it is what drives me and helps me build a better product.

A history of non–ownership

I started my career doing some blend between consulting or contracting work, a model that is incredibly common for new grads back in Sweden. Straight of university, I started a traineeship at a consulting firm, went through some training and internal projects for a few weeks and was then ready to be on-site with customers.

My first project was at a customer who’d outsourced a year-long project to an agency that had in turn outsourced it to its Sri Lankan subsidiary. There had been little communication between the customer and the developing team during the time, and I came in shortly after the project had been “delivered” and just “had to be made ready for production”.

It was a mess. The software barely worked and I spent the better part of six months fixing a seemingly endless stream of bugs and performance issues in a deeply flawed product. There was never any time to make larger changes as “the big launch” was always just weeks away.

I left six months into the project after asking to be transferred to a new project. What followed was a string of projects and customers that followed a similar pattern. The software was generally better than that first project, but the work followed a similar structure. Bugfixes and incremental improvements to fundamentally broken software.

What I experienced here was probably some combination of poor software and not–invented–here syndrome — the idea that a rewrite always seems better than maintaining software you didn’t write in the first place. But above all of that I just never felt any responsibility for the products. I was fixing issues in someone else’s software that I didn’t even create in the first place.

Something different comes along

After three years I left that company and while I didn’t know what I wanted out of my next role, I knew exactly what I didn’t want. I ended up building fleet–management software at a small startup in the micro-mobility space. Quickly after starting I was thrown into the deep end—the company needed a way to efficiently debug and manage its 50 thousand or so vehicles of varying manufacturers and models. I had never done anything like it before but didn’t shy away from a challenge.

Limited resources led to me effectively being a one-man army building and maintaining this product. From ideation to initial release took about a month and after iterative releases for about a year we had a pretty solid product. Being a team of one meant I was responsible for many different roles; talking to users and gathering feedback, consolidating that feedback into a comprehensible roadmap and then executing that roadmap. It was an intense learning curve and I loved it.

If there was an issue with that product I would jump on it immediately. I could probably have waited with fixing some of them as they weren’t exactly blocking, but I wanted to fix them. It was my product, I built it and I had a sense of professional pride attached to it. To some extent, the product was a reflection of my abilities as an engineer.

Ownership over tasks

These are cherry-picked stories and there is some level of hyperbole involved, (there were definitely times I didn’t love my job at the micro-mobility company, for example), but I can’t deny the fact that ownership was an incredibly important factor at play.

If there are any takeaways here at all they are to give employees larger reponsibilities and to avoid constantly moving them between projects. The next time an issue comes in, rather than discussing who will fix the issue talk about who will be responsible for the related (sub-)system. Hopefully, they’ll gain a sense of responsibility for their part of the product and you will increase employee retention and productivity as a result.

Just a thought. Don’t agree? Let me know on Twitter (or don’t).