Halfway through my 5 1/2 years at SpaceX, management decided to change the way we developed software by handing over the job of creating a product vision to the engineering team. They felt that the traditional way of putting product management in charge of the product roadmap was creating a layer of abstraction. So, they set out to eliminate the game of telephone played between people on the factory floor building a rocket and the people who were actually building the software for the rocket. 

While the change was challenging, having engineers in charge of product visioning ultimately led to better products being designed. That’s why this way of doing things has influenced the way countless startups founded by former SpaceX engineers have structured their engineering departments – including ours.

Are there challenges with setting up software development this way? Sometimes. Does every software engineer want to be in charge of product visioning? Probably not. It’s important for product visioning to be in the hands of engineers – and changes in the industry and software development tools themselves are compelling engineers to up level their skills in ways that lead to better products, and, in my mind, a better career.

From Ticket Taker to Extreme Ownership

Here at Sift, we don’t have product managers so the types of software engineers that we hope to attract are people who want to have total ownership over how our software is designed and what features go into it. SpaceX has an extreme ownership culture where people are given more responsibility and expected to grow into that role instead of being given a little box to work in. When you put people in boxes, you don’t allow them to realize their full potential. I think that’s why SpaceX has accomplished some pretty amazing things. In our effort to create similarly amazing technology, we are trying to also instill a culture of extreme ownership. How do we do this?

A lot of engineers are motivated by wanting to solve their customer’s problems – the question is how much do they feel that through the abstraction of a requirements document versus actually watching their customer use the software? We believe it is the latter, which is why we have our engineers work directly with customers as much as possible. 

This way of working is actually responsible for the original DNA of our product. When we started Sift, our small team sublet space from a company in our network who we knew could benefit from the product we were trying to develop. They shared their data and we set out to develop software that we knew could help them and countless other startups struggling with developing cutting edge hardware in a growing sea of data. We spent three months in their space, iterating our product. We brought the two engineering teams together to show them their data in our tool and had them use their existing solution and the one we were developing side-by-side. At the end of that period we had developed a product they were willing to pay for and one that is now helping a number of other startups solve similar problems.

While we don’t set up shop in our customers offices, we do get our engineers directly involved in new customer onboarding sessions – meeting face-to-face to see how customers work in their existing tool and watch them work in ours. This helps to make sure that our solution is set up in a way that is going to benefit them the most – and informs important product development decisions for the next iterations of our product. Engineers spend a lot of time in the tools they are developing so it’s not always easy for them to identify things that are missing in the product or areas where the product is clunkier than they should be – spending a day or two with a new or existing customer actually watching them use it is the perfect cure for that. This direct line of communication between our customers and our engineers continues long after the initial onboarding session through direct Slack channels that we set up and quarterly meetings with members from our engineering team. 

Engineering in a Post Chat GPT World

While this all sounds like a ‘nice to have’, I believe in a world where increasingly software is going to be written by low code applications and AI copilots, engineers need to level up. AI is going to take over more software development and it’s going to go after the simple things first. Engineers can do one of two things: focus on work that is deeply technical or develop a really deep understanding of how the tool is used, the industry it’s being developed for, and the problem it is trying to solve. 

We want our engineers to be part of the future, not stuck in an endless loop of ticket taking. Despite what the old tropes about engineers say, we are finding legions of engineers excited to welcome a new way of doing things – and that’s going to benefit customers and the engineering profession at the same time.

You may also like…

Developers, leaders disconnect on productivity, satisfaction

Prioritizing your developer experience roadmap