Frequently asked questions

Complicated technical problems that need to be understood before they can be solved: unclear or conflicting requirements, systems that have become hard to reason about, migrations and integrations that carry real risk, and decisions where several options all look reasonable.

Often, yes. A lot of the work is systems that have grown organically and become more complicated than anyone intended. The first question is rarely "how do we redesign this?" - it is "which parts are actually causing the problem?"

Yes. Migrations are one of the clearest cases for understanding the problem first: the risk is almost never in copying the data, it is in what the data means, what depends on it, and which of the old system’s limitations you are about to rebuild.

Yes, and it is a good example of a decision that is expensive to reverse. The useful work is agreeing the decision criteria before comparing options, so the choice is made on evidence rather than on whichever option was demoed most recently.

Yes. Designs that never meet the people building them tend not to survive contact with real data and real users. I work with engineering teams throughout, and a design that your team cannot maintain is not a good design.

Agaya Cloud is the company I founded. It is building TrueSignal, which collects information from the systems a company already has and flags problems before they escalate. I also built Asklet, a micro SaaS for page-specific feedback surveys. Building my own products keeps my advice honest: I have to live with the decisions I make.