A few principles I care about when software supports people across many offices, processes, and day-to-day decisions.
A lot of internal software lives in an awkward space: it is critical to the people who use it, but it rarely gets the same external attention as customer-facing products.
That makes product discipline even more important.
In my current work, I think a lot about what happens when one system has to support staff across many offices with different contexts, expectations, and operational habits.
When internal software is shared broadly, I try to focus on three things first.
Users should understand where information lives, what actions are available, and what state the system is in.
Internal systems often fail because they accumulate exceptions and hidden knowledge. Good UI does not solve every process problem, but it can reduce confusion dramatically.
When many teams use the same tool, consistency becomes a form of trust.
Patterns should repeat. Labels should stay stable. Similar tasks should behave similarly. That consistency makes training easier and reduces the cost of switching between workflows.
Internal tools are not only built in code. They are also built through reviews, planning, estimation, and communication.
If a team does not share the same expectations about quality, scope, and delivery, the product will eventually reflect that confusion.
Internal systems are practical. They reveal whether a team can build software that helps real people do real work with less friction.
That is a challenge I keep finding interesting.