When Being Helpful Backfires
3 February, 2021
One of the teams we worked with had a product launch coming up that they were trying to accelerate. They wanted to be able to launch their experiment early and get feedback from users. To do that, users needed to be able to purchase this product. It was still a very early stage product, but they wanted to be able to do some limited ability to sell it to our customers. My team was responsible for all the checkout pages and the specific work that had to be completed for them to sell their product.
They came to us asking when we were able to build the checkout capability they needed, according to our existing roadmap. It was scheduled for six or seven weeks from then, but they wanted something a little sooner, asking for three to four weeks. They came to me, as the tech lead, proposing we shift the schedule around and get that capability available sooner so they could have more time to run their experiment and more opportunity to gain revenue for their project. That project was driving their team's success metrics, and they felt significant pressure to get it out the door.
I started talking with their lead engineer, and what they were asking for was something I didn't think we would have ready anytime soon. Because I wanted to support their launch as well as we could and not block it on our existing constraints, I recommended that they just copy all the code that we had into their own little sandbox, hack on it the way they needed to, and get something up and running. We had a lot of work to complete in those six to seven weeks timeframe and having them working with us in that code would have been very disruptive to both teams. I thought that the best way would be to fork everything, have them work on their own fork until they get what they needed and then we could go on and do our thing.
When I brought my recommendation back to my team, explaining what they had asked to do, I got a strong pushback and came to realize that I had a bad misunderstanding about what our schedule was and what we were planning to deliver. It turned out that what I was thinking was a long way off was in fact, much sooner than what they were asking for. My recommendation to them to fork the code was hugely problematic because there were a lot of things that we were going to be changing that would make that much more complicated than I realized.
I was fairly new to the project, but as a tech lead, my job was to understand these things and to make recommendations based on actual knowledge and not intuition. My team convinced me that the forking was a bad idea. I went back to the other team and tried to convince them of this by enumerating all the problems with copying the code while working on the things we had to complete. There were a lot of compliance requirements, including making sure taxes were correct, the required disclaimers were shown to users anytime we were taking money from customers, etc. There were just too many additional requirements they needed to be able to deal with, and they weren't familiar with the code.
However, the horse was already out of the barn -- they had their target to hit, and we couldn't convince them not to do it even though we were going to deliver what they asked for within a couple of weeks of what they wanted. We felt it was reasonable for them to wait, but they felt that they needed to do everything possible to accelerate their launch. There was a lot of pressure on them to get their product released. They were approaching the problem from a perspective of “If it is possible for us to do, we should because it would save us time.” We were approaching the problem from a perspective of “This is going to be a huge amount of work with a lot of unknowns, that would not save them much time, but could put our work at risk.”
We kept working from these two perspectives, but we didn't realize it. We had a week and a half of discussion, trying to figure out how to get our idea across. More people got involved, including managers, and the stakes kept going up for the decision.
In the end, we were not successful in convincing them not to fork our code. They decided that even if there would be a chance that it wouldn’t work, the prospect of having a couple of extra weeks was worth it. We had to wash our hands of it and emphasize that we strongly recommend not to do this, but we couldn’t stop them.
We ended up escalating that to the group leads, explaining why we thought it was a bad idea. I was frustrated not because their approach was wrong but because it was my own recommendation in the first place that caused it. We spent a huge amount of time trying to get this thing resolved that delayed our other work. In the end, my manager actually assigned someone else to be dealing with it because they had other things they needed me to do, and I didn't have an opportunity to fix the problem that I caused.
- I got myself and my team into this problem because I was trying to be helpful to the other team that wanted to achieve their goal. But I wasn't thinking through how the recommendation I made would impact my team. Even though it's good to be helpful, I should have paid more attention to the broader dynamics before I made the recommendation.
- Make sure you know what you're talking about. I was going on some assumptions, and I was wrong. Even though I was fairly quick to realize my mistake after talking with my team, the damage has already been done. It hurts the credibility of our team for me to make a recommendation and then to walk it back. All those things could have been avoided if I'd been less eager to be helpful and more willing to talk to my team and then make a recommendation.
- Not everything is in your control. I recognized the mistake and tried to walk it back. Though we tried to convince them, it was ultimately not up to us if they would accept our recommendation. At some point, I had to stop blaming myself for causing this huge problem and just get on with it. Even when we make mistakes and try to fix them, not every mistake can be fixed, and not every bad situation is caused by the mistake you made.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Andrew Schamp, Software Engineer at Dropbox, recalls recommending a risky and time-consuming solution that he couldn’t take back without talking to his team first.
Software Engineer at Dropbox
Andrew Schamp, Software Engineer at Dropbox, tells of his efforts to improve team peer reviews and build a quality culture across the team.
Software Engineer at Dropbox
Glenn Block, Principal PM Lead at Microsoft, reflects on the problem of accountability and how being explicit about what you can do helps with expectation setting and alignment.
Principal PM Lead at Microsoft
Guru Kini, Co-Founder and CTO at Fincity, recalls how he managed to strengthen the coherence of a remote team dispersed across different time zones and improve the team collaboration, and productivity.
Co-Founder & CTO at Fincity
Aurélien Pelletier, CTO at PrestaShop, details how to establish and manage expectations with the business and their often unrealistic requests.
CTO at ex PrestaShop
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.