People performance - key measurement points

I was recently asked how I measure the performance of people in IT.  While there are many related aspects of people management (e.g., setting objectives and measuring progress, remuneration change process, conducting a formal evaluation, career planning, motivation, creating shared values/methods, leadership and non-tech attributes, work prioritisation, KPIs, ...), the following is focused on key areas of performance measurement.

For each role, you want to have 3-6 top level areas of measurement - enough for meaningful evaluations but not so many that evaluations become too time-consuming and lack focus.  For each area of measurement, collaborate with the people in that role to list the area's archetypical traits.  Determining and agreeing the areas and the traits are a collaborative exercise although there will likely be recurring themes.

I've not included the process of setting and measuring against objectives in this article.  Objectives are very contextual with the work at hand and will change frequently.  You can list high level objectives and measures at the start of a review process and/or weave them in as examples in each area (particularly #1).  Objectives are the vehicles that demonstrate effectiveness in the five areas below.

The following are my five areas for technology roles along with some fleshing out I've used in both informal and formal reviews.  I've also added weightings for each area, although these might vary depending on the specific role (e.g., a manager of many people might elevate areas 3 and 4).

1. You deliver (40%)

• Delivery is the most important item on this list of 5 areas
• You get things done, over and over again
• You deliver consistently, not in fits and starts.
• Your deliveries enable additional revenues and/or secure existing revenues (but ultimately, working on a project that contributes big new revenues to the business wins)
• You take ownership and show responsibility for what is owned
• You consistently demonstrate integrity, delivering what you say you're going to deliver; however you can also…
• be flexible and you're not afraid to change your priorities and commitments to do something that is even more valuable to the business at that moment because you can...
• communicate effectively with stakeholders to come up with alternatives and/or renegotiate a delivery "win" based on changing circumstances and new information and priorities
• You know when to ask for help and when to negotiate delegation of your responsibilities to others
• You're focused on delivery and don't allow allow lower priority tasks to interfere with delivery; conversely, you keep an acceptable level of balance with your other objectives
• You know why what you're working on is important to the business and can explain it to anyone that asks in non-technical business terms
• You innovate to deliver new products and solve problems, but don't waste time re-inventing wheels
• You remove, bypass or fix roadblocks and slow-down points
• Everyone who pushes themselves and their team will sometimes fail:  When you do:
• you take time to learn from it so you don't repeat the same mistake
• you're passionate that you're colleagues learn from your failure as well
• You understand and demonstrate good judgment and flexibility around commercial and technical trade-offs
• You are comfortable making decisions to enable delivery progress in an absence of complete information

2. You are the go-to person (20%)

• You're the expert, the master, the guru for your area(s)
• People trust you and your work
• You figure things out and solve problems
• You are the innovator, the break-through thinker in your area
• You're approachable and can talk at various levels (deeply tech to simplified non-tech)
• You solve way more problems than you create
• You have a passion for learning as much as you can in your area(s), but...
• you exercise good judgment on spending time learning in areas that will help the business versus areas that really only benefit you
• you don't expect to delay deliveries by spending time learning areas that aren't even distantly applicable to your responsibilities
• You maintain a top-of-mind list of priorities for your area, improvements and maintenance
• You know where your main areas of technical debt exist, proactively flag risks, and can present solutions and support business cases on how to remediate it
• Your mastery radiates confidence, not arrogance.

3. You play nice with others (15%)

• You make the whole greater than the sum of its parts
• You think about how your decisions and implementation will impact others and collaborate on difficult choices
• You're interaction with others increases their productivity and in turn the overall value of the company
• You actually like people!
• You share your knowledge freely; you don't stay silent waiting for someone to ask the right question or hoard your knowledge to increase your value
• You help others, including proactive identification of problems and helping where you can
• You have several informal mentoring arrangements helping others out on a regular basis
• You enjoy recruitment and want a say in who joins your team
• You like giving and receiving feedback - from informally over a beverage to more formally during 360 degree reviews
• You recognize that different people have different communication styles and strengths and you freely adjust yours to maximize each interaction
• You look for opportunities to interact with new faces through internal/external coms/blogs, meet-ups and hackathons

4. You have a great attitude (15%)

• You're generally positive about your work, your colleagues, the company, it's products, and it's customers
• The first thought in your head is "yes" when asked if something can be done, followed quickly by trade-off thinking and a view on how it can be done.  It's not "no", followed by "here's why we can't do it".  You think "we can do this".
• You freely give credit to others and recognise and are transparent about when you're standing on the shoulders of giants versus when you are the giant
• You're passionate and exited about a majority of your responsibilities, recognising that sometimes you have to roll up your sleeves and do some grunt work.
• You're "present" in interactions, actively listening and participating
• You're fair and firm, treating people and situations equally
• You produce more energy than you consume
• You keep cool and professional under duress
• You're ambitious, pushing yourself and challenging those around you in a positive way
• You're self-motivated and motivate others around you as well

.5. You're curious (10%)

• You recognise that learning is motivated by curiosity, an innate desire to understand how things work
• You pick up product and domain specific knowledge, at least enough so you understand the company and their products through the eyes of the customer
• To sate your curiosity you develop relationships across the business.  You learn about other functional areas in the business and mentor others about technology.   As a result you improve your effectiveness at communication across the business.
• You understand how things get done across the business, how processes and prioritisation work, who the decision makers are
• You see how the business makes money and how your contribution generates revenue
• You think about why your (potential) customers go to the competition rather than your company
• You're interested in what is going on across the business, not just in your area but cross-functionally
• By exploring new areas you're curious about, you contribute innovative customer-valued solutions

Ultimately, a company must deliver product to customers, not just be a great place to work with nice people.  As a result, you'll notice that I've weighted delivery and talent (60%) over the softer skills (40%).  When creating a new product/service from scratch (e.g., at a startup) with just one or a few people, you'll probably weigh 1 and 2 more than anything else.  When you start scaling up the team size, 3 and 4 start becoming more important.  And ultimately, to be considered a strategic team, you need people excelling in 2 and particularly 5, because that's where your innovation will come from.

Remember to that not everyone excels in all these areas from day one (or 20+ years for that matter…), but it's a good starting point to encourage your team toward greatness.

What does it mean to be a technologist?

At some point about half way through my career, 10 or so years ago, I started referring to myself as a technologist.

Sure, I got the usual "what a geek" comments early on - I was the guy that fixed friend's computers and saved up for a horrifically expensive mobile phone when they first came out.  Yes, I found myself taking technology night classes at local Uni (pre-WWW, give me a break) and hacking on this and that for fun.  Of course I wrote automation scripts at work to reduce the tedious parts of the job, even though building the tools wasn't actually the job.

Then I got into technology management and was told I'd have to give all that up because good managers knew how to delegate individual contributor work and should spend their time managing.  That never felt right to me so I rebelled and sometime later started calling myself a technologist who also happens to also manage stuff.  Some years later I think my much more technically savvy friends will call me more of a "wannabe" technologist, but that's ok.

About 2 years ago I wrote about what I do as a technology leader.  That blog entry was done in the spirit of trying to help me understand my responsibilities at the time and whether they felt right.  Maybe it also helped others understand the kinds of responsibilities they might have in the future if they wanted to lead technology teams or tune their own technology management responsibilities.  In hindsight, I also discovered (for myself anyway) two important ideas.  First, I uncovered the notion of own and do, concluding that I valued maintaining a balance between the two.  Second, I separated practical day-to-day responsibilities from leadership concerns.

So that brings me to today.  Earlier I stumbled on an article about Skills Every IT Person Needs.  It got me thinking about my old technology leader blog entry and what skills I thought every technologist needs, at least in my world.

So what is my definition of an IT person, or in my book, technologist?

As it turns out, I still think there are two sides, just like my view 2 years ago on technology leadership: a pure technology side and a softer side.  What follows is my definition of an effective "technologist".

On the pure technology side, I think "technologist" implies curiosity, passion and some base of knowledge and skill in four areas:

1. Foundation technology that underpins the technology you work with regularly. "Yep, I know the basic building blocks of a computer and can use them to talk theoretical performance trade-offs."
2. Specific technology areas you directly work with regularly.  "Let's talk about how we can performance tune this Apache server."
3. Mainstream pop technology.  This is what your non-tech friends and colleagues read in the mainstream press and want to ask you about for an "experts" view:  "Hey, can that security problem at Sony happen to us?".  It can also be just simple help requests to sort a home network problem or give advice on which smartphone to buy.
4. Geek pop technology.  A grab-bag of technologies you learn about in geek press and from your geek friends at a very superficial level:  "So tell me, what the heck does the Large Hadron Collider do exactly?" and "Yeah, I can't really explain why I installed Android on my old iPhone."

Non-technical people will challenge technologists on the value in some of these four areas.  When tactically focused, items 1 and 2 clearly create value, so spending time in these areas is easy to justify.  Item 3 creates value when we help educate our non-tech colleagues around how to judge risk, make better tech decisions, and sometimes just lend them a hand to fix something for them.  Item 4 can be justified with learning new ideas that you can apply to items 1-3, but more often you'll just have to accept the tech guy is going to be nerdy sometimes for item 4.

As a career moves on, technologies change and perhaps the span of responsibility widens.  As a result it becomes increasingly difficult to stay on top of 1-4 above.  Difficulty is compounded by living in an age of ever-expanding and changing technologies.  A technologist copes with this by becoming more and more selective about what they dive into and how deep, as driven by how to best get things done - delivering the next product or service.  A good technologist learns their weak spots as well, and knows the areas that they simply can't dive into and instead should create leverage or ask for help.

On the softer side, I believe technologists also have a desire to produce something of value; that is, technology with a purpose.  Technologists want to build products or services that get used and appreciated.  Like taking an art appreciation class, technologists understand what they've delivered in depth and "get more out of it" when their products are used.

I fully accept that there are very successful people in technology that are not technologists.  They tend to manage things and not understand much about what they're managing, instead focusing on breadth and excelling by managing many things at once.  While this can work, a technology department needs to be careful here.  Having people managing something they don't understand is how projects can fail and businesses get sold third party products and services they don't need.  However, so long as there is someone technical around to provide targeted advice, the non-techs can create value and thrive.

However, let's say your curious about what makes up a technologist, at least my definition of one.  Maybe you want to set up an induction program for your company's technology department for new hires.  Maybe you want to create a framework to to provide guidance to less experienced staff to progress their career as a technologist.  What might you cover or recommend to them?

As inspired by Skills Every IT Person Needs, and to make this more practical, I've assembled the following checklist of knowledge and skills to be considered a technologist, both the harder and softer sides.

But first a few caveats to explain some biases below:
- I work with Internet and retail gambling systems which colors my world
- I'm pretty far removed from most technical details but that doesn't stop me from having things like "program something in Scala" on my to-do list
- I've skipped some of the items in the Skills Every IT Person Needs list that I certainly agree with, but weren't top of mind when I put my list together
- I've thought in terms of a for-profit business, but at least some apply to not-for-profit and joy-of-creating endeavors as well

Now, onto the checklist, as organized by technology category, followed by the softer attributes.

Foundation technology

• Understand at a basic level what the major parts of a computer are.  Be able to open up a PC case and point them out: CPU, memory, disk, I/O, bus, clock.  Understand storage layers and trade-offs (cache-memory-disk-tape).

• Understand how a browser works: HTML/CSS markup, Javascript/AJAX, HTTP, DNS, TCP/IP.

• Understand a basic web delivery stack:  LAMP, Java, Microsoft.  For example: client side programming and markup; server-side page construction; business logic; database.

• Understand why MVC specifically and separation of concerns generally is useful.

• Understand a few high-use design patterns.  Facades and factories are useful.

• Understand the difference between asynchronous and synchronous design.

• Understand object oriented concepts: Encapsulation primarily, but inheritance and polymorphism as well

• Understand how to design for fault tolerance: clustering

• Understand why backups are important and some ways to implement them.

• Understand a software development tool chain.  Use an editor and compiler to write and run some code. At least write a few simple scripts to automate something.  Be able to read simple code and understand the gist of what is going on.

• Understand what a transaction is.  Atomic, ACID, and locking should be familiar terms.  Bonus points if you understand transaction performance implications and double bonus points for why database synchronized architectures are easier in the beginning but don't scale well later on.

• Understand basic problem solving techniques.  Divide and conquer, process of elimination, hypothesis testing, change conditions and observe, 5 whys - there are plenty more.  Participate in hard problem solving sessions.

Specific technology areas

• Develop at least a high level understanding of your software, systems, and infrastructure architecture.  Jump on the opportunity to be a sounding board for a colleague's architectural frustrations or contribute to a brainstorming session on how to improve the architecture.

• Identify, offer to own, and deliver a solution to a hard problem.  Particularly between-the-cracks, no-one-seems-to-own problem.  If you see someone struggling with a hard problem, ask them if you can help.

• Learn something new about a relevant technology on a regular basis.

• Understand what key departments do and how they philosophically differ: software development, project management, QA/Test, change/release, technical operations.  Understand the different approaches between development and operations.  Why are the best in these two areas wired quite differently from each other?  Why is QA and change/release such hard jobs?

• Manage or help manage a change into production like a production push of fresh code.  Run a release plan early one morning.

• Manage or help manage a crisis situation, an unplanned downtime.  Lead a team to finding the solution.

• Build something that hits production, goes live, people use, and earns money for the business.  Build something you find interesting.  Know how many people use it, how much they like it and how much money it earns.  It's your right, you built it (* confidentiality concerns and third party handoffs can inhibit so best effort!).

• When you're more junior, find an area of technology and make it your own.  Become the guru, the expert, the goto-person for that area.  As you progress your career, master a couple of areas as a guru.  When you're more senior, occasionally sharpen and leverage your knowledge in these areas and make a real hands-on contribution to a project.  Moving into management doesn't mean you should give up your guru status in any area, it just means you're just not quite as good at it as you used to be (but you're still competent because you were a guru at one time!).

• Know when your ignorance or skill deficit is hurting the business.  Go seek help, ask questions and train if you can.  A little business hurt is sometimes the cost of you learning - that can be ok, but be transparent about it.  Renegotiate your responsibilities if you simply can't do what's being asked of you.

Mainstream and Geek Pop Technology

• Use some flavor of Windows and Unix at home.  Use what mainstream users use, at least once-in-awhile.  Manage your home systems - installs, upgrades, trouble-shooting, repairs.  Make your own backups.  Recover from a failed disk.

• Be willing and able to fix a office issues, PC, printer, or basic network when you're visiting someone's office or a friend's home.

• Security.  Be able to clean a friend's system of viruses and malware.  Read the mainstream articles about security failures so you can proactively talk about them with concerned colleagues.  Understand the basics of how criminals break into systems and steal data.

• As for Geek Pop - that's up to you.  Let your interests be your guide.

Soft skills - non technical attributes that will help you create value

• Be able to communicate.  Document, email, blog on a topic.  Create sustainable business value through creating durable enterprise knowledge using tools like wikis.  Be able to speak and present effectively in various situations from one-on-one to large audiences.

• Understand the basics of project management, including important tradeoffs - schedule, scope, resource; quality, risk, technical debt.  Try to educate people about these tradeoffs when they try to constrain all of these dimensions of your work. Walk away from them in the nicest possible way and escalate to your boss if they don't understand it.

• Understand when it's time to fix things for the short term or the long term.  Both are often important but sometimes you have to pick and recommend because you're best placed to do so.

• Learn how things get done.  Who can you ask to do things?  Who controls priorities, allocation of resources and budget?

• Understand how the business makes money.  You should understand how your daily work enables the business to interest customers and earn money.  What do you need to know to make intelligent decisions and prioritize tasks on daily basis to help increase revenue?

• Understand a process your involved in end-to-end.  Rebel against the process if it's broken.  Work from within it to improve it.  Work with the people in the process to really own the process, customizing and optimizing it to the team's needs.  Make it hum.

• Pay attention to your balance between managing and doing.  Managing is overhead, sometimes but certainly not always necessary.  Doing is creating tangible value.  If you find yourself just forwarding email back and forth, have the confidence to remove yourself from that path.  You're not creating value.

• If you want to change jobs, perhaps to one with more seniority, then just do the job.  Too often people get hung up on not doing what they're not being paid for even though they want the job.  Consider it an investment.  If you do the job well, recognition will follow.  It has to.

• Don't ever apologize for being a technologist.  You should take great pride in knowing what you know.  However, try understand that what excites you really doesn't do it for most non-technologists.  Find a few mainstream topics that interest you that you talk about.  Home science projects don't count.

Conclusion

There are many views of what it takes to be a technologist.  For me it comes down to curiosity, selective understanding of the details, trying to make things better, and creating and delivering products and services that customers like.