top of page

Building a Smooth Engineering Workflow: The Key to Successful Project Launches

Building a Smooth Engineering Workflow

If you want to have a thriving flow of projects, launches, and releases in an engineering org, but you have no structure in your engineering operations, there will be issues. After years of launching projects and programs with tech teams, I've noticed I can support my project much better not by changing the project structure but simultaneously supporting the operations to make sure the teams, people, and systems are setup to support the project. Building a smooth engineering workflow will positively reinforce how you launch projects and reduce surprises.

Some TPMs (Technical Program Managers) are focusing on battling the system so that their projects and programs launch on time. They add tons of buffer and risk management to deal with the level of uncertainty. If the TPM team can also focus on a proper engineering operations ecosystem, their projects will have lower risk, higher predictability, and higher success.

The Positive Reinforcing Feedback Loop of Technical Project/Program Management

Reinforcing Loop

I've seen Technical Project and Program Management teams solely focus on their projects and individual systems, but there's always something getting in the way. If the engineering org is setup chaotically, your project will be chaotic. The best way forward is to split time in supporting the entire ecosystem so your projects will run smoother. Here are some examples:

Operations Supporting Projects

Engineering Operations

How it supports

Product Development process

If there is a high-level process teams follow to accept new projects, discover, design solutions, and build, it will be much easier to work across multiple teams. If this is lacking, the TPM and teams must create a standard process for the project which is very disruptive.

Engineering metrics

If teams are measuring their productivity holistically, projects are way more predictable. Teams that measure their work, happiness, efficiency, communication, and performance are much more likely to be a productive team alone and with other teams. Ex: SPACE metrics

It's recommended that a team has an allocation of work that's: 60% new and improving work, 40% KTLO and productivity. If this balance is off and the team works 100% on new features and squeezes time in for bugs sometimes, there will be an emergency that pops into your project timeline and completely ruins it. Watch this closely.

Project portfolio & capacity management

The project selection process is the most critical component for the team. This process can be the most disruptive or support the best possible product and workflow for teams. Projects must be selected with engineering input from day 1, a review of capacity including project tradeoffs, and must include engineering estimates. Otherwise, this is the biggest burnout and project risk to meeting deadlines and working on the right things.

Performance, quality, security, incidents

If the teams are focused (and have allocated time) on a building a high quality system that performs well, they will have time to also work on new products and features. If your project constantly is off track since there are surprise emergencies, then there's an off balance of new work to KTLO.

Tooling & Automation

Teams that work on creating an efficient flow for releases, work on productivity and automation will be that much better. Many engineers estimate their working time on a feature, but they don't take into account the terrible process after they're done. This is a huge buffer you need to take into account or let them focus on building an automated system that cuts out wasted time.


If you're seeing projects never release on time and you're not sure why, take a look at your setup, operation and overall process for some clues. If a project must launch in this setup, you're fighting against it rather than having the supporting effects of a good system.

Projects that I've launched that have had less struggles, emergencies and risks had a system to support it. I've also launched projects on time in less structured environments but it takes tons of work, adding buffer time, uncertainty, and lots of people to pull it off.

Let me know your thoughts!


bottom of page