Collaborating with Internal Dev Experience and Tool Teams

The tools a cloud native development team uses are designed and selected to solve productivity pain points and achieve business goals. It involves asking some basic questions: What challenges is my team facing? What goals does my team need to achieve? What tools exist that can address those challenges or meet those goals?

More importantly, when the tools you need don’t exist, can or should the internal team take on a “homegrown” approach and build themselves? Does the team have the right experience to successfully build — and use — these tools? How will internally built tools contribute to productivity, both for your internal teams and potentially external teams?

Using Your Own Products: A Path to Productivity and Empathy

At Ambassador Labs, using our own products not only makes us more productive but also lets us experience our products as consumers. Taking a look at the bigger picture, as we drink our own champagne, we’re able to test how features and functions might work for developers and teams externally, which is critical to building both our open source community and addressing the needs of commercial customers. Drinking the champagne and fine-tuning what will resonate externally starts with internal use.

This allows us to get a better taste of how real-world users might experience the product and better understand their pain points, infusing the product with what cloud luminary Kelsey Hightower calls “empathetic engineering.” That is, by using our own products, we can design software that is more usable and reliable for users.

We see a twofold set of benefits from using our own tools. Internally, it allows us to look out for and eliminate friction points in our application and, by extension, boost developer efficiency and accelerate developer onboarding.

Externally, it delivers similar benefits for organizations adopting them by enabling faster feature releases and better products for end users.

Internal Benefits: Increased Developer Productivity and Operational Excellence

Before shipping the champagne to external users, it makes sense to use it internally to ensure that it does what it’s intended to do — and certainly to test whether it makes a developer’s job easier.

What factors help us know whether our champagne is objectively any good? It’s all about measuring what is achieved. At Ambassador, we measure the impact of using our internal tools and examine the less quantifiable gains. These measurements look at performance based on business outcomes, not on individual vanity metrics, such as lines of code created, number of pull requests, and so on. This sets the developer and the team up for efficiency, real feedback, and an understanding of how their work affects the business.

We look at developer productivity and effects on operations.

Achieving Developer Productivity from Day 1

Developer productivity at Ambassador means that our culture and tools empower engineers to deliver business value fast.

The drive to use our own tools starts from Day 1 during developer onboarding. We use Telepresence and Ambassador Cloud heavily, which kicks things off the right way, building developer confidence by helping new developers get their development environment set up immediately, often running our cloud application locally and intercepting requests with Telepresence on Day 1 and opening pull requests on Day 2.

Using our own tools every day ensures that improvement is embedded in developers’ workflow. And as developers become more familiar with the tools and platform available, our experience shows that developers can reduce their inner and outer dev loop execution time and incrementally build productivity gains alongside faster feedback loops.

Gaining Measurable Operational Excellence

We set clear operational KPIs to understand our own performance. For example, we look at the number of incidents we experience, service downtime, software regressions, mean time to detect, and mean time to recover. This performance directly ties back to the business goals, the core of which is shipping software safely and fast to production.

Performance is measured against DevOps Research and Assessment (DORA) metrics, which examine deployment frequency, lead time for changes, change failure rate and time to restore service. DORA metrics keep us on the right track.

External Benefits: Build Better Products to Give to Users Faster

Using our own tools seems like an obvious way to boost developer productivity and help us achieve our business goals. But why do we do this? Like most organizations, we have end users and customers who can also benefit from drinking our champagne.

“Drinking our own champagne allows us to have confidence in what solutions we put into the world. When we use our own tools, we may be using the most common use case, which is not as complicated as the use cases of many of our customers,” according to Ambassador senior engineering manager, Steve Barlow. “When the baseline use case is solid, we are very sure that when someone has a problem, we can more easily and quickly identify fixes and alleviate points of friction for users.”

Ambassador’s VP of Engineering, Katie Wilde, explained that she was a champion of Ambassador tools in her previous role at Buffer and experienced how the tools helped remove engineering and developer friction. “Like most engineering orgs, we need to share and review a lot of our work. We also do a lot of cross-functional work at Ambassador, and Telepresence let colleagues share their work and get fast feedback without friction,” Katie explained. “Developers could develop and debug services running on a remote cluster locally.”

Spreading the Productivity: Take a Drink – And Share

A good “drinking your own champagne” experience doesn’t end when you pop the cork and drink the champagne yourself. Internally, there’s no doubt that benefits abound in terms of developer experience, developer productivity, improved metrics and smoother operations.

But your tools shine particularly when they are adopted and used externally, and external developers and organizations experience the same benefits — or better — than we do. By using our products ourselves, we raise a toast to our users, building empathy into the user experience, leading to better products that reach the market faster.