Old School Management Techniques That Still Matter

Something that has always bugged me about the way that folks talk about agile and other flavors of management methodologies is that the methods are always phrased as something brand new. When in reality they very rarely are.

I started adopting agile methodologies after reading the citations of a Kent Beck book over 10 years ago.  Both The Goal, published in 1984, and The Mythical Man Month, first published in 1975, were mentioned in the book. Yet there are still experts pushing the same ideas as new trends in project management. This is similar to someone discovering Led Zeppelin or The Velvet Underground for the first time and telling everyone they know about this cool new band they found.

In response to my expert fatigue, I’ve compiled a list of my favorite old school management techniques. Included are the stories of the folks that told me about them.

PERT Estimates

PERT Guide for management use, June 1963Originally put into use in 1957 for building submarines, PERT estimates are a good way to break out of “nag & pad” style project management. An added bonus is that the journey is more valuable than the destination.

The end result is a more accurate estimate and a list of possible risks. After completing three or so estimates, a PERT estimate takes only a few more minutes to complete than a guesstimate.

To implement:

  1. The Project Manager clearly defines a task to be estimated.
  2. The individual closest to the work produces:
    1. A list of everything that could go wrong, what they would cost, and optionally how likely they are to happen.
    2. A list of everything that could go exceptionally well, how much these would benefit the project, and optionally how likely these would be to happen.
    3. An estimate based off of experience. Ideally time and estimate data from previous projects would be included.
    4. A pessimistic estimate. This is created by adding the cost of things from the “go wrong” list (step 2.2), that are reasonably likely to happen, to the overall likely costs. Use your best judgment.
    5. An estimate that involves adding the benefits of what could go exceptionally well to the overall likely estimate for an optimistic estimate. Again, use your best judgment.
  3. To get the PERT estimate combine the results of steps 2.3, 2.4, and 2.5 using this formula:
    (Optimistic  + 4xMost Likely + Pessimistic) ÷ 6 = Time expected
  4. Then combine the results of the “go right” and “go wrong” list into a Risk Register, with a basic plan on what to do about each item. Add that to your project management plan.

A word of caution. From this point some folks jump into gantt charts and critical path planning. Sometimes that’s a good idea, but often it creates more busy work than results. I use the estimates for prioritization & very rough timelines. I value the risk register because it makes the inevitable surprises less surprising. PERT also provides a structure for estimates that encourage a more holistic approach to predicting the future.

The Product Life Cycle (PLC)

The PLC appears to have been first documented around 1965 in the Harvard Business Review by Theodore Levitt.  While primarily a tool for product managers, there are some valuable concepts for everyone involved. Even those working on the new fangled cloud-based SAAS business.

Imagine that you are managing a project for Facebook. Learning from AOL in the mid 1990s, and later MySpace, you might want to reevaluate your methodologies. Putting a greater focus on evaluating and reacting to the market might leave you in a better position than these former companies.

Being knowledgeable about where the organization is with regard to market development, growth, maturity, and decline are important pieces of information for the team crafting a solution.

For example, early in my career as a developer I was assigned to diagnose and maintain a database management web application. After digging through the code for several hours I found a “=” where a “==” should have been. Additionally, there was a lot of quick and dirty code.

I ended up recommending a huge rewrite to improve reliability. This would also make it easier to maintain. In addition, I recommended a serious evaluation of the continued employment of the developer that did the coding.

If the project was in the growth stage, the rewrite would be worth considering. However, this product was in decline, and would likely never have a new customer. Therefore, my suggestion of a rewrite was not well received. What’s worse is that the author of the code was a principal of the company. A little more context from my PM at the time would have saved me a lot of embarrassment. It would have also saved the PM some hassles. Oops…

Sergeants Run the Army

Sergeants run the army. John Hanie, aka grandpa, told me this many years ago. He likely learned it in the 1940s when he in his words “backpacked through Europe with a 40 pound pack, a mortar, and a few extra bands of machine gun ammunition”. I was unable to track down where or when this phrase originated.

However, I really enjoy this related paper: Institutionally Constrained Technology Adoption: Resolving the Longbow Puzzle . The paper discusses how the English of the 1300s found that empowering their blue collar archers acted as a devastating force multiplier. This is best represented in art by the Band of Brothers speech in “Henry V”, and the resulting victory at the Battle of Agincourt.

Moving on to this century, I was able to find example, after example, after example culminating in Google’s outstanding re:Work post on the importance of empowered frontline managers.

An organization’s sergeants, aka front line project managers, are the reason staff leave. They are also responsible for staff who provide outstanding customer service. Frontline project managers are closest to the problems and solutions that organizations face. They are also often inexperienced. This means that they may be terrible, but with a little coaching they could have huge gains in productivity relative to their more experienced colleagues.

Celebrating Success

Cake, a firm handshake, and an authentic thank combine to be an excellent motivator.

In the early 1990s Big Bob, aka dad, had been assigned, through a series of unfortunate events, to a team that the state organization he worked for wanted gone. They wanted him gone too. It would be years before he came home from a state legislative hearing vindicated. In rural america quitting a professional job usually means moving, and he was not interested in that.

Faced with seemingly insurmountable adversity, Big Bob responded decisively. He did this by making cakes on Thursday nights for Friday staff parties. It took a while but the team morale began to improve and trust was rebuilt. Then, with this new found political capital among his motley crew, Big Bob was able have some very effective “so do you want the bastards to win, or do you want to change” talks. These talks turned careers around, including his own.

As an added bonus, cake parties really annoyed the other managers that had so carefully stacked the deck against him.

I continue this practice by buying the team a round of beverages and calling out specific things I appreciated about everyone involved. It’s not huge, but it’s authentic, appreciated, and reminds everyone I pay very close attention to what’s going on. If you’re in the Minneapolis / St. Paul area I recommend Able Seedhouse for their ample free parking, central location, and an outstanding beverage selection. Alternatively Yum! Kitchen & Bakery makes cakes that taste like winning.

Staff Development Through Real Coaching

A year or so ago I was sitting on a couch in a funeral home for the former but not so old boss of the great love of my life, Mel. After a while I noticed there were as many former coworkers as there were family members.  I could tell this because Ken, the former boss, had always dressed professionally at work. Apparently, however, he reserved collared shirts and ties for the office. His friends and family had known to come casually dressed. His work colleagues, however, were in more traditional funeral dress.

Ken was an outstanding manager, and had character that was immediately recognizable. He was also important to my wife’s professional growth. He provided her, and apparently half a funeral parlor full of folks as well, with bespoke and actionable coaching.

Manager feedback in my experience, and that of many of my colleagues, has rarely been actionable or related to our success. However, when Mel’s work started to signal layoffs were coming she was well positioned, and well rewarded for her efforts.

Giving actionable and constructive feedback is not without its risks. At the risk of seeming like the old man that shakes his fist and yells for kids to “get off my lawn”, it sure seems like folks don’t take negative feedback well these days.

I’ve had senior executives refuse to believe me when I told them that they were about to lose their entire team. A year later after their teams had largely quit, they found their name off of the brand, and presumably their role, and definitely their reputation, greatly diminished in the company.

Another time I told an entrepreneur that his entire startup had not worked for at least 45 days. Fixing it was months away. Again this was poorly received and the business quickly shuttered.

I’ve also given my, “it’s unreasonable for me to believe in you more than you believe in you, so suck it up and learn this new skill because you’re going to be good at it”, speech a few times, with some success. It feels pretty great when you see someone for the first time in a few years and they thank you for the kick in the pants that put them in a better direction.

Sometimes I’m surprised. I started out a coaching session and with some listening found out that I was WILDLY incorrect about what was going on. An example of this was a young staffer that had a bad experience with an abusive client. The staffer had shut down and was clearly frustrated. An offsite cup of coffee later I was going into other managers’ offices and reminding them that these were grown adults that can handle themselves appropriately and don’t need to be coddled. Even if they look like one of those adorable Campbell Soup kids. Moping soon stopped and productivity as well as jokes significantly improved.

The worst is earnestly coaching only to be reported to HR for being abusive. This usually results in a message a few months later from their new managers, frustrated with the same issues. Then a LinkedIn notification that they are at a new company.

What’s the difference between successfully coaching a valued staff member and being reported to HR? It’s some mix of building and maintaining trust with the team, and the individual’s own character. I’ve taken to setting up challenge interviews where the candidate has an opportunity to be coached, as well as to criticize the work of others. How they take criticism and how they criticize others is an important metric that measures how they’ll work on a team.

So why take the risk and do the hard work needed for effective coaching? Coaching is not just for when someone is underperforming to existing standards, it’s also to make existing resources more valuable.  A highly coachable brand new employee will improve faster than you can learn new tricks. Which is worrisome because that does make the team less dependant on you, but it’s also the only way you’re going to be able to delegate enough work to learn new tricks.

Coaching also a great way to spot shooting stars. Anyone that wants to get better enough that they will have an open conversation on what they can improve on AND do the work to get better, is going to get better at their job. Everyone else is going to drag the organization down to their level to avoid the hard work of continuous improvement.

Will your newly improved staff demand greater compensation, and have more opportunities available? Yes, but after watching the folks that did not keep their skills sharp suffer though a few recessions nobody can afford a job where they are not continually improving.

Be Coachable

This is tough. We form emotional callouses to protect us against life’s barrage of negativity. We do this both passively and directly just to make it through the work week. Some folks are just wrong when they give feedback, but most don’t care enough about you to provide any. So, appreciate any honest feedback at least a little.

The most common feedback is the most ignored, and it happens when you annoy your team members. My personal definition of professionalism involves handing off deliverables. Whoever receives it is happy with it and feel that I went out of my way to make their job easier. I think this is based off a concept from Eliyahu M. Goldratt’s “The Goal”, or some combination of lectures on work ethic from my elders. Either way it’s far from new.

It’s been surprising to me how often designers will pass off, to web and mobile developers, great designs that did really well in client presentations. Soon, however the developers notice links to nowhere, and orphan pages with no links to them. Additionally, amazing features are completely unsupported by the chosen platform. The reverse is also true. New features are requested and the design team is completely absent from the discussion. This results in user experience inconsistencies that can be tedious to resolve.

Value the opinion of the folks using the product of your work, as much or more, than that of the client or sponsoring executive. This goes double for project managers. Poor deliverables from project managers rarely go discussed, at least with the project manager that produced them. I assure you everyone else on the team is talking about them.

Opinions are easy to get, just ask. It will make folks uncomfortable. Eventually the team might even make fun of your silly mistakes, but that’s a sign that they like you. Otherwise they’d make fun of you when you’re not around so, in my honest opinion, it’s better to be a part of the joke.

Simon Sinek, author of one of my favorite leadership books, “Leaders Eat Last“, explains it well in this video:

Make Friends in Low Places

The front desk receptionist knows who the assholes on the team are. This is a trick I regularly use when starting new contracts. I ask the receptionist something casual about the stakeholder I’ll be meeting with. For instance the appropriate pronunciation of their names, or whether they have a meeting right after ours. Then we get to talking. If they don’t say something like “Helen is great, you’ll like working with her”, or I get a “look”, then it’s time to up the proposal numbers.

Alternatively receptionists know when your team members are only decent when they have to be, which can be hard to figure out.

This is a fairly common trick. So, when another manager does it to you, make sure that the receptionist receive one of the cupcakes you brought. It can really pay off.

The folks low in the pecking order are the first to know who above them abuse their power imbalance.

Edit: To avoid the pain of being made to feel old again, “Friends in low places” is a country music song released in 1990, and not meant to be demeaning to receptionists, janitors, or anyone else. Now stop making me feel old and educate yourself:

 

Van Halen’s No Brown M&M’s Trick

For those not cool enough to be alive then, Van Halen were big in the 1980s, and were unusually supportive of educators.

This one is so good it’s on Snopes for a fact check. Much like the lengthy scope of work documents faced by most project stakeholders, Van Halen has a large rider, similar to a contract, that defines everything they need to succeed. The problem we all face is getting folks to read and understand these documents. Even worse we usually can’t tell the documents went unread until it’s too late.

Van Halen’s brilliant solution was to add a clause demanding a bowl of M&M’s in their dressing room. In this bowl all of the brown M&M’s had to be removed. Not a difficult request, but one easy to miss unless the contract is carefully reviewed. If they walked in and saw brown M&M’s they immediately started checking everything, especially anything that could affect the team’s safety.

The two ways I use this trick is to first add bizarre clauses to my contracts. Secondly, I add instructions that should trigger reasonable folks to ask a question. For example all of my scope of work documents contain this clause or one similar:

“On failure to respond to a request for information via email, txt, IM, phone, within 48 hours a Bachman’s escalation may be implemented”

This sounds ominous, but if asked, I answer that it’s simply that I will order flowers from Bachman’s Flowers, have my question put on the card, and send it to your office. However, if I’m not asked I can be pretty confident that the document was not read.

Another time this is handy is when following instructions is crucial to mitigate risk. I had a situation where I could not control a server, and the automated deployment tools failed about 1 out of 10 times. So almost always any individual project would be deployed with a simple press of a button and be forgotten about. However, when managing as many projects as we were, 1 out of 10 meant a production failure several times a week that we could not easily fix. The solution was to make sure the server team was around and aware we were deploying so that they could let us know of a problem ahead of time, or quickly fix anything that came up.

I wrote up new deployment procedures, added them to the project documentation and informed relevant stakeholders. All standard stuff, except for step 7, which was to email me a selfie giving me a thumbs up. As usual nobody read it, but I could tell this time. So when I got the email telling me the sites were successfully deployed, I immediately replied back requesting them to read the deployment documentation and to tell me which steps they’d forgotten. Sure enough, other than not sending me a selfie, they neglected to contact the server team. A couple days of chuckles in the break room and the whole team was on board with the new procedures.

If you have a few minutes to spare I recommend watching Van Halen’s own Diamond Dave explain the strategy himself:

I have a small favor to ask…

I spend between 5 and 20 hours creating these blog posts in an attempt at both being helpful & shameless self promotion.

If you find them helpful please share them on LinkedIN or other social networks. It really does help me find new product or project management gigs.


Or if you’d like to grab a coffee and talk shop, send me a email with the form on the top right

Thanks,
  Robert

This post was professionally edited by Suzanne Jaochico.