Sunday, October 15, 2006

Effort versus output, and the implications on performance management

Writing good code is not easy. Anyone worth his software engineering salt can recall the two (or more) hours spent on a problem whose solution was one line of code. Where does this leave managers who need to assess performance and rate engineers on their contributions to the organization? It all depends on your management philosophy.

In an effort-driven model, those engineers who work hard, stay late, come in on the weekend, and deliver good code (regardless of lines of code or volume of modules) tend to be seen as top performers. The key flaw with this approach is the frequent inattention paid to the question: "How long should it have taken them to deliver this software given the constraints under which they were working?" Weak managers are often fond of giving the benefit of the doubt to people they see "working hard." If, however, these individuals' effort is high due to their lack of skill, lack of organization, decreased analytical ability, or other factors that indicate "lower performance," then the assessment does a disservice to the highly-talented engineer who accomplishes two people's work in a regular week. Mind you, I'm one of those who believes in "all hands on deck" when times are rough... but have little sympathy for undisciplined time wasters.

Going to the other extreme, a pure results-driven model is also flawed. Comparing the performance of two individuals based on the number of modules they created in a given time period ignores the difficulties each faced or the inherent complexities of the modules in question... which can lead you to reward unequitably. Furthermore, a results-driven model often disregards attitude, which is an important part of organizational talent management. If someone's attitude is "I will put in only 8 hours no matter what," you should ask yourself whether you can rely on this person when facing the tough battles that will invariably come your way. In some cases it is better to have someone with less talent and a great "win at all costs" attitude than someone who is an expert but lacks the stamina for trench warfare.

Since neither model is perfect, what is a manager to do? My approach is to use a personally-developed model, lovingly-coined the Subjective Assessment Technique. I will just refer to it as the SAT from now on. After struggling with purely quantitative measures that yielded the wrong results, I have come to believe that the SAT is the most pragmatic method. Its main drawback is the perception that the final assessment is based on the whims of the assessor, thereby leading to inequities among the employee population. As will be demonstrated, this perception is inaccurate. That said, the method does cause some unpredictability from year to year... though marginal. The key tenets of SAT are as follows.

First, become comfortable with the idea that your performance assessment is subjective... no matter what approach you take. As the "boss," the company has empowered you with, among other things, managing performance of people vital to its success. If your subjective assessment is wrong and a top perfomer either leaves or decreases in productivity, it's something you're just going to have to live with.

Second, assess the individual's objective results independent of effort. How do these measure up to not only what you expected the individual to achieve but also to what her peers accomplished? Expectations are funny animals. On the one hand, they clarify for us what we should do and set a baseline to surpass... and on the other they can limit some people from unleashing their full abilities. That said, contributions to the bottom line and long-term success of the company are what matter in business. Measure results in terms of both business outcomes as well as engineering output. Failure to take business relevance into account can lead you to grow talent in a business-irrelevant direction.

Third, assess the individual's commitment. Is this someone on whom you can depend to deliver even in troubled times, or someone who delivers well when all of the stars align? Will he stand by you when the cannons start blasting, or will he put in his shift and then retire to his quarters when the clock strikes five? The commitment exhibited by someone can be transient, affected by such external factors as family needs, outside interests, priorities in life, etc. My approach is to give individuals the freedom to decide their level of commitment rather than force it upon them. We are people first and employees second. Each person must live his life in accordance to his own value system... and make the priority decisions needed to achieve his personal goals. Forcing someone to work 60-hour weeks (other than during short stints) not only creates personal tension, but also makes you the driver of someone else's life... which I would personally discourage. There is no moral or ethical basis for your forcing commitment... so don't do it. That said, you should recognize and reward when someone willingly exhibits higher commitment consistently. Those for whom work is a priority should receive the rewards of this choice, just as those for whom a non-work activity is a priority receive its rewards. A last note on this topic is to focus on gauging commitment during the current performance period. Exceptions should be made for temporary exigent circumstances, so get to know your team members and what's going on in their lives.

Fourth, seek informal feedback from people who work with each team member being assessed. While this is similar to 360-degree feedback in principle, I've found that formal feedback tends to be an inaccurate assessment of true performance. How many people will praise someone who competes with them for ratings, or how many will speak constructively of a team member on whom they depend for support on their projects? The best feedback is informal, such as conversations about project progress and such. While you may have personal views of someone's performance already, orient your feedback-gathering efforts on a "balanced view": positive as well as constructive or negative aspects.

Fifth, spend some time job-shadowing each team member to understand what issues she is facing and how she resolves them. Spending anywhere from a day to a week doing this is warranted, especially if you are on the fence about someone's performance. Job-shadowing peers who perform similar roles is also a good idea, especially if you don't personally know what it takes to fulfill the responsibilities of the person's job title.

Sixth, compare individual results and commitment to peer performance. Given that everyone is different and works on different projects, it may sound counter-intuitive or impractical to do this. It's easier and more relevant than it seems, actually. Regardless of temperament or task, you can abstract people's behavior into invariant themes, such as drive to deliver results, planning/organization, analytical ability, learning aptitude, quality coding discipline, problem solving... the list continues. Determine what behavioral themes--sometimes called leadership traits or competencies--are important to your organization, and what the optimal strength configuration is for your team. As Aldous Huxley astutely pointed out, "Even Epsilons are useful. We couldn't do without Epsilons." His observation, though made in a grimmer context, underscores the fact that even people without "higher-level" skills are useful if they have other strengths necessary for society. Every software organization needs good planners, good drivers, good coders, good testers, etc. in order to thrive. It is both difficult and impractical to find good planners who code well... or to seek other "ubermench" combinations. It is, however, easy to compare among planners or coders or troubleshooters and see who shines. Whether or not a troubleshooter is intellectually superior to a planner is irrelevant. The important point is that you need both. Pick the star performers in each of the roles you need, if you want to thrive. However, if someone is a great musician, can do little else, and you don't need musicians on your team, his performance may not be a good fit with your organization's needs.

Seven, take into account potential performance. This is, perhaps, a very tricky proposition, especially since potential performance falls into the realm of psychic prediction. In many cases, however, you can leverage past growth levels to determine if someone has the potential to add substantially-higher value to the company in the foreseeable future. You also need to assess the probability of someone actually willing to fulfill his potential. As the character of Will Hunting shows, it takes much personal change before some geniuses live up to their potential... and it is highly unlikely you have the resources or the personal time to invest in someone as Professor Lambeau and Sean did. Net net, if someone's future performance is likely to jump and actual performance is on par with peers who have plateaued, it may be warranted to assess performance higher in order to retain and groom the talent. This is the person you will want to tap for more challenging assignments in order to begin actualizing their potential ability. On the other hand, if the individual fails to demonstrate practically-higher future potential, assume that his actual results are the best he can deliver.

In the end, your goal is to deliver strong results today and to retain talented individuals who will help you deliver strong results tomorrow. Actively manage your talent pool from year to year during fourth quarter to ensure you continue to have a vibrant team. Also, consider moving people around to different projects after they've spend two or three years developing depth in a certain competency. This gives them the opportunity to grow horizontally and expand their horizons, as well as gives their apprentices the chance to breathe new life into a mature team.

There are times when you will need to either fire someone or manage them into other parts of the organization where their talents are more in line with the needs of the company. Both are difficult to do psychologically until you develop the attitude that you need to deliver strong results. You cannot do so if your people are mediocre. If someone takes undeserving advantage of the company by not delivering, you lose if you allow him shelter. If, however, some is skilled but just not a good fit for your team, your performance demands, etc. it is warranted to give her a second chance to succeed if the company can afford it. Wear a CEO's hat and decide if the individual can add value commensurate with his compensation. If so, then keep him. If not, don't hesitate to make the tough choice.

Saturday, August 26, 2006

On resource optimization...

How many people does it take to develop a specific software module in a mid- or large-size organization? On the face of it, it seems to be a simple question. You size the project in terms of man-hours, divide by 8, divide by the number of working days you have to complete a project, and voila: you have your people count... right? Not really... as there are quite a few additional considerations to take into account.
  1. How many changes do you expect on your project? In sizable organizations, project scope fluctuates... and saying no to every change control does not foster a positive relationship with your business partners. Since the amount of change is driven by both the individual(s) who initiate your requirements as well as by the inherent nature of the domain, use historical examples to determine what capacity buffer you should plan for during your project. Ramp up these resources at key points in the lifecycle, such as toward the end of your requirements-analysis phase. This allows the majority of your team to focus on mainstream design, while others can evaluate new requirements and incorporate them into the project.
  2. How skilled is your technical team? In many companies who use outsourcing today, skill in a specific system or domain can vary each year, as the outsourcer rotates people among portfolios. Even if technical skillset is solid (and don't be surprised if this is a "big if"), your developers must understand the system architecture, environmental tools, and the like. Otherwise, plan for a good amount of ramp-up at the beginning of each project phase and assume productivity will be lower per capita. Consequently, add a "new team member" contingency to your project... which will translate into either additional staff, longer timeline, overtime, or a mixture.
  3. Flu season? People have been known to get sick once or twice during a project. This risk increases if you're executing during periods of known flu seasons or other types of periodic illness. If your dates can't slip, allow for some contingency due to illness.
  4. Have you done this type of project before? Projects come in all shapes and sizes. If you've done this type of development before, consult your historical records for variances between your projected and actual effort... and build yet another contingency in your project. If this is your first time with this type of animal, either consult colleagues who tamed this beast before or allow for some healthy contingency.
  5. On how many other groups do you depend? Large-system development in sizable organizations typically involves other groups... both internal and external to the company. Each group's changes either be "business as usual" or can represent a significant effort for said group. Increased effort increases their (and your) risk, especially if not all managers run a tight ship like you do. Hence, increase your contingency for every integration point outside of your direct control. Unfortunately, this contingency will impact your schedule more than anything else... so make sure you have the people necessary to troubleshoot, bug-fix and implement workarounds when the time comes.
The purpose of planning for the right amount of people is to enable successful delivery of the project with quality and within agreed-upon timelines... without needing to beg for mercy (in the form of additional time or cost) from business owners. There will always be risks that you either cannot predict or are so infrequent as to not be likely. For example, if the business champion for your project suddenly wins the lottery and a new champion will take her place, the impact to timeline this creates definitely warrants a project checkpoint and an independent go/no-go decision. Unless you're already into heavy coding and you've already forgotten the business partner's name, you need to have a candid conversation with your business champion.

Setting the stage...

Why do some writers employ pseudonyms? On one hand, it gives one the anonymity necessary to publish views without fear of heckling from friends and close associates. It allows freedom to experiment with ideas without later being tied to statements no longer part of one's worldview. On the other hand, should one have a profound influence through one's writing, the world may never truly know the author. Though I've often considered the question of anonyms, I never envisioned myself using one someday. Alas, the tactical benefit is, for the present time, the clear winner. Hence, I shall pen these musings as one Walter Bradford Jones.

That said, here is a riddle. The SHA1 digest of my first, middle (full), and last name (all letters lowercase and including spaces) as computed in PHP Version 5.2.0RC6-dev is 28c2323c86c1ac810e4504e80efa8e61e581d4ff . Who am I?