People naturally make snap judgments on very little evidence. We do it when browsing books and when screening job applicants. Business Technology’s resident U.S. blogger Keil Hubert suggests that it’s in our best interests to give both books and people a fair chance to pitch themselves, since our initial impressions are often skewed.
If there’s one aphorism that every leader should memorize when it comes to evaluating new hires, it’s this: the only real difference separating the heroes and the villains in a story comes from the agenda of the person telling it. That’s as true in job interviews as it is in fiction. If you’re thinking that I’ve gone and lost my mind, consider the strange case of Jake. [1]
Jake and I worked together in a large corporation for a couple of years. He didn’t supervise me and vice versa. We worked close enough that we shared the same coffee machine, and we were friendly enough to occasionally share a lunch table down in the company canteen. Jake wrote code for a living, creating new applications and tweaking application interfaces in order to solve problems that the company’s formal development arm didn’t have time for. I knew enough about Jake’s projects to know that he was probably the most important person on his team. Jake’s bosses depended on him to quietly fix things behind the scenes that they could never get fixed through official channels. That ability made Jake an office hero.
When our branch of the company got laid off, Jake expressed his confidence that we’d all be getting better jobs soon. The fellow was incurably optimistic, and rightfully so – he did snag a new contract in just a couple of weeks, long before he needed to cash his first severance cheque. That made sense to everyone; a person with mad coding skills won’t stay on the bench for long. Before I’d managed to secure a single interview, Jake was already settling in to his new cubicle, just as happy as could be.
After his first day at the new gig, Jake called me to tell me how much he liked his new coworkers. A week later, we met down at our local for a pint and he gushed about how he was stepping into an informal leadership role at the new gig, helping raise morale and increase productivity for his people. He was using techniques that I’d shared with him to help the other developers in his group to gel as a team. He was so happy about his new opportunity that I didn’t have to pay for the drinks.
Flash forward one fiscal quarter, and Jake’s story had changed for the worse. I was on my way home from a client site when Jake called me to let me know that he’d been ‘invited to pursue other career options’ earlier that afternoon. That is, he’d been sacked. He was shocked and angry – and you’d expect – but not surprised. I made arrangements to meet him for dinner so that I could heat the whole story for myself. The first thing he asked me when we met was, ‘How do I explain this to a new employer? How do I explain that I was fired from a job so that they’ll still want to take a chance on me?’
I told him the truth: people live and breathe stories. They understand and respond to interesting tales. You need to tell the truth, I said, but you also need to tell the facts in such a way that your audience understands what happened and (more importantly) why it happened that way. If you don’t provide any context, they your audience assume that you were the bad guy. If, however, you present the context and cast clearly, your listener might believe that you were the hero. Or, at least, heroic.
As an example, I used Larry McMurty’s beloved Western tale Lonesome Dove to make my point. [2] If you summarize that story too tightly, the impression you get is that you won’t like it. A couple of unpleasant rural ne’er-do-wells foolishly embark on a ruinous journey across the Old West. Bad characters + bad decisions = bad outcome, suggesting a bad story. If that were all I had to go off of on the book or DVD cover, I wouldn’t buy it. That’s why Amazon’s review had to provide a bit more context for the story in order for it to appeal to me. They said… wait. Let them tell it:
‘At first the novel seems the kind of anti-mythic, anti-heroic story one might expect: the main protagonists are a drunken and inarticulate pair of former Texas Rangers turned horse rustlers. Yet when the trail begins, the story picks up an energy and a drive that makes heroes of these men. Their mission may be historically insignificant, or pointless – McMurtry is smart enough to address both possibilities – but there is an undoubted valor in their lives. The result is a historically aware, intelligent, romantic novel of the mythic west that won the 1986 Pulitzer Prize for fiction.’
Now, that’s got my attention! I find that I’m suddenly interested in hearing more about these ne’er-do-wells. I might not be ready to commit to reading the whole story, but I’m certainly curious about it. At the very least, I’m not willing to put the story back on the (metaphorical) shelf just yet…
That, I told Jake, is what you need to do when you tell your prospective employer about your recent workplace misadventure. Yes, you have to tell them that you were sacked; honesty is non-negotiable. How you pitch the story, however, will make all the difference in the world when it comes to having your interviewer either put your CV straight into the bin or having your interviewer lean in, curious to hear more about what happened. That’s what you want: a fighting chance to tell your story.
That being said, here’s the gist of Jake’s story, as I understood him explain it:
Jake was hired by a large company to join a group of 20(ish) other programmers stationed at the Dallas office. Their job was to make changes to existing bespoke applications as requested by other employees. So far, so good. Jake met the other programmers and found them to be nice folks. They all got along. The office was an okay working environment, and his coding skills were right for the work. Seems like Jake had everything that he needed to be a long-term success.
It didn’t take Jake long to discover the fly in the ointment: first, he couldn’t find anyone in charge. Oh, there were managers… but those managers were all based somewhere on the East Coast. There wasn’t a single supervisor to be found anywhere on site. That is, there weren’t any for the dev group. There probably were for other departments, but none of those other supervisors had anything to do with the isolated and abstracted cluster of app programmers. That was definitely a problem…
Fortunately, this company wasn’t a Dot Com style ‘brogrammer’ culture. The lack of adult supervisor didn’t inspire the workers to drink at the office, or skip work, or play video games all day. These were all serious, sober adults who wanted to do a good job.
Anyway, his first discovery quickly exposed the second problem. Jake discovered that the mysterious absentee managers had established a strange policy that forbade the developers from working on any job requests in their team queue without express, prior permission from said absentee managers. Hundreds of jobs were piling up, but the number of tasks blessed to work on were so small that the devs spent most of their days idling, frustrated and feeling useless.
Jake wasn’t a manager. He was, however, inspired to lead. He figured out that his co-workers were anxious, frustrated, confused and generally unproductive. They were also fully aware of their no-win situation and didn’t like it one bit. So, Jake took stock of what-all had gone on before he got there, and crafted a plan to let the team triage and turn their own small projects from the work queue whenever management approval and formal change control weren’t required. His proposal would allow the developers to stay constantly engaged between larger projects; every time a dev found him- or herself idle, they could snag a small job and kill it off, thereby keeping the jobs queue clear and keeping the customers happy. Everyone would be happier. Everyone, that is, with the exception of the remote managers. They hated Jake’s plan and vetoed it – without any explanation.
Feeling more confused, Jake struggled to make sense of the rigidly dysfunctional corporate culture that he’d stumbled into. He was part of a pool of workers who had – for all practical purposes – no leadership, no mission and no utility. They also seemed to have no authority to influence their fate. Meanwhile, customers were getting fed up with the dev group’s apparent unwillingness to complete easy work in a timely manner. Morale was degrading.
One afternoon, Jake started to work on a ‘management-approved’ work request from a customer that just happened to work right there in his building. A representative from Internal Audit filed a request to get a report run that would reveal whether or not any of the developers in the company also had permissions to deploy code – a huge potential violation of the ‘separation of duties’ rule. Jake spoke with her, learned what she needed and figured out how to provide the requested report. He presented his solution to the absentee managers… and was told that he was required to trash his work because it ‘would overload and crash the server’. Instead (the managers said), they’d provide the customer with an incomplete report. Jake argued that failing to fully disclose the truth violated the company’s duties to respond to regulator inquiries, and was told to shut up and colour.
Worse, it appeared that the absentee managers were deliberately withholding compliance evidence from Internal Audit. Jake was aghast. This wasn’t just a misunderstanding of technical processes; it was potential fraud. If it was discovered during a formal investigation that Jake had known how to comply with the demand and had colluded with management to refuse… that wouldn’t just cost him his current job. It would also cripple his future ability to find work.
Flash-forward a month later, and the Internal Audit customer was finally fed up with her clearly incomplete report. She complained about it to the High Holy Dev Managers, who haughtily condescended that the automation that she’d asked for ‘couldn’t be done’. Not shouldn’t – couldn’t. That’s when Jake made the willful decision to act: He ran the report and turned it over to the auditor as spec’d.
Jake’s remote bosses phoned him on his mobile to tell him that he was terminated, effective immediately. No disciplinary proceedings, no HR involvement. No paperwork. Just sacked. The good news was that he wasn’t technically ‘fired’ like a normal employee would be; since he was a contractor, the company simply defunded his contract at the end of that day. The only long-term repercussions would be a high probability that Jake would be black-balled for all future work at that company … at least, in dev. Internal Audit would probably hire him in a heartbeat.
That was all right. Was the sacrifice worth it? Yes, Jake told me. Yes, it was.
That, then, is the story that he needs to tell. If he has to summarize it, then summarize it thusly:
I took a short-term contract at Company X to help fix their bespoke software tools. When the company’s Internal Audit department asked for a report that would reveal possible conflicts of interest within the IT department, the managers I worked for refused to provide the report. They told me to lie to the auditors and turn over incomplete data. I was caught between the two horns of a dilemma: be fired for conspiracy to conceal evidence from regulators, or be fired for disobeying my bosses. I chose the latter option based our code of professional conduct.’
By establishing the story’s context, we’ve changed this story from ‘man joins business, shortly thereafter gets fired from same’ to ‘man joins business, is told to falsify evidence, refuses to, and gets sacked for it’. We’ve (truthfully) re-cast the narrative from Jake being a (minor) villain to Jake serving as a (minor) hero (or, at least, a minor martyr). Since his CV only shows that he did a short contract at this client – he wasn’t technically fired; the client just ended his contract early – the encounter probably won’t hurt his overall reputation. More importantly, the story will likely convince the interviewer or hiring manager to want to hear more. That, then, may lead to the story that convinces the hiring authority to bring Jake aboard his or her team.
Stories matter. Good stories can move people. Sometimes, even the synopsis that summarizes another story will be enough to ignite some interest. For us hiring managers, we need to be aware of this phenomenon. First, we need to realize that the person telling us about their escapades has every reason in the world to spin their tale in such a way as to frame them in the best possible light. That’s human nature. A healthy dose of cynicism is always warranted.
More importantly, though, we need to remember that not all story summaries paint an accurate picture of what really happened – or of why things happened. Sometimes, we need to encourage the applicant sitting across from us to give us more context. We need to give the person that we’re interviewing a fair fighting chance to spark our interest. We absolutely shouldn’t jump to the logical conclusion about what must have caused something without at least hearing the tale. Yes, it takes time. We might well have been right in our guesses. We might be disappointed… or we might just discover that the person telling the tale is a more interesting character than we’d initially judged. One that’s worth our time and attention. We won’t know until and unless we ask.
[1] Not his real name, but near enough as makes no difference.
[2] I’m not gonna lie; I chose that particular story because the dove/devs wordplay angle popped immediately into my head.
Title Allusion: Larry McMurty, Lonesome Dove (1986 Book) and Lonesome Dove (1989 Television Miniseries).
POC is Keil Hubert, keil.hubert@gmail.com
Follow him on Twitter at @keilhubert.
You can buy his books on IT leadership, IT interviewing, and Horrible Bosses at the Amazon Kindle Store.
Keil Hubert is a retired U.S. Air Force ‘Cyberspace Operations’ officer, with over ten years of military command experience. He currently consults on business, security and technology issues in Texas. He’s built dot-com start-ups for KPMG Consulting, created an in-house consulting practice for Yahoo!, and helped to launch four small businesses (including his own).
Keil’s experience creating and leading IT teams in the defense, healthcare, media, government and non-profit sectors has afforded him an eclectic perspective on the integration of business needs, technical services and creative employee development… This serves him well as Business Technology’s resident U.S. blogger.
