How to Avoid these Engineers Pet Peeves
How do you soften the blow and work around the conversations you must have with you engineers?
Reporting bugs, asking for the feasibility of building a feature and timelines are conversations we must have with engineers. However, those are topics that engineers dread and can often turn into heated conversations. How do you soften the blow and navigate these discussions?
1. “It didn’t work”
Why is this annoying?
It doesn’t provide any details to help the engineers solve your problem. Which part didn’t work? (The data didn’t get updated after you hit save or the page just keeps loading?) What did you do before that?
Without any “evidence”, the engineers will likely reply “It is working as intended”. This leads to a circular loop and frustration.
Do this instead
Provide the details so they can reproduce the problem. This means they can follow the same steps and see the same result as you do.
Very often, it only happens to a subset of users. Sharing this helps engineers narrow the possibilities. It also helps them ensure that the solution doesn’t introduce new problems to the users who are not impacted.
Are you a looking to work more effectively with engineers? Check out my book that address these pain points.
2. You can build this right? (aka. Shiny object syndrome)
Why is this annoying?
We often get excited about an idea and want to see it come to fruition. Calling an impromptu meeting and spending hours babbling an idea distracts engineers from focusing on other tasks you asked them to do.
Do this instead
Channel your excitement and creativity into words. Write a one-pager with a high-level overview of what I’m looking to build. Flush out your idea with one or two of your closest developers to free up others’ time.
If you really need to call that meeting, keep it to no longer than an hour. Be very clear that the idea is still at an exploration stage and you are not looking to change their priorities. This is an important disclaimer — especially if you are in a leadership position. So they don’t drop everything to work on your half-baked idea.
3. You can build this instead? (aka. Rework)
Why is this annoying?
Changing the requirement often requires taking down what they built. It’s discouraging to have to throw away codes they spent days writing — or solve the same problem for the nth time.
Do this instead
However, it is unavoidable — because someone changed their mind last minute or forgot to communicate a key workflow. I reframed the problem to make it sound easier and more exciting.
- You will do it faster and better this time — because you know what didn’t work last time.
- Would it help if I pair you with another engineer to divide and conquer? You are the expert in this area — and I want you to teach others how to do the same.
The second example is best for engineers who aspire to be in a “leadership” role. To the other engineer, this is a “new” problem.
4. When can you build this (aka. Timeline)
Why is this annoying?
Everyone is afraid of deadlines, including engineers. They are reluctant to give you an answer for two reasons:
- They have not tackled this problem and therefore they don’t know what the solutions are. How can they give you a timeline without knowing what to do?
- They don’t want to get blamed when they miss the timeline.
Do this instead
Deadline is a necessary evil as your work depends on the engineers — either to sell a new product or tell users when issues will be fixed.
How do you get past the “I don’t know”?
- Offer to give them a day or two to investigate. So they are not pressured to give you a makeup number that you can’t trust anyway.
- Throw out two extremes, such one day to a week, and see how they react. When you hear “Definitely not a day”, then you can rule out the impossibles. If you say “a week” and you see a look of relief, you are more likely to get it by then.
When I get a precise number, I add a 20–40% buffer on top of the numbers the engineers give — and round it up.
Buffer is important to account for the unexpected. Here are the surprises I often encountered:
- They push their fix live — but it didn’t actually fix the issue or it introduces another bug.
- They weren’t able to push their fix live — because another developer’s work changed how the feature should work.
Say the estimate is 4 days. The buffer would be:
4*0.2 = 0.8 = 1 day
4*0.4 = 1.6 = 2 days
So the actual number of days will fall between 4+1 = 5 days to 4+2 = 6 days.
Sum it up
If you can’t enhance the relationship, at least don’t break it by avoiding saying the wrong thing.
This is especially important when you and your engineers are still getting used to working with each other.
Trust is the most valuable investment. Sometimes, it only takes one bad conversation to lose the rapport you’ve worked hard to establish.
Want to work more effectively with engineers?
Check out these related articles:
- Say These 4 Phrases to Make Engineers Love You Right Away
- Scripts for Tough Conversations with Engineers
Download my book How to work with Engineers
