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?