Leadership — MOI

· tech

#leadership

📑 Contents

Models of leading

A model of leading is a handful of dimensions used to describe an environment. The MOI model is one of them.

MOI

The MOI model has three dimensions: Motivation, Organization, Innovation. Each one is a way the leader shapes the environment.

Leader M · Motivationpeople want to move O · Organizationorderly, predictable I · Innovationsafe to differ the three together = the environment the leader shapes
MOI: a leader doesn't control people directly — they pull these three levers to shape the environment: willing to move, orderly, unafraid to say something different
1. Motivation — motivating behaviour, which includes both reward and punishment. Common forms: - Clear recognition and reward - Opportunities to grow - Transparent consequences and scope of responsibility Put simply: make people want to move, and let them see that effort has both a direction and a payoff.
  1. Organization — letting people work efficiently and in order. Usually:
  • Setting rules
  • Designing process
  • Allocating resources
  • Defining roles Good organization isn’t more constraint; it’s making things predictable, standardised, and clear about how people work together.
  1. Innovation — an environment that feeds imagination, encourages experiments, and tolerates different points of view. A team with innovation in it usually looks like this:
  • People enjoy discussing
  • Everyone can put an idea forward
  • The loudest voice doesn’t win; the best idea does
  • People dare to try, and failure is allowed Innovation isn’t “the genius shines”. It’s “the environment lets you say the thing you just thought of”.

How a tech leader solves problems

A good tech leader keeps three core tasks in balance:

  1. Problem understanding
  2. Management thinking
  3. Quality assurance

What each one looks like in practice:

  1. Problem understanding — a technical leader’s first job isn’t writing code, it’s making sure the team genuinely understands what the problem is. Common methods:
  • Read the spec carefully: don’t assume, don’t imagine; the document and the requirement are the ground truth.
  • Get the members to read the spec too: fewer errors from second-hand retelling.
  • When people disagree, go back to the original problem: it keeps the argument from drifting off the core.
  • Re-read the requirement after making progress: your understanding has deepened, and a second reading usually surfaces detail you missed.
  • Verify in reverse: ask yourself “if the requirement can’t be met this way, what would the reason be?”
  • Break the problem down: turn a vague requirement into specific sub-problems. Understanding the problem isn’t done once. It’s something you repeat through the whole project.
  1. Management thinking — a tech leader isn’t a PM, but has to think from a management angle. That includes:
  • Contribute sensible ideas
  • Encourage borrowing ideas that work
  • Improve on the ideas other people bring
  • Listen patiently while a member explains their thinking
  • When criticising an idea, be specific — about the idea, not the person
  • Try it yourself before offering it as an idea
  • When time and people are short, stop hunting for new ideas
  • Set priorities: not everything matters equally
  • Allocate work sensibly: the right person in the right place
  • Keep the team’s information in sync: fewer misunderstandings, less rework
  • Help members break tasks down and confirm they’re feasible
  • Keep a transparent record of decisions (why this decision, what the context was)
  • Shield the team from outside interruption (communicate the bottleneck clearly, block unnecessary queue-jumping)
  • The essence of management thinking is: let the team stay focused on producing.
  1. Quality assurance — a tech leader has to make sure what ships meets the standard the team and the product need. That includes:
  • Measure quality while the project is running
  • Think about how quality will be monitored as early as the survey stage
  • Track the pace of implementation and stay able to switch approach at any point
  • Look at the project from the outside; change your vantage point and refresh your view
  • Verify together with the customer
  • If the project went the wrong way, find a way to rebuild morale
  • Set up a code review process
  • Define coding style, architectural principles, API conventions
  • Help put automated tests and CI/CD in place
  • Help investigate problems and chase the root cause
  • Make a healthy trade-off between quality and speed Quality isn’t patched on at the end. It’s prevented, starting from architecture, process and habit.

Reflection

  • My team is in the middle of turning a POC into a product, so everyone is heads-down on implementation. I haven’t built any real motivation — at least there’s organization for the project to follow. More discussion inside the team would probably lift innovation, and rather than telling everyone “anyone can share something technical”, I should just go first and share one myself.
  • I don’t have good MOI in my own life either: I reward myself for nothing, and do whatever I feel like. Maybe some rules would help — a reward only after something hard is done. Finish today’s running session and I can eat whatever I want; skip it and it’s the healthy meal.
  • I’ve already tried one approach — prefetching while avoiding str scattered everywhere. I’ll write it up and share it with the team.