Stop Hoarding Knowledge

Imagine a manufacturer who starts up a production line knowing that each time a worker reached a certain point in the process she or he would have to walk over to the foreman and ask for a critical piece of raw material. Naturally no company would ever do such a thing and if it did it wouldn’t be around for very long. This process would cripple productivity, dramatically increase the cost to produce each piece and send the time to market through the roof. The company would fail and we’d all agree that with a workflow like that it probably deserved to.

Despite that opinion, we in software development seem to think it’s OK to function under the same asinine workflow. Don’t believe me? Has your team or company ever had to…

  • …delay a deployment
  • …rejigger the development schedule
  • …miss a deadline
  • …lose a customer
  • …call someone in the middle of the night
  • …deal with under-trained staff

…because the only person with the knowledge is somehow unavailable?

In our field of software development we’re justifiably proud of the fact that we make things. We take a jumble of arcane symbols and arrange and assemble them in such a fashion that the end product improves someone’s life in some way. We manufacture tools and toys to fill needs for our customers. Software is our product and programming is our production line. Like any production line we need a stockpile of raw materials. Knowledge is ours, but I’ve yet to see a software team or company which doesn’t fit the ludicrous example I presented above. Each one has at least one person on the team who’s been there forever and knows the entire product inside and out, idiosyncracies and all. Each one has a resistence toward documenting this knowledge, making the raw materials available to everyone on the production line. And each one pays a terrible price in productivity and scalability.

This isn’t the way things have to be. This is the way we allow them to be. We have it within our power to fix this problem and all it takes is documentation and sharing of information.

When asked why a process or fact isn’t documented most teams will answer, “We just don’t have the time.” While, yes, it does take time to write these things up it takes considerably less than the time that’s lost when people are searching for answers. The lack of time is just a convenient cover for the real reasons things don’t get documented:

  1. People don’t understand the value of documentation. We need studies showing how much time and money is wasted chasing down undocumented answers. I’ve little doubt that managers would be aghast at the resources they’re flushing down the loo. Once the managers understand the value they can start communicating it to their departments and making knowledge documentation a priority for everyone on the team. This sort of thing has been done before in our industry. Years ago no one had time to write test suites for their code. Eventually people grew to recognize how invaluable a robust test suite is to a product and started including them in the software development process. The same thing needs to happen for capturing knowledge.
  2. Writing docs isn’t as fun as the other parts of the job. Let’s face the facts: the team would much rather be running the processes than writing about them. Tell folks to write something up in the wiki and they’ll drag their feet and come up with every excuse in the book to avoid it. For most people it’s just not fun. Ya know what else isn’t fun? Getting woken up in the middle of the night because you’re the only one who knows how to restart the webapp properly. Taking a couple hours out on a Friday afternoon to write up tips and instructions on a mission-critical procedure can be a good way to wind down toward the weekend and can help reduce immense amounts of stress later on when someone needs that information.
  3. People want to feel important. You’re it. You’re the one. You know every line of code, every method call, every peculiarity of server setup, every script or tool and all of their undocumented uses and command line options. You are the Most Important Person in the Company. Capturing all that you know and sharing it with everyone would be best for the team but—so you believe—it would drastically reduce your power and influence at the office. Here’s the truth of the matter: You’re a bully and no one really likes you very much. You’re holding your team hostage and they’re right to start resenting it. What you need to recognize is that what makes you important and influential at your job isn’t the knowledge you’ve amassed but the fact that you have the ability to amass it in the first place. Documenting and sharing that knowledge with the team isn’t going to reduce the amount of knowledge; it’s going to free up the time you used to spend answering questions so you can learn and create even more knowledge. It starts a cycle of knowledge generation with you at the center. Congratulations: not only have you made yourself even more important but now people like you. A lot.

There are some ways that managers can help reduce knowledge hoarding on their teams. The first thing they can do is start asking the team to include documentation in their time estimates. This helps show that brain dumps are as much of a priority as test suites. It also removes the excuse of not having the time to write up processes and procedures.

Another thing that can help is including documentation in the build process. If no documentation is found, the build should fail.

Also, managers can and should reward team members who make contributions to the internal documentation. Have a doc-a-thon. Hand out prizes. Do whatever you need to do to show the team that documenting processes and procedures is valued by your organization.

This isn’t something that you’ll be able to do overnight. It’ll take infrastructure, time and commitment. Undoubtedly you’ll fail and have to start again. Maybe more than once. But when you hire someone new and she’s able to hit the ground running and be productive in less than a week because she was able to find her answers in the wiki then you’ll know that all the effort was well spent.

‘Fail’ doesn’t have to be a four-letter word

Projects fail. Companies crash and burn. Screws fall out all the time; the world is an imperfect place. Just because it happens doesn’t mean we can’t do our best to prevent it or—at the very least—to minimize the damage when it does. As a matter of fact, embracing failure can be one of the best things you do for your organization.

First, let’s start with a few extreme examples of how things can go wrong…

A grim roll call

  • Despite warnings from many engineers, the space shuttle Challenger was allowed to launch with a faulty design on its oxygen tanks. The thinking, paraphrased, was “it will only be dangerous in these specific and unlikely circumstances…” Those circumstances, unfortunately, occurred.
  • A stuck valve, a signal light known to be ambiguous and lack of training led to the near meltdown of the TMI-2 cooling tower at Three Mile Island, to date still one of the worst nuclear disasters in history.
  • The Deepwater Horizon oil rig, off the coast of Louisiana, exploded in 2010 due to a number of factors: A cementing procedure was not followed correctly, allowing gas to escape from the well…on a windless day when a man was welding nearby.

Each of these tragedies has something in common: it could have been avoided. In each case there were known problems or procedures which were ignored and in each lives were unnecessarily lost. Each was the result of a compounding of small issues and oversights which unfortunately combined in just the right proportion at just the right (or wrong) time, small issues which were insignificant…until they weren’t.

Most likely lives are not on the line in your business but that doesn’t make your project failures feel any less personally and professionally devastating at times. Like these three tragedies, it’s likely that your failures can also be avoided.

Before suggesting how to avoid project failures, we should take some time to understand some of the factors which lead to them in the first place. There are many reasons why a project might fail, but two of the biggies are Culture and Cognitive Biases.

Cause #1: Culture

Do you like failing? No, nor do I. In general, humans do not like to fail. If things don’t go as expected we tend to get very cranky and sometimes irrational. This is unfortunate as failure is one of the most effective teachers we have.

Many project cultures are openly hostile to failure in any degree. In these cultures, backing or working on a project which doesn’t succeed as forecast can be very unhealthy for one’s career. Mistakes—even honest ones—are punished. This frequently leads to errors and oversights being swept under the carpet rather than being brought to light and addressed promptly. As we’ve seen in the examples above, ignoring the small things can have devastating results.

People in these cultures go to great lengths to avoid association with failure. Frequently, they’ll shelve a new and potentially profitable endeavor rather than take the chance it may fail. This risk aversion stymies innovation and company growth. As well, when a new project is pursued and is not going as planned the people associated with it will not report this underperformance. Doing so is often perceived (at best) as rocking the boat or (at worst) hitching yourself to the failing project. Therefore the project chugs along, devouring company resources, rather than being cut as it should be. All because of a culture which is hostile to failure.

Cause #2: Cognitive Biases

We all come with mental software packages which help us cope with life, allowing us to form judgments and take actions in situations both mundane and exceptional. Usually these work as expected and everything is just fine. But then there is the edge case, where the software doesn’t work quite as it should. This is a cognitive bias, “…a pattern of deviation in judgment that occurs in particular situations, which may sometimes lead to perceptual distortion, inaccurate judgment, illogical interpretation, or what is broadly called irrationality.

While many cognitive biases have been identified, there are four which most commonly contribute to instances of failure. You will all recognize them:

  • Normalization of deviance: The tendency to accept anomalies as normal. “Yeah, we get that error message all the time. Nothing’s ever blown up so we just ignore it now.”
  • Outcome bias: The tendency to focus on the outcome rather than the complex process leading up to it. “Sure, some things went wrong during the code deploy but the product shipped and isn’t that what really matters?”
  • Confirmation bias: The tendency to favor evidence which will support existing beliefs. “No, see, I know Windows would suck for this purpose because I read this article by RMS…”
  • Fundamental attribution error: The tendency to put too much blame for failure on personal rather than situational factors. “We fired the out-sourcers because they were hacks who didn’t know anything.” (Actual: the out-sourcers weren’t given the information and support required for success)


The possible causes for project failure are too varied and unpredictable to be able to avoid them all. However, given what we know it’s possible to minimize the impact and occurence of many potential failures.

First and foremost, it’s necessary to change the project and/or company culture so that it encourages people to report problems, no matter the size. The saying of this is, of course, much easier than the doing. Changing a culture is difficult but, at least in this case, very worthwhile. You can only solve those problems you know. The ones which go unreported end up costing dearly in money, time, effort and team morale.

Any cultural change must have honest and complete support at the highest levels of the organization. An effort like this can only succeed with commitment and leadership. Management must understand why the change is needed and lead by example. Only then will other members of the team feel comfortable enough to pull back the curtain and expose the problems which are holding the organization back.

Leadership should also learn to celebrate rather than blame those who bring errors, problems and failures into the light. Such actions should be seen for what they are: successfully preventing the waste of vital resources. Most people in tech have heard the phrase, “Fail early, fail often.” Few live by those words or reward those who do.

Many organizations will perform a postmortem on a project which has failed. While useful, these processes don’t even show half of the picture. The best way to identify issues which may put future projects at risk is to postmortem all projects, successful or not. Thanks to outcome bias, a near-miss will look like a success and typically will then escape a postmortem scrutiny. This leaves a raft of issues unidentified, ready to appear and compound in future efforts.

But even this won’t help you identify potential problems when you need to. While locating and anaylzing them after they’ve occured is, of course, valuable, wouldn’t it be better to spot them before they become real problems in the first place? Part of the cultural changes which must occur is an organization-wide commitment to spot and report potential problems as quickly as possible. This is more likely to happen if people are asked to use simple and familiar tools to make the reports. Rather than re-invent the wheel or roll out yet another tool for team members to learn, I suggest that the organization’s existing issue tracking system be used for this purpose. After all, while these problems may not be software bugs they are issues which need resolving. Simply create a new database/project/what have you in your issue tracker then open it up to everyone in the organization. It does little good to report issues if people are not able to see them, after all.

Reporting the issues isn’t enough. If people believe that the reports go into a black hole, where they are never viewed let alone addressed, they will stop creating them and you’ll be right back where you started. These issues should be analyzed to determine the root causes for them. When resolving a problem, all too often people will scratch the surface and leave it at that. “This build failed because $team_member didn’t follow the procedure.” That’s not a reason for the problem; that’s a symptom. The true reason is buried somewhere in there. Why did $team_member not follow the procedure? Is the procedure wrong? Was there some exception? Was $team_member getting undue pressure to work faster, causing corners to be cut? Did $team_member not know that the procedure exists or that it should be used in this situation?

The statement, “This build failed because $team_member didn’t follow the procedure” is a presumptive and possibly incorrect placement of blame. As you can see, it is much more likely the case that the system within which $team_member is working is flawed than that this person is incompetent. The urge to point fingers is strong, but a vital part of the cultural change required is to discourage laying blame without doing analysis. Take an hour to speak with everyone involved to figure out the true underlying reasons for the error. Never punish but in the cases of gross negligence or repeated incompetence. Let people know it’s not only OK to make mistakes, it’s entirely natural to the human condition. Not only will you find that people start reporting and addressing issues before they become real problems, you’ll also find that team morale improves as people realize that they’re respected and trusted.

Once you’ve identified the underlying reason(s), make sure to correct and communicate. It does no good to analyze a problem if you’re not going to do something with what you discover. Fix the procedure. Provide additional training. Add a new Nagios warning. Modify the schedule to allow time to do things right. Bring in a specialist. Do whatever needs to be done to be sure the issue never happens again. And, of course, it’s vital that you communicate not only the necessary fixes but why they were necessary in the first place. Team meetings are a good way to do this but don’t forget that issue tracker. Any resolution should be captured here for posterity. Just like adding comments to a complicated piece of code, Future You will be grateful if you document both the problem and its solution.

Other Resources

As I mentioned above, there is a myriad of ways in which a project can fail. This article only starts to address that and some of the things you can do to prevent or minimize damage. If you’re interested in learning more, here are some of the resources I’ve stored up on the subject. Most of them are from HBR, so you may need to pay to access them. You can also probably get them from your local public or university library.

Common Resume Mistakes

I’ve been hiring in the tech industry for the past ten years or so. In that time I’ve looked at hundreds—if not thousands—of resumes from people applying for a variety of positions on my teams. While the positions may differ, the majority of the resumes share the same quality: they stink.

See, here’s the thing: While I’m a hiring manager it’s not the only thing I have to do with my day. There are staff meetings and progress reports and design meetings and scheduling development and any of the myriad of other of tasks which land in the lap of a software engineering manager. By the time I carve out an hour to sift through all of the resumes I’ve received for an open position, the average resume crosses my desk in less than 30 seconds. If you can’t make a good impression in that amount of time then, I’m sorry, but I need to move on. I have too many other constraints on my time.

Therein lies the problem with the average resume: the average part. It doesn’t stand out from the pack. The same words, used in the same way, conveying the same lack of information.

Are you average? No? Then why in the hell is your resume? Let’s fix that…

What follows are tips for how to make your resume stand out from that big, tall stack through which I have to sort every time I have an open req to fill.

  • Don’t get fancy with the design. Unless you’re a graphic designer, please stick with a more traditional formatting for your resume. Anything else is at best jarring for the hiring manager and at worst actively distracting. The most important part of your resume is the content, not the layout. As with any good design, the layout and formatting should take a back seat to the content it supports. It should enhance the content, not be the focus of attention. This means you should probably stick with black on white and use minimal (or no) images. In truth, this will probably help to get your resume more noticed than a tightly designed document. Many companies use online job app services now. Those services require you upload a resume file, which they then—for better or worse—scan for keywords. A beautifully designed ‘Shop job of a resume will not parse. No parsing: no keywords. No keywords: no attention for your resume. You don’t get hired.
  • Order by most important/impressive to least. Remember that 30 second skim I mentioned above? When listing out your experience, your resume is more likely to leave an impression in those few moments if you organize it so the most important or impressive bullet points are at the top of each section. This is where my eye is most likely to alight during my skim so logically I’m most likely to pay attention to things I see here.
  • Do not include a picture of yourself. I cannot recommend against this strongly enough. Your resume is not about how you look. It is about what you can do. Including a headshot removes attention from your accomplishments and places it squarely on that photo of you. Furthermore a resume which includes a headshot puts me, as your hiring manager, in an incredibly awkward position. Suddenly I’m opened up to the possibility of accusations of not hiring you because you’re female or overweight or older or younger or have piercings or appear to follow a particular religion or are of a certain ethnicity… Job seeking is hard enough. Don’t cripple your chances by making the hiring manager feel uncomfortable. Instead, use that room on your resume to tell me more about how great you are.
  • Expect to be Googled and make it easy for your reader. Oh, don’t look so surprised. Yes, people who look at your resume will be Googling both you and any company or organization you list on it. If you recognize this and make it easier on them by including URLs to everything then you’ll leave a very good impression on your reader. Also, if you have any pseudonyms by which you’ve done relevant work (for instance, many in the Open Source community may be better known by a handle than the name on their birth certificate), make sure to mention that name somewhere on your resume. I can’t be impressed by your accomplishments if I can’t find them.
  • Stop being cliché. “People person.” “Team player.” “Responsible.” “Motivated.” “Hard worker.” Stop it. Just stop it. None of these phrases mean anything to a hiring manager. Even if they once did, they’ve since been so diluted that they’ve been washed clean of any meaning. Don’t describe yourself with empty adjectives like everyone else does. Do it by listing all the cool things you’ve done.
  • Be specific. Don’t tell me “Managed a project for a large client.” Tell me what you did—specifically—while managing it and just how large that client was. Tell me what you did and why I should care that you did it. Don’t say, “Organized company events.” That tells me nothing. It could have been a birthday party for a group of five or it could have been the 30th Anniversary Bash for a company of three thousand. Be specific. At no point should your reader be left wondering, “Well, what’s that mean?”
  • Ignore the “only one page” crap. And while we’re on the subject of specificity, don’t leave out details just because you want to keep your resume on a single page. This precept is an archic throwback to the days of analog resumes. Newsflash: we’re digital now. One of the perks of going digital is that no one cares if your resume is more than a page long. Everyone is just going to skim it on their computer or device anyway. Unless someone’s wasteful or inefficient, odds are good that they won’t be printing out your resume until/unless you reach a later stage in the process (like an interview). That said, practice moderation in all things. Just because you now have license to exceed a single page doesn’t mean you need to send a novel. Don’t forget that the hiring manager’s time is at a premium. Don’t waste it. A maximum of a full two pages ought to be plenty of space for you to say what you want without overwhelming the nice person who has to read the thing.
  • Numbers Numbers Numbers. Quantify as much as possible. You didn’t just help land a client. You helped land a $2 million client. You didn’t just improve processes. You streamlined a process which reduced client response time from two days down to four hours, retaining $500K in business and saving an average of $150K in staff costs. This goes hand in hand with the edict to Be Specific. If you currently don’t have numbers then start collecting them.
  • Update early and update often. When I say you should start collecting numbers, I mean you should do it on your resume itself. Most people only update their resumes when they’re about to start a job search, and that’s a mistake. By the time you start editing the file several years could have passed since the last update. That’s several years of memories you now need to dredge. What are the chances you’re going to remember everything you’ve done in that time, let alone numbers associated with your accomplishments? If you answered, “Pretty bad” then you win a gold star. If you want your resume to best reflect your skills and abilities, you should update it frequently to be sure it includes your latest and greatest accomplishments. I have a repeating Remember The Milk task to remind me to update my resume every month (or at least consider doing so).

    Once you hear this tip it’s one of those “duh” moments, but it’s not something most people would usually think of on their own, myself included. I first heard this tip to update your resume regularly from Andy Lester in his excellent book Land the Tech Job You Love. I highly recommend it for all job seekers, technical or otherwise.

  • Save that sucker. You can’t update what you can’t find. Many people end up having to rewrite their entire resume from scratch each time they need to update it because they’ve lost the file for some reason. Do yourself an immense favor: use a version control system for this and all other important files in your life. Version Control: It’s not just for code, dammit. I use and recommend Github for this purpose. Not only is your file safe and backed up, it’s also stored offsite and safe in case of disaster or harddrive crash. Truthfully, what I have is a git repo in a Dropbox directory, so in my case the file is well and truly backed up in several locations.

    Also recommended: if you use Github, shell out the minimal monthly charge for private repositories and use that for your resume. No one wants to get a pull request on their own resume.

Hopefully these tips will help improve the chances of your resume turning heads the next time you’re looking for a new job. Good hunting!

Managers: It is NEVER OK to be a jerk

Earlier today I had a conversation with a friend. She had just been chewed out by her manager. It seems my friend had let a typo slip into some copy. Normally a typo wouldn’t be that big of a deal, but this one was in the price for an item. Customers saw the typo’d price, contacted people to make a purchase and were disappointed to learn that the price was incorrect. They complained to the manager. He took it out on my friend and her coworker. I believe the phrase my friend used was something about being glad she’d managed not to cry when her manager was yelling at them.

From where I stand, there is nothing correct in the way this incident was handled. There is never a good reason to be a jerk. There is never a good reason to bring an employee to the brink of tears. And, because it bears repeating: There is never a good reason to be a jerk.

While I’m not familiar with the intimate details of the situation in question, I’m going to hazard a guess at a healthier, more professional and more productive way to approach it…

  • Be open with your customers. Unless you’ve cornered some freaky market about which the rest of us have no knowledge, your customers are human. If an error is discovered, openly and honestly notify them and apologize for it (even if they haven’t approached you about the error). They will understand that mistakes happen and appreciate you proactively approaching them about it. Odds are they’ll forget about the error or, if they remember it at all, it will be with a positive feeling thanks to how you handled it.
  • Figure out how the error occurred. A harmful typo got into the wild? A product flaw? Site crashed? Complaining about it and attacking people does not fix the problem. Instead, channel your energy and the energy of your team into locating when, where and how the error crept in and how it was allowed to be exposed to the customers. THIS DOES NOT MEAN FIND SOMEONE TO BLAME. By looking to point fingers and assign blame you make everyone uncomfortable and set up barriers to people revealing errors in the future. While, yes, a human made the error that does not mean (s)he is to blame for it. If there is proof that the error was a willful effort by someone to cause damage then, yes, there is blame. But otherwise it’s just what it is: an error. An error which can be prevented. To whit…
  • Set up a process to prevent the error. Even something as “simple” as writing and publishing copy involves a complicated set of processes and procedures. If there is an error then odds are good that the problem is not with the person but with those processes. Fix that so that the error will not happen again.

Mistakes happen. It’s a part of life and therefore a part of business. Embrace them and learn from them. Don’t pillory your people. Don’t be a jerk.