To make an IT project successful, it is important to recognize the 'difficulty of release'

Sean Goedicke, who has been involved in various projects in the technology industry for the past 10 years, writes in his blog about 'How to execute and release a project at a major technology company.'

How I ship projects at big tech companies | sean goedecke
https://www.seangoedecke.com/how-to-ship/

◆Shipping is hard
Projects are not automatically shipped or released to the market - in fact, projects are often postponed indefinitely, canceled, or released in a half-finished state and then destroyed.

The shipping of a project is usually done by a single person. Even when all the code is written and all the bugs and improvements are done, someone needs to be intentional about doing the 'difficult and delicate work of shipping.'

This doesn't mean that 'that person writes all the code or does all the work' or that 'a release can be made without the support of the entire team,' but that 'you need one person who understands the technical picture of the project and the product and business objectives,' says Goedike. For example, spending too much time improving the customer experience will push the release away. Focusing on UX is a laudable behavior for an engineer on the team, but a mistake for a project leader. Good teams and companies understand this and assign a person called a 'technical lead' or 'DRI (direct responsibility)' to each project. Goedike says, 'Shipping is not an easy job that can be done in your spare time.'

◆What is shipping?
'Many engineers think that a release is just about deploying code or making features available to users, but that's a mistake,' said Goedike. For Goedike, a 'release' is a 'social concept' within a company, specifically, when 'important people in the company believe that the project has been released.'

Goedecke asserts that if the vice president (VP) or CEO is dissatisfied, it's not a true release. For example, if you receive a congratulatory message from the VP on Slack or a report of success on an internal blog, that's a good indication of a successful release. For small projects, even just getting praise from your manager is enough to be a successful release, says Goedecke.

A project that delights users and generates revenue is considered a success because it makes the leadership team happy. Paradoxically, a project that delights users and generates no revenue can still be considered a 'successful release' if the leadership team is happy.

'If you don't like this reality, work for a company that really cares about user satisfaction,' said Goedecke, who said engineers who think of release as fulfilling specifications and deploying code will end up working endlessly on technical projects that repeatedly fail to ship.

◆Communication
For a project to be successful, you first need to clearly understand what the company wants. Your approach will vary depending on whether you're building an enterprise feature, a feature for free users, a specific major account, or a pet project for the VP or CEO.

Since leadership teams often don't understand the technical context, they need to trust their leaders to estimate and anticipate technical challenges. Maintaining this trust is a top priority, says Goedicke, noting that past performance, expressions of confidence, professional communication, and regular updates are especially important in maintaining that trust.

◆Getting into production
When migrating to a production environment, various challenges may arise, including technical details, coordination with other teams, legal issues, etc. Addressing these issues requires a deep technical understanding of the system and the ability to respond quickly.

'At the end of the project, you need to be free from more than 90% of the implementation work, so it's important to create a state where you can concentrate on dealing with problems,' says Goedicke. Even in cases where there are no real problems, you need to be prepared to deal with concerns raised by other teams appropriately. For this reason, it's important not to get too deeply involved in the implementation work and to make time to deal with problems.

◆Can we ship right now?
Using feature flags and staging environments to get as many people to see features as early as possible is key, says Goedecke, because exposure to live functionality can surface unexpected issues and increase leadership's comfort level.

Leaders should always ask themselves, 'Can we release it now?' and think about what is needed if we can't release it right away. Also, if you are waiting for other teams to respond, it is effective to prepare an alternative that will work without the change. Many engineers postpone deployment due to fear and anxiety, but Goedecke says that the scarier the change, the sooner it should be made, because 'people who understand the entire project should be the least afraid.'

Releasing a project is very difficult and must be tackled as a top priority. Shipping is not just about deploying code, it means satisfying the leadership team, and trust from the leadership team is essential to make the release happen. On the technical side, anticipating problems and creating a backup plan is a key task. Goedecke stressed that it is important to always ask yourself, 'Can we release it now?' and take on the challenge with courage.