talks

Abstract # We are great at quickly gravitating to problems. Especially, with our deep understanding of the systems we own and operate. When things go wrong, great teams are quick to adapt, mitigate, and identify what we should do better in the future. However, it is easy for us to limit our minds based on our perspective of the system or how we have always done it.

This talk was part of the Kansas City Java User Group on May 15, 2025. When building and deploying Java applications, gaining insight into their performance characteristics is crucial. This talk will share methods and tools to help you gain a deeper understanding of what’s happening in your JVM. You’ll learn about improvements in how you can utilize these available tools in your development and evaluate performance issues (CPU, memory, and network) with your Java production workloads.

Newer revision of content from 2022 DevOps Enterprise Summit. Abstract # Change is something we must continually navigate. In a large organization, change can be further challenging based on the number of people that must have a shared understanding in this navigation. This can be complicated with organizational boundaries that can limit consistent communication across large groups, allowing costly variance or great ideas only surfacing within a smaller team or organizational boundary. We must improve how we stay connected, without overloading teams through more channels of communication. There must be a better way.

This talk was part of a New Relic User Group session in August 2023. This short talk walks through some different examples of data you can access in New Relic … which you may not have known about. This can include data about your data usage (ingestion), your agents (version compliance), and even the queries being executed. This also includes ways you can explore the data dictionary or execute queries through NerdGraph (GraphQL).

Presentation was part of DevOps Enterprise Summit - Virtual 2022. Abstract # Change is something we must continually navigate. In a large organization, change can be further challenging based on the number of people that must have a shared understanding in this navigation. This can be complicated with organizational boundaries that can limit consistent horizontal communication, allowing costly variance or great ideas only surfacing within a smaller team or organizational boundary. We must improve how we stay connected. This should recognize that we cannot increase the cognitive load on our teams through excessive forms of communication. There must be a better way.

This talk was presented at New Relic’s FutureStack 2022 conference, which focused on sharing lessons learned when dealing with some of the sociotechnical challenges in system observability within a large organization. This walks through some practical examples with how we focused on cultural aspects of learning and sharing approaches, while also including concrete examples in how we scaled and seeked ways in balancing consistency and autonomy in the usage of New Relic.

Abstract # Our systems are continually evolving, spurring the necessity to focus on how we can introduce changes which minimize the risk of a “big bang” event. By examining how traffic flows through your distributed systems, you can find ways of testing and evaluating gradual changes. By understanding different ways of managing your traffic, you build new options for evolving and testing your systems.

Abstract # Documentation is a valuable means of scaling knowledge through your teams. Teams are continually challenged to do more, with less. However, making lean maintainable documentation is a challenge, especially when documentation systems are not aligned to your development toolchain. Any point of friction in maintaining your documentation increase your probability of having out-of-date and untrustworthy documentation.

We live in a complex and fast-growing industry. While other engineering disciplines have been around for 100s of years, software engineering is still in its infancy and changing often. We are asked to share ideas to influence change, but this can be challenging in this rapidly growing field. This requires conveying thoughts to different audiences which may also vary on their technical vocabulary. It may be easy to reference a software engineering principle or law that can elegantly describe a technical scenario, but it may be ineffective when conveyed to others who are not aware of that concept. To be effective, we realize that words matter based on our audience.

Slides In this talk, we will discuss how to introduce and grow chaos engineering in your organization. This includes how to effectively communicate this approach with leadership and related teams, strategies on how to start small and expand into more risk adverse environments, and valuable lessons learned on making it effective within your systems. Approaches will include specific examples of how teams have applied chaos engineering at Cerner Corporation, a healthcare technology company. From this talk, you will be equipped with ideas on how to safely grow your chaos engineering practice within your organization.

QCon San Francisco 2019 recording Slides Get the 8.5 x 11" PDF hand-out QCon SF 2019 Recap: Blog post that summarized my experience at the conference and all of my notes. This guide includes a second page, to convert the guide into a paper airplane.

When I began my career in software engineering, I was fueled by the joy of programming and working through unique problems knowing that an answer would be discoverable through my trusty debugger and perseverance. As my career grew in the field, I began to learn more of the challenging constraints with large systems, human organizations, and complexity that seemed untamable. Through additional exposure to these larger problems that no longer could be tackled through the use of my beloved debugger, I began to see how it required different care and feeding at both the personal and team level to overcome these challenges. By investing in these areas, it would invigorate our creative process and deliver ideas that would contradict our traditional thinking.

One of the most powerful things we can do is make a decision. With the ever growing landscape of technology choices, we are faced with making a decision on a frequent basis. While decision making is not something we view as a core activity of engineering, it is the one thing we are doing at all levels of our architectures. This type of activity not only deserves our focus, but should also be considered as part of our craft that we pursue with improvement.

Meetings, the human ritual of synchronous communication. They are considered the cornerstone activity of keeping teams aligned on their mission. As engineers, we encounter meetings routinely in order to facilitate team work in software development. While meetings are a core ritual to team work, we many times find meetings drain our efficiency of software development. As a result, we perceive meetings as a negative exercise, only hindering us from our larger goals of software creation.

The most valuable asset in an organization is the people. Without people, you don’t have an organization (excluding robots). In the world of software development, many forces get applied to the people within your team which harm or degrade their quality of life. Fixed deadlines, the presence of Murphy’s Law in production environments, compilers which don’t understand your intentions, or just dealing with humans that don’t understand your code is working as designed. Face it, software development is tough and the only way you can survive it is by sticking together. The power of camaraderie within a team, is a force that can combat many of these ever-changing external forces that can damage your team. To build camaraderie, one must invest time and effort within the team.

If you are building Java Virtual Machine based services, a core measurement of your success is performance. The act of measuring and analyzing how your code is performing becomes an essential activity in all phases of your development. This skill becomes even more critical once you are required to troubleshoot and evaluate your service in a unique production environment. Understanding what operations are consuming most of our CPU time, as well as, what areas of your code are wasting resources will greatly improve your ability to diagnose a sluggish JVM.

Abstract # It is easy for documentation with our projects to get stale. This can especially be true with diagrams. This powerful visualization that illustrates our systems, can quickly become misleading when they become out of date. What if we could make it easier to maintain visualizations of our systems, by removing the burden of classical diagramming tools or forcing people into a presentation building tool to illustrate their system?