Balancing Engineering vs Business
There is always a tussle for control between engineering, business, and product. Founders need to understand how to bridge the gap between these three.
Hello there. This is a monthly newsletter from Together. Our aim is to help entrepreneurs and founders realise their potential.
What can we promise you from this newsletter?
It will be fun and smart.
It will not take too much of your time. We know you have a lot to do.
If this is the first time you’re reading our newsletter, we suggest you run through our back catalogue. There are some interesting guests there.
Build the bridge
It’s a source of friction and frustration in fast-moving companies across the world. Engineering and business have their own ambitions and their own road map. Often these two cross paths and then diverge, like rail tracks. And just like those tracks, the two always run parallel to each other. Their ultimate goal remains to create a product for customer satisfaction. The path to that can be fraught with challenges and if founders can learn to navigate and avoid these roadblocks, they will achieve PMF faster.
In the last issue, we spoke about the mistakes founders make. And one of our readers wrote in and asked, what about the friction between engineers and business? It gave us food for thought. The reader explained that founders often let tech leads and business heads run these functions and don’t understand that setting a culture is important, so both teams don’t end up working in silos. Working in silos causes delays, and these delays can get expensive.
You can define expensive in different ways. Expensive because you may end up spending more than you want, you may lose a customer because a feature isn’t built on time, or you may end up losing talent. These are important daily battles that founders have to win. We often look at founder’s battles with competition or against market forces, but forget that company building also needs the ability to bring out the best in their team.
We’ve dedicated this issue to helping founders lay the groundwork, so they can minimise the friction between engineers and business leaders. We won’t say it is important because the gloom of a slowdown is around the corner. Because at Together we believe there will always be capital for enthusiastic founders with an eye for detail.
So, we spoke to two operators who have worked at the crossroads of engineering, product, and business. Parimal Bajpai, VP of engineering, InMobi and Irfan Shah, CTO, Setu. The duo has a combined 30 years of experience running large teams and we asked them a few questions.
“If you listen to every customer of yours, your product is probably going to look like Frankenstein’s monster,” says Irfan.
Listening to the customer
The end-user of your product is the customer, and you build your product to help solve the customer’s biggest problems. That’s the foundational step. “But founders need to think a little deeper,” Parimal says.
Business teams focus on customer satisfaction and engineers focus on product stability. The catch is to bring the two together.
“It is a question for the product, engineer, and business. Product and business come up with a vision,” he says. But business and product managers need to understand the engineer’s primary goal.
An engineer has to break this large vision into milestones. “Engineers are creative people. They find creative ways in which a minor tweak can reduce the cost of implementation,” says Parimal. “The engineer has to tell the business what is useful to the customer, requires a low effort for quick turnaround, and puts time and resources to good use,” he adds.
But a lot depends on the stage you’re at as a company. The change-to-implementation cycle becomes shorter once PMF is achieved, and shipping a product or feature change is a shorter process, says Irfan.
Sometimes, a customer requirement may not seem like the best idea on the first go. Irfan suggests moving such feature requests to the bottom of the backlog and revisiting them regularly.
But product managers and tech leads need to know when to draw a line under customer demands.
“If you listen to every customer of yours, your product is probably going to look like Frankenstein’s monster. The product is simply trying to fit into a customer's specific use case,” Irfan adds.
Listening to the engineer
The key to making this happen is having business and designers have an open communication channel with the engineering teams. Part of building the culture of listening is also trusting what engineering has to say about a proposed change.
“We need to focus on a tech lead,” says Irfan. Just as a product manager brings in what direction the product is going in, a tech lead can say, what you're asking makes sense, but it will derail a lot of things.
Sometimes the context switch can cost more than just restarting the feature.
The right way to look at this, Parimal believes, is to divide the product into two parts: revenue makers and growth.
'Revenue makers' need to progress with care. Typically, PMF exists with a dependable revenue stream.
Improvements need to be weighed.
A/B testing framework needs to be inducted.
Product development and UX need to be frozen before engineering picks up any change.
Engineering solutions and estimating need to happen before development work starts.
Adequate monitoring and alerting need to be added to prevent outages.
“Hiring engineers is hard enough, but if you look for these unique qualities, you’ll never be able to make a hire,” says Parimal.
Engineering a unicorn
The perfect engineer, Parimal and Irfan agree, is one who is equally interested in business and tech.
“Hiring engineers is hard enough, but if you look for these unique qualities, you’ll never be able to make a hire,” says Parimal. These engineers who can add both qualities to their skill set are true unicorns, says Parimal.
But this doesn’t mean one can’t be developed.
One thing that companies often do not invest enough in, but should, is the way they onboard engineers. It is equally important to onboard people who are not only aligned to the technical backend, or the language you build in, but also to the company’s core values.
Irfan says it all starts small. Encourage the engineer to sit in and try to solve customer complaints. They can spend some time manning the email and chat complaints.
“It plays a dual role. They identify systematic issues and can solve them before things bubble over and they understand how a customer feels,” says Irfan.
The next step is to give engineers access to customer meeting transcripts and call recordings.
“This is helpful because engineers get context. There is nothing lost in translation between the product manager and the customer,” he says.
Once the engineer is used to this kind of interaction, Irfan suggests introducing them to the customers with the product manager present.
Here the engineer has contact with the customer but through the product manager.
Once the engineer has gained enough knowledge and confidence from these interactions, it’s time to let them have one-on-one with the customer.
“There are always those who don’t enjoy speaking to customers. It’s wise to move these engineers to the platform team,” he says.
Save time
The best way to make things easier between business and engineering is to save time. All businesses come to a point when they have to decide between build and buy.
When you’re building a startup, time is your biggest currency, and using tools and solutions already available to organise and collaborate better is a no-brainer, says Irfan.
“Simply use an open-source or cloud-based service instead of building it because your superpower is your developer's time and you should use it wisely. So I would always advise to use these open-source tools, or a SaaS solution, and save time,” he says.
These aren’t forever decisions, he adds, and depending on the building stage you’re at, it is a good idea to revisit your choices.
“The choice can change over time. What I mean is that just to build fast you might use a SaaS solution, but a SaaS solution might be very costly. It may compress your margins. But for seed stage, Series-A startups, these tools are the way to go,” Irfan says.
Different tools work for different stages of planning and work.
Jira is good at managing the engineering part.
Roadmunk for roadmap planning.
Figma for UX.
However, “once you have frozen what your next two releases are. Jira is the worst tool for strategy and conversation,” Parimal says.
What Together has been up to
A few things we’d like to share with you.
Welcome SpendFlo: SpendFlo joined our growing network of companies. CFOs are going to have larger roles to play in organisations moving forward. Software that can enable them to make faster and smarter decisions will become one of the first spends companies make. And that’s what prompted us to invest in the company.
Build Together: We announced a 10-week bootcamp, which will help Web3 founders build in the tutelage of some of the smartest people in the business. Our colleague Subhendu will lead that part.
A little social media popcorn 🍿
This thread on scaling is very interesting.
This on getting to the first 1,000 paid customers was insightful.
That’s it from us for the month. If you believe you’ve got an idea that we need to hear, write to us here at hello@together.fund.
We’ve got an exciting guest lined up for next time. Until then, stay safe, and let’s build Together.