The office of the 20th century is a testament to design. A great deal of thought goes into the layout of a building. How are the offices laid out? Where are the elevators located? Where will teams meet? But the focus on co-located office space is quickly becoming a relic of the past. To meet the challenges of the 21st century GitLab's Head of Remote Darren Murph is pushing organizations to put just as much thought into their remote work structure as they would an office building. 

For many companies, the transition to this mindset comes with difficulty. They've shifted into remote work as a necessity, but maintain the 20th-century ‘office-first’ mindset. While this is passable and can work, it's not ultimately taking advantage of the key benefits of a virtual atmosphere. 

To take advantage of the shifting dynamics, GitLab is using their own platform to consolidate all of their virtual collaboration. Providing a single source of truth, GitLab has designed the virtual version of a central hallway where all work is funneled. This breaks down organizational siloes and enables the GitLab team to collaborate with maximum efficiency, by making sure that everything is as visible and as transparent as possible for everyone in the organization. 

A company’s ‘central hallway’ is going to look different from organization to organization, but the takeaway for all remote organizations and engineering leaders should be the importance of de-siloing information across your organization. This will encourage virtual collaboration and boost creativity. 

Meetings that Support Remote Culture

A Chief People Officer once asked Darren, “How do we make our meetings better?” His response? “Make them harder to have.” 

Darren believes that you should have as few meetings as possible because people deserve to be able to focus on their work. From this belief flows the practice of using tools like Slack or Microsoft Teams to gather consensus asynchronously, and then reserve synchronous time for meetings where only decisions are made or important status updates are shared. 

This has the effect of focusing a team’s attention which is important as teams become distributed around the globe, and time zones become a greater issue. It's far too easy for your entire day to be meeting with teams across your organization, with people coming online in various time zones to fill your day. Instead, the focus should remain on having critical day-to-day functions performed asynchronously - with meetings taking a back seat. 

In addition to focusing an organization's efforts, being thoughtful about structuring remote work also reduces meeting fatigue. We’ve all experienced being on Zoom or other video conferencing software continuously throughout the day. Not only is it inefficient and distracting, but it can lower your company morale and leave you exhausted and feeling like you didn't accomplish anything during the day.

Darren’s ideas may have seemed radical just a couple of years ago. But he and the folks at GitLab are pioneering - and thriving - in today’s remote environment. The office of the 21st century is undoubtedly going to be virtual, so remember to put as much rigor and thought into your virtual work structure as you would if you were designing a building. 

To learn more about how GitLab and other companies transitioned to remote work, check out Dev Interrupted's Remote Work Panel on August 11, from 9-10am PST.

Image showing four leaders of remote work from Dev Interrupted's New Leaders of Remote Work panel

Interested in learning more about how to implement remote work best practices at your organization?

Join us tomorrow, August 11, from 9am-10am PST for a panel discussion with some of tech’s foremost remote work experts. This amazing lineup features:

Dan Lines, COO of LinearB, will be moderating a discussion with our guests on how they lead their teams remotely, how the current workplace is changing, and what's next as the pandemic continues to change

<Register here>


Don't miss the event afterparty hosted in discord from 10-10:30am with event speakers Chris and Shweta, as well as LinearB team members Dan Lines and Conor Bronsdon.

If you haven't already joined the best developer discord out there, WYD?

Look, I know we talk about it a lot but we love our developer discord community. With over 1500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>




Shweta Saraf, the Senior Director of Engineering at Equinix, has a particularly interesting remote work story: she experienced a fully remote acquisition during the pandemic.

Her former employer - Packet - was acquired by Equinix, a huge company with more than 30,000 employees and over 200 locations around the world. Suddenly, the small team at Packet who were experts at remote work found themselves in the position of trying to onboard not just themselves at a new company, but onboard an organization of 30,000+ to the principles, structure, and best practices of a fully remote work environment. Because Equinix is the largest data center company in the world, operating data centers and office hubs all over the globe, the switch to remote work had to be as seamless and efficient as possible.

One of the key areas Equinix first looked to be efficient was in their meeting practices. They began what they refer to as ‘Better Way Wednesdays’ (their name for a best practice also utilized by Shopify) as a way to better inform employees and leadership. These meetings paired with a monthly business memo, capture the state of business along with key achievements, challenges or blockers, and give senior leaders KPIs and metrics.

This practice made it possible to cut down on the number of weekly status meetings, where the same information is passed on in different formats or through different levels of abstraction. The investment in this practice paid off immediately. Teams found that the “Better Way’ meetings would often only take an hour, but would save tons of time across the board. It also had the added benefit of reducing zoom fatigue. More focus time and better communication were realized by a single meeting shift.

The biggest focus Equinix implemented was asynchronous communication, because of the many time zones involved and the number of people all over the world, including engineering teams. Rather than restrict productivity to a specific set of time zones, async communication gives employees the agency to be held accountable for completing their work on their own time. Meaning that it is no longer necessary to align employees on separate continents onto the same Zoom call if that information can be transcribed in a chat app.

However, for companies where office culture is strong, with ceremonies happening in-office, it can be a learning process to adapt to working completely remote. With Packet’s experience aiding the transition for Equinix, a cross-synergy of ideas was realized. Employees from both companies found themselves questioning former agile ceremonies, such as stand-ups and retros, and whether these can be done asynchronously, or if they require a meeting at all. The merger resulted in an easier working environment for everyone.

Equinix, a company of tens of thousands of employees and hundreds of locations, transitioned to remote work successfully during the pandemic not because they were remote-friendly, but because they adopted a mindset of remote-first. Meaning that a developer on the other side of the globe could participate meaningfully and not feel left out. While not every company underwent an acquisition during the pandemic, Equinix's journey to a fully-remote organization is a familiar story for many tech companies this year.  To learn more about Equinix and how other companies transitioned to remote work, check out Dev Interrupted's Remote Work Panel on August 11, from 9-10am PST.

Interested in learning more about how to implement remote work best practices at your organization?

Join us tomorrow, August 11, from 9am-10am PST for a panel discussion with some of tech’s foremost remote work experts. This amazing lineup features:

Dan Lines, COO of LinearB, will be moderating a discussion with our guests on how they lead their teams remotely, how the current workplace is changing, and what's next as the pandemic continues to change

<Register here>

Don't miss the event afterparty hosted in discord from 10-10:30am with event speakers Chris and Shweta, as well as LinearB team members Dan Lines and Conor Bronsdon.

If you haven't already joined the best developer discord out there, WYD?

Look, I know we talk about it a lot but we love our developer discord community. With over 1500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>



Informing someone that you want to “measure” them is not a great way to start a conversation. Software developers, like all people, tend to look unfavorably upon having their performance closely measured. But measuring developers is one of the hottest trends for companies around the globe. So is it tyranny to measure people?

People are quick to note that numbers don’t tell the whole story and can become defensive at the notion their productivity should be quantified somehow. This resistance can become even more entrenched when teams become stacked against each other. 

Many leaders - like Netflix's Kathryn Koehler - believe we should absolutely avoid stack ranking of individuals and teams. After all, the human elements of teams - communication, coordination, leadership - can all affect the speed or perceived productivity of a team or process, so how can you quantify that? 

Thankfully, plenty of tools exist to enable a data-driven approach to the development process. With the right approach, these tools can be used to enhance any individual’s or team's performance. Beyond performance, when applied correctly, these tools can bring about more harmonious alignment between leadership and employees. 

But first, why do we measure? 

Why measure at all? 

It’s important to remember that measuring is just a tool -- it can be used for both good and for evil. An effective leadership team understands this basic fact. The cool thing about metrics is that they provide insight that might otherwise be difficult to obtain. Employees should note that good leadership will use metrics merely to inform their decisions, not solely drive them.

As a basic rule, it is difficult to improve something that is not measured.

I started with the really basic observation that I believe you cannot be sure that you're improving something if you don't measure it, right? I mean, think of trying to lose weight without weighing yourself. -Luca Rossi, from the Dev Interrupted Podcast at 4:31

Measuring creates a foundationa benchmarkwhich can be built upon. Once this foundation is established, organizations can begin to set goals. If you can set goals, you can rally a team; and if you can rally a team, you can achieve your product goals. This all becomes easier when you adopt a quantitative approach to your process. Success flows from the foundational element that measuring provides. 

Lastly, there exists a psychological benefit to measuring: namely, that people implicitly understand that metrics which are measured are important. After all, no one measures something they don’t care about. That which leadership identifies as measurable naturally informs employees what metrics leadership thinks are important. The very act of deciding to measure something telegraphs your intentions. Inversely, the opposite is also true: people tend to believe what is not measured is not important. 

All of this means leadership should be careful to identify what metrics are important because they define your organization and its behavior.

What should be measured?

First, an organization must decide what metrics are worthy and whether or not they are actionable. A lean approach is best here. Decide what does and does not matter to you, and then move confidently in that direction. 

So what metrics are worthy to an engineering team? 

There are many valid metrics which include things like Velocity, Branch Coverage, and Cycle Time, but one of the most interesting metrics we care about at LinearB is the Pull Request. In fact, it’s kind of our thing

A pull request has two major goals: the first is to improve the quality of code before you release it, while the second is to share knowledge between the team about the code base. 

Pull Requests are great because they let your team have control over what goes into git; they let people comment about what and why things were done a certain way; and they can serve as permanent documentation about a chunk of code that can be useful down the road.

If we at LinearB were to recommend one metric to start measuring, it would be Pull Request Size. Measuring PR Size -- and using that measurement to encourage smaller Pull Requests -- will help drastically lower Cycle Time. It will encourage all kinds of good behavior around code reviews, and it will prove that metrics can have a positive impact on business outcomes.

Once you have identified the best metrics to track for your success, you will need to go about making sure they last. Here it is best to maintain a lean approach, avoiding large upfront investments of time or money. 

How to make metrics stick

Image shows Luca Rossi and his title: Head of Engineering at Translated

And you should, as a leader, as a manager, you should make people feel that you care. There is no substitute for that. - Luca Rossi, Dev Interrupted Podcast at 21:10

We have all worked at a company where a change was decided, people were excited to see the change and then, after a couple of months, everyone has forgotten about it. Metrics are no different. Once a company makes the decision to align itself with a metric it must make the effort for it to last. 

It’s often best to start small. In the beginning, it is best to maintain a lean approach, avoiding large upfront investments of time or money. With small actionable change in mind, there are two ways to approach metrics adoption:

  1. In a top-down approach you ‘ll want to speak with your senior developers early on. Give them strategic input to help them figure out the best way to implement metrics into your dev team. An engineering leader can then explain how the metrics fit into the company’s strategic direction and convey that message clearly to employees. It is important to get buy-in from your employees because they are the ones building value, and further discovering what can and should be measured. When done correctly, the top-down approach will have managers saying, “Wow, I’ve always wanted to measure this. Now I can.” 
  2. In a bottom-up approach, it’s all about making your team understand what you want to achieve. Provide them with the initiative to build value so they understand why and how they are being measured. For instance, most developers can relate to a bad pull request experience - one that takes way too long or one that has a poor review and causes issues during production. People understand that a good code review should be both fast and accurate. So by starting small with a metric that is already understood, you will gain buy-in from your team. When done correctly, the bottom-up approach will have employees saying, “Wow, we didn't think we could measure this, and it's actually valuable.”

How you approach adjusting for change in the long-term is up to you. In an ideal world, both the top-down and bottom-up approaches would be utilized simultaneously.

Most importantly, your people should know that you care and that you value their feedback. 

Bottom Line

To achieve future goals a development team should know where it started. Metrics provide that benchmark. They are a foundation on which future success and business alignment can be built. 

Furthermore, in engineering, just as in life, tiny improvements are staggering when tracked continuously over a period of months and years. These gains boost team confidence and collaboration. 

Because with continual improvement, people feel as if they are working within a team and working as a team. When things go right, and everyone improves together, bonds are formed.

And of course, if you want to learn more about LinearB’s metrics or find out what our customers already know, you can book a free demo of LinearB.

I included a few quotes from Luca Rossi above. He has a great blog for those who are passionate about engineering. You can check it out here: 

Who says developers can't be the life of the party? Come see for yourself why the Dev Interrupted Discord has emerged as the go-to community for developers. Growing from 0-1400+ engineering leaders in just the past 8 months, our community is attracting the attention of CTOs and VPs of companies like Netflix, GitHub and Google. Join the community.

Three phases of a controlling engineering manager

Every morning, I see the unfiltered thoughts of 1200+ engineering leaders as one of the community moderators in the Dev Interrupted Discord server. We start every day with a Daily Interruption topic about how to make agile work in real life; scaling teams, building culture, hiring, continuous improvement, metrics - fun stuff like that. 

Recently this Daily Interruption popped up and stopped me in my tracks:

How much control is the right amount of control?

Nick might as well have asked, “what is the meaning of life?” You can see my immediate reaction was bewildered introspection. 👇

A bit of context… 

I was born with a default control setting of 10 (out of 10). I believe your strength is your weakness. At least in my case, this has proven to be true. Like many controlling people, I take ownership, obsess over little details and get the job done. Also, like many controlling people, sometimes I have a hard time working with others. I’m putting it mildly. 😄

So what do you think happened when I got my first job working at a software start-up? 

As an individual contributor, I crushed. My super controlling nature propelled me to dominate every task that was assigned to me. I overachieved. 

Then I got promoted. And just like my friend Dan Lines said about being promoted from dev to team lead, “a freight train hit me.” 

Since then I’ve been on a journey to figure out how much control is the right amount of control when it comes to leading software teams. I've been managing people for sixteen years now and I can break that time into three distinct phases:

My three phases of controllingness 

Phase 1

When I first got promoted to team lead I was highly controlling. I literally did most of my team's work for them. I worked seventeen hours a day six days a week to ensure every single task was completed to my exact specification. The people that worked for me were unhappy (some actively disliked me personally) but we got results that the CEO cared about so it went unnoticed. 

And I was good at managing up, so I actually got promoted for this behavior!  I was in my early twenties and motivated by the wrong things (power, money, and, of course, control). I look back on the period with embarrassment and I've actually apologized to many of the people who worked for me back then. 

Phase 2

I'm a person of extremes so when I realized micro-management was wrong, I naturally swung the pendulum in the exact opposite direction. I told myself I was hiring smart people and I should leave them alone. I'm good at hiring so it kind of worked. But, again, the people who worked for me suffered -- this time in a way that they noticed much less. Good people actually want feedback! It's not good for their work to go unchallenged because then it's harder to improve. My teams in Phase 2 all had a lot of fun and liked each other but we were a bit chaotic in how we got work done and we were not living up to our potential. 

Phase 3

I like to think I'm currently in Phase 3 which is more of a happy medium. I try to do four things to attempt to strike the right balance:

  1. Write super clear job descriptions and goals so every person knows which areas they own and which outcomes they are responsible for driving for the business.
  2. Provide extremely honest feedback... sparingly. You have to pick your battles. I find a lot of feedback is good upfront for new employees. And then, over time, you have to give people room to make their own choices or make mistakes. I find my people actually prove me wrong a lot of times when I think they are going to make mistakes anyway which is a good reminder to keep my mouth shut.
  3. Occasionally I decide I'm going to personally own something that needs to be handled my exact way -- like when an important new project needs to be bootstrapped with care and skill. In those cases, I let my control freak flag fly and I just do it my way. It’s ok to do this very rarely.
  4. I warn everyone upfront I am a recovering controlling jerk and apologize constantly for when I step over the line which I still do all of the time. 😁

Phase 2 is just as bad as Phase 1 

Managers in phase 1 get all of the credit for being the worst but we should not underestimate the damage that can be caused by phase 2 controlling managers - ones who do not “control” enough. 

I found this response from drdwilcox (a VP of Engineering) fascinating. 

“Communicating expanding expectations that come from growth
is such an important part of what I do with my leaders.” 

When I reflect back on my time in Phase 2, I realized it was my own insecurity that stopped me from communicating and coaching more. Once I put my imposter syndrome aside and realized I just needed to do my best for everyone on my team, I was able to strike a balance between too much input and too little feedback. 

Engineering metrics - a tool for good and evil 

Engineering metrics are probably the most common topic in the Dev Interrupted Discord as well as on our podcast (with the same name). Everyone has ideas about which metrics are good and bad and everyone has a story about a time that a bad manager used metrics to control their team in a negative way. 

Phase 1 managers often use bad metrics to stack rank engineers and pit them against one another or just force them to work harder. Phase 2 managers don’t share enough data and miss an opportunity to use good metrics to unite the team. 

If you’re trying to become a Phase 3 manager, our community has tons of resources about how to use metrics to help your people improve and increase quality and efficiency among your teams. 

What do non-managers think about all this? 

Scott, a “never-ever-a-manager”, has insightful and hilarious things like this to say almost every day in the Dev Interrupted Discord 😆

All are welcome in the Discord so please join us and share your thoughts and controlling manager stories! 

Join the Dev Interrupted Discord Community!

With over 1200 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed.

Join the community >>

We all understand that proper data analytics is crucial to the success of an organization. But what if your analytics can do more than help you troubleshoot current problems? Splunk is building a future where data analytics proactively solve problems before they occur. 

Data is essential to success and innovation for modern organizations. However, no commercial vendor has an effective single instrument or tool to collect data from all of an organization’s applications.

However, there is an open source framework: OpenTelemetry. By providing a common format of instrumentation across all services, OpenTelemetry enables DevOps and IT groups to better understand system behavior and performance.

Last week, Splunk’s Spiros Xanthos joined us on Dev Interrupted to explain OpenTelemetry - and to understand OpenTelemetry, we first need to understand Observability. 


What is Observability? 

Observability is the practice of measuring the state of a system by its outputs, used to describe and understand how self-regulating systems operate. Increasingly, organizations are adding observability to distributed IT systems to understand and improve their performance and enable teams to answer a multitude of questions about these systems’ behavior.

Managing distributed systems is challenging because of their high number of interdependent parts, which increases the number and types of potential failures. It is hard to understand problems in a distributed system’s current state compared to a more conventional, standard system. 

“It’s very, very difficult to reason about a problem when it happens. Most of the issues we’re facing are, let’s say, ‘unknown, unknowns’ because of the many, many, many, failure patterns you can encounter.” - Spiros Xanthos, from the Dev Interrupted Podcast at 3:02

Observability is well suited to handle this complexity. It allows for greater control over complex modern systems and makes their behavior easier to understand. Teams can more easily identify broken links in a complex environment and trace them back to their cause.

For example, Observability allows developers to approach system failures in a more exploratory fashion by asking questions like “Why is X broken?” or “What is causing latency right now?”

What is OpenTelemetry?

Telemetry data is the output collected from system sources in observability. This output provides a view of the relationships and dependencies within a distributed system. Often called “the three pillars of observability”, telemetry data consists of three primary classes: logs, metrics, and traces. 

Logs are text records of events that happened at a particular time; a metric is a numeric value measured over an interval of time, and a trace represents the end-to-end journey of a request through a distributed system. 

Individually, logs, metrics, and traces serve different purposes, but together they provide the comprehensive detailed insights needed to understand and troubleshoot distributed systems.

OpenTelemetry is used to collect telemetry data from distributed systems in order to troubleshoot, debug and manage applications and their host environment. In addition, it offers an easy way for IT and developer teams to instrument their code base for data collection and make adjustments as an organization grows. For more information, Splunk has an in-depth look at OpenTelemetry.

Benefits of OpenTelemetry

“In terms of activity, it is the second most active project in CNCF (Cloud Native Computing Foundation), the foundation that essentially started with Kubernetes. So it’s only second to Kubernetes and it’s pretty much supported by every vendor in the industry. And of course, ourselves at Splunk are big supporters of the project. And we also rely on it for data collection.” -- from the Dev Interrupted Podcast at 16:47

Since the announcement of OpenTelemetry 2 years ago, it has become highly successful. 

On the Dev Interrupted podcast, Spiros discussed how in his role as the VP of Observability and IT OPS at Splunk, he has seen OpenTelemetry grow to become an industry standard that Splunk relies upon for data collection. He highlighted three key benefits of OpenTelemetry:

    1. Consistency

      Prior to the existence of OpenTelemetry, the collection of telemetry data from applications was significantly more difficult. Selecting the right instrumentation mix was difficult, and vendors locked companies into contracts that made it difficult to make changes when necessary. Instrumentation solutions were also generally inconsistent across applications, causing significant problems when trying to get a holistic understanding of an application’s performance. Conversely, OpenTelemetry offers a consistent path to capture telemetry data and transmit it without changing instrumentation. This has created a de-facto standard for observability on cloud-native apps.  Enabling IT and developers to spend more time creating value with new app features instead of struggling to understand their instrumentation.

    2. Simpler Choice

      Prior toOpenTelemetry, there were two paths to achieving observability: OpenTracing or OpenCensus, between which organizations had to choose. OpenTelemetry merges the code of these two options, giving us the best of both worlds. Plus, with OpenTelemetry’s backwards compatibility with OpenTracing and OpenCensus there are minimal switching costs and no risk to switching. 

    3. Streamlined Observability

      With OpenTelemetry developers can view application usage and performance data from any device or web browser. Now, it’s easy and convenient to track and analyze observability data in real-time.

However, the main benefit to OpenTelemetry is having the knowledge and observability you need to achieve your business goals. By consolidating system telemetry data, we can evaluate if systems are properly functioning and understand if issues are compromising performance. Then, it’s easy to fix the root causes of problems, often even before service is interrupted. Altogether, OpenTelemetry results in both improved reliability and increased stability for business processes. 

Why OpenTelemetry is the Future

With increasingly complex systems spread across distributed environments, it can be difficult to manage performance. Analysis of telemetry data allows teams to bring coherence to multi-layered ecosystems. This makes it far easier to observe system behavior and address performance issues. The net result is greater efficiency in identifying and resolving incidents, better service reliability, and reduced downtime.

OpenTelemetry is the key to getting a handle on your telemetry, allowing the comprehensive visibility you need to improve your observability practices. It provides tools to collect data from across your technology stack, without getting bogged down in tool-specific deliberations. Ultimately, it helps facilitate the healthy performance of your applications and vastly improves business outcomes.

Listen here if you want to a deeper dive into the topics of OpenTelemetry and Observability - and how Splunk leverages them.

Join the Dev Interrupted Discord Community!

With over 1200 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>