You understand the problem. You know what needs to be built. You have protected time to work on it, and you understand the technical decisions behind the solution.
But there is still one question:
Will the work actually be delivered?
Software engineering is full of work that is almost complete.
A feature has been developed but not tested. A pull request is open but has not been reviewed. A bug has been fixed locally but has not been deployed.
The code may exist. The effort may have been substantial. But the intended result has not yet been delivered.
This is where the next component of CRAFTER comes in: Execution.
In Part 4, CRAFTER Technical Mastery, we explored the technical knowledge and architectural reasoning needed to build sound solutions.
Now we move to the next area: turning that knowledge into completed outcomes.
🧩 What Is Execution in CRAFTER?
CRAFTER defines Execution through a simple principle:
Intentions don't ship. Code does.
The world only cares about what is finished.
Execution is the discipline of closing loops and pushing through the last 10% of a task, where many engineering efforts lose momentum.
A task is not necessarily complete when the code compiles, the main functionality works, or a pull request has been created.
Completion means that the agreed outcome has been achieved and the work has reached its defined endpoint.
CRAFTER outlines three foundational principles:
- Bias for Action
- Finishing Over Starting
- Velocity Tracking
The practical rule is straightforward:
Break tasks into smaller, deliverable components. Close every ticket you open.
Read about Execution in the CRAFTER Framework.
🚀 1. Bias for Action: Turn Decisions into Progress
Engineering involves analysis, discussion, and planning. Analysis alone does not result in an engineered system.
Bias for Action means taking concrete steps towards implementing a solution once you have sufficient information about the problem.
It does not mean coding without thinking. Cognitive Clarity and Technical Mastery are still essential. It means avoiding unnecessary delays once you have enough information to solve the problem and a sufficiently clear direction for implementation.
Consider a task:
"Improve the reliability of the payment integration."
This is an expression of intent, not a task.
A more precise approach would be:
- Reproduce the bug.
- Describe the desired behavior.
- Implement the correction.
- Write new tests or update existing ones.
- Validate the behavior.
- Deliver the change.
Each step produces an observable outcome.
A small-scale experiment or test can provide more information than additional speculation.
Action creates feedback. Feedback improves decision-making.
🎯 2. Finishing Over Starting: Commit to the Last 10% of the Job
Starting new projects gives you a sense of productivity. Finishing projects does not feel the same.
The end-to-end process might involve testing, additional implementation work, documentation, code reviews, preparing for production, and addressing feedback.
These tasks aren't always as enjoyable as implementing features, but they are important parts of the overall delivery process.
This is an anti-pattern identified by CRAFTER:
Leaving a trail of 90%-finished tasks or polishing without releasing.
The cost of unfinished work
Imagine an engineer who works on five projects and brings each one to approximately 90% completion.
The board looks busy, but none of those projects has been successfully completed.
Unfinished work has many drawbacks:
- Context retention: The engineer has to remember the details and remaining work for multiple unfinished tasks.
- Team coordination costs: Other team members cannot reliably build upon incomplete work.
- Delayed feedback: Integration issues and other problems remain undiscovered.
- Uncertain delivery: Progress is mistaken for completion.
The solution is to clarify what "Done" means.
For features, this might include:
- Implementation completed.
- Relevant tests passing.
- Code review feedback addressed.
- Integration tests completed.
- Deployment or handover completed, according to the task's scope.
Quality is important. More revision time does not always lead to better outcomes.
The goal is not to produce low-quality work faster. The goal is to produce high-quality work without succumbing to perfectionism, which can prevent work from being completed.
A completed, validated increment creates value and feedback. An endlessly improved implementation provides neither.
📦 3. Iterative Development: Ship-Ready Increments
Large projects involve many decisions. Defects in large projects are often discovered later in their lifecycle and are more expensive to correct.
CRAFTER recommends breaking work into smaller, deliverable pieces.
Consider creating a new integration with authentication, request handling, retries, error mapping, and monitoring.
Instead of exploring all possible paths before selecting an approach, divide the project into smaller tasks:
- Establish a basic connection.
- Implement the primary requested functionality.
- Include error-handling and retry mechanisms.
- Introduce observability.
- Validate the integration.
- Prepare the production delivery.
Each delivery step should be tied to a specific, concrete achievement.
Small steps provide regular feedback on progress and make it easier and less expensive to identify and fix errors.
Incremental development is not the same as partial development. Each increment should be complete; that is, it should satisfy its own completion criteria.
Reduce the size of each delivery without reducing product quality.
⚙️ 4. Deep Work: Producing High-Quality Output Through Focus and Concentration
Focus provides time for engineering work. Execution determines what happens during that time.
CRAFTER's Deep Work (Execution) process, outlined in the CRAFTER-OS GitHub repository, follows this principle through a practical routine.
It consists of three core practices and a closing routine.
Zero-Noise Environment
During a protected Deep Work block, Slack, email, and phone notifications are OFF. Unnecessary interruptions are eliminated.
The purpose is not to avoid communication permanently. The purpose is to create a protected period for focused work.
Single-Tasking
Work strictly on the current task until you reach a logical milestone.
Don't switch or divide your attention because you receive a new notification or have another thought.
The 20-Min Rule
If you are stuck for more than 20 minutes, stop coding and try to work out the problem on paper.
Identify missing information, reconsider your approach, and seek assistance or clarification when needed.
Repeating the same unsuccessful approach won't move you forward.
Post-Flight: Close the Loop
At the end of the work session, produce a tangible result:
- Commit.
- Pull Request.
- Stakeholder update.
Also write down the first action for the next session. This helps save time by providing a clear starting point and avoiding unnecessary reorientation.
The entire process is outlined in the CRAFTER Execution Playbook, Deep Work (Execution).
Focus protects the work. Execution turns it into an observable result.
🛠️ Example: Transition from an Open Task to a Delivered Result
Imagine a payment-processing service that occasionally experiences timeouts when sending requests to an external API.
The task is to improve the reliability of the integration.
Without a clear execution approach, an engineer might investigate several possible solutions, start multiple related improvements, complete most of the implementation, and leave testing and other related tasks unfinished.
With CRAFTER Execution, the process is carried out more deliberately.
1. Bias for Action
Reproduce the timeout. Identify the source of the failure. Define the expected behavior. Gather facts and avoid assumptions.
2. Incremental Delivery
Break the task down into smaller steps:
- Develop a test case that others can use to reproduce the issue.
- Implement appropriate timeout and error-handling mechanisms.
- Write tests for expected failure scenarios.
- Test the failure modes.
Each step produces a verifiable result.
3. Deep Work Execution
Schedule focused time and minimize interruptions. Apply the 20-Min Rule if you are blocked.
4. Finishing Over Starting
Complete testing and validation, address feedback and other concerns about the proposed change, and prepare it for delivery rather than starting other work.
5. Post-Flight
Create a commit or Pull Request and notify the relevant stakeholders.
The outcome is not just code that appears to work. It is a tested change that is ready to move through the delivery process.
This is the difference between being busy with an implementation and actually executing it.
⏱️ 5. Velocity Tracking: Measure the Rate of Delivery
Without feedback, you cannot determine whether execution is improving.
CRAFTER describes three diagnostic indicators for Execution.
Completion Rate
Measures: The number of tasks moved to "Done" per cycle.
It helps reveal whether work is actually reaching its intended endpoint rather than accumulating in progress.
Lead Time
Measures: Time from "Task Started" to "Task Delivered."
It can help identify delays caused by large tasks, dependencies, code reviews, changing requirements, and related activities.
Stall Rate
Measures: The number of tasks that remain "In Progress" for more than 48 hours without a commit.
It can uncover blockers, unclear next steps, and other problems related to completing tasks.
These metrics do not show the underlying reasons for problems. They provide signals that can be used to investigate them.
A high Completion Rate does not automatically indicate good engineering. A high Stall Rate does not automatically indicate bad engineering.
Metrics are diagnostic signals, not performance surveillance.
Detailed information is available in CRAFTER Metrics, Execution.
🤖 Programming in the AI-Assisted Programming Era
AI tools can help with coding and related tasks, such as generating tests and offering recommendations.
But writing code is not the same as finishing a project.
An implementation may require further work, including testing, debugging, compatibility checks, and other pre-deployment activities.
An AI tool can help create an implementation. The engineer is responsible for verifying that it meets the requirements and achieves the intended outcome.
Execution isn't measured by lines of code written. Execution is measured by what was successfully delivered.
🔮 What's Next?
Execution involves using engineering knowledge to achieve outcomes.
But delivery doesn't end when a task is labelled Done.
Who owns the result after deployment? Who resolves integration issues and addresses technical debt to maintain the system's reliability?
In the next part of CRAFTER, we'll cover Responsibility: the discipline of taking ownership of entire systems and being accountable for the results.
🧬 Conclusion: Engineering Is Measured by Delivered Outcomes
Software engineering does not end with discussions about project requirements, code creation, or code reviews.
It is complete when the intended outcome is delivered at the required level of quality.
Execution requires engineers to:
- Take action on their decisions.
- Break large projects into small deliverables.
- Finish tasks instead of repeatedly starting new ones.
- Define what Done means.
- Identify and address obstacles.
- Measure delivery flow and investigate bottlenecks.
Cognitive Clarity helps identify the right problem.
Focus protects the time and attention needed to address it.
Technical Mastery provides the knowledge to build the solution.
Execution turns that knowledge into a delivered result.
The goal is not to maximize activity.
It is to make engineering outcomes predictable, valuable, and complete.
Intentions don't ship. Execution does.
That is Execution in CRAFTER.
📚 References & Further Reading