We all know it’s good to have a strong sense of ownership toward your work, but what happens when you get too attached?
Recently, I encountered this problem while collaborating with a smart, senior engineer who couldn’t make logical decisions if it meant deprecating the system he and his team had worked on for a number of years. Even though the best thing would have been to help another team create the replacement system, they did not want to entertain the idea because it would mean putting an end to something they had invested so much in.
I recognized this behavior, because this has happened to me, too. So, I started thinking about why this happens and what one can do to navigate these difficult situations.
One of the great things about writing software is that you get to create something. Great engineers typically are good not only at building things, but also at owning and maintaining them over time. This can foster a great sense of ownership and responsibility, which is something that is recognized and rewarded (in most situations, anyway) because it benefits the whole team.
Sometimes, however, ownership can lead to emotional attachment, and that can have negative consequences.
The longer you work on one system or application, the deeper the attachment. For years you have been investing in it—adding new features, updating functionality, fixing bugs and corner cases, polishing, and refactoring. If the product serves a need, you likely reap satisfaction for a job well done (and maybe you even received some raises or promotions as a result of your great work). I totally get this—I still have copies of big projects from 10-plus years ago that are so out of date they likely would not compile if I tried.
This can also be true for inexperienced engineers. I remember my very first job and my first bug.
I spent a few days getting up to speed, setting up my environment, and then fixed the bug—submitting my first check-in to the large project we were working on. That night, one of the senior engineers, working late, had reviewed all the new code that had been checked in prior to the nightly build. Apparently my function didn’t meet his approval, so he erased it and rewrote it as part of another class. I still remember the next day I was devastated. It was like he had erased my whole career with a single submit. When you have only a small amount of work, every little thing you do represents a lot of your career, and so it is easy to be attached.
This doesn’t just happen with code. It can happen with ideas, proposals, projects—anything you have invested significant time, energy, and care in. It is natural that people become very attached to things they have invested in, but unfortunately, that attachment can often make it difficult to see your work objectively, as other people do.
When Ownership Turns Emotional
Becoming too attached to your work can have negative consequences. While each situation is unique, sometimes it can result in suboptimal decision-making. Here are a few real-world examples (keep in mind that these can be good or bad, depending on the circumstances):
- Building functionality in one system instead of another, based on the team that owns it (that is, some manifestations of Conway’s law).
- Prioritizing tech debt or refactoring projects over new features.
- Refusal to adopt or purchase other implementations that are superior in some way.
- Maintaining an investment in a project longer than justified (that is, sunk-cost fallacy).
- Impaired or slow decision-making.
In a Utopia, all people act rationally, are able to weigh the pros and cons, and make well-informed, thoughtful decisions. In reality, though, people are emotional creatures and their judgment can be clouded.
As a leader, this can be tough to navigate, because you want to encourage strong ownership and enable people to work on projects that satisfy them. At times, however, these desires can be at odds with the decisions you need to make for your business and goals.
What do you do when you have to work with someone who is too attached? Following are some of the strategies that have worked for me.
Strategies for Navigating Emotional Attachment
1. Align on goals and purpose.
The first step is to ensure all parties agree on the objectives and goals. If you don’t know which variables you are optimizing for, it will be difficult to achieve alignment.
Start the conversation by asking questions that will uncover what the other people are focused on. Try to understand what things matter to them. Then you can determine if your goals are different and if you need to negotiate or escalate. Your job is to figure out how to align on the same outcomes.
Once you reach an agreement, it can help to record it (on a whiteboard, in an email or document, and so on) since some people absorb and interpret things differently out loud and in writing.
Sometimes this alignment is enough to make decisions and move forward.
2. Ask everyone to be open to ideas and alternatives.
Sometimes people might think they know the answer. They have already thought through all of the options and they are certain they are on the path forward. While unintentional, the result of this thinking may close off any consideration of alternatives.
By asking people to be open to other ideas, and by being willing to entertain other options yourself, you can start a dialog to consider different approaches. There are seldom right answers. There can be wrong answers, but most of the time there are just different options with pros, cons, and risks.
Work together to explore other options, and for each, lay out the different considerations. This can help frame the discussion and potentially uncover issues that may not have been obvious to everyone involved.
3. Ask for stories, not solutions.
When you focus on the specific details or solutions to a problem, alignment can be more difficult. Just like someone’s values, these beliefs are so strongly held, it can be challenging to change anyone’s mind. If you focus on the how and why, however, it can be much easier to find common ground and solve the problem.
For example, if you start with the premise that a service must exist to provide a certain API, it can be difficult to argue. Where can you go from there? However, if you start with the story of what the API is used for, it may be possible to provide that data in a completely different way elsewhere in the system.
By framing it as a story, using the big-picture insight you have as the leader, you can help the other people involved see the service in a larger context than they had been thinking about. It is so easy to get hyper-focused on one thing when you are too close to a project or have only the perspective of working in one department or team. This is your opportunity to help people zoom out and see the situation with fresh eyes.
Alternatively, you can ask people to imagine other scenarios where the service could be used in different ways from those they are currently working toward. Maybe they see only one logical solution right now; by asking them to look for other functions the service could have, you can help them unlock more ways that the problem could and should be solved. This allows you to solve problems more creatively and see more perspectives on the situation.
As humans, we follow narratives far more closely and with far greater understanding than we do data or facts. Instead of just insisting that people change their opinions, you can guide them there by helping them reframe the situation or see it more broadly.
4. Accept their experience, suggest new interpretations.
Most likely, the positions of emotionally attached people are based on experience and significant effort. It is important to recognize and validate that experience. Being empathetic helps you understand where they are coming from and what the reasons behind their emotions are.
Once you have an understanding of their particular experience, it is much easier to suggest alternative interpretations or viewpoints based on that experience.
For example, if the system has been hardened against hundreds of edge cases, start by acknowledging that and helping them think through the “why.” This can lead to different discussions and stop you from talking in circles.
Ask questions such as: What drove so many edge cases? How were they discovered? Are any edge cases no longer relevant/needed? What risks exist if an edge case is missed in a future implementation? If you had to build the service again, what would you change to eliminate many of these edges? This line of questioning can help them assess risks and open their minds to potential alternatives.
If you are having difficulty influencing people, consider enlisting the help of someone they trust; this can be their manager or maybe other teammates. Sometimes having others on your side can help you influence and change someone’s decision. Those people may also be able to explain another person’s position to you differently and in a way that is less emotionally charged.
Either way, getting a second (or third) opinion on the situation can help add color and put you in a position to influence the outcome.
6. Practice being open-minded.
Sometimes emotional responses are driven by solid concerns, but the delivery or interaction can prevent getting to those details. By practicing patience, strong listening skills, and thoughtful question-asking, you can help take charged situations and dissect them. Don’t be afraid to ask why—and accept the possibility that the people on the other side may be right and you might be wrong.
Go into the interaction assuming good intent and looking for the opportunity to work together—not to prove something right or wrong. Having a curious mind and seeking to understand will lay the groundwork for a more positive discussion.
Most complex problems have multiple solutions, and you need to be able to separate your ego from your intellect and decisions.
As you work with more people and more systems you will inevitably encounter people who are very attached to their projects. The key to reaching common ground starts with being open and thoughtful. Always seek to understand other positions—and let people tell their stories. Validate their experiences, and ask thoughtful questions. And if you reach a roadblock, look to others to help you.
Being able to collaborate and work through these issues will make you a better leader and should lead to better outcomes.
Related articles
on queue.acm.org
Nine Things I Didn’t Know I Would Learn Being an Engineer Manager
Kate Matsudaira
https://queue,acm.org/detail.cfm?id=2935693
The Small Batches Principle
Thomas A. Limoncelli
https://queue.acm.org/detail.cfm?id=2945077
Death by UML Fever
Alex E. Bell
https://queue.acm.org/detail.cfm?id=984495
Join the Discussion (0)
Become a Member or Sign In to Post a Comment