An outside look at what slows your delivery down — and what to fix first
As the codebase and the team grow, delivery slows, releases start to feel risky, and nobody can say with confidence which change would pay off most. What helps at that point is not another internal opinion, but someone who looks at the system, the pipeline, and the decisions from the outside. I work remotely: video sessions with a shared screen on your codebase, and a written deliverable at the end.
What I typically see
Familiar situations
- Releases feel riskier, so they happen less often — which makes them riskier still.
- Everyone knows CI is slow, but nobody can say where the time actually goes.
- Architectural decisions were never written down, and the people who made them have left — newcomers reverse-engineer intent from the code.
- Two teams follow two different sets of conventions, and code review is where it gets decided which one wins.
- There is a refactoring plan that hasn't started in two years, because the right moment never comes.
- Leadership expects feature velocity, the team wants to pay down technical debt first — and there is no shared language to settle it.
- Infrastructure and deployment rest on tribal knowledge: one person knows how a release actually goes out.
Delivery and architecture review
- We walk through your current architecture, deployment setup, and engineering practices — focused on what actually blocks delivery and what makes change risky.
- We identify the bottlenecks and the places where a small change buys a large improvement, so you know where to act first.
- A written summary and concrete, prioritized next steps your team and your leadership can both work from.
Decision support
- Facilitated sessions to capture technical decisions as ADRs, so the rationale outlives the current team.
- Help comparing architecture options against explicit trade-offs — not on instinct, but in a way that still holds up six months later.
- A second opinion on what your team or a vendor is proposing: from the outside, with no stake in the outcome.
- Help articulating risks and constraints so non-technical stakeholders can take part in the trade-off.
Mentoring for tech leads
- 1:1 or small-group mentoring for tech leads and senior engineers — on whatever is actually on their desk, not on theory.
- Practical discussions on how to introduce and sustain new practices: ADRs, boundaries, CI/CD — in your codebase, with your team.
- Feedback on architecture proposals, RFCs, and rollout plans, before production reveals what was missing from them.
Entry engagement
Review — 2–3 weeks, with a written deliverable
Three 90-minute video sessions. In the first we go through where you stand and what hurts. In the second we walk the codebase, the pipeline, and the architecture together — not slides, your actual systems. In the third I hand over what to fix and in what order. Between sessions I am available in writing.
At the end you get a written document: what slows delivery down, what to tackle first, and what to leave alone for now. In a form you can put in front of leadership — the same logic as an ADR, written for a business reader.
How remote work looks in practice
Every session runs as a video call with a shared screen. Where you allow it, I also look into the codebase, the CI config, and the deployment scripts — read-only access is plenty. Between sessions I am reachable by email, and on a shared Slack channel if that suits the team better. Nobody has to travel, and no full day has to be cut out of the team's calendar.
If you still want an outside view afterwards
The review stands on its own: it does not end with you halfway through and holding a proposal. Where rolling the changes out does call for a continuing outside view, we carry on with a monthly arrangement — two sessions a month, with written availability in between. Nothing depends on it, and it is decided after the review, not before.
What I say no to
In consulting, the good business is the one that lasts as long as possible. That is not what I am after.
- I don't write strategy documents that nobody opens in the next planning round.
- I don't propose a rewrite when the existing system can be fixed — a rewrite is the most expensive answer to most questions.
- I don't introduce a process just because it worked at a larger company. I adapt it to your constraints, or I leave it alone.
- I don't take your decisions away from you. I help you make them and write them down, but the system stays yours.
- If it turns out that what you need right now is a hire, a tool, or simply time rather than consulting, I will say so plainly.
Why me
I'm Krisztián Papp. I have been designing and building systems for fifteen years — hands-on, in codebases, pipelines, and architectures, not in slide decks. I speak regularly at conferences and meetups about ADRs and what it costs when decisions go unwritten. You work with me directly: there is no team behind me that the work gets handed to.
A separate focus area
AI-assisted engineering transformation
AI tools really help teams that already have solid engineering practices — for everyone else they typically just accelerate the accumulation of technical debt. This is a separate focus area: AI readiness assessment, decision support on concrete AI decisions, and team-level practices.
A short note about your current systems and where you got stuck helps more than a long brief.
What if training is the better fit?
If what the team needs is not an outside view but shared practice on a specific topic, there are separate workshops for that.
See the training