By Ramya Nirmal, CEO, CI Global Tech
A few years ago, one of our product teams came to me asking for more developers. We were building a product that needed more multi-lingual support and the list of languages kept getting longer. More languages meant more translation work and more translation work, it seemed meant more people.
I have heard some version of this request many times in 25 years of building products. Usually the team is not short of hands. What’s missing is someone who owns the decision about what to build.
What Happened When We Asked “Which Languages and Why”?
Before approving any new hires, we went back to the list and asked why each language was on it. The answers varied a lot. Some languages had real demand from users. Others were needed to meet compliance rules in particular markets. And a few had simply been added at some point and never questioned.
Once we looked at each one in terms of who would use it and whether the market required it, the order became obvious. We knew what to build first, and we could park the rest without much debate.
We also found that much of the translation work was repetitive. Our engineers wrote a custom algorithm to automate a large part of it, which left them free to handle the pieces that needed a person’s judgment.
We shipped the languages that mattered without adding the developers we had originally been asked for.
Why More Developers Rarely Fix a Crowded Roadmap?
Every product roadmap has more ideas than we could ever build. Requests come in from customers, sales, support and leadership, and each one sounds reasonable when you hear it on its own.
If nobody owns the call, the team ends up building a little of everything. Effort spreads thin, and small features compete for time with the things customers are waiting for. Adding developers here makes the team busier, but it doesn’t make the choices any better.
For me, ownership means one person is accountable for what gets built and what doesn’t. They weigh each request against what customers need, what compliance requires and where the product is headed, and they explain their reasoning so the team isn’t left guessing.
Where AI Fits in Product Development?
We practice Human + AI delivery at CI Global Technologies. AI did not choose which languages to support. That was decided by people who knew the customers and the markets. Once the direction was set, AI took on the repetitive translation work and the team moved faster.
I think the order is important. AI is very good at scaling work once you know what the work is. It has no way of telling you whether the work was worth doing.
What I Ask Before Adding Capacity?
These days, when a team asks me for more people, I ask a few questions first. Who owns this decision? Which of these requests do customers actually care about? What could we automate? What are we deciding not to build?
Sometimes the answer is still that we need more developers and then we hire. But more often than I expected, a smaller team with a clear owner and a short list gets further than a bigger team trying to do it all.
Building Products with Purpose
Adding developers is sometimes the right call and when the need is clear, I’m happy to make it. But more capacity can’t tell a team what deserves attention, what customers will value, or what to leave out. Those are ownership decisions.
When someone owns them, the team stops chasing every request and puts its effort into the work that makes a difference. In my experience, that is what keeps a product focused as it grows.
