Why it’s not my fault, why it is, and why it doesn’t matter

When things go bad, people have a tendency to want to blame folks. It is a bad habit, but people do it anyway.

When I was much younger, I had trouble shouldering responsibility. When things went wrong, I didn’t want to take the blame. I tried to think of a million excuses. I was convinced that there were always multitudes of factors (to blame), which were out-of-my-control. Nothing was ever my fault. Unfortunately, it undermined other people’s trust in me, and stifled my ability to grow.

Now that I’m much older and wiser, I don’t mind shouldering the blame for stuff.  Even if something wasn’t my fault, I’ll take it.  Go ahead.  This is because I’ve come to the realization that blaming a person is value-less.  What really matters is results.

This all started with some advice from a mentor of mine: “Don’t blame a person. It doesn’t fix anything. You can’t fix a person or expect to find/make perfect people. Instead, create processes to insulate against mistakes.” When you do that, it takes the blame off-of people and makes it easier to focus on the root-cause and solution.

Also, I’ve found that responsible people are much more supportive of resolving a problem, especially if they don’t have to spend arbitrary amounts of time resolving blame & defending against accusations.

When “blaming a process” doesn’t work

I’ve talked about this concept with nearly every manager and leader that I’ve worked-with.  It didn’t take long before I found someone who didn’t like the idea of [blaming a process instead of a person]. Here is why: Imagine that I was the guy who came up with the process, or worse: maybe I’m the guy in-charge and I don’t have a process at all. I am probably going to feel responsible for the process and therefore, when you blame the process, I might feel like I am being blamed. Right? Like, I’m the idiot who didn’t come-up-with a flawless process. So I guess everything must be my fault.

The root-cause of this debacle is 1) people still focusing on blaming people and 2) the impression that the process is owned by one person rather than the entire group, and maybe 3) the fallacy that a process could be perfect and therefore would never need any adjustments, ever.

A more sustainable approach would be to drop these three problems. Try the opposites: 1) Insist that a problem is the result of flawed processes. 2) A process is owned by everyone (not the opposite!  People are not owned by the process). 3) The process will never be perfect. Therefore, you must nurture it:  review, revise and improve it regularly.


When you stick with this, then it really doesn’t matter if the next problem is your fault or someone else. Let’s just review our process, and fix it. Of course perfection is nice, but it is probably unrealistic. It is better to have a means to fix problems quickly and reliably. Let the people focus on doing their jobs.

Posted in IT Psychology, Lessons Learned, Professionalism | Tagged , , , | Leave a comment

Why your projects don’t seem to get “done” (part 3)

Okay, so let’s say that you are a shrewd manager, and you are certain that your requirements are crystal-clear, your scope is contained, and yet, stuff isn’t getting “done”. In that case, part 1 & part 2 (of this article) clearly have been satisfied. “That ain’t it”. So, let’s have a look at some other common culprits and consider their efficacy.

These are fairly unlikely reasons that a program isn’t getting done.  I’m serious. This probably isn’t your “cause” (below). However, I have seen these things contribute to a “not-getting-done” condition.  Once again, just for the record: you probably cannot fix these (below) until the rest of your dev process and scope are well-defined. If you are certain, then please read-on.

  • Perhaps the developers are worried about their next paycheck. So maybe they are stretching the tasks, or sand-bagging.
    Analysis: I don’t believe it, because nearly every programmer is constantly hounded by job offers. When a programmer completes a project, it just means replying to a few emails, interviewing, then packing your gear and unpacking it the next day. Not very scary.
  • Perhaps the developers are not productive for 8 hours per day.
    Analysis: Usually, this is caused by meetings, or deliberating over timelines and requirements. Developers are not naturally chatty-cathys. They only do this if they are bored, waiting, or stressed.  Figure out which one, and address that problem.
  • Perhaps the developers don’t seem to take this very seriously, or they lack a sense-of-urgency. Analysis: This is a common management problem. Perhaps the current approach is not working. Try an approach which is more likely to work with smart people. Hint: threats or anger will reduce productivity. Carrot vs whip strategy time.  (Think carrot)
  • Perhaps one or more of the developers are in-over-their-heads.
    Analysis: If your top technical person is used to being a hero, it might be really hard for his ego to relinquish control over a problem.  Put on your “counselor” hat and help this person make the right choice.  Make it easy to gracefully get the help needed.

The strategy here, is similar to finding a leak in a bicycle tire.  Find out how others (successfully) find the problem, apply some scrutiny and be thorough, (and try not to make things worse).

Isolate the work tasks per-person, break it down into smaller (measurable) pieces, track the work, ask questions.  Try not to assign blame, but rather, ask about other resources that could be used to move the project forward.   See who is making progress (checking items off of the list).  Focus the team on solving the current situation instead of blaming a culprit.

When you find the leak, you can usually shuffle things (tasks or people) around and things will start moving again.  Don’t forget to consider a root-cause.  If you find one, and treat it, maybe you won’t have to repeat this too-often.


Posted in IT Psychology, Lessons Learned, Methodology, Professionalism, Team | Tagged , , , , | Leave a comment

Why your projects don’t seem to get “done” (part 2)

In part 1, I talked about the things that typically stand in-the-way of your project getting done.  If your project had one of these problems, the simple solution is to close the scope of all tasks and if any of your tasks could not be completed in the next 2 weeks, cut them from scope.  Yes, I actually said that.  Let me explain what is going on.

It might seem hard to imagine implementing my advice.  This is probably because your root problem, might be that you are thinking of your project as “one project” instead of [phase one,  two, and more phases, depending on how it goes]. This concept is pretty hard to pitch to management: a project with more than one phase. Management may give you feedback like “we are not paying for multiple phases, get it done in one shot”. This is like the guy who wanted his pizza cut into four slices because he couldn’t eat ten slices. Think about that logic for a second.

Scope & scope-creep

Let’s say that you have a thousand people, and your job is to get them to the other-side-of-town, but you only have one bus. Can you do it? Yes, of course. The solution does not involve cramming everyone into the bus, or attaching a long rope and 950 pairs of roller-skates. You need to take several trips. This means some people will arrive earlier and some later. The key is to get everyone to accept that they cannot be first. This is exactly the case with scope-creep. People are already thinking of improvements to the app, before it is done, and since those features are super-cool, it is hard to imagine postponing them. However, each release of your app is a bus (trip). There are only so-many seats.  Don’t allow the whole thing to be late because of a half-dozen (or-so) features, that just couldn’t wait.

Back to the bus metaphor:  You still have to make a choice of whether all features are the same or if some are more important.  If you decide that some are more important, then you will experience the joy of asking the less-important features to give-up their seats, so the more-important ones don’t have to wait.  It is just as awkward for features, as it is for people.  I’ve seen it turn into a real mess, because everybody (and their ideas) wants to be #1, and it becomes “personal” really fast.  If you are super-smooth and politic’ky, you can probably work it out without too many bruised feelings.  However, if you are not a born-politician, you are better-off treating everything the same, or picking features out of a hat, or something arbitrary, and leaving it like that.

Please keep this axiom in-mind: There will always be something that doesn’t fit. Count on it.  Make a place for that stuff. Give it a cool name like “the out-of-scope bucket”, and give yourself a daily goal to put something in there every day (or week, etc).  Rome wasn’t built in a day and neither will your app.  Push some stuff out-of-scope, finish your current work, deploy, and re-evaluate your remaining work.  Done.  Next?

Posted in Lessons Learned | Tagged , , | Leave a comment

Why your projects don’t seem to get “done” (part 1)

In my career, I’ve seen a few projects that had a problem getting “done”. Okay, I was being too nice. Let’s just say: it happens more-often than I think it should. I’ve even had a CIO mock me because I asked him to clarify what he meant by “done”. He actually didn’t know, but he did know that it is easier to blame the programmers, than to define “done”.

When your team is not crystal-clear about the meaning of “done”, you are bound to have trouble getting there.

Even if you have a clear idea of what “done” means, you still might have trouble getting there. Nearly every programmer can tell tales about this sort of thing.

Easy, but wrong solutions

First, let’s look at common treatments, which are NOT surefire ways of getting to “done”. I’m sure nearly everyone has tried these (at some point) and was disappointed to find that they didn’t work:

  • Working more hours
  • Being more motivated
  • Meetings
  • Management getting more intense and scrutinizing everyone
  • Blaming people

I know you must be aghast that this list doesn’t work. After-all, it seems to be the “top 5” list for a lot of people. Right?

It is especially frustrating when the boss tries some (or all) of the items on this list and it doesn’t fix things. So the boss just keeps trying them with more intensity. “Use a bigger hammer”, I guess.

In case you didn’t already guess, the reason these don’t work is because they don’t address the root cause. It is like bailing water from the titanic, or throwing water on a grease fire.

Root causes

There is a very short list of things that prevent you from getting to “done”. Which is good, because you just need to identify which one(s) is/are the cause and then focus on fixing it. Once you fix the cause. The path to “done” will be very clear and you can get to “done” pretty quickly. Look for these problems:

  • You don’t have a clear definition of “done”: i.e. a checklist of features, and tasks which must be completed. Your list must be specific & clear. When you have that, you can work the list until every item is checked. Management can track it. Timelines become predictable.
  • Scope creep: Somebody keeps adding new features or tasks, or the definition of the current tasks seems to change or expand. Perhaps they don’t know the danger of moving the finish-line before the current race is finished.
  • The 90/10 rule states: your first 90% of the work will take 90% of your timeline, and the remaining 10% of the work will take another 90% of time. This happens when you leave the hard work (eg. unsolvable, insurmountable) till the end. If you have done that, then you are facing some bad stuff. If you don’t own a time-machine (to start your project correctly), then you can recover by turning all of your focus to the hardest stuff. Consider renting a ninja to help.
  • You have been programming, but don’t have all of your requirements yet. Probably this is another form of [lacks clear-definition of “done”]+[Scope creep]. Double-whammy!

The answer to all of these is: close the scope of your work right now. If you have any features which cannot be completed in the next two weeks, then push those features out of scope and finish what you already have. You will probably encounter some friction, but if you thoroughly control your scope (and clearly define it), your timeline problems will completely change and “done” will become clear and achievable. If none of your features are clearly-defined, then you need to direct enough attention to that fact. It will help to justify your actions, so you can divert all of your focus to “clearly defining your features”.

In part 2, I will discuss scope containment, and some philosophies about it.

Posted in Lessons Learned, Requirements | Tagged , | 1 Comment

Why you don’t need college, and why you do

Back 100 years ago, books were super-expensive. Think about the availability of paper, printing, and means to distribute books. Plus think about supply/demand. How many people needed a history book or calculus book. 100 years ago, people were mostly concerned with how to get food and make clothes and retain their teeth. Calculus and sociology were topics discussed by people who had enough money that they didn’t have to worry. 100 years ago, you really needed universities, because it was really hard to find information. You needed hubs for knowledge and a place to store all of those expensive books, and you needed a place for rich people to hang out and discuss calculus and sociology.

Modern day, you can get onto amazon and download a book about nearly anything, or find dozens of youtube videos about nearly any topic. Acquiring knowledge has become pretty easy and cheap. So, this starts to beg the question of why we still need college degrees, when the actual cost of getting information (educated) is so low, but the price tag is disproportionately high.

There are actually a few things that you get from a college/university. An education is only one of those.

Work-ethic – The most prestigious universities are usually the most difficult to get into. It isn’t even about money. The best universities require people who are super-smart, outgoing, community leaders, sports stars who play instruments and act. Whew. This is because the best universities have brutal curriculums and only “the best” will be capable of succeeding. If you get a degree from one of those places, any-company would hire you. It is because you have proven that you are super-smart and work hard-enough to succeed at a broad spectrum of topics. On the other hand, if you have a piece of paper that says you graduated from University of Someplace-nobody’s-heard-of: meh, not very impressive. Probably anybody could do that.

Meet-market – Let’s say you came from a family with money. After college, you will take-over the family business(es) and maybe start a few of your own. You will need to know a few engineers, lawyers, accountants, marketing folks, etc. You could google it or something, but you would feel much better if you could hire people who you know. Now suppose if you went to school with them for four years: you would have a pretty good idea of who works hard and who doesn’t. Maybe you would even like to find a spouse who has a similar background, wealth, goals as you. College is a good place to find those people.

Broadening your horizons – Colleges will make you take a bunch of classes that have nothing to do with your degree or interests. This is because it helps you achieve your first two goals (hard work, meet people) and to introduce you to other topics that you otherwise would have avoided. For instance, maybe you were born-for particle physics, Mesopotamian history and underwater-basket-weaving, but never thought to try those up-to-now. Also, once you know about sociology and science and physics, you won’t look or feel as stupid when you go to a dinner party (or company party) and people are talking about stuff that you don’t do. You will have a basic understanding, and you will have a foundation on-which to build, if you ever feel so-inclined.

There you have it. College. It is not just a piece of paper and it is not just an education. It is people, connections and growth. One last caveat: you really get-out of it, what you put into it. If you try to “just get through it”, without immersing yourself in the experience, then you are not getting the full value of what you pay-for.

Posted in Career, Education, Personal, Professionalism | Tagged , , | Leave a comment

Why you need a little technical debt

Ever since I was a kid, I always wanted a corvette. They are just cool, and I want one more than anything in the world.

Okay, that seemed a little over-dramatic. Clearly that is not true, because I have a house, and kids, and lots of cool stuff, but no-corvette. If a corvette was the most important thing in the world (to me) I would just buy it and deal-with the debt and insurance costs, etc. For me, I think I already have enough financial obligations. A corvette just doesn’t fit in there. It would be irresponsible of me to buy a corvette. So, I have learned to live without it. It is the right thing to do.

Technical Credit Check

Let’s say your company/department wants a custom program or a revision to an existing program. You probably want it now, or sooner. If you ask some developers to estimate how long it will take, they will probably give you an estimate that is bigger or later than you hoped. You might pressure them to give you a better estimate. If they do, you take it and don’t ask questions.

Right now, you probably feel pretty cool, because you are a shrewd business person and you negotiated a great deal for yourself. The programmers will have to be highly-efficient to meet your demands. Ha! You win. Sort-of. For-now.

The problem is that there is a pressure situation for the programmers now. The only way to resolve it is 1) programmers need to donate time (money) to you, or 2) they have to cut some corners to make the timeline. Maybe both. If you are not a programmer, will you be able to tell which one happened?

Maybe you think you will have some good testers and they will find the cut-corners. Nobody will sneak one past you. However, the easiest corners to cut are the ones called “quality”. Low code-quality is exactly what people mean when they talk about “technical debt”. Your testers are not going to find something that they cannot see or touch. The person(s) who will see/touch it, will be the next set of programmers who will maintain the app/system.

So back to my statement, that you need some technical debt. Well it comes down to this: Nobody has time to implement every feature as nicely as you would actually like. We all need to live with deadlines and we all need to constantly raise the bar for ourselves. This means that there needs to be some give-and-take. Accept something less-than perfect and then work-on improving it. This is why you should expect to acquire some technical debt. You also should plan to resolve it regularly. This is economics and it is reasonable. Count on it. Plan on it.

You may think that allowing for (or accumulating) technical debt, is a very dangerous proposition. You are correct. It is akin to accumulating financial debt. If you don’t deal with it, you will find yourself in financial peril. If it ever “gets away from you”. It is extremely difficult to come back from it. (read about technical bankruptcy).

The key to managing technical debt is awareness from management. Once they are aware of technical debt and the risks associated with it, you can have the discussion about managing that tech debt. Like with financial debt, if you don’t have the money for a Corvette, you don’t wait and save up until you can pay cash for a Corvette. No, that will take forever. You borrow, and pay it off. Software development is the same principal.

Posted in Programming | Tagged , , , | Leave a comment

Triage: picking your battles vs being lazy

A few years back, I joined a team that had a lot of problems. I mean A LOT of problems. To give you an idea: the team wasn’t even fixing the problems. They retreated to the point of documenting “the order in which to reboot servers, when things crashed”. Their stuff actually broke that often, and they felt it was the best solution they could offer. I was brought onto the team to pull them out of the well that they had fallen into.

For the first week, I observed how support was handling things. Each morning I would report to my boss about the top issues that I faced yesterday, and which ones I fixed. After a few weeks, I managed to fix a pretty popular complaint and my morning report was pretty upbeat, “Yesterday, I deployed a fix which should resolve the top two bugs in prod”. The head of support asked if that meant all of the bugs were fixed in that system. I told her that there were still a few bugs in there, but for now, I was avoiding their gaze. Everyone in the meeting got quiet and seemed perplexed about my statement. It took me a second to remember, there is a homonym for “gaze”. I continued, “You know, like vampires! If you look them in the eyes, then they got you, and you have to deal with them”. Half of the people understood and I guess the other half thought I was avoiding gay vampire bugs or something. So I reworded my response, “It is good enough for now”.

The head of support was not satisfied by this and said something implying that I was being lazy or doing a half-job or something. I felt like it was out-of-line, because I just squelched the top two issues for the project and she was disappointed that I didn’t build Rome in a day. It hit a nerve, but whenever someone questions my integrity, I always give it some consideration. I know I have an ego and sometimes I need to confirm that my ego is not driving my decisions. Nope. This time, it was a business decision.

Too much work
When I get some work to do, I get in there and just knock it out. When I get too much work to do, I start by prioritizing what needs to be done first and which can wait. However, when I am avalanched by an unmanageable amount of work, I know that I need to keep my head together and make some important strategic choices. My great mentor, Robert Baldyga taught me this crucial lesson:
When everything catches on fire and people are screaming at you to fix it NOW, you need to do the following:

    1. Don’t succumb to the chaos or panic. People are counting on you to keep a clear mind and make good decisions. Bad decisions will waste your precious time or make things worse. So make sure you know the difference between a bad decision and a good one. Take a second to make sure, before you act.
    2. Before you make any changes, make sure you can undo them.
    3. Before you start making changes, understand the problem.
    4. If you don’t have enough information to understand the problem, then your first priority must be to gather the information to understand the problem.

Of course, there are plenty of things you can do before a problem occurs, to make it easier to isolate the cause. However, if you are fixing someone else’s problem, then you are on your own. It is really hard to put a timeline or ETA on the fix. You simply have to do your best to get things headed in the right direction and chip-away at the problem until it is all-done.

My boss (at this place) understood what I was doing and was satisfied with my strategy and progress. Eventually, I was able to resolve all of the problems and take the pressure off of the support team. Of course, it messed up all that documentation about “what order to reboot the servers”, because you didn’t need to reboot stuff anymore. That was a whole different battle to pick, and another story for another day.

Posted in Professionalism | Tagged | Leave a comment