This is how I believe an effective software engineering program should be run. It is based on the principles outlined in this post. This page is intended to be initially read top to bottom, but can be used as a reference once read.
A software engineering program is the organizational structure that a group of software engineers operate in.
Engineering consensus creates value
Consensus gives many benefits in an engineering context. I talk about those benefits as well as how I think a software engineering consensus process should be managed and driven in this post.
Initiate product changes with PRDs
The most effective way to utilize engineers is to give them problems to solve. The least effective way to utilize engineers is to tell them what to do. Product Requirement Docs explain what the product should do. This post provides a PRD template and explains more.
Write design documents in response to PRDs
PRDs create a problem. The problem is that there is a difference between the current state of the product and the state of the product described in the PRD. Engineers solve the problem by writing one or more design document and then implementing those designs. This post provides a design document template and explains more.
Complete a launch checklist for large changes
A launch is a collection of product changes that are released as a unit. The changes included in a launch are described by one or more PRDs. Launches are typically high visibility so significant effort is warranted to make sure they go well. This post provides a launch checklist template and explains more.
Set up a launch campaign for public facing launches
Public facing launching serve to generate interest in the product. It is worthwhile to spend time on an outreach campaign in addition to building the product. This post provides a launch campaign template and explains more.
Manage launch risk
Not all product changes require risk management, but all launches do require risk management. Launches are a promise about product changes. Do not make promises about product changes without risk management. A quick and low effort risk management system is described in this post.
Evaluate software release processes
A bad software release process has a high potential to decrease the velocity of the entire software engineering program. It is not a good use of engineering time to perform manual release actions, and it should be easy to predict when changes will be released under normal circumstances. This blog post provides guidance for creating a good release process.
Perform postmortems when something goes wrong
When any process goes significantly wrong a postmortem should be completed to understand why. This could be a failed launch, a production outage, a feature that is not adopted by users, a bad hire, or anything else. Do not sweep things under the rug in your software program. This post provides a postmortem template and explains more.
Prioritize transparently
Regularly meet to prioritize recently proposed PRDs. Invite all relevant parties. This would typically mean any engineering teams involved in the implementation of the PRDs, the product managers proposing the PRDs, and the management who has the best view of the company priorities. By exposing the prioritization process, the entire organization can better support the priorities of the company.
Consider hiring philosophy
Create a cohesive hiring philosophy that can guide the hiring process throughout the organization. Mine can be used for inspiration.