Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Developing High Performing Teams: How To Transform a Software Developer Into a Product Engineer

Product Team
Collaboration
Cross-Functional Collaboration

30 May, 2020

Alessandro Pintaudi
Alessandro Pintaudi

Product Management Director at PayFit

Alessandro Pintaudi, Product Management Director at Payfit, comes up with an exciting proposal of transforming software developers into product engineers by establishing cross-functional context analysis and shared objectives.

Problem

One of the problems I frequently encountered is that the business side of the company makes in advance very detailed plans on how to structure product roadmap, which product to build, and how to build it. Volumes of analysis are made even before talking to clients, but the reality often unfolds quite differently than forecasted. After the initial discussion with clients and the first efforts to build a product, every so often you realize that you are unable to attain your plans as you come across real-world frictions that you couldn’t anticipate.

At the same time, the level of detail of a plan in many instances goes down to the level of a product team affecting the autonomy of the team itself. While everything is well structured, a little or no freedom is left to change things during the solution definition or execution. Commitments towards investors, customers, or internal stakeholders have already been made and engineers can only blindly follow the direction that was set in advance. Both the process and methodology that were set years ago to reduce uncertainty and tighten control resemble a supply chain with strict roles and strict production processes that undermine attempts to grab opportunities or calculate delays.

As a result, engineers are interested only in technical aspects of things, unconcerned about Why and refrained from being proactive and solving customer problems. Results are measured at a very high level, making it impossible to run product iterations based on usages and customer insights. Consequently, frictions are frequent between a PM and engineers over deadlines and commitment. Therefore, engineers are merely software developers uninvolved in the product side of things.

Actions taken

The first thing a PM (or a business analyst) should do is to explain the context -- the reasons behind the decision to do something in a certain way. This explanation could arrive from analyzing business context or market-specific target segment for example but should be presented as a problem that should be collaboratively solved. Clear objectives should be set at every level and should be defined cross-functionally (versus vertically) and rooted in a customer-first viewpoint. This will reveal Why that is behind of What is being done.

You should be concerned with the outcome, not outputs. How many features will be released in the next quarter is nearly not important as if the outcome is achieved and properly measured, whether on a macro or micro level. If we are able to translate every single Jira ticket into the outcome and establish how to measure that outcome, we will give the team a sense of purpose.

This approach will inevitably require cross-functional team meetings at any stage of the process. While there should always be someone responsible, everyone is the owner of the product at any stage. of the process. The ownership is co-shared by every single person involved and that is pushing engineers to take on product decisions, include challenging the existing product decisions. There are many benefits to this approach. Engineers will be able to attain the same objective by choosing a faster route, become more involved and thus advocate for their solution(s) and be proactive in front of stakeholders and the other team members co-owning the responsibility on the product (from identifying opportunities, finding the right solution, delivering it in the right way and measuring the outcome).

Lessons learned

  • People would be able to use resources more efficiently. If you transform your engineers into product engineers you won’t need to micromanage or micro-lead them -- no need for product owners to constantly check on the backlog and check if everything is prioritized. Instead, more time could be spent on specifying the problem and the metrics to measure the outcome.
  • PMs and EMs could finally focus on more value-added tasks, for example identifying the right product to build or the right problem to tackle instead of asking engineers to estimate every single task, log every single hour because they are afraid that they are spending time on off-target issues. If everyone is aligned and motivated the whole team is moving forward without the necessity of being pushed.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Preparing Your Team for the Remote Workplace

29 November

Vadim Antonov, Engineering Manager at Meta, dictates how he brought a brand new team into the remote learning process by ramping up onboarding and creating a mentor system.

Alignment
Remote
Internal Communication
Coaching / Training / Mentorship
Data Team
Cross-Functional Collaboration
Vadim Antonov

Vadim Antonov

Engineering Manager at Facebook

Delegate successfully as a first time manager of Product Managers

24 November

Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.

Scaling Team
Building A Team
Delegate
Coaching / Training / Mentorship
Psychological Safety
Cross-Functional Collaboration
New Manager
Andrew Tsui

Andrew Tsui

Director of Product at Startup

Specialization vs. Wearing Many Hats

23 November

William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.

Internal Communication
Collaboration
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Deadlines
Stakeholders
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

How to Pivot a Product Idea at the Right Time

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he diligently managed a product in one of the biggest eCommerce companies by being an individual contributor.

Innovation / Experiment
Product Team
Product
Embracing Failures
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.