Why Every Role at semperMade is Filled by a Software Engineer

Why Every Role at semperMade is Filled by a Software Engineer

Most software vendors separate technical delivery from client management. Account managers handle relationships, project coordinators handle status, and engineers handle the code. At semperMade, those roles are collapsed into one type of person: a software engineer who can also own the client outcome.

The short answer

Every person at semperMade who touches a client engagement is a software engineer. The partner who owns the account writes and reviews code. The person coordinating the project can read the codebase. The person answering client questions can evaluate technical risk. This is not a cost-cutting choice. It is a quality choice.

Why non-technical layers slow projects down

When a client asks a question, the answer usually travels through multiple people. A project manager asks an engineer, the engineer answers, and the project manager relays it back. Each hop is a chance for meaning to slip. Technical questions get translated into business language, business concerns get translated back into technical tickets, and by the time the work starts, neither side is sure the request is right.

The result is rework. Features are built against the wrong interpretation. Risks are hidden because the person reporting status does not know what to look for. Velocity is lost to clarification loops that should never have existed.

How the pod model works

Our team is organized into small pods led by senior engineers. Each pod handles a specific set of clients, and the partner who owns the pod is accountable for delivery. Reporting flows in one clean line: client, partner, senior engineer, engineers and junior engineers. Every person in that chain writes, reviews, or has shipped production code.

When a client raises an issue, it is escalated through people who can actually evaluate it. There is no layer that has to ask engineering what it means. That changes the speed and accuracy of every decision.

What this means for clients

Clients get direct access to technical decision-makers. Scope is discussed with someone who can estimate real effort. Risk is explained by someone who has seen the code. Status updates are given by someone who knows whether the work is actually on track, not just whether the tickets are closed.

This is especially important in complex or regulated work. Federal programs, legacy modernizations, and AI-built rescues all require judgment under uncertainty. The team that guides the work must be able to understand the software itself, not just the project plan.

What we do not do

• We do not staff engagements with non-technical account managers who act as translators.
• We do not separate project coordination from engineering understanding.
• We do not let junior engineers ship without senior review.
• We do not pretend that status updates are a substitute for technical accountability.

Why this is hard to scale

A technical-only model does not scale as fast as a body-shop model. We cannot hire generalist project managers to cover more clients. We cannot subcontract engineering work to meet demand. Growth is limited by the number of senior engineers we can hire and trust. We accept that limit because the alternative is a different kind of company, and not the one we want to run.

How to evaluate a vendor's team model

If you are choosing a vendor, ask who will be in your meetings, who will review the code, and who is accountable if the work is late or wrong. If those are three different people who never talk to each other, the risk is higher than it looks. If they are the same person, or a tight technical team, the feedback loop is shorter and the accountability is real.

That is the model we have built. You can read more about it on our team page or in the broader story on our about page.