LeadShift began with a problem I kept seeing in management advice: it tends to turn a leader into one label. Real teams do not need one fixed version of a manager. A new engineer learning an unfamiliar system, a senior engineer exploring a design, and an incident team restoring service all need different amounts of direction, autonomy, context, and challenge.
I built LeadShift to make those adjustments visible. It describes a management style with ten movable dimensions, then compares three profiles:
- Natural — the style I reach for without thinking.
- Working — the style I am choosing to use now.
- Recommended — a profile shaped by the situation and the needs of the team.
My baseline
My default profile is an enabling, high-care, high-challenge style. I prefer to give people context and ownership, make my reasoning visible, and address difficult patterns directly without making the conversation impersonal. The goal is autonomy with a clear performance bar.
That baseline is visible in a few recurring choices:
- Give an owner the outcome and constraints, then let them choose the path.
- Pair candid feedback with concrete support and a clear checkpoint.
- Turn failures into guardrails, tools, and shared standards instead of blame.
- Make tradeoffs explicit so the team can make good decisions without waiting for me.
- Increase direction temporarily when risk or urgency demands it, then give authority back.
The last point matters. During an incident I become more directive: decisions need a clear owner, changes need short feedback loops, and rollback must stay simple. In coaching, I slow down, ask more questions, and let the other person build the solution. With a senior team, I share the destination and boundaries and expect them to shape the plan.
What the laboratory explores
LeadShift turns that way of thinking into something that can be practiced. A scenario assessment estimates a natural style from decisions rather than self-description. A situation builder combines experience, confidence, trust, urgency, consequence, uncertainty, reversibility, and the need for innovation. The resulting recommendation explains which dials should move and why.
The tool also includes conversation examples, a decision journal, team-perception comparison, history, and branching simulations. These are reflection aids, not scores for evaluating employees. Personal working data stays in the current browser session, and anonymous analytics are opt-in.
The project is open source because the recommendation logic should be inspectable. A management model is more useful when people can challenge its assumptions, adapt it, and discuss the tradeoffs it makes.