I came across a really good blog post by way of The Pragmatic Engineer: How I ship projects at big tech companies by Sean Goedecke. Sean is an experienced engineer, and he does a great job of laying out both what it means to “ship” and why shipping is really challenging.

Shipping is Essential

Let’s start here:

Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.

At tech companies, engineers are required ship things, and getting things shipped is a binding constraint for just about every strategy. This is obviously true for the product strategy, but it’s also true for marketing and customer support. Most involve a software component that needs to interact with the product or with behavioral data generated by the product, and some engineering work is required to get things working.

When a company is focused on outcomes over output, shipping can be defined as addressing the software requirements of outcome you’re pursuing. In most cases, this is completely obvious. If the outcome you’re pursuing is increasing purchases from search by personalizing the results, then you have to ship a search ranking model that includes personalization features. It may be less obvious if the outcome is that the marketing team wants to run test campaigns in a new paid channel. To do that, there are several integrations required. If marketing can’t start the test because these integrations aren’t done, then engineering hasn’t shipped.

So I would tweak Sean’s definition a bit, software has shipped not when important people believe it has shipped but rather when it has been applied to the problem it was written to solve. In the case of the search algorithm, it has fully shipped when you have run an A/B test that shows that the personalized algorithm outperforms the current algorithm and you launch it to all of your users. In the marketing example, you’ve shipped when marketing finishes a test campaign with trustworthy results.1

There are, of course, intermediate milestones that can resemble shipping as well, but shipping isn’t complete until the outcome is achieved (or whoever is responsible for the strategy has learned that the pursuit of the outcome is no longer worthwhile).

The Engineering Productivity Discourse

The software industry is in the midst of a broad, extended conversation about developer productivity. How can it be measured? How can it be improved? What is the role of Gen AI in improving it? Can we use Gen AI to enable non-engineers to do engineering work? These questions are salient because demand for new software still vastly outstrips supply, and within companies, their need for software is greater than their budget for hiring engineers.

I have some answers to these questions. Yes, we can better understand engineering productivity at a systemic level (see the DX Core 4). We can, of course, continue to improve developer productivity through technology and better ways of working (as we have since software became a thing). Gen AI can definitely enable engineers to be more productive — every engineer I’ve talked to who has taken the time to learn how AI-powered tools can help them has found they enhance their productivity. And yeah, there are going to be Gen AI tools that eliminate some work that currently requires engineers. When I started my career, we created web pages one by one in a text editor and uploaded them to the web site with FTP. Creating tools to enable the computer to do some of your work for you has always been an essential part of engineering.

When I read Sean’s blog post, though, what occurred to me is that the core tension between engineering and everyone else is driven by disconnects around shipping.

When people who are dependent on an engineering to ship aren’t sure what’s going to ship, when it will ship, or how much effort it will take to ship it, rifts tend to form. This is often characterized as an engineers versus non-engineers problem but the same negative dynamics exist between engineering teams as well. When a product team is waiting for an infrastructure change that they can’t make themselves, or an infrastructure team is waiting for a product team to update a system to support a migration, the same conflicts arise.

To bring it back to Sean’s original blog post, not only do individual engineers benefit by understanding how to ship, but engineering teams need to be great at shipping collectively, and strong engineering cultures value shipping as their primary function.

Shipping is Hard

If shipping were easy or inevitable, there wouldn’t be any point in writing blog posts like this one (or Sean’s). He puts it well here:

The default state of a project is to not ship: to be delayed indefinitely, cancelled, or to go out half-baked and burst into flames. Projects do not ship automatically once all the code has been written or all the Jira tickets closed. They ship because someone takes up the difficult and delicate job of shipping them.

One thing I want to say is that “did not ship” is a fine final state for many projects. Not all outcomes turn out to be worth pursuing. We had an infrastructure project that went on so long that changes in the underlying technology eliminated the need for the project before we could finish, and so we killed the project. Sometimes you build something, test it with real customers, and find out that it isn’t going to provide the value you hoped for. The right move is to capture the learnings and figure out what’s next. Succumbing to the sunk cost fallacy kills companies.

I also want to reinforce the idea that if you’re working on a project, shipping needs to be the imperative. Moving a project toward its conclusion (whether it’s wild success or future deletion) has to be the focus. One thing he doesn’t mention that eventually kills many projects is taking on side quests while you’re doing the main quest. “As long as we’re working on this we should …” is a phrase that ultimately kills many projects.

What I agree with most strongly from that quote, is that shipping is an act of leadership.

On Tech Leads

You’d think that one of the great things about being a CTO is that you can decide what ships, or ensure that important things ship, or that your priorities will be reflected in what ships. The truth, though, is that bandwidth constraints are real. At any given time there may be a project or two that I really care about and keep a close eye on it, but for the most part, I try to create conditions that are conducive to shipping, and then depend on leaders who are closer to the day to day work to ship.

Having leaders in place at the project level who both understand the desired outcome and technical details is critical to shipping, as Sean states here:

… it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves. Good teams and companies understand this, and make sure every project has a single responsible engineer (typically this position is called a “technical lead” or “DRI” role).

This is the best definition of a tech lead that I’ve seen — it’s the person who both understands what a project is intended to achieve and understands the technical details of what needs to happen to achieve it. They also need to be deeply invested in the outcome. If they don’t prioritize the outcome, they’re not going to have the tenacity to ship. What that usually means is saying no to people who want to attach goals unrelated to the outcome to the project, even if it creates friction.2

This concept of technical leadership covers a lot of what organizations should expect from senior individual contributors. They need to have the technical depth to get into the details, the domain or business knowledge to understand how the software they’re working on will contribute to the desired outcome of the project, and the leadership skills to combine that knowledge to address blockers and renegotiate requirements that will prevent the project from shipping.

It’s easy to look at the org chart and assume that technical leadership is happening, especially when you’re ultimately responsible for all of the projects going on at the same time, but that’s never a safe assumption. Certainly when a project seems to be off track, figuring out the state of technical leadership on the project needs to be the first priority.3

On Communication

I have a few things to add on the subject of communication as a technical lead:

1. Be actively engaged with the outcomes of the project and talk to the stakeholders yourself. There will likely be a product manager, or a project manager, or someone else involved to ensure that non-technical requirements are being addressed and that the project timeline is compatible with the desired outcome. However, it’s your job as the technical leader to make sure that the software you’re going to ship will be fit for purpose, and the more deeply you understand the intended outcome, the more effectively you’ll be able to play that role.
2. Engage with expectations around timing and what’s driving them. Is this a project that needs to be delivered by a certain date, or is it a project that needs to be delivered as efficiently as possible in terms of hours invested? Companies have a fiscal year, and concerns around time vary depending on where it falls within the fiscal year.
3. Be very clear about the risks at every phase — from day one you should be communicating the risks to shipping that you know about, and revising that list as you go on. Explaining that shipping is delayed due to a risk that you warned people about ahead of time is a whole lot easier than explaining that you fell prey to “unknown unknowns.”
4. If you need help, ask for it, especially from leadership. In a world where everybody is prioritizing shipping the projects that are their priorities goal conflict is inevitable. Goal conflict almost always has to be resolved at the level where someone is accountable for all the goals that are in conflict. It’s a bonus if you can articulate what’s involved in going alone versus getting help from another team, and what risks that introduces.

In Conclusion

When it comes to execution, there are only two things, prioritization and shipping, and really understanding what it will take to ship a project is a really important input for prioritization. As an executive, knowing that you have people you can count on to ship things is the best feeling there is.

I loved this article because it laid out in very clear terms what an outcome-focused approach looks like for senior engineers who want to play a really impactful role in their organization. There’s no replacement for a leader who has the knowledge to get things done and real clarity of focus, and at a software company, a huge amount of that leadership needs to be provided by engineers.