So this is something I’ve been thinking a lot about lately, and I figured it might be worth doing a blog post about, and that’s the topic of Perfectionism, and the idea of being your own worst enemy.
In my new role, I’m doing a lot more coding, and software development and I find myself in a position that I’ve been in before, where I have sort of a “blank slate” to build out something and have a degree of latitude to figure out the “how” I want to do things. And it can be great, but also stressful.
We’ve all heard the stories of Steve Jobs, Elon Musk, Thomas Edison, and others. Who demanded nothing less than perfection from themselves and those who they worked with. And we’ve all had that manager who’s standards were too high, or even been that person who tries to make every detail of your work perfect.
I have lots of times where I catch myself doing the later, and being the one who holds myself to a higher standard, and there can be a lot of reasons for that. Some of those reasons include:
- Fear of Failure
- Imposter Syndrome
- Lack of self confidence
In my experience, due to the positive nature of the word “Perfectionist” because of people like Elon Musk, or Steve Jobs, there is now this “convention” where people say “I’m just a perfectionist” to really help mask one of the other truths above.
And at the end of the day that’s telling yourself a lie, which can create this vicious circle. For example, it took me a long time to realize that my perfectionist tendencies were really imposter syndrome.
And this ultimately created a vicious cycle, as follows:
- I would be over critical of my work, and put in more hours thinking that it “Needs to be better” or people are going to “realize I not as good at this as I think I should be.”
- When people would identify the extra hours and work, I would hide it by saying “I’m a perfectionist, and just need to really deliver the best work possible.”
- I would then feel increased pressure to deliver perfect every time, and repeat the cycle with more intensity.
And it should surprise no one, that the above cycle is about the furthest thing from sustainable that you can get to, and because I would take on too much and put too much pressure on myself, I would then set myself up for failure, which made my imposter syndrome a self-fulfilling prophecy.
Now after talking to friends and colleagues, I find that this type of issue is pretty common, subtle differences might be involved (Remove imposter syndrome, and replace with “Fear of Failure”). And the first thing to know, is you are not alone, there are a ton of people now starting to talk more about this. Personally I like Scott Hanselman’s discussion on this topic, found here.
But here are some tricks I’ve found to help myself avoid this, and increase the amount of work I deliver and getting to a quality I am satisfied with, and avoid the downward spiral.
This is the biggest thing I find that helps me, so let’s do it first. And I did this recently with a coding project that I needed to work on. I take every coding project and break it into small tasks, things that can be done in like 20-30 minutes. And then I break that list into two categories Essential and Nice to have.
The idea here being that I am forcing myself to take 2 minutes and define what is absolutely essential and what would be nice to have. And then as I work on this I will focus on the Essentials, while roping in as many nice to haves as I can.
Now what I did find is that this alone is not enough, as you will find ways to push to make sure both groups get done, but Tip #2, helps with that.
The next part is that I will timebox everything I do, maybe not with tight like “I have 30 minutes to do this.” But more of a “I’m going to get X done before lunch.” And I find that by doing so, I ensure that I don’t lose focus on the larger picture.
This forces me to keep the essential at the front of my mind, and only let’s me go so far down the “rabbit hole” that is the “Nice to have” list.
At the end of the timebox, I then adopt the Scrum mentality and either add the “Nice to have” items to the backlog, or throw them out all together. This helps me feel like I’m being productive and delivering on what I need to, and can lead to a confidence boost, when I see how many “Nice to haves” I knocked out.
This is the other critical one, I’m clear for myself and when I communicate with team members about this. Avoid words like “need to…” and be clear about “trying things”.
For example, I had a scenario where I wanted to implement threading in python to resolve an issue and making something more performant. At the time I hadn’t even researched threading, so I was very clear with my team members that I was going to “try” and make this work, and made sure that I went into it with the expectation of trying, not that I 100% committed which reminded myself that getting this working was not essentially.
Now as it turns out threading in python is really easy, and was pretty thrilled with the results (2 hour process down to 17 minutes). But it helps to understand that you need to make sure that you are clear about what you are “trying to do” or “experimenting with” and what the expected outcome is.