Presumption of Success based on "Experience"

Experience is a great thing.   Oscar Wilde said, "Experience is simply the name we give our mistakes."  I don't always agree with that, since sometimes a success teaches as well.  However, among blowhards and non-blowhards alike, I often see over-reliance on experience even though the current situation is not truly analogous to the already "experienced" situation.  Managers often miss nuances in the current situation that make the current situation different than the old one.

It is good to look at a situation and say, "Well, this worked for me before," but that analysis is often too shallow.  As a result, managers make the same decision as last time, and sometimes it works and sometimes it doesn't work.  Now managers start second guessing themselves, and they don't really understand the problem before them and therefore the solution to the problem.  The real problem is that new factors should have been part of the new decision, and the decision tweaked for those factors.  I meet and even advise so few managers that look for nuance, or as Eli Goldratt might say, they don't look for the new hidden constraints in the system.  The decision should still incorporate experience, but that experience should help you understand nuance, not ignore it.

I'll give you an oversimplified example.  Say a development manager, Andy Friese, (love that name) has two developers who can contribute 40 hours per week, and he needs roughly 100 hours per week of development time.  Just about every manager I know has hired people before in those situations, so their default action is to say, "If resource time is the problem, then resource time is the solution." So Andy hires a developer.  He now has a 20 hour need at 40 hour cost.

Side bar: Managers love to hire people.  Many think that managing more people makes them better managers, but I submit the following to you for your consideration.  The managers that do the most with the fewest human resources are the best managers.  Corallary: That doesn't mean kill people by working too few people to their death.


Back to my example:  The solution of hiring assumes that all variables are roughly the same as the last time.  Andy has the same project management practices, the same revision control, or QA practices, etc.  Blowhards (myself included) often get too busy to look at the nuanced differences in the system, and go with old easy.  But Andy has not really looked at what the real constraint is that is causing the problem.
 
Lesson: Andy needs to look for, and understand the constraints in his system.  If he looks openly enough without presumptive bias, he might find that his revision control, or QA practices, or project management practices are wasting developer time.

So let's say Andy doesn't Friese up, and discovers that revision control is wasting huge amounts of time.  He changes the system to a more efficient system, and discovers that he's now got more time in the system from existing developers.

If he had hired another developer without understanding the original problem he might solve the issue of getting 100 hours of work, but Andy has extended the marginal cost problem of his system on a per person basis.  He now has three people wasting time and using an inefficient process. He's also paying a whole extra salary. He's not fixed anything except the topical problem of needing 100 hours.  In the long run, he's probably making things worse.

Instead of using experience to understand nuance in order to make better decisions, managers often use experience to make the same decisions over and over.

One of the worst phrases in management, "We do it this way because we did it that way before."

Any employee's response should be (a la Rule 6), "Are you sure that the variables in this instance are the same as before?"

Some tips for leadership mentoring

People ask me for all sorts of tips on leadership mentoring. How do you get someone to magically make good organizational leadership decisions because you think they have management/leadership potential? Many managers simply hand the person a management job and see what they can do. I've found that that works in very few cases. There are some alternatives. Here are some of mine:

1) Force potential managers to make tough decisions when they don't have to and when the pressure is off. If they can start to see how to make good decisions in this way, they'll make good decisions when the pressure is on.

Here's something I like to do (straw man example): The CEO or COO asks me for advice on a thorny personnel issue or operating decision. The COO sends me an email with some background and the question. I read it, think about it and come to my own conclusion/decision. Then I call in someone that I'm "mentoring" to be a tech leader and say, "Read this and tell me what you think and what you'd do." If I think they're a little off, I say, "Well what about x-factor? How does that impact your thinking?" And push on them. In this way they begin to see management level information, and understand how decisions get made at that level and what orthogonal things they need to look at to make good decisions.

Caveat a) Make sure that your management peers or bosses (COO/CEO in the example) know that you're mentoring these people and that you have complete confidence that the information will remain in confidence. I suspect you shouldn't be mentoring them if that's not the case.

Caveat b) Be prepared to change your own mind. Occasionally someone comes up with an answer out of left field that I hadn't thought of, and it's better than what I had come up with. Get over your ego, discuss that with the mentee, tell them good job and that his/her idea will be the one to run with. If you feel comfortable with it, get your mentee exposure for the idea. I have on occasion told the original asker, "Well, I decided to discuss it with Josh, and he came up with X. I think it's a great idea and concur."

2) Push on people in odd leadership positions. One of my favorite things to do is to tell a development team (that I've recently begun managing) that we're going to have rotating team leads. Maybe one person per quarter, or more usually I have one developer as team lead for the duration of a project.

Developers invariably ask me for a well defined set of guidelines clearly defining "team lead." Don't be tempted here. I generally drive them nuts by giving them a very loose definition: "Manages x, coordinates with me, etc." I do this on purpose. I understand that it's a little frustrating, but I want to see what the individual team leaders come up with. I want to see how expansive they'll be in the role. Most people are somewhat smart (if not, then why are they working for you?). Given that, they often come to me with issues to work out before deciding them, and I can help them figure it out rather than correct a bad decision after. Of course I encourage them to do this before they start. Also of course, I watch carefully and nudge when someone needs nudging.

Give people an out. Not everyone is cut out for organizational leadership roles. Tell them that they don't have to do it and that there are no penalties for declining.  I've had very few of these, but some people want to be high quality contributors, and some people want to be "field" leaders rather than organizational ones. Ye olde square peg...

More to the point, I almost always learn a great deal about each person. I've found that few people when thrust into a team lead position, operate exactly as I had expected. I've had team leads that were the quietest, most shy people turn into big time jokesters. People I thought were probably worthy of being fired were suddenly stars. More importantly, we all see new valuable leadership skills come from nowhere. The team members see these from their peers and sometimes incorporate or reject these styles and ideas. Almost everyone becomes either a better team member or team leader in this process.

3) Get odd with exercise: One thing I've found works great with younger organizations is do some mental stuff that gets people out of what they perceive is their job.  At the Open Source Lab, we had weekly brain teasers and exercises that I put together just to see what happens.  One week it was, "Explain Hemi engine type and its valve setup to the team." Another was, "Debate the pros and cons of outsourcing from organizational and economic perspectives."  Stuff like that.  Some people I thought were sub par employees turned out great and I learned that they were probably in the wrong place and also had real leadership potential.

Anyway, this list is by no means exhaustive.  I've seen lots of things that other managers have done with varying success.  Find ways to get people leadership skills before you give them leadership jobs.  If they are already there, then mentor them.  But usually just throwing someone in the pool is a bad recipe.

And for all of us blowhards out there:  No campy stuff.  Skip the trust falls.

Rules 3, 4, and 5

Rules 3, 4, and 5 are a block.

3) Take care of the people who work for you. The Team comes first.
4) Take care of the user/customer.
5) Take care of the people you work for. Rules 3 and 4 will do most of the work on rule 5, but the boss always comes last.

They sound mostly self-explanatory. They are. But the order is important.

3) Take care of your team: This goes equally for members of the team as for blowhards. Team members must look out for each other, and sometimes to the exclusion of other important things. Most managers hate this, but if you want team cohesion, taking care of a teammate is more important than taking care of something the boss wants. This one can be tough for even the most magnanimous managers. But if you really want to have a great team, get over yourself. If a team wants to take a half day to help a team member move when the manager wants to do something else like have some stupid trust falls, or read Steven Covey in a circle while quietly saying, "Namaste," your best bet is on the moving. And then go burn your Steven Covey books. I'm just kidding. Sort of.

4) Take care of the customer: Again it's obvious, but also the order is messaging in itself. The team comes first. You need a good team to take care of the customer. A cohesive team works together to nail customer needs. Period. Some blowhards' first instinct is that "the customer always comes first." Well, if you haven't got a good team, the customer gets crap.

5) Take care of the people you work for. Rules 3 and 4 will do most of the work on rule 5, but the boss always comes last: At the end of the day, you are an organization that needs the team's skills, and the cohesiveness of the team. Usually executing well on 3 and 4 require little execution for rule 5. But sometimes you have to do rule 5 stuff too. But it's last. We'll call it Jason's Heirarchy of Corporate Needs. Except instead of that really important stuff like Physiology, Safety, Love, it's Team, Customer, Blowhards. And no, just reading Steven Covey and doing trust falls to please your boss doesn't count.

Distinction: "The people you work for" is not just about the blowhards/bosses. It's also about the company as a whole. The fuzziness is intentional to be broad enough to cover both.

For the aspiring blowhards: Team rule three is critical. Make sure your team feels truly taken care of from their peers (no backbiting, politics, etc) and from their managers (no backbiting, politics, etc). Keep your teams from getting depth charged. If customers are unruly, ask the customers to deal with you directly. This isn't that hard, but it seems to be one of the leadership functions most massively missed in today's corporate culture.

This is directly in support of Rules 1 and 2. Content and effective.

Rules 1 and 2 explained

The first two rules are more important than people think and are, at least in my mind, less facile and glib than they sound.

Rule 1) Have Fun: It sounds obvious but fun is important. I don't mean fun in the sense of playing Halo on your XBOX. I really mean content. It's important to be content in your career if possible.

But "have fun" is also more expansive than implied in the statement. When people start working an organization for which I am the blowhard, I give them my 13 Rules spiel. With Rule 1, I tell them that it IS important to have fun in the content sense. But it is also important for ME, as the blowhard, to ENSURE that they have an environment where they can be content. If they aren't or can't be content, but are legitimately good and intelligent people, then it's my job to find them a place in my organization where they can be. If they can't do that, then I promise to help them find a job elsewhere in the company or even outside of the company, where they can be content.

Of course, I also have to believe that these are quality people. If they're lamers, then they shouldn't be in the company in the first place.

2) Do good work and make some money. This also sounds facile, but doing good work and making some money are probably important in the private sector. But this is really about being effective. It is my and the employee's job to do everything we can to help them be effective. If I can't setup the environment where it is possible to be effective, then it's first and foremost my fault for their lack of effectiveness.

If I can do that, and they aren't effective, then I have effectively eliminated myself as part of the problem when they aren't effective (Rule 8, There are only bad team leaders). Of course that's easy to say in a black and white statement, and it's never such. But it is important that management is confident that they are NOT the cause when they accuse employees of being ineffective. That just happens so often in corporate America today.

Content and effective. Those are two critical ideas encompassed in Rules 1 and 2. If people are content and effective, you generally have groups of people that can accomplish real things, and build great companies. In that vein, I believe Rules 1, 2, and 13 are just about the most important of all 13. In fact, for really good leaders and employees, they probably obviate the need for the other rules. But that is maybe too subtle in business, when leadership so often lacks that level of nuance.

What are you getting paid for? Cognitive shift for new leaders and managers

Something that I have a hard time teaching to new managers and leaders is getting them to understand one of the most critical changes that you must make when you become the latest promoted blowhard.

You worked your butt off, putting in 80 hour weeks to reach the director/VP/C-level management. But let's start with this important premise: YOU ARE NO LONGER GETTING PAID TO WORK HARD. Don't get me wrong, you may still have to work hard. But it is emphatically NOT what you are getting paid for.

Corollary: You ARE getting paid to make good decisions.

So many new managers just get right back on the treadmill. The visceral and even cerebral assumption that new managers make is that continuing to do what got them promoted will continue to make them successful. So they start running again. It's a bad assumption. They're trying to do it all, instead of trying to get it all done with good decisions and a group of people. That is now what you are paid for.

You've now got to use decision making to get a group of people to get it all done and be effective and content. Those two things are the crux. You're brilliant decisions have to get a group of people to deliver/be effective, while keeping them happy or content. I might even reverse it. Content first, then effective (a la the 13 rules).

The unspoken rule, HAVE SOME RULES

The evolution of the rules started with my first real management and leadership job. I was probably too young, and definitely too inexperienced, but I gave it a shot anyway. The only problem was, there was no framework for how my organization would operate. I'll give you an example. I realized very early on that if there isn't a framework for decision-making, then how could I, the Pointy-Haired-Bosscon (some years later it's Bald-Headed Bosscon in my case) possibly be annoyed at someone who made a bad decision. They probably made the best decision that they could. But with no touchstone, it's a decision made in a vacuum.

In fact, if I haven't set the framework, and the bad decision is made, then it is not only not the decision maker's fault but it is surely my fault that a bad decision was made (see Team Rule 8).

So, to keep this entry short, the number and composition of the rules is probably important, but the very existence of the rules is just as important as the rules themselves. I originally started with 10 rules (The first 9 from below and #13). Now we've got a framework. That framework is as binding upon me as it is on everyone else on the team.

When I start a new management job or hire a new person, every person on the team reads the rules. I require that they look me in the eye and tell me that they understand the rules and that they are O.K. with the rules.

Now, for example, if a team member calls me a jackass in front of a customer (thus violating Team Rule 6), the framework is set. I sit down with the person and say, "You recall that you read, understand, and agreed to the rules. So why the hell did you do that?" Now, let's be careful here. I'm not implying that calling your boss a jackass is a bad thing. Sometimes the boss needs to hear it. I often need to hear it. Rule 6 specifically says that team members CAN challenge the boss. Just do it in private. So I say, "How does calling me a jackass in front of the customer help our team?" Do it in private, convince me, and often you'll find that you were right. I was a jackass. But doing it publicly showed divisiveness within the team, and that's bad for the team (it therefore also violates Team Rule 3).

I have set expectations upfront, and the rules were violated. For the purpose of this exercise I have eliminated myself as the problem (there not being rules about the issue), and can fairly apply correction in saying, "You agreed to the rules, you clearly broke the rules, you're in trouble." Although, I've found that usually noone's in trouble. I just want to be told how and why it won't happen again. I don't enforce the rules so much as reinforce the rules in this manner.

So, have some rules. You are welcome to mine. There are lots of others out there. But remember the existence of the rules is important as the rules themselves.

Sidenote: The scientists and engineers love to point out the recursive nature of Rule 13. Great! Rules 1 and 13 are absolutely the two most important rules on the list.

The 13 Rules

The primary reason that people started asking me to write this blog is because of a set of "rules" that I have developed over the years. I call them "Jason's 13 Rules for Team Leaders and Team Members." The evolution of the rules, according to my...ahem...supporters is as important as the rules themselves. So, what I'm going to do is write a few entries that cover both the rules and how they evolved. First is discussion about the application of the "rules." The rules apply to everyone, including me. In effect, the rules are more of a "Bill of Rights" for team leaders and members. They are a framework for how, as a group, we can interoperate, make decisions, and support each other.

Here are the rules, and after that I'll discuss why the very existence of the rules is a critical organisational leadership and management function. In separate entries, I'll discuss the individual rules, why the order of the rules is important, and the evolution of the rules.

1) Have fun.
2) Do good work. Make some money.
3) Take care of the people who work for you. The Team comes first.
4) Take care of the user/customer.
5) Take care of the people you work for. Rules 3 and 4 will do most of the work on rule 5, but the boss always comes last.
6) It is the team's obligation to challenge its leader. You won't get smacked down, you'll get MORE respect. However, do it appropriately. In private.
7) Once the team lead has made up his mind, even if a team member disagreed before, it is now his/her responsibility to push that decision to the outside world as though it was his or her own.
8) THERE'S NO SUCH THING AS A BAD TEAM, ONLY BAD TEAM LEADERS! If the team is bad, it's still the leader's responsibility to make it good.
9) It is the team leader's job to insulate the team from the outside, so that they can do their jobs.
10) Don't ever say, "that's not my job."
11) It is a core component of every leader's job on this team to pass their knowledge on to others in the team. So pass it on...
12) It is a team leader's job to push power and loyalty down, not up.
13) See Rule 1.