All Developers Should Build These Four Non-Technical Qualities
A former product manager’s pov on effective cross-team collaboration.
“I attend a ton of product planning meetings” — a statement you may hear from many senior developers nowadays.
The stereotype that Developers sit at a desk and code all day is farther from the truth than ever before. The position is no longer a siloed role, especially as one gains experience and takes on additional responsibilities.
The role of a developer requires a ton of cross-team collaboration — even more so when working for a startup. Most of these interactions are with Designers or Product Managers.
For a Developer to collaborate effectively, they should understand the characteristics that are valued by other cross-functional teams.
There are several articles from a Developer’s point of view on what qualities/skills a Designer or a PM should possess to collaborate effectively with them. However, as a former PM, I hope to share my insight from the other side.
Apart from the technical abilities, there are 4 non-technical aspects of a successful Developer that makes cross-functional collaboration both enjoyable and efficient.
1. They Adapt Their Development Approach to Match the Business Needs.
2: They Work on Interesting Problems and Not Interesting Technologies.
3: They Can Identify Unarticulated Customer Needs.
4: They Invest Time in Learning Why Before They Share How.
#1. They Adapt Their Development Approach to Match the Business Needs.
In an ideal world, the same execution plan could be applied to every problem all the time. However, in reality, we all know that is never the case. The development approach we select depends on several dynamic factors such as project scope, delivery timeline, feature priority, competitive threats, market trends, etc.
The best collaborative Developers are flexible in their development approach. Instead of exploring reasons to push back or eliminate these factors, they adapt their execution plan to meet business needs with appropriate technical trade-offs.
They understand a short-term sub-optimal solution that is adopted by customers early is better than a well-architected solution that is released late and receives no customer adoption. Improving a product in subsequent iterations is significantly easier than making a customer switch from a competitor product.
This adaptable quality is appreciated by cross-functional roles, as in the world of agile development, these fast-paced and unpredictable scenarios happen all the time.
#2: They Work on Interesting Problems and Not Interesting Technologies.
I have worked with so many engineering teams where a Developer has requested that I budget time in the next quarter so they can explore an “interesting” technology.
When asked why, their reasoning was often something along the lines that this technology can help improve our product or some key metrics, or that other companies are also shifting to this new tech stack.
Sometimes investing in an exploration step is the right move. But, in most cases, a technology-led approach is not an impactful pitch if a developer wants to get others on board with their idea as well.
Developers who have the best pitch always use a differentiated product feature or a remarkable improvement to existing customer experience as the primary driver — the new technology is only used as a release vehicle to offer that unique value.
I love collaborating with such developers. They are always excited to build outstanding products that have a broad customer impact rather than upgrading the stack to the latest technology.
#3: They Can Identify Unarticulated Customer Needs.
A successful product has a ton of fans rather than a ton of features. To build fans, a team has to release unforeseen product value that delights existing customers.
In my experience, even when the PM is looking for such opportunities, the best Developers will also look at the telemetry or usage logs to come up with additional insights. With time they tend to build a holistic understanding of the product too, which allows them to identify unarticulated customer needs.
A product builds a cult fan base by delivering such unexpected features over multiple releases. A team with members who are all interested in identifying such opportunities has a massive chance of developing a product with high adoption and phenomenal retention metrics.
#4: They Invest Time in Learning Why Before They Share How.
I have seen a lot of times engineers don’t challenge why and what from a PM. Their focus is only on building an execution plan for the project. When it comes to cross-team collaboration, the developers with such a mindset are not considered best partners.
The most collaborative engineers feel comfortable learning the why and what of a project. They spend time raising appropriate clarifying questions and suggesting improvements to the potential solution. Only after they fully fathom the reasoning for the feature, they build a technical strategy.
A PM greatly appreciates such developers because it ensures the project hypothesis is thoroughly validated before we start the execution stage. Moreover, it brings everyone on the same page from the start and hence makes the execution journey a lot easier.
In the case of Developers, above non-technical qualities are not only beneficial for becoming better collaborators, but these soft skills also aid in accelerating one’s career trajectory.
In my early years as a PM in Microsoft, I got to work with a team of four engineers where every developer had most of these characteristics. It is still one of the most rewarding times of my career — not only did we deliver a successful product, but I also got four friends for life.
As they say, it takes a village to build a successful product, and to have a healthy operational one, a clear understanding of each other’s expectations is vital.
I have seen many experienced Engineers who possess these exceptional qualities also explore the possibility of transitioning to a Product Manager role. Many have not only successfully made this transition but have also excelled in their new PM role as well. If you are also interested in such a move, please read one of my earlier articles:
