Less talking. More doing.

By Col. Matthew Paul, Acting Deputy CPE, ES2

I say it often enough that my team has started finishing the sentence for me: less talking, more doing.

It is not a management philosophy. It is a diagnosis. In my experience, the single biggest obstacle to faster Army software development is not technology, not budget and not talent. It is time spent doing everything except building and delivering software.

We meet. We brief. We review. We staff. We coordinate. We schedule the meeting to plan the meeting. And in the spaces between all of that activity software gets developed.

It does not have to work this way. I have seen what happens when teams are empowered, decisions are pushed down and the organizational friction is cleared. The speed is there. We just have to choose it.

Here is what that choice actually looks like.

Stop defining everything before you build anything. The waterfall mindset is still with us, just wearing different clothes. We schedule months of working groups, stakeholder sessions and documentation reviews. By the time the requirements are locked, the problem has changed.

The Accessions Information Environment (AIE), our program to modernize Army recruiting, learned this the hard way. AIE’s original platform was built using a waterfall approach. Development included significant customization, which created technical debt before the first user touched it. We made the call to stop, reboot and do it differently.

The new approach: Define the minimum viable capability, get it in front of real users and iterate.

AIE’s Soldier-Centered Design Exercises (SCDEs) are a key enabler of our new approach.

SCDEs help AIE work out the kinks — not just technical kinks, but process kinks. They create the conditions where the team can fail fast, learn fast and fix fast without every iteration becoming a major event. That is exactly what Agile development requires, and it is exactly what traditional government IT has historically made very difficult.

The same principle applies across my portfolio, and the Global Force Information Management (GFIM) program illustrates it from a different angle.

GFIM took a deliberate tactical pause. Not to slow down, but to reassess. The team recognized it was trying to do too much at once and chasing perfect requirements before a single line of code had been written. The reset was simple and clarifying: if the capability allows the user to do their job, that’s the baseline. “Need to have” drives the sprint. “Nice to have” waits.

Integrated Personnel and Pay System — Army (IPPS-A) has adopted a two-week Agile development sprint cycle, mirroring industry-leading software engineering practices. Unlike its static legacy predecessors — which required months or years to plan, resource, test and field major updates — IPPS-A continuously delivers system improvements every two weeks.

For IPPS-A, Agile methodology translates directly into rapid operational responsiveness. Soldier feedback from the field can progress from an initial problem report to a deployed system fix within weeks rather than years, eliminating the need to delay critical updates until major release cycles.

This consistent sprint cycle ensures that IPPS-A continually scales in capability over time. Rather than being fielded and allowed to stagnate like past platforms, IPPS-A operates as a dynamic, continuously modernizing system with an accelerating pace of enhancement.

Push decisions down — and mean it. Speed dies at approval gates. Every time a decision that could be made by a program manager, a product owner or a team lead has to travel up a chain before it can move forward, you lose days. Sometimes weeks. Multiply that by every sprint, every release, every integration event and you understand why programs that adopted Agile still feel slow.

Empowerment is not a slogan. It means a product owner who can accept a user story without running it up the chain. It means a program manager who can make a risk acceptance decision without a signature on a waiver. It means trusting the people closest to the work to make the calls they are in the best position to make.

I tell my team: If you are waiting for me to make a decision that you could make, you have already made a mistake. Their job is to bring me the decisions that genuinely require my level. Everything else, own it.

Senior leaders who want their programs to move faster should ask themselves honestly: Am I a resource for my team or am I a bottleneck?

Kill the compliance theater. I want to be precise here because this point gets misread. I am not anti-compliance. Cybersecurity requirements, data protection standards and acquisition regulations exist for real reasons, and I take them seriously.

What I am against is compliance theater — the performance of compliance without the substance of it. Checkbox exercises that consume months of calendar time without making systems more secure, more reliable or better for users. Documentation requirements that describe software nobody has built yet in language that only lawyers can parse.

When something is blocking progress and nobody can explain why it exists, that is a signal, not a stop sign. Challenge it. If it matters, someone will be able to tell you why. If nobody can, you have your answer.

Build badgeless teams. One of the most significant shifts my programs have made is moving toward badgeless teams. My teams working on a capability include government civilians, military personnel and contractors — and the badge matters less than the work.

All of my programs operate this way. As Valarie Tran, AIE's product lead, puts it: “We develop software in a badgeless environment. Everyone, regardless of title, shares responsibility for solving problems.” That is not a cultural aspiration. That is how my teams run sprints.

Shared accountability changes how fast problems get solved. When everyone owns the outcome, the finger-pointing that slows programs down tends to disappear. The question stops being “whose lane is that” and starts being “how do we fix it.”

Use what exists. Very few Army software problems require custom solutions built from scratch. Very few mission-specific issues truly require bespoke development.

AIE is proof. The program runs on Salesforce — a commercial platform used by thousands of commercial organizations worldwide. The Army did not need to build a customer relationship management platform from the ground up. We needed to configure, integrate and deploy one that had already been stress-tested at commercial scale. The customizations that sank AIE’s original waterfall build were not requirements. They were habits — the reflex to modify commercial software to fit Army processes rather than adapting Army processes to leverage what commercial software already does well.

The same logic applies at enterprise scale. IPPS-A is the Department of War’s largest enterprise resource planning system, serving 1.1 million users across all Army components. It did not get there by building a bespoke, tailor-made solution to consolidate what already existed. It got there by rationalizing the functionality of over 28 legacy systems into a single commercial platform, Oracle Peoplesoft, while minimizing software customizations in favor of business process reengineering to align to Army processes.

IPPS-A is coordinating subsumptions of an additional 20 systems scheduled for decommission in fiscal years 2026 and 2027. Every system that goes away is a seam that disappears, a data handoff that no longer breaks and a manual workaround that no longer needs to exist. That is what “use what exists” looks like at scale — not just adopting a platform, but having the discipline to stop maintaining the ones you no longer need.

Use AI to give time back to developers. The AIE team looked at where developer time was still being consumed and went after it.

Decomposing a high-level feature into user stories, technical enablers and test cases used to take a skilled team member about 10 hours. It is essential work — you cannot skip it — but it is also largely analytical, pattern-based work. The kind of work AI is good at.

The AIE team built a tool called Decomposer. It draws on an internal knowledge base of over 1,500 curated articles built over two years of program history. Feed it a feature overview and it returns a decomposed set of user stories, enablers and test cases in under five minutes. The output is 50 to 80 percent complete — a human still reviews and refines it — but 10 hours becomes five minutes. That time goes back to the developers who can use it to build.

Talk to users — before, during and after. Software that nobody uses is not a software problem. It is a requirements problem, a communication problem or a culture problem — often all three.

AIE's early adopters inside the Indianapolis Recruiting Battalion are not passive recipients. They are partners. Recruiters who understand the science and art of recruiting told the team what worked and what did not, sprint by sprint. That continuous feedback loop is not a feature of AIE's development model — it is the engine.

There is very little patience in today’s Army. Soldiers who interact with enterprise systems have been using commercial applications on their personal phones for years. They know what good software feels like. If ours does not meet that standard, they will tell us.

User feedback is not a nice-to-have. It is the mechanism by which the program learns. Without it, you are not doing Agile — you are doing waterfall with shorter sprints.

Get out of the building. GFIM did something most program offices don’t: they stopped scheduling virtual meetings and sent developers directly to the field. When GFIM was supporting the rapidly evolving requirements of the Total Army Readiness Review, the team embedded with Soldiers at the 1st Infantry Division. Sitting beside them, GFIM developers built the exact dashboards those divisions needed in days. Not weeks. The difference was proximity. You cannot replicate that in a Teams meeting.

The speed is already here. I want to end where I started, because I think it is the most important point.

The Army has the talent to build great software quickly. AIE, GFIM and IPPS-A are not outliers — they are examples of what happens when a team pivots hard, commits to Agile, uses commercial off-the-shelf software, runs badgeless, listens to users and applies AI where it creates real leverage.

The barriers to faster delivery are not primarily technical. They are meetings that should be emails, decisions that should be pushed down but are pulled up, requirements that are still being written while user needs have already changed and compliance processes that exist because they always have, not because they still should.

Less talking. More doing. It sounds simple because the idea is simple. Executing it requires organizational courage: the willingness to empower people, accept risk at the right level and trust that moving forward with imperfect information is better than standing still with perfect analysis.

We are doing that work. The programs in my portfolio are delivering capability faster than they were three years ago. AIE is modernizing Army recruiting on a commercial platform. GFIM is building readiness dashboards in days by putting developers in the field. IPPS-A has replaced over 23 legacy systems. We are not done. But the direction is right, and the results are real.

Now stop reading and go build something.