Tobias Schlitt

I start with a 2-day on-site workshop with 2-3 of your most interested and skilled engineers. We analyze your codebase and the full process around it - how requirements come in, how your teams collaborate, how QA, deployment, and all other functions involved in your delivery chain work together. From that, we craft an agentic workflow tailored to how your organization actually operates - including all required artifacts and tools, such as context files, skills, and prompt structures.

We then introduce the workflow to a single team in a dedicated full-day hands-on session, where they work through their first real tickets using the new process with me in the room. After that, the team pilots the workflow for the first couple of iterations on their own. The goal: test real-world acceptance, see if quality holds up, and refine the process based on what actually happens when it meets daily work. I stay available on a regular basis for guidance and feedback during this phase, typically for 4-8 weeks.

Once the workflow proves itself, we roll it out to additional teams - each with their own hands-on introduction and guided pilot phase. After the broader rollout, we evaluate together: what works, what needs adjusting, what's next. From there, we can bring in the departments attached to engineering - product, QA, support, and others - helping them integrate into the agentic way of working. This can start during the rollout if you're ready for it.

Three things matter throughout: engineers need to feel confident that this helps them, not replaces them. The workflow must improve actual team output, not just generate more lines of code. And everyone involved works in a shared, structured way - with clear guardrails, but enough autonomy for each team to make it their own.

I begin with a workshop with your senior engineers and leadership - understanding your challenges, your goals, and where you want to go. Then I step back and do the deep work: I research, I analyze, I talk to the relevant stakeholders where I need further clarification or alignment, and I think through the options and their consequences properly. The result is a recommendation paper - an honest analysis of your situation, evaluated approaches with trade-offs clearly named, and a clear recommendation with reasoning for why I lean a certain way.

We discuss the paper together, remote or on-site. You might find you can take it from there on your own. Or you might want me to help execute: on-site workshops with the affected teams, hands-on architecture work, concept papers, training on specific methodologies, review sessions. How we work together from there is entirely open - we find whatever shape fits your situation and your team best.

I start with a half-day on-site session, 1-on-1 or with up to three people in similar positions. We set baselines: where are they, what are their challenges.

Then we move into regular remote sparring sessions - typically one hour on a regular basis, as frequently as needed. I invest time between sessions thinking through their specific situation. We work on concrete things: how to help a junior engineer who's struggling, how to scope a large refactoring effort, how to run a productive review, how to measure progress without making people feel controlled, how to handle engineers who push back against new ways of working.

This is a confidential space - they can ask things openly, without it leaking into their performance review. I've been a principal engineer myself, and I know what the job actually looks like on a Tuesday morning.

Before bringing both sides into a room, I talk to each party separately - engineering and business - in a confidential setting. I want to understand their actual situation, their motivations, what they're trying to achieve. I can do this because I genuinely understand both worlds: I've worked in technical roles for over 25 years and I've co-founded and led multiple companies myself. I know what keeps a CTO up at night - and I know what keeps a CEO up at night.

Then we come together for a 1-2 day workshop where I translate between both views, make the invisible visible, and help both sides arrive at a shared understanding. I document the outcomes - a report both sides can commit to.

From there, we can move into long-term coaching: I help set up and moderate regular alignment meetings where real issues get discussed honestly. New customer priorities, unexpected technical challenges, resource trade-offs, incidents - all the things that erode shared understanding over time. My role is to be the sparring partner for both sides and to keep that honest conversation going.