If you talk to someone who complains that their company is out of control, the reason is not always obvious. Once you pin them down about the reasons for their problems, you’ll find that they aren’t managing. We rarely think we’re doing enough managing to deal with these issues. If pressed about whether we’re managing the cause of these problems, we’ll own up to it. We often know the problem and the solution. Despite this, we aren’t putting the effort into managing the root of the problem.
Managing is work
Don’t get me wrong. Managing people is not easy. It can consume a ton of time. Yet we all know the repercussions if we don’t manage. We do know those things, right?
So why don’t we do more of it? It’s not that we don’t care.
Even profitable, “well run” small companies doing $10-15MM ARR suffer from a lack of managing. While it’s obvious, we have a way of being terrible at dealing with the obvious.
A few questions to inform whether you’re managing:
Cash flow – Do you have a resource that tells you at a glance your cash needs are under control for the next 30-60-90 days? If not, you’re not managing cash flow.
Projects – To find out the status of all active projects, can you look at a single resource? Doesn’t matter if it’s a whiteboard, software, clipboards, or a spreadsheet. Or do you have to ask each lead for the project? Can you see which aspects of a project are on schedule and which are behind? Or do you have to ask each lead? Are you aware of the risks of each project and how the leads are mitigating them? For that matter, are the leads aware of them?
Hiring – Do you have a hiring process? How many hires do you make that you’re happy about after six months? What percentage don’t work out? How many start their own company after leaving you? What percentage of your non-leaders take leadership roles after leaving you?
Training – What routines are in place for new employee training? Is there a way for you to review every staffer’s training progress? What about the progress of senior staff?
Service – Can you review your customers’ happiness with your service? Without someone complaining, can you identify service opportunities that didn’t go well? Without asking someone, can you review the outcome of a sample of service calls over the last 30 days?
Sales – Which salesperson produces the least (or most) refunds? Why? Whose sales are the most profitable? Which one produces the longest-lasting customers? Who makes the most calls? Who makes the most of their calls? Is it the same person?
Marketing – Which ad medium has the best ROI for you? Which ad source produces the most profitable customers? Does customer lifetime value vary from ad source to ad source? Which ad source produces “bad” customers?
Managing – Without asking, can you tell how your managers’ teams projects are going? How are their people are doing? If you can’t do these things, neither can your managers.
What managing isn’t
Why are we bad at managing? For some of us, it’s because we learned managing from the wrong kind of manager. Some of us learned it by the seat of our pants. There’s nothing wrong with either method, unless you’re learning the wrong way.
One of the wrong ways is thinking that yelling at your team is managing. Do you or your team only think you’re managing when you’re angry? As an old friend used to say, “You’re doing it wrong.”
Micromanagement is a good example. It is not managing. While micromanaging is good for two year olds, it’s ineffective for employees. It’s not good for you or your company.
It’s not uncommon to see micromanagement at companies with management problems. Instead of managing they’re micromanaging.
You might be micromanaging if you’re:
Tracking time, not to track progress, but from a “butts in seats” perspective.
Not tracking time now and then to find out “how long a process takes so we know what our costs are” perspective.
I bring up micromanaging because it’s a good example of what managing isn’t. The worst part is that we micromanage and think we’ve been managing. Problem is, we still haven’t managed our team or the problem we want to solve.
There’s a quote in the story about Moderna’s technology that identified the key to going after the virus (the spike protein, apparently) within two days of receiving the genetic sequence of the virus, which follows:
That’s from January. The comments about this process reminded me so much of custom work. Specifically, of showing a customer the mockup of an application or website that maybe took a day or so to develop. Mockups don’t take long because they don’t do much. They’re just a visual example that proposes a look for the real software / webpage. The idea is to get feedback from your customer *before* doing a ton of work.
Mockups are everywhere
It’s not terribly different from the 3D mock ups that you can create if you remodel or build homes. There’s architectural design software that’s simply amazing in that respect. The realism is impressive. I remember seeing it a few years ago. You could design a house in 3D including landscaping. Once done, you could visually “walk” through the design and get a feel how it would look – all in very realistic 3D. While impressive, it was still nothing more than a mockup. Like mockups in other industries, it looked real, but it didn’t do anything.
The parallel isn’t exactly like Moderna situation but it’s similar. Here’s how: once you identify what you have to build – in detail – and you get agreement on it, the hard part is done.
I don’t mean that building whatever you mocked up doesn’t require a lot of work, technology, raw materials, time, communication, know-how, etc. It does. Even so, the work to figure out what you needed to build in the first place, can be most difficult. Getting consensus on an on-budget design that everyone agrees on – and it’s actually what’s needed – can be rather difficult.
Many times a project is doomed from the outset because there wasn’t enough communication to describe what was wanted and why, what the possible solutions look like, and what solution makes the most sense for the situation. What ends up getting built is what we thought someone wanted, only to find out both sides made too many assumptions and failed to ask enough questions. Mockups are great for reducing these problems.
New school design
What Moderna did in two days is flat out amazing, particularly when you compare it to how it was done in the past. Old school methods of building vaccines were in some cases done by getting people sick and studying the reactions in the sick peoples’ bodies. From those reactions, scientists, doctors, chemists and others eventually came up with a vaccine. Today, much of that work happens in a computer. That’s an oversimplification medically, biochemically, and probably in other ways – but you get the idea.
Some of you may remember the SETI project from years ago. After you installed their software, it would download and process a small amount of the radio telescope data collected by the Arecibo observatory – yes, the one in Puerto Rico that suffered damage resulting in it being permanently taken offline. SETI’s software would process the data and send it back to the SETI system, which would use whatever processing your computer had done to figure out if that data was valuable.
Early this year, I stumbled across similar project for medical study called Folding@Home. Folding@Home is working on protein folding analysis for COVID and other diseases. I read somewhere that some of the data processed by this project helped produce some portion of the vaccine solution – but I don’t know the details. This happened thanks to a large number of people all over the globe letting their computer do these computations and analysis in the background. As a group, these computers served someone as an equivalent to a medical supercomputer. That’s important to this work because supercomputers are rare, in demand, and really expensive.
Before I digress further, let’s explore how expectation gaps appear.
So if Moderna’s software figured out the spike protein after two days of work in January 2020, you might be thinking “Gee, it’s November, why don’t we have a vaccine yet?”
It’s a reasonable question and it brings the discussion back to our mockup discussion.
By identifying the shape that a vaccine has to match, they’ve done a very important piece of work. It’s a mockup of part of the work of producing a vaccine (yes, a sizable oversimplification).
Once you have a vaccine, it has to be tested, including time-consuming human trials. That process is often where the work doesn’t pass muster. Once it’s been tested, accepted by the FDA, and probably other work I haven’t mentioned, then you have to manufacture millions of doses. That requires sourcing raw materials – some of which may be expensive, time-consuming to make, etc.
You have to figure out the logistics of delivering it and administering it to millions. That takes money, people, logistics, systems, and time, but that’s not the point.
Communication is essential
What fascinated me about it was the gap in expectations between the reality of the work and what we (the general public) expect.
Anyone who has done custom work learns very early on that if you don’t manage the expectations gap, you’re in trouble. I suppose it’s a good thing that Moderna’s successful protein work didn’t make it into the news in early January since they didn’t yet have a vaccine. They simply had the protein match. Some who knew of this success had expectations for a quick solution, not realizing that the process had just begun – thus creating an expectations gap.
Despite the fact that the typical multiple year process of figuring out what to build had been reduced to two days thanks to years of effort, testing, and trials on other diseases, plenty of work remained.
First US Polio case: 1894. Polio vaccine approved: 1960.
They felt they’d have a vaccine in 18 months vs. four years, the recent best case for vaccine development. A reminder: It took 76 years to get a polio vaccine. Science has improved and our expectations have kept pace.
That’s the lesson those who do custom work must learn from this. We have to be careful to manage expectations because it’s so easy for the customer to see very early on what looks like a finished product but isn’t – because we want to get feedback from them.
Whether it’s a house design, software, a website, or whatever – there’s a lot of work required to get from that mockup, to something that only works on the programmer’s machine and nowhere else (aka “WOMM” – works on my machine), to a point where it works on every computer, browser, mobile device or whatever.
This gap is “significant”, kind of like the gap that can be created when a home builder gets the foundation poured, framing done and the roof on. All of a sudden it looks like a house. Get windows and the front door on and it starts to look like a real house – but it’s only been a couple of months. Why does the rest take so long? If your expectations aren’t set properly, conflict is coming.
Avoiding the expectations gap
Why? Because the first 80% looks like everything and the second 80% is hard to see from the curb. A house may not be wired, plumbed, sheet rocked, painted, etc. The builder may be waiting on various tags / permits. It may lack cabinets, appliances, flooring, fixtures, etc. It may not be cleaned up or landscaped.
Some of these things are hard to see from the street, where it doesn’t look much different from the day the roof was finished. It’s similar to me showing you an app on my machine, where it works in the environment I work in every day – where it’s easy to make it work.
It’s critical when doing custom work to make sure that you explain what people are seeing and what’s left. Part of doing that (and not catching a lot of grief) involves your expertise in knowing what it takes to get from point A to point B because until you know the expectation gap may also be in your head. This gap is a good way to assess the expertise of someone that you’re planning to hire.
The house in the hills
Back in the 90s, we built a custom home – architect and all. When we interviewed the builder, who came with good references, he set expectations for us from the outset. He said “All the references had projects that went pretty well. But I should tell you, every 10 or 20 projects we have one that seems to the homeowner like a complete disaster. It will feel like everything that can go wrong, does go wrong. It turns out fine in the end. Most times we can control those things, but sometimes we can’t. Between the weather, people, suppliers, subcontractors, and everyone else that’s involved – there’s a lot of moving parts and opportunity for things to go wrong. What you need to know is that I will take care of these things if that happens.”
At the time, I appreciated the warning, but didn’t think much about it. We never think the gap is going to get us.
Unfortunately, that’s what happened. We had maybe eight or ten things go wrong that seemed like a disaster at the time. Halfway through framing, the builder said “The way the architect designed this staircase… it didn’t go anywhere. The only way to build it so you could walk upstairs was to make some adjustments.” He simply took care of it.
A concrete truck got stuck in the backyard, slid down the slope of our lot and jammed itself against a tree on the neighbor’s lot (which fortunately didn’t have a house on it yet). They had to call another concrete truck to pull first one out. Meanwhile, the concrete was getting hotter and hotter, meaning it was going difficult to spread once it was poured.
Filling the expectations gap
That night I stop by the house after work and find guys in the dark working hard trying to spread the concrete before it sets. I can tell by how hard they’re working that it’s already decided to set and they’re doing their best to make it work. They ended up having to pour another small layer to smooth everything out. Other things happened, but it didn’t matter because a) he set the expectation and b) he took care of it. While the problems were annoying, the builder did what he said he’d do. He filled the expectations gap.
Years later I ran into a real estate agent who had a similar expectation gap filler. She had a checklist for the refrigerator when she listed your house. She said “Here’s a list of things that may go wrong between now and the time your home sale closes. Some are normal, some are crazy. If they happen, I will let you know and I will take care of it.”
She set the expectation and filled the gap appropriately. That’s really all customers want. When they hire you to do a custom job, they want it taken care of. Whether the work is selling your house, building software, or a tax return, customers simply want a professional to finish the job and handle whatever problems arise.
The good news is that this is a fairly easy situation to improve. You already know all the things that can go wrong. You’ve dealt with 99% of them. Why not document them? Present them to your customers in a way that turns them into a way to show you’ve got experience and expertise on your side. Make sure they know what your response will be.
Don’t fear putting them in writing – not so much as a guarantee, but as a “We’ve got your back.” Remember, they’re coming to you for a result, not for the mess between point a and point b.
You might be worried that your competitors will copy what you do in this area. The rare one might, but most won’t. It’s surprising how many things you can do for your customers right out in the open where your competitors can see them – and they’ll simply watch. Some will attempt them and find them too much work. Don’t worry about your competitors. Worry about your customers.
So… how are you filling the expectations gap for your customers? How can you bridge that gap and give your customers more confidence that they’ll be well cared for?
We’ve been mulling change, prioritization, and getting important tasks done. It’s time to get serious before the holidays distract you. When they’re over, having a ready-to-start game plan will help you get a solid start on the new year. Question is, what should be on your game plan?
We’ve all probably heard the story about putting the big rocks in the jar before adding pebbles, sand, & water.
The story resonates because we remember a time when we left the big rocks till later & then disappointed someone by missing a deadline, or being unable to fulfill a commitment.
These disappointments, failures or what have you often happen at least in part because we didn’t deal with the big rocks first. Old news for Covey followers, but worth a reminder when making a game plan.
A game plan of three things
I suggest starting with three big tasks. Looking at the list of tasks you want to accomplish in the next year, which three should have the most impactful and positive strategic result to your company over the long term?
Think about it. Discuss it with your team. Decide.
Consider the possible causes of failure. Some call this a “pre-mortem”. Make sure your game plan includes steps to defuse these issues or prevent them from becoming a problem. Think about the essential accomplishments needed to complete these tasks. Make sure everyone knows what these points are & that someone has direct responsibility to monitor them.
Painting the building may not be one of your three things, but it could be. I can recall on more than one occasion seeing a restaurant whose building had clearly been ignored for many years – and wondering if they handle food safety with the same level of care.
Up next – figure out how long these tasks will take. You need to know if your game plan is reasonable. This is not the place for fantasy.
People are terrible at estimating how long a task will take. Eventually, some figure out a system for accurately estimating how long work will take because they got burned, fired, etc). This is particularly true in the technology business, but we aren’t alone.
Why is that?
We’re too optimistic about the pace we can maintain. We rarely bother to consider that we may run into an issue that we’ve not dealt with before – and the research, work (plus rework) & testing to resolve it takes time. These episodes don’t typically happen just once in a big project – which we also don’t consider.
We often discount the possibility of interruptions for urgent tasks that, while not of high importance, still must take precedence for a few hours or day. Naturally, we forget how many times this has happened based on our history, industry, team, etc.
Some folks estimate something, then “double it and add four”. Maybe that builds enough buffer into the estimate, but it’s still a wild guess with little more than gut feel to back it up. “Double/triple it” is a pretty good indication that you put insufficient thought into your estimate.
In some environments, you’ll find people will give an “instant” estimate to stop the “How long?” questioning. “You need to do this, how long will it take?” doesn’t usually have a legitimate answer when the task was unknown to you five minutes earlier. Saying “two weeks” without further introspection is simply avoiding persecution… temporarily.
It takes thought to produce a reasonably accurate estimate. This isn’t about making estimates correct to three decimal places. It’s about being reasonably close.
If you promise completion on January 15, you need to have confidence in that date from day one. If you know from the start that you’ll never make the date, don’t know if you can make it, or can only make it if everything goes perfectly – you’re asking for trouble.
Big tasks should be broken down into pieces before you can estimate them. Starting from task completion & working backward helps us remember steps we might otherwise forget.
Estimate your list of steps. Break down steps estimated over four hours & estimate the new steps. Four hours seems extreme, but it’s a timeframe we can wrap our heads around. In your line of work, maybe it’s four days. You know where your estimation accuracy really shines.
Make a game plan. Work your plan. Get big things accomplished.
How much of what your company does absolutely MUST be done by you? How many hours a week do you spend doing those things? What if you could do 10-20 more hours of that per month. After a few months, what if you refined that new ability three or four times? Think hard about that. At that point, you would be able to spend 10-20 hours more per week on the things you and only you must do. How would that change your business? For that matter, how would it change your life? I learned this magic from a mentor who is pretty demanding about getting people to work on the things they’re best at – and nothing else. While not everyone can do that much delegating right off the bat, this process still leaves plenty of opportunity to gain valuable time to do the work no one else can do.
Choose someone else
Perfecting the art of delegation (or at least refining it) is something that takes time. Identifying everything you do that can be done by others… doesn’t. If that seems tough, just identify the few things you do that no one, absolutely no one, can do for you. Now it’s easy: delegate everything else.
Yep, that simple. Start with the easy stuff.
Say you want to send flowers to your mom for her birthday. You can call the florist in the town where she lives and work it out with them. Maybe you prefer to call 1-800 whatever, or a local florist and ask them to make it happen. Or you can do none of that – and delegate the task to someone with as much or little detail as you like. Your mom doesn’t care that you didn’t make the phone call. She’s happy you remembered her and thought enough to send flowers.
You might be thinking “that was only 10 minutes on the phone”. Or 15. Or 20. Plus following up, if needed. Whatever. The time for this one task isn’t all that relevant. Look at the big picture and add them up. The point isn’t how much this one task takes. It’s about how many tasks like this are consuming your time each month.
Turn it up, by turning it around
Once you start getting into the groove of delegating, it’ll get easier over time. Thing is, there’s a way to completely rethink the process and realign how you look at new projects. When a new task or project pops up, think first about who else (ie: not you) can do the work – unless the work is on that (probably) short list of things that only you can do. Who else can manage it? Plan it? Track it? Lots of people, right? Let someone else do those things. They’re important, but that doesn’t mean someone else can’t do them. You focus on the portion of the project that’s work for you – and nothing else.
Multiplying the impact
Want to take this a bit further and multiply the impact? Start teaching it to your managers and skilled team members who get distracted / side-tracked by work that someone else could do.
You might be wondering “If everyone is delegating this work, won’t that require more people?” Yes, it might.
Thing is, if your managers and highly-skilled team members are doing enough of this work that it requires one or more people to complete it, that’s a problem. It means that your managers aren’t spending all of their time managing (hard to imagine, right?) Instead, they’re doing work that someone else can do. It also means your highly-skilled team members are spending an inordinate amount of time on things that other team members can do.
For managers, the problem is that when people, projects, relationships, and product delivery isn’t managed well, the entire company is affected. In the case of highly-skilled team members, we’re talking about high value, high cost, high return on investment work. Any time your highly-skilled team members are spending time on other tasks, they’re getting more expensive by the minute. Worse yet, they become more expensive when they spend time on random tasks that have nothing to do with their skill. Removing any non-core task from these folks increases their value and allows them to contribute more to the company’s bottom line. In some cases, this newly found time opens up sales opportunities because these folks can produce more of the thing you hired them to do.
As the end of the year approaches, it’s a natural time to look back over the past year’s work. Did you make progress? Was the year a success? The source of our motivation has a big impact on how we perceive the year’s work. Did I achieve a financial milestone? Will I get the leadership position I want? Did we reach our sales goals? These are external motivations. Internal motivations may also drive us – such as a need to learn, achieve, better yourself, make fewer mistakes, etc. Neither driving force is the wrong one. Personally, I think a mix of the two serves us well. As we walk the trail through our careers and personal lives, the source and makeup of what motivates us often changes. About 10 years ago, a mentor‘s comment completely changed how I relate to the things I achieve.
The gap on the way to ideal
When we look at our goals or ToDo list, 100% “perfect” completion of every single one on time and on budget is the ideal “destination”. While there’s nothing wrong with that, it’s rarely realistic. It’s also rarely necessary – at least on the first completion.
“First completion“? Yes, exactly. Few of us knock off a project and find that it’s perfect and never needs another polish, tweak, or modification. Even if the only customer is you, it’s better to complete the job, gather feedback and make another pass to improve your work.
The trouble with 100% completion is we rarely, if ever, achieve it. If 100% completion of your goals is consistently achieved on time and on budget, it often means the goals were watered down. We might extend a timeline, ignore some portion of the budget or loosen quality standards. Doesn’t matter which one.
Looking back at the Apollo project, NASA was charged with getting men safely to the moon and back by the end of the decade. I remember watching the first steps broadcast on a grainy black and white TV at my grandparents’ farm. That was a late night for a young kid in 1969. Yet Apollo wasn’t 100%. An Apollo I launch rehearsal cost the lives of three astronauts. Apollo 13 almost did the same while traveling between Earth and the Moon. NASA achieved the audacious goal Kennedy laid before them, despite not achieving perfect execution.
The gap between perfect execution and your actual execution is quite often significant. Having the right perspective is critical.
Perspective and the gap
When we look at the ideal outcome, we’re almost certain to come away disappointed. We expect perfection. You won’t be happy or satisfied with your efforts when you assess where you are against where you expected to be when everything went perfectly. That space will be filled with regrets about incomplete tasks, tasks that weren’t started, things that didn’t go as planned, etc.
The comment from my mentor paraphrases like this: If you look forward to the difference between what you did and the ideal outcome, there will always be a gap. That gap will always bother you – and it destroys the ambition in some. However, if you look back from where you are to where you started, you’ll find great satisfaction and motivation to charge forward when seeing how far you’ve progressed.
This change in perspective completely changed how I felt about the incomplete / untouched items taunting me from their comfortable home on my Trello board. Strive for 100%. Celebrate your progress, however imperfect. Use your progress as motivation. Keep improving.
When a team’s original goal appears to be within reach, managers often trot out “stretch goals”. Is this done to create a failure that can be held over a team? Stretch goals usually create morale failure from significant progress. Motivation is rarely the outcome. Managers should focus on the 90% your team achieved, rather than the 10% that didn’t get done. It seems natural to do this when you’re a software guy – since we often focus on what’s broken. As a leader, it seems like a great way to repeatedly chip away at the morale of your team by never letting them celebrate or acknowledge accomplishments. The time to focus on the 10% will come soon enough.
A couple of months ago, I was driving to Banff to meet some friends in a rig we call the Scoutmobile. About an hour into the drive, the engine’s temperature started heading into risky territory. I was in an area where there was very little room to pull over, so I started looking for a safe, roomy place to get off the road. In management-speak, this would be a stretch goal.
While searching for a place to stop, I used common engine overheating delay tactics: turn on the heat, slow down, etc. I had a simmering suspicion that a blown head gasket was coming home to roost. This rig had close to 300K miles on it, so this wasn’t an outlandish possibility. As this suspicion moved toward reality, it was obvious that simple overheating delay tactics wouldn’t help for long. I needed to stop.
Stretch goals and context
Getting to a safe, roomy stopping place became a new and much smaller stretch goal because the context changed. Frankly, making the 400 mile drive to Banff and getting back without mechanical trouble was really the stretch goal. Given the rig’s mileage and concern about the head gasket, I had wondered for months if it would survive the trip.
Once the engine temperature started rising, my decision making context changed. Meeting friends in Banff was off the table. Finding an ideal place to pull over became the stretch goal. Getting off the road was possible, but not quickly. Leaving the road in a nice wide spot so I wouldn’t cause traffic issues became the stretch goal.
As I finally rolled into a safe spot out of traffic, the engine lost the little remaining power it had and locked up. The first time it stranded me in 17 years turned out to be our last drive together. While I made the stretch goal even in the altered context, even that seemingly tiny stretch goal was too much for the situation. That’s the lesson here – attention to changing context is critical.
Stretch goals aren’t the problem
I don’t mean to say that stretch goals are bad. They aren’t, but context is critical. When my trip’s decision making context changed, so did my goals for the day. Looking back, it’s possible that stopping immediately would have prevented the locked up motor. I didn’t want to partially block a lane on a two lane highway. That as my justification to push a little bit further – a stretch goal.
When you decide on stretch goals, be sure you aren’t going to drive your team too long at “redline”. Redline (in automotive terms) is the maximum speed at which an engine and its components are designed to operate without causing damage to the engine.
Making your monthly sales goal in three weeks is a classic time to give your team a stretch goal for the month. Adding requirements to the final days of a project that’s already behind will all but guarantee late delivery. Likewise, shrinking a timeline they’re already likely to miss is a good way to sour a hard-fought win.
Race drivers will repeatedly push a race car’s engine to or a bit beyond redline because that’s when they get the most from their engine. Thing is, they won’t do it for long. Pretty soon, they’ll shift or brake. They know redline is there for a reason and pushing the engine beyond normal operating limits for too long will end badly.
Running at redline
Prolonged running at redline has similar effects on people. Someone can work a couple of 80 to 100 hour weeks under near-term deadline conditions and some will do so willingly if they believe in the goal.
Where this goes bad is when it becomes “normal” to work like this. Do this and some (probably all) aspects of their lives will suffer. They’ll not have (or make) time for family, or taking care of themselves. Eating and exercise habits will suffer. They’ll have less (or no) time for friends, the dog, yard, car, hobbies, etc. Rest will suffer, so their ability to focus, concentrate and show patience will be affected. Burning bridges at home combined with a drop in work quality / output can permanently create morale / attitude problems.
Sometimes limits really are limits. Exceed them too often for too long and you’ll damage engines, people, relationships and before long, your company.
How many projects does your company focus on at a time? For many companies, the number of active projects is often related to team size. How do you control, or at least manage this? What does that process look like? Do you use a tool, software, a manager, or something else?
The benefits of keeping control
What happens if you keep projects under control? While control is relative and may seem to consist of things not moving as fast as you’d like, it’s still critical.
“Control” does not demand a state where that things that look static, never changing, not growing, etc. Instead, we’re likely to see active projects where the mental headroom is available to thoughtfully consider the next step, much less the current one.
When that kind of space is available to teams working on a critical project, they tend to make fewer mistakes and overlook fewer things. These same things will be painfully obvious in hindsight.
A mind allowed some breathing room is less likely to work in a semi-constant distracted state where they’ll make mistakes, get injured, and / or overlook what will later seem obvious.
While it’s happening, it’s difficult to measure the cost of task switching and frenetic activity that comes having too many projects and too few hours / people to tend to them. What I tend to see from this is “doing 100 jobs poorly”. While your team might not be doing 100 jobs, they might be trying to do so many things that they don’t do any of them well. This damages your satisfaction with the quality of their work as well as theirs. These situations cause your team to do things a second time because they didn’t have time to do them right the first time.
Some iteration is a good thing, as our ability to provide a contextually accurate solution increases as our initial plan gets tested against reality. However, when the first iteration is almost always an attempt to check a box, the box really doesn’t get checked. That first iteration tends to be a solution that doesn’t satisfy your team or the client (internal or otherwise). Once you’ve trained your client not to bother implementing 1.0 of anything you create, it’s a tough place to battle back from.
We discussed the loss of trust a week or so ago. This is another type of trust – can your clients trust your new products, new services, new releases of software, new salespeople, new service writers, new mechanics, etc? When your project management and controls create a level of comfort for any or all of those new things / people / projects in your business, it creates a higher level of trust with everyone you work with.
How would your team benefit if they trusted each other more than they do now? How would your business, clients and partners benefit if your clients trusted practically anything or anyone new that you exposed them to? Same question – if your partners trusted practically anything or anyone new that your company exposed them to?
It’s not just a matter of quality and consistency. It’s a matter of what those things create. When you pay bills on time, people assume you’ll keep on doing that. When you don’t, it’ll take a while before paying them on time allows them to trust you.
What happens if you lose control?
While control is a bit of an illusion, seemingly out of control, frenetic behavior is fairly easy to see. If you aren’t careful, you’ll start seeing activity just so people can show that they’re doing something. Look at what’s being accomplished.
Inefficient activity often results from these situations. Have you ever gone to the grocery store without a list and found yourself bouncing all over the store as you think of the things you need? I remember as a kid that my mom grouped her grocery list by department, i.e.: produce, dairy, etc. While I’m not sure it sunk in while I was a kid, the benefits of that little effort on “elapsed time in grocery store” became obvious later in life.
Imagine a plane that gets to 80 knots on the runway and then decides to stop, change runways and take off again. It wastes a lot of energy starting and stopping, while getting little accomplished in the way of actual travel. Think of your projects in the same manner. Avoid changing runways.
A new project idea is always exciting. You think you have a great idea that’s going to take off in your market like gangbusters and you can’t wait to get started. In fact, the gravitational pull of this new bright, shiny object might be so compelling, you might discard all encounters with reality and start without doing any sort of market research, perhaps even setting aside real paid work that has stacked up.
As you might expect, I have another suggestion: use a concept called the minimum viable product (MVP), which is part of process called “Lean Startup“. While this originated in the software world, the process of developing a MVP can be used in ANY business.
Let’s talk about what usually happens to a new project idea.
New project idea development
While the minimum viable product concept took root in the software business, it can be used ANYWHERE.
Let’s take a brief look at the old way. I’ll discuss it in the context of the development of a software project, but this can happen during the development of any new project idea in any business.
The Lean Startup world relates primarily to software startups. Lean Startup recognizes the history of software project development over the decades and that it’s had a high failure rate. This failure rate quite often happened because software development often looks like this:
Software people get an idea
They determine what they believe to be the perfect solution and fall madly in love with it.
They run into a room for two years (or longer) to develop it, and work incredibly hard to produce this perfect solution to fit their idea or problem they’ve identified.
After years, they emerge, sweaty and victorious, having completed some portion of this perfect solution
These developers might emerge from their self-imposed development exile having become chest-bumpingly-giddy about their victory, only to find that they built something in a vacuum of customer feedback and the customer finds the solution misses the mark – often by a wide margin. Either it solves a problem the customers don’t care about, or it addresses a problem in a way that makes little sense to the customer, or the customer thinks it’s workable, if only the software people can make these 247 changes to how it works.
Making those 247 changes might take longer than the initial development, might cost more than the initial development, may not have management support, and idea doesn’t do much for a team of software people who became quite misty-eyed over the baby they worked on for the last few years.
Minimum viable product does away with running into a room for two years, and with creating what has universally become recognized as a danger to new and existing businesses: a vacuum of customer feedback.
Test, gather feedback, repeat
The Minimum Viable Product process is a rather efficient, mostly emotionless process for getting to the root of the problem and to the solution that best fits the customer. It looks something like this:
Talk to clients.
Build what you think they want – but build the smallest possible solution that emerged from the conversation about the problem or idea.
Place it in the client’s hands as soon as possible. If you can make this happen in two weeks or less, do so.
Watch them use it, ask them how they feel about it, ask them what they like, don’t like, hate, love, etc.
Go back to work, leverage their feedback and quickly make changes based on the discussions you had.
Repeat as necessary.
During your feedback sessions, ask them if they would pay real money for your solution and let them do so if they say yes. If they won’t pay for what you’ve shown them, you need to reconsider further investment in (or the direction of) the project.
Rather than two years (or some other long, expensive period) of product/service development, you might have two to four weeks invested. It’s better to find out that you’re on the wrong track earlier, rather than later.
For the last month or so, I’ve been working on an all-consuming project. Yesterday, during a conversation with the recipient of this work, it became obvious that both of us had made some assumptions about the work that overcomplicated the project in the short term. In the long term, no time was wasted on this large, multi-phase project but in the short term – the assumptions were stunning.
Despite hours of phone conversations and emails, detailed technical specifications (geeks: think WSDL but newer), we still managed to have a rather large gap in the workflow of this project. Fortunately, there wasn’t any damage done and the situation merely juggles the position of a few tasks on the timeline, but we didn’t have to be that lucky.
“Your assumptions are your windows on the world. Scrub them off every once in a while, or the light won’t come in.” – Isaac Asimov
The root of assumptions
The root of assumptions, at least in this case, was both groups of people thinking they had properly and completely described the project. Bear in mind that there are mindmaps and API calls and a bunch of other technobabble. Still, this happened.
Not enough questions?
Not enough diagrams?
Not enough workflow description?
Not enough conversation?
Perhaps all of those, but there have been plenty. What ultimately caused this was quite simple: there was a fundamental asset involved in this project that I was unaware of. They knew it would be used. I didn’t know it existed, so I was planning to use a similar asset under my control.
I speak vaguely about these things because the details really don’t matter and I don’t want the technical jargon to distract from the meat of the discussion: assumptions are dangerous.
The project will come in on time and it’ll be good for both parties, but it might not have worked out as well had this discovery happened a week later. It wouldn’t have broken anything, but it would have wasted some time, or at least caused work to be done that won’t be needed for a month or more and that would delay work needed soon.
There are many ways that assumptions can endanger your projects. The key is to have a process that does as much as possible to eliminate them.
Eliminating assumptions with a third party
The most dangerous assumption I made was that the technical documentation and the mindmaps would effectively communicate the project’s details to a technical audience. At a granular level that was true. Where this assumption got me was at the 10,000 foot level – the level where you break down a ton of technical workflow to 10 sentences (step 1, step 2, step 3…) in plain old English that anyone would understand.
Didn’t happen. Six weeks went by without this critical message climbing out of the technical documentation – and even then, it didn’t. It came out when those 10 sentences were written to clarify something that suddenly became confusing.
Many years ago, I was involved in an exercise along these lines where two people with experience in a field had to explain something to each other. Once they reached agreement, they had to explain it to a third person who had no background in the subject.
A fascinating thing happened.
The two people who thought they were describing the same thing were still far apart. When each of them described the project to the third party, they were stunned at the assumptions each of them had made – not big ones, not project killing ones, but differences that could create drama, friction, additional cost and so on.
Watching these two people realize they were not talking about the same thing was illuminating and stunning at the same time because the audience was made up of people with similar experience to the two ‘explainers’.
Of course, the exercise was designed to set them up to some extent and the whole idea was communicate to all involved that communication is real work and that it is breathtakingly easy to make a few small assumptions that can take two parties on substantially different paths even though they think they are talking about the same thing.
Getting two people (or two groups) to understand each other and agree that they are talking about the same thing requires great care.
Next time you have a project to deliver, involve a third party with much different skills. Describe the project to them and see where the conversation goes. Maybe you can avoid dangerous and potentially costly assumptions.
What are you not getting done? Why aren’t you getting those things done?
Does important work often go undone? If so, is that work truly important?
Why aren’t you getting those things done?
Is it because of other things that keep you “busy”?
Are you busy because you aren’t delegating enough?
Are you unable to delegate?
Are you unable to delegate because you have no one to delegate to?
Are you unable to delegate because you don’t have time to document the task to be delegated?
Are you unable to delegate because the task requires skills that no one on the team has?
Do you have a system to develop people on your team? Is the system producing people that you can delegate tasks to?
If not, what should be changed so that the system produces team members who can take over the parts of your work that can be delegated?
Is it because you aren’t developing the “former” you in your team so that you can spend more time being the current you?
Is it because you don’t have an organized manner (system) of keeping track of what needs to be done?
Is it because the system (whether it’s paper, phone or computer-based) doesn’t work?
Is it because the system doesn’t work like you do?
Is it because the system doesn’t remind you of work that is scheduled or that needs to be done?
Is it because you don’t use a system that you have?
If you don’t use a system you have, why don’t you use it?
Is it because you aren’t giving yourself enough focus time?
What mechanism do you have in place to create focus time for yourself?
Does the mechanism work? If it doesn’t work, why is that?
Do others ignore the things you place in the way to allow you to have focus time?
If others ignore your focus time barriers, what have you done to clarify the situation or “discipline” those who ignore the barriers you build to create focus time? Are others aware of these barriers?
What is the cost of not getting these things done?
Is the cost, benefit or other financial impact what you use to determine the importance of a particular piece of work?
Does not getting these things done imply that they weren’t important after all?
Is the mechanism you use to identify work as “important” performing effectively?
If you look back at the work you considered important last month, do you still think it was important?
If not, how will you fine tune the system you use to assign importance?
Is there a system you use to classify work as important, not important, etc? One such system identifies work in four quadrants: “important and urgent”, “important and not urgent”, “urgent but not important”, and “not urgent and not important”. This system is often credited to “Seven Habits” author Stephen Covey, but there are also documents dating back to President Eisenhower’s use of the so-called “quadrant of work” system to decide what to do, what to decide upon, what to delegate and what to delete from the todo list.
Do sales or project goals depend on whatever you aren’t finishing?
Is the important work you’re not getting done tactical or strategic?
If so, is that a consistent situation? If not, have you recently been fighting through a situation that required you to focus on tactical?
Of the work considered important, is the cost of doing the work more than the benefit of doing that work?
If the cost exceeds the benefit, what makes that work important?
If the cost exceeds the benefit, should the work be done at all?
Turning that toward the less important (busy work?) that is consuming time best spent on the important work – if the cost of the busy work exceeds the benefit, should this work be done at all?
Do the important work
Consistently being able to identify the important and completing it while delegating what isn’t important IS the important work. The work you delegate may not be as important for YOU to do, but the fact that it can be delegated is the critical difference.
What’s the important work for you this coming week? What’s in place to make sure you get it done?
If you don’t have your system fine tuned yet… Does your staff?