Improving the quality of software & aligning to customers' success: Q&A with Patrick Wiseman, co-founder and CEO of Spaceship
At Spaceship, we’re all about improving the way companies ship software to help deliver a higher quality end result. That’s why it made perfect sense for us to partner with Blackmill, a software engineering practice consultancy focused on deliberate development.
I sat down with the team at Blackmill to share a bit more about what Spaceship does and why I believe Continuous Delivery is critical to achieving our shared goals.
What do you do at Spaceship and how long have you been there?
I am the co-founder and CEO at Spaceship. Tim Dorr and I formed Spaceship last year to democratize access to the way that the fastest-growing companies ship software. Spaceship takes the guesswork out of adopting Continuous Delivery through a powerful, reliable, and easy-to-use process.
We’re still a very small team, so I do a bit of everything — general business operations, customer discovery, customer support, customer onboarding, finance, team management, and product development. My typical day involves helping develop the platform in the morning and doing an amalgamation of everything else the business needs in the afternoon.
What’s your background? What were you doing before joining Spaceship?
My background is largely in product development, building technical teams, and running businesses. I helped build the technical teams and delivery processes at SalesLoft and Calendly — two Atlanta-based unicorns.
The process that those companies used to continue building so quickly is fundamentally the process that we are building into the Spaceship platform. The focus was always on team collaboration, high-fidelity feedback earlier in the process, and shipping every day.
After Calendly, I ran a consultancy called Deft Services that advised Fortune 500 companies on software delivery and product development.
What do you like about Spaceship?
Spaceship feels like the culmination of a decades worth of working with highly productive software teams. It feels like a huge win every time I speak with a customer who is simply delighted by how much easier Spaceship makes it to get their software off the ground.
This is my first time at the helm of a product-led company, and having an opportunity to more perfectly align our success with our customers' success feels infinitely better than my time running consultancies. There is a very virtuous feedback cycle when you are building things people want and need, and it’s been incredible to be a part of that with Spaceship.
What are you passionate about?
It is my personal mission to improve the quality of software across the internet. Everyone has some software that they have to use everyday that they low key hate. Good software is honestly still pretty hard to build.
I believe the practice of Continuous Delivery helps folks build higher quality software. However, adoption of Continuous Delivery is currently low because it helps in non-obvious ways. A lot of the focus on building better software has been on planning, developer productivity, and better testing. The problem though, is that most of these efforts focus on building the best stable version of an idea that might be fundamentally wrong. Everything you decide to build is at the cost of not building something else. Continuous Delivery as a practice is essentially a demand for a better product process — build the smallest version of this and see if it actually matters.
A Continuous Delivery practice operating at its highest level is an implementation of Cunningham’s law, or the idea that “the best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer.” This means that the quality of feedback you will get from shipping bad software is often more valuable than what you’ll get from shipping good software. Users don’t write in to tell you that you did it right; they will write you to complain.
From my experience, we did not build perfect features at SalesLoft or Calendly. Instead, we shipped minimum viable, or sometimes less than viable, features. Often users would tell us they sucked, but they would tell us exactly how and why they sucked. In turn, that feedback helped us build the right version of that feature much, much faster and more easily.
What is your advice to others who want to embrace Continuous Delivery and make that shift you described?
Getting comfortable shipping less and less complete implementations takes practice, but it is worth the reward. The alternative is spending a lot of time, energy, and budget bikeshedding hypotheticals about the best version of the feature. With all your eggs in one basket, you have to hope that the first version shipped is the right version – because when you inevitably spend all of your resources up front, you won’t have any remaining to ship the next version once you get feedback. That is the actual crucible through which almost all bad software is made.
As builders, we often believe the worst version of software is the version that people hate. But in actuality the worst version of software is the version that people are indifferent about. If they hate it, then you have very actionable feedback on what to do next. If they don’t care about it, then you’re completely off the mark. Building the perfect version of something that no one wants is psychologically safe, but bad for your long-term success.
Companies should focus on stability and quality tools that empower high-output teams where everyone ships software every day. There should be quality checks that keep developers from hurting the productivity of other developers. But there needs to be a balance. Most teams are over-invested on quality in new development and under-invested in quality on proven, valuable, stable features. A more sophisticated delivery process can differentiate between the quality checks and delivery process for an early-access program feature vs. the quality checks and delivery process for a stable feature. Almost no one but the largest, fastest-moving companies do this today.
What do you enjoy doing outside of work? Any hobbies?
Outside of work I channel my inner perfectionist and joy of over-engineering at woodworking. I have built a lot of my own furniture, including shelving, drawers, a monitor stand, a bathtub tray, and other knick knacks around my home. One of my other side projects at the moment is open sourcing all of my woodworking plans and getting them up online on a new personal website (which is also being over-engineered and thus is not online yet). More leisurely, I spend time playing pinochle, bridge, and Fortnite with my partner Laura and am looking forward to pool season starting again this summer.
What is some of the best advice you’ve received?*
Cunningham’s law: “The best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer.” This comes up a lot when trying to make decisions where the cost of mistakes are not very high.