# Sunday, May 10, 2009

Juan

Juan is a software developer working for a consulting company.  He is smart, conscientious and hard-working. One day, Juan showed up at his customer, was given a task and set off to his cubicle to complete it.  After working diligently for a week, Juan completed the task, checked in his code and asked for a new task.  A few days later, a tester opened a defect against Juan's task.  It turns out that Juan had misunderstood the assignment.  He had coded to the task as he understood it rather than as the task writer understood it.  Juan received clarification, completed everything correctly in a few days, and resumed his work.  No big deal, thought Juan.  In fact, the actual assignment was simpler than he had originally anticipated so he implemented it correctly in less than a week.

Over the next 6 months, Juan did a lot of very good work for the customer.  Any minor mistakes he made were very small compared to all he accomplished.

When Juan rolled off the project, he received an evaluation from his manager.  To his surprise, she asserted that Juan had trouble following directions.  She had never told Juan this was a problem, but the evaluation listed several minor incidents to support this point. After working hard and receiving only positive feedback for six months, Juan expected a better evaluation. 

Ammal

Ammal is a software developer working for a consulting company.  He is smart, conscientious and hard-working. One day, Ammal showed up at his customer and was given a task.  Before beginning this task, he verified that he understood it by articulating his understanding to the person who wrote the task.  Before writing a line of code, he was able to reconcile all discrepancies between his assignment and his understanding of said assignment.    He then set off to his cubicle to complete the task.  After a couple days of writing code, he had a better understanding of the system and the environment in which he worked, so he was able to identify some ambiguities in the task description.  He formed assumptions around these ambiguities, but he immediately sought a decision-maker to validate his assumptions.

When Ammal began coding, he understood his task and was able to complete it the first time.

After about a week, he checked in his code and asked for a new task.  A tester tested and passed his checked-in code.

Over the next 6 months, Juan did a lot of very good work for the customer.  Any minor mistakes he made were very small compared to all he accomplished.

When Ammal rolled off the project, he received an evaluation from his manager.  His manager raved about Ammal’s performance.  She specifically called out some of his accomplishments and made no mention of any minor issues.

What went wrong for Juan?

Ammal and Juan performed almost identically, yet their evaluations were considerably different. So where did Juan go wrong? 

In this example, a few things worked against Juan.

A bad early impression marred the manager’s opinion of Juan.  The manager didn't stop to ask why the miscommunication took place (Generally, both parties are to blame for a miscommunication).  She only noticed that Juan spent over two weeks on a task that should have taken one.  Once this opinion formed, it was difficult to change and everything the manager saw afterward was colored by her early perception.

Get feedback early and often

Ammal avoided this early bad impression by initiating communication early.  By being proactive, Ammal not only avoided the initial rework, he also established a communication channel, making it easier to get feedback sooner. 

This frequent feedback loop that Ammal encouraged helped him to correct misunderstandings before they cost him time and effort. 

Frequent feedback loops are a very popular strategy in software development.  Many agile methodologies suggest scheduling software delivery in sprints of 1-2 weeks in order to increase the frequency at which developers will receive feedback from business users.

But this increased feedback cycle can also pay dividends outside of software delivery.  On the projects I work, I strive to get feedback from my manager or managers as early and as often as possible.

Within days of starting on any project, I always try to schedule a one-on-one appointment with my new manager.  We met alone for anywhere from 15-60 minutes to discuss the manager’s expectations of my role.  I may have already received information about my role but I want to get that information from the person who is going to evaluate me.

I may have been hired to write code, but does the manager expect more from me?  Am I expected to mentor junior developers on the team?  Would it be helpful to write documentation on the features I implement?  Is unit testing important in this environment? Should I look for ways to improve the process in the department?   Are there particular areas of the application in which they needed more help?  I want to find out the kind of things that they value so that I can focus my energies there. 

I use this initial meeting to describe my experience, strengths and interests and to suggest ways that I might add value.  I always emphasize that I am here to add as much value as I can, but that I am looking to the manager to tell me where I can most effectively do that.

I take many notes during this meeting and use them to guide my activities for the rest of the project.

Different managers have different ideas about how their employees should work.   Some believe in controlling everything themselves and some believe in empowering users.  Usually a manager’s style becomes obvious during this early meeting.

The initial meeting helps to establish goals; but this is not sufficient.  We need to act on those goals – keep them nearby; tape them to your monitor or tack them above your desk. 

Send frequent updates to your manager and let him know what you are working on and how that relates to the goals the two of you set together. 

Send him a weekly status report.  Don’t ask if he wants or needs a status report – just send him one.  Every week.  No exceptions.  Even if you are on vacation, send him a status report, letting him know what is pending.

If possible, encourage your team (and your manager) to hold a daily standup meeting.  This meeting should be less than 15 minutes long (Forcing everyone to stand up discourages long meetings) In a standup meeting, each team member gives a quick status of what he did yesterday, what he intends to do today, and any impediments standing in his way.

These status reports and status meetings help you to stay on track; they help you to communicate your agenda and goals to your manager; they allow your manager a chance to give you frequent feedback; and they give you a chance to brag about your recent accomplishments, so they are fresh in the mind of the manager.

The punch line

On his next project, Juan adopted the strategy of getting feedback early and often from his manager and others.  As a result, his work quality improved a little but the perception of his work quality improved substantially.  This time around, Juan’s performance review was as good as Ammal’s.  Which is where we get the old expression: “If you’ve seen Juan, you’ve seen Ammal.”

Comments are closed.