You know it is good to have strong ownership, 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 didn't 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 wouldn't 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 hard to see your work objectively, as other people do.
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 (i.e., 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 (i.e., 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.
The first step is to make sure that 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, etc.) since some people absorb and interpret things differently out loud and in writing.
Sometimes this alignment is enough to make decisions and move forward.
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.
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 has to exist to provide a certain API, it can be hard 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.
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 that 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.
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.
Nine Things I Didn't Know I Would Learn Being an Engineer Manager
Many of the skills aren't technical at all.
Kate Matsudaira
https://queue.acm.org/detail.cfm?id=2935693
The Small Batches Principle
Reducing waste, encouraging experimentation, and making everyone happy
Thomas A. Limoncelli
https://queue.acm.org/detail.cfm?id=2945077
Death by UML Fever
Self-diagnosis and early treatment are crucial in the fight against UML Fever.
Alex E. Bell
https://queue.acm.org/detail.cfm?id=984495
Kate Matsudaira is an experienced technology leader. She worked in big companies such as Microsoft and Amazon and three successful startups (Decide acquired by eBay, Moz, and Delve Networks acquired by Limelight) before starting her own company, Popforms (https://popforms.com/), which was acquired by Safari Books. Having spent her early career as a software engineer, she is deeply technical and has done leading work on distributed systems, cloud computing, and mobile. She has experience managing entire product teams and research scientists and has built her own profitable business. She is a published author, keynote speaker, and has been honored with awards such as Seattle's Top 40 under 40. She sits on the board of acmqueue and maintains a personal blog at katemats.com.
Copyright © 2019 held by owner/author. Publication rights licensed to ACM.
Originally published in Queue vol. 17, no. 2—
Comment on this article in the ACM Digital Library
João Varajão, António Trigo - Assessing IT Project Success: Perception vs. Reality
This study has significant implications for practice, research, and education by providing new insights into IT project success. It expands the body of knowledge on project management by reporting project success (and not exclusively project management success), grounded in several objective criteria such as deliverables usage by the client in the post-project stage, hiring of project-related support/maintenance services by the client, contracting of new projects by the client, and vendor recommendation by the client to potential clients. Researchers can find a set of criteria they can use when studying and reporting the success of IT projects, thus expanding the current perspective on evaluation and contributing to more accurate conclusions.
Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler - DevEx: What Actually Drives Productivity
Developer experience focuses on the lived experience of developers and the points of friction they encounter in their everyday work. In addition to improving productivity, DevEx drives business performance through increased efficiency, product quality, and employee retention. This paper provides a practical framework for understanding DevEx, and presents a measurement framework that combines feedback from developers with data about the engineering systems they interact with. These two frameworks provide leaders with clear, actionable insights into what to measure and where to focus in order to improve developer productivity.
Jenna Butler, Catherine Yeh - Walk a Mile in Their Shoes
Covid has changed how people work in many ways, but many of the outcomes have been paradoxical in nature. What works for one person may not work for the next (or even the same person the next day), and we have yet to figure out how to predict exactly what will work for everyone. As you saw in the composite personas described here, some people struggle with isolation and loneliness, have a hard time connecting socially with their teams, or find the time pressures of hybrid work with remote teams to be overwhelming. Others relish this newfound way of working, enjoying more time with family, greater flexibility to exercise during the day, a better work/life balance, and a stronger desire to contribute to the world.
Bridget Kromhout - Containers Will Not Fix Your Broken Culture (and Other Hard Truths)
We focus so often on technical anti-patterns, neglecting similar problems inside our social structures. Spoiler alert: the solutions to many difficulties that seem technical can be found by examining our interactions with others. Let’s talk about five things you’ll want to know when working with those pesky creatures known as humans.