diff --git a/patterns/2-structured/fixing-issues-step-by-step.md b/patterns/2-structured/fixing-issues-step-by-step.md
new file mode 100644
index 000000000..639e5ca27
--- /dev/null
+++ b/patterns/2-structured/fixing-issues-step-by-step.md
@@ -0,0 +1,58 @@
+## Title
+
+Fixing Issues Step by Step
+
+## Patlet
+
+Solving an issue by deadline without consideration of the current scope of change to process causes developer frustration and decreased efficiencies. Utilize a continuous improvement approach which right-sizes the work and provides realistic expectations.
+A baby-step development culture fosters external contributions (more opportunities for engaging, less to learn, less to comply with, less to document, less to review). This culture reflects in the open source mantra _["Release early, release often"](https://en.wikipedia.org/wiki/Release_early,_release_often)_.
+
+## Problem
+
+Results are expected to take place within a few days/weeks after a process has started. Adding a process or a toolchain will not provide any result by itself beyond developer frustration. Stating that something has to work by a certain deadline will not make it possible. This will just force the situation, and workarounds will be done by developers.
+
+## Context
+
+* Developer frustration is spread and at high levels. Complaints about pressure and stress.
+* Clumpsy workarounds, undocumented and/or prone to be broken/voided are frequent.
+* Voluntary contributions are scant.
+
+## Forces
+
+Understanding step changes in a process requires adequate time and clarity of impact.
+Lack of clarity of impact on the process and delivery pressure are deterrents to change.
+
+## Solutions
+
+When planning new steps, set the way that step is successful if compared to others. Follow a continuous improvement approach and measure the delta between steps.
+Splitting targets into smaller bits multiplies the opportunities for engagement. And they are more attractive too, because they require less to learn, less to comply with, less to document, and less to review (reviews are contributions too).
+
+When reviewing contributions, don't strive for perfection and approve them as soon as there's a tangible improvement (regressions must be avoided, of course).
+
+Lurkers will feel that the (small) achievement is within their reach and will convince them to contribute. This bootstraps a virtuous cycle, as more frequent and diverse contributions also seduce other lurkers to join the party.
+
+## Resulting Context
+
+Expectations are aligned and realistic in terms of the improvement path of the organization. A continuous improvement is required and understood.
+Contributors feel like they can contribute partial improvements without the need to solve all problems at once.
+Contributions are small and can be reviewed swiftly.
+Trusted Committers accept contributions or partial or imperfect solutions if they provide enough value to improve the previous status. Pointers on how to perfect the contribution become comments instead of mandates.
+
+## Known Instances
+
+Santander Bank
+
+## Status
+
+Structured
+Published internally in Santander Bank; drafted via pull-request in December of 2022
+
+## Authors
+
+Alberto Pérez García-Plaza
+Daniel Izquierdo Cortázar
+Addie Girouard
+
+## Acknowledgements
+
+Igor Zubiaurre