Experience is simply the name we give our mistakes. - Oscar Wilde
Intuition
Process is the codification of success.
We automatically incorporate processes into our workflow without thought. We fumble our way through life and work, and find ways to mitigate those challenges over time. Informal processes naturally emerge through collaboration with Product. We develop our own daily procedures for managing our tasks and our time.
But we flinch when process is imposed on us.
Bureaucracy
Inherently, we hate bureaucracy. We hate hurdles. We hate red tape. Friction feels wasteful, no matter how well-intentioned.
“Why do I need to spend time writing this document and getting approvals when I could be getting things done?”
It’s a valid question, but it misses the point.
Crash & Burn
Eventually the need for processes emerges and it’s often in the messy aftermath of a preventable disaster. We’ll post-mortem about what and why and how, and all agree that “if only we had done X” it could have been avoided.
And it’s true. It might have been avoided if only there was enough upfront friction to create an opportunity for someone to raise the alarm.
Process
Process is a repeatable mechanism that reduces variance in how we accomplish our objectives. Process minimizes risk, reduces cognitive load, encodes prior lessons, and creates a shared mental model.
Well-designed processes improve our velocity by eliminating ambiguity.
Limiting Process Bloat
Despite its power, the allure of adding too much process is high. We know it greases the wheels so we apply it everywhere. The end result is conflicting systems, endless meetings, and delays.
The answer is simple:
- Rigorously aim for the “Minimum Viable Process”
- No processes should conflict. Processes are either orthogonal or directly support other processes.
- Higher-level processes should always minimize steps in downstream processes
- Regularly reform existing processes to improve efficiency and scrub fluff
Real-World Anecdote
I joined a new organization suffering from constant delays and low morale.
The core problem was lack of alignment. Product was presenting incomplete ideas to the team during sprint planning without any structure, and Engineering was just following their gut instinct. The outcome was churn.
In response, I introduced a few core processes. They were met with skepticism, but sprint velocity and employee satisfaction improved over time.
- Standardization - Product had to create a complete requirements doc, based on a template, which included designs, MVP, nice-to-haves, and links to other related initiatives
- Vetting - Tech leadership had to review and approve the requirements before sharing with engineers
- Ownership - For each initiative, an engineer was assigned as tech lead
- Understanding - Tech leads had to decompose the problem into deliverables before presenting to the team for sizing and prioritization
High-Impact Processes We Often Overlook
It’s 2025. Most modern software companies already operate with a dense baseline of process drawn from Agile practices, Team Topologies, and decades of industry experience.
The opportunity exists with more precise interventions.
1) Product-Design-Tech Discovery - Eliminate ambiguity to avoid future chaos
- Product and Design are joined by an EM and a senior engineer to review upcoming initiatives to discuss feasibility, identify problems, and provide rough sizing
- Based on feedback, Product/Design refine requirements
- If necessary, engineering researches technical challenges and reports findings
2) Technical Discovery Pre-Planning - Unearth the worms upfront to prevent headaches later on
- During discovery or once requirements are clear, an engineer has dedicated research time to identify all the work required, decompose into stories, and identify likely pain-points and risk
- Once ready, they meet with their SDM to review the findings. Refine as necessary
- If there are major issues, surface to Product
3) Assign Tech Lead - Improves project success, boost employee satisfaction, and create a domain expert
- One engineer is assigned as tech lead for a given initiative
- They own the project delivery, architecture, documentation, etc
- Identify initiatives that are useful for support the tech lead’s career growth
4) Decision Log - Never re-litigate past decisions
- In a shared location, capture all product and tech decisions with date/time, who decided, and why
5) Informal Product Initiative Sanity Check - Avoid surprises months in advance
- As new product initiatives are being considered, EM and Product meet to discuss what’s involved at a high-level
- Surface technical blockers, surface resource constraints, provide rough sizing
6) Sprint Review - Not advanced, but easy to skip
- Team thinks about how the last sprint went. Identifies successes and challenges. Captures feedback in permanent record. Attempts to incorporate lessons into their workflow
- SDM shares key takeaways with their manager and peers within their organization
Balance
“Everything in moderation” is an old mantra my father taught me.
We add process to improve our working conditions. We also remove process to improve our working conditions. Don’t be afraid to experiment by adding friction in areas that have been historically problematic. If it doesn’t fix the issue, change or discard that process.
With some experience you’ll find your team consistently delivering top-tier results.