Respect My Authority, PLEASE

Much like the old "Take my wife...PLEASE," the theory in having your authority respected is that asking people to do it often turns the whole respect thing into a joke.

When you encounter someone--in an elevator, in a work group, on a basketball court pick up game (yes, I play basketball. I don't play, you know, well, but I do play it)--you have to make a judgment about how much you are willing to trust that person given the immediate circumstances: what you are doing, if it's together, if it's collaborative, if it has long term consequences, etc.

In an elevator, for example, the immediate concern is not collaborative nor long term, but is certainly important and immediate: Can I turn my back on this person? This is because people in elevators traditionally face forward (unless you are a norm violating machine as mentioned in an earlier post). Whereas people looking to group for a pick-up game of basketball need to determine if they think that you can play at all, if you are an asshole (assholes tend to not play well with others) and put the more immediate safety concerns out of their mind. Finally, when working with someone (or someones) in a work group situation, you are not only looking at their ability to perform this task, you're probably also evaluating them for long term tasks, fit for your team or your personality, and, weirdly, some immediate safety questions pop back up--for example, does this person make you feel creepy? Because no matter how good he/she does the job, creepy is a trait that is VERY hard to overcome.

So why am I bringing up creepy people and basketball players? Because in each of the examples, you have to make a decision about how much you trust someone. Trust is the key, integral part that leads to respect. Its very hard to be untrusted and respected in the business world.

There are tons of books out there that basically say the same thing, which I'll sum up for you here: Respect is Earned.

Many of those books say things like "There are not shortcuts to respect," and "Respect comes gradually...it can take a long time." I'm going to suggest otherwise; you sink a few baskets and prove you can pass and be a team player, and the basketball pick up group is going to respect you. They are likely to remember you next week and pick you for their team, on purpose, because of that trust and respect.

While it's unlikely fellow passengers on an elevator will select you to stand behind them again, this metaphor does actually apply to the work situation. If you have to work with someone you don't know, and you treat them in a fair and open manner and, like the basketball player, share the ball and help others to score, you have respect. It's not in its full form; they won't follow you into battle or anything. But they might back your play in a safe environment. That's how respect starts.

These are all very controlled examples of trust and respect in a short period of time. The most common you'll run into is that you are sent to a completely different group to do something there related to, but not a standard part of, that group. For example, you're hired to lead an existing team of developers whom you've never met. Or, you are sent to another group to help them adopt a peer review process that your team did a great job with and management wants to reproduce the results.

Those people don't know you. They had a system in place prior to your arrival. It may have worked. It may have been dysfunctional. But it was theirs. You are new. You are unknown.

And the same things that garnered respect on the basketball court, in the elevator and in the base work group example still apply: be yourself, be trustworthy, perform well, share the credit, help other people look good. It can take days, not weeks (sometimes hours) to form at least the minimum respect from my basketball example...and that's what real respect and trust can easily grow on: stable, consistent behavior.

If you have to do things that make your trustworthiness questionable, be upfront about them. Be transparent. If the team succeeds at something, celebrate the team--don't give any credit to yourself. You do it right, and part of respecting you will be calling out your contributions; the quickest way to lose respect is to toot your own horn. Instead, toot the horn for other people. The important part, though, is MEANING it. Lying, as noted before, is the suck part of the job.

Everyone has something about them that makes them amazing to work with, even if that something is their absence. Seriously. I have had folks on my team who were pit bulls--the rest of the team had trouble working with them because they could not let go of something and they kept coming back on that topic aggressively, over and over again. But it turned out that pit bulls are very good to have when working with other teams that are shy about returning your emails or getting you the resources they promised. The pit bulls mentality can be useful to a team aimed in the right directions. Pit bulls, as a breed, are good dogs, and pit bulls in the office can become heroes. With the people as with the dogs, it's all in how they are trained and rewarded for their efforts.

Obviously, I could talk a really long time on this topic, and many, many people have devoted books to it. Sufficing to say, respect and trust are the foundation of a good manager and is the giant-blue-catch-bag-that-stunt-people-jump-into-to-avoid-being-hurt of the imperfect manager.

Bonus Blog: Know the Players (Don't Hate the Game)

When you're running a project or managing people who are doing a project, it's important to know the players:

1) Stakeholders: These are all the folks (and I do mean all) that either feel they have a say or actually do have a say in what goes on in the project. Some people might define these more narrowly, but generally, this is a large group that has to agree on the business needs/requirements or no project happens.

2) Product Manager: Sometimes part of the stakeholder crowd, product managers have a variety of duties and/or titles depending on where you work/look. Often they are engaged at the early levels of a product to shape everything from marketing and packaging to actually gathering the high level business needs/requirements. Sometimes they're called "product owners" in Scrum/Agile methodology, but it really depends on how much refinement they do and collect regarding requirements.

3) Project or Program Manager: Typically, I think of program managers as those who manage collections of projects, usually under a specific theme, though some people recognize senior project managers the same way. These are the folks that take what requirements there are from the business (by meetings, collecting written materials, requirements, etc.) and turn them into business requirements that are the start of what developers, artists, UX/UI designers, etc., can work on. Sometimes, they do not do this role, and instead farm it out to Business Analysts. Regardless, whether they do that or not, Project/Program Managers manage schedule, resources and scope of any project.

4) Development Manager: This is the person who manages developers. Sometimes they are more active on a project and make specific decisions. Most of the time, they provide agreed upon standards for all developers and enforce them. They also handle the daily/monthly care and feeding of the people whom the manage. Sometimes they are a Developer Lead (and the group of devs reports to someone else for management) and they still do either specific project development lead work and/or standardization and technical help for the other developers. Sometimes the Dev Lead is treated like a Dev Manager, where they are also responsible for daily/monthly care and feeding of all developers. The Dev Lead or Dev Manager, or a Senior Developer will go over the business requirements document (and any attempts by Project/Program Manager and/or Business Analysts) and help break the work into technical requirements.

5) Architect: This can be several people; an architect can be an architect for business intelligence systems (how data is handled, entered, ordered, and reported on), for technology (how all the systems including this latest project are plugged in together and meet all standards/needs for the platform in the future), or if you're literally building something, physical architecture. Typically there can be more than one architect consulting on a project, but typically it's per specialty; rarely do two tech architects both consistently weigh in throughout a project. The role of the architect can be anything from someone who reviews designs and approves that nothing is beyond the ordinary, from someone heavy into the construction of the project at the very beginning and who occasionally monitors progress until the end. It really depends on the work being done and the time available for the architect to provide expertise.

6)Operations/Systems Administration/Production/Release Management: Depending on the org and the type of project, these are the folks who maintain what is currently live in production, and move any changes into the live system. They also maintain that system, review security (usually in conjunction with testers), and may handle permissions to access specific machines, utilities, etc. Their overall schedule is not tied to the project schedule, though the project schedule is tied to when they can help move code or work between environments or locations, and when they can help launch a project. They also provide subject matter experts on hardware, software, security, and a variety of other very handy topics which should be considered BEFORE the entire product is completed. Their requirements are frequently as mandatory if not more so than stakeholder business requirements, because they control the medium of launch/publication: you don't meet their requirements, your project never finishes. 

7) Project Team: This is the group that does the work. Usually this includes the Project/Program Manager and/or Business Analyst, a Product Manager/Product Owner, a Dev Lead or Manager, a group of developers and/or testers (Some teams have the devs do the testing cycles), UI/UX folks, designers, subject matter experts, etc. It can be expanded from the those immediately doing the software or building the hard ware to include folks doing the legalese, packaging, distribution, etc. Note: the architect might be a part of the project team, but often isn't completely dedicated to the project, so, often is not. Sometimes Operations/Systems Administration/Release Management will assign someone to work on a project, but more typically they are consultants brought in and sometimes treated like stakeholders (see above about not launching without meeting their requirements).

I'd like to take a moment to note that I was a Quality Assurance Tester, Lead and Manager for a large portion of my life, and they are awesome, required people. I have included them in the project team and not called them out specifically because many companies are moving away from a purely testing model to one where developers and testers share roles (and or swap them). I have not forgotten them, and I do, completely value them (or else several of them will come for me and I will be killed and this will be my last blog post), but I'm not pulling them out on their own for this particular project overview, though I will in the future, I swear (please don't hurt me).

There are a few other roles that sometimes come into play:

A) Patron - This is (usually) the single executive backing/pushing for this project. Consider them the stakeholder with the highest weight given to their requirements and needs, because without them, your project could get cancelled.

B) Other BigWigs - People at the level of your Patron, or at least above you, that may interfere with and/or poke at your project, because they can. I typically try to treat them just like any other stakeholder and/or direct them to my Patron rather than telling them to leave me the hell alone, which is kind of my preference, but typically the fastest way to get them to NOT leave me the hell alone.

C) Clients or Users - The people, in theory, for whom this product has been designed/created. Sometimes its an external client who is paying you for a service or a project, other times its an internal user who needs to be happy with a service or project in order for the project to conclude before you die.


Now you know the players! A future feature will go through RACI (Responsible, Accountable, Consulted, and Informed) and talk about how these all fit together so that we can have a happy project (or at least one that isn't chasing it's tail).

Construing Criticism -- Constructive, Destructive, and Trying Not to Make That Face While You Get It

I do not take criticism well. Constructive/destructive, my inner voice thinks that you are a jerk the moment you suggest to me that I might not be perfect. Never mind that I spend a lot of energy every day wondering if people see my imperfections, and quite a few more praying that they won't. However, confront me logic and facts (or illogic and meanness), and my inner monologue is going to call you names.

Note, however, it's the "inner" voice that does this; I have learned, painfully, over the years not to say what immediately comes to mind, no matter how funny it sounds in my head. There are HR departments out there blissfully unaware of what they have been spared; but this is how it should be. Part of being a grown up means not saying what you think, exactly at the moment you think it. Sometimes, it means not saying what you think, AT ALL.

Usually it means sizing up the situation and saying what you think in a professional, rational and reasonable way.

Now, if you're going to talk about what happened with someone who was ridiculously unreasonable and just plain mean, the filter between your brain and your mouth might not have as much work to do in terms of responding. But rarely are people so simple and idiotic in their criticism that they leave themselves open to a shot, and as a result, even if the shot looks tantalizingly easy to take, you probably ought not.

First, you are a grown up. While as someone's manager (or being managed by someone else) you can occasionally goof off and be child like, childish is pretty much the turn off the high way of employment: you may not leave the freeway for a while, but you are definitely speeding away from it.

Second, people who are viciously and thoughtlessly attacking you at work have bigger problems than you. Seriously. Very few people--even our special friends the sociopaths and psychopaths of the world--wander into work and let you have it verbally with no reason other than the voices in his or her head (ok, this suddenly makes my first couple of paragraphs seem like I'm a sociopath or a psychopath, but I assure you, I'm not). Usually there's spilled coffee, a verbal fit with someone else, bad traffic, sick children, lack of sleep, oncoming illness, death in the family....the list goes on, but the gist is, there is something else at play. That thing will still be with them when you're done tangling, and they know that, and so whatever petty revenges spring to mind are really nothing big to them. They aren't quite people with nothing to lose, but what's the point of fighting with a person in a position of irrationality, unless you're practicing your "Yelling" voice?

Third, people who are vicious without cause, while wrapped up in whatever is upsetting them, are, themselves, upset. Something is WRONG. When someone needs help, you try to help them. It's decent and kind. Just because they sound like a bear doesn't mean that they don't need help; try to look past the rage and give them space if needed.

Of course, this post is supposed to be about constructive criticism, which is the most common you'll run across in a work place (or at least what other people think is constructive criticism). From your boss suggesting you write shorter blog posts (SORRY) to people pointing out that a seemingly innocuous turn of phrase is NOT for some of your audience, there are things to consider and review.

Of course, my inner voice thinks they all suck. In the old days, it would paint my face with a look of incredulity and/or dislike. These days I've got it (mostly) under control, desperately trying to think of pictures of sleeping kittens or how much I dig it when my husband hugs me, instead. As an aside, this may be problematic because I relax and look a little "awwwww" afterward which is not what they were expecting, either, but if you had to choose between the two reactions, I'm betting you're hoping I'm thinking of kittens, too.

It isn't, however, just about listening to what they say. It's about what happens when they're done talking. A polite person would sum up what they thought they heard, and then say, very carefully "Thank you."

You are not required to tell them what will happen with their advice. With your boss, he/she might want to know, but typically summing up what they said and repeating it back so they know you heard following it with a "thank you" and then beating feet for the hills works just fine. You can consider how you feel about the advice later. The most important, thing, though, is to understand what you've been told, and thank that person for their feedback. Even if you hate their guts a thousand fold, the world would be a far more horrible place if people didn't give constructive criticism--seriously.

What do you do if you disagree with their criticism?

EXACTLY THE SAME THING. Fresh off of criticism is not the time to argue with it; most people will feel you're being "defensive" and shut down any logical arguments you might use to the contrary. Also, they won't feel as if you appreciated their comments if you immediately refute them. While people don't give constructive criticism for all the awesome thanks they receive, they do know when to NEVER give it again, and that's after someone blows up at them.

So you've said thank you and fled. Now what? Now you actually think about what you were told. If you are the type that gets benefit, you stop and chat with someone you trust about the commentary. You come to decide if a) you agree with the comments and come up with a plan to incorporate them so that you can improve yourself or b) if you respectfully disagree, and come up with a plan so that you don't come across in the way they found critical before.

If its your boss or your employee, you follow up with your thoughts and future plans. If its anyone else, let it go. The ship has sailed. As much as you may have been thinking about them and their words, there is a good chance they haven't had another thought about you since.

I will do a future blog post on actually giving constructive criticism, but I will leave that excitement for another day. I hope your heart is as aflutter as my own.

Bonus Blog: Presentations Are Not Just Reading PowerPoint Projected On the Wall

A lot of people think that presentations are a PowerPoint "deck" that they read to a room full of semi-bored people. Technically, I guess that does meet the definition of a presentation--you are, you know, showing people something. You're just not doing it well.

A little bit of notice here: I am not the greatest PowerPoint presenter known to man or god. When in front of large groups of people my speaking voice gets higher and higher until I'm fairly certain that dogs in nearby neighborhoods are clear on what I mean when I'm talking about whatever I'm talking about, but the people in the room are making funny faces and holding their ears. I also tend to talk REALLYREALLYREALLYFAST when I'm nervous. This does not make for ease in attention span, although the rising pitch and volume of my voice does make me impossible to ignore. I strongly suspect people are waiting to see if I will actually explode, or if someone will pull me (the kettle) off the hot burner.

However. I have eyes and ears, and I've been bored out of my mind enough times to at least be able to tell you what seems to work. As noted, I have a lovely backlog of what doesn't.

That said, everyone in the room looking at the projected image on the wall can read if they've managed to get a job where you're working. There are notable exceptions (maybe you work at a literacy center), but for the most part, they can read. Reading to them about interesting stuff--say the Lord of the Rings or something--might make a difference, but most adult people don't really like to be read to anymore unless a glass of wine and a loved one is around somewhere (or they are driving to and from somewhere trapped in traffic). In those two cases, they CHOOSE the material they're being read, which is the chief difference between you and the more fun activities.

Now, you can give a crappy presentation. There are a lot of mandatory meetings in everyone's life, and no matter how bad the presentation sucks, people are going to stay for it because they have to--your meeting is required for them. Short of physically harming animals or humans (plants are fair game!) or obscenity, they'll hang in there. They're being paid for this.

However, giving a bad presentation with a trapped audience does not do well for future engagements where you need them to actually WANT to come back. For example, a mandatory meeting on the new HR software everyone has to use bores them to death, so they don't attend subsequent update trainings, and you, the support for the new HR software, get stuck with tons of people asking questions they totally could know the answer to had they'd actually come to your subsequent meetings. However, if you'd sat through the mandatory meeting, you might actually also not come to the subsequent meetings, because it was BORING.

So, my first rule of presentations is "A presentation needs to not be boring."

It does not need to wildly appeal to all audiences. You're not expecting a critic to explain that "They laughed, and they cried," and review you for all your peers (4 stars!). No standing ovations are likely. But more eyes on you (or your presentation) than cell phones or laptops is the goal.

My second rule of presentations is "Don't write everything down on the slides."

Some people will disagree with this, especially if they like to review presentations after a meeting. And when I suggest that you don't write everything down, I'm not suggesting that you fail to write important things down...such as where to find the software that the presentation is about. What I am suggesting is that you give people a reason to actually LISTEN to you, rather than just read the current slide then resume whatever they're doing on their own machines, phones, notebooks, or imagination.

So, you have three major points to hit, and explanations regarding each point. The slide should be the three points, only. You can add your notes to the notes section of the doc (or provide a separate notes section if you're not using PowerPoint) so that people have access to all the data later. But for the actual presentation, you will not fill in the space between the points, giving people a reason to actually look at you and not just the shining words on the wall in the dark room.

My third rule of presentations is "Anticipate what they are most likely to ask, and answer it before they can ask it."

This requires knowing your audience. If you are creating training materials, you'll need to remember the first questions you had, or areas where you were confused, and specifically call that out in the presentation. If you are creating a project pitch to executives, you're going to want to talk to people who work with those executives to find out what they are most interested in, so you can include it in the presentation before they ask. Seamlessly meeting the needs of your audience makes a presentation go more smoothly, but also manages the most important task of a presentation: transferring information to the people in the room who are not you.

Don't be afraid to do research. Don't be afraid to do a mock test with co-workers before you do a big presentation so you can capture good questions. Remember, presenting isn't just about a flashy deck of information, it's about a flashy deck of the RIGHT information.

My next rule of presentations is especially difficult, "Be funny, but don't be juvenile or trite."

I frequently joke about using Dilbert cartoons relentlessly in my presentations, but actually, I don't really do that (I use, what I like to call "Hyperbole"). Presentations with one cartoon on a slide by itself are sort of a warning sign to me that I will be bored of my socks ten seconds after I read the punchline, and probably two full minutes before the presenter reads it out loud.

Interspersing cartoons throughout a presentation is actually worse; people read a lot faster than you can talk, and cartoons that are universally funny are rare. On the whole, more than one brings down the quality of the entire presentation. And just one--unless specifically on target for the presentation--can be kind of trite. No one likes trite.

What I like to do is use metaphors to explain to people how the idea comes across. People understand metaphors--to a certain degree, our brains are hard wired to look at other experiences, compare them to the current experience, and derive the difference for future reviews. Metaphors add color and life to a presentation while they explain things to people in a non-patronizing way.

Metaphors are also a nice way to work in amusement without actually being juvenile or trite.

So, for example, I had to explain what a Beta Tester was. I put two guinea pig pictures at the bottom of the screen (cute and cuddly) and then I talked about Beta Testers as people willing to be guinea pigs for our software changes in exchange for getting those changes more quickly than other users. People understood that, and, as I had hoped, laughed at the picture of the cuddly animals.

Note, you should stick with as positive a metaphor (or simile) as you can during the course of a presentation. Negative metaphors can set people into the wrong mood ("And that's why viruses are just like Hitler") and you don't want them leaving your presentation feeling negatively

My final rule of presentations is, "Keep it short!"

You should be able to see white space on the slide of at least a finger when standing in the back of the room looking at it on the wall throughout the slide. Type as much as you like into your notes, but keep slides targeted and short.

Further, keep the presentation short. I like to use up half or three quarters of the time if I can manage it. For example, for an hour meeting, I'll do maybe 22 slides. Maybe. That gives time for questions at the end, questions in the middle, and any additional amusements you might want to throw into the mix (I am not opposed, for example, to spend the first 2-3 minutes of a presentation passing out fruit and candy).

Now, there are a lot of ideas of the perfect presentation out there. I'm not advising a perfect presentation. I'm just advising on one that will get the job done. Some presentations have more specific rules (must be done in 5 minutes with three slides, go!). Certainly your audience has a major impact on what goes on the slides--execs don't like the nitty gritty details as much as they like the summary charts and data.

These are the rules that I try to do my presentations by, and I've so far seen relative success when they could understand me and I wasn't actively injuring their ear drums.

Trust But Verify

A lot of my posts have talked about direct ways of influencing the workplace to improve things both for yourself and for your team.

This post is a bit more introverted. We’re going to look at how we think, and how other people think, in an effort to get them to actually do things or understand why they do the things they do.

You’ve probably heard the phrase “Never assume,” which follows about making an ass out of yourself and someone else, if you do (to paraphrase). However, it keeps reappearing as a notation of import in the process of doing business. So apparently, people—myself included—keep assuming, and keep paying the price for it.

For example: you are in a meeting with Bob. Bob says he’ll email Jane after the meeting so she will do the database back up you need. Bob is earnest that you shouldn’t bother his employee, Jane, directly, and he will do it. Bob is a really trustworthy guy and he’s done a bang up job in the past.

Three hours later, you still have no back-up.

Its not your fault you assumed that Bob would do what he’d said he’d do. It may not even be Bob’s fault that it didn’t get done. But if it was your job to get a backup by the end of the day, no matter that you can’t control Bob or Jane, it will be perceived as your fault because you’re the manager. Whether you’re the project manager, product manager, dev manager or QA manager, when you’re supposed to manage stuff people ASSUME that you will get it done, no matter how impossible.

So what could you do? When you get the promise from Bob about the email to Jane, you need to rephrase it so the item falls within Bob’s realm of responsibility. That way if he shoots an email to Jane as promised, he doesn’t stop thinking about it assuming (because everyone does) that Jane will tell you or magically you will somehow figure out what you’ve asked for has been done. To shore up your ability to put Bob in charge of the thing, give him a time limit to get back to you.

So, looking at the previous example, Bob says he’ll contact Jane. You thank Bob. Then you ask Bob if he can be in charge of the action item to make sure the back up is done by end of day? If Bob says yes—great, ask him if he can get back to you with the fact it’s done by X time today. If Bob says no, you now have negotiation room to access his employee, Jane, yourself, because the fact remains that item has to be done and its okay if Bob doesn’t want to do it as long as someone does. So Bob has said he can’t accept that responsibility, fine, let him know you’ll check in with him and Jane at X today to see where the back up is. Checking in with them means that Bob can send the email (if he hasn’t) while you’re standing there, and then walk over to Jane with you, later that day, to make sure it gets done.

People constantly promise things during the work day. Because they are adults and have held down jobs a while, its natural to assume that they’ll keep commitments that they make. In the words of Ronald Reagan, “Trust but verify.” Never make someone feel like you don’t believe them, believe in them, or trust them. By the same token, however, never leave responsibilities of yours to be completed by others on trust alone.

It is so easy to assume someone will just get something done if you ask them. A lot of the time that person will come through. However, it really depends on a lot of factors how reliably someone will do things for you, even if you are their boss.

1) What else do they have to do today?
2) How many other priority items are there?
3) Are they preoccupied with home life, anticipation of a pleasant or unpleasant event, etc.?
4) Are the prone to forgetting things and didn’t have a pad and pen with them when you asked them?
5) Is this thing really close to something else they could easily confuse with it? That way they might think both are done when really only one is.
6) …the list goes on of possible issues.

To combat assumption (on my part and that of others), I keep a To Do List For Other People. Yes, I keep a list to make sure other people do things for me. I use it for myself (I’m #4 above, so I try to always keep a pad of paper and a pen with me, and then transfer those notes to my main list), but its also where I keep my “nagging” list—the list of things I do to surreptitiously check on items I would otherwise assume were being done.

While it's no fair you're dinged for Jane not doing what she was supposed to do or Bob not doing what he said he's going to do, you will be. The only surefire way to get things done is trust, but also VERIFY those items. Poised logically, most people have a hard time arguing with the logic of making sure something you're responsible for gets done. Unfortunately, and probably the topic of several future posts, people aren't always logical.

Bonus Blog: Weird Work Situations: Credibility

This week's bonus blog was spawned by a memory of a former boss that ruined his reputation in our industry and (hopefully) is still recovering from it. In my previous blog, I almost referenced him, but figured that putting in his story would divert from the actual point of the blog post.

Diversion is what Bonus Blogs are all about.

We'll call this person X. X was a rich personality, funny, vivacious, non-stop movement and action. He was a project manager and a team lead running multiple projects and managing a few groups of developers, testers, etc. His project were never in the red (or yellow); he always reported his statuses as "green."

X came to work one day and quietly spoke to some of his close friends at the office and to HR. He told them about a health condition, but didn't go too much further into it. A few weeks later, with confirmation of his diagnosis, X informed those who worked with him/for him that he had a brain tumor.

The tumor, he said, was operable. While he was having severe headaches and occasionally needed to take time at home, or work from home, he was going to be ok; he had multiple doctor appointments, and eventually scheduled surgery. He was positive that he'd be right back to work, two weeks after surgery, despite me telling him that my other friend--also having needed brain surgery to remove a tumor--took six months to get back on her feet. He repeated that his doctor said he was otherwise in excellent shape, and that he should be back two weeks after the surgery.

The day of the surgery, we got a nice email from him before he went under. Then nothing for several hours. Many of us were worried. My current boss (I had worked for X, but now worked for another person) was especially concerned because he and X were just about best friends, having eaten at each other's houses and gone to church together.

Finally, my boss's boss started gathering all of us to come to the center meeting space at the organization. He had news, he said, about X. All of us were terrified--had he died? My boss's boss shook his head sadly and said, "No, he hasn't died, but we have news about him and we need to share it."

So we all gathered. And that's when the world spun a bit.

Apparently, X had not been taking bed rest. X had been attending other job events. In fact, X apparently had a job with a major competitor. Someone's Significant Other in HR had seen X at a trade show event representing the competitor, and looking FINE. Upon further investigation, X had made the entire thing up about the brain tumor. Apparently he intended, all along, to switch companies, but job hunting and then actually working there before he switched out had been orchestrated through his many doctor appointments. Additionally, he had intended to claim disability (and in fact, had already started to do so) during his "Brain Tumor Trauma." So, in addition to lying to everyone who trusted him, he had planned to also defraud the local government of their disability payments.

He was effectively fired that day and all access to the system was revoked; during the meeting, he emailed he teams that he came out from surgery ok and wanted to know what was up with their projects. Because someone who has been in surgery for several hours, blurry out of anesthesia totally can process project management duties.

Everyone was informed not to contact him, and his team was inconsolable. Figuring they needed some help, I invited the teams to lunch. A few people took me up on it. As a side note, if you are a manager or want to be in a aposition of management, standing up when other people really want to run screaming or sit down quietly and hope not to be noticed are opportunities. Although I must say I didn't offer to talk to them for the opportunity of it, as much as the fact that these were my friends and they were hurting. Employees who feel hurt and betrayed do not make the best employees, but friends who are hurt and betrayed--well, I drop everything to sort that out.

That lunch was when I learned his projects were in the yellow and, almost, in the red (and had been in the red a good bit before). The lead dev had been left to manage the projects--X was apparently not doing any work at all, and reporting that everything was FINE as well as taking on additional projects when new ones came in.

It is my opinion X was gathering intelligence about our company to take with him to a new company where he felt he could be paid better and better valued. An inhibitor to learning about all new projects would be any appearance of his own projects not being under control. Likewise, he befriended people "in the know" about the status of all projects and effectively betrayed the people whose table at which he'd supped and church where he'd gone to worship with them.

So. When I think about burning yourself in an industry, I think about X, or, as I like to call him: "Fake Brain Tumor Man." I imagine if his resume floated near my desk or another manager asked me about him, the first thing I'd think of to say would be "He faked a brain tumor. Don't hire him. Seriously." Then I might have to show that person this post.

Don't be like FBTM. For that matter, don't be like me. Be like yourself, but you know, the best version you can be. Don't trade in your credibility for anything; there are very, very few things worth the price you'd pay for it.

Applying for Jobs, Part 1 in a Multiple Part Series That I'm Sure I'll Get Around to at some Point

The first thing I need to say is that my theories on job application, resume and cover letter writing, etc. are my views. For every manager who kind of likes what I suggest, there are at least 12 that prefer everything from variants to the opposite of what I suggest. Your mileage may vary.

The second thing I need to say is actually what those things are I plan on saying. Er. These are the things I do and look for when people are applying for jobs to work for me or my company:

Spell check my resume. You'd be surprised how few people do this. I would also have a human do it, because Word may be down with you saying "hear" when you meant "here," but people who are wondering if you are as detail oriented as you claim will get a negative impression when they notice the homonym instead of the correct word. Spelling your own name in more than one way on a resume counts as a misspell in my book unless you specifically are making a point of telling me it can be spelled more than one way...though I'm not sure why you would do that on a resume. "See, I go by Holly or Hollie..." You go, girl, you.

Have someone, who is not me, read my resume. Preferably I want someone who is not especially technical to do it. Does it make sense? Do they understand what I've done in relatively plain words so all they have to do is look up the acronym/code phrases/etc.? Typically, your resume has to be screened before someone that you'll be working with looks at it daily, and those screeners REALLY appreciate a clear and easy to read resume; it makes the difference in whether yours gets tossed into the "eh" pile or the "prospect" pile. Yes, people who are not as technical as you are may be vetting your resume. Accept, move on.

Keep my resume to 2-3 pages. Back in the old days, one page was fine; but people no longer stay at companies for five or more years...and in the age of consulting and contracting, you may have a lot of gigs. Regardless, keep it as short as possible; 3 pages max. While many schools of resume writing indicate you should explain every "t" you've ever crossed and wax philosophical about all the "i's" you've dotted, it is PAINFUL to read a really long resume full of repeated buzzwords. I have also been known to copy buzzwords from the resume and quiz participants on those buzzwords, so you might want to stick to words of which you completely understand the meaning.

A side note: privately, if you use any of the major buzzword bingo words in your resume--eg: Paradigm--I'm less likely to want to even interview you. I'm probably alone in that, but the lesson to take away is to use unique words that explain stuff, not fancy words that I might cross examine you over or make you spell in an interview. Oh yes. It wasn't my finest moment, but I did it.

Try not to repeat buzzwords. Oh, for every industry/job there are buzzwords that make people reading your resume feel comfortable you have some clue of the job you're applying for. But keep them to a minimum. See the bullet up above about someone who is not you reading your resume.

Do not include an objective. This is a purely subjective judgment, but basically you are either saying "My goal is to be patently vague so I can reuse this resume multiple times" or "My goal is so utterly specific to the job description that its as if I might be lying to you that my whole life is wrapped around the one chance to be part of your company." I honestly don't see any value in either, especially when you need to capture additional work experience (since as you move forward, your resume is only going to get longer). On a sparse resume--where you have one or two years experience only, or you are trying to change fields, then an objective is more tolerable. But my general preference is skip it.

Target my resume. When I'm submitting a resume, I want to make it as easy as possible for the person reading it to realize why, just from looking at my resume, I'm the person for that job. If I'm going for a Quality Assurance Manager position, I'll reduce the amount of time I spend explaining what I have done in various positions as a Project Manager, and spend more time explaining everything and anything Quality Assurance I've done. People do not like to dig to find out information they really want to know (and possibly have a stack of other people giving it to them more easily than you are).

Don't lie on my resume. People will ask me about things I've done, and they'll want specific answers. You might pass a screener, but if you cannot do/don't have the experience/knowledge of something, you're pretty much wasting your time and the time of the person asking you the more in-depth questions. This is BAD. Even if you don't get the job, you want them to feel positively about you, or at worst, not negative about you. Most industries of the world do in fact talk to each other, and you may have trouble finding work if you're called on what you've put on your resume.

Submit, even if you don't have the exact qualifications. I don't, for example, apply for CEO positions at Fortune 500 companies. However, if I have all but two of the technical requirements for a specific position I can do, I'll send in my targeted resume, anyway; some managers like to use that initial criteria to screen people, but put more stock in person-to-person evaluation. Others might immediately put your resume in the circular folder, but since email is pretty much free (other than your time) and most people want an emailed resume, it can't hurt to apply. Let me give a better example: You have two years of Project Management experience. The job calls for five years in the exact topsy turvy atmosphere in which you are currently working. Apply, anyway; in a perfect world, no one will have 5 years and they'll take anyone they can get. In an imperfect world, they may take a look, see you have the skills and take a chance.

Always have a targeted cover letter. I like to keep my cover letters to 1-2 paragraphs, tops. I look up the firm and the type of work they do, and I begin my cover letter with my interest and/or experience in that field. I highlight a few of my best qualifications, and end with "look forward to seeing you soon" or something equally "The-ball-is-in-your court, please-call-me, god-I-hope-I-don't-sound-desperate." Sometimes the only thing that causes them to click open your resume is a decent cover letter, and most people (at least in technology) send maybe a sentence (if that). You'll stand out. Just, you know, have your cover letter proofread, as well, before you send it, so you don't stand out in a bad way.

Ping again. I set an alarm in my calendar to email the address again in a week; if I've heard back, I cancel the reminder. If I haven't, I send another email asking if they got my materials. I typically don't ping more than the once, though, unless they've acted somewhat interested. A lot of people use silence as their method of explaining you didn't make the cut. However, a lot of people us silence when they really mean "Doh, overwhelmed!"

Basically, you want to be noticed by someone for a good reason, pass the screeners, and make sure that anyone who calls you back about a position/resume knows at least some of the experience you have in the area of the job. Applying for jobs can be pretty depressing, extremely overwhelming, and/or terribly exciting. I just try to manage the excitement a bit, so I can enjoy it more and panic less.