How Non-Engineers can work with Engineers
Over the past 16 months, I’ve had the pleasure of working extremely closely with senior level software engineers and I wanted to write about the findings that might be helpful to me in the future. I think other people might find value in this as well if you are or hope to work with engineers in your career.
As a fairly junior professional, I consider myself incredibly lucky to have had the chance to work with senior engineers who’ve had combined over 35 years of engineering experience. They vary from startups to massive corps such as Atlassian, NASA, TED Talks, & FB.
I learned a LOT working closely with them on multiple products. Some lessons turned out to be critical building blocks in not only working well together but eventually becoming friends in real life.
Working well with engineers is perhaps the most underrated skill of the 21st century.
A line that has stuck with me ever since I heard it from one of the engineers.
There’s 5 critical things to understand and improve:
- Understand the engineer’s role
- Communicate clearly
- Engineers have great product ideas, listen to them
- Keep them updated on progress
- Keep meetings at a minimum and if you do have meetings, come prepared
What does all that exactly mean? I’ll explain in some detail.
Understand the engineer’s role
Empathy 101. Think from their shoes. What is their role in the company? What are they currently assigned with? What sort of deadlines are they working towards? What product are they building? Understand the fundamentals of how the product is being built and their priorities at the moment. It’s crucial to account for these things so you know how they’re structured so you can put yourself in a better decision making place once you know the factors at play.
That way you don’t embarrass yourself by barging into their work and asking for a login button and two other action buttons that do XYZ in 2 days. While the ask may be easy but to actually implement and integrate with current systems, it might not be that simple. This way of working hurts the rapport between the engineer and the non-engineer.
In order to build this rapport, it also helps tremendously to learn how the engineer’s day is structured. When are they focused on only coding? What time do they take lunch? When do they take meetings? What sort of questions do they usually ask when asked to do something on product engineering? Essentially, what is their style of work? The best way to learn this? Simply ask when they don’t want to be bugged and respect that. Small things will go a long way.
Communicate clearly
Cliche, right? We’ve all seen this so many times! In probably every job responsibility there is out there. It is so underrated. The difference between a good leader and a great leader is that of communication. It makes a HUGE difference when you’re on a diverse team working cross-functionally.
What does communicate clearly really mean? It means you don’t just say the what, where, and when. You say the why as well. If the requirements or specs of a product change, you don’t only state the changes but you also state why we’re making the changes. That means you not only communicate clearly but you communicate factually. Come to the table prepared with some facts, observations, studies, or customer feedback that prompted this change in the product. This helps in building the critical component of earning an engineer’s trust and building rapport when it comes to working together.
When it comes to rapport and team dynamics, the tactical advice I’ve received is simple. Just ask. They can be upfront questions like, how can I work better with you? What can I do better to be more effective together?
Engineers have great product ideas, listen to them
PM’s & CEO’s aren’t the only ones that have ideas. In fact, from my experience, engineers have brilliant ideas. They’re a pragmatic species, they’ll present things that are deliverable not just finger pointing magic.
Think about it. They’re close to the product, they’re the ones actually making it. They understand the in’s and out of the product from a technical point-of-view. They might know some implementations that you never knew might be possible. If you’re lucky enough to have a vocal engineer, don’t take them for granted. For the ones who aren’t, ask them for their thoughts on the product. Are we, the non-engineers, overlooking anything? What suggestions do they have to improve if they were leading this?
Get their actual thoughts individually in a meeting. We’ll get to the meetings part in second.
Keep them updated on progress
If you’re working with engineers, it’s more likely that you’re a bridge for the team between the engineers and the customers. The role of the engineer is primarily to build. Once the feature of a product is built, they move onto the next. It can be a vicious cycle, I’ve seen it up close.
To build up that rapport and dynamic we spoke about earlier, it’s crucial you keep them updated on the progress of the product. If you just got off a big customer meeting, make a small write up and share it with them to communicate how the call went. Maybe the marketing plan was just launched, share the data on how the customers are responding to the new product that they directly helped built.
If it allows, maybe even get them in on a customer feedback call that you’re going to be doing. They’ll appreciate this way more than you think.
Keep meetings at a minimum and if you do have meetings, come prepared
You don’t need multiple tag ups on small things. Maybe a 10 minute check-in in the am to see if there are any roadblocks. See if there are any options to communicate before you schedule for a meeting. If it is non-essential and you can convey it with words, use email or slack. It’s more efficient to both parties.
If you do end up having meetings, please come prepared. That’s common sense but I guess we don’t have a whole lot of that these days. These meetings can be deadly. They can break the morale of your engineers and shift the momentum of your product in the negative direction. I am not exaggerating one bit. We have gone into meetings that would turn into 3 hour direction-less conversations and would walk out with 0 progress.
The solution for that? If you call for a meeting, lead it. Do your homework. Have updates, an agenda and goals for the meeting ready to be shared once the meeting is in session. Keep them short. The ideal time I observed for most effective meetings was 30 minutes. You came in with a specific ask/reason and you left decisively with a direction.
I’ll get even more tactical. What does the homework entail? What is the goal for your meeting? What problem are you trying to solve? Why do you need an engineer in this meeting? There is difference in meetings and brainstorming sessions. Understand that. If you know the answers to the above questions, how do you see this meeting clearing the hurdle for you? Have you prepared solutions to show the engineer or are you relying entirely on the engineer to come up with solutions? The former helps build trust and rapport even if your solutions aren’t optimal. If you help make the engineer’s job easier and more collaborative, it will help the team dynamic.
Don’t forget at the end of the meeting, always summarize the meeting goals, solutions reached, and then lay out the next steps to be taken.
It’s been an absolute gem to work with these people so early into my career and for some of them to become my engineering and leadership mentors, it is truly nothing short of a blessing.
So how did I earn their trust? I read somewhere that “action is better than strategy”. As much as I threw out ideas at them, I tried backing it up with as much tangibles as I could provide. Whether that was learning how to code the basics, doing intense research on a subject we were focused on, asking them to teach me the terminal so I can take it off their plate, it was always about action. They recognized that. A lot of non-technicals like to think of themselves as visionaries and thought-leaders, which is a problem when working with pragmatic engineering species.
You see the best strategies come from action and execution, not just sitting in a room and brainstorming/pondering. This is not to undermine the importance of brainstorming, it has a rightful place in innovation and creativity but a good chunk of great discoveries come from action oriented behavior. As they say “actions speak loud than words”.
I hope this serves you well. I LOVE working with engineers! Working together we shall make a difference in our world. Ad Astra!
