We all crave for a feeling of importance. Dale Carnegie claims “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. On one hand, it 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 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 is almost done because I feel responsible for it and there’s no way to know for sure things would go well until they have 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. It also did some harm, which I will go into details 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 disserved 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 didn’t create 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, which 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 impacts, 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 impacts we want. We should focus on creating impacts 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 is weighing 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 much 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 impacts, 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 weigh 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 judgments, and communicate timely 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 later, you focus on moving the business forward. You are not limited by existing projects. This way of thinking open the door for new opportunities. Some impacts come with responsibilities, some don’t. The key is to have the impacts 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 here with new findings. I would love to hear what has worked for you as well. 🙂

[1] Just to clarify, responsibilities can be neutral. I’m criticizing the way I used to view responsibilities, not responsibilities themselves.
[2] Things might be a bit different for managers and product leads as much of their work is not about implementing solutions but more about setting directions or getting resources. Nevertheless, you should still share your vision and knowledge with the team as much as possible.

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 learning on the blog.

In the next few months, I will focus on growing in the following areas. You can expect to see posts 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.

Related Posts

• Not Working Overtime, but Working Flexibly

• Refactoring Legacy Code V.S. Staying Focused On The Current Project

• Never feel overwhelmed at work again- the M.I.T. technique

• The Fastest Way to Get Promoted as an Engineer

• Knowing what needs to be done