How to Avoid these Engineers Pet Peeves

Lee Ling Yang
Nov 27, 2020 · 5 min read

How do you soften the blow and work around the conversations you must have with you engineers?

Photo by Anna Shvets from Pexels

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”

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.

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.

How to work with engineers book cover
How to work with engineers book cover
Link to get the book “How to Work with Engineers”

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)

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.

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)

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.

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)

Everyone is afraid of deadlines, including engineers. They are reluctant to give you an answer for two reasons:

  1. 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?
  2. They don’t want to get blamed when they miss the timeline.

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:

Download my book How to work with Engineers

How to work with engineers book cover
How to work with engineers book cover
Link to get the book “How to Work with Engineers”

The Startup

Get smarter at building your thing. Join The Startup’s +793K followers.

Sign up for Top 10 Stories

By The Startup

Get smarter at building your thing. Subscribe to receive The Startup's top 10 most read stories — delivered straight into your inbox, once a week. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +793K followers.

Lee Ling Yang

Written by

Director of Product @ LionDesk. Author of “How to Work with Engineers”. Ex-Biologist. Biker. Empower Women in Tech 🇨🇦

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +793K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store