How to structure your engineering-product org for faster delivery
Building software is easy. At least it used to be. All you needed was a small team of full-stack engineers with an idea, a good understanding of your ideal users, and of course, the ability to write code. Everyone did everything — participating in DevOps, writing code, being well-versed in security practices, and bringing new feature ideas for the product roadmap. Ah, the good ol’ days, I tell you.
Illustration: Karthikeyan Ganesh
But things are different now. Technology has become advanced, and products have become complex with broader sets of features. A small team of full-stack engineers isn’t enough. You now needed bigger teams and specialization in various engineering and product disciplines. A traditional engineering-product org structure won’t cut it.
A traditional engineering-product org structure is passé
When you’re just a small team with a handful of engineers building a single product, working together is easy. Everyone understands the bigger goal and can unite behind it. You can probably physically see everyone. You only have to look over your monitor to talk to people to know what they are working on. Everything works like a charm.
With more people building a product, a traditional engineering org looks something like this: you’d have smaller teams for each feature or project. Each product would have multiple product managers and engineers, reporting to one or more managers depending on whether you follow a hierarchical or pod structure.
The hidden problem in an engineering-product org structure
A good team understands that it should do things for the benefit of the team, yes? But there’s a problem — when teams work toward their respective goal, it’s easy to forget the bigger picture.
Teams begin to interact on a more transactional basis. Product managers, engineering managers, and technical architects alike may become entangled in their daily tasks. They have less visibility into what the other teams are doing. Their focus may shift to achieving their individual team goals. The entire group begins to feel like a less coherent team with a shared mission.
Trust me; it happens to the best of teams.
The product manager is seeking new ideas to solve your customers’ needs. The engineering manager is focused on managing their respective team, while the technical architect is entirely focused on technology. Each of them has a distinct goal for their team. That’s great, but there is a lack of visibility into what the other is doing. It muddles the direction in which they lead their respective teams towards the company’s overall goal.
Let’s say you’re going to war. You recruit the best of chariots, infantry, admirals, and elephantry. Each arm is set to fight its best with minimum casualty within its arm. That’s great. But if each of the arms don’t speak to each other or if they don’t have visibility into when each arm is going in for the strike or when to withdraw, you would have set chaos upon the battlefield.
Without a general or a commander to orchestrate the fight, you’ll be fighting a losing battle.
Where is your commander?
Now, like most companies, you probably have your company’s mission statement on your website for all to see, posters of the company’s goal decorating your office space. But that does little.
Without a commander to orchestrate team collaboration, understand pain points, enable visibility, and steer the engineering-product org in the direction of your company’s vision, you’d be setting your org up for failure.
Having built and scaled engineering-product orgs in the past, we knew this problem needed solving right from the start.
So we set out to find someone who can develop a culture of high collaboration, a willingness to iterate and make adjustments, and a growth mindset. They should balance trade-offs to maximize effectiveness, keep a close track of goals and metrics, never taking their eyes off the bigger picture. They should enable agility in our teams, empowering our leaders and teams. Did I mention they needed to have technical experience too?
What we needed was a Product Navigator. I know it’s a first.
I also know what you’re thinking — that’s one hell of a job description; where would you find someone who fits the bill?
Oh, we did find our Product Navigator.
Say hello to our Product Navigator.
Meet Radha Krishnamurthy, one of the prominent women engineering leaders at Zoho. She led the product conception and development of Zoho Mail on a team of more than 100 people to build one of the largest email providers that, today, competes with the likes of Gmail and Outlook.
With 15 years of experience in her belt, she’s is an adept software engineer, well-versed with the complete spectrum of product development. In the earlier days of her career, before joining Zoho, she was one of the first women engineers at Gemini Communications, where she worked on building a paperless office. This project became a blueprint for how the company would go on to build a digital business, automating most of its internal processes.
I couldn’t be more excited to join SuperOps.ai as they prepare to launch a mission-critical product. It’s exciting to be part of such a vibrant team. I will be working closely with the respective stakeholders, ensuring tight collaboration between them, and steering them towards achieving the company's goal. I look forward to working with the team to accelerate innovation and growth.
Product Navigator at SuperOps.ai
Radha has the technical expertise and insight to refine and enhance our product journey and help dramatically accelerate SuperOps.ai’s product growth. We’re thrilled to welcome her into our team.
We’re introducing a new role within the engineering-product org: a new playbook to build an engineering-product org. We’ll be sure to tell you how that worked out for us.
That said, not all teams work the same way or have the same needs. And no pre-existing playbook you copy will fix all the problems. You need to know your team and the problem they are facing before you create your own playbook.
Ticketing system and PSAs for new/small MSPs
Every new business has some growing pains as they are starting up. There is a certain learning curve they must face, and sometimes we learn through hard experience. A good example of this for MSPs is where to move to a PSA and get those tickets out of your inbox.