Performance Pyramid

The performance pyramid forms a part of a performance framework that establishes clear expectations on how to succeed in the organization. It's a tool for changing behaviour and should be used in the earlier stages of onboarding and probation as well as during performance reviews.

Performance Pyramid

Tip

Here's a Google Sheet template for the pyramid that managers can use for their reports. It includes tickboxes and a notes section

Performance Pyramid sheet

I came up with the performance pyramid at Neara during a scale up stage where there were a number of challenges presented:

Issues the Performance Pyramid Fixes

Levelling Up a Junior Workforce

The company traditionally did well with graduate and junior hires. Great return on investment in the early stages with smart, hungry and motivated individuals.

The challenge was the level of professionalism wasn't quite what you get with seasoned engineers. This compounded with COVID lockdown where interactions with peers was limited. The valuable face time was deprived and the subtle social cues and rapport building disappears with the transactional nature of video conferences.

The bottom of the pyramid, the foundational skills addresses this. It sets the tone and expectations for every individual of what the baseline should be. By delivering it earlier on at onboarding time and during probation, you can assure that the individual you hired levels up in their professionalism. Visiting the pyramid and making it part of performance reviews ensures that it stays that way.

Supporting Process Experiments Thoroughly

The headcount quickly increased causing constant shuffles in skillsets, teams and processes. We were trying all sorts of new ways to do agile, moved team members around to where we thought was appropriate for deliverables all the while trying to reduce the amount of knowledge silos.

This meant that there were varying degrees of compliance on processes. A process is doomed to fail if nobody gives it a proper go. I can't stress that enough. An organization should always be experimenting and improving on their processes. If a strategy is set, everyone should do their best to support it even if they don't agree with it. Once the experiment has run its course and it clearly isn't working, then proposals to improve the process should be actioned -- and it should be open to constructive criticism. It will be doomed from the get go however, if there is non compliance from the beginning. It also sets the culture of support. The next strategy might be yours and you wouldn't want it to die without everyone giving it a good try.

Again, the foundational skills addresses this. This time with heavier emphasis on Follows Processes. It's not there just for show. Here are some concrete examples where there's a negative ripple effect across roles if not followed well:

  • Has this person actually filled out their work tickets properly and kept them up to date? There are several methodologies out there in managing work and most like it involves a ticketing system like Jira, Fibery, post it notes etc. Not filling it out properly means:
    • Product Owners and Managers can't see work to plan it,
    • lack of acceptance criteria means bugs can creep into the system,
    • tracking time spent on work and their associated costs on projects is lost
    • people rabbit hole due to lack of understanding
    • knowledge silos continue as context is kept in the implementer's head, of which they can forget too
  • Are they following the software development lifecycle as everyone else? This can involve tooling and code revision style, CI/CD practices, addressing CVEs in a timely manner, and even the current flavour of workflow methodology (Waterfall, Agile, Shape Up etc.)
    • If the org uses commit based reviews on a specific tool but another team wants to use branch based reviews on GitHub, the knock on effect is that metrics like code review turn around times get muddled. You would need to instrument that metric in more than one place and you lose insight into the overall developer experience of fast reviews. Now developers would need to have two ways of working instead of one.
    • Not addressing CVEs in a timely manner would affect SLAs and compliance requirements for things like ISO 27001 and SOC2.
    • Not committing to the workflow methodology means teams lose information on things like velocity, prioritization, reporting, planning and other metrics. This is the fundamental way the organization works and deviating from it makes everyone's life harder which may cause managers and above to put a magnifier glass on individuals and nobody likes to be micro'd but how else would they know what's happening?

Making Actions Speak Louder Than Words

After all the planning, prioritization, de-risking and talking, the business needs to see results. The engineer needs to make impact, especially in individual contributor roles. Plenty of people can discuss all day about their great ideas but then get stuck in analysis paralysis or can't move the needle or don't carve out time for their goals. Impact needs to be shown, not talked about and that's what the Exemplify Performance section is all about.

In order to succeed, people need to be hitting goals -- not necessarily all of them but there's got to be effort there and not make it just an administrative task.

They need to work sustainably and consistently. Health and predictability are important. People should be reliable and not move up and down in odd waves of burn out. Once burn out happens, it can take much longer to recover than to consistently deliver. I've seen first hand how long that can take and that's not a pretty place to be. For example, 2 weeks of high throughput followed by 1.5 months of slowness makes it really hard for the team to plan and rely on that individual. For more extreme cases, it can take months and months to recover.

The bulk of the organization should be operating in this realm of the pyramid to be effective. These people can lead by example and be a solid foundation for moving the needle.

Correlating Hard Work with Outcomes

There's an infinite amount of work out there. What's the most impactful thing someone can do and how does it relate to the bottom line? The number of people and resources aren't infinite so people need to be aware of what will help the organization the most. An engineer who goes off to do some SQL optimizations and save $1k a month is fine and dandy but they could have been on something else that generated $20k a month in features. People might be working hard but they need to work on the right thing that the organization values most at the time. The Show Value part of the pyramid will align and quantify the individual to business goals and show them the level of impact they had with real numbers.

It's important from the onset of work that people think about what it is they want to achieve and what success metrics look like. Metrics will look different for every organization but here is a concrete example for Neara. Neara creates digital twins from geospatial data GIS and LiDAR. It can then provide insights into the power network once it has the twin.

  • km/h: how fast are people digitizing the network? Let's say there's a team that manually does this, pole by pole, cable by cable. As an engineer, you could build algorithms and tooling that boosts this metric. This correlates directly to time saved in manual labour and you can put a dollar value on that.
  • processing costs: Processing insights into hundreds of thousands of kilometers of network length can be costly, especially when using a public cloud provider. An engineer can use a brand new technology, implement an algorithm efficiency, make the processing more reliable (e.g. less failed / restarted jobs) etc. which reduces the overall cost.
  • classification speed: Classifying TBs of LiDAR can take awhile. Increasing the speed of classification of each point e.g. from 100M points / second to 1B points / second has a direct correlation to costs as well. That means the model takes less GPU time and saves money in infra costs. It also means people can deliver faster and don't have to wait as long for the model to run, allowing them to bring value to customers earlier.
  • feature revenue: Sometimes there's a feature that straight up has a dollar value attached to it that one or two developers can work on. e.g. If there was a feature that was being billed for $250k, it takes 1 week to build and the developer's salary is $150k, that's a no brainer. That person has almost paid for their year's worth of salary already.

We'll talk more about metrics in a different area but that's just a few examples of what individuals need to be looking at and correlating it back to some success metric to measure their impact. They should be proud of what they've accomplished and have hard numbers to back that up.

As for the positive reviews from both peers and managers, it's to make sure that we aren't promoting and exemplifying really smart...but really mean people. Leave ego at the door and come to work to do great things.

Giving Managers a Framework to Identify Good Performance

Finally, in terms of performance reviews, having the pyramid makes it easier for managers and their reports. Reports can self select whether or not they're doing all the things in the pyramid. This reduces the burden on managers for people who just ask for raises and promotions without anything to back it up. It provides them a framework for people who ask anyway and to point out each individual item where the report needs to improve upon. It doesn't mean that everything has to be perfect, but the majority of each level of the pyramid has to be there.

By having more objective measures that relate to business goals, managers will be able to represent their reports with confidence when it comes to performance reviews and especially for promotion considerations.

For reports not meeting the standard, it gives the managers a framework to sit down and discuss deficits and improvement plans for their reports. It becomes less about me vs you and more about clear expectations in the standard process.

This should be seen as a contract. If the employees are doing all these things, they should be rewarded. If not, don't blame the employee for leaving.

Have a look at the performance reviews section for more on how the pyramid plays a role in it.

results matching ""

    No results matching ""