Get Off Your Ass And Talk To Them

To preface: no, this is not dating advice.

One thing I’ve noticed during my time as an engineer is an over-reliance on technology to accomplish all communication ends.  By this, I mean that an engineer will sit at their desk and exchange a series of 20+ emails and instant messages to discuss a topic that could have been resolved with a two-minute face-to-face conversation.

Let me begin the discussion by saying that I am a text message fiend (as in, I send over 1000 a month).  I’m also a mild Facebook addict along with Twitter, email and various other social networking sites.  What can I say, I enjoy talking to a lot of people in a variety of ways.  There is nothing wrong with having some level of dependence on networking and communication tools; in fact, I wholeheartedly encourage people to reach out and communicate by any means at your disposal.  The unfortunate side-effect of our technology-driven society is that somehow, the longest-lasting time-honored and effective tool we have, has been largely forgotten: face-to-face communication.  Now, phone conversations also suffice for this to a large extent, but there is something about looking in someone’s eyes and watching how they elaborate on their topics with body language as well as voice inflection that merits a look at the physical proximity of communicating with others.

I recently moved across the country, from Reno, Nevada to Gainesville, Florida.  The move was not lightly taken, but was a huge next step in the life of my family.  This left us with nearly all of our good friends and direct family 3000 miles away.  We call our friends and family as often as we can, but to be honest, speaking with my mother and father is not the same on the phone as it was when we would go out to lunch and enjoy each other’s company for an hour.  By no means am I saying that you should take a different coworker out to lunch every day, but rather making the point that the phone simply is NOT the same as looking at someone while they talk to you.  I have also had many experiences where those 20+ emails went back and forth with no one really understanding what the other was trying to say, only for me to go physically stand in front of them and figure out that, in fact, we’re talking about the exact same problem and have more-or-less the same solution (obviously with some minor tweaks).  The language of an email wasn’t the right mechanism to see the nuances of the conversation, so while I thought my idea was being attacked, the other person was using different terms for their standpoint and feeling like I wasn’t listening.

A former coworker of mine was constantly reminded that his language and tone of his email was unacceptable.  Rather than adjusting his emails’ “tone”, he decided that it’d be easier to append a disclaimer to the end of his emails with rectification steps should his tone be considered inappropriate.  Needless to say, eventually this disclaimer disappeared because the problem was never solved by simply having it there in the email.  When you’d speak to him in person, you could see why people would see his tone as condescending and rude.  He freely spoke his mind and had some sarcasm throughout the conversations with him, however, none of it really was rude.  Back to the point at hand, the tone in his emails was the same, but without the lighthearted amusement that was included in his actual conversation, the essence of his discussions was lost and thought nasty.

Have you had an experience where a conversation through non-face-to-face means turned bad?  Or perhaps, clarified matters in a way that speaking directly to them couldn’t do?   I’m interested to hear!

 

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!

 

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”