Say These 4 Phrases to Make Engineers Love You Right Away
Build trust and rapport is key to working effectively with engineers. Show them you can help them focus on what they love and do best — coding.
I made this clear to my engineers — so they know I’m available to help remove bottlenecks and shield them from distractions. The quote sums it all.
“My job is to play defense — so you can run as quickly as you can”
1. “What can I do to unblock you?”
Why will engineers love this?
When you are stuck, it’s comforting to know someone cares to know why and wants to help.
What to do after you said it?
Needless to say, the first step is to identify the blockers. Some common ones:
- Vague requirements — What are they confused about? Walk them through the use case again and include more designs.
- Unclear on the technical approach — If they haven’t solved this problem before and are shy to ask for help, you can connect them with more senior engineers who may know the answers.
- Waiting for another party to proceed — If they are waiting for another teammate to review their code, surface this to the rest of the team in Slack channels or standup. Explain why it is important to push it live asap.
A more scalable approach is to encourage the engineer to be proactive in telling you when they are blocked — rather than having you to ask them.
2. “I trust you to make the right (technical) decisions”
Why will engineers love this?
Who doesn’t like to feel trusted and have the autonomy to decide what to do?
What to do after you said it?
Be clear on the business constraints. So the engineers know how “good” the solution needs to be given the resources they have. Some common considerations:
- Is this just a proof-of-concept? Or does it need to scale to support all users?
- Will they be working on their own? Or will they have help from other engineers?
- How much time do they have to build this?
3. “I can manage the stakeholders’ expectations”
Why will engineers love this?
They know you have their back and will shield them from external pressure.
What to do after you said it?
I often share the key quotes from the stakeholders — so the engineers can empathize with the problem they are facing. They want to know when they will get what they want. Unknowns and uncertainty stress people out.
If the engineers can provide a tentative date, make sure they are proactive in flagging any risk that can cause a delay — so you can reset expectations.
If they are not in a position to give a date, tell the stakeholders when they can expect the next update and what progress you’ve made. This gesture gives them peace of mind that their requests are still being worked on. Some common stressors:
- Bug fixes — Here are a series of sample replies you can give to update users on a critical bug
“We are currently reproducing this bug — so we can investigate the root cause. I will have an update before noon.”
“We have some hypotheses on what the issues could be. We are reverting the recent updates so it doesn’t cause further issues — while narrowing down what the root cause would be. I will have an update around 1pm”.
“We’ve found the root cause. The fix will be deployed by 4pm today.”
- Feature launches — I use release maps so they can see what we are working on now and what’s coming up next for a few months. So they are not in the dark.
- Changing priorities — Resist the urge to treat every request as 911. Engineers enjoy deep work and focus on solving one problem at a time. Context switching to a new task while the last one is not finished is draining for engineers. They like to see their code push live where real users can benefit from. If you need to, clarify the priorities by specifying how much you want the engineers to spend time on the new issue.
4. “You don’t need to attend that meeting”
Why engineers live this?
They get more time to focus on what they love the most — coding.
What to do after you say this?
Fill them in on anything that can impact them — especially change in scope, priorities to timelines. So they are not caught by surprise.
Record the meetings and highlight the timestamp when important discussions are brought up. So they get the full context. You also won’t need to worry about mistranslating any technical information.
Sum it up
Trust and autonomy are what motivate people. Engineers are no exception. Keep repeating these phrases. Nobody will get tired of hearing them.
Want to know what NOT to say? Check out “How to Avoid these Engineers Pet Peeves”
Are you a looking to work more effectively with engineers?I’m currently writing a book to address these pain points. As I’m preparing for the next iteration, get it at any price you want. (You read that right — including free).
