What I Do

You can think of me as senior technical judgment temporarily embedded into the team.

I am usually brought in when a software system has become hard to manage and that complexity is starting to hurt the business. Delivery feels risky, decisions are hard to make with confidence, and normal roles are no longer enough to restore clarity.

Below you will find the kinds of situations I step into, how I approach them, and when this kind of work is a good fit.

When teams bring me in

I am typically brought in when a system is critical to the business, but no longer feels under control.

Common signs that indicate this kind of situation include:

  • Important systems behave in ways that are hard to predict or explain
  • Teams avoid certain areas because the consequences of change are unclear
  • Delivery slows despite capable people and sustained effort
  • Complexity has accumulated without clear ownership or boundaries
  • Previous attempts to “fix it” failed, stalled, or made things worse
  • Rewriting everything from scratch is not a realistic option

In these situations, the core problem is rarely lack of skill or effort. It is a loss of shared understanding of how the system works, where the real risks are, and what can be changed safely.

What I focus on first

I start by building a shared understanding of how the system works today. Not how it was intended to work, not how people wish it worked, but how it actually works.

Early on, I focus on:

  • Understanding the system end to end: architecture, integrations, runtime behavior
  • Learning the history behind past decisions and trade-offs
  • Making technical, organizational, and budget constraints explicit
  • Identifying where the real risks are
  • Distinguishing between problems that can hurt the business and those that are uncomfortable but safe to live with

I prioritize understanding before change. Action without clarity usually increases risk rather than reducing it.

How I help teams regain control

Once there is shared understanding, I help define a realistic path forward. Not an ideal solution, but a plan that can actually be executed with the people, time, and constraints you have.

This typically leads to:

  • Fewer unknowns and less background anxiety
  • Clearer language for discussing problems and trade-offs
  • Earlier visibility into technical and organizational risk
  • Decisions that stop being guesses
  • More credible planning and prioritization

The goal is restored control and deliberate progress.

How I stay involved

I don’t stop at recommendations.

I stay involved during execution where it matters most. I work hands-on in high-risk areas, reviewing critical decisions, and adjusting the plan as reality unfolds. This ensures the path we define holds up in practice, not just on paper.

When I leave, the system is in a better long-term position, and the team understands the decisions that were made and can carry them forward without me.

When this is not a good fit

This kind of work requires a real problem and a willingness to decide.

It is usually not a good fit when:

  • Goals are undefined and no one is willing to make trade-offs
  • There is no clear decision maker
  • The expectation is instant fixes or progress without decisions
  • The work is chronically underfunded or driven purely by cost cutting
  • Senior judgment is requested, but not trusted

I do not promise miracles or outcomes that ignore real constraints.

Next step

If this sounds familiar, the next step is simply to get in touch.

Tell me a bit about what’s going on, and I will let you know how I might be able to help.

Contact me
© 2026 Conifer Media · Independent Software Consulting by Michał Wilkosiński · Europe