Tag Archives: Management

Live Earth and Long Hours

So, who watched the Live Earth concerts this last weekend?  Okay, okay, who you even knew there were a series of International rock concerts supporting the conservation of Earth’s natural resources happening this last weekend?  

Live Earth was especially significant to me because I’ve be working on a SharePoint based web site for the launch on behalf of Conservation International.  My diligent software team and I spent many agonizing hours working around the clock to get the site up and running in a number of weeks for the launch data of 7/7/07, and the site was a great success.  This got me thinking, what is it I did to motivate my team into working into the twilight hours?  Where do other project managers go wrong under pressure?  I can only surmise, but the the following is a short list of some of the things a lead can do to motivate his/her team at crunch time….

Set Expectations – In my experience, both as a project lead and a developer, this is an area where many project managers go wrong.  If you expect your team to stay late and work overtime then you need to communicate this fact.   It is no good getting upset when employees go home at the regular time and complaining after the fact if you never set your expectations up front.

Get the Team Buy In – Every team member requires some form of motivation to drive them into working late.  For some it’s overtime pay, for others it is the thrill of seeing their hard earned effort go into production.  Either way, it is important that each member of the team have some level of responsibility and accountability on the project. No man is an island, and it is important to realize that large projects are only ever successful when effort is put in by the whole team.

Work The Hours – If you are asking your team to stay late and burn the late night oil then it is only right that you stay and work the hours with them.  This ensures you are available to handle any late night decisions, motivate employees suffering from lack of sleep, and keep the moral level high at all times.

Feed your Staff – Work goes much smoother when your team have full bellies, so if you have to dip into your pocket to buy pizza it is a small price to pay for the success of the project.

Reward Good Work – Honest sincere hard word deserves reward, so if your team pull out the stops and make a success then they should receive both recognition and reward for their work. 

Respect Personal Agendas – Once you ask your team to work beyond the regular 9-5 your are encroaching on their personal life.  Significant partners, children, and family members become concerned when they no longer get to see their loved ones for a few days.  So if members of your team need time to align their personal life cut them some slack.

Be Prepared to Roll Up Your Sleeves – During crunch time anything goes.  As project manager you are responsible for the success of the project, and if that means helping out with development or data entry then so be it.

Watch for Burn Out – So you’ve motivated your team to work late, only a little too much, to the point that one of your team members is looking worse for wear and needs to rest.  Do not be afraid to enforce sending someone home or at least taking a break – happy alert team members make for a successful project. 

Tools of the Trade

Anyone who knows me, or has been reading my blog of late must know that I have had my head buried in my new job. A career change certainly has its rewards, but also involves a learning curve. Since my time is precious of late (no surprise that blogging has taken a back seat), I thought a good theme for a blog post would entail the tools that save me time. My new role involves more client face time – meetings, time on the road etc, in fact I have never seen my work calendar with so many occupied blocks of time, so my dependency on keeping my schedule in order has never been more important. Below is a list of the software applications that make my career that little bit easier to manage every day….

Microsoft Exchange 2007 – Yes, I hear the groans, but before I receive the comments about rigid IT departments who break out into a rash with the mere mention of Microsoft Exchange, let me tell you why the latest version – Exchange 2007 – is so productive. No matter what anyone says, I refuse to believe that any other mail server is as feature rich as Exchange. Taking aside the fact that Exchange is only happy when tied at the hip with Active Directory, in my opinion it is hands down the best messaging platform. Exchange has provided Outlook Web Access since version 2000, and the newest version still provides the same rich AJAX-like-user interface (introduced long before AJAX was a common term) to emulate the rich client version in a web browser. The new version integrates with SharePoint, allowing me to access my document libraries from anywhere on the Internet. Since version 2003, Exchange has supported MAPI over HTTP, and because my employer is nice, I am able to access my mailbox, calendar, and tasks using Outlook on my work laptop at home, as if I never left the office. Finally, my favorite part about Exchange – I can synchronize with my Windows mobile device, so can receive push email, calendar and tasks whilst on the road – how nice is that?

Outlook 2007 – I cannot talk about Exchange without mentioning its partner in crime – Outlook. Once again, find me an email client that can do half of what Outlook can (Outlook Express does not count because it is technically Outlook on a diet). I mentioned MAPI over HTTP above, which I use constantly when away from the office. 2007 includes an RSS feed aggregator, and like OWA, Outlook 2007 now connects with SharePoint to access document libraries, task lists and calendars. If you are an SMS hound, you can also send and receive SMS messages using the Outlook Mobile Services. Personally, I think the Internet Calendars feature is a lifesaver – I can access my personal Google calendars and overlay my off work schedule with my daytime schedule to see what the week has in store.

Windows Mobile – My Pocket PC phone combo (HTC PPC 6700) cost me a chunk of change when I brought it, but almost a year later, I never regret my decision. I cannot count the number of times I have been away from my computer and needing to get access to important information in an email, calendar information, or contact information. I think of my PPC as an extension to the office –the other day I was stuck in traffic on the way to a client meeting. So, I called my boss for my client’s telephone number, so I could inform them I would be late, and he was able to email it to me without having to relay numbers over the phone.

Google Apps for Your Domain – For a while, I was hosting an Exchange server at home to look after my email, mainly because I wanted email at my own domain name and I could not stand the half-baked web clients offered by the cheapest hosting clients. Only problem was is that, although Exchange is very nice, it is a problem when something goes wrong. Not so long back, I remember pulling an all nighter trying to get my server back online after a disk crash. When I heard about GAFYD – free email hosting for your domain email, I decided to let Google take the responsibility of backing up my email and worrying about offline issues. As far as everyone else is concerned, nothing changed; they can still email me at the same robgarrett.com email address. However, I get the feature rich web client of Gmail to access my domain-hosted email. No more headaches if my broadband connection goes down, or concerns with hardware redundancy.

Google Calendar – My wife and I used Google calendar long before I switched to GAFYD, which also uses the same calendar engine. Google calendar provides me, and the family, with a nice UI for shared calendars, and because it is Google, I can search for any appointment in seconds. Prior to Google, my wife and I were in constant battle over miscommunication of appointments – paper calendars were lost, emails about upcoming appointments went astray, and I found out about most planned events on the evening before they happened. I guess you can say that Google saved my marriage.

Foldershare – There is nothing more frustrating than finding out that all-important file is on another PC and you forgot to copy the darn thing over before a big meeting. Fortunately, there is Foldershare. FS synchronizes files between multiple computers of your choice, and I use this application exclusively to manage access to my important files.

Groove 20007 – Much like Foldershare, Groove enabled me to synchronize my files with other computers and peers, only Groove has many additional features. For one, Groove permits collaboration against SharePoint document libraries. So, my peers and I can work on documents together and when ready I can synchronize the changes to our company SharePoint server for archival.

I could go on, many more products exist that enable me to shave vital minutes off my day, but the above list contains the main tenants. Between these applications, I can collaborate on work items, schedule appointments, stay in touch with the office, plan my weekends, and gain access to all information when working remote – pretty cool.

How To Tell If You Are Being Micromanaged

It happens to us all – you get that annoying boss that just cannot handle letting you do the job without interruption, and insists on keeping tabs on every task he/she assigned you.  The following is a list of sure ways to tell if it is time to get on the bus and leave “micromanagement world”…

  1. You meet with your boss every day (sometimes more than once) – in each meeting he or she will ask for a status update.
  2. You are asked for delivery estimates for the same task more than once a week.
  3. Tasks are issued in precise patronizing detail, and all too often verbally.
  4. No matter how hard you work on a task, the result is never good enough for your boss.
  5. You spend more time in meetings than actually implementing the solution.
  6. You have a spare seat in your cube/office and your boss occupies it regularly.
  7. When away from the office, your boss will call you every day to make sure you’re at work.
  8. You receive calls from your boss on weekends/evenings and if you’re out sick.
  9. Your boss has intricate knowledge of your current tasks, down to the level of nitty gritty implementation.
  10. Your boss coaches you on the precise wording to say to another colleague when asking for something.
  11. You feel stressed and exhausted before you have even begun implementation.
  12. Use of headphones is impossible because you cannot complete a music track without interruption from your boss.
  13. Bathroom breaks are monitored by your boss, if you take too long to shit he/she makes a remark.
  14. You prefer to work outside office hours because you are more productive that way.
  15. Your boss never goes on vacation for fear that the company will collapse in his/her absence.
  16. When leaving the office for lunch you receive a call on your cell about work related issues.
  17. Your boss is involved in technical decisions when his role is at a much higher level.
  18. Your boss talks more than he/she listens.
  19. You are provided with a company cell phone, pager, laptop, etc, and are expected to be on standby 24×7.
  20. Working from home is strictly forbidden, even when it would be more profitable for the company.
  21. Your boss has an opinion on your visual presentation, even when you meet the company dress code.
  22. Meetings are scheduled with 5 minutes notice and sometimes at close of business.
  23. Your boss eats his/her lunch at your desk.
  24. Everything is an emergency and cannot wait.

I can think of a few more, but in an effort to keep this post short I’ll leave it at that. [;)]


Disclaimer: The above list was generated from past experience, and not necessarily reflective of my current employment.

Management Advice

I love nothing more than reading blogs that give out useful advice, and even more so  if the author injects humor into their posts.  Trizle is by no means an exception in the above statement, and I find myself amused by some of the daily posts, as well as a feeling of empowerment having gained some useful knowledge.

Today’s post, titled “How to Drive Your People to Meet Customer Deadlines,” certainly is as witty as previous posts, but I have to raise an eyebrow on the suggested technique called “No Deadline Left Behind.”

The synopsis of “No Deadline Left Behind” is that managers need not accept constant delays and fake promises of delivery from worker bees (named Johnny in this case) if they deduct payment form the worker each time a project misses a deadline.

  1. For instance, say you hire Johnny for $1000 to write a white paper for customer Craig. Craig needs it done 7 days.
  2. If Johnny doesn’t get that paper to customer Craig in 7 days, you remove $200 — returning those Benjamins to customer Craig.
  3. Now, if Johnny again misses it on the 8th day, you remove another $200. And, so on — until the sucker’s free to customer Craig.

Seems simple enough… if we lived in a dream world.  Yes sadly we live in a world where employees like to do as little for their money as possible (typically) and managers want to extract as much work out of their employees (typically) to meet the deadlines imposed by managers further up the chain, or by paying customers – it’s a broken equation, but what most expect from 5 days out of a 7 day week.

Personally, I think employees – let’s call them developers in my world – need to take more of a responsibility for project deadlines.  It is not acceptable to promise delivery by a certain date and then blatantly blow the deadline without some concrete evidence of some unforeseeable problem, or direction change by management or customer.

But what if you work for a manager who does not live in the real world?

I’ve lost count of the number of fellow employers who have said something like the following: 

“The project was doomed from the start, there was no way I was ever going to meet my deadline.”
“The customer changed their mind mind flow.”
“My boss would not leave me alone to complete the project.”

All of the above and more are signs that you work for a “bad planner,” and if you’re the employee charged with making the project work at a lower level then expect unreasonable deadline expectations, overtime, and hair pulling to make the project successful.

My immediate thought on “No Deadline Left Behind” is – why should the worker-bee take the hit for a missed deadline?  There’s an art into providing a perfect estimate of work, and many employees get it wrong (including myself occasionally), which is why it is the job of the project manager to establish reasonable and workable deadlines/estimates with each employee. Surely the project manager should be pitching in to the refund collection along with Johnny?  And what about upper management? Your boss’s, boss’s, boss’s boss is so far up the food chain that they cannot possibly be concerned with the finer points of implementation, and any small change made to the project for overall gain can have a huge ripple affect through the lower levels – should he/she take a hit when the project overruns?

I am not sure there is ever a right answer to the enterprise project paradigm, but I am quite sure that the extraction of money from workers for delays will only incur a decrease in motivation within the ranks and mental images of slave drivers with whips.

What makes a good manager?

I had a great Christmas this year, eating, drinking and conversing with family (as I always do).  This particular year, I got talking with Uncle Bob – a retired product manager from IBM – and we were conversing about what qualities make a good manager.  The post feast banter was riveting, so I decided to blog about the qualities that I seek in a good project manager in the software industry:

•    The project is the main concern – any manager who is not giving top priority to the project has another agenda.  Typically, the project manager is solely responsible for a failed project, but everyone on the team suffers in the long run. The client, the contractor company, middle management, and all the software engineers.  If all project decisions made are in the best interest of the project then the project is more likely to be a success.

•    Be free with information – Managers should never be “black hole” people when it comes down to important information about a project.  A good project manager should be able to share his/her information and be free from concern about reporting employees gaining power from increased knowledge.

•    Co-ordinate with staff – Along the lines of being free with information, every employee on the project should be aware of what their peers are doing.  In the case that one or more employees are out of commission, the project manager should be able to delegate responsibility of work to another member of staff.

•    Control the road map – As a manager, I would not run a project without a project plan any more than I would drive across the country without a road map.  The project plan is the living breathing core of any successful project, which evolves with the lifetime of the project.  Projects should never start without a baseline project plan and during the life of the project; the plan should always reflect the current progress and next steps in the project direction.

•    The client is always right… – within reason.  It is the job of a project manager to set the expectations of the client with regards to what work can be completed in a finite period of time with a set budget.  The project manager should never promise more than the development team can deliver, causing burnout.  On the other hand, it is important to provide the client with solutions to some of their requests, and good communication with the development team can assist in the creation of a good solution.

•    Never micro-manage – This is the sin of all manager tactics.  When you micro-manage your staff you’re affectively telling them that you do not trust their abilities.  Micro-management usually leads to frustrated team members, and the project manager looses respect of his/her peers.

•    The buck stops here – Some difficult decisions are sometimes called for in the lifetime of a project.  These decisions can be technical, staff related, or just about taking the next step in the project roadmap, but no matter what the quandary there needs to be a team member willing to make the hard decision.  It is usually the responsibility of the project manager to make these types of decisions.  Everyone on the team is entitled to an opinion (and should be asked), but once a decision has been reached everyone on the team should abide by it.  If things work out, great, but if not, the project manager is solely responsible for taking heat on the mistake.

•    You’re the leader, so lead – The development staff looks for a clear direction from an individual who can overview the whole project.  The project manager should be strong enough to drive the project according to the project plan.

•    Be a people person – Project management, and management as a whole, is not just about being in power and delegating work to other individuals.  A great project manager knows how to manage his/her people so that they are motivated, non-frustrated, and have a clear understanding of their role in the project.  Make no mistake, project management is not an easy job, and it is not a bolt on task to a regular developer role.  Management of staff and project can take a while to get right, and not everyone is cut out for the job.  Bottom line – if you want a managerial role, you need people skills.

Managing Bad Apples

Continuing on with my theme about managing
software developers
, and getting
ahead in your career as a software developer
, this post discusses poor performing developers and what steps can be taken to protect the project.

It is a sad fact that the software IT industry is awash with many individuals
that claim to be expert developers in the field in which they practice, but in fact,
they lack the skills required for the simplest of software development
positions.  Often is the case that these individuals will appear to have
the necessary skills on paper to secure them a job on a development project and
the only thing to stand in their way is a good interview screening process. Therefore,
what can be done to avoid jeopardizing a project if, as a project manager, you
find yourself with a bad apple on the team?

  • Recognizing a bad apple – Most managers can spot a duff developer on the team, however
    poor performing individuals can often go unnoticed on software development projects,
    especially large enterprise projects involving more than a handful of
    developers.  It is the responsibility of a good project manager to have an
    accurate understanding of every team members past and present performance
    metrics.  The typical approach taken by many project managers
    is to maintain a project plan containing project tasks assigned to
    each developer, along with original estimates and current percentage of work
    complete. Project planning tools, such as Microsoft Project, can provide project
    managers with an indication of where the bottlenecks exist in a project and
    which developers are failing to meet the quota. A good project manager should always maintain a history of all
    under his/her supervision, both for future performance reviews and for
    comparison of previous accomplishments with the present.  Regular
    design and code reviews and peer-to-peer staff meetings can also
    indicate a problem brewing.

  • Cauterize the wound

    Once established that a developer is lacking performance on
    the team it is important to isolate them from any tasks deemed critical to the
    success of the project. The developer will work on less important tasks until
    the proof of increased performance and understanding of the more crucial tasks
    is evident. It is important not to chastise
    the developer for their poor performance at this stage. However, the developer should
    be aware of their failure to meet the project expectations.

  • Establish a cause – There are many reasons why a team member may
    fail to meet required project expectations. Failure to complete one or many tasks in a
    designated time period is not necessary an indication that the individual is
    incompetent in their role. Other factors, such as lack of training for the task
    in hand, lack of motivation, failure to apply talent in the correct area, bad planning,
    or a long number of hours etc, can influence the ability in completing a task.
    External factors such as a stressful home life, lack of sleep, a difficult
    commute etc, are other reasons.The
    project manager should invite the developer to share an explanation of inability
    to complete tasks assigned before concluding lack of professionalism.

  • Provide an opportunity to make amends
    – Once all external factors have been ruled out or addressed, the developer can show promise and future worth to the
    project when provided with an opportunity to gain the confidence of the
    project manager.  A good way to provide this opportunity is to
    assign an obtainable task, which both matches the skill set of the
    developer and occupies a short time period.  It is the duty of the
    project manager to monitor the task progress to determine if the
    developer is showing progress.  The project manager must define
    the expectations up front and the developer should be clear on what
    objectives they must meet to complete the task.  This
    “hand-holding” technique requires extra time from an otherwise busy
    project manager, but secures the project manager with an understanding
    of the ability of the developer before any drastic action is required.

  • Cut your losses
    – If the developer continues to show little or no promise of becoming
    an asset to the project and continues to be a liability, the time has
    come to cut them loose.  It is a sad day when a project manager
    has to fire a member of his/her development staff, but necessary for
    the good of the project.  Stale developers that do not provide
    useful input to the project can drag a project and impede the efforts
    of other useful developers on the team.  Never terminate developer
    (or any other team member) for personal reasons.  Plenty of
    guidelines exist for terminating an employee.  In a future post, I
    list some of the ways to fire a member of staff, whilst retaining
    professionalism and avoiding uncomfortable conflict.

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.

How to get ahead in the software development business

I’ve been working in the software development industry for a number of years now, so I
decided to post some useful information for others, who maybe new to the scene, and are looking to get

I’ve been a developer on many a software project, been a project
leader and also provided consulting services. During each of these
roles I’ve had the pleasure of working with some talented individuals,
who have taught me a thing or two. I’ve also worked with some
dissimilar individuals who have caused a great deal of frustration in
my career, but never less I have learned from them also – how not to do

I’ve listed some tips for getting ahead below. At first glimpse they
may appear obvious, but it’s surprising how many developers and project
managers do exactly the opposite of what I’ve listed.

  • It’s a job not a hobby
    It took me a long time to learn this valuable lesson. Like many other
    software developers, I have a passion for writing software. Over the
    years, since I started at a young age, my passion has brought me
    through college and into a career. I’d effectively hand crafted my
    career from a personal interest – bonus! However, I soon found out that
    writing software for an employer is radically different to throwing
    some code together in my spare time for the hell of it. Namely, my
    employer is spending large amounts of cash on my efforts, which means
    they have some say in how I write software. It’s quite amazing how
    software deadlines, dictation of technology tools, budgets and
    unrealistic time lines can really put a crimp on creativity. Before I
    knew it I was waking up and not liking the very thing that had kept me
    up enthralled to all hours of the night during college. When I
    complained of this problem one of my colleagues politely reminded me
    that this is “work” and why I’m getting paid. He suggested that I save
    the wild creativity to efforts outside of work.

  • Process brings about order
    – Get used to process. Unless you’re working on a small project with a
    handful developers and the software is small-scale, it’s likely that
    your employer will want you to adhere to some soft of process. Process
    can range from simply documenting software design to a large software
    design methodology, such as CMM or RUP.
    Either way, you’re employer will most likely expect some sort sort of
    design documentation, work breakdown schedule and user manual.
    Software development is no longer just about throwing code into the
    machine and praying it’ll work – brush up on different methodologies,
    learn how to use tools like Microsoft Word and Microsoft Visio and ensure you can
    articulate thought well in grammar, not just code.

  • The Boss is always right – seems like an obvious
    statement, right? This didn’t stop me becoming very frustrated with
    the CEO, of one of my employers, because he insisted on micromanaging the
    project, imposing unrealistic expectations on results and always
    looking for a cheap way around a problem, which usually ended up
    costing the company more money in the end. One day I woke up and
    decided to go along with all his decisions. I still offered my best
    advice in every situation, but no longer battled for my point when my
    advice was dismissed. As a result I was respected more, and when the
    project failed, as I predicted, the CEO took the wrap for the mistake.

  •  Do whatever is asked of you by your superiors – There’s a fine line here between getting ahead and brown-nosing.
    When the Boss is looking for a volunteer to perform an extra task on
    the project do your best to sign up and complete the request. The aim
    here is recognition, you want your superior to associate you with
    reliability and the ability to get anything done. Once you succeed in
    this lesson your boss will start looking for you when he or she needs
    someone special they can depend on, this will later help you to gain
    promotion. Never go asking for extra duties, this would be classed as
    crossing the fine line I spoke of above.

  • Always go the extra mile – The employees that are
    always remembered are those that stayed late to fix a problem in a time
    of crisis. Every job I’ve found myself in has involved at least one
    late night, and in some cases a round-the-clock effort. The reason for
    the crisis and need to stay late is irrelevant, you employer will soon
    forget the problem, once solved, but remember those that stayed to fix
    the mess. Even if you cannot assist in providing a solution to the
    problem, being around to provide moral support for those who can is a
    sure way to secure a position on the list of heroes.

  • Never forget your peers – Whilst doing a good job of
    securing your position with your Boss be sure not to forget your peers.
    Your peers are the people that will stay late with you in a crisis,
    help share the burden of work, and be working along side you for every
    day in your career. Never climb the ladder of success at the expense of
    your peers, this can only lead to animosity and isolation from the
    group. Some organizations rate individuals based on recommendations
    from peers members of staff, others simply watch to see how well their
    employees work in a team. Either way, being a team player is very
    important, without a team there is no solution.

  • Estimate conservatively – You’ve gone to the trouble of
    signing up extra tasks to impress your leader, but you fail to deliver
    on every task your assigned – not good. For you to get ahead in this
    field successfully you need to be known as an individual that
    accomplishes their goals. When asked for an estimate on how long it’ll
    take to complete a software task be sure to take into account: margin
    for error, testing time, documentation time and deployment time –
    writing the code is only half the battle. Always over estimate by at
    least 50% – you’ll be liked much more if you meet expectations.
    Some project managers will add extra margin to your estimate, others
    will assume you’ve over estimated and expect you to come in ahead of
    time, try to find out how your project manager leans and set estimates
    accordingly. On the rare occasion that your project manager sets
    impossible expectations, stick to your estimate and go on record with
    your assessment – do you best to meet the demands with what you have to
    work with.

  • Worry about today, not tomorrow – Unless you’re tasked
    with future project predictions it is likely that the CEO or another
    individual high up in the food chain is responsible for planning where
    the project is going next. As a software developer or project manager
    your only concern is meeting the project objectives of the time. This
    objective might involve writing requirements for the client, or
    implementing the software, either way the road ahead has been laid for
    you, so there is no need to concern yourself with future endeavors.
    My friend and colleague gave me a great analogy for this, it went something like – “we’re
    all passengers on an airplane, we should enjoy the flight and not worry
    about the destination, the destination is unemployment