Archive for the ‘Seeing Things As They Are’ Category
Is the timing right?
If there is no problem, it is too soon for a solution.
But when there is consensus on a problem, it may be too late to solve it.
If a powerful protector of the Status Quo is to retire in a year, it may be too early to start work on the most important sacrilege.
But if the sacrilege can be done under cover, it may be time to start.
It may be too soon to put a young but talented person in a leadership position if the team is also green.
But it may be the right time to pair the younger person with a seasoned leader and move them both to the team.
When the business model is highly profitable, it may be too soon to demonstrate a more profitable business model that could obsolete the existing one.
But new business models take a long time to gestate and all business models have half-lives, so it may be time to demonstrate the new one.
If there is no budget for a project, it is too soon for the project.
But the budget may never come, so it is probably time to start the project on the smallest scale.
When the new technology becomes highly profitable, it may be too soon to demonstrate the new technology that makes it obsolete.
But like with business models, all technologies have half-lives, so it may be time to demonstrate the new technology.
The timing to do new work or make a change is never perfect. But if the timing is wrong, wait. But don’t wait too long.
If the timing isn’t right, adjust the approach to soften the conflict, e.g., pair a younger leader with a seasoned leader and move them both.
And if the timing is wrong but you think the new work cannot wait, start small.
And if the timing is horrifically wrong, start smaller.
If you want to change things, do a demo.
When you demo something new, you make the technology real. No longer can they say – that’s not possible.
When you demo something new, you help people see what it is and what it isn’t. And that brings clarity.
When you demo something new, people take sides. And that says a lot about them.
When you demo something new, be prepared to demo it again. It takes time for people to internalize new concepts.
When someone asks you to repeat the demo so others can see it, it’s a sign there’s something interesting about the demo. Repeat it.
When someone calls out fault with a minor element of the demo, they also reinforce the strength of the main elements.
When you demo something new and it works perfectly, you should have demo’d it sooner.
When the demo works perfectly, you’re not trying hard enough.
When you demo something new, there is no way to predict the action items spawned by the demo. In fact, the reason to do the demo is to learn the next action items.
When you demo something new, make the demo short so the conversation can be long.
When you demo something new, shut your mouth and let the demo do the talking.
When you demo something new, keep track of the questions that arise. Those questions will inform the next demo.
When you demo something new and it’s misunderstood, congratulations. You’ve helped the audience loosen their thinking.
If you want to change people’s thinking, do a demo.
Image credit – Ralf Steinberger
Projects, Problems and People
The projects you choose define the problems you solve.
The problems you choose to solve define the novel value delivered to the customer.
The people you choose to run the projects set the character of the projects.
The choice of the projects’ character defines how the people feel about working on the projects.
How people choose to feel about working on the projects influences the character of the projects.
The people on the projects choose how the problems are solved.
How people choose to solve problems defines how well the problems are solved.
The choice around how well problems are solved sets the level of goodness delivered to the customer.
The level of goodness you choose to deliver to the customer governs the incremental revenue you create.
It doesn’t seem right that the amount of incremental revenue is a choice.
But, when you choose the right projects and the right people to run them and you choose the right problems and the right people to solve them, incremental revenue becomes your choice.
image credit — officallychaz
Some Questions to Ask Yourself
If you can’t imagine it, it’s impossible.
But if you can imagine it, at worst it can only be almost impossible.
Who controls your imagination?
What you think about something affects you like it’s true, even when it isn’t.
And what you think is true often isn’t.
Are you responsible for what you think?
If you have two things to do, that’s doable. So, do them.
And if you have twenty things to do, chose two and do them.
What if getting ten things done in a week is enough?
If the work is good, it’s likely you’re doing it with people you enjoy.
And if you work with people you enjoy, the work gets better.
Which comes first, the good work or the people you enjoy?
If you tell someone what to do and how to do it, they can do it.
But if you’re not there to tell them, they cannot.
Will you always be there?
If you show you care, people know you care.
And if you tell people you care, they’re not sure.
Why not show them so they can be sure?
If you tell the truth, people can work with you even if they don’t share your truth.
But if you sometimes tell the truth, it means sometimes you don’t.
And how does that work?
image credit — Miranda Granche
When it comes to mismatches, seeing is believing.
When there’s a disagreement between the stated strategy and the active projects, believe the active projects.
When there’s a formal objective to reduce the number of meetings and the number of meetings doesn’t decrease, the desired outcome isn’t really desired.
When there’s a desire to reduce costs and there’s no hiring freeze, there’s no real desire to reduce costs.
When it’s acknowledged that there are too many projects and more projects are added, the doers’ morale tanks while the approvers’ credibility is decimated.
When people don’t talk openly about the mismatch between words and behavior, it does not mean they’re unaware.
When there’s a mismatch between words and behavior, people see it.
The Difficulty of Goal Setting in Domains of High Uncertainty
When you work in domains of high uncertainty, creating goals for the next year is exceptionally difficult.
When you try to do something that hasn’t been done before, things may blow up instantly, things may work out after two years of hard work, or things may never work. So, how do you create the goal for that work? Do you give yourself one month to complete the work? And things haven’t worked out at the end of the month, do you stop the work or do you keep going? If it blows up instantly, but you think you know why, do you keep going? Do you extend the due date for the goal? At the start of the work, should the timeline have been set to one year instead of one month? And who decides that? And how do they decide?
When you have to create your goals for something that hasn’t been done before and the objectives of the work are defined by another team, yet that team hasn’t done the prework and cannot provide those objectives, what do you do? Do you create a goal for the other team to define the objectives? And what if you have no control over that team’s priorities and you don’t know when (or if) they’ll provide the needed information? What does a goal look like when you don’t know the objectives of the work nor do you know when (or if) you’ll get that information. Can you even create a goal for the work when you don’t know what that work is? And how do you estimate a completion date or the resource requirements (both the flavor and quantity) when you don’t know the objectives? What does that goal look like?
When you have to create your goals for a team of ten specialized people who each have unique skills, but you don’t know the objectives of the work, when that work can start, or when that work will finish, how do you cascade the team’s goals to each team members? What do their goals look like? Is the first goal to figure out the goal? How many goals does it take to fill up their year when you don’t know what the work is or how long it will take?
When working in domains of high uncertainty, the goals go like this: define the system as it is, define something you want to improve, try to improve it, and then do the next right thing. Unfortunately, that doesn’t fit well with the traditional process of setting yearly goals.
And your two questions should be: How do you decide what to improve? and How do you choose the next right thing?
Image credit — Rab Lawrence
The Mighty Capacity Model
There are natural limits to the amount of work that any one person or group can do. And once that limit is reached, saying yes to more work does not increase the amount of work that gets done. Sure, you kick the can down the road when you say yes to work that you know you can’t get done, but that’s not helpful. Expectations are set inappropriately which secures future disappointment and more importantly binds or blocks other resources. When preparatory work is done for something that was never going to happen, that prep work is pure waste. And when resources are allocated to a future project that was never going to happen, the results are misalignment, mistiming, and replanning, and opportunity cost carries the day.
But how to know if you the team has what it takes to get the work done? The answer is a capacity model. There are many types of capacity models, but they all require a list of the available resources (people, tools, machines), the list of work to be done (projects), and the amount of time (in hours, weeks, months) each project requires for each resource. The best place to start is to create a simple spreadsheet where the leftmost column lists the names of the people and the resources (e.g., labs, machines, computers, tools). Across the top row of the spreadsheet enter the names of the projects. For the first project, go down the list of people and resources, and for each person/resource required for the project, type an X in the column. Repeat the process for the remainder of the projects.
While this spreadsheet is not a formal capacity model, as it does not capture the number of hours each project requires from the resources, it’s plenty good enough to help you understand if you have a problem. If a person has only one X in their row, only one project requires their time and they can work full-time on that project for the whole year. If another person has sixteen Xs in their row, that’s a big problem. If a machine has no Xs in its row, no projects require that machine, and its capacity can be allocated to other projects across the company. And if a machine has twenty Xs in its row, that’s a big problem.
This simple spreadsheet gives a one-page, visual description of the team’s capacity. Held at arm’s length, the patterns made by the Xs tell the whole story.
To take this spreadsheet to the next level, the Xs can be replaced with numbers that represent the number of weeks each project requires from the people and resources. Sit down with each person and for each X in their row, ask them how many weeks each project will consume. For example, if they are supposed to support three projects, X1 is replaced with 15 (weeks), X2 is replaced with 5, and X3 is replaced with 5 for a total of 25 weeks (15 + 5 + 5). This means the person’s capacity is about 50% consumed (25 weeks / 50 weeks per year) by the three projects. For each resource, ask the resource owner how much time each project requires from the resource. For a machine that is needed for ten projects where each project requires twenty weeks, the machine does not have enough capacity to support the projects. The calculation says the project load requires 200 machine-weeks (10*20 = 200 weeks) and four machines (200 machine-weeks / 50 weeks per year = 4 machines) are required.
Creating a spreadsheet that lists all the projects is helpful in its own right. And you’ll probably learn that there are far more projects than anyone realizes. (Helpful hint: make sure you ask three times if all the projects are listed on the spreadsheet.) And asking people how much time is required for each project is respectful of their knowledge and skillful because they know best how long the work will take. They’ll feel good about all that. And quantifying the number of weeks (or hours) each project requires elevates the discussion from argument to analysis.
With this simple capacity model, the team can communicate clearly which projects can be supported and which cannot. And, where there’s a shortfall, the team can make a list of the additional resources that would be needed to support the full project load.
Fight the natural urge to overcomplicate the first version of the capacity model. Start with a simple project-people/resource spreadsheet and use the Xs. And use the conversations to figure out how to improve it for next time.
Defend, Extend, Transcend – A Good Way to Assess Company Priorities
Defend – Protect your success in its current state. In short, do what you did last time and do no harm.
Extend – Modify and adapt your success. In short, sell similar offerings to similar customers.
Transcend – Obsolete your best work before someone else does.
All three elements can be important to a company’s success and longevity, but it’s more important that the company’s resource allocation aligns with its priorities. But how to tell if the company’s resource allocation matches its priorities? Well, even though I was the one that asked it, I think that’s the wrong question because how a company allocates its resources DEFINES its priorities. Though we don’t usually think of it that way, I think it’s a good way to think about it. It’s a straightforward thing. If it’s a priority, allocate the resources. If it’s not a priority, don’t allocate the resources. But there’s confusion when a company declares its priorities but those words contradict how resources are allocated. Here are two rules to help navigate the confusion:
Rule 1. When there is a difference between how people spend their time and what the company says is a priority, company priorities are defined by how people spend their time.
Rule 2. When there is a difference between how the company spends its money (projects, investments, equipment, other) and what the company says is a priority, company priorities are defined by how the money is spent.
We’re all pretty clear on what the company says are the priorities, but how do you tell if the words are aligned with the actual priorities? Well, measure how the resources are allocated – measure how you spend your time.
Open your calendar and move forward in time by one month and you will see a collection of standing meetings. These are the meetings that are on the schedule and are the meetings that WILL happen. Sure, there will be other meetings that come up, but the standing meetings, the regularly recurring meetings, are a good indicator of how you’ll spend your time. For each meeting in week five, determine if the meeting is a defend, extend, or transcend meeting. If the meeting agenda defines work that protects things as they are, that’s a Defend meeting. If the meeting agenda defines work that modifies or adapts success, that’s an Extend meeting. If the agenda defines work that obsoletes what’s been successful, that is a Transend meeting. Categorize the meetings of week five and tally the hours. Then, repeat for weeks six through eight. You now have a good measure of your resource allocation and the company’s priorities.
If all the meetings are Defend meetings, the company’s priority is to defend what’s been successful. This indicates the company’s priorities have a short-term bias. If this is the case, I hope you have an unfair monopoly. If not, you might consider adding some medium-term work to adapt and extend your success. If half the meetings are Defend meetings and the other half are Extend meetings, that’s a better balance between short-term and medium-term priorities. But I hope there are no startups in your space because, without some Transcend work, one of them might soon eat your lunch. If almost half are Defend, another almost half is Extend, and some are Transcend congratulations. You have a reasonable balance of short and medium priorities and a splash of long-term priorities. I’m not sure the balance is exactly right, but it’s at least a great start.
A similar characterization/quantification can be done for how the company spends its money.
Take a look at the open job requisitions on the company website. Do those positions do work that defends, extends, or transcends? Count them. What does the data say?
Review and tally last year’s capital equipment purchases. Did they defend, extend, or transcend? Do the same for this year’s capital budget. How do you feel about all that?
Count the people who do projects to keep the production line running (defend), count the people who do new product development projects with the same DVP as last time (defend), who do new product development projects that adapt the DVP (extend) and who do technology development that builds on the DVP (extend) or decimates your best product (transcend). What does the tally say?
Review this year’s training budget. What are the relative fractions of extend, defend, and transcend? Do you feel good about that?
There is no best ratio for defend, extend, and transcend. What’s important, I think, is to be objective and clear about how the resources are allocated and to be open and honest about how all that aligns (or not) with the stated priorities. And most important of all is what you do when there’s a mismatch between resource allocation and the stated priorities.
Image credit — Tommy Wong
Are you making progress?
Just before it’s possible, it’s impossible.
An instant before you know how to do it, you don’t.
After searching for the answer for a year, you may find it in the next instant.
If you stop searching, that’s the only way to guarantee you won’t find it.
When people say it won’t work, their opinion is valid only if nothing has changed since the last time, including the people and their approach.
If you know it won’t work, change the approach, the specification, or the scope.
If you think it won’t work, that’s another way of saying “it might work “.
If you think it might work, that’s another way of saying “it might not work”.
When there’s a difference of opinion, that’s objective evidence the work is new.
If everyone sees it the same way, you’re not trying hard enough.
When you can’t predict the project’s completion date, that’s objective evidence that the work is new.
If you know when the project will be done, the novelty has been wrestled out of the project or there was none at the start.
When you don’t start with the most challenging element of the project, you cause your company to spend a lot of money on a potentially nonviable project.
Until the novel elements of a project are demonstrated, there is no real progress.
“Jumping Backwards – Cape Verde, Sal Rei” by Espen Faugstad is licensed under CC BY 2.0.
Four Things That Matter
Health matters. What did you do this year to take care of your physical health? What did you do this year to take care of your mental health? Next year what can you stop doing to make it easier to take care of your physical and mental health? Without your health, what do you have?
Family matters. What did you do this year to connect more deeply with your family? And how do you feel about that? Next year what can you change to make it easier to deepen your relationships with a couple of family members? If you’re going to forgive anyone next year, why not forgive a family member? Without family, what do you have?
Friends matter. What did you do this year to reconnect with old friends? What did you do this year to help turn a good friendship into a great one? What did you do this year to make new friends? Next year what will make it easier to reestablish old friendships, deepen the good ones, and create new ones? Without friends, what do you have?
Fun matters. What did you do this year to have fun for fun’s sake? Why is it so difficult to have fun? Next year what can you change to make it easier for you to have more fun? Without fun, what do you have?
“Friendship” by *~Dawn~* is licensed under CC BY 2.0.
Which new product development project should we do first?
X: Of the pool of candidate new product development projects, which project should we do first?
Me: Let’s do the one that makes us the most money.
X: Which project will make the most money?
Me: The one where the most customers buy the new product, pay a reasonable price, and feel good doing it.
X: And which one is that?
Me: The one that solves the most significant problem.
X: Oh, I know our company’s most significant problem. Let’s solve that one.
Me: No. Customers don’t care about our problems, they only care about their problems.
X: So, you’re saying we should solve the customers’ problem?
Me: Yes.
X: Are you sure?
Me: Yes.
X: We haven’t done that in the past. Why should we do it now?
Me: Have your previous projects generated revenue that met your expectations?
X: No, they’ve delivered less than we hoped.
Me: Well, that’s because there’s no place for hope in this game.
X: What do you mean?
Me: You can’t hope they’ll buy it. You need to know the customers’ problems and solve them.
X: Are you always like this?
Me: Only when it comes to customers and their problems.
image credit: Kyle Pearce