When do I get to be a “trusted partner”?

If I had a nickel for every time I’ve heard someone in IT say something along the lines of “we want to be a trusted partner,” I’d be wealthy. If I had a nickel for every time a business person said it, I’d be broke. Becoming a trusted partner seems to be something that IT is obsessed with, but not so much on the business side.

I do think that being trusted is important, but no matter how much you talk about it, it will never be granted to you. It must be earned. While I can’t tell you how to earn it, I can give you a simple example of how it could be earned.

I’m not an auto mechanic, so I am forced to trust the guy at the mechanics to take care of my car. Because of the information inequality – he knows way more than I do about cars – I am always suspicious of his motives. After all, he is in the position to diagnose my problem and then make money on me by fixing the supposed problem. Here’s a person I inherently distrust. Sort of sounds like IT as well to me…

One day I took my car in because I swore something was wrong with it. I was prepared to pay for new brakes mentally. So, when they put it up on the lift, told me that the brakes were fine and then didn’t charge me, I started to see this shop in a different light. And it wasn’t just once that they didn’t push unnecessary work on me, but several visits. Usually I was just in for an oil change and since I was there I’d ask about something else. Time and time again they probably could have fleeced me and didn’t.

After that, I trusted them to tell me when things were wrong and was more willing to have them done. That’s what establishes trust. It’s not doing as you are asked, even if you do it cheaply. It’s not suggesting all kinds of new and shiny things you could do. It starts by doing something that is truly in the customer’s best interest in a way that they know it is. Sure, a fancy architecture might be in their best interests in a really long run, but your customer isn’t going to sense that.

Save all that for later, when they’re finally listening to you. Start off by demonstrating a willingness to solve their immediate problems, to save them money and time, and to help them avoid unnecessary work and you will have a much better chance of becoming trusted by the business. Continue to pretend you know better and you can just keep talking about becoming one.

Why “spend it like it is your own” is a bad mantra

Recently I’ve been hearing people say fairly frequently “spend it like it’s your own.” The intonation behind this is to not waste the company’s money on things that the company doesn’t need. In other words, if someone gave you a million dollars, do what you would do with it. The foregone (but wrong) conclusion is that you will spend it wisely.

Seriously? If someone gave you an extra million dollars are you the person who would set it aside for your kids’ college, fill up an IRA and make sure you had an adequate rainy day fund? Of would you finally buy that beach house you’ve been dreaming of? The new BMW? The huge TV?

Ok, maybe you would, but what about everyone you know? Is everyone you know that responsible? I doubt it. In fact, I’m willing to bet you know a spendthrift or two, or more. People who have to go on vacation every summer but haven’t fully funded their retirement. People with two new cars but $30k in credit card debt. People with the latest gadget, no matter what it is. People who stand in line for the newest iPhone. In short, people who don’t exhibit any self control. People who can’t discern between ‘need’ and ‘want.’

Even if this person isn’t you, these people exist. They’re not bad people, but they have different priorities. Perhaps you recall the cookie study done on a bunch of children? Essentially, they offered kids the choice of one cookie now, or if they could wait a bit, two cookies later. Guess what, most children couldn’t wait. More surprisingly, as they followed these kids through their lives, the ones who could not delay gratification did less well in life overall (how you measure that, I don’t know.). It’s built in to many of us to desire what we can have now, whether it is the best choice or not. So with that in mind, the mantra “spend it like it is your own” probably deserves reconsideration.

Two kinds of inaction

I was recently thinking about inaction in response to some event. It was brought to mind by some research I was reading on giving managers the choice to not act (wish I could remember where I was reading it.). It turns out that given an A or B choice, managers are more likely to make a decision than if you give them an A, B or “no decision” choice. In the latter, they are more likely to not act. I suppose that’s not entirely surprising, since we likely frame our worlds around the options posed to us and don’t think much beyond that. Want someone to take action, offer them only two paths of action.

As I kept thinking on it, I started to wonder what drove inaction among managers. One possible reason for inaction, and probably the more common one I would guess, is not knowing what to do in response to a situation. You see a project risk, but can’t think of a way to mitigate it, so you don’t.

Then there’s another kind of inaction. You don’t take action because you know to not do anything. That is, you observe something happening that might normally drive someone to take action, but because of additional knowledge you know to do nothing. What you’re seeing might be a statistical blip, or real but already mitigated by existing processes, etc. I don’t think this type of inaction happens often enough. Going back to the original research, we don’t offer the choice of inaction enough, and given how little we seem to know about software development within our organizations, even if given the option of inaction, we don’t know when we should choose it.

Data is exciting to me in two ways. One, it shows when something is abnormal, but it also shows when something isn’t abnormal. Knowing that something is typical is a great way to know not to take action. We see it in our own lives in little ways. When you have a newborn, any little cough or sneeze is likely to cause you to race off to the doctor. After a little bit you begin to learn what is normal vs. abnormal with your kid. Suddenly if they get the sniffles you just tuck them up in a blanket, turn on the TV and let them rest. Knowledge allows you to choose inaction (and save you the cost of a visit to the doctor.)

Inaction is free, presuming you know when to choose it. Using data to help you figure out when not to act is a smart investment.

Entering “project manager mode”

A few of my friends recently told me they were entering “project management mode” as they prepared for the upcoming holiday season. It struck me as funny that anyone could call what they were doing “project management.” It’s not that they lacked a project plan or anything. It is just that entering project management mode would indicate you hadn’t been doing so before, and yet, Christmas comes predictably on December 25th every year! You can’t even call it poor risk management, because it wasn’t like the holiday might not occur. I guess you might condition the probability of the holiday on whether you were going to celebrate it, but the probability of that was exceptionally high, no? After all, you celebrated it all these prior years.

To be fair, I don’t prepare for the holidays very much in advance either, but I also don’t presume to say what I’m doing is managing the holiday. After all, if it was, then I’d start my planning process for the next holiday the day after the prior one ended. Procrastinating for eleven months is a better description than entering project management mode.

Reverse mentoring?

I read a lot of articles.  Mainly because getting new ideas is a big part of my job.  Today I was reading an article that referred to the concept of “reverse mentoring.”  My first reaction was “why would you want to undo someone’s mentoring?”  Apparently what they meant by reverse mentoring was that younger employees were educating senior executives about the use of social media.

So, in some regard I sort of get what they meant.  It’s “reverse” because the typical mentoring relationship is between and older individual to a younger one.  But age really isn’t the issue here.  Experience is.  In the business world, senior managers (who happen to often, but not always, be older) have lots to share with more junior, and typically younger employees.  When the junior person has some area in which they are more experienced, they aren’t “reverse mentoring.”  They’re just mentoring.

Generally, I’d ignore language quirks like this one, but I think it exposes a bigger issue.  We assume that no younger person has anything of value to offer an older person and thus we’re so surprised that we have to coin a term for it – “reverse mentoring.”  It’s just mentoring, and until we come to value what a person has to offer instead of how many battle scars they have, we’ve got a bigger issue on our hands.

OCD or just good management?

I’ll freely admit that I’m a bit obsessive compulsive about things, and I’m sure my wife would laugh at the “a bit” modifier I put on that.  But I was thinking about it this morning as I was driving to an early appointment.  See, I had to get somewhere that I hadn’t been before via roads which could have major traffic backups.  I had no experience with the location or with the traffic patterns.

Think of this as trying to run a software project – a known destination with a known but risk prone path to get there.

How you’d handle this situation grants you insight into what kind of project manager you would be.  If you’re a typical person, you’d plan to leave a few extra minutes just in case.  If you’re a true project manager at heart, you’d go a lot further than that, I believe.

I showered the night before.  It’s not that I didn’t intend to shower in the morning, but I saw a risk.  What if my alarm clock didn’t go off for some reason?  Power outage.  I mis-set it.  Random alarm clock failure.  So, I showered and shaved the night before, full well knowing I might do it again in the morning, but guaranteeing that I would definitely not show up having not showered for 24+ hours and unshaven.  At worst, it’d be 8 hours and a slight 5 o’clock shadow (albeit at 9:00am).  Was I just being crazy?  No, in fact, I had past experiences with my alarm clock not going off (who hasn’t?), so it made sense to actively manage a potential risk.

I laid out my clothes the night before.  What if I selected something with a stain and didn’t notice until the last minute?

I selected a driving route that was slightly longer but more likely to have less variability.  A key to being a good project manager is to minimize variability in the outcome – in my mind it’s better to cost slightly more (slightly being a key word) to prevent the possibility of a major overrun.  In traffic terms, a guaranteed extra 5 minutes of driving is better than the risk of being 45 minutes late.  For the overall organization, if you deliver your project over budget, but someone else delivers under, it all comes out in the wash.  However, you only participate in a limited number of projects, so what comes out in the wash for the organization may not play out so well for you as an individual manager.  If you’re not managing risk, you run the risk of being the person with the over budget project.

Lastly, I got multiple estimates.  I used both Bing and Google maps to look at the route.  Inconsistency in estimates is a warning sign that something isn’t right.  Indeed, they disagreed by nearly 15 minutes, so if you think a few extra minutes buffer is going to get you there on time, you might be in serious trouble if you relied on the wrong site.

In the end, my alarm clock went off just fine and I arrived early… despite encountering construction and rush hour traffic I didn’t know about.  You might say “oh, you’re just being OCD, you would’ve showed up on time anyway.”  Possibly so, but that’s no way to manage risk.  If you don’t do anything to mitigate the things you can control, you won’t survive the things you can’t control.

Your change of mind doesn’t excuse my error

Who doesn’t appreciate dodging a bullet, right?  You know that your project is going wrong – resource issues, a big requirements misunderstanding, a major design flaw… maybe even despite your best project management, proper risk analysis, etc.  Sometimes things go wrong.  In fact, the Standish Group, who publishes the CHAOS report, indicates that as an industry we’ve approached about 70-75% of projects being +/- 10% budget and schedule, and we don’t seem to be getting a lot better than that.

That means, 25-30% of the time, we’re going to miss by a bigger value than that.  At any rate… let’s say your project is going south and there’s nothing you can do to recover.  You’re going to miss your promised date or budget.

Suddenly, the business changes their mind.  Maybe in a way that’s unrelated to the issues you’re having.  Phew!  You breathe a sigh of relief, since you can now use the business’ change to reset dates, including enough time to fix the issue(s) your dealing with and come out smelling like roses.

Not so fast, I say.  Dodging a bullet is great, but if you fail to learn from what would otherwise have been a failure, you’re doing yourself a disservice.

It’s like watching a movie where the only reason the otherwise doomed hero escapes is due to some serendipity.  Sure, it makes for a great movie when a hapless bird flies into the power lines, taking out the power, plunging the enemy into darkness and allowing the hero to sneak off largely unscathed.  But, if that played out in the real world – most of the time the bird would never come along and the hero would be dead.

You can’t count on a random event to save you nearly as often as it happens in the movies.  So, when your potential failure is only alleviated by a lucky turn of events, still take the time to reflect on the failure that could have been and learn from it rather than rejoice it never came to be.

It’s not a recurring issue, until it is one

I know, the title doesn’t make much sense, but let me explain.  When faced with a decision as to whether to fix a defect, we often have to make choices between what to fix.  Limited resources require us to pick and choose, particularly where we haven’t invested in quality historically.

In my ideal world, we’d never get into the situation where we were deciding between whether to fix defect A or defect B, but it happens.  One prioritization mechanism I’ve seen people use is to focus on high-impact and recurring issues.  Here’s the thing, every issue if not permanently addressed will become a recurring issue.  So, if you’re using whether an issue has recurred as the driver of what to fix next, your selection process is totally arbitrary – it just depends on who uses what functionality and reports the next bug as to what you’ll work on.

Instead, focus on potential impact.  Sure, a given bug might be an annoyance to one person, but if it happened to many people would it suddenly become a major problem?  If the answer is yes, the fact that it hasn’t recurred yet should not be the reason you don’t work on it.

Remember, nothing is a recurring issue… until it is.

The cost of everything, but the value of nothing

There’s a programming joke that I heard a long time ago that went something like “LISP programmers know the value of everything but the cost of nothing.”  The point being that LISP was a very powerful language that had basically no capability to use system resources efficiently.  When I used to program and LISP, back in college, this certainly seemed to be true.

However, that’s not what I wanted to write about.  It’s just that the joke popped into mind for some reason, and it made me think about a project failure a long time ago.  About 10 years ago, I used to develop software for a Point-Of-Sale system.  Retailers are notoriously cheap, so while technology had advanced quite a bit, some of the systems in the field were still 386 based processors.  As a result, we had to cater to the lowest common denominator in the field, and for reasons I forget, this meant that we had a fairly slow build process.  It took about 2 hours to build our system to get a distribution ready that could be installed into a test environment.  And then, the install process took another half an hour or more, depending on whether you went to floppy disks, or built a distribution package via the deployment tool.  All in all, it was slow.

If you were a decent developer, you didn’t go through this process too much.  You did all the debugging at your desk and only did the full builds when you were ready to test in the lab environment.  For the most part, we could simulate pretty much everything, but it was helpful to go to the lab for some reasons that aren’t worth getting into.

At any rate, one day, we delivered a package to our QA department and it wouldn’t boot.  That was a very strange event, since we couldn’t recall at time when the entire system simply wouldn’t come up.  After some researching we figured out what had happened.  The build wasn’t good because it wasn’t complete.  And why wasn’t it complete… well, that comes back to the original joke, except in reverse – “the cost of everything, but the value of nothing.”

See, a developer knew full well what the cost of our build process was – 2 1/2 or more hours of time.  They were in a rush, so instead of running the full build, they grabbed the pieces they thought they needed from their desktop, assembled a package and threw it over the wall to QA.  Had it gone well, we’d be none the wiser it happened.  But it didn’t go well.  Because they had circumvented the build process, we ended up with an invalid build, and instead of losing 2 1/2 hours to the build process, we lost almost a full day trying to figure out what was wrong plus the confidence that QA lost in us.

Developers are a lazy lot – after all, we spend our entire lives automating repetitive tasks.  Saving 2 1/2 hours seems like a good deal.  After all, if we could take an easy quarter of a working day off our delivery timeline, it seems like a no-brainer, right?  Well, as it turned out… not right at all.

Process has value in that it prevents errors.  The build process is but one of many processes we partake in.  When all we see is the cost of something, instead of the value it provides, then not doing the activity makes a lot of sense.  Now, by all means, if the costs outweigh the value, that’s an entirely different story.

But as a point of reference, it’s about 25 times more expensive to fix a bug in test than during coding, and about 100 times more expensive to let that same bug to production.  So, when you think you’re saving cost by cutting back, consider the possibility that you’re driving up future costs in exchange for a small savings now.  What’s the value of that?

Simulation works if you can make the intellectual leap

Some time ago I read a study about playing basketball. The study divided players into three teams. One team shot baskets on day one, went home for a few days and came back and shot baskets again. Team two shot baskets on day one, practiced on the court for a few days and shot baskets again. Team three, shot baskets on day one, and then thought about shooting baskets for a few days and shot baskets again.  Not surprisingly, the control (the team who didn’t do anything in between the two tests) didn’t change at all.  What was surprising is that the team who thought about shooting baskets did as well as the team who actually practiced!

Recently, I got to be involved in a simulation of a software development process.  A room full of people was divided up into teams, given roles and told to build a fairly difficult Lego kit.  If you’ve played with Legos before, you’ll know that it can take one person quite a while to build one of these things.  Lots of tiny parts, sometimes the directions are challenging to quite tell what you’re supposed to do, etc.

At any rate, add on top of that a business sponsor who keeps bugging you, status reports to provide, rules about who can touch what (just like a real project, qa people don’t write code), and demands to send some of your development work offshore and you’ve got something that feels and acts much like a real development project in a two hour time frame.

What really interested me wasn’t the exercise, but knowing some of the players of the game, was that they acted in the game like they acted on real projects.  If they were bad project managers in real life, they tended to be bad project managers in the game.  And the teams with the weakest managers got the least far in the game.  In fact, I had a similar experience years ago when we played the same game as a team building exercise.  The individual who struggled the most at work also struggled the most with the game.

In the end, at the report out that always gets done, the same people who struggle with the game struggle to connect it to their real lives.  They don’t see the problem, or dismiss the game as silly and unrealistic, when in fact the reason they struggled with the game is the same reason they struggle in their jobs.

It’s an unfortunate conundrum – those who would benefit most from learning from the game cannot learn from it.  That doesn’t mean these simulations aren’t useful, they’re just useful in a different manner.  As the leader of the organization, what you can learn from watching your employees play games like this is much faster and far less expensive than figuring that out in real life.

Just like the basketball players, those who can do something that isn’t the actual task, but can extend it to the actual task stand to benefit.  Though building Legos isn’t running a project, as a manager you can learn a lot about how your projects are going to go.  Make the most of simulations – those who can learn from the game will transfer knowledge into their daily habits, those who can’t learn from the game will show you that so you can learn about the players.