How we approach CI/CD · Resend

How should we review ongoing work as a team? Where do we build our prototypes? How can our executive sponsors track our work? Where do customers go to give feedback on new product features?

The following example shows the workflow.

Frameworks over Processes Less Is More The Hot Potato Process A Change in Tools Needs a Change in Behavior Hot Potato Gotchas Resistance to New Workflow Questions for Reflection

This is how we de-risk change: by building continual evolution and learning into the architecture itself. If you do it all the time, suddenly change is no longer scary.

Another way to improve cycle time is to make decisions more durable so the cycle doesn’t have to repeat later. One way we have found to do that is make decisions on demos and prototypes rather than docs and decks.

Some takeaways: Work in small teams, create fast feedback cycles, reduce requirements-in-process, improve security hygiene, deliver small pieces of work frequently.