Making a Distinction Between Functional Skill Set and Institutional Knowledge in Employee Development

Earlier in the week I did a poll on topics and the number 1 pick by an overwhelming margin (beyond Sad Ass Salad) was "Business Domain vs Functional Domain in Performance Evaluations."  

Project Success does not equate to Individual Success in Performance Goals

Successfully support the <milestone> for the <project name>

Many managers use this boilerplate performance goal for just about any employee.  It's lazy. It reflects nothing with regards to the expectations of the employee, nor does it reflect at all, in what way would one grow in their capabilities.

Why is it not great to tie project success to performance goals.

Simply stating success of a project without identifying how they should be contributing to the project does not set them for success in being able to support the NEXT project on a DIFFERENT team in a more COMPLEX situation.  This not only provides no guidance to the employee on what they should be improving upon, but also may not give you, as the manager, the right capabilities in succeeding should any adversity arise.

Most importantly, many software projects fail due to circumstances that have absolutely nothing to do with the execution of the project.

Why is project success commonly tied to performance goals

• If a project succeeds, the company would make more money, therefore, there's more money in the pool to pay for raises, right?
• A manager's thinking: if a project succeeds, then I succeed, and that means the individuals of the team succeeds right?

What should performance goals include instead?

Activity and contribution to a project should be an EXAMPLE of how you want them to be performing.

Focusing on Software Developers: 

• Three Basics
• Ability to tackle complex challenges.
• Ability to interact with their colleagues in the form of clean code, communication in PRs, and overall communication with the team via chats, email, IRL
• Ability to interact with stakeholders in the form of requirements feedback for clarification and further getting feedback on software behavior. 
• The thing that I care about the most 
• How accountable are they in production and are they able to observe the behavior of their code out in the wild?

If you really want to talk about it in the context of a project:

• How did they contribute to projects last year, and is there any difference in contribution that htey should be doing in future projects?  Spell it out.
• Are these projects more or less complex that last year's projects? How does completing these projects demonstrate their skill set? Explain how this project is a more significant challenge that will test capabilities that haven't been tested before.

Bottom Line:  Goals should not be effectively "yeah do what you did last year but more". You need to give them explicit skills to level up and a clear example of how you plan to observe it. for some managers, that is solely based on the success of a project, and that's a shitty manager.

Soapbox Moment

In developing and operating software, it all boils down to how much trust do you have in the employee. When shit hits the fan, will you call on them? When a brand new paradigm needs to be investigated, will you ask them to spike it? When another member of the team is not around, will they be able to temporarily fill in?  These should all be straight forward yes/no questions and for the situations your team finds themselves in, you should have a pretty clear list of which members of your team are your primary, secondary, "bench" type people for a given situation.  

For each of these moments, based on an employees skills, potential, and professional interests, their goals should be balancing enhancing their skill set so that they can contribute more for your team that suits both their interests, capabilities, and team needs.

Who said management is easy!?

Support you should expect from HR and your Org in prepping to give a Performance Eval

So previously we discussed the importance of being well prepared for your performance evaluation. However, every single different company is different both from an HR perspective and an Organizational perspective. However, they should all be able to provide you some foundational resources in 

• being able to clearly explain why they are getting the performance scores they're getting
• understanding how your eval may impact their salary next year
• understanding how your eval may impact their odds of a promotion next year

What HR Should Provide

HR should be able to provide you basic overviews of the current state of your direct report as well as some high level information on the process for 

Your direct report's job title (and tier if there is one) as well as their salary and the standard salary band for that title.

In many organizations, raise calculations take these 3 things into account along with your performance evaluation. If there is a standard raise calculation, you'll have a decent understanding of what their raise may be.

Your direct report's previous performance eval, if available

It's valuable to review past performance evals, not just to know where they've excelled or struggled in the past, but also to refresh your memory on past goals you've set for them and where their skill set is today versus the previous year. Especially when you observe noticeable improvement (and they're at the same job tier), that should impact your performance score today.

Each Performance Category

In general, performance categories are pretty broad from the HR level. This is where your own org and your seniors should be able to provide more granular guidance.

From your org (and your seniors)

Rather than "doesn't respond well to feedback", your org can give you more explicit guidance like "do you find yourself repeating yourself over and over in their PRs." In absence of any formal documentation, your org and your own manager should provide you with additional context in how your direct report treats their work and their teammates.  

How each Performance Category applies to your direct report's job function

This can provide you examples where to look or what to ask about from peers regarding their work. 

• Aptitude => Are they entrusted with more complex challenges than others? => do they ever get assigned an 8 point story to oversee
• Communication => Do you encounter surprises from them? => system behavior that a product owner did not anticipate and it's already in production?
• Versatility / Team Player => do they shy away from duties that may not be their primary? => are they an asshat when they're on-call?

For each performance category, a discussion of situational example or a behavioral example. Sometimes it's easy to hone in on a specific situation where they may have gone the extra mile or have fallen short, but it's important to make the distinction between what may have happened at a particular instance vs an established behavioral pattern that they have exhibited (and did they improve on it when given feedback about it).

Guidance on for gathering feedback if you're not a hands-on manager (because that's how the org structure is)

If you do not directly interact your direct report (I mean... that sucks) your organization should provide you with the appropriate tooling to gather feedback from those who are better equipped than you are. Discussion with tech leads and 360 Reviews are decent subjective methods in understanding one's performance. Quantitative tools may be a method to open up a conversation with a tech lead, but generally not a great way to gauge whether one is an asset or burden to their team.

My HR nor my Org has this

lol, buddy. sounds like you get to establish this yourself and set the precedence, should you choose to accept it.  Nobody will thank you.

Solidifying Trust when giving Performance Evaluations

The performance evaluation is the pivotal point of the power dynamic between a manager and a direct report.  

In most cases, this is when a manager is making a final decision to move someone to a Performance  Improvement Plan or make a recommendation for a promotion. In many cases, direct reports are using this to gauge whether they want to move to another job within the company or apply for a job elsewhere.

The biggest takeaway for this post is to understand why it is extremely important to be blunt in your feedback at this important confluence of expectations, impressions, and receipts.

A quick look at motivation

Because this is my first people management post we're going to do a quick primer on motivation and the basic structure to a Performance Evaluation.

There can be 3 categories in an employee's motivation: 

• Compensation
• Authority / Respect
• The work, itself (interesting problem to solve, they like the outcomes the business is driving)

We're mainly going to focus on the top two, as those are the pieces that a lot of people generally care about, especially earlier on in their careers. In the performance eval, you need to be able to answer 

• Am I going to make more money next year?
• Will I have more authority next year?
• How can I make MORE money the following year? 
• How can I have MORE authority next year? 

Footnote: for many people at certain parts of their career, they're extremely happy where they are financially and in the work they get to do. Being able to confirm that is important. But honestly these people are few and far between.

You can look at a performance eval in three parts.

• Explain to them what you, as their manager, can do to help them make more money or get more authority next year
• Review of their performance and how does that impact your decisions.
• What should they be improving upon so that you'd pull the levers at your disposal harder for them?
• Many organizations have goal planning and performance evals as two separate exercises, sometimes months in between. However, 

Many managers just go through the performance metrics and that's it. Just because you filled out the space allotted doesn't mean your work is done.

Why they are falling short... of a PROMOTION

9 times out of 10 you will not be offering someone an above average raise or a recommendation for a promotion, and this is where you need to make sure that your understanding of their efforts throughout the year is crystal clear. You need to have the receipts for both situational occurrences where they could have improved and, more importantly, behavioral / skill set patterns that may be preventing them from getting as good an evaluation as they would like.

Why is it so important to lay it all out

Everything boils down to trust. The performance eval is the pivotal spot for a manager to make or break the trust that you've been building all year.  Your direct report should have a clear understanding about the process, what is in your control, and how their actions drive compensation and career track.  The review itself is more reflection of your understanding of their contributions, their impact, and their skillset that allows them to help the team become successful. 

Goals set next year are not only a commitment from your direct report on achieving certain goals, but also a commitment from you as a manager that you will ensure that they have the opportunities to achieving them. This is the key mutual relationship between you two that need to be established for both of you and the team to succeed.

It's definitely a balance

All of this is a balance of trust between you and your direct report that if they accomplish what you set for them, you will help them achieve more of what motivates them.

In the end, what you have to be is honest and demonstrate that their work and effort hasn't gone unnoticed.  The amount of effort that you put into these reviews is the clearest artifact of your commitment to a direct report's success. If they ever sense that it is half assed, they're on their way out.

Man, it's been nearly 10 years.

 Alright going to start writing up stuff again so what's happened.

Since Grubhub I have been at Paypal where I was absolutely not a good match for the Braintree nor Paypal culture.  

I joined Chowbus an early employee to head their operations and helped them expand up to a Series B round.

I'm now CTO at Bucket Listers where we're 1 year into operating a ticketing marketplace to promote cool things that are happening in your town.

All in all I've gotten to really flex on my convictions, some to great success and others to not so great success. I figure I have about 5 years left in my career so let's see where this all goes.

Logstash Examples with Data Generators

Logstash is a pretty cool application that generically takes some input, does something with the data, and spew it out somewhere else.

It's commonly used in conjunction with Elasticsearch, a Lucene based search service, and Kibana, a dashboard UI for Elasticsearch.  You can easily consider this as a "Splunk without super awesome ad hoc query capabilities" but the software itself is FREE so there's that.

The documentation for Logstash is pretty straightfoward, but I thought it would be nice to have some hard examples to work off of that involved the whole ELK stack:

Logstash Examples

Right now it just has two examples: file and log4j.

File:

• Write to a file
• Logstash monitors the specific file and does some grokking before passing it to Elasticsearch
• Load the provided kibana dashboard.
  

log4j:

• Spew log4j stuff out with SocketAppender
• Set up Logstash to monitor a port for log4j messages and grok before passing it to Elasticsearch
• load the provided Kibana dashboard

So yeah I hope this serves as a quick and easy way for people to observe the awesomeness that is Logstash.  Feel free to add your own examples to this guy as well.

IT'S A TRAP

Wife:  "How do you think I've been doing with my makeup lately?"

*pause*

Wife:  "... IT'S A TRAP!  No, seriously.  You have to answer."

Read the Freaking Documentation to Couchbase!

Just wanted to point out a pretty awesome product with pretty awesome documentation:

Couchbase.

We're using it for a pretty specific use case and for that, it's handling things extremely well.  However, we noticed that it was using a ton of swap space to the point I was thinking we were on Windows boxes.

Buuuut lo and behold we didn't read all the documentation on how our nodes should be set up and here it is for v2.2 that we're using.

http://docs.couchbase.com/couchbase-manual-2.2/#swap-space

Actually that screenshot is further down in the issues section, complete with impact and JIRA issues!

It's actually pretty awesome to be able to track something down this easily.  Obviously, other people have encountered this that has lead to issues but it's great to see the trail and the resulting recommendation.