Category Archives: Management

Related to the activity of managing IT staff or resources.

The Dreaded Annual Review

I recently got pointed to an article in the New York Times on annual reviews. And, probably because my office AC isn’t functioning at top capacity, I got a little annoyed at yet another management article that forces another important personnel concept through some black-and-white filter and oversimplifies things.

Everyone will likely agree that that giving or receiving a well-received annual review is difficult. The article reinforces our fears by tying some horrible-sounding-and-dubiously-linked statistics on heart attacks, workplace stress, and by tossing around weighty organization names like the American Psychological Association, as if to drive home a point not with a hammer, but rather with a particle collider.

My current opinion is that there’s nothing wrong with having a good annual review. There’s obviously lots wrong with badly-formatted annual reviews. The trick to getting them right is to think about your approach to the reviews and how you treat them and the “secret sauce” is to frame them properly. Given that most people reading this blog are likely techies, let me rephrase it to say that the fundamental problem I’ve seen in annual reviews comes down to something akin to a “proper scoping” problem.

In IT, and more precisely in software development, scoping is a process whereby a “universe of discourse” is sized appropriately to the context. What is relevant to a small block of computer code, like a method on a class, is often not relevant to a larger scope, like the whole application. Not only is it not relevant, it should be hidden so as to not confound the whole system. But, sometimes, other pieces of information gets shared or pushed upwards from a small scope into a larger context and there are often guarded ways of doing this so as to keep things running smoothly.

The same concepts, I think, apply to performance reviews.

If you have a yearly review, hopefully not your only review process, your proper scope is the summary and trending from the year backwards through the year (or 1-3 years) forward. I treat it not like a micromanaged review of every day of the last year, whereby one nitpicks on the instances of failure.

career growth over time

Visualizing career-related growth

Instead, I imagine it like a projection of the data we (the reviewee and reviewer) have from the last year or so forward. Most managers fall into the trap of rehashing the one costly thing you did 11 months ago. That’s wrong, awful, and should have been taken care of on the spot, or at least through smaller-scoped meetings like daily huddles or weekly one-on-ones. By analogy, if you plot a line graph in your mind where the x-axis is time, and the y-axis is the effect on your career, and where each decision you made in the workplace either moved you up or down the y-axis by some subjective amount, I don’t want to talk about each stepwise movement one-by-one. What I want to cover, in a servant-leader-ish way, is the fact that it’s heading generally up, flat or down. Furthermore, what I really want to cover what we can do to affect that rate so that it is the most upward-looking rate the reviewee can achieve.

The annual review should be like a form of one-on-one strategic planning: strengths, weaknesses and long-term action plans that help the individual align themselves with the company and their team, and reach their goals. Done properly, they can be highly motivational. I use them, in a sense, to review each of my teammates’ BHAG, not the minutiae of individual actions I may or may not remember.

The annual review does not replace the smaller-scoped meetings, just like the daily huddle cannot serve the need for larger-scoped guidance (esp. in juniors). You have a collection of tools available to you as a manager. Why not use them?

Now, the common criticisms of annual reviews are:

  • Managers playing favorites: One common complaint is that pet employees never get dinged as badly as the less favored one. And, what’s worse, it’s not an extremely rare occurrence. However, I’d argue that this is not a reason to avoid annual reviews. Any such favoritism is/would be an issue in an annual, a quarterly, a weekly or any daily reviews. If the manager lacks the ability to bring as much objectivity as possible into this process and to work for the team and the company, then the fault lies with the manager, not the review.
  • One-Sidedness: Another common complaint is the one-sidedness of the review. The reviewee sits down and is forced to listen to how he or she fared, with limited viewpoints. Again, this is a problem if one approached the yearly as an “itemized recap”, or ” event-based debriefing”. Taking more of a trend-like, aggregated approach, mixed in with more forward-looking goal-seeking would negate this problem.
  • Compensation Tie-In: Simple. Don’t tie compensation (or termination of compensation) to these types of reviews that are more akin to brainstorming on 10K-foot career growth plans. Personally, I prefer to look at a) growth in responsibility and skills in operation in the team, and b) trends infrequently evaluated perfomance metrics.

It should not be “banished”. It should be done… right.

Outsourced Or In-House Developers?

So, you have a workload of software projects, a veritable plethora of projects to get off your plate. Or, maybe you are considering an expansion of your capabilities. Your current team is tapped out… hopefully not overworked and tired; you don’t want to break their backs.

WARNING: I will be using the word “outsourcee” to refer to any entity not in-house performing work on behalf of your company. There’s nothing wrong with the word itself, although it’s full of negative connotations of lost jobs, cheap labor and evil executives. But, if you are a die-hard isolationist or a nationalist, you will be unable to read further. You have been warned. 🙂

You’re looking at various reasons and wondering if you should hire more in-house developers, or farm out. Here’s the top-level factors I look at to help me decide when to farm the work out. Of course, this is all from an SMB point-of-view; larger companies have a completely different perspective and set of tests to check against.

  • Niche/Esoteric Skills: If the project involves some fringe technology, or unique skill set that will not see much re-use in-house, then farm it out. Note that this could be an emerging technology, or an old one that would bore your in-house team to tears. Usually, hiring in-house for this is a big challenge anyways…
  • Time-To-Market Pressure: If the project involves the need to get something out before competitors claim the territory, farm it out. You should seek an outsourcing shop that will properly staff up so as to get your project out in the time frame you set for it. You’ll pay through the nose, but that may be the difference between sick or swim…
  • Overwhelming Workload: Obviously, one reason to consider farming out is if you have a large spike in the overall short-term workload. This is quite common in small businesses. Instead of slowing down and stretching thin, just bring in short-term, contract-based workers to shore up your team(s).
  • One-off or Short-Term Project: If the project is a side-bar to a core project, or some “throw-away” task where ongoing maintenance is not going to be an issue, consider farming it out and don’t bog down your core, in-house team(s) with it.
  • Experience Gain: You may want to consider randomly outsourcing the “easy, non-critical ones” just to gain experience with outsourcing options in your local area, or the broader market, simply so that you then know a little bit more about who to go to when it really counts.

There are undoubtedly more reasons, but I think these are the main, big ones. The more these reasons exist in any one project, the more you should consider farming out the work. Otherwise, don’t. It is better, and less costly, to go in-house. No really!

First, less face it, every dollar you spend creates/elevates talent in some individual, and it is generally best to keep that talent close to your vest rather than see it go to another company, especially a competitor.

Second, there’s more to developers than churning out code, even the so-called “boilerplate” stuff. Being able to effectively understand and translate requirements and interact with business users comes, in large part, from close familiarity with the people and the processes, a.k.a. the “ramp-up” or “learning curve”, and the short feedback cycle that comes from being in-house. These two have had a larger, empirical, hard-to-measure impact on any team’s performance than anything else. It doesn’t help the “super-awesome outsourced guru” if he has to wait two days for an email reply on a process issue from some department because they are swamped with some monthly peak of work. Every time you farm out, you’ll hit this over and over again. In-house is undoubtedly both a short-term and long-term investment. Treat it as such.

Lastly, contrary to the typical assumption I hear, farming out is usually not cheaper. A good, in-house team will simply cost less than an equivalent, good outsourced team, even if you consider all indirect costs. My off-the-cuff, empirical, “from-the-SMB” conversion factor is that outsourced is 2-4x more than in-house. One main problem is that because the outsourcing market, even post-dotcom bubble, has an incredibly high markup on IT work. Unfortunately, the perception that outsourcing is cheaper is because the comparison is usually between a bad, in-house team and a good outsourced consultancy.

If you are going to farm it out, the next question typically becomes who to farm out to. There are four general categories:

  • Freelancers: These are the “unincorporated” outsourcees that cost on the low-end of my conversion factor. They usually don’t have much overhead to worry about because the job isn’t their primary source of income. Lots of developers from large, status-quo-loving companies want to expand their skills and so pick up work on the side. Or, out-of-work, between-job developers will take on short-term contracts to fill the income gap. The main and dominant problem is the lack of accountability on multiple levels, from the personal involvement to the legal ramifications if they drop out on you. If you don’t know any freelancers, consider shopping on websites like Rent-A-Coder.
  • Local Outsourcee: The local outsourcee is a local, incorporated shop, usually with a smallish team or teams, that makes a living providing recurrent, happy IT service. They are usually not cheap, because of their business overhead. However, as a manager, if I can’t keep the capital in the house, I sure try to keep it in the neighborhood, because it eventually comes back to us. I’m not talking about “paying it forward” (although if that does happen, then great!), just that a vibrant local economy is indirectly good for my business. On a selfish level, it also helps me build out my local personal and corporate network of contacts.
  • Remote Outsourcee: There are all sorts of levels of outsourcing here, ranging from neighboring states, to neighboring countries to full use of sweatshops in Central Nepal. If you are an SMB, you should really not go to this option, unless you have a direct reference to an active shop used actively by another SMB you know and trust. I have heard too many horror stories of SMBs burned by this kind of outsourcing. The problem is that lots of these big offshore consultancies are driven by big customers and you’ll simply get lost in the mix. The smaller, satellite consultancies that emerge in such areas are usually unable to serve you properly because the big shops drain the area of real talent. The former is exorbitantly expensive, the latter is expensive in terms of direct cost due to the inevitable mess-ups. You’d be surprised how not cheap offshore work in places like India has become.
  • Internship: Don’t forget to consider using variants of the idea of internship. The concept is that you get some raw talent and let him/her beat his head on a project in exchange for a low wage and a great reference. Like farming out locally, there’s a lot of goodwill generated in this route. You may find your next hire in an intern; you certainly may find out who not to hire too. Each individual will hopefully go on to speak highly of you to other students or junior co-workers, generating potential future hiring opportunities. But, if you want to do this right, don’t hire just to stick a kid in the corner cube, and leave him or her to sink-or-swim. What you save in hard dollars will have to be spent in your own or senior developer’s hand-holding time.

This pretty much sums up how I consider outsourcing, short of a lengthier novella on the subject.

One last warning: Be open with the work and get your team’s opinion on farming out any work. Don’t let them hear about it indirectly and give them the opportunity to step up if they want and can deliver. Psychologically, from a morale point-of-view, keeping your team out of the loop is a big no-no.

What are your experiences? Do they match up with the above?