Technical Agile Coach
Patrick Baumgartner works as a Technical Agile Coach, in the code and with the team. The focus is engineering capability, not ceremony or certification.
Developer Coaching for Java & Spring Teams
Your team understands the practices, but delivery pressure makes them hard to apply consistently. Embedded technical coaching puts the work in context: a Technical Agile Coach pairs in your repository, on current tickets, and helps the team build habits it can sustain.
Typically one to two days per week, three months minimum.
Anonymised outcomes: one enterprise product team increased delivery throughput by 25%; a financial-services team moved from quarterly releases to daily production deployments. Results depend on context and starting point.
The problem we are usually called about
Your team knows the theory. Delivery pressure exposes the gap between knowing and doing.
-
Knowledge is not becoming practice
The team understands the concepts, but delivery pressure pulls it back towards familiar working patterns. It needs practice on real work, not more theory alone.
-
Review flow depends on a few people
Reviews and difficult decisions queue behind a small number of experienced engineers. Other team members wait rather than learning through the work.
-
Tests cannot be trusted
The test suite is slow, flaky, or both. Developers work around it because feedback arrives too late to guide the design.
-
AI-assisted output increases review pressure
Coding agents can increase the volume of proposed changes. Without clear review, testing, and ownership standards, the team may accept code it cannot confidently explain or maintain.
This is technical coaching, not Scrum or process coaching. If your need is broader software engineering support, see our services.
What the coaching covers
Not a classroom course. We practise these skills in your codebase, against your backlog, where the trade-offs are real.
-
Testing and feedback under delivery pressure
Test-driven development, fast feedback, and a testing strategy that provides useful evidence without making every change slow.
-
Lower-risk legacy refactoring
Characterisation tests, seams, small steps, and design improvements that reduce risk while the product still has to ship.
-
Pairing and mobbing
Make knowledge visible. Work through difficult tickets together so expertise spreads instead of staying with one senior developer.
-
Reviews that teach
Code review becomes a learning loop rather than a gate. We improve review habits, feedback quality, and shared technical standards.
-
Continuous integration discipline
Keep the main branch releasable with small changes, reliable pipelines, fast feedback, and ownership of broken builds.
-
Architecture that can evolve
Incremental architecture improvement in the code you already have. For a focused architecture intervention, see our architecture review.
-
Responsible AI-assisted development
Use coding agents without eroding review standards: understand generated code, test it, constrain it, and require the team to be able to explain what it ships. For deeper AI engineering, see agentic AI engineering.
How the engagement runs
The engagement has an explicit handover and end point. We reduce our involvement as the team takes ownership.
-
Baseline
We observe how the team really works: a sprint, the code, the pipeline, the review culture, and the points where work gets stuck.
-
Agree targets
We agree a small set of technical targets with the team, not just the manager. The targets connect engineering behaviour to delivery outcomes.
-
Embedded cycles
On regular days, we pair, review, and run working sessions on current tickets. We model the behaviour, then help your engineers own it.
-
Fade out
We deliberately reduce our presence and track whether the agreed practices remain in use. The timing depends on what the evidence shows.
What you get
Changes in day-to-day work, backed by material and measures the team continues to use.
- A baseline of your current engineering habits, delivery flow, and technical constraints
- Agreed targets that the team understands and can influence
- Working examples in your repository: tests, refactorings, reviews, and pipeline improvements
- A more reliable test suite and faster feedback where that is the constraint
- Review and pairing practices that spread knowledge beyond senior bottlenecks
- Practical guardrails for AI-assisted development that preserve understanding and ownership
- Measures showing whether the habits held after we reduced our presence
- A deliberate handover and an end to the engagement, not a permanent coaching dependency
Who this is for
-
CTOs and engineering managers
You are responsible for Java and Spring teams and need engineering capability to improve without adding another process layer.
-
Teams that need practice in context
The team has shared vocabulary, but needs guided application on its own code, pipeline, reviews, and delivery constraints.
-
Organisations scaling delivery
Onboarding takes months, senior engineers are overloaded, and you need technical habits that scale without adding another process layer.
Why us
We bring technical depth, teaching experience, and enough delivery experience to coach in the messy parts of real systems.
Teaching and practice
Patrick has lectured at ZHAW since 2013. He is a Java Champion, Oracle ACE, Microsoft MVP, Spring Certified Professional, and VMware Certified Spring Instructor.
Evidence from prior engagements
In two anonymised engagements, a financial-services team moved from quarterly release trains to daily production deploys, and an enterprise product team increased delivery throughput by 25% after embedded coaching. Results depend on context and starting point.
Small and senior by design
Patrick leads the coaching work, supported by the core team where the engagement needs complementary delivery or teaching expertise. Our verified track record includes more than 20 years in enterprise Java, 70+ conference talks, and 200+ workshops.
Meet the people behind the work on our company page. Explore our other services when coaching is one part of a larger engineering change.
Frequently Asked Questions
How is this different from training?
Training creates shared knowledge in a defined course. Coaching applies that knowledge during normal delivery: in your repository, on your backlog, and with your constraints. The right format depends on whether you need shared understanding or sustained changes in day-to-day practice. See our training programmes.
How much of our team’s time does it take?
It happens during normal work, not on top of it. We pair, review, and run working sessions as part of the team’s existing delivery, typically one to two days per week.
Is the coaching remote or on-site?
Both work. On-site for the first weeks usually works best because it makes observation, pairing, and team conversations easier. We then use the mix that fits your organisation.
How do you measure whether it worked?
We agree baseline measures with the team and track delivery and engineering signals such as lead time and deployment frequency (two of the DORA metrics), review flow, test-suite trust, onboarding time, and the team’s ability to solve problems without us.
What if the team resists?
Resistance is information, not a reason to impose a method. We start by observing real work, agree targets with the team rather than only the manager, and demonstrate improvements on current tickets. The coaching is designed to transfer ownership, not create dependency.
We have more than one team. How does this scale?
We start with one pilot team, usually where the delivery pain is clearest. Reviews and pairing bring neighbouring teams into the work, and we develop internal coaches who can continue the practices. For several teams, a staggered start lets us establish the approach with one team before adding another.
What does it cost?
Typically one to two days per week, three months minimum. We scope the engagement in a 30-minute call.
Build practices your team can sustain
Book 30 minutes with Patrick. Bring the capability you need, the current bottleneck, and the work your team is doing. We will assess whether embedded coaching is the right format.