At Google, I first experienced what world-class developer productivity looked like. Bootstrapping a new service, writing code, deploying safely, monitoring performance, and getting alerted when something broke all felt seamless. That ease came from a mix of deeply integrated tooling and a strong culture of engineering discipline.

At Harness, I worked on the mission of bringing that level of developer experience to a wide range of companies. Partnering with teams across industries gave me a clear view of what it really takes to unlock productivity at scale. It was not only about the tools themselves, but about how they were used, how they worked together, and how they fit into the broader engineering practices of each team.

At Databricks, the company is moving at an incredible pace, while also investing heavily in developer productivity and best practices. That combination reinforced a simple idea: tools matter, but culture is equally, if not more, important for helping engineers move fast with confidence.

Here are the key lessons that shaped how I think about developer productivity.

1. Culture makes tools count

Teams rely on many different CI systems, whether it is Jenkins, GitLab, Harness CI, or a homegrown solution. The tool can make a difference, but it is never the whole story. Productivity depends just as much on the culture around how those tools are used.

A fast pipeline cannot, on its own, solve deeper problems. Without testing or reviews, it simply delivers issues faster. But when testing and reliability are ingrained, the same tools become powerful accelerators.

The real lesson is that tools and culture work together. Tools provide the capability, and culture ensures that capability translates into real productivity.

2. Integrated tooling = real velocity

When critical steps like code review, CI checks, and security scans all live in different places, developers spend more time jumping between tools than writing code. That fragmentation slows everything down and makes feedback easy to miss.

The real gains come when these steps are integrated into a single workflow. Presubmit checks, CI runs, security scans, coverage reports, and quality gates all showing up in one view create a fast, reliable feedback loop. This also makes shift-left practices possible, catching bugs, vulnerabilities, or contract violations at commit time rather than after release.

The trend across the industry is clear. GitHub’s pull request checks, GitLab’s all-in-one lifecycle platform, and Google’s presubmit pipelines all reinforce the same lesson: velocity comes from integration.

3. Frameworks and golden paths as cultural assets

Frameworks are not just code scaffolding, they are carriers of culture. A strong service framework does more than spin up an endpoint. It gives you metrics, logging, security hooks, admission control, and other essentials from day one.

At Google, every new service started with the same consistent foundations because the frameworks enforced them. Databricks has taken a similar approach, building on Armeria to standardize service development at scale. In the JVM world, frameworks like Spring Boot or Dropwizard play this role for enterprises, while other ecosystems have their own equivalents.

On top of frameworks comes the idea of golden paths, popularized by Spotify’s paved roads. These are pre-approved, opinionated ways to build and deploy that reduce decision fatigue. They make the right thing also the easiest thing. Together, frameworks and golden paths ensure that best practices are not just recommended, they are built into the default developer experience.

4. Monorepo as a force multiplier

A monorepo is often misunderstood as just a way to keep all code in one place. In reality, its real power comes from how it reinforces culture at scale. With a monorepo, consistency is not optional. Shared dependencies, presubmit policies, and global refactors all flow naturally across thousands of services.

Without this foundation, frameworks begin to drift, tooling fragments, and teams start solving the same problems in different ways. With it, improvements can be applied everywhere at once, whether that is rolling out a new logging library, tightening security patches, or introducing stronger quality checks.

A monorepo is more than a code storage strategy. It is a cultural multiplier that keeps engineering practices aligned across the entire company.

5. Contracts matter more than pipelines

Even the best CI/CD pipelines cannot guarantee smooth releases if service contracts are brittle. In a microservices world, deploying safely means more than running tests against the current version. You also need to validate against the previous version for backward compatibility and the upcoming version for forward compatibility.

Without clear API versioning, consumer-driven contract tests, and practices like diff-replay testing, every release turns into a coordination exercise across teams. Pipelines might be green, but production still breaks because assumptions between services do not hold.

The real lesson is simple. Pipelines improve speed only when the culture around service contracts is strong. Without that discipline, all you are doing is automating broken dependencies.

6. Reliability enables speed

It is easy to think of monitoring, alerting, and incident response as overhead that slows teams down. In practice, the opposite is true. Strong reliability practices are what make rapid iteration safe.

At Google, no service was considered production-ready without monitoring and alerting built in from the start. That discipline gave engineers the confidence to release often, knowing that issues would surface quickly and could be addressed before they turned into outages.

The same principle holds everywhere. Engineers move faster when they trust that problems will be caught early and surfaced clearly. Alerts that fire at the right time, dashboards that tell the right story, and a culture that treats incidents as learning opportunities all combine to create confidence.

Reliability culture is not a tax on velocity. It is the foundation that makes speed sustainable.

Conclusion: Culture and tools together

Across my journey from Google to Harness to Databricks, one lesson has stood out above all others: tools are multipliers, not creators, of productivity.

The best platforms do more than provide CI pipelines or service frameworks. They embed cultural practices like testing discipline, strong contracts, and reliability into the daily rhythm of engineering. When those practices are reinforced by the right tools, developer productivity takes off.

For anyone building platforms, the takeaway is simple. Invest in tools, but invest just as deeply in the culture that surrounds them. In the end, productivity is not defined by how quickly code moves through a pipeline. It is defined by how confidently engineers can build, ship, and operate their systems at scale.

As we create the next generation of platforms, the challenge is not only technical, it is cultural. The teams that succeed will be the ones that excel at both.