Engineering the future: leadership & platforms

Rajeev has spent two and a half decades at the bottom of the stack. His case is that the platform layer decides how fast everything above it can move — and that accountability can never be demanded, only grown.

Watch the full episode on YouTube

Executive summary

Rajeev is head of platform engineering at Freshworks, where he leads the Neo platform that powers the company's product portfolio. Two and a half decades in, across enterprise B2B and B2C systems and data engineering, he has an unusually clear view of a layer most people only notice when it fails.

His argument has two halves that turn out to be the same argument.

On the technical side: the platform is a promise, and the promise has to be made before the business logic is written. Scale, performance, reliability, resiliency — decided first, because everything above inherits whatever you settle for. "You're at the bottom of the stack for a multi-product company. You're going to have all the traffic come down to one place." The reward for getting it right is not stability; it is speed. Application teams stop thinking about the hard guarantees and start thinking about customers, and new offerings ship on groundwork already paid for.

On the human side: ownership is an input, not an output. The industry talks constantly about building accountability in teams. He inverts it — accountability is what you get when you have already given people responsibility, then authority, then genuine ownership, in that order. It cannot be requested. It certainly cannot be demanded after a failure.

Connecting the two is a single leadership move he returns to repeatedly: answer the why behind the what, before the what. That one habit, he argues, is what converts an assignment into a mission — and it is the same instinct that makes a platform team document its APIs for the internal developers nobody thinks of as customers.

The sharpest operational insight in the episode is about where platform teams systematically under-invest. Everyone funds detection. Almost nobody rehearses recovery.

The story

Start with what a platform actually buys you, because "scale and reliability" undersells it.

"Platform always creates the promise of performance, scale and reliability. As you accumulate data at one level, and as you accumulate the power of various services at the similar level, it gives you many more possibilities — it prepares your product ecosystem to bring in new offerings at a very fast pace, and to have very quick go-to-market delivery schedules."

Get the guarantees right at one layer and every layer above it gets faster — and cheaper.

Then the compounding effect, which is the part that matters in an AI-shaped market:

"Platform also generates a very tangential value, which comes through the power of the data that you accumulated and the services you built on top of it, which can provide contextualisation to the data. If you look at the modern ecosystem based on AI, they're all based on data — and contextual data is the need of the hour."

That is the strategic case. The engineering case is an ordering constraint, and he states it as a rule:

"A platform developer should always think about scale, performance, reliability, resiliency — these factors first, before doing the business logic."

The reason is structural rather than aesthetic. A platform sits under everything, so its failure modes are everyone's failure modes. He has a line about defensive coding that lands the point better than any architecture diagram:

"There is something you should always take care of, because platform can bring the whole business down."

And the payoff for that paranoia is felt by people who never see it:

"If you're taking the problem of scale, of performance, of reliability, of resiliency — and the common services like authentication, authorisation — away from a developer who is developing a front end to engage the customer, they can focus on developing really engaging applications rather than worrying about all of that. And that is the largest impact."

His summary of what the layer owes the organisation is worth keeping: the platform should always be ahead of time — not only in timing, but in robustness. It is built for the traffic you do not have yet, because by the time you have it, it is too late to go back and add it.

Key decisions

Decision 1 — Answer the why before the what

The first of his three leadership pillars, and the one he keeps returning to across completely different topics — distributed teams, first-time managers, cross-geography alignment.

"Always answer the why behind the what. Instead of telling people what to do, first tell them why we are doing that — where the organisation or the customers or the competition is leading to, where are we going with it, and what is the reason we're building what we're building."

The claim is that this single move changes the category of the work:

"That moves the needle from assignment to ownership."

Note that it is proactive by design. The point is not to be able to answer why when challenged; it is to volunteer it before anyone has to ask, "rather than letting people assume."

Decision 2 — Give ownership first, and let accountability follow

This is the inversion, and it is worth reading slowly because it runs against how most organisations talk:

"Generally we talk about building accountability in the team. But I always say this — accountability never comes out of failure. Accountability is a progressive function of giving people ownership, giving people responsibility, giving people authority. Once you do this, exactly in that order, you get accountability."

The failure mode this diagnoses is common and quiet: a team is told it is accountable for an outcome it was never given the authority to shape. What follows is not ownership but defensiveness — and then the leader concludes the team lacks accountability, and tightens control, which removes what little authority remained.

Decision 3 — Be the one who releases pressure, not the one who adds it

The third pillar, and the one most likely to be neglected by capable leaders under pressure themselves:

"Modern business changes very fast, and that creates a lot of pressure within the system. As leaders we should be the one who go in and release the pressure from the system, rather than building on top of it."

Concretely, that means resisting the instinct to press harder when timelines look uncertain:

"Rather than going in and actively pressing where the teams are going, or doubting whether they'll be able to deliver — build up trust. A leader should always trust that my teams are doing the right thing. We should have all the probes to track that, but you should not be tracking actively — track passively. Use the tools to do that."

And when the team misses: "You should trust that they're putting in the best effort they can, and provide them that backup, that air cover — which will build even better trust."

He ties calm and trust together explicitly: "Calmness and trust always go hand in hand."

Decision 4 — Keep processes thin and structures strong

His warning to first-time managers is specific enough to be actionable:

"Processes create friction. Structures build cohesive teams."

"I've seen many times with first-line managers that they start to over-index on the processes. We forget the fact that processes are there to serve the structure, never the vice versa. The fun is not about creating processes — it's about keeping the processes as thin as possible, using them to create a very cohesive structure."

This connects directly to his definition of transparency, which is narrower than the industry's:

"For some leaders transparency is important so that they can do very active tracking of where the teams are. In my opinion, transparency should be that very thin layer of processes which gives the teams a visibility into where they are going."

The goal is an intrinsic feedback mechanism inside the team — one that does not need to be enforced from the top. Transparency as a mirror for the team, not a window for the manager.

Decision 5 — Treat internal developers as real customers

A small decision with outsized consequences, and an honest admission about how platform teams behave:

"One of the things platform teams generally neglect a little bit is that your consumers are mostly internal developers in the organisation, so they don't get the exact same level of care as you might for an application. Which is something we should not do."

The fix is unglamorous: clean, well-defined API contracts; scaffolding and tooling so the contracts can actually be adopted; examples; documentation; API tooling so developers can try and test things.

"That gives developers more confidence to use it fast, and gives them the speed of development on top of it."

A platform nobody can figure out how to use is, from the business's point of view, a platform that does not exist.

Mental models

Speed is the accelerator; scalability is what you live on

"Speed is how you will go and challenge the market space. Scalability is how you're going to live through the growth of that product, live through the challenge in the market over a period of time."

They are not opposites to be traded once. They are two dials to be balanced continuously, with three rules:

1. Build small, fail fast, learn fast. Start with proofs of concept. Do not let scale block the first step — but factor scalability in from the beginning.
2. Modularity. Loosely coupled modules, open interfaces, and — critically — "where the API boundaries are crossed, your contract should be very clearly defined." That is what keeps the velocity of everything built on top of it high later.
3. Time-box the trade-offs. Speed creates debt; the question is whether the debt has an expiry date.

Tech debt is a product feature

The third rule deserves separating out, because it is a reframe rather than a reminder:

"Trade-offs generally get written off as tech debt. But tech debt should always be attended to as part of the product feature — because with product growth it is an essential part of the product that engineering and product management should collaborate upon. The business is going to fall off as soon as you hit that limit."

Debt filed under "engineering hygiene" competes with customer features and loses, every quarter, until the limit arrives on a day nobody chose. Debt filed as a product feature is scheduled by people who own the roadmap.

Which raises the obvious question — how do you know where the limit is?

"Generally platform teams miss out on having a performance, scale and reliability test suite. That is important, so that you know in your current form of architecture what your limits are. As soon as those limits are reached, you should be able to re-architect — and you should earn yourself time to do that."

Earn yourself time is the whole idea. You cannot re-architect under a customer-facing outage.

Detection is funded. Recovery is not.

The sharpest operational observation in the episode.

"There is generally a lot of focus on mean time to detect. If you can get early indicators of when the issue is creeping into your system, it gives you the advantage of time so you can recover faster."

Detection is well served — dashboards, alerts, probes, and flags on release modules, feature modules and configurations so you can turn things on and off and "get out of the bleeding to the customer."

But then:

"If you have to go beyond that and do some recovery, we generally do not formally anticipate proactively and create tooling around it — and that impacts our MTTR. That is what an incident can take away: a lot of our customers."

Detection tells you the house is on fire. Recovery is whether anyone has practised getting out. Only one of the two is a number your customers actually experience — and it is the one nobody puts on a slide.

AI is a function of data, and platform is where data lives

His guidance on building with AI starts by refusing the usual starting point:

"Always look at how it solves the complexity for my customers as they interact with my product, rather than starting to build models."

Then the structural reason platforms matter here:

"AI is basically a function of data. You will enrich your experiences, your accuracy, your outcomes more and more as you bring in more data and you contextualise that data. Platform is one place where you accumulate all that data — and you not only accumulate it, you contextualise it."

And a design principle carried straight over from platform thinking:

"Whenever we are developing AI applications, we should always look at developing generic modules — you have to draw analogy with how you used to develop generic modules with open interfaces and clearly defined endpoints. The same applies here: generic modules which can be suited together for multiple use cases, rather than developing one big monolithic model which can serve only one use case."

The knowledge wheel is moving from the user to the system

The clearest articulation of what agentic actually changes:

"What we used to call workflows — it was a clicking experience at every point of time, and there was a lot of user input and user intelligence required. There was a knowledge wheel that we created between the application and the user, and in many cases it was bending towards the user. Now it is bending towards the system, and the system has that intelligence, so it can reduce your workload."

The example the episode settles on is travel booking. The old model was a workflow: you clicked through search, compare, select, pay. The new model is assisted: the agent finds the flights and comes back for a judgement — "it can ask me for a choice between the flights that it found," and you can direct it on airline preference or booking platform.

The repetitive clicking is gone. The judgement stays with you.

From pull to push

"Analytics would present you with reports and dashboards. You can see what happened, you can interpret those — and then it is left to interpretation to figure out why it happened. That works well when the data is small and you can work through it manually. But in the modern world the decisions are happening very fast, and the amount of data you've got is huge."

Three shifts are happening at once, and he names each:

• What → why. From static reports of what happened to systems that surface why it happened and what can be done about it.
• Descriptive → prescriptive. Not "here is a report on your sales numbers for the past three months" but "your sales numbers moved fifteen percent because of these reasons."
• Analyst-mediated → self-service. "I should be able to self-service rather than rely on some analyst who I'll ask questions of and get an answer some time later."

Add personalisation — "the system knows me, knows my business, knows my competition" — and the output becomes forecasting rather than reporting.

The line he is careful to draw is the one about who decides:

"We move the intelligence to the system and the decision-making to the users. We are using the system to provide all the information in a more proactive fashion, and leaving the decision-making to me."

Or as he puts it more plainly when the conversation drifts toward machines taking over: "Let's keep the human flag up."

Frameworks

Framework 1 — The ownership ladder

How accountability actually gets built. The order is the framework.

Skipping to step 4 is the common error. Accountability demanded before authority is granted produces defensiveness, not ownership — and, as he points out, "accountability never comes out of failure."

Framework 2 — Building trust across distributed teams

For teams split by structure, geography, or both.

1. Be proactive about the why — the same first move, now load-bearing, because distance removes the informal channels through which context normally leaks.
2. Make decision-making collaborative at multiple levels. Not just across org structures but across geographies, "because with separate geographies there comes a cultural element for the local geography." Involvement creates a combined sense of ownership.
3. Be intentional about relationships. He is emphatic that this is the biggest factor. Formal and informal — team meetings, staff meetings, outings, sitting with folks over lunch. "That enforces people to learn about each other, and personal relationships sometimes help you get past cultural barriers."
4. Operate with zero authority. "Authority should be the last thing that leaders push in the modern network of work. It should always be about logical reasoning — and let the best idea win."

Framework 3 — Advice for the first-time leader

Four things to internalise on the way from senior engineer to manager.

1. Give away the fear of missing out. "You're not going to be a part of every implementation anymore, and you have to trust your people that they will do that."
2. Deal without authority. Be one of the team. "Allow anybody and everybody to come in and argue on a logical point — accept defeat, or be ready to argue against those points."
3. Keep processes thin, structures cohesive. Processes serve the structure, never the reverse.
4. Hire people who are smarter than you. "Always believe that there are smarter people than you who can do the job. Bring them in so that they can challenge you and help you grow."

And a maintenance habit underneath all four: "Always take time to reflect back on where you are going with your org and yourself — whether you are getting into a progressively growing structure, for the learning of individuals and for yourself."

Framework 4 — The platform architecture checklist

What to settle before the business logic.

Lessons

Platform and architecture

1. Decide scale, performance, reliability and resiliency before writing business logic — everything above inherits your answer.
2. The platform's real return is speed: application teams stop thinking about guarantees and start thinking about customers.
3. Build the platform ahead of time, in both timing and robustness.
4. Error handling should scale with blast radius. Platform code carries everyone.
5. Define contracts precisely wherever an API boundary is crossed.
6. Treat internal developers as customers — tooling, examples and docs decide adoption speed.
7. Keep a performance, scale and reliability test suite so you know your ceiling before you hit it.
8. Fund recovery, not just detection. MTTR is the number customers feel.
9. Time-box trade-offs and schedule tech debt as a product feature, jointly with product management.
10. Build generic, composable modules — including for AI — rather than monoliths that serve one use case.
11. Start AI work from customer complexity, not from models or infrastructure.
12. Contextualised data, not model choice, is what makes AI outcomes better.

Leadership

13. Answer the why before the what, proactively, every time. It converts assignments into missions.
14. Accountability is the output of ownership, never the input. Give responsibility, then authority.
15. Release pressure from the system instead of adding to it — calm and trust travel together.
16. Track passively with tools; active tracking reads as doubt and costs you trust.
17. Give air cover when teams miss, and you will get more effort, not less.
18. Keep processes thin. Processes serve structures, never the other way round.
19. Transparency is visibility for the team, not surveillance for the manager.
20. Push authority last. Let logical reasoning and the best idea decide.
21. Be intentional about relationships across geographies — they carry you past cultural barriers.
22. Bring in people smarter than you so they can challenge you.

Actionable advice

This week

• Take the next task you assign and lead with the why — the customer, the competition, where the organisation is heading — before you describe the what. Notice whether the questions you get back change.
• List what your team is currently held accountable for. For each item, ask whether they were ever given the authority to change the outcome.

This month

• Ask your platform or infrastructure team a single question: what is our mean time to recover, and when did we last rehearse it? If the answer is a shrug, that is the finding.
• Audit your internal APIs the way you would audit a public product. Is there documentation? Working examples? A way to test a call without asking someone?
• Find one process your team follows and ask what structure it serves. If you cannot name the structure, the process is friction.

This quarter

• Build or revive the performance, scale and reliability test suite. Establish where the ceiling is while nothing is on fire.
• Reclassify your largest piece of tech debt as a product feature, with a date, jointly owned with product.
• If you lead a distributed team, put one deliberate relationship-building mechanism in place — not a status meeting. Something informal, recurring and genuinely optional.

Final thoughts

There is a symmetry running through this conversation that is easy to miss because the two halves use different vocabulary.

The technical argument is that you cannot bolt guarantees on afterwards. Scale, reliability and resiliency have to exist before the business logic, because everything built above inherits whatever you settled for, and by the time the traffic arrives it is far too late to go back.

The leadership argument is identical in shape. You cannot bolt accountability on afterwards. It has to be grown, in order, from responsibility and authority and ownership — and by the time you need it, in the middle of a failure, it is far too late to demand it.

Both are arguments about paying early for something that only becomes visible under load. The platform nobody notices is the one that was built correctly. The team that owns its outcome under pressure is the one that was given the why, the authority and the air cover long before the pressure arrived.

His own summary of the leadership half is the shorter one, and it will do for both:

"Instead of being the agents of pressure, we should be the agents of releasing pressure from the system."

Rajeev is head of platform engineering at Freshworks, where he leads the Neo platform behind the company's product portfolio. He has spent more than two decades building enterprise B2B and B2C systems and data infrastructure.

▶ Watch the full conversation on YouTube