I cannot work with my CPO

Julia is the CTO of Newtery, a two-year-old Fintech startup building a SaaS platform for Fortune 500 enterprises. Julia has six developers in her team, all working remotely and asynchronously, using a Slack channel for affecting development tasks bit by bit.

Six months ago, Newtery founders decided to hire Rohit, the CTO of one of their current customers and named him Chief Product Officer. Rohit is, on paper, a great addition to the team. He knows what potential customers want, has experience leading teams, and reassures prospective customers. But since Rohit joined, his relationship with Julia has been catastrophic.

For Julia (the CTO), Rohit is too focused on processes that are slowing down the company. For example, Rohit has asked developers to use Jira to log Epics and Stories, organises daily stand-ups with product managers and developers, and promotes manual testing over automated tests. For Rohit (the CPO), Julia and her developers are immature and don’t realise that they’re building a carrier-grade platform for Fortune 500 enterprises. The other day, a developer did a hot-fix on the production platform without telling anyone.

What should Julia do?

Sometimes, well-intended and engaged leaders can pull in very different directions, creating a company-wide battle. This situation is happening at Newtery because both Julia and Rohit focus on the HOW instead of the WHY.

In Start With Why, leadership expert Simon Sinek popularised the Golden Circle model, which helps organisations focus on their WHY, before the WHAT and the HOW. According to Sinek, an organisation’s WHY is its purpose, its belief, the reason why team members wake up in the morning and go to work. The WHY goes way beyond making money or “winning”, which is the WHAT, the result. Lastly, the HOW represents team members’ actions and processes to get to the WHAT.

In the case of a startup’s product and engineering teams, their WHY is to delight end users. In the finance industry, end-users usually deal with outdated and complex software. So any simple and elegant solution that solves their problem is already a significant improvement. Also, delighted users keep using the product (retention), they talk about their experience (referral), and marketing can leverage them for promotion (acquisition). It’s important to stress that both product and engineering teams have the same WHY. Misalignment starts when teams have different WHYs, like producing roadmaps and specifications for the product team or shipping quality features for the engineering team.

Now that we’ve established that both teams have the same WHY let’s move to the WHAT. If the WHY is to delight end users, the WHAT is a collection of features that work well, are simple and solve a problem for end-users. The previous sentence could mean different things depending on the market you’re targeting. For example, suppose end-users already have alternative solutions. In that case, the company should focus on catching up with competitors, shipping features as fast as possible with an acceptable quality of service. If the company’s solution is at the same level as its competitors, the product and engineering teams should focus on value-added features that set them apart. So the WHAT would highly depend on the environment, but again, it’s the same for both teams.

For the sake of argument, let’s assume that Newtery is playing catch up with competing products but with a better UX. In this case, the product team’s HOW is about making very accurate feature specifications and having a fast feedback loop to ensure that new features are a fit. The engineering team’s HOW is to build the required features as fast as possible with an acceptable quality of service. When selling to enterprise customers, the Change Failure Rate should be as low as possible. Still, you shouldn’t underestimate users’ tolerance for bugs if the overall product is much better than their previous alternative and if bugs are corrected quickly. So speed is critical here.

Now, if Julia’s team can ship features and solve bugs quickly without going through the classical agile rituals, then Rohit shouldn’t be bothered. Julia should at least share a structured plan with other C-levels, so they know her team’s pace and estimated timeframe to ship the roadmap. On the other hand, Rohit should accept that there are many ways to reach the same result and let Julia prove that her team can deliver.

Are you ready to scale your engineering team and grow as a leader?

Membership includes weekly live learning sessions, online resources, exclusive events and a community of 100+ engineering leaders

APPLY FOR MEMBERSHIP