Stop Asking How You Can Help — Just Help
Asking 'how can I help' assumes the other person has the capacity to answer. Sometimes they don't — and the question becomes one more thing to carry.
About
About Formative Solutions
Years inside engineering and product teams. Now coaching the people who build them.
Hi — I'm Mike.
I'm a coach and technical practitioner with years inside product and engineering teams. I work with people who are overworked, overwhelmed, and second-guessing themselves — and I help them figure out what's actually in the way.
Before coaching, I worked as a software engineer and technical lead — web systems, databases, Kubernetes, cloud infrastructure, microservices, and the messy realities of scaling teams. The technical work was interesting. What stood out more were the human patterns underneath: burnout loops, unclear expectations, the pressure to stay "on" even when the system was breaking down.
I recognized those patterns in myself too — taking on too much, trying to fix everything through effort, ignoring the signals telling me something needed to change. Coaching became the place where those patterns finally made sense. And where they started to shift.
Formative Solutions grew out of that. Today I help individuals and teams cut through the noise, name what's actually standing in the way, and build forward from there — one executable step at a time.
Curious about working together?How I work
No scripts. No fixed curriculum. Every session meets you where you are right now.
Curious questions over prescribed answers
I don't show up with a playbook. I show up with questions that help you see what you're actually dealing with — not what you think you should be dealing with. The client leads. I navigate.
The Persona Method
We give your self-doubt a name and a face. We build it out. Then we teach you to recognize when it walks in the room — and tell it to leave. It's specific, it's ownable, and it works.
Agile-based breakdown
Overwhelm is just an unsolved backlog. We break it into small, executable steps — the same way a well-run sprint works. Every session ends with homework. Between sessions is where the real work happens.
Why the technical background matters
Engineers and tech professionals don't need a coach who speaks in metaphors. They need someone who understands sprint planning, delivery pressure, imposter syndrome in a room full of smart people, and what it actually feels like to be the one everyone depends on.
I've been in the room
Years as an engineer and technical lead means I understand the context you're operating in. The deadlines, the architecture debates, the 11pm deploys, the standup where nobody says what's actually happening.
I speak the language
You don't have to translate your world for me. Sprints, backlogs, stakeholders, on-call rotations, scope creep — I already know what those cost. We can get straight to what's underneath them.
I also work beyond tech
The same overwhelm, overthinking, and paralysis that shows up in engineering shows up everywhere. Coaching through it doesn't require a technical context — it requires curious questions and a process that actually works.
Background
Built from years inside real engineering teams — not theory.
Coaching & facilitation
1:1 coaching, group facilitation, and Agile team coaching. Sessions draw from reflective inquiry, The Persona Method, and experiment-based frameworks — not scripts or generic advice.
- 1:1 coaching for individuals in tech and adjacent fields
- Facilitation of retrospectives, workshops, and team sessions
- Named Alliance agreements — your rules, your space
Technical experience
Background in software engineering and technical leadership across modern web stacks, infrastructure, and distributed systems.
- Web development with React, Astro, and modern JavaScript
- Databases, microservices, and internal APIs
- Kubernetes, Docker, and GCP-based environments
Agile & team coaching
Years as Scrum Master, technical manager, and Agile coach across multiple teams and organizations.
- Sprint planning, retros, standups, and Kanban flow
- Leadership-team dynamics and decision boundaries
- Metrics and reporting that create insight, not theater
How I got here
Not a single turning point. A series of pattern recognitions that kept pointing in the same direction.
Software engineer
Early roles in software engineering and web development. Seeing how products actually get built: trade-offs, late nights, shifting requirements, and the quiet pressure to keep everything running.
First introductions to Agile
Exposure to Agile frameworks — noticing both the potential for better collaboration and the gap between ceremonies on paper and how teams actually felt inside them.
Technical lead
More responsibility for systems and delivery. Realizing the hardest problems weren't technical — they lived in expectations, communication, and the weight of being the one everyone depended on.
Scrum Master & technical manager
Supporting teams through sprints, releases, and organizational change. Seeing where frameworks helped, where they hurt, and where human realities didn't fit neatly into any model.
Agile coach & facilitator
Working with multiple teams and leaders on retros, ways of working, and cross-team alignment. Experiments over rigid playbooks. People over process.
Coach (present)
1:1 coaching at the center, with a strong Agile and systems lens still in play. Helping individuals name what's in the way, build The Persona Method around their self-doubt, and execute forward — one step at a time.
What clients notice
Different situations, different people — but some shifts tend to show up consistently.
For individuals
Moving from "I'm the problem" to "I understand the pattern — and I know what to do about it." Less second-guessing. More forward motion. A named persona they can actually talk back to.
For teams
More honest conversations. Clearer expectations. A shift from vague frustration to shared language about what's actually happening — and experiments that stick instead of slide.
For leaders
Better alignment between what's said and what's experienced. Conversations about pace, capacity, and trade-offs that reflect both delivery needs and the humans doing the work.
Additional notes.
Related writing exploring small shifts that influence people, teams, and systems.
Accountability Is a System Design Choice
Organizations treat accountability like a character trait — something people either have or don't. They're looking at the wrong variable. Accountability is a system output. The behavior you're getting is the behavior your system was designed to produce.
AI Adoption Is Failing for the Same Reasons Agile Transformation Did
Organizations are deploying AI the way they deployed Agile — mandate first, accountability never. The pattern is identical. So is the cost.
Ready to name what's in the room?
Whether you're dealing with work overwhelm, a major transition, or just a persistent sense that something needs to change — one conversation is enough to find out if this is the right fit.