Saturday, July 11, 2020

Plan to Do Nothing

Rule 1. Plan to Do Nothing and You Will Certainly Achieve Your Goals.

This rule started out as a bit of joke, along the lines of if your plan for a goal of doing nothing, you can always achieve that goal. But then I noticed something as a manager, the busier I was, the more I was doing every day, the less effective I was.  At first, it seemed like a wicked problem, with no real solution. (I may write on some real wicked problems later, but for now, you can check out this somewhat depressing treatise.)  Fortunately, managerial busy-ness has a cure, planning to do nothing.  Posh you say, the speed of today's work means that he manager will always be busy. Managers are the hardest workers of all, if they are to be successful, or so we are told.

That view fails to answer: what is the work of management? The key concept here is planning.  The manager must be working very hard at planning!  And what is he planning? TO DO NOTHING! This doesn't mean that the organization is doing nothing; the mission and the work remain and must be accomplished.  But the rule should look like this: Every predictable aspect of the team's effort should be planned as to who has responsibility for execution.  Further, the responsibility for any routine work should NEVER be allocated to the manager.  This allows all routine and predictable work to flow to the correct performer.

Does this mean the manager is doing nothing? Of course not. Unpredictable new tasking is always arriving. The changing environment is always causing work to be re-planned. There is always a crisis.  But if your day is filled with executing routine work, where is the time to handle the all of the predictable crises? Not that each crisis is predictable, or you would have planned for it. But it is predictable that there will be crises. And some crises do become predictable; so we PLAN to be ready for them.

I once went through a period where we were tasked to produce a "stop-light" chart with detailed notes to show what additional funding we needed to get our portion of a major defense program to green.  We put the brief together, it was presented by our program manager, and we congratulated ourselves on a job well done.  But then a funny thing happened.  We didn't get all of the funding. And another opportunity to brief came up on short notice, late on Friday with a Monday deadline.  And this happened again.  Third time was the charm; we just started keeping our charts up to date because the short notice tasking wasn't going to cease, and didn't for about 9 months. But as manager, I didn't keep up the charts, my project controller did so by coralling necessary input from product leads on a weekly basis. 

Once the routine work and predictable crises are planned, we can start to do our real job, which is making things better. Some like to call that "continuous process improvement," but that sounds way too bureaucratic and non-value add. Making things better is just asking basic questions over and over to make sure your team is performing well.
1. Is the team fully productive? If not, who is under performing and how can we help them improve.
2. Do my reporting processes give me the right, TIMELY, information for decision making? Do they give my boss the correct and TIMELY information?
3. Do we have the right people on the bus? (H/T Jim Collins.) Who do we need to hire or fire?
4. Are we organized effectively? Is work flow efficient? Do we have the right tools?
5. What is the next threat or opportunity? How do we get ahead of it?

Answering these questions may not feel like "real work." But if you don't plan to have the time to answer them, you will lurch from one crisis to the next, and always be busy and ineffective.

Sunday, July 5, 2020

Riehm's Rules - All Ten

I skipped rule 6 in my last post, because I had apparently lost track of the count.  It gave me an opportunity to revisit my rules in light of my more recent experience. I had thought of adding Rule 5 "Simulate Concern." But that only has situational applicability, and was already taken by someone else.  Besides, I need a rule 6.  Here is the new list.
1.  Plan to do nothing, and you will certainly achieve your goals.
2.  Management is hard, leadership is better and supervision is most difficult of all. Corollary: Hire people who don't need supervision.
3.  Hiring is the manager's most important decision.
4.  Stay on message. Communicate consistently. Repeat your theme repetitively.
5.  The commodity in shortest supply is management attention. Corollary 1: The most important word in a manager's vocabulary is "no." Corollary 2: Email is an evil leach of your time.
6.  Don't fight market forces.
7.  Understand your firm's economic engine and your unit's.
8.  Be careful what you ask for, you just might get it.
9.  Deliver the bad news yourself, let your people deliver the good news.
10. If you can't cover yourself in glory, cover yourself in paper.
Not fighting market forces can have different meanings, depending on your organizational context. Two key elements stand out.

1. Broad market forces are going to drive technology available for you to conduct business. That's obvious but bears repeating, I often see arguments for using the "better technology," but if no industrial base exists in five years to support the choice, it wasn't a good choice.  Managers also have to show some common sense regarding technology trends.  One example, you can expect a mutually reinforcing cycle of operating system upgrades and hardware upgrades to be required of all your embedded technology, not just your laptop.  This means we should lean forward to be at the high end of the state of the shelf to avoid technology obsolescence, announced or otherwise.

2. Your organization is an ecosystem with market forces of its own. Attempting to force fit new technical solutions, except when absolutely necessary, is another way we can be fighting market forces.  We make more allies within our organization and deliver faster with lower sustainment costs when we cause the already delivered enterprise solutions to be modified rather trying to bypass them.  For a seemingly ludicrous example, the Department of Defense has been billions on a public key infrastructure technology.  There are occasions when the technology doesn't fit a particular use case. But reverting to user name and password log delivers low security that will either cost a lot due to a breach or cost a lot when the organization directs an upgrade.

Next up. Start outlining all of the rules in a more rational order.