The Trouble With Toilet Paper

Why the subject of toilet paper you ask? Well, mid-way through my time at my previous employer, someone in management or purchasing thought to themselves, “Hmm. How can we save some money on our lavatory expenses?  Obviously having the clean bathrooms cleaned less frequently is not an option, nor is perhaps having the lights shut off when the whole room is vacant… Ooh, perhaps, the urinals shouldn’t have been converted over to an automatic flush so that a gallon of water each time someone stands in front of it is wasted. No, no, they decided that it would be a great idea to buy cheaper paper.

Ok, so how does buying cheaper toilet paper and paper towels mix with management communication? I’m glad you asked! Looking from a high-level scope, it basically tells your employees that the company is so strapped for cash that they can’t shell out an extra $0.10 per roll in order for you to be more comfortable. Every time someone enters the bathroom and puts these things near their area, there’s a cringe at one of two possible outcomes: 1. The fact that it’s single ply AND cheap means that there are occasionally holes in the paper itself and now I have to use MORE of it to ensure that I don’t touch any of what it might pick up, and 2. I’ll chap what I have down there with the sandpaper finish that the paper provides.

Yes, I understand that this is all whining about something that is so trivial, but when you think about it, is it really trivial? When you decorate a house and put only large chunks of furniture in it with no smaller knick-knacks or sconces or the like, does it feel like it’s well done? I think the answer is no. And I can’t speak for everyone, but whenever I would go to the bathroom and see the paper towels (not to even mention the toilet paper), I think, “Management hates us.”  Well, maybe not so bold, but perhaps “management thinks we don’t deserve mid-range paper.”   Suffice it to say that my mood is in no way improved by the fact that simple things are being penny-pinched.

The other half of this is fascinating to me also. By providing thinner paper, people appear to use more of it each time they go. It’s not unheard of to see someone take the amount of paper provided by the automatic dispenser and yank down to obtain 3-5x the original amount to dry their hands. So all in all, it seems a wash because the money saved on quality is made up for in quantity. I haven’t seen numbers on it (so if anyone in accounting has any idea if the gain is worthwhile, please comment), but the point is not about cost.

While the world is shifting around all of us, layoffs are occurring, deficits abound, paychecks and benefits are being cut, why would an organization decide to do something mildly demoralizing to their employees which will be felt (literally) every single day and possibly more than once per day? HELP ME PEOPLE. Please explain! I know it’s a bit of a rant, but it’s not ABOUT the toilet paper; it’s about all of those little things: coffee brand change, or removal altogether, cancelling holiday parties, charging for things that we never charged for, etc.  The list can go on and on, but the reality is, the employees notice.

P.S. It should go over the roll, not under 😉

Should You Really Be A Manager?

Employees rely upon the knowledge and leadership direction given them by their superiors.  This is not a new or novel concept, however in looking at many of the managers out there where I’ve worked, the fact is that many of those managers are not capable of the job they perform.

I was placed under a manager recently, who exemplified the phrase “promoted to the level of incompetence.”  This man’s leadership style was not just bad, but entirely lacking.  He showed this through his actions as a manager in the following ways:

  • When asked by his superiors if a project could be done in a certain time-frame, he would never ask the engineers doing the work; merely being a “Yes man”.
  • During meetings, when one of his engineers would point out a problem, or a time conflict, he would chastise them in front of the group and all but guarantee that the issue was not an issue.
  • He wouldn’t accept the reality of what the current technology could do, and so, would offer solutions based upon a ten year old technology that had long been abandoned.
  • Little communication came from his office until the time had come for action to be taken.

I could continue the list, but suffice it to say, management and leadership were NOT his forte.  The problem is that this type of scenario occurs because of the intrinsic desire for people to move up in an organization, and for the established leadership to recognize good performers and try to promote them.

Ponder this.  You are a new engineer and you got your first job.  You love the job, and you’re engaged by the work, so you pursue your projects with fervor and excitement.  A year or three in, you receive a promotion for the great work you’re doing.  You continue and after some more years, gain another promotion!  Eventually the time comes to make a choice: do I stay an engineer, or move up into management?  Your manager offers you the option of either, and what choice do you make?

Think hard!

The answer for most people I’ve spoken to is “Management”.  I then continue probing and asking why management is their goal.  The response usually falls back to “pay is better, and you get bonuses.”  Now, this logic may very well be true, but the fact is that the position of manager holds its own responsibilities and duties that an engineer does not need to concern themselves with.  It also comes with those responsibilities that many engineers don’t understand.

But I can totally lead a team!

That may be, but it also might not be.  Leadership and management positions hold completely different requirements to be effective!  Engineers are detail oriented and focused on tasks at hand.  Leaders must be somewhat detail oriented, but predominantly they are big-picture people:

  • They must be able to see skills in others and determine how to deploy those human resources.
  • They must be able to prioritize tasks, even when the desired tasks may not be at the top of that list.
  • They must understand that an overly personal relationship with one member of the team can have adverse effects on the rest of the team.
  • They must be able to make the hard choices of when and how to fire employees (I’ll keep the PC sugarcoating out of it).

Obviously there are many more facets beyond the small list above, but the fact is that being a great engineer does not equate with being a stellar manager.  When contemplating your future, or when another engineer is thinking of their future as a manager, the real question to ask is, “Are you capable of performing the job?”

Money is great, but staff and senior engineers make a good amount of money.  If you are hesitant to meet new people, communicate effectively, or make the hard decisions that are required, then management really isn’t for you.  If you love writing code, making CAD schematics, debugging and getting projects done, it likely isn’t going to make you happy and fulfill your goals and interests.

Obviously, many people make the transition successfully, as evidenced by the large number of upward-bound employees at large software companies around the world, but the decision must be based upon more than “more money” or “more power.”  It should be based on your goals for your life.

What suggestions would YOU make to someone contemplating moving up in an organization?  Pitfalls?  Please share them in the comments!

 

Task Management 101 For Managers

As a manager, one of your jobs is figuring out how you can score the best projects for your team.  After all, the best team wins in everything!  That’s not true, of course, but it IS the implicit assumption that most people run by.  After all, the best teams get the biggest budgets, the best and highest profile projects, and the best rewards for completing those projects.

Alas, you must take the projects that your manager dictates, though this isn’t really a problem.  After all, someone is paying you to do the work that needs to be done, and they, like you, are always looking for the optimal way to spread their work over their resources.

So here you sit, looking at a list of tasks that must be completed by your team, and you are wondering where to start.  Here is my outline of the steps you should take to get your priorities straight and look AWESOME to your superiors:

  1. First and foremost are the deadlines.  Personally, while I despise day planners and do all of my scheduling electronically, I still print out hard calendars when I have to arrange tasks in my year like a puzzle (this happened a month or so ago when my partner and I realized that we had a hundred things to do and no idea when we could do them).  So sit down and put your deadlines on the calendar.  Don’t worry yet about the work required, just put down the hard-fast deadlines.  If one deadline is soft, put a mark for the desired completion date and give yourself a wavy line to indicate that it can possible go X days beyond.
  2. Now that everything’s on the calendar, the next step is ponder the tasks assigned to your team.  How large are they?  Field issues may be a line of code changed, back through quality assurance, and out the door.  A large project may be nine months long and require six people to complete in time.  Likely, if you’re managing your own engineers, you have had experience as one beforehand (I would hope), so use that knowledge and gauge the length of time required for each project.  If you can’t, leave it blank.
  3. Once everything’s “estimated”, you are on to the next task.  I put the quotes around estimated, because the reality is that once you have been in management for some length of time, your ability to accurately estimate development time is somewhat muted.  So, this step is actually starting the estimation process.  First, set up a meeting with your engineers and tell them about the projects.  By sharing the work expectations for the year, you are sharing that responsibility with them, and letting them know that your decision are not arbitrary.  Leave everyone with a copy of the task list and assign someone to estimate the length of each project.
  4. Now, you can setup a follow-up meeting, or you can merely have your engineers reply to your inquiry via e-mail.  Either way, you must receive a response so that you can move on to comparing your estimates with your engineer’s.  If they don’t match by some acceptable range of error, you need to discuss why they are so different with the engineer.  Both of you should indicate what assumptions you were making and where the time came from.  Mind you, a full-on Gantt chart is not necessary at this phase, but a good guess requires some thought.
  5. Now that everyone is in agreement about timelines, your task becomes to look at the priority of the projects.  Some, must be ready on-time (or before), while others are on the back burner.  There are also hot projects.  At my current company, we have varying degrees (though no one really knows which supersede which), from “hot” to “volcano hot” to “nuclear blast hot” and several more in between.  Field issues generally take highest priority, but there are some customers that make unrealistic demands that you MUST meet.  If there is any doubt as to the actual priority of the project, ask your manager and find out.
  6. Once priorities are determined, connect your estimates with your priorities with your calendar of deadlines.  Top projects generally are due first, and so, allocate them immediately following the current tasks of your engineers.  For the rest, focus on the priorities, and place the lesser ones further down.
  7. Last step (before deploying) is to determine which engineers should get which tasks.  You know your engineers and their capabilities, so do your best to place each project with care, because the engineer who gets a task they aren’t good at, likely will take longer and do a poorer job of implementation than another who loves that type of work.  Mind you, you’re not playing favorites here.  You’re simply playing to each of your team’s strengths.

Once you have the plan, you must deploy the plan.  I prefer transparency, as do most people I interact with.  No surprises there, and if there are any changes, notify the team.  Have a meeting and go over the plan and what your thoughts are.  Welcome changes if they are forthcoming, but don’t let the team dominate and choose their own tasks.  If you do, very likely you have an engineer who is shy and won’t speak up about wanting to do something.

What other helpful hints do you have to help with project prioritization?  Are there any steps I left out?

 

Lazy Co-workers, What Do I Do?

Now that I’ve addressed the main addressable points about working with lazy project managers, let me leave you with some general points.  First off, if you want to (and you WANT to, I know) resolve your problems with lazy people in general, this resolution comes through direct communication and documentation.  In fact, document EVERYTHING.  Any request you know that was made and not fulfilled, mark it with a description, date, and time (and if you want, a severity level). Continue reading “Lazy Co-workers, What Do I Do?”

Top Problems With Lazy Project Managers

I’ve already discussed that project managers are a necessary addition to a development team, as well as the fact that some are overzealous, which takes its toll on the team dynamics. Today I want to discuss why lazy project managers are actually terrible and destructive additions to any development team.

  • They don’t respond to information requests.  How many times have you contacted someone with a question and not wanted to receive a reply?  I’m not sure that’s ever happened to me, because generally I ask questions with the expectation of an answer.  This is no different for project managers, and in fact, the majority of their job is balancing the plates up in the air while shuffling people toward the end goal.  This requires providing INFORMATION when individuals need it.  An engineer, artist, designer, etc. should not have to ask twice, or even three times for an answer that is relatively easy to obtain.
  • They come to meetings noticeably unprepared. I’ve been to numerous meetings where everyone arrives on time, is ready to contribute and discuss, and all that is necessary is the person in charge to get things underway.  In fact, the project manager has that duty.  So, the meeting begins, he/she then asks what needs to get discussed.  Wait a minute, shouldn’t the purpose of a meeting be to have an agenda?  A plan of action?  Open ended meetings tend to be rather unproductive and useless, which is why we rely upon the manager of the project to get things focused.  Not knowing where people are, what they are to do, or why the meeting was being held in the first place is a huge issue with productivity in teams.
  • The behave reactively, rather than proactively. A sign of any truly great person is their ability to see problems ahead and act on those before they become a problem.  Lazy project managers, however, sit in their cubicles and no one really knows what they’re doing with their time.  The idea is based on the knowledge that they don’t go out of their way to resolve issues ahead of time.  Until YOU go speak to them, the issue doesn’t exist as far as they’re concerned, and in reality, once you leave their office, it gets shoved to the back burner for some YouTube amusement.
  • Are unresponsive unless 1. The boss asks, or 2. you go and talk in person. Everyone is interested in maintaining their job placement for as long as it suits them.  This is a fact of the working world, so of course, when the boss asks a question, the answer must be somewhat forthcoming.  With non-supervisor people, however, the communication channels tend to be more lacking.  In fact, sometimes, the communication becomes non-existent.  This forces the coworkers to actually go to the project manager with questions because they likely will never get answered via the telephone or email.
  • They destroy team enthusiasm and engagement. This is less a feature of lazy project managers, and more of a symptom of having one on a team.  When a project manager is performing their duties to the best extent possible, they provide a level of cohesiveness to the team that is hard to obtain any other way.  This aspect is removed, however, when the project manager is lazy with respect to their duties.  The ties of comradery never fully develop, and in fact, many times are reduced to merely “having to” work with your team on some project that no one cares about.

There are some things I’m missing in the above list, however, these are the most problematic issues I have seen in my time engineering.  Project managers can, and I would argue MUST, be the lynch-pin in any development project.  Success or failure to launch lies significantly on their shoulders, and as such, they should be treated with reverence and respect so long as they get off their asses and do it.

Mind you, more often than not, the project managers I have worked with have been proactive and successful, but those that cause problems are the ones that stick out in peoples’ minds.

What have I missed?  Am I off-base?  Let’s discuss in the comments!

 

Project Managers Don’t Listen To Anyone’s Ideas

You may have the greatest ideas on the planet, but if you can’t communicate their worth, no one will adopt them.  Not always is the problem that your ideas are the best, however, and so I’m going to describe a few reasons why your “great” ideas dont get adopted. Continue reading “Project Managers Don’t Listen To Anyone’s Ideas”

The Dangers of Feature Creep

 

In my prior post, Beware, Feature Creep Has Downsides, I discussed the implications of feature creep that would be of concern to managers in relation to time and money expenditures.  I’m going to delve a little bit further here to discuss employee engagement and something to think about for managers out there. Continue reading “The Dangers of Feature Creep”

Beware! Feature Creep Has Downsides!

Feature Creep: The misguided notion that somehow, more is always betterToday, I want to talk a bit about feature creep.  First off, let me say that I’m going to be performing my own voluntary feature creep in this post by adding a podcast version and a video one.  Take a look at the next post once it’s up and I’ll do a vid for the both parts (I was just getting long in the tooth by the end of this one).

Feature Creep

My programming friends, as well as most engineers I know, already understand the concept, but bear with me.  Feature creep is a situation in which a scope document was created with requirements before the project started.  Once underway, however, someone (usually at a higher level, or even a customer level) requests a new feature to be added.  It may be fairly innocuous, or potentially larger in scale, but in the end, it is another feature that was not included at the beginning.  One new feature really can’t be considered “creep”, now can it?  Ok, so the creepiness comes from the fact that it’s not one, but generally, many new features requested, not included in the original scope.

Who Cares?  That’s What We Pay Them For!

True, you (managers) pay your engineers to complete projects that need to be done.  And also true, that those features must be super cool if you’re asking for them to be done.  There are some problems with feature creep though, namely:

  1. More time is required to implement new features.  This sounds like a “duh” kind of statement, but for some reason, managers don’t seem to understand that fact.  Obviously, the engineers are inflating work estimates anyways to get some more time for browsing the internets (yes I pluralized that for fun).  I have found that in the majority of estimates, these kinds of inflations don’t occur.  Engineers design the plan and work the plan, basing their estimates on what they really believe they can accomplish.
  2. More time is required to implement new features.  Yes, I repeated myself, but this point is slightly different.  When new features are requested, the engineer generally NEEDS more time.  This means that the time-table of the project SHOULD be extended.  I have had so many situations in which features are requested that will take an additional week of work, and the project managers say, “We can’t push the date back.”  If you go to the store and have just enough money to buy your deodorant, if you pick up a container of ice cream too, some milk and cookies (I’m feeling sweets right now), walk up to the counter and plop it down, the cashier will NOT let you take the items with only enough money for the deodorant that you likely forgot on the way to the ice cream!  Just because you want more, does not mean you can have it just because you ask.
  3. More requirements equal more money spent.  Let’s assume that you can push the date out slightly for the new features.  That’s great, but what are you really doing?  You’re increasing the cost of engineering time, obviously, but you’re also increasing testing time too.  Sometimes, seemingly innocuous feature additions can have some very interesting bugs attached to them.  So not only are you increasing the engineering time for development, but also testing, bug fixing, and not to even mention documentation of the new features (I’ll assume your customer would want to know how to USE the new feature).
  4. More requirements can impact system design and robustness.  Not always is this applicable, depending on the scope of the implemented function, however, systems are designed to perform the tasks they need to perform.  If you need a simple system that accepts employee hours and comes up with summaries for year-end reports, your design will be MUCH different than if you need a system that will be scalable to incorporate plugins for new functionality that may be needed in the future.  Or, for example, if your system needs to handle a small amount of traffic by users, it will be designed with one particular database technology.  If, halfway through, you decide you want to deploy it on a massive scale with millions of hits an hour, that database technology may be insufficient.

Are there more implications to feature creep that I haven’t mentioned?  I’d love to hear your thoughts!

Update: Check out the sequel: The Dangers of Feature Creep

Dealing with Regulators and compromise

I presently work in an environment ripe with regulation.  The gaming industry (and by that, I do not mean video games for WoW players, or XBOX) is the most regulated market in the world.  More so than even health care, in fact.  As such, one of our largest points of contention revolves around regulators.  These regulators are not one cohesive body, but rather, different entities in every different jurisdiction around the world.  This poses some interesting problems with respect to how engineers and managers design products for release. Continue reading “Dealing with Regulators and compromise”