Chief Engineer

Job Description

Job Description

Make the whole system work.

A feature can work perfectly and still be part of a system that does not.

The services can all be healthy while the workflow fails. The application can pass functional testing and fall apart under realistic load. A new integration can solve today's problem while quietly creating the dependency everyone regrets two years later.

Someone has to be responsible for seeing the whole thing.

That is the Chief Engineer.

Pioneering Evolution has spent more than 15 years building software for federal acquisition and financial management — the budgeting, planning, tasking, and execution processes that move real money and support real mission decisions. We are now building a federated enterprise platform intended to connect those processes, systems, data, and decisions in a way that can grow far beyond any single application or contract.

The platform is being built now. The important architectural decisions are not all behind us.

If you want the responsibility of shaping what that system becomes, this is that job.

The architecture, honestly:

At Pioneering Evolution, we are building SyncCore™ — a Mission Operating System (Mission OS) designed to connect data, systems, workflows, and decisions across complex mission environments. SyncCore provides the secure, event-driven digital backbone for identity, integration, canonical data, governance, auditability, and interoperability, creating the foundation on which mission capabilities can evolve.

Built on SyncCore, SyncPoint™ is a modular application ecosystem composed of independently deployable modules supporting requirements management, budgeting, task planning, resource allocation, execution, and decision support.

Real programs. Real money. Real decisions.

The Chief Engineer owns the system architecture and engineering standards that keep all of that functioning as one platform.

You will make the significant decisions about service boundaries, integration patterns, messaging, scalability, observability, performance, shared capabilities, and how the architecture evolves as new requirements arrive. When we introduce another external system, change how events move through the platform, add an AI capability, evolve our data architecture, or discover that something works at ten users but not at a thousand, you should be involved.

Not every ticket needs the Chief Engineer. Architectural authority should not become architectural bureaucracy.

Your job is to recognize the decisions that have consequences beyond the feature in front of us and make sure we get those decisions right.

How the leadership actually works here

We want this to be clear before day one.

The Product Owner owns the requirements process, working from stakeholder needs to complete functional requirements and acceptance criteria.

The Technical Lead owns day-to-day engineering execution — technical decomposition, developer coordination, sprint execution, code review, blockers, and the handoff of completed development to QA.

Senior Software Engineers own significant capabilities end to end and are expected to bring architectural proposals rather than wait for them. They argue for where boundaries belong, how services communicate, and how data moves, and they back those positions with what the code and production actually show. Mentorship and raising the engineering capability of the team is shared work between the Technical Lead and the Senior Engineers.

The Chief Engineer owns the system architecture and engineering standards. You have final technical decision authority when a decision materially affects that architecture.

That authority should rarely feel adversarial. The best outcome is a strong Chief Engineer, Technical Lead, and development team challenging one another constructively and arriving at better answers together. But when the system needs a decision, this role is accountable for making it.

DevSecOps, Cybersecurity, QA, Data Engineering, and AI/ML are separate technical functions with their own expertise and leadership. You do not manage those people simply because their work affects the architecture.

You do own the architectural outcome.

You will work with DevSecOps and Cybersecurity to ensure deployment patterns, pipelines, scanning, STIG requirements, observability, and the technical aspects of our federal authorization environment are appropriately designed. You will work with QA to establish the non-functional strategy for performance, load, stress, reliability, and system-level validation. You will work closely with the Data Engineer and AI/ML Engineer so that data services and AI capabilities become coherent parts of the platform rather than isolated technical experiments.

Ownership of the outcome is not the same thing as owning every person who helps produce it.

This is still an engineering job

We are not looking for someone whose architecture exists primarily in diagrams.

You should stay close enough to the code and deployed system to know whether the architecture actually works.

Sometimes that means reviewing a design or a pull request because it has system-level consequences. Sometimes it means pairing with an engineer on a difficult concurrency problem. Sometimes it means profiling the application, tracing an event across services, proving an integration approach with a prototype, or sitting with DevSecOps until a systemic deployment problem makes sense.

And occasionally it means opening the IDE and building the solution yourself.

You will not normally carry a developer's sprint workload. If you do, you will not have enough time to do the job we actually hired you to do.

But we also do not want a Chief Engineer whose response to an urgent technical problem is "not my job." Good technical leadership means knowing where your involvement creates the most leverage, and being willing to go there.

The current environment:

Our platform uses C# and modern .NET / ASP.NET Core, PostgreSQL with Entity Framework Core, asynchronous and event-driven messaging, Angular and TypeScript, containerized workloads, CI/CD, and Azure / Azure Government. The broader architecture includes distributed workflows, microservices, micro-frontends, shared platform capabilities, multi-tenancy, external integrations, and emerging data and AI/ML capabilities.

The implementation contains more technology than fits comfortably in one paragraph. That is intentional.

You do not need prior experience with every product we use. At this level, though, the specifics matter more than they do for an early-career engineer. You need enough modern .NET depth to work credibly in the codebase and enough distributed-systems experience to understand the failure modes that appear only after individual components begin interacting.

We care less about whether you have used our exact message broker than whether you understand idempotency, retries, ordering, eventual consistency, and what happens when distributed work fails halfway through.

Architecture vocabulary is useful.

Architectural judgment is the requirement.

What we actually require:

• Significant professional software engineering experience, typically 10+ years, with substantial responsibility for architecture or technical direction of complex enterprise systems.
• Demonstrated ownership of system-level architectural decisions, not simply feature or component design.
• Strong systems thinking across distributed applications, APIs, integrations, relational data, asynchronous messaging, service boundaries, performance, scalability, reliability, and observability.
• Strong hands-on experience with C# and modern .NET / ASP.NET Core and enough current technical depth to work directly in a production codebase when necessary.
• Experience diagnosing difficult problems that cross application, data, integration, infrastructure, or service boundaries.
• A track record of making consequential technical decisions while balancing long-term architecture, delivery needs, technical risk, and maintainability.
• The ability to establish useful engineering standards without creating unnecessary process or abstraction.
• The ability to explain technical decisions clearly, defend them with evidence, listen seriously to competing ideas, and change direction when the evidence says you should.
• The ability to work effectively with senior engineers and specialists across product, data, QA, DevSecOps, cybersecurity, and AI/ML.

Years alone do not make someone a Chief Engineer. We are looking for evidence that you have been responsible for what happened to the system, not only the portion of it assigned to you.

Particularly useful, not an entrance exam

• Azure or Azure Government and containerized application platforms such as Kubernetes.
• Event-driven architecture, sagas, eventual consistency, and complex distributed workflows.
• Enterprise frontend architecture or micro-frontends.
• Performance engineering, capacity planning, or large-scale production troubleshooting.
• Federal or other regulated environments, including RMF and ATO activities.
• Integrating enterprise data, analytics, AI/ML, or generative-AI capabilities into production systems.

Who thrives here:

We move fast, and we are trying to create something special — a platform whose architecture is still worth defending ten years from now. A slow company does not get to do that, and neither does a mediocre team. Ours is small, genuinely dynamic, and staffed with talented engineers who will argue with you on the merits and expect you to argue back.

That takes people who notice problems before they become incidents, and architectural consequences before they become technical debt.

You should enjoy strong technical debate without needing every disagreement to become a contest. You should be comfortable saying, "I don't know yet — let's prove it." You should want talented Senior Engineers to challenge your assumptions, because the point of being the final technical authority is not to always be the smartest person in the conversation. It is to make sure the system ultimately gets the right answer.

You should also want your decisions to matter.

There are Chief Engineer jobs where architecture means governance meetings, slide decks, and approving other people's work.

This is not one of them.

The platform is still taking shape. The team is small. The distance between identifying the right technical answer and seeing it running in production is short.

If you have spent the last few years wishing you could fix the system instead of repeatedly fixing its symptoms, we should talk.

Clearance, citizenship, and location

• U.S. citizenship is required. No exceptions.
• An active clearance is not required to apply. Active Secret is welcome. Otherwise, interim Secret eligibility is required and PE sponsors — we will walk you through it.
• Hybrid, a few days a week at our Arlington HQ, 2550 S. Clark Street.

What we offer:

$150,000 – $190,000 based on demonstrated technical depth, scope of prior architectural responsibility, and interview performance. Plus paid time off, 10 paid holidays, medical, dental, and vision insurance, company-paid life and AD&D, company-paid short- and long-term disability, 401(k) with company contribution, legal assistance, tuition reimbursement, and continuing education opportunities.

And the part that matters specifically for this role: the architecture is not finished, the authority is real, and there is very little distance between a sound technical decision and seeing it become part of the platform.

Innovate. Accelerate. Evolve.

Pioneering Evolution is an equal opportunity employer.