Being self-critical
Tags: selfcritical, career, feedback
Published: 2022-03-16 10:47:55

---
title: Being self-critical
published: true
date: 2022-03-09 00:00:00 UTC
tags: selfcritical, career, feedback
canonical_url: https://www.manuelobregozo.com/blog/being-self-critical
---

Like every person who is self-critical, finding your way to improve yourself can differ depending on the role and responsibilities you have.

A process that can both make you better as a professional/person but also gave you the necessary visibility that you are performing well. Or basically, paint point to the areas to improve.

And on top of that, I do see this as a unique feature or skill to develop and one of the attitudes that took me to different places.

Funny enough, in the process of improving you might get into changes and reinvent yourself just to focus on areas that make you feel better.

## **Different roles**

As a developer, measuring performance, the amount of software shipped, bugs created, the number of pull requests we have reviewed, the number of questions I was getting about my way of writing code, the amount of time we had to roll back a deployment, are some of the tangible metrics we can refer to while looking for results about how well we did.

Although not all of them depend on us, is just a metric to set a baseline.

So that, when looking for personal achievements, while having 360 feedback rounds, or performance checking, it becomes easier to get results or facts from which we can base whether we are performing under our expectations or not.

Or even define and choose milestones we have achieved over time.

Most companies have their own _framework_ that enables them to define the goals we need to achieve or the responsibilities we have to develop in order to become more proficient.

A mix of something in the direction where the company is moving, and what will make you better as a professional for that particular role. Targeting a win-win situation.

In my personal case, having switched to another role towards management, with not many technical implications, slowly became a challenge.

A challenge as it is hard to understand whether my performance of the last quarter/month/week was good or not, and which are the areas where I should focus more.

This is when OKRs, KPIs, or things like that can look like a good option. But most probably they are not for a personal evaluation.

## **Forget about the business and make it personal**

When thinking about performance and success, I am not referring to business progress but a personal indicator. Like a key indicator that I can refer to when looking back about how did I perform.

Link to the sense of how autonomous in my daily work I am.

Putting 360 feedback rounds and personal assessments aside, what can we use as a guide for a personal follow-up?

As I was saying before, using the company [north star metrics](https://mixpanel.com/blog/north-star-metric/) as indirect feedback can also help, but hard to link that to our personal development.

Take into consideration that a metric could also be something that isn't measurable, but we need to make sure they are not binary.

So let's try to think which things do we normally look at when thinking about how good we are in a certain role.

As a dev, I used to focus on deliverables and ways to improve that process without taking shortcuts or compromising the quality of the products I have built.

There are a lot of options that we can observe and monitor regarding that. We can even think of looking at the tracking system we use and measuring success based on the tickets we close per sprint or month, depending on the work methodology we use. Despite the drawbacks, it is known as lead time.

But, what happens when things are not that easy to measure? What if the work we do as Product Managers (just to name a different role that I am familiar with) is not as easy to measure?

Well, that only means that we have to be creative.

Don't confuse personal success with team success, it can be that things don’t go as expected but our personal performance taking the learnings, was good. There are always external dependencies that are not under our control that directly affect the final results, but that doesn't necessarily mean that we did badly.

## **Measuring non-technical work**

This is far from a final solution, but my first iteration is about things to look for when finding a way to measure success.

This came as a request from a manager but trigger some idea about how to accomplish such a request.

As someone insecure with a low profile, I am always looking back in time analyzing what things I could have done differently.

So finding a way to auto-assess myself became a complex puzzle to solve, but here are the things I took into consideration.

- Measuring what for each one of us is a success can be diverse and this is a subjective matter. What being successful means for me can be nothing for others and vice versa.
- Social media is out of the table, and as I am not a full-time content creator, metrics that I can get from it are not something I am going to consider.
- Use retrospectives to understand when the team has feedback about issues that fit under my responsibilities.
- Keep an eye on our autonomy, how much support do we need before making decisions or moving things forward.
- Define milestones or achievements that qualify as something you can count as a success for your role.
- Ask feedback to different stakeholders, especially to the ones outside of my team, and check how they perceived my role.

Beyond that, it is just about asking questions to ourselves.

- How many times have we switched priorities because of poor analysis, and not necessarily related to business changes?
- How many times have I had to re-defined use cases of a feature because they were not properly explained.
- How many hypotheses I was able to validate or discard.
- How many A/B tests have we performed?
- How many times has the data we have collected proved that our assumptions were correct?

Putting aside those ideas I try not to set numbers because as a former dev I will unconsciously find a way to trick the system and meet those goals, by only looking at the numbers.

### **Prevent cheating the system**

Defining metrics has drawbacks. When having them tight to promotions or salary raises can encourage people to tweak them in order to get better results, but not necessarily gain something out of it.

So from a manager's perspective, it’s always good and recommend to move money off this discussion.

Well, this has a name: [Goodhart's law](https://en.wikipedia.org/wiki/Goodhart's_law), from which we can abstract the following quote:

```
"When a measure becomes a target, it ceases to be a good measure"
```

The thing is, sometimes we transform metrics into our main target to the point that it stops bringing any value to what was our main objective.

Just to give an example of how targeting results can’t mean that our measured value is optimized would be by looking.

If I were to measure my success based on the number of hours I spend connecting with people over meetings, can cause me to change in the way I do meetings just for the sake of improving this measure but not necessarily improving my performance.

Other options that I have heard are the number of commits or speed of delivery that, as you imagine, can directly impact the quality of the software we deliver. Most people will focus on improving those metrics but not the quality of the code.

Most of the quantitative metrics can be gamed. You will end up with either someone that knows how to game the system or someone that gets along really well with higher-ups. But not necessarily improving your skills.

Overall there isn’t a single way to develop this, as it’s something personal, and we all have different goals and expectations about the future, so the bias can't be removed from this equation.

So, allow yourself to fail, try again, and whatever felt like a good metric in the past can be meaningless towards the future.