Leadership Principles (shouldn’t the Army know?)

Digging through my old Army stuff I ran across the “Rangers Handbook” (MCOE SH 21-76) which caused me to pause and reminisce for a little while. I must admit that I never earned a Ranger tab; I was an Armor officer. Fortunately, just as it states in this publication, this material can “.. also serve as a handy reference for other(s) …”.

The Ranger Handbook starts off with defining the Principles of Leadership and while they surely are aligned with light Infantry units, they can easily be adapted to leadership in the business world in general and to software development management in particular. The rest of this post is simply a cut-and-paste of Section 1.1-1; the BE, KNOW, DO “principles”. For non-military purposes, any words/phrases that don’t apply are highlighted with strikethrough markings and all additions are underlined.

1-1.1. PRINCIPLES.

BE

• Technically and tactically proficient.
• Able to accomplish to standard all tasks required for the wartime mission goals assigned.
• Courageous, committed, and candid.
• A leader with integrity.

KNOW

• The four major factors of leadership and how they affect each other are-

• Led
• Leader
• Situation
• Communications

• Yourself, and the strengths and weaknesses in your character, knowledge, and skills. Seek continual self-improvement, that is, develop your strengths and work to overcome your weaknesses.
• Your Rangers team, and look out for their well-being by training them for the rigors of combat assigned tasks, helping them take taking care of their physical professional and safety motivational needs, and disciplining and rewarding them.

DO

• Seek responsibility and take responsibility for your actions; exercise initiative; demonstrate resourcefulness; and take advantage of opportunities in the workplace on the battlefield that will lead to you to success victory; accept fair criticism, and take corrective actions for your mistakes.
• Assess situations rapidly, make sound and timely decisions, gather essential information, announce decisions in time for your organization Rangers to react, and consider the short- and long-term effects of your decision.
• Set the example by serving as a role model for your team Rangers. Set high but attainable standards; be willing do what you require of your team Rangers; and share dangers and hardships with them.
• Keep your subordinates informed to help them make decisions and execute plans within your intent, encourage initiative, improve teamwork, and enhance morale.
• Develop a sense of responsibility in subordinates by teaching, challenging, and developing them. Delegate to show you trust them. This makes them want more responsibility.
• Ensure team members the Rangers understand the task; supervise them, and ensure they accomplish it. Rangers Team members need to know what you expect: when and what you want them to do, and to what standard. These tasks could range from following a well-defined process to a completely open-ended effort in an uncharted realm.
• Build the team by training and cross-training your team Rangers until they are confident in their technical and tactical abilities. Develop a team spirit that motivates them to go perform their tasks willingly and confidently into combat.
• Know your unit team’s capabilities and limitations, and employ them accordingly.

How Projects Really Start (its all about the money)

Long before I became a development manager I truly loved the beginning of a software project. I enjoyed that short period where a few folks started kicking around the requirements and ideas & plans started brewing on how we would design and implement a solution. The next steps of actually starting to build something that aligns to the plans (including the learnings from what the plans didn’t tell us) are even more enjoyable. What I can tell you about my role as a software development manager at a typical corporate IT shop don’t excite me that much…

In a typical corporate world the “real” start of a software project happens weeks, if not months, before the perceived start. This is when we, the leadership, try to estimate what a project might cost and how long it might take so we can try to secure funding from a bunch of accountants. If we pass their test of capital vs expense allocations and return on investment (ROI) periods, then we usually get the green light to begin a project. The amount of time invested in this “dance” varies from company by company, but it would blow the average developer away knowing how much time is actually spent on this endeavor.

Truth is, this is why many companies want their managers and directors to earn an MBA. You end up feeling like a member of the corporate finance team after a few of these cycles. Not exactly what you signed up for years ago when you started your career in software development, but surely where you are now.

So, be forewarned! Don’t move up in a software leadership role unless you are OK with accepting that this is an area you will have to deal with and learn to understand. It is an area most of us don’t like and many of us still struggle with; although most won’t admit it. Fortunately, it is only a part of a manager’s responsibilities and we, at least the first line managers, still get to be part of the solution our team is creating.

If you can, do your dev manager a favor — fill out that weekly timesheet and split out maintenance from new development like she asked so that way her finance numbers line up and she’ll get a chance to commission another project that you’ll get a chance to be the true hero on!

100 Percent Goals (only yields inflated estimates)

For several years now, our CIO has continued with his mandate of ALL projects completed 100% on time. Now, he’s really not stupid enough to think we could really pull that off, but he is stupid enough to think that this will get him as close to 100% as possible. What it really encourages is for teams to make sure they build so much buffer and padding in the project estimates that they can almost certainly deliver on time.

If that alone doesn’t make the project leaders produce some excessive estimates, then we surely do a great job of making sure the folks that miss a final deliverable don’t do it again. How you ask? Well, we put them under the hot lamp and give them a good old fashion chewing out and remind them that their peers are meeting expectations, not to mentioned refresh their memories that those who can’t meet expectations will get plenty of “help” finding someplace else to work.

My experience tells me that asking my project leaders to give me aggressive timelines and fully expecting some projects to run over their time and money budgets. The real benefit is that I get many more projects that come in early and cheaper than originally expected. If we let our folks do their job and support them along the way with true involvement in their efforts, then you will almost always be able to reap the benefits of technologists being self motivated to do a great job and to do it faster than any padded delivery date you would have received with a 100% on time mandate.

I don’t know about you, but I’d rather get 90+% of my projects finishing way ahead of those padded delivery dates instead of 100% on time based on those inflated estimates.

Lucky (it doesn’t mean privileged)

OK… I’ll admit it before you read too much. This posting is really a bit of a rant, but I do try to wrap it up with something positive; maybe even insightful.

I was in a drive-thru the other day and the personalized license plate on the giant SUV in front of me read, “LUKYONE”. This “lucky” person decided the world was his oyster and proceeded to dump out his coffee as he reached the speaker station. Of course, coffee splashed everywhere. Fortunately, even a bit hit his own vehicle.

The prestige of his overpriced behemoth and the smug look on his face as he decided he would make a mess for someone else to have to deal with implied his good fortune in life. The license plate only put icing on the cake. Now, I’m not against anyone having some good luck in this life as we all know it is hard enough as it is. I simply don’t believed that if we’re lucky enough to have good fortune shine on us that we ought to confused that with thinking we’re privileged.

Nobody is privileged to do harm to another. Now… I know this fella didn’t actually hurt anyone, but his cavalier attitude was just too much for me and made me get on the subject in the first place. I believe strongly in civility and responsibility (now there’s a rant you don’t really want to start me up on) and this seemingly small event betrayed that this gentleman didn’t practice either.

How we act in the seemingly insignificant matters foretells how we will act when there is something important on the line. When push comes to shove, I sure don’t need somebody working for me that feels they are “privileged”. None of us really are. I want bright folks folks who know how to stay focused on the tasks at hand. I want SUCCESSFUL folks, not privileged ones.

Do I want lucky? Heck yes I do! Bright folks know that luck combined with opportunity, ability and effort rounds out the four legs that hold up the table called success. So… find an opportunity that aligns with your abilities, lean into the work and with a bit of luck, bask in your success. And if you fail, don’t feel like you were privileged in the first place; just notice how much luck actually had to do with it, be persistent and try it again.

Specializing Generalist (or is it a Generalizing Specialist?)

There are a ton of different beliefs of what it takes to be successful in the software development profession. Some folks out there would tell you to become the very best “Xyz” developer you can possibly be. While I’m not against be very competent at any particular skill, I’d sure advocate being very good at many different skills as well.

Scott Ambler declared this kind of person a Generalizing Specialist years ago and I wish everyone would read his short essay on this topic. Scott doesn’t suggest being a generalist as these folks are Jack of ALL trades and masters at NONE. Generalizing Specialists are Jack of MANY trades and masters of SOME.

Again, best to get this information straight from the link above as this is a solid strategy for a successful and interesting career in software development.

The NEW Secret CIO (I miss Herbert Lovelace)

Well… the Herbert W. Lovelace “Secret CIO” postings in Information Week ended back in 2005, but there is a new Secret CIO and he’s using the pseudonym of John McGreavy. His latest posting, What Makes For A High-Performing IT Manager?, while covers more than this, sure hits on a couple of points I’ve been preaching on for some time.

First, everyone talks about learning how to “talk to the business”. This doesn’t mean that we should walk away from our technology focus; it simply means we need to accept that we have to take off our propeller caps when we’re talking with our partners/customers. We need to make sure the folks who approve the money for projects understand how this will make their lives better — not what we’ll be doing “behind the curtain” to make it all come together.

The second big topic that our new Secret CIO (subtly) called out is the raw truth that we all have too much to do. Successful knowledge workers have to learn how to decide which work we decide to tackle. Unfortunately, there is not magical formula to apply and the choices are heavily influenced by your specific situations, environment, projects and so on.

The first big step to becoming successful on this front is to truly internalize that you just can’t get “everything” done. Once you realize this epiphany you’ll be able to create your own decision making process that allows you to be even more productive while leaving some things on the shop floor.

I’d love to hear your thoughts on these topics.

Assholes and Prima Donnas (you need a few)

Despite the economy, our company is holding its own. In fact, things are going so well that Alpha Wolf Ken’s boss, Wild Will, managed to convince our business partners of a whole new product that we need to bring to market as quick as we can. This is the kind of stuff Wild Will is good at. He has absolutely no idea of what the “little people” do, but we get chances to do new stuff because of his ability to drum up new work. On that note, I sure admire him.

This lack of knowing what the developers “do” is overshadowed by the fact that he doesn’t know that he doesn’t know what our developers do — much less what really goes on in project teams. To make matters worse, he’s created an environment where “a can-do attitude is expected”. That translates to “you’d better be glad you have a job” and (simply) “don’t bitch”. We’ve lost some really good folks over the last couple of years due to this expected behavior.

I started getting excited by our ability to hire some fresh new faces with all the openings Will created, but that simmered down a bit at our last staff meeting. Will pontificated that we need to only hire folks that “fit in with our culture” and he absolutely declared, “no assholes or prima donnas”.

Will has failed to realize a couple of things. First, this culture of “sameness” and “can-do attitudes” has simply forced the staff to only talk among themselves, and not to their leaders, about the things bothering them in the organization. How can we, as leaders, fix things that aren’t coming to our attention? Of course, any leader worth his salt would feel a bit awkward with NOBODY is EVER coming to them with ANY TYPE OF COMPLAINT.

Hmmm… that reminds me of the day that Joe-Bob told me that he was a great manager as everyone always agreed with him, but we’ll save that one for another day…

I’m not advocating a season of Total Drama Island, but seriously, when was the last time that everyone on your team was perfectly happy about everything. The other thing Will doesn’t understand is that you need a healthy mix of folks to get a stellar team. While I’ve been lucky to lead (and be part of part) of a couple of high performing teams where everyone’s skills were almost identical and nobody had an attitude at all, there are some great teams who are great because they have and a couple of assholes and/or prima donnas.

Assholes and prima donnas can only get away with being the folks they are if they perform, and they usually perform so well that they even know it — hence, they turn up the “attitude”. Heck, even General George S. Patton said, “all very successful commanders are prima donnas and must be so treated.” He also admitted being a prima donna himself and I’m sure I’m not alone when I think that he was called an asshole many times!

Assholes stir things up when they need to be. If they see something stupid happening, they call it out. They don’t have time for nonsense. I want an asshole, or two, on my project instead of a bunch of “yes men”. Prima Donnas are the superstars of your team. Let them puff up their feathers. Let the other team members know that if they rock, then you’ll put up with their crap, too!

With all of that said, I’m proud to say I’m a bit of an asshole, too, and I’m surely a prima donna. I challenge you to look within yourself and the folks you admire in your organization to see if they just might be assholes and/or prima donnas. Are they the ones driving the bus? Is your organization better off because of them? Despite their problems, do you really want them to leave?

“Do we really have bugs?” (did he really ask that?)

In contrast to Joe-bob, Rico has been around the block for a while.  Rico is savvy,  Rico is suave and Rico will be a “manager” (maybe not so much of a leader…) at his current company a long, long time.  Surely much longer than I.  It’s not that he solves that many problems; it is that he knows how to stay stain free.

Furthermore, you’ll never hear Rico say anything in anger — heck, I’ve only gotten him to say one curse word the whole time I’ve worked alongside him.  Are these bad traits?  Of course not, but they do bug a straight shooter like myself who believes in just telling it like it is instead of spinning a “story” that folks want to hear.

History tells me that when you run into someone like Rico, they often don’t “get it”.  They start reminding you that they really are a top-notch developer just like everyone on the team.  Note: if anyone has to tell you how good of a developer they are, then they usually aren’t much of a developer at all.

It all rang true the other day when we were about to deploy a new app into production that our teams jointly built and I let Rico look at the outstanding bug list.  He froze in his footsteps… jaw dropped… eyes went wide… (ok, you get the picture) and said in what was almost a freaked-out tone, “do we really have bugs”?

Of course, I thought he was joking so I laughed at him.  Soon I realized that he actually thought all large apps went into production absolutely perfect.  I mean without even a single minor bug/issue or missed requirement.  Obviously, I’m not advocating we ship shit, but come on; nothing is 100% perfect.

So, I started to explain this concept to him and I quickly realized that if we needed to have this conversation, then I really didn’t want to have this conversation.  I politely (as that’s Rico’s style) wrapped up the conversation and gave him some “we’re all good” affirmations so that he could keep up his overly confident manager style and be on his way.

I guess the moral of this story is to spot the Rico’s in your organization.  It’s not that you can ignore them or conversely, need to spend a ton of time with them.  It is that you simply need to know their kind and learn how to use them to your benefit.  Heck, I use my personal Rico whenever the bureaucracy of a big organization is overwhelming as he eats that stuff up.  I also use him to help out with those extra management duties like move coordinator and “fitness in the workplace” advocate.

Good luck identifying your Rico’s and finding “appropriate” work for them to do in your world!

Don’t dip your pen in the company inkwell (seriously… don’t do it)

Well… most of us in the software development field already know it — we are a heavily male dominated culture.  The percentages are against us and many, dare I say most, of our peers are men.  It is so bad at the jobs I’ve worked at over the years that I created a whole new ranking for women, “IT Hot”, which simply means that an average looking woman that is an island in a sea of (mostly geeky!) fellas takes on a whole new level of attractiveness.

Of course, if I’m fair I’d look at it from the woman’s point of view.  It is probably like living in remote Alaska where the ratio is about the same and the women have a funny saying — “The Odds are Good, but the Goods are Odd”.

So where am I going with the rambling?  I’m heading to the tag line for this post, don’t dip your pen in the company inkwell, which simply means to go out of your way to avoid intimate relationships in the workplace.  And if you are the CEO of the largest tech companies in the (can you say Mark Hurd at the wheel of HP) you surely don’t need to do this.  At this point, it doesn’t matter where you stand on Hurd’s firing (I mean “resignation”)  as it is done and it can happen to anyone.

To wrap it up, no deep philosophical lesson here.  Just keep it clean and keep your job!!

Don’t panic when something wicked your way comes (pull together a plan to make it better)

So, Joe-bob is at it again.  His team recently took on support of an existing app.  Atlas is not just an existing app, but one that has been passed around like a hot potato.  Every developer who has touched Atlas is now the CIO — I don’t mean Chief Information Officer, but CAREER IS OVER!  Why did Joe-bob get this app?  Because he’s still fresh meat and he actually thought he was doing a little “empire building” when he said “sure… I’ll take it”.  It was kind of like watching that old Life cereal commercial; “give it to Mikey, he likes it!“

Ok… it probably isn’t fair to Joe-bob stating that he solely did this to himself.  There actually was some sophisticated “empire building” going on from Joe-bob’s boss, the dreaded Alpha Wolf Ken.  Ken’s a real jerk and everybody HATES him, but I can save some of those stories for another time.  Ken was the real mastermind behind Job-bob’s taking on Atlas.  Ken is just devilous enough to let Joe-bob think he did this to himself so that he doesn’t blame Ken for it.  Ken further wins as he has more headcount and we all know that is all that matters.  *wink!

Oh, did I say Atlas deserves its reputation.  Well it does, but it surely isn’t the end of the world.  Besides, one should very carefully consider the quick impulse to just want to rewrite an app.  Any app!  I always cringe when people jump on that bandwagon.  Everyone is quick to trade in a known set of problems for a completely new set of them.  That may be the right answer, but it can’t be without some careful consideration and analysis.

Job-bob, being the good engineer (and not so good manager) that he is, decided the best way to solve the problem was to public denounce his new pride & joy, Atlas.  “It’s bad, I know it is and we shouldn’t have to deal with it”, he declares.  “We’ll make a better one, that’s what we’ll do”, he proclaims.  Problem is that we’ve got a lot of skin invested in that app and even if he’s right you just can’t put yourself in that kind of bind and go on the record that way.

What should Joe-bob do in this difficult situation?  Here’s some definite possible next steps:

1. Learn the darn thing — it might not be that bad.
2. Support it well — it will only make you and your team’s life better.
3. Don’t declare it obsolete without a very clear plan of where you’re going and how/when you (and the system’s users!!) will get there — nobody likes a whiner; especially one without a plan.

Again, the key is to formulate a plan.  You know… “manage”…  As with everything else, it sure makes it easier if you can answer the “what the heck were you thinking” question.

Good luck Joe-bob!  I want to see this work out well, but please stop scaring all of us — remember, I’m a user of Atlas, too!