I Never Wanted to be a Manager

Innovating  Innovation

Copyright Steve Jurvetson (Creative Commons)

I remember when I was younger, sitting around the campfire with friends, roasting marshmallows for smores, and exclaiming loudly: “When I grow up I want to be a Manager.”  They all looked at me with wonder in their eyes: a Manager.  I had the audacity to want to become a Manager.

Ah, I can tell that you scoff at me.  You are ridiculing me for my desire to become a Manager.  To have my name extolled with the likes of Fred Seabrim, Joachim Soleonus and Archibald Jacobson.  Managers that have stood tall against the test of time and have never wavered in their undying commitment to manage things.

Not wishing to push people away because of my grandiose dreams I scaled back and instead dreamt of becoming a programmer, a developer, someone who would shape applications to become the tools for future growth.  I never saw the writing on the wall until the chalk board hit me in the head.  Developers don’t create applications, managers build them with developers just writing the code that creates the management vision.  A developer is a tool whereas the manager is the brain behind the tool.

Management is where all the cool things happen.  Where meetings are held to determine the course of the project, the company, indeed, the world.  Who gets invited to meetings?  Managers.  Who makes the decisions in meetings?  Managers.  Who is able to grasp the idea of client disengagement due to poor client experience and instantly come up with the idea that what we need is an app?

What better way to understand the organic processes happening within an organization than to become part of those processes themselves?  Imagine how much more a microbiologist could learn if they could make themselves as small as a microbe and follow it around, asking questions and generally learning about the microbe from the perspective of the microbe.

Managers.  Is there anything better?


NaNoWriMo

When I started the National Novel Writing Month contest I wasn’t sure what to expect.  After all, I didn’t have a story in mind, no plot had immediately come forth pleading that it needed to be written, and most importantly, I didn’t have the foggiest idea if I could do it.

Well, I am a ways into it now and I must say that the pep talks they gave on the site were correct:  the story does have a tendency of writing itself.  With only the opening sentence to work with the story slowly started to evolve and grow.  Characters started coming together, pasts started being revealed and the tone of the story started to come out.  (Now if only I could figure out some way of making these notes count towards my word total.)

It was really strange because, in many ways, that’s how I’ve always done my programming as well.  To be honest, I was never one for getting all of the requirements together before building the application.  I would start with the framework and start building the rest of the application in pieces.  Sometimes this caused me no end of trouble because I had built the framework in such a manner as to cause endless rewrites due to a specific requirement.  I learned, however, and I developed better frameworks.  I learned to "steal" code from the best of the applications and re-use it where necessary.  In essence, I started with the barest of bones and built up the application in stages, much like what is happening with the novel.

Some might call it eXtreme Programming, while others might just lump it in with the generic term Agile Development.  All I can say is that it worked for me.  It does not work for everyone.  Indeed, the vast majority of people cannot do it this way because of the unknowns and the, to be honest, the fear of failure.  I’ve failed at so many things in my life that failing at writing a computer program, something I love doing, just never crossed my mind.

Managers and team leads need to understand that there is not just one type of developer.  You can’t go to the store and pick up a box of Generic Developers (now with Vitamin B12) and have them substitute for your Toasty O Developers,  Supervisors, leaders of people, need to understand that there is a wide range of people and that some people, very few, can be left on their own to build the application.  Indeed, interfering with that development process is sometimes more harmful than letting them run loose.

Does this mean that you have an entire team of highly motivated, highly charged, highly independent developers at your disposal?  No, you don’t.  The key is finding those that are and nurturing their growth.  Studies have been done with regard to programmer productivity, and anecdotal evidence abounds with stories of Software Heroes.  Suffice to say that they are relatively rare, so the odds of finding more than one or two on your staff is unlikely.  Which in some ways is a relief.

 

P.S.  For those that want to know, the opening sentence is:

The screaming didn’t start when the lights went out; it only started when the first body hit the floor.

Antacids for the PM

PMs, can you imagine the look on the faces of those developers when I said that they needed to supply you with things like estimates and time sheets?  I bet some of them were knocked off their feet!

I mean it’s not like you were asking them for anything difficult.  I mean, how hard can it be to create an estimate for a project?  It’s not like it’s rocket science.  Every developer should be able to do it.  I mean, the National Gun Registry hit it’s target.  Well, maybe it didn’t.  Well, what about the Denver luggage handling system?  Another fiasco?  OK, the FBIs Trilogy Project, now that was … a disaster?

Everybody can look into the past and come up with failed estimate, but sometimes, the Project Manager does it to themselves.  This may be a shock for some of you, but sometimes Project Managers are under different pressures than you realize.  Back when I was younger I worked for a consulting company.  My job was to come up with the technical work plan and estimates for the projects the local office undertook.  I would then, using historical data and some darn fine guessing, come up with what the effort would be on the technical staff for the project (technical staff meaning project DBA and internal technical support). 

One of my proudest, and saddest, estimating moments came for a relatively simple business project that had a number of interesting technical complexities.  My estimate of the technical cost was 179 days.  When combined with the other parts of the project it turned out that this simple application was going to cost the client a lot of money.  In an effort to reduce the impact tot he client the scope was shuffled, but this did not reduce the technical effort that needed to be spent, so in a classic PM moment the number of days was arbitrarily reduced to 79.  I am proud/sad to say that this is one of the few times in my life where I was dead on with regard to the effort.

Project Managers, if your team says that something is going to take a certain amount of time, ask them questions, make sure they understand both the problem and their own estimate, but don’t arbitrarily change it unless you know for a fact it can be done for less.  The odds are they understand what needs to be done better than you and by changing their estimate you are telling them that you don’t trust them.  If you still feel the estimate is high, have them sit down with you and walk you through the estimating process they used.  But, if the numbers still add up to something you don’t like, take a tums.

Microwaves and IT

I was trying to follow the instructions on the back of the box the other day when I cam to a part that had me stumped.  It said that in order to defrost the item I held in my hands I needed to set the power to low and put it in the microwave for 2 1/2 minutes.  Now, I consider myself to be reasonably intelligent (some may not agree with that statement) and I consider myself to be somewhat of a technology geek.  I like silly, geeky things, but, darn it, I can’t defrost anything in our microwave!!!!

Now, thinking just like the instructions, I set the power to low and then tried to enter a time, but for some reason I was entering in the time for “Step 2” of the overall process instead of Step 1.  So, I hit the “Defrost” button and was asked to enter in the weight of the object in kilograms.  Tossing it up and down like the frozen pork sandwich from Costco that it was, I guessed at about 0.1 KG.  I tossed it in the microwave and crossed my fingers.  I came close but it was probably about 0.15 KG, which I couldn’t enter as it expected only a single digit after the decimal point.  (By the way, the correct method was to enter in the time, then enter in the power setting.  I had this epiphany on the bus on the way to work this morning.)

We sometimes build applications the same way that manufacturers build their interfaces.  it makes perfect sense to one or two people, or even the “study group” that looked at the interface, but when you give it to someone that has never seen it before, has never been part of the privileged few that saw the development process, the interface sucks.  Sorry for the bad news, but interfaces made by geeks are … well, geeky.  They make sense to geeks, some of them,  but honestly don’t make sense to anyone else. 

You see this in many applications and still see it today.  I was looking for an application to catalog by DVD collection using information sucked out of the Amazon.com database.  I found half a dozen applications, but they all looked like they were put together by Picasso.  I then found an application that looked like it was put together very well.  They had the complete package from the functionality that I wanted to a simple, pleasing user interface.

Project Managers, don’t trust developers when it comes to user interfaces.  Look at the designs yourself and see if they make sense.  if you can’t figure out how to do something, get it redone as someone totally unfamiliar with the project is going to be completely lost.  If the response is “the user wants it this way” then this really means that there are too many geeks trying to cook and it might be time to bring in a professional designer to help you out.

Innovation on Demand

I know this is going to bring up painful memories, but it will soon be over.  Imagine that you’re at a meeting where you are discussing some project related issues and potential solutions.  Suddenly your manager says to you, “So, now that you’ve heard the problems, what’s your solution?”  Your mind goes blank as you try to think of a solution to a problem that you’ve never really analyzed before.  You start breathing quickly and shallowly as your heart hammers away at 200 beats per minute and the adrenaline flowing through your system makes you acutely aware of everyone looking at you.  Looking at you with both sympathy and glee, thankful that they were not chosen. 

I am confident that 99% of you have been through this.  The 1% that hasn’t been through this  just graduated and hasn’t had the opportunity that the rest of us have had.

It is widely thought amongst management types that geeks can innovate on demand.  (Boy is that statement going to get me a lot of email.)  This is, however, fundamentally wrong.  Indeed, it is wrong for most people, not just geeks.  In order to proved a good answer to a question the person needs to understand the context in which the question is being made or the issues behind the problem.  By tossing out that one liner about coming up  with a solution with no opportunity to prepare is quite unfair.  The individual in question probably does not have a suitable answer (if they did the answer was so obvious that other people should have realized it) and the added pressure of having to answer this in a more formal meeting environment is going to make the person less likely to come up with a good solution and more likely to come up with a safe solution.

This is not to say that safe solutions cannot also be good solutions, but the odds are that the reason the manager is asking this question is because none of the safe solutions seem particularly attractive.  Managers are traditionally risk adverse which means that they would have looked at the safe solutions already.  Sometimes, however, a Eureka moment arrives and an answer comes to your mind, fully formed and breathing on its own.  The rush, the thrill of coming up with an answer is fantastic.  BUT, don’t expect it.  Expecting it is almost guaranteed to make sure that it is not going to happen.

So, managers, if need to get an answer to a problem in a meeting, don’t single out anyone as that added pressure is probably going to do the exact opposite of what you expect.

So, when is it going to be fixed?

“So, when is it going to be fixed?” Have you ever screamed when someone has said this?

About fifteen years ago the company I was working for had just replaced the biggest application that they used. After a number of months of daily fire fighting the system had begun to stabilize and the number of daily data fixes was down to handful. I came in to work, sat down at my desk and immediately had half a dozen people asking me to help them out. It appears that our application was no longer responding. Literally the eighty percent of the organization that used this application on a daily basis was unable to use the application. Off we went to investigate the problem.

About an hour later, when I was walking down the hallway my boss asked me “So, when is it going to be fixed?” I told her that we didn’t know what the problem was so I couldn’t tell her. She kept pressing me for a time commitment as to when it would be fixed and I kept telling her that when I knew what the problem was I would know how to fix it and I could then tell her when it would be fixed. She kept pressing me, however, until I finally snapped … and just walked away.

There is an important lesson here to both management and the people trying to resolve issues. For management, if the people who know the most, don’t know what the problem is, they cannot tell you when it will be fixed. It’s as simple as that. Come up with an answer that conveys this to your clients because you’re going to be using that same phrase a lot throughout your career. For people trying to resolve the issues, if you don’t know what the problem is, don’t give a time estimate because all you’re doing is lying to them and to yourself. Tell them you don’t know what the problem is. There is no shame in that. You don’t walk into a Doctor’s office and expect him to have an answer right away, so why should they expect you to have the answer?

Project Managers and Bullies: Are They One and the Same?

I hope my tease yesterday kept you on pins and needles. I have had the good fortune to be on a wide number of project teams, some of which had good project managers, some of which had bad project managers and some of which had me. Throughout all of these projects there is a common theme of trying to lead the team. Different PMs had different ideas about how to lead the team with some methods being more effective than others.

One popular method of leading the team is through the use of “It’s my way or the highway”. This is rarely effective as it stifles creativity, leads to aggressive behavious between the team members and the PM and usually causes people to devalue the importance of the PM. (Sometimes it leads to team members calling the PM an “arrogant SOB from Chicago”, but that is another story.)

Another popular method is consensus. Everyone needs to agree on something before it is done. While this may work for some areas, developing IT solutions requires a vision that needs to be followed. If that is the vision of one person or the organization as a whole, there needs to be someone driving the project forward and that is the PM.

An effective PM leads through something I like to call “motivation”. You need to be able to get the team engaged and believing that their part, no matter how small or obscure, is part of the overall picture and is important to the success of the project. And you know what, it is!!! Everything that someone is doing on the team is helping to craft the final product and is important, because if it’s not, why are you doing it? The PM needs to be cheerleader, traffic cop and salesman all rolled into one. Being a bully doesn’t cut it as that devastates the motivation piece and does nothing to engage the project team members.

Are Project Managers bullies? No, but that doesn’t mean they can’t be strong willed and opinionated, just that they know when to apply these features to the tasks at hand.

(Any similarities to people living or dead is purely coincidental, unless you are referring to that arrogant SOB from Chicago in which case …)

Project Managers: Who are they?

My apologies to those people who do the work of a Project Manager but don’t necessarily have the title of Project Manager as I may have unintentionally left you out. In some of my commentaries I refer to a Project Manager (notice the capital letters) but I never actually defined what a Project Manager does or explain that this may be more of an informal role that someone on the project team is playing as opposed to a formal title and list of responsibilities.

In my mind, at least today, as I’m writing this, a Project Manager is a person who guides the team closer to reaching the ultimate goal of creating a working, quality application for a client. This may be something which is being done on a piece meal basis, in which case the Project Manager may be the same person as the developer and designer – a team of one – or it may be something much more complex like a multi-year, multi-phase project where each phase has a Project Manager and the overall implementation has an uber Project Manager called a Programme Manager. In either case the target is the same, although the scope of action may be narrower.

So, why am I bringing this up? I’m reading a book called The Art of Project Management by Scott Berkun and it has a number of nuggets of information that I will probably be sharing with you over the course of the next few weeks. I wanted to make sure that we are all on the same page so that tomorrow, when I talk about “Project Managers and Bullies: Are They One and the Same?”, we all know the type of people I am talking about.

Planning for Change

People have come up to me recently and expressed a concern that I am losing control of my mental faculties. To emphasize this point they point to the fact that I keep talking about “planning” and yet I am also an advocate of Agile Development. The usual comment I get is “In Agile Development, you don’t plan, you just do.”

Ah, the misguided conceptions of youth. Contrary to what people believe, Agile Development does believe in planning, but they are not slaves to the planning process. I once worked for a Programme Manager from Chicago who was quite … stubborn … with regard to his belief that if it isn’t on the project plan you don’t do it. Needless to say we butted heads a number of times, with him always coming out on the winning side because he was the Programme Manager.

This caused a few problems with the client and the application, however, as we were never responding quickly enough to requests. Each time something new came up we had to revise the project plan to take this into account and then confer with the client about the correct project variance that this would cause and sign off on the change request. This process took a number of weeks to complete. We were as agile as a beached whale.

After a while, we figured out how to handle the Programme Manager: insert line items into the plan, that planned for change. Indeed, that is what any agile project should do. Yes, you need to have an overall plan as to what you are going to do and when you are going to do it, but you also need to plan for change. You need to understand that change is natural in a project and you should develop your plan, and work out, in advance, how to deal with change with the client.

Change management is just as important to the development of an application as it is to the ongoing maintenance of an application.

Oh, That’s Easy — Part 2

“Oh, that’s easy.”

As a project manager I hated those words, particularly if they were coming from my technical team. The more technically adept a person is the more inaccurate the person is at coming up with estimates. Yes, there are exceptions, but they are few and far between and should not be counted on at all times.

Someone who is familiar with the technology and lives and breathes the code is someone who is going to be horrible at coming up with estimates for other people. Heck, they are even horrible at coming up with estimates for themselves. I have had the privilege of working with some very talented people over the past 25 years (damn, there’s that age thing again) and with the rare exceptional circumstance, every single one of those people has problems with estimates.

So, how do you compensate? First of all you need to ensure that the developer has thought of everything. Most of the time an estimate only includes the raw time to develop the code, but not to test it, document it and ensure that any technological innovations are compatible with the existing environments. You need to keep track of this persons estimates and use previous estimates in guiding your decision about current estimates.

No, don’t create the estimate for the developer as you probably don’t know the technology. (See yesterday’s note.) Understand, however, that the developer is going to be optimistic about his part of the solution so you need to take his estimate, inflate it, and come up with something that is realistic for the project. And, the most important point of all, keep track of previous estimates and how they matched reality. As mutual funds state “Past performance is not an indication of future results”, but they’re probably darn close.