If you take a look at my warts you’ll notice I’ve moved around a good bit, and one of the things I’ve noticed is something that varies wildly from company to company is the empowerment of the individual.
In his description of Lean Product manufacturing, Taiichi Ohno has countless principles I love. Chief among those is Stop the Line, where teams have a big red button (real or virtual) which they can smash to stop a build when they see defects on the line.
The core concept here is that the individual can call attention to pipeline problems, and by solving these problems early and immediately, you end up saving the company a significant amount of money (as a result of reducing waste. More on that elsewhere)
The powerful, less discussed aspect, is the ability for ANY WORKER on the factory floor to push the big red button, if they believe there is a flaw in the pipeline.
The main excuse I’ve seen for not empowering employees with this is a lack of trust. Well, the unfortunate answer there is that’s a management problem, not an employee problem.
One of my favorite quotes in Paul Allen’s killer book High Output Management, is “There are only two ways a manager can impact an employee’s output: motivation and training”. If you don’t trust an employee’s decision-making skills then you have failed to sufficiently train them.
We also know that between Intrinsic and Extrinsic Motivation, Intrinsic is the stronger motivator. Let people get bought in and excited about their jobs, and do that by letting them feel like they have some ownership over those jobs.
The last might be that you have the wrong people for the job. Everyone knows the adage “Hire Slow, Fire Fast” but when it comes down to it our own pressures tend to make us do the inverse. If you know that you have a hard time firing people, then make sure you hire the right people, and once you have them: let people do the job you hired them to do.
Selective Hearing
A lot of places run Scrum (or Agile). A lot of places swear up and down by the Agile Manifesto. For some reason, there’s this one sticky wicket though that people just choose to ignore: “The best architectures, requirements, and designs emerge from self-organizing teams.”
There are a lot of articles out there about self-organizing teams, I find this one by Mike Cohn the most useful. It’s also really powerful to go back and read the original article. This autonomy is powerful and consider this: IBM used this developing it’s personal computer, is what you’re making more groundbreaking than that? If not, why aren’t you trusting your employees to self-organize more?
More and more companies are selecting Product Owners for their companies to drive individual projects to completion. Maybe working alongside your team technical managers/technical leads. Both of these roles are at-risk for being anti-patterns. Here’s a great article from a French PO (Jean-Pierre Lambert) discussing.
This is an organizational sniff test for me. An employee has a project proposal which will result in, say, a $10k return for the company with low risk. How much effort is it for the employee to have this project enacted.