How to manage projects and developers in the software development business

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

  • 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 – According to Shravan Gupta 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
  • 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
  • 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.

2 thoughts on “How to manage projects and developers in the software development business

  1. Seun Osewa

    I’ll keep that in mind for a time when I’ll have people working "under" me. Nice update to the ‘boss is always right’ post 😛

  2. http://

    <br>Article is all good . But what if the apples in team are really below sea level and we have fixed bid project with tight deadlines …
    <br>Is there a way to push them upto – thinking level – undertand the way ti test the application etc….

Comments are closed.