I like the work between the requirement and the reality.

I learned to lead without assuming authority was the same thing as influence.

Multi-unit leadership changed how I worked with people. I was no longer the person directly running every location I supported, so telling experienced managers what their own business looked like was rarely useful. The better approach was to understand how they saw the opportunity, bring experience and best practices, help them build a plan around the behaviors they could influence, and use my network to bring in support they could not access alone.

That lesson carried naturally into customer-facing technical work. Customers, Product, Engineering, implementation partners, and operations teams usually do not report to the person trying to move the problem forward. Progress depends on context, trust, good questions, and enough shared evidence for people to choose the next action themselves.

Start with what someone is trying to accomplish, then decide how technical the answer needs to be.

Sometimes the answer is an API flow, authentication issue, SQL validation, cloud configuration, or production signal. Sometimes it is a better requirement, clearer ownership, a readiness check, or a process that stops the same issue from coming back. I am comfortable moving between those layers because I have spent years working on both the customer and engineering sides of the problem.

Build around complementary strengths instead of expecting everyone to be good at everything.

I tend to notice the work people are naturally good at and the work that gives them energy. I would rather put ownership where those strengths fit, then balance the team with people whose strengths cover the remaining gaps, than spend most of the effort trying to make every person look the same.

That approach shapes how I lead, how I work with customers, and how I coordinate across teams: understand what each person can contribute, make ownership clear, and build a system where those strengths fit together.