If you’re stressed out by work, focus on creating impact instead
This is the another post in my weekly learning series about my journey of becoming a tech lead.
We all crave a feeling of importance. Dale Carnegie claims that
“the desire for a feeling of importance is one of the chief distinguishing differences between mankind and the animals” and it’s “almost as deep, almost as imperious, as the desire for food or sleep”.
This is also true for work — we want to be the M.V.P. (Most Valuable Player) of our team. The sense of importance provides meaning and motivation. At the same time, it also feeds our ego. After all, Marvel movies are popular for a reason — deep down, at some point in time, we all want to be heroes.
The word “responsibility” gives me mixed feelings.
In this post, I share:
- My old attitudes towards responsibilities at work;
- Two main ways my attitudes did not serve me;
- Two approaches for coping with the pressure from having too many responsibilities.
My old attitudes towards responsibilities at work
On one hand, the word “responsibility” reminds me of my importance and motivates me to produce great work. It feeds my ego and makes me feel good. On the other hand, it brings me stress. Feeling things depending on me sometimes weighs me down and even makes me paranoid.
I’ve lost many nights of sleep to questions like: “What if we can’t deliver the project on time?” or “There are so many unknowns; how can I know if everything will be fine?”. I would be restless until the project was almost done because I felt responsible for it. There’s no way to know for sure things would go well until they happened.
This way of thinking, using responsibilities at work to feed my ego and allowing them to interfere with my life, served me well at the beginning of my career. It motivated me to produce lots of good work and push projects across the finish line.
But it also did some harm, which I will go into details about later, but that was not obvious to me early on. As my career advanced, I took on more and more responsibilities. Gradually, this way of thinking did more harm than good.
Two main ways my attitudes towards responsibilities hurt me
1. It created an unhealthy sense of “ownership” and made sharing work and knowledge hard.
Earlier in my career, whenever I got assigned to work on a project, I would try to get all the work done by myself. I was reluctant to share any work when new team members joined the project. As immature and childish as it sounds, I thought of my projects as my toys, and I wanted to own them fully and didn’t want to share them with anyone.
So I worked hard hoping to get as much work done as possible before others had a chance to claim them. I created a false sense of competition in my head and tried to beat my “opponents”, who in reality were my teammates. If I hadn’t created this stupid, imaginary competition in my head, we could have created more value together and had more fun at work.
2. It created counter-productive stress.
As I mentioned above, my relationship with my work responsibilities made me restless. Because I allowed the sense of importance from work to feed into my ego, the responsibilities became personal. I was too close to my work to be objective and productive.
Nothing is a guarantee in the world of software development. There are always changes, surprises, and unknowns. All we can do is to use our best judgment and adjust quickly when new information comes. But because I took my responsibilities and projects to a personal level, this lack of certainty made me restless. This was harmful to both me and the projects.
This second effect had been taking a toll on me for a long time. I couldn’t find a way to protect my life without having to give up some responsibilities.
That was the case until I had a conversation with a co-worker who shared similar experiences. His words changed my attitude towards responsibilities.
He said what we actually want is to have impact, not responsibilities. Many people think having many responsibilities is a good thing because it reflects how important you are. But he doesn’t think so. He thinks responsibilities are costs, not benefits. They are costs we have to pay in order to create the impact we want. We should focus on creating impact and accept the responsibilities, but not let them drag us down.
I have been thinking about his perspective and arrived at two things that might be helpful.
How to cope with the pressure from having too many responsibilities
1. Avoid “bus count one” as much as possible.
Don’t be the only one the project has to rely on. If a project solely depends on you, something is wrong. You should share the knowledge with one or two teammates as much as possible. If you feel the amount of responsibility weighs you down, it’s a signal to share your knowledge.
You want to make yourself replaceable in your team. This can be counter-intuitive because we crave a sense of importance, and making ourselves replaceable goes against that. But being the single point of failure for a project is neither good for you nor the project. It can create a tremendous amount of stress.
When a project is in the spiking or inception phase, it might make sense to have only one person to work on it. In this phase, you should share what you learn with the team as early and as often as possible. As soon as the development plan is clear, you should bring in at least one other teammate to work on the project. Pair programming and code reviewing are good ways to spread knowledge while increasing productivity at the same time.
2. Seek impact, not responsibilities.
After you have done step 1, hopefully, you no longer feel like being the single point of failure for your projects. Even after that, the weight of responsibilities might still be there, especially when you think of all the unknowns and everything that can go wrong.
Like my coworker said, you should focus on creating value and impact. Unknowns and changes are inevitable in software development. You have to accept that things might go wrong and even get out of control. Projects might get delayed; some features might need to be cut, and you might not get to clean as much tech debt as you want.
I would argue you are not responsible for the success of a project. What matters is you try your best, use your best judgment, and communicate often and transparently with all stakeholders about how the project is going. Thinking we can guarantee the success of a project is like pretending to be omnipotent — sorry, none of us can control the Universe.
You might want to gauge your career progression by the number of responsibilities you have. Don’t. Instead, gauge your career progression by the value and impact you create. When you focus on the latter, you focus on moving the business forward. You are not limited by existing projects. This way of thinking opens the door for new opportunities. Some impact comes with responsibilities, some doesn’t. The key is to have the impact you want. Responsibilities are merely the side product.
When you focus on increasing the value you provide, you will naturally realize at some point in your career that the best way to increase your influence is by sharing your knowledge and vision and empowering the people around you. You will stop being obsessed with how much code you write and start to feel proud of how much your team achieves. That’s when you become a true team player and leader.
To be honest, I’m far from following my own advice and keeping a healthy distance between work and life. This is an area I’m still learning and trying to get better at. I will try out this new way of thinking and update on my personal blog with new findings. I would love to hear what has worked for you as well. 🙂
My career plan for the year is to grow into a tech lead. I’m excited about all the learnings ahead and would love to share this journey with you in a brutally honest fashion. I will be sharing my weekly learnings on my personal blog (not Medium).
In the next few months, I will focus on growing in the following areas, so you can expect to see learnings related to them:
- focusing on the big picture of the project instead of near-term implementation details;
- balancing my efforts between leading projects and coding;
- work-life balance for long-term productivity;
- the human side of software development: making sure everyone riding with me enjoys the ride and feels fulfilled and inspired.
Originally published at www.sihui.io on February 14, 2019.
