Regarding how to face problems on a project, there are three kinds of people.
Critics: those who point out where the problem is.
Problem-fixers: those who light candles.
Nothing-doers: those that ignore a problem and keep with their lives.
“You can blame people who knock things over in the dark or you can begin to light candles. You’re only at fault if you know about the problem and choose to do nothing.”
Paul Hawken
On every team I need at least one critic and one problem-fixer. The critic will uncover the problem. The fixer will… fix it.
Roles can be interchangeable. Some people is interested in backend, the other in frontend. Some people keeps an eye on performance, others on security… To have every angle covered, the more diverse the team, the better.
Beware.
A problem-fixer will become a critic if I don’t give him chances (time, resources, leverage) to fix problems.
A critic will become a nothing-doer if he sees than no problem is being fixed.
So I must assure that the team has time to fix the problems they’re uncovering. Otherwise, it’s a downwards spiral until every member of the team become a nothing-doer.
People who can play both problem-fixer and critic are priceless.
I must hire as many problem-fixers as possible and treat them well.
I should search for ways to grow the critics into problem-fixers. At least, keep them from becoming nothing-doers.
August 2019. I tried to climb a small peak in Teruel to visit some remains of the 1936-39 war. My footwear was not the best for the task, but I started climbing anyway. I climbed with ease until I look down and realized I would need to descend all the way down once I’ve made the visit.
I gave up. Chance lost.
Every time I climb a peak (or a stair) I am more nervous (afraid?) going up than going down.
Why?
Because I am thinking both on the stairs above and on the stairs behind. How high am I? Every step I take, I am a step farther from safety. Every step I take doubles the steps I need to take to return home. Every step up increases the potential damage I’ll suffer from falling.
The higher the top, the harder the fall.
When going down, I forget about the steps up there. There’s no risk of me falling up to the sky. Every step I take (down), I am one step closer to the end of the journey. Every step I take reduces the risk of being killed.
I gave up. Chance lost.
How up would I dare to climb if I could forget of the steps I’m leaving behind?
How many ideas could I test, challenges could I accomplished, just by forgetting that I could fall down?
The answer. I need to think that the step I’m taking now is just the first step of the climbing. Then climb. And repeat.
If I’m working by the hour, my main goal if fulfilling some specific ammount of work during the workday.
What would happen if I fill my goals by midday? I could try to get more work to do or I could enjoy the dolce fare niente. Anyhow, my paycheck will be the same.
Working by the hour. We do not hurry to be in the juice.
And if the person who cuts the lawn shows up with a very fast riding mower, we don’t insist on paying less because they didn’t have to work as hard.
And yet, some jobs, from law to programming, charge by the hour.
If I’m working for a salary, I’m permanently incentivised to find ways to do my work faster, cheaper or better.
Salaried people is leading. That’s finding new ways to do old things or finding how to do new things.
Hourly people is normally managed. That’s following procedure, being optimized on time or money.
This means hourly jobs are under pressure of being outsourced or automatised. And the pressure is not going to fade out any time soon even in the mid of a global pandemy.
Leaders, including leaders of one, have jobs that nobody knows how to automate. And you cannot outsource leadership.
Specific knowledge is often highly technical or creative. It cannot be outsourced or automated.
Hint:Where did all the good jobs go? A hint. They’re not coming back. In the following decades we are not going to deal with cogs and nuts anymore. Being a compliant worker is not going to be an advantage since machines can be more compliant than any of us.
The problem solver, and his will to be helpful, has set a constraint. But, most likely, it’s a constraint he has made up himself.
Constraints are useful for solving problems. When JFK set a time constraint on the problem of putting a man on the moon and bring him back (before the end of this decade, although what he really meant was “anytime soon AND not after the Russians!!”) it set in motion people and resources and also reduced the number of available solutions to the problem. Everything that allowed put people on the moon and bring them back that needed more than 9 years to create and execute was radically out of the question.
When do you need it, Mr President? Anytime soon but not after the Russians!!
So there are good constraints, that allow me to actually speed-up the project.
But if setting up a constraint does not benefit me, please, I need to avoid setting it in the first place.
Imagine this alternate dialogue.
Customer: When would you have it fixed?
Problem-solver: When do you need it for?
Customer: I think by Friday it’ll be enough.
Problem-solver: Deal!
This way you are working based on a REAL constraint, not on a made up one.
Indeed, someone is doing it better. When there are billions of interconnected people, my chances of being #1 tend to zero.
Time is ticking.
But it’s not a competition. I don’t need to do it perfect. I just need to do it. And then iterate. I don’t need to be perfect. I just need to be a better version of myself.
By the way. I could wait until I get better too. Put some more effort. Wait a bit before going public. Study more. Analyse more. Plan more. But then I am assuming a cost. The cost of not showing up.
Showing up will give me feedback. Showing up will let me learn. And by the way, showing up is the only way to, eventually, achieve success.
What’s leadership? What’s a winner? Films tells us a story that differs from real life.
The football film The Replacements tells the story of how a fallen-from-grace player finds the will to become a leader… and a winner.
Jimmy McGinty: Falco! If I had wanted Cochran to have the ball I would’ve called it that way! Shane Falco: I read blitz Jimmy McGinty: Bullshit! I put the game in your hands… you got scared. Winners always want the ball… when the game is on the line
Winners always take the ball. Sometimes they miss. Sometimes they score. It doesn’t matter because what makes you a winner is not the result but the will to face defeat.
The movies have taught us that when the music swells and the chips are down, that’s when leaders arrive and when heroes are made. It turns out, that’s not how it works. Our work is what happens in all the moments. Leadership doesn’t simply appear when the script announces it does.
Leaders always show up. In films there is a clear defining moment for being a leader. Being a leader in real life is not the end of a process, it’s a continuum.
Winners always take the ball when the match is on the line. In the infinite game of real life there is not such thing as a winner or a loser. Your goal is always keep the game going, and making it interesting.
Don’t wait for the defining moment to come. Don’t give up if you lose. Show up. Everyday. Then the rest will happen.
The important thing in the Olympic Games is not to win, but to take part; the important thing in life is not triumph, but the struggle; the essential thing is not to have conquered but to have fought well
Pierre de Coubertain
Ok, Monsieur le Baron. But how do you know you ‘have fought well’?
If you work without keeping the score, you could just be the hamster running wild on the wheel, going faster to nowhere.
Keeping the score allows you to figure out when you are not improving your play, when your struggle is not benefiting you, when you are not fighting well enough.
Worst thing the team can build is a great solution looking for a problem to solve. Does it works? Yeah! And who are we going to sell it to? … (awkward silence) … (more silence) … Eeeeerrrr.
Then, you need to work on things that provide value to customers.
Lowdermilk and Rich proposed some tools:
“How might we [fill the gaps]?: start stating a problem based on what the customer can’t do (yet) and should be able to do (once we fix the problem).
“What else?”: based on feedback from the previous question, search deeper to uncover new problems or to divide the problem into smaller ones.
Generate ideas: once the team feels comfortable understanding the problem, it can start generating ideas.
Once the team has identified problems (whether top-down or bottom-up) and generated ideas (on a “How might we?” basis), they need to sort them out.
Essentially, you organize your ideas into a 2×2 matrix, comparing the impact on customers with the effort for the team. In terms of direct impact on customers, the ideas that have a higher impact are projects that the team believes will improve customer value, satisfaction, desirability, or usefulness.
When you make a first-guess estimation, you are using your crystal ball to see the future.
Once you start working into the problem, getting deeper into it, it’s possible to find that the whole task was easier than expected. But it’s not likely.
Usual thing is, in fact, that once you start analysing, you’ll find it harder than you thought. If you inspect a drop of water under the microscope you’ll discover a lot more complexity than you found at first glance.
Besides, if you failed on the good side estimating one task that you estimated for 2 hours, you’ll save at most 2 hours. But if you failed on the bad side, this task could take you 4 hours, 4 days, 4 weeks, 4ever… The advancement is limited, but the delay could be infinite.
McConell’s representation of the Cone of Uncertainty (via Construx.com)
I never liked McConell’s representation of the Cone of Uncertainty. Since both curves (best-case and worst-case) are symmetric, the sensible difference in ACTUAL AMMOUNT OF TIME to completion is not perceived but for the trained eye.
A one-hundred-hour estimation in the initial concept could become a 25 hour (best-case x0,25) execution or a 400 hours one (worst case x4).
The ratio is symmetric (I estimated in 100 hours and it could be 4 times more or 4 times less than that). But the difference in effort is brutal.
Best case: 100 hours turned into 25 hours. You saved the company 3 weeks of work.
Worst case: 100 hours turned into 400 hours. Bang! Your one-month project is actually a four-month effort!
I usually try with this representation so Business and customers really understand that uncertainty is not a zero-sum game.
If things result better than expected, we will have a small gain. But if risks finally hit, if doubts are always solved for the “let’s do more to avoid discussing today” instead of “review the scope to keep dates, cost and quality fixed” then things are going to take A LOT MORE to be made. What a x2 vs /2 estimation means is that you can have up to 50 hours saved in your 100-hour project but you would need to pay for 100 extra hours if things delay.
That’s why worst time to do promises on how much is going to cost the project is during conceptualization stage. This is no time to promise, but to analyse, investigate and accept trade-offs to reduce uncertainty.
That’s why methodologies like Scrum delay “commitment” until requirements are frozen. And that’s why they ask for the smallest chunk of work. And that’s why they fixed deadline.
Related: The Cone of Uncertainty (Construx.com): The variability in these factors contributes variability to project estimates — an accurate estimate of a variable phenomenon must include the variability in the phenomenon itself. As these sources of variabiility are further investigated and pinned down, the variability in the project diminishes, and so the variability in the project estimatescan also diminish.
Related: A matter of time. Estimation and uncertainty: You don’t really know. It could REALLY take you ANY AMOUNT OF TIME. From literally zero minutes, if you start working remote from home, to several hours if you’ve moved to a big, crowded city or to a nice house at the outskirts.
Related: Cone of Uncertainty (Agile in a nutshell): The Cone of Uncertainty described by Steve McConnel, shows what any experienced software professional knows. Which is at the beginning of any project we don’t know exactly how long a project is going to take.
