The real process matters
Not the policy. Not the ideal diagram. The actual path work takes when people are busy, tools are imperfect, and someone still has to make the thing happen.
I draw, make things, collect records, tinker with systems, and notice when the thing everyone is working around is probably the real problem.
My path has never been especially linear, which is probably why I am comfortable in messy situations.
I came up through support, music, making things, and figuring it out by doing it. I never treated technology as a separate lane from people. The useful part was always where the tool met the person trying to get something done.
That still shapes how I work. I am interested in the real version of a business: the spreadsheet someone trusts more than the system, the calendar workaround nobody wants to admit is load-bearing, the Slack thread that has quietly become the process.
The workaround everyone depends on.
The tool nobody trusts.
The step only one person remembers.
I started in hands-on technology support, which is a blunt education in reality.
Nobody cares about the diagram when their day is stuck. They care whether you can understand the mess quickly, find the real constraint, and make the next step usable.
That trained the part of my brain I still use most: reading the person, the process, and the system at the same time.
Later, in a growing SaaS company, I worked in the layer between product, support, IT, operations, customers, and leadership.
The layer where nobody wants the problem to live, but everyone feels it when it breaks.
I built internal tools, untangled access, automated repeated work, chased support signals, cleaned up handoffs, and kept things moving through growth, mergers, shifting teams, and customer-facing fires.
The Slack thread pretending to be an operating model.
That is the kind of problem I am good at spotting: the business is not broken, exactly. It is just carrying too much in memory, chat, heroic follow-up, and private context.
Creative does not mean decorative. It means I notice shape, rhythm, tension, and the small absurdities people quietly adapt to. I care about whether something feels coherent, not just whether it technically functions.
Technologist means I can turn that noticing into working systems. Support means I do not forget the person on the other side of the process, trying to get through the day with fewer dropped balls and less operational anxiety.
So yes, I help with operations, systems, automation, and internal tools. But underneath that, I am usually helping people make the work feel less tangled.
Not the policy. Not the ideal diagram. The actual path work takes when people are busy, tools are imperfect, and someone still has to make the thing happen.
Skipped fields, side spreadsheets, repeated Slack explanations, and careful little rituals are not noise. They are clues about what the system is failing to hold.
Automation, AI, and internal tools only help when people trust them. The point is less guessing, fewer dropped balls, and work that feels easier to carry.
We can begin with the friction you already see, then work backward into the systems, handoffs, and decisions causing it.
Start a conversation