Five Technical Questions Anyone Can Ask

The delivery model only works if the people closest to the work can notice when engineering needs to enter. This isn’t about product, design, or agency teams solving the technical problem themselves — it’s about spotting a real technical dependency, risk, or decision that needs an engineer’s judgment. You don’t need the answers; you need to know how to ask.

Five Technical Questions Anyone Can Ask

What does this work depend on to function?

Before anyone commits to a direction, map what the work is standing on. Follow-ups to draw out:

Which existing systems does this work touch today, and who keeps them running?
Where does the data live right now, and who owns it?
Is this replacing a tool people use today, plugging into one, or changing how one behaves — and which one?
Which vendors are already in the picture, and what are they responsible for?

Worth asking because when work leans on existing systems, data, vendors, or platforms, engineering may need to assess feasibility, constraints, and risk before the team treats the path as real.

What has to be true for this to work?

Every plan rests on technical assumptions; this question drags them into the open so they can be tested. Follow-ups to draw out:

What tells us an API actually exists for the system we’d integrate with?
How would we get the data out of where it lives today, and in what shape would it come?
What would it take for a vendor to connect to State systems?
Who has actually confirmed that SSO, hosting, reporting, and security approval will go smoothly?
When someone says it’s “just a form” or “just a workflow,” what does that form or workflow really have to do?

Worth asking because projects fail when untested technical assumptions harden into planning assumptions. Bring engineering in to validate the one the whole plan rests on.

Which decision is stuck without an engineer’s read?

Pin down the specific decision that can’t move until someone with technical judgment weighs in. Follow-ups to draw out:

Are we choosing to build, buy, configure, or reuse — and what’s driving that choice right now?
Where would this be hosted, and why there?
What tells us the legacy system can carry the workflow the team wants next?
A vendor made a claim — what would make that claim credible to you?
What do we actually know today about whether this outcome is technically possible?

Worth asking because engineering should be assigned to real decisions, risks, and deliverables — not to general uncertainty that a conversation with product could resolve.

What are the security, identity, and compliance realities here?

Surface who touches the data and under what rules, early enough to shape the plan. Follow-ups to draw out:

What data does this work involve, and how sensitive or regulated is it — think PII, PHI, CJIS, or IRS records?
Who needs access, and how do they sign in today — SSO, MFA, something else?
What approvals stand between this and launch — an ATO, a security review, specific hosting controls?
Once it’s live, who operates it and answers the support calls?

Worth asking because security and compliance should inform product and procurement decisions early — while staying short of turning Stage 1 into full implementation design.

What happens the day after it’s built?

Trace the life of the thing past launch, when the deploying team is gone. Follow-ups to draw out:

Who owns the product once it ships?
Who maintains the code, the configuration, and the vendor relationship?
Who picks up the phone when it breaks — and what happens the first time it does?
How do changes get deployed after go-live?
How does anyone see performance, uptime, and incidents?
What capability has to exist on the receiving side before MDDS can exit?

Worth asking because launching isn’t succeeding. Engineering helps surface long-term operational and maintenance risk before the team commits to carrying it.

When These Questions Trigger Engineering Support

Bring engineering in when the answer to any of these questions is:

Unknown, and important to where the project is heading.
Based on an assumption no one has validated.
Tied to funding, procurement, security, or whether delivery is even feasible.
Likely to shape long-term operations or maintenance.
Likely to create significant risk if it’s discovered late.

Here’s the honest check that goes the other way. If the team can’t yet explain the problem, the users, the current process, or the decision that needs making, the project needs more product and discovery work first — not an engineer. A technical question can’t get a useful answer until there’s a real problem underneath it.

Engineering shouldn’t be pulled in because a project feels uncertain — it should be pulled in when there’s a technical assumption, decision, risk, or operational consequence that needs judgment.