Recently I had a case where a very senior engineer in my team cannot let go his engineering pride in a project, and I had to step in and fix it before it’s too late.
Here’s the context: the very senior engineer has joined for over 6 months. Before joining, he open sourced a project at the previous company, he takes pride in it and thus ever since joining my team, he has been trying to bring in that project and grow its adoption. My team has a rule of 20% work-on-anything-you-are-interested-in time so he has been using it to promote his project. However the project turned out to be of relatively small scope, and not of critical value. there’re progress made but not a lot, not many user demand and thus we cannot commit more resources on this project. He is a bit frustrated and says he believes this is due to a different company culture.
This is the moment I realized I have to step in immediately because it has nothing to do with company or organizational culture, but that he did not fully realize where the problem is.
To tackle that, I helped him analyze the situation and status quo:
First, I clarified to him priority of the project — fact is this is not a top priority, and actually it’s not even in our priority or even backup list, it will remain a personal project and not become a priority for the team/organization until he can acquire critical users and prove there are strong business need, value, and customer demand for it. This is the most common and standard process in companies on how to bring up new initiatives and not specific to him or his project.
Second, as his manager, I’ve been and will be continuously supportive for him to use the 20% time to work on this project and grow its adoption internally, as 20% time is exactly for engineers to work on things they are interested in but not necessarily a priority.
Third, as one of the most senior people in the team, he needs to level up and think of an overall picture rather than over focus on his own little thing, in two folds: One, his official project scope is wide enough, and as a leader in the team, he needs to focus more on real priorities; The other one, he can be more artfully to push for his project rather than keeping on bringing up the project name — e.g. one of the org’s top priority is to break service silos within the organization, and his project can actually integrate and fill a gap between a couple services, so what he can strategically do is to emphasize on the integration and totally hide the project away, rather than keeping on pushing for the project using its name.
Last but not the least, let your engineering pride and ego go. The fundamental root cause of this struggling and entanglement here is that he felt the project was created by him, he is so proud of it and he gives himself a mission to drive the org to adopt the tool. Thus, upon frictions, he become frustrated. To solve the situation, he eventually has to let go the pride, and be brave enough to admit that, maybe the project is not popular for a reason, maybe it’s not bringing so much value as he originally imagined, maybe it’s ok to not try to drive the whole organization adopt it. Instead of keep on denying this fact, he needs to face it directly, as users and markets do not lie — they only pay for and ask for the most valuable things, not something that can bring “a little value” or “a little improvement”.
One example I gave him is my personal experience. Back in 2018, 2019, I was working on a state-of-art stream processing engine which had an ambitious goal and vision of unifying batch processing and stream processing architecture and use case. I’m so proud of it and so convinced that it’s going to succeed and beat the existing popular batch engines on market, like Spark, to the hell. I became blindly confident about it because the project was kind of my baby, thus blindly ignored all the other factors. At some extreme time, I had the opportunity to join Databricks but I was so proud of my project and believe in the judgement that Databricks will die as Spark is inferior to what I’m building.
Time proved I’m wrong. Databricks keeps on growing and expanding, while the adoption of my project is staggering and the OSS company behind the stream processing engine was acquired in a cheap price and eventually almost went dissembled. I paid a costly price for the unforgettable lesson that, users and markets don’t lie, and we have to bravely face the facts and let go our engineering pride and ego.
