Eric Krohnfeldt
Résumé PDF

Approach / Complex systems

Solve the underlying problem, not just the visible bug.

My work often begins when a problem has crossed the boundaries between services, teams, data, infrastructure, or operational ownership. I start by making the failure understandable, then build the smallest reusable model that prevents the same class of problem from returning.

  1. Understand the actual failure before choosing the fix

    The visible symptom may be several boundaries away from the underlying problem.

    Practical consequence
    Trace behavior across services, events, data, infrastructure, and operational workflows before changing the system.
    Supporting example
    Out-of-order events appeared as different service bugs, but the durable solution belonged in shared platform behavior.

    Production problems rarely respect organizational or technical boundaries. A failure may begin in one component and surface several boundaries away.

    I trace the full path before deciding where the correction belongs. This prevents a visible symptom from turning into another local exception while the underlying system continues to fail in the same way.

  2. Replace collections of special cases with a coherent model

    A new conditional for every incident makes the system harder to reason about.

    Practical consequence
    Identify the shared rule and move it into reusable behavior that can be tested, adopted, and maintained consistently.
    Supporting example
    The event-processing framework replaced service-specific fixes with one reusable reliability pattern.

    When each new bug creates another one-off rule, maintenance eventually becomes the larger failure. The repeated exceptions are evidence that the system is missing a useful model.

    I look for the common rule behind those cases and move it into a reusable library, platform capability, template, or workflow. The result can be tested and improved once instead of rediscovered in every affected component.

  3. Build leverage into repeated engineering work

    Repeated manual work is often evidence that the platform is missing a tool or source of truth.

    Practical consequence
    Use shared configuration, generation, templates, and automation so future work becomes routine.
    Supporting example
    Centralized Maven parent POMs and reusable Git templates replaced repeated service-by-service setup with a shared foundation.

    I prefer solving repetitive work once. Shared configuration, code generation, build tooling, and automated workflows let engineers spend less time reconstructing boilerplate and more time on the parts that require judgment.

    The useful measure is not how much automation exists. It is whether the next change becomes easier to understand, validate, and maintain.

  4. Treat operation and maintenance as part of the architecture

    A system's real design includes deployment, failure, observability, recovery, security, and ownership.

    Practical consequence
    Evaluate how a system will be supported and changed before implementation is considered complete.
    Supporting example
    The manufacturing control system included application code, virtualization, network failover, equipment integration, and production support as one design.

    Architecture does not stop at a clean component diagram. A dependable system also defines how it is deployed, observed, recovered, secured, upgraded, and supported.

    Maintenance cost is an architectural consequence. It should be evaluated with performance, complexity, and delivery speed before implementation is considered finished.

  5. Automate repeatable work while preserving accountable judgment

    Automation should reduce toil without hiding important decisions.

    Practical consequence
    Let tools perform known workflows while keeping final review and production authority visible.
    Supporting example
    Development agents implement tickets and address pull-request feedback, but human review remains the final approval checkpoint.

    Automation is useful when the process and policy are understood. It can carry out known workflows consistently and preserve a decision the team has already made.

    New tradeoffs still require accountable judgment. In my agentic-development platform, agents complete implementation and review corrections while a human remains responsible for final code approval.

Use the right technology for the problem

My career has required work across application code, user interfaces, databases, cloud infrastructure, industrial controls, virtualization, networks, and physical equipment. I do not begin with a preferred tool. I begin with the constraints.

  • Healthcare microservices and event processing
  • Cloud and developer-platform infrastructure
  • Manufacturing equipment, networks, and control systems

Guide teams without adding unnecessary ceremony

I translate requirements into implementation designs, explain architectural choices, review code, teach patterns, and help less-experienced engineers work through difficult problems. The objective is not control. It is to make sound engineering decisions repeatable across the team.

  • Technical direction for teams of approximately 4–10 engineers
  • Mentoring for Level I and Level II engineers
  • Technical interviews and candidate evaluation

Let's talk

Need someone who can take ownership when the problem crosses every boundary?

Open to remote software engineering and architecture opportunities in the United States.

Download résuméSend email