Reader

Performance evaluation processes can be a great fuel for personal growth. However, some strategies become the obstacle or even sabotage any chance at growth.

Focusing on weaknesses

Working on one's weaknesses is great, if done for the right reasons. However, if the process forces people to work on skills they hardly use, just because they're a requirement on a checklist, it can kill all motivation to grow.

Forcing a great engineer to learn management skills, just to move to a senior position is one common example. Skill matrices are particularly prone to this.

Grading on a curve

Grading on a curve, or allowing for only a set number of promotions a year, or providing a set budget of points to distribute within a team towards promotion, all of those have one thing in common: They incentivize joining weak teams to get promoted quickly and leaving high-performing teams, because they slow down a personal growth trajectory.

Systems like this will lose self-motivated high-performers, that don't want to leave their teams hanging for their own gain. They're a great environment for the politically savvy, that don't mind a bit of back-stabbing to look better than their team mates.

Targeting averages

Similar to grading on a curve, targeting averages across teams, departments or a whole company incentivizes back-stabbing or even sabotage to look better by comparison.

They offer a second incentive too: Joining a low-performing team and taking it slow, joining the low average that then will be increased to stay inside the target band.

Hidden agendas

Nothing hurts trust and motivation more than a hidden agenda. Teams are fully dependent on what their managers and the company as a whole communicate. Great motivational speeches about career path systems are very common but it's just as common for those to not reflect the whole truth.

Some companies value looking good over transparency. They praise career opportunities and rewarding individual growth, but then, when the chips are down, apply methods like the ones above to 'equalize teams', 'harmonize growth' or 'avoid having too many leaders'.

Motivation from this is temporary. At some point the people will catch on, motivation will drop and churn will increase.

Recommendation

Design your career model with transparency and fairness in mind. Allow employees some freedom to develop the skills they are most interested in or motivated by. Evaluate them as objectively as possible, based on demonstrated behaviors and past performance. Reward success on team level and growth on personal level. Be open about your intentions.

Nice and handy term. Looks very german. Essentially, it means to build on your strengths (as opposed to mitigating weaknesses).

Time and again when people are struggling with their next career steps, trying to understand where their path leads, or who are unhappy with the options that present themselves, they turn to self-discovery. And in doing so, they invariably are confronted with their weaknesses. Our knee-jerk reaction is to tackle those head-on and mitigate them.

Don't do it.

Or, at the very least, be intentional about it.

I have a colleague who is in just such a situation right now. She's found some areas she calls “weaknesses” and that's where her development focus ended up.

When I suggested, she should not do that but focus on “Stärken stärken”, she was confused: Aren't people supposed to mitigate their weaknesses first?

I asked her a simple question and her eyes went wide:

Do you want to stand out or fit in?

This is really the key distinction. When mitigating your weaknesses you get to a “well-rounded” skill-set. Jack of all trades, very employable. Master of none, vanishing in the crowd.

When focusing on your strength, you build a skill-set that is much more specialized, but you get to operate on a much higher level. You're qualified for very different jobs.

When my team and I started working on our new project, it seemed like this daunting pile of work with no end in sight. Initial guesses put us at a time horizon of four months to get it all done. It was way later than everyone would have liked.

So we set out to see how we can speed things up. At first we started to negotiate the scope, but we were already looking at an MVP plan, there wasn’t much to trim. With a fixed scope – our backlog in hand – and a clear budget – 40 person hours in any given week (at best) – we turned to look into getting the most out of the time we have – and to figuring out where we were losing time.

Enter stage right: A tool called LinearB provided us insight into our current flow of change.

Coding time → time waiting for a review → time it takes to review → time waiting for a deployment → deployment

Looking at the data immediately made it clear that we were losing or wasting a lot of time, waiting for things to happen.

With LinearB as a canary, we made a number of changes to improve our flow of work. Every time, we kept tracking if indicators moved in the right direction. This post is just about the first and possibly most impactful step we took.

There’s very little reason to wait for reviews, and virtually no reason to wait for a deployment.

Just Leave it Out

The most straightforward way to eliminate these waits is to do just that: eliminate them.

Mob programming or ensemble programming are the best approach to this: The whole team works on the same problem together, in one large session with a shared screen. Once a problem is solved, everyone has seen, contributed to and reviewed the solution automatically, by virtue of being present. (There's a bit more to it, but bear with me for argument's sake.)

This is a highly effective step and yields surprising results. It's also very counter-intuitive to most people. Getting a dev team and wider organization on board with this technique is a whole endeavor in and of itself, in many cases.

So with this idea promoted to ultimate goal, I thought about what first step we could take to make small-but-significant improvements to our way of work. This is the first iteration, we came up with.

The Rule

We changed our workflow to focus on these waiting things first, with a very simple rule:

When picking your next activity, focus on the right-most column first.

1. Deploy what needs deploying – the right-most column (besides Done).

2. Then review what needs reviewing – second column from the right.

3. Then see if you can unblock blocked tickets (we placed the Blocked column after In Progress).

4. Next, try to help out with something already in progress.

5. Lastly, start a new item.

Our cycle time (DORA definition: the time between starting development and deploying the code to production), shortened quite a bit, just from eliminating the waste of waiting.

Why does this matter? Aren’t we working in sprints, delivering a package at the end?

It matters because focusing on delivering every task as soon as possible allows for the fastest feedback cycle. Every step after the initial coding time adds feedback and improves the work. Wait time delays this feedback, but without this feedback we can’t know if a given task is in fact done already. We run the risk of not finishing the story within the sprint. Earlier feedback mitigates that risk and increases the chance of delivering everything we committed to.

When focusing on the thing on the right, you’re focusing on the right thing.

As you grow your business and your team, keeping everyone on the same page can be challenging. To ensure that everyone is working in alignment, you’ll want to optimize the cognitive load in your organization. Cognitive load is the amount of mental effort needed to understand a task and complete it successfully. In other words, how much do you have to think about what you’re doing? In this blog post, we’ll walk you through three ways you can optimize cognitive load in your organization: identifying Cognitive Load Optimization strategies, using tools to track and monitor improvements, and implementing changes that reduce bad cognitive load as much as possible.

What does Cognitive Load mean?

Cognitive load is a term used in cognitive psychology to describe the amount of mental effort required to perform a task. It is the total amount of information and activities that a person's working memory can process at any given time. When the cognitive load is too high, it can lead to mental fatigue and decreased performance.

Identifying Cognitive Load

The first step in optimizing cognitive load is to identify the sources of the load. Common sources of cognitive load include:

• Complexity of the task
• Volume of information presented at once
• Interference from irrelevant information
• Lack of control over the task
• Novelty of the task

Monitor Progress with Tools

Once the sources of cognitive load have been identified, it's important to monitor progress towards reducing the load. This can be done through a variety of tools, including:

• Self-report questionnaires
• Performance monitoring software
• Eye-tracking technology

Optimizing Cognitive Load – Three Strategies

Minimize extraneous cognitive load

Extraneous cognitive load refers to the load that comes from information that is not directly relevant to the task at hand. To minimize extraneous cognitive load, you can:

• Present information in small chunks
• Highlight the most important information
• Remove irrelevant information

Minimize intrinsic cognitive load

Intrinsic cognitive load refers to the inherent complexity of the task itself. To minimize intrinsic cognitive load, you can:

• Simplify the task by breaking it down into smaller, more manageable steps
• Provide clear instructions and feedback
• Allow for customization of the task

Enhance germane cognitive load

Germane cognitive load refers to the load that is necessary to achieve a desired outcome. To enhance germane cognitive load, you can:

• Provide meaningful, relevant context
• Encourage exploration and experimentation
• Use visualization and other aids to support understanding

Bottomline

Cognitive load is an important concept in optimizing performance. By understanding the sources of cognitive load, monitoring progress, and reducing extraneous and intrinsic load while enhancing germane load, you can ensure that you are able to perform at your best.

I'm impressed by what people accomplish with tools like Excel, Macros, and some no-code automation. Recently, my DevOps team and I had the opportunity to support a project that aimed to replace such an existing, purely hand-built logistics solution with a custom-built system.

The company hired experts with lots of prior experience in such projects. Those experts made project plans, designed interfaces, created road maps. Then everyone went to work. As projects are want to do, this one blew away early estimations and went quite a bit over the time budget. Pressure mounted and corners were cut.

It was a wild ride. The team tried to roll out the new system all at once, and it was a complete and utter disaster. They attempted and failed with several roll-outs and ultimately had to roll everything back. It was a humbling experience and a valuable lesson.

When we approach the implementation of such big projects, a phased roll-out is key.

First and foremost, it's essential to start with a thorough analysis of the current system. Understand its limitations and the pain points that the users are facing. Instead the experts fell victim to the law of the instrument: they approached the project with previous solutions already in mind.

The things we know that just ain't so.

(not) Mark Twain

Involve the users and stakeholders in defining the requirements for the new system. Ask them where their biggest needs and problems lie. This way, you'll have a clear understanding of what the new system needs.

Next, instead of trying to replace everything at once, start with a small set of functionalities. Then gradually expand as you gain confidence in the new system. This minimizes the risk of failure and allows you to stay agile.

Moreover, it's crucial to have a robust testing and validation process to catch and fix issues before they surface in production. And, a proper training and communication plan should be in place. It is key to helping the end users to be prepared and using the new system efficiently.

Salvaging the situation

In the wake of the rollback, I sat down with some stakeholders to really listen to what they need. We found that one capability was completely missing from the current system: Automated handling of returns. Gaps like this are the obvious first step for a phased roll-out. As there is no component to replace, the risk is minimal and even small improvements would pay off. It is also the last step in our workflow. For the phased approach, we could back-track, working our way us until we have everything covered.

In summary, when it comes to big projects implementation, a phased roll-out approach is key. Starting with a specific functionality that addresses a specific pain point minimizes the risk of disruption to existing business operations and allows for adjustments to be made as needed. Additionally, you need a robust testing and validation process, along with proper training and communication plan, to ensure the success of the new system.