Between the people who know what is needed and the system that delivers it.

How the work starts

Nobody has ever walked into my office with a specification. They walk in with a bottleneck, described in the language of their department, usually in the middle of a conversation about something else.

The useful part of my job happens in that conversation. A nurse manager saying the same issue keeps coming back is describing a system with no owner and no clock. Human resources saying evaluations are late is describing an approval chain that lives in convention rather than in software. Hearing the system underneath the complaint, and being confident enough about it to say so in the room, is most of the value.

What follows is a number. Before anything is built I size the problem against what a vendor would charge to solve it, because a recommendation to build without that figure is an opinion, and a recommendation with it is a business case. That is what goes to the CIO, and that is what I chair the Software Developer Committee to align the roadmap against.

Then the part everyone thinks is the job: the architecture, the schema, the audit trail, the mobile clients, the engineers I mentor through it. That part I enjoy most. It is also the part that fails hardest if the first two were done badly.