Key result Areas (KRA) for software developers

4 min read

Introduction

A good software developer is an experienced craftsman that consistently strive to excel and be better. Your happiness and professional pride is found on this path, and on this path alone. You will never reach a level where you can relax and stop improving and just feel wonderful about yourself. You are only happy when you work your way trough frustrations, resistance, technical challenges, relevant books, new knowledge and then deliver code and solutions on the very edge of your current abilities.

One way of improving yourself is to be better at your primary programming language or to learn new languages. Another, and more subtle approach, is to question where you stand in the Key Result Ares for a software developer, and then to work systematically to improve on your weakest areas.

I first learned about the concept of “Key Result Areas” in the audio-book “the Ultimate Goals Program” by Brian Tracy. He explained that no matter what your job is, you have a few key areas that you need to master in order to do an excellent job. In order to be excellent, you must know these key areas. You must know how you master each one of them. And then you must aim to improve in the areas where you are weakest.

This is actually an interesting idea that was totally new to me. (It’s management/HR speak, so it’s origin is from a world far away from the books I usually read / listen to).

When I briefly sat down to identify the KRS’s for me, as a software developer, I immediately realized that I suck at estimating time required to implement anything. The fact that I suck at this is not a new revelation (most software developers do), and I’ve always been totally transparent about it. However, I have never identified it as something that is actually my responsibility to improve on. For improvements, I have always chosen the funny parts, like digging deeper into the C++ programming language, libraries or flirting with other languages.

If you rate yourself 100% honestly on your Key Result Areas, you will probably be surprised at how much opportunity you have to improve yourself, even if you are among the best developers around.

Definitions

Key result Areas is not a new term invented by Brian, although he uses it in an interesting way. Some duckducking reveals several definitions.

“Your Key result Areas are those things that you absolutely, positively must do to fulfill your responsibilities and achieve your business goals”. Brian Tracy.

The “Critical success factor(CSF) is a management term for an element that is necessary for an organization or project to achieve its mission. Alternative terms are key result area (KRA) and key success factor (KSF).” Wikipedia.

“KEY RESULT AREA = crucial outcome space”

For example, the Key result Areas for a Product Manager may be:

• Customer Satisfaction.
• Product Management.
• Operational Cost Control.
• Quality Check.
• Record keeping.

Interestingly, it seems like the idea of using Key Result Areas to improve your own performance and success, as a software developer, is a quite novel idea. I have not found any articles about it at all. All the articles I found focused on managing developers, teams and projects.

Key Performance Indicators and measurements

Key Performance Indicators seems to be all about measuring developer performance. That is bs and junior-manager jo-material. It’s simply not possible to measure the performance of a good developer, something all the r&d managers and product managers I have worked with agree with. A good developer will implement the “thing” as fast as he can in maintainable code of high quality. So I will leave KPI out of this article.

So, what are the KRA’s for developers?

The exact list will of course vary between specialties. A front-end developer will have different KRA’s than an embedded developer or kernel developer. The list below applies roughly for general developers. As a C++ developer myself, I may have a bias towards application performance over developer performance (time to market) – so feel free to add and subtract areas in your own list.

• Understanding the specifications for the “thing” you are about to implement.
• Estimating time required to implement something.
• Communications skills and clearness in your reporting and communication.
• Knowledge in the programming languages you use.
• Knowledge in the libraries you use.
• Knowledge in the tool-sets you use.
• Analytical thinking and experience (practical when you design the architecture of the “thing” prior to coding it).
• Technological understanding (ability to see your new “thing” in a wider perspective, for example how a small library fit into a large project or product).
• Creativity (finding better ways to achieve your projects goals).
• Planning.
• Coding (testable code, clean reusable code, maintainable code, readable code, bug-free code, beautiful code).
• Correctness (few bugs, few iterations with refactoring).
• Application performance (the application does what it’s supposed to do without wasting CPU, memory or other resources).
• Learning (your ability to learn about and use new technologies, protocols, libraries, or even languages as needed).
• Durability (to stay on track no matter what, even when you feel dead bored, or in way over your head).

All these areas are very important for serious software developers. Whatever points you remove, you probably want to keep the first one. It’s dull, but absolutely essential for the success of any project.

How to become a better You?

If you want to be better (significantly better) at your job, you can write down the 5 – 7 areas that are most critical for your or your projects success, arranged by priority. Rate yourself at a scale from 1 to 10 on each one. Then you make a plan on how to improve your performance on the weakest area, and repeat. Your ultimate goal should be to perform at 9 to 10 on each of the most important areas. When you do, and people around you notice that you are actually improving fast, new opportunities will come to you. For example, if you make a point out of playing with new technology, and you are already very good at reading specifications and writing code, you can expect your boss to throw more interesting “things” in your direction. In the software development business, interesting “things” are usually better payed than average “things”, so eventually you will make more money, having more fun. At least, this is my personal experience.

The ultimate goal for most of the good developers I know (and that include some pretty amazing guys) is not to make as much money as they can, but to have as much fun as they can, while at work. More money is a side-effect. They care genuinely about the products they build, they do spend quite some time improving their skills, and they all love to solve puzzles, which is basically what we are payed to do.

Conclusion

I think working on your skills, by thinking about and identifying the Key Result Areas, and then addressing the weakest ones, is the most efficient way to the fast track to excellence. And by having a honorable goal to work for (your own well being), you will enjoy more fun and happiness in your professional life than ever before.