Drinking Your Own Champagne: Drive Developer Productivity & Better Products

RMAG news

Eat your own dog food. Don’t just talk, the talk—walk the walk.

Drink your own champagne.

Whatever you choose to call it–in 2024, the concept of “drinking your own champagne” has become even more crucial for developer productivity, faster feedback loops, and the creation of better products. This approach, which involves using your own tools and solutions internally, has proven to be a game-changer for organizations across industries, and we, too, practice it! Let’s explore how this practice contributes to the success of developers and the products they build, with relevant examples from the current landscape.

It Creates Empathy

Understanding the needs and challenges of users, whether they are external customers or internal developers, is at the core of building successful applications and software. By using their own tools, organizations gain a deeper understanding of the user experience and can empathize with the pain points faced by developers.

When we drink our own champagne, we’re experiencing the software from the user’s perspective; teams gain a deeper understanding of their needs, pain points, and frustrations. This understanding enables us to make informed decisions and prioritize improvements that directly address user concerns, and enhance the overall user experience.

It Reduces Friction & Developer Toil

If your developers are utilizing their own product while they work, developer toil is lessened because pain points and friction are uncovered and addressed immediately. Drinking your own champagne also helps bridge the gap between technology and business requirements, reducing artificial stress and improving the overall quality of products.

When organizations use their own software, they gain firsthand experience of the challenges and friction points that developers and users face. This allows them to identify areas where the software may not be intuitive, efficient, or user-friendly. By recognizing these friction points, organizations can take proactive steps to address them, resulting in a smoother and more streamlined development process.

Additionally, when organizations use their own software, they have the opportunity to iterate and continuously improve it based on real-world usage and feedback. This allows teams to quickly identify areas that need enhancement, gather feedback from users, and make iterative improvements. This iterative approach helps reduce friction by addressing pain points and incorporating user suggestions, resulting in a more refined and user-centric software solution.

A strong example of this is Microsoft, which is known for using its own software products internally. For instance, their development teams use Visual Studio, Azure DevOps, and other Microsoft tools to build and manage their own software projects. This practice allows them to gain firsthand experience with their products, identify areas for improvement, and provide valuable feedback to their own development teams.

GitHub is another solid example of this practice in action, as they extensively use their own platform for managing their own codebase, development processes, and even some of their blogs. By relying on their own tools, GitHub developers gain firsthand experience with the platform’s features, identify areas for improvement, and contribute to the ongoing development of the product.

It Helps Us Measure Success & Create Cross-Functional Alignment

Drinking your own champagne aligns the development process with the organization’s business goals, and success metrics play a crucial role in evaluating that impact. Organizations should focus on both operational and business-related metrics to ensure continuous improvement and full business alignment. Ensure that you’re following both sets of metrics to paint a full picture of success.

By using their own software, teams gain insights into how the software contributes to the overall business objectives. This alignment helps bridge the gap between technical and business teams, as they can collectively work towards achieving common goals. By using the software internally, these teams can better understand each other’s perspectives, challenges, and requirements. This shared experience fosters effective communication, reduces misunderstandings, and helps bridge the gap between different stakeholders. It enables teams to work together towards common goals, resulting in a more cohesive and efficient development process.

Using your own software ensures that the software meets the needs of the organization and its users, reducing friction and enhancing the overall effectiveness of the software. Plus, it will give you a few metrics and talking points to use with prospects if you can speak to the efficiencies produced by utilizing your own software!

Additionally, organizations that embrace this approach understand the importance of having a mediator who can identify and resolve the sources of tension between technical and business teams.

To bridge that gap, having a “voice of reason” to help influence and shape how tools are developed, improved, and shared throughout the organization can make a huge difference in drinking your own champagne. Whether it is individual tools or the entire developer experience through a developer control plane, having some kind of paved path for developers to follow helps that champagne go down smoother. This generally starts with onboarding, which can be one of the biggest challenges for developers joining a cloud-native team, more on that later.

It Starts With the Culture

Drinking your own champagne goes beyond using tools internally. It also involves leveraging these tools to spread best practices and foster a culture of continuous improvement. It is a philosophy that filters down and works particularly well if your developer team is working in cycles so that they can adjust as needed.

Drinking your own champagne starts at the onboarding phase. When someone new starts, a best practice is to pair them with another seasoned developer on the team, preferably someone that’s a similar level to the new hire. Let that new hire shadow, learn, and jump in right away on easy PRs (even if it’s just fixing a typo) so they can get a handle as quickly as possible on the tool stack. Also, a pair of fresh eyes trying to navigate through your product internally will offer a new perspective on pain points and challenges that may have been otherwise glossed over by a team that’s working in the tool 24/7, day in and day out.

Culturally, it’s also important to be able to answer the question as to why external organizations and developers should use your tools. If you don’t like it, you don’t use it, or you get frustrated with it yourself–how are other developers supposed to feel any differently?

Atlassian is a solid example of this approach. Their development teams use their own tools (like Jira and Confluence) and they’ve created a culture where everyone internally manages their own projects and collaborates effectively within those tools. This allows them to understand the pain points faced by their users, improve the tools based on their own experiences, and deliver better products to their customers because it’s what they have to work in every day.

A Toast Drinking Your Own Champagne
In 2024, the practice of drinking your own champagne has become a cornerstone of successful software development. Organizations that use their own tools internally gain valuable insights into user needs, reduce friction between technical and business teams, and create better products. By measuring success, expanding tool usage, and spreading best practices, they foster a culture of continuous improvement and empower their developers to deliver high-quality solutions.

As the technology landscape continues to evolve, the importance of drinking your own champagne will only grow. Build better products that meet the needs of their users, starting with your own needs. Raise a glass and toast to the power of using your own tools!

Leave a Reply

Your email address will not be published. Required fields are marked *