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.