I recently posted an article
about getting ahead in the software development business. The post
focused on some key ideas to get ahead as a software developer in the
current industrial climate, from the employees stand point. According to
my weblog stats, my post has sparked some interest. I received an interesting comment from Seun Osewa,
who suggested that I write a post concerning views from the other side
– the manager’s stand point. During my 12 years of service in the
software field I have had some experience managing developers, and of
course I’ve been managed by lots of different managers to know good
from bad. So, below are some suggestions for managers of software
developers…

• Never Micro-manage – I once worked for a CEO who
  would meet with me 3-4 times a day for an hour or two at a time, when
  not in meetings he would come and watch me work in my office.  He
  could never understand why I had trouble-developing software. 
  Micro-management tells your staff that you do not trust them to do a
  god job; it also severely hinders progress with the constant
  interruption of workflow.

• Responsibility doesn’t roll down hill – Many
  managers believe in the tiered organizational structure: The CEO sits
  at the top, and then comes the upper management, project managers, and
  finally developers.  This concept usually dictates that the CEO
  and management level employees stipulate the work for the project
  managers and developers.  Project managers’ figure out the plan
  for the project and the developers construct it.  The only snag is
  that management typically does not have a faintest clue about what is
  involved with software development; they only understand business and
  money.  Likewise, developers do not always know about the latest
  business deals or the financial situation of the company to determine
  the best software to engineer.  It is the job of the project
  manager to sit in the middle, with knowledge of both sides, and
  determine how to make a product best using the talent of the developers
  whilst staying in budget and within time line.  To be affective in
  this position project manager should be prepared to listen to both
  sides.  Sadly, too many project managers shift the blame when it
  comes to responsibility, leaving the developers with the task of
  generating software in an unrealistic time with stupendous constraints,
  and limited understanding of the expected solution.

• Have a vision of the solution – Some
  would argue that that solution vision is the responsibility of the
  architect; others say it is up to the PM, in most cases these two roles
  are satisfied by the same person.  Whatever the situation the
  person whom delegates work to software developers should have an
  understanding of how the finished product should work.  Developers
  should not have to determine vision.  In most cases, will each
  developer have a different idea and over complicate the problem to make
  use of new technology.  This does not mean that the view of the
  developers should be discounted, just considered as a view, not relied
  upon.

• Getting requirements from management is like getting blood from a stone
  – Management (sometimes the client) won’t necessarily know what they
  want in a software product, just that it should do everything, continue
  to do everything in the future and cost relatively nothing.  The
  PM should work closely with management/client to establish a base set
  of requirements.  Requirements are the basis for software
  developers to perform their work and a necessity in any software
  development project.

• Be accountable
  – Most project managers have no issues holding a developer accountable
  for the estimates and work they provide.  Developers should expect
  no less from their PM.  A strong manager who comes through on
  promise, turns up to scheduled meetings, and takes responsibility for a
  late project or project gone bad will gain the most respect from his or
  her peers.

• Reward good work as well as reprimand for bad work
  – Software developers are people with feelings (rumor has it), they
  like to receive compliments.  Saying “well done” occasionally
  costs nothing, and will often inspire an individual to work just as
  hard on the next task or project.

• People have lives
  – It is a known fact that die-hard developers like to burn the midnight
  oil in front of a computer trying to solve a development problem. 
  Never exploit this fact.  Any developer that routinely works more
  than 50 hours every week will most likely burn out and end up leaving
  the project for another with less hours and more pay.  If a
  developer is asked to work a weekend or late evening once in a while he
  or she will most likely oblige, but, ask them to work late every night
  and every weekend (especially if no overtime exists)  and they’ll
  start resenting the fact that they have no free time for personal
  pursuits.

• Manage staff expertise –
  Developers come in all different flavors, some good, some bad and some
  extraordinarily brilliant (I will let you decide which I am).  The
  trick is to manage a development team and level expertise.  A team
  with one expert and remainder bad will result in the project failing
  because the expert will get tired of being a crutch for the poor
  performers.  On the other hand, a team consisting of only experts
  is a hindrance because no one wants to work on the mundane jobs. 
  The trick is to balance the team to utilize talent best, and match
  interest level.

• Have a plan – A
  good development plan (Gantt charts are best in my experience) will
  resolve any curiosity from developers.  Getting buy-in from all
  involved is important.  It is no good asking completion of
  software from developers if they do not believe in their ability to
  meet the objective.  Commitment upfront also makes it easy to
  consult a developer when they fail to meet a deadline.

• Stay in contact – Always aim to be reachable by
  your team and encourage them to do the same.  During development
  questions will arise, in which the answers are not always obvious from
  the requirements.  Developers should be able to get clarification
  on issues sooner rather than later to avoid developing unnecessary
  software.  Avoid calling team members outside of office hours
  unless the staff member has given permission to do so.

• Always be honest
  – Never keep your team in the dark, if there is important information
  in the company that affects the project or employment status, the team
  should know about it.  The exception to this rule is any
  information that requires clearance, is not project related, or
  divulging of information that would violate the employee/employer
  relationship agreement.

For the record: The above information is suggestive and is in no way a
bad reflection of my current project manager/employer’s abilities. The
information stipulated above is based on previous experience throughout
my software career.