Deadlines

9 times out of 10, there is no such thing as a deadline.  Do you know what a deadline is?  It is a compound word where dead means death and line means time.  A deadline means that someone will die if things are not in order when the given time passes.  9 times out of 10, there are only goals not deadlines.  Managers, especially upper management, use the term deadline to put fear into the work environment.  In their pathetic insecure minds, they actually believe this tactic will increase productivity.  No, what it does is turn your environment into a slave shop and skyrocket the turnover rate.  Most important, it does nothing for productivity because people will make more mistakes.  When you rush to do anything, the risk for mistakes is EXTREMELY HIGH.

In other words, if not applicable, stop using deadlines.  Instead, call them what they are, GOALS!  Anyone that has managed a project, regardless of project type, has experienced change.  Change in requirements, change in schedule, change in stakeholder availability, CHANGE DAMN IT!  You cannot escape it.  With goal oriented projects, changes can occur or the project may fail, but no one dies!  With deadline oriented projects, critical changes can occur yet someone will die if the project fails.

Be a leader.  Trust your team.  If they look down, inspire them.  Best believe stressing them will only make things worse.  If your brain is wondering “How do you inspire a team?”, then you have some research to do.  It is very VERY easy.

Thanks for reading. Keep this blog relevant by leading IT managers and actual workers here for laughs, insight, and further debates. Continue to submit your management stories to stupid.it.managers[(at)]gmail.com. Your identity will be kept private.

We Use Scrum

Do you? Do you really? I hate dumb ass IT managers that say, "We're Agile." or "We use Scrum."  No you're not.  Just stop!  When you visit to see how they are actually implementing Scrum, it's usually some half ass, jacked up version of Scrum.  Hey! Guess what dumb ass!? If you're not using the foundational principles of the Scrum Guide, THEN YOU'RE NOT USING SCRUM, DAMN IDIOT!

Ohhhhhh GOD don't even get me started on User Stories... Screw it, I can't help it. OK, PEOPLE. It's called a "User Story."  It is an application requirement from the user's perspective. The word "User" pertains to the "person" or "role" that is using the system or application.  Now... come closer.  Don't be shy silly, come closer.  OK, are you ready?  THE USER DOES NOT PERTAIN TO A DAMN PHYSICAL SYSTEM NOR PROCESS. YOU MULE HEADED IDIOT!

Oh yeah, for those that know how to properly scrum and write user stories, there are companies out there writing stories like this:

"As a ETL process, I need to send a message to System P, so that it knows I completed my work."

...

Are you fucking kidding me? NO, seriously, this is happening for real. Stupid IT Project Managers are real!  What's the reason behind writing stories like this? This is what they will tell you: Well, we need to be able to estimate tasks for building background processes or setting up the environment.

...

Listen, don't do that. Stop it. You're embarrassing yourself, your team, and your organization.  If someone actually convenced you into doing this, they were highly misinformed, and you need to slap them.  If you want to use User Stories, use them appropriately.  Their entire purpose is to express clear enough requirements so the development team can estimate  and implement them.  Anything needed to get the job done is estimated.  That includes the background shit.  If the team says a story will require 8 story points, then that's what it is. Scrum teams manage themselves.  You don't manage a damn thing. Your only purpose is to make sure they have what they need to get the job done and leave them alone. If a user story is too large, appropriately partition the story. Large stories are often 2 or more stories wrapped into one. Challenge the BAs (Business Analysts) to pull out those hidden stories. Everything should mostly fit into its own context.  If a story does not have enough detail, your team will let you know.

Don't get so wrapped up into thinking you need user stories to document all requirements the same way. That would be silly. User Stories are requirements for the application. They should not be used for design nor infrastructure specifications.

Let's see... What else... Oh! I almost forgot. Why would you use both Use Cases and User Stories??? Yeah, there are some stupid tards forcing their team to do this.  They write stories with the business and rewrite them as Use Cases for development. STOP IT! If you claim to be a scrum shop, then you should be using User Stories!  Duplicating work is a classic mistake only good for wasting time.  With Use Cases, your team will hate you forever.  Why do people hate Use Cases?  It is because they are boring by nature, so if the formatting is not beautiful, don't even bother.  They don't work in agile practices because they are always written, in non-story-format, by people not doing the work.  These peope don't think like development, which means they don't care like development, which means the requirements will be more confusing.  With stories, everyone gets it.  There is no rigid format.  It's just a plain read.  You will only put readers to sleep with Use Cases.  I'm not talking about the modeling aspect of Use Cases.  I'm talking about the boring written requirements.  For those that are wondering why stupid managers are allowing both requirement gathering styles, it's because their dumb asses like the User Story sentence structure, but want the details of a Use Case...

WAIT FOR IT...

YOU DOUCHEBAG! Don't do that.  Scrum development teams are meant to implement products using the User Story format.  If you really feel the need to additionally use the Use Case format, then your stories are lacking clarity. Wowwww, really? Would that be safe?  Could I do that? Yes, POP TART!

Example:

As a teacher, I need to grade student tests, so their grade average is tracked throughout the semester.

1. Allow teacher to select the appropriate test to begin grading students.
2. Present teacher with a list of students.
1. Student names should begin with last name first (e.g., Doe, John).
2. The student list item should display a their current grade average.
1. This view of their current grade average should be uneditable.
3. The list item should also allow the teacher to enter the student's test grade.
3. Allow teacher to save grades for all students in the list.
1. Teacher should be able to save grades regardless if they have not finished grading all students.
2. Teacher is allowed to finish grading students at a later time.

Pretend the above is a complete User Story vetted by the business. Why redo it as a Use Case? That is stupid.  A scrum development team can take it from there.  I understand there are some companies with senior management that have been brainwashed into thinking they need Use Cases for everything.  Have you ever thought about telling them "No?" I could go on and on about this topic, but you should get the gist of what I'm saying.

Thanks for reading. Keep this blog relevant by leading IT managers and actual workers here for laughs, insight, and further debates. Continue to submit your management stories to stupid.it.managers[(at)]gmail.com. Your identity will be kept private.

Drunken Encounter

Story Sent,

Okay - this should be an interesting blog. The story I'll relate happened early in my career as a newly minted project manager. If it matters, that was back in the 70's, I'm now retired. I was one of 5 project managers tasked with developing a significant portion of a huge mainframe system. We reported directly to the VP of Product Development in a mid-sized software company. Our leader sold the clients and more importantly, upper management (all the other execs) on an enhancement project while what he had us doing was developing a major new system. Along with this effort came a wave of new reporting, designed to inform all about our status and current resource requirements. It soon became apparent to me that the staffing for my segment of the project was woefully inadequate so I religously filled out all of the paperwork so that I would communicate effectively. This went on for weeks and weeks and was a laborous process because it entailed re-estimating all of the tasks and reporting in detail. This took virtually all of my time but resulted in squat - no one who should have responded to what was essentially a cry for help bothered to carry their end of the bargain and dip down to see why I was reporting what I was reporting. I eventually figured out that I was wasting my time, which could be better spent picking up some of the actual development tasks to try to dig out of the hole my team found itself in. It came to a head one night in a bar, I found myself sitting at a table with the VP and after more than a few beers, I unloaded. He responded by asking why I never said anything and I told him in no uncertain terms that if he would read the damn reports he designed he would have known. I eventually got the help I needed but it took a drunken encounter with the executive to make it happen.

The End,

Thanks for reading. Keep this blog relevant by leading IT managers and actual workers here for laughs, insight, and further debates. Continue to submit your management stories to stupid.it.managers[(at)]gmail.com. Your identity will be kept private.

The Bad Interviewer

Let's talk about the bad interviewer.  These are people that poorly conduct interviews and provide no value to the process.  If you haven't experienced this yet, then you haven't been involved in the game long enough.  Keep going.  You'll see.  I guess it's also possible that you could be that person.

Winging It

This is illegal and you can be prosecuted for doing so.  "Winging It" is a phrase that means you have no intention nor the appropriate time to properly plan how you're going to handle a situation.  With interviews, however, this is illegal.  You should not ask a different set a questions to different candidates.  You have to ask the same questions to each candidate.  Not doing so is simply unfair and often allows the wrong candidate to shine.  Each candidate must be given a chance to answer the same set of questions as everybody else. 

This is a small world.  Could you imagine two friends going for the same position and later talking about how their interview went?  What do you think is going to happen when one realizes their interview was unfair?  Lawsuits are always an inconvenience, so I recommend avoiding them.  Managers... come on!  You know better.  Don't be lazy and do the right thing.  Remember the old phrase, "Plan the work and work the plan."  Plan your interview process and make sure you're executing according to plan.

Being a Bully

OK... I don't know where in the hell managers are getting this from, but stop it!  I'm noticing junior douchebags being born from copying techniques of bully interviewers.  By bully, I'm not referring to physically beating up candidates.  Obviously, assault is illegal.  I'm referring to bullying by expression.  Facial expressions, body expressions, and linguistic expressions of the interviewer are often being used to bully candidates into being more nervous than they already are.

I love concrete examples so here you go.  The shit face.  Have you seen it?  Of course you have.  We all do it, but it is not appropriate in an interview.  The shit face is when interviewers look as though they smell shit.  They squint their eyes, they wrinkle their foreheard, and cover their mouth throughout the interview.  They have this look on their face as if you are bothering them or they are cronically constipated.  Where did this come from?  When did people start thinking that having the shit face while you're interviewing someone is the way to go?  Some people think it makes them look more professional, yet I ensure you it does not.  You only end up looking like a dumb ass that was manufactured to be a douchebag.

Here's another one.  Purposely being socially awkward to establish your dominance.  Stop it!  You're not auditioning for some mafia sitcom pilot and you're not a lion in the jungle.  You're a person interviewing another person to determine if they have what it takes to get the job done and be a team player.  There's nothing worse than being interviewed by some clown that thinks they are better than everyone else.  Trust, you're not.  If you really want to go there, then how about this?  There is always something or someone better than you.  You can be serious and cool at the same time without making your guest feel uncomfortable.

Ok, last one for this section and that is the number of interviews being demanded per candidate.  Interviews should not go beyond 2 encounters.  I'm hearing companies calling candidates back for a 3rd and 4th interview.  What the hell!?  How inconsiderate can you be?  Excessive interviews only make your company appear as though it DOES NOT have its act together.  Candidates have family, jobs, and traffic to deal with.  They are looking for new opportunties. You either want them or you don't.  Their time is as precious as yours is.  Don't waste it.  A phone interview and a face-to-face is all that's needed.  Keep the face-to-face interviews to an hour, especially with candidates that currently have a job.  They most likely need to return to that job after the interview.

The Good Friend

You know I couldn't let this one go.  Come on, it's me.  Look, I'm all for bringing aboard friends that are qualified to handle the job.  Notice I said qualified, not certified (more on that later), but you must keep the process fair.  Keep it easy and remove yourself from actually conducting the interview.  After all, your name is on the line when you attempt to hire a friend and you better know for a fact they're qualified. If they fail, you look really bad.  It's best to allow other professionals to interview your friend so respect can be gained during the interview. The last thing you want is for your friend to come aboard and not have the respect of others because you snook them in.

Favoritism

The ultimate sin is influencing the interview process so that an attractive candidate is hired.  Not attractive in the sense that they look good on paper, but physically instead.  This is completely unacceptable and quite revolting.  Let me set the scene for you.  This is a big problem with male managers, so we'll use them in this example.  Let's say at some point, a candidate that looks like Kim Kardashian walks in...

For whatever reason, you find her attractive.  All of a sudden, you change your tune for this particular candidate. The only thought running through your mind is that you want her no matter what.  You find yourself trying to rationalize the wrong answers said.  You're smilling like a kid enjoying their first ice cream cone scoop.  YO, IDIOT! WAKE UP! Never, never, never even think about hiring a candidate based off their looks.  This is an immoral jackass move.  If the person is actually qualified for the job and it is determined that they are truly the best fit, then go right ahead, but do not dare immediately consider them without analyzing all the qualified candidates.

Female managers do this as well, but the problem is more common with men.

What You Should Do

We've gone over plenty of what not to do, so let's further solidify that by talking about what you should do to lay the foundation for not turning into a bad interviewer.  First, get a plan.  Determine the allowable time frame for finding the right candidates.  Determine the questions that will be asked.  Group interviews are common these days, so if you are going to allow this, make sure there are at least 3 interviewers per session.  This allows greater collaboration.  Do not hold large group interviews.  You'd only be wasting resources and increasing the chance of running out of time.  Hold feedback sessions for each candidate and rank them.  This will help measure who should get the job.

Don't be such a stickler for candidates with certifications.  You best believe that they in no way prove the candidate can actually survive in the environment.  Be honest about your environment, so the candidate knows exactly what they are stepping into.  Don't hide it.  Talk about all the bad and all the good.  No company is perfect and yours is certainly no exception.  Checkout the video below, "Interview Tips for a Project Manager."  At [05:30], the presenter touches on qualifications, yet mentions that certifications indicate the candidates' willingness to learn more about their craft.  I somewhat agree with this, but what you should do is ask them how do they keep their craft polished or if they do at all.  Books and online materials are a lot cheaper than throwing money at a certification.  Perhaps the candidate reads up on their craft a lot, which can be more valuable.

Thanks for reading. Keep this blog relevant by leading IT managers and actual workers here for laughs, insight, and further debates. Continue to submit your management stories to stupid.it.managers[(at)]gmail.com. Your identity will be kept private.

Teleworking

Oh boy, where do I start with this topic…  It appears that teleworking is governed by the same old wrinkled assholes that control the Oscars Voting Club.  In other words, they are managers that are against change, higher productivity, and the mental wellbeing of people that actual do the work.  If a company provides the teleworking infrastructure, then they should allow employees or contractors to telework as much as possible.  Especially, in high traffic cities that only increase the stress of commuters.  To name a few, Atlanta, Detroit, and Miami are well known to be pure hell for commuters.

Just so we’re clear.  Teleworking depends on the context of your job.  If your job doesn’t require a computer and all you needs is a phone, then a phone is your only requirement for teleworking.  If your job requires you to build products using a computer with private access to network resources, then that’s your requirement.  The latter is true for most IT projects.  Software engineers, whether building web, mobile, desktop, or service applications, use expensive and specialized software to provide needed value to the company.  The security model of these companies is typically setup so that work can only be produced by using internal machines.  That logically makes a lot of sense.  For a person to truly telework in this environment, they need the ability to remote into these internal machines.  Companies like Citrix make this extremely easy.

With that out of the way, let's get on these stupid IT managers that are so resistant to an obviously good thing.  Find any manager that is against teleworking.  Have them explain why they are against it.  They sound like complete babbling idiots because they can’t give you any logical answer to why they are against it.  Now, does that make any damn sense?  No, it doesn’t.  The reason it doesn’t make sense is because they are not telling the truth.  The truth is they DO NOT trust you.  Why?  They’re stupid IT managers that are insecure in their leadership ability.  A quality leader trusts their team.  A stupid one wants to believe they can control them, yet that control is only an illusion.  In their hearts they know this, yet fight to deny it.  To be honest, they were most likely poorly raised as children and didn’t receive enough love.

Managers need to burn this next statement into their brain with a blowtorch.  Companies pay for performance, NOT for office butts-in-seats (BINS).  I dare you to argue that stress free workers do not perform better than stressed workers.  I dare you.  Do you honestly think an employee that spends an hour in traffic coming to work is excited to be there?  They come in stressed and leave stressed because it’s an hour of stop-and-go traffic back home.  That’s 2 extra hours they could spend teleworking.  If you have 5 people on a project and they all roughly spend 2 hours in traffic a day, that’s potentially 10 extra hours that could have been used towards a project.  Teleworking isn’t the enemy; it is a gift of tremendous value.

Why companies spend money to setup a teleworking infrastructure if they are barely going to use it is beyond me.  That is a total waste of IT investment that could have been better served elsewhere.  Some companies only allow employees or contractors to telework 1 day a week.  Wow, that’s total bullshit.  What a great way to slap your workers in the face.  You’re basically telling them that you only trust them to telework 1 day a week and the other days, well, you know.  If you’re one of these managers that believe it’s the employees fault for taking the job, how dare you?  You may have been fortunate enough to find a job close home, but you certainly have no right to judge.  People have their reasons.  Being able to work close to home is a luxury that not many have.

How to manage a teleworking software development team?  It’s so easy.  Are you ready?  Don’t be a douchebag.  Allow the team to telework 90% of the time.  The other 10% should only be for meetings where face-to-face is actually needed.  Trust that your team will produce quality work.  Track their performance like you normally do.  Ensure that they are willing to come into work for emergencies.  A good example would be cases where the teleworking infrastructure is down or extremely slow.  Don’t be a douche if they do not respond to your email within 5 minutes.  Simply call them if they are taking too long and don’t be a douche about it.  People are allowed to take breaks just as they do in the office.

Teleworking could allow employees to appreciate the company more.  Being managed by douchebags is a horrible feeling.  I have been there plenty of times, which is why I refuse to be a poor leader to my team.

Thanks for reading. Keep this blog relevant by leading IT managers and actual workers here for laughs, insight, and further debates. Continue to submit your management stories to stupid.it.managers[(at)]gmail.com.  Your identity will be kept private.

Blog Introduction

After decades of well documented approaches to managing IT projects, these idiots still get it wrong. This blog pertains to not only the core project manager, but the other managers involved. They are the executives and directors that think they know what the hell they're doing. We could talk plenty about idiot clients, but it's the manager's job to influence their way of thinking to stop them from making mistakes.

I hold a PMP, which is totally worthless and I shall not renew it after it expires. It's a total croc of shit. Well, not totally yet one doesn't need a PMP to manage projects well.  This is a disease allowing PMI to get rich and is futher promoted by companies led by children.  If you know how to manage projects well, then you know how to manage projects, PERIOD. No one can take that away from you and you certainly don't need to continuously waste your money proving to others that you know what you know.

The goal here is to turn idiot IT project managers into smart ones and yet encourage the normally smart ones to avoid making stupid decisions.  We're talking about all the bad that people are afraid to talk about, so the good can flood in and wash it out.  Few of the posts will come directly from me, yet I am allowing people of various IT backgrounds around the world to submit their stories to me.  I shall not post who they are. If they are sending their stories to me, then that means they have one or more stupid IT project managers that will cry like a bitch and attempt to fire the whistleblower. Send your stories to stupid.it.managers[(at)]gmail.com.

If anything, this blog will be quite comical and informative.  Join me, will you?  Help me spread the word about this blog in hopes that it will eventually change poorly managed IT environments across the world. Most importantly, lead managers of all intelligence to this blog. If you are afraid to do so directly, be clever. After all, they do not have to know it came from you.

Alright, sports fans. Let the games BEGIN.