Communicate with engineering teams effectively
As a software engineer who worked in companies of various sizes, I learned many valuable lessons in how different teams communicate with engineering teams effectively and each other. Especially when it comes to product owners and managers that need to engage with engineering teams to implement new features and enhancements effectively.
Who am I?
Hi, I’m Sunny Singh, a software engineer with a wide array of experience in building products. I started out working on my own side projects like IronMic, but I also worked at a few startups with small teams of about 6 people. Recently, I spent 2.5 years in the corporate world at Bank of America.
Taking lead
Building products on your own teaches you about all the different aspects needed to ship software. Working in a large multi-team environment teaches you how to work efficiently with others and focus more on soft skills like communication.
This was my biggest takeaway from my career so far. At Bank of America, I took various initiatives to work with different teams across the organization to help make our processes more efficient. This means that while I could have stayed purely within my development role and have minimum communication across teams, I decided to instead gather people across teams together to help solve any internal pain points or product issues. Some of these improvements were to our deployment flows, software testing automation, and dependency management.
Team perspectives
When you speak with an engineer or engineering team, you will quickly start to realize that the focus may not align directly with the product. You will hear terms like technical debt, building to scale, dependencies, frameworks, and other jargon that might sound confusing.
There are ways of improving these types of conversations, but the first step is to realize where the other perspective is coming from. When you’re close to the underlying code of the software, you worry about its maintainability in the future. When you’re far away, you worry more about how people use your product.
Communicate with engineering teams effectively
Here is the list of things that I do when speaking with other teams.
1. Avoid jargon
It’s tempting. We believe that we sound smart using acronyms and terminology that a subset of people know. However, it does not end up helping you or providing others value when they don’t know what you are saying.
2. Ask questions
When you notice that someone is using jargon or is not explaining a concept in simple terms, don’t be afraid to ask questions. Engineers are used to saying technical terms so often that it’s hard to break the habit. There is also a chance that when speaking amongst a group, there is at least one person wanting to speak up about being confused, but is too afraid to do so. It takes just one person to ask a question for many others to gain confidence in asking theirs.
3. Show empathy
Or at least, seem like you care about the problems that engineering may have. It’s not required to have a full understanding of what an engineering team is doing at all times, but a common frustration among product and engineering teams is on how time is spent.
From a product perspective, time should be spent on shipping products and features out the door as quickly as possible. That makes sense because this is what makes money. However, from an engineering perspective, there are many problems waiting to happen. Features become slower to ship, user issues start piling in, and the worst is when a security exploit is found.
These are important issues that need to be evaluated and spent time appropriately. If you trust your engineering team, then let them know and ask how the product may help coordinate.
Engineering is dynamic
Another important realization is that engineering is dynamic. The scope of two features or defects in software may look the same, but one may take longer to fix than the other. The same goes for any aspect of building products: you can never accurately estimate the level of complexity and effort.
Knowing that you can use agile product management to your advantage:
- Bugs don’t have to be pointed.
- Bugs or spike (research) stories can be “time-boxed” to limit how much time should be spent.
- Create spike stories to perform research, architecture planning, and code refactors.
By allowing flexibility in how projects are managed and time is spent, you set both product and engineering teams up for success.
But, we’re not that different
At the end of the day, we’re all just people building products. As an engineer, I believe that I write code to provide value to others, and that value is the end product that people use.
I hope that you can take away at least one lesson from this article to use in your day to day team communication. If you do, you might enjoy some of the content that I publish on my Website and my podcast. Of course, also feel free to reach out to me on Twitter or LinkedIn.
Thank you for sharing your expertise with The Product Angle community. 🙏