About Dustin Schneider
Understanding the business, the people, and the systems behind the work.
My experience spans software development, technical architecture, business operations, and organizational leadership. I help business owners, boards, and leadership teams examine problems that cross those boundaries. In these situations, it is not immediately clear whether the issue is technology, process, information, or how decisions are being made.
I’ve worked at both ends of that conversation: developing strategy and leading operations, while also building the software, working with the databases, and supporting the people expected to use the systems.
That combination shapes my approach. I want to understand how an organization actually works before recommending how it should change.
Experience beyond the recommendation
I’ve served as CEO, led technical development, and built software products. My hands-on work includes application architecture, databases, reporting, infrastructure, deployment, troubleshooting, and integration with legacy systems.
One example is a custom customer portal I designed and built that processes more than US$3 million in transactions annually and has more than 10,000 users. The work extended beyond the customer-facing application to the administrative tools, business rules, reporting, and infrastructure needed to support daily operations.
My organizational work has been similarly hands-on. As part of an assessment, I interviewed every employee in a company, examined responsibilities and workflows, developed business improvement recommendations, and presented findings to leadership and stakeholders. I’ve also been responsible for implementing changes, training users, and addressing the practical problems that appear after a plan meets daily operations.
My work also includes developing practical plans for new initiatives. For a community organization seeking stronger local engagement, I developed a proposed program of recurring educational and cultural activities.
The plan defined what participants should gain from each activity, established a monthly schedule, and distributed delivery across a small team. It used existing community venues and was designed to begin at a manageable scale, with room to expand as resources became available.
This reflects another part of my approach: connecting an organization’s purpose to a specific experience for the people it serves, then working through what would be required to deliver it.
These experiences help me evaluate more than whether an idea sounds reasonable. I consider whether it can be implemented, what it depends on, and whether the people responsible for carrying it forward have the information, authority, and resources they need.
My experience as an airline captain also informs my approach to preparation, risk management, clear communication, and decision-making when information is incomplete.
Following the problem across boundaries
A report that takes too long to produce might involve an inefficient database query. It might also involve inconsistent records, repeated manual steps, or unclear responsibility for providing the information.
A system that appears unreliable may contain a genuine defect. It may instead be configured incorrectly, poorly understood, or being used for something it was never designed to do.
Those explanations lead to different recommendations.
I work to distinguish them by examining records, observing workflows, speaking with the people involved, and reviewing the underlying systems. I look for recurring patterns, then test those patterns against the available evidence. Where information is missing, I separate what is known from what still needs to be established.
For an owner or board, the value is a clearer explanation of what is happening and a practical basis for deciding what to do next.
Carry the torch, not worship the ashes
I have hands-on experience with legacy software and long-established business processes. I don’t assume a system needs replacing simply because it is old. I also don’t assume an established practice deserves to continue simply because it is familiar.
I start by understanding its purpose, why it developed, and what knowledge people rely on to make it work.
Some of that knowledge may be essential. Some steps may exist only because of a limitation that no longer applies. The work is to distinguish between them.
Sometimes the right answer is to document and automate an existing workflow. Sometimes it is to simplify the process before automating it. Other times, replacement or retirement is the better choice.
The goal is to preserve useful knowledge and capability without preserving unnecessary effort. That includes moving essential information out of individual people’s heads and into documented processes, appropriate controls, and systems the organization can maintain.
An organization should not have to lose its operating knowledge when one person leaves.
Recommendations that account for reality
A useful assessment should help leadership decide what to preserve, what to change, and what to address first.
I consider the relationships between proposed changes: what must happen before something else can work, who needs to make the decision, and what the organization can realistically support. More software is not always the answer. Neither is another training session or a complete reorganization.
My aim is to provide findings and recommendations that are specific enough to act on, with the reasoning, trade-offs, and dependencies made clear.
The work should leave your team able to move forward independently, with enough clarity to determine the next steps.
Working together
I accept a limited number of project-based consulting engagements focused on operational assessments, technology reviews, and business transitions.
Each engagement begins with an agreed scope, defined deliverables, and a fixed project fee. Depending on the assignment, the work may include stakeholder interviews, document and system reviews, workflow analysis, a written assessment, and a findings discussion.
These are defined engagements, not ongoing management, routine IT support, or on-call services.
Describe the situation, the decision you need to make, and what you would like the assessment to clarify.
I do not accept consulting engagements within the aviation industry.