It shouldn’t be a surprise that the outlook for many tech companies in 2023 is not rosy. With layoffs across the industry, we’re all going through a challenging time - whether you’re a dev or not.

The last 14 years have been an unprecedented boom time - but economic conditions will eventually challenge all companies. How do we, as leaders, handle these challenges? 
I sat down with Michael Stahkne, VP of platform at Circle CI; Lewis Tuff, VP of engineering at Blockchain.com; Carolyn Vo, partner & head of engineering at Oliver Wyman, for a panel at Dev Interrupted's conference to answer that exact question. Here’s how these leaders described what effective leadership looks like in uncertain times.

1. Increase the quality and frequency of communication

Some people will see this as counterintuitive. If times are tough, don’t you need more time to get work done? However, stellar communication is one critical way to lead effectively in both prosperous  times and times of crisis.

Michael had a strong viewpoint on this: in an async remote world, he will communicate when he needs to, and he expects his colleagues to share when they need time back. They have tools with settings to mute communications and get notifications as they see fit, and they can choose when to respond. 

Why meeting communication matters

It’s important to acknowledge that part of communicating well involves meetings (gasp!). It’s common to hear engineers complain about meetings. Yes, it’s good to streamline meeting schedules to reduce synchronous status updates that force context-switching. There are, however, ways to have effective meetings—and some are essential. Many meetings are crucial working sessions where you can collaborate with your colleagues.

Yet not all communication is formal. Informal signaling is also key. For example,  Carolyn shared  how she jokingly refers to herself as “Jr. Probationary Intern” to break down the artificial separation between you and your teammates as you become more senior. You can’t get rid of the power dynamic completely, but you don’t want your new people to be scared of you, and you need to have their trust to understand people’s motivations. Carolyn chooses to try to lower that separation through humor and direct acknowledgment.

You can't let this happen:

2. Connect motivation to business results

Understanding your team’s motivation is also essential. When things are uncertain, you must determine what motivates each team member. They’ll have questions like “Will I get to write the code I like?” And you have to answer immediately, “Yes, you will,” or “Yes, but you’re going to be reallocated to this new group.”

Michael also noted an often underrated motivating factor: How is your company oriented?

If your company is customer-oriented, if you’re focused on what they’re trying to achieve and are helping them do that—it softens the blows that land on your own company in tough times. Cutting back on your bets and focusing on your high-impact projects can also help with this and is sometimes necessary; sadly, this is often seen in layoffs or “reductions in workforce”.

Instill excitement through experimentation

Once you understand people’s motivations, you can help bring joy by providing space for teams to have fun.

When valuations are going up and to the right, it’s a lot easier to have work feel fun - so in an uncertain period, it’s imperative to get teams excited when you can. It lets people stop focusing on the downturn and instead on things that excite them.

Everyone can define “fun” differently, but knowing your team’s motivation can help you find the right ways to provide some levity and keep everyone aligned. You can bring fun in simple ways, like sharing something interesting you learned at the start of a meeting or, in Michael’s case, by throwing in emojis on Slack and shooting memes at a high rate per day.

For Lewis, teammates can find fun by having space to experiment and try new things with little pressure. Even if you disagree with your direct report’s decisions, part of providing space to experiment is still advocating for them and letting their choices play out—even if what they’re making feels like something you’ve seen before. Even then, the variables can be different, and it could turn out entirely differently. Whatever you do, don’t tell everyone you disagree with your team member’s idea. 

3. Have the tough conversations

One way to understand how much fun a team can have is to understand your tolerance for failure, which can get stricter as things get uncertain. But being transparent about this tolerance will continue to give team members the space to enjoy their work.

There is a myth that you must filter lousy news and hard decisions as a leader. But being transparent helps people understand the context behind why things are happening and helps ensure people aren’t being shocked. If you end up filtering news, you breed rumors and speculations, which can produce resentment.

Blame is a communication killer

Another pitfall to avoid with tough communication is blame. One example of blameful leadership is when a team member asks for a raise, and the leader says, “I want to give you one, but my boss won’t let me.” This type of blaming irks leaders like Michael, partly because it comes off as inauthentic. Authenticity is an integral part of being transparent and conducting successful challenging communication. There are a lot of discussions you can have during tough conversations beyond finding someone else to blame. Plus, people who own messaging are more likely to get promoted.

What to avoid when providing critical feedback

Providing harsh feedback can be challenging, particularly across cultural boundaries where how tough feedback is communicated can vary wildly. Like Carolyn, this is an area of improvement I see for myself as a leader, and somewhere, I’ve made mistakes. One example: I had to communicate critical feedback to a team member and thought I was writing a thorough and fair review by simply writing extensive feedback and including positives and negatives.

However, I didn’t spend enough time thinking about how to communicate that critical feedback: I started by addressing an area of concern and initially shared the feedback in writing vs. having a conversation with them. In some cultures, such as the Netherlands, this might have been perfectly acceptable--but in working with a US-based team member who was seeing layoffs at other companies, it backfired. Instead of helping provide feedback to initiate improvement, I’d caused them to worry that their job was at risk. 

In the end, I had to assuage this team member's worries--and acknowledge my own failure in how I communicated the criticism; I lacked context and empathy in my communication. When sharing critical feedback, I needed to remember the old US business adage of two positives to one negative.

4. Remove team roadblocks but track team progress

While communication is crucial for leadership, particularly in tough times, it isn’t the only thing. It’s also important to buckle down and ask yourself, “How can we as leaders remove roadblocks?”

If we want our team members to direct how they want to progress, we need to figure out how to support that and track it. By tracking this for your reports, you can align how you feel they progressed with how they feel while tailoring things to the individual. For engineering leaders, understanding the health of your team - without being a data-driven tyrant - is a crucial first step. 

A helpful next step is to find the individuals who are driving the company's principles and have them mentor teammates. Leadership can come from every seat but often requires effort to foster culturally and enable team members' progression.

Leading teams in uncertain times

Leading in uncertain times hinges on communication, transparency, and understanding motivation. You can’t treat everyone the same, as everyone has different goals and ideas for fun. The more you tailor to your individuals, the more you can help your team thrive in uncertainty. 

Watch my whole conversation with Carolyn, Michael, and Lewis on our YouTube 👇

“Treating devs like human beings” may sound like it should be an obvious idea. Yet we see the opposite happening on a regular basis - developers measured on lines of code, managers who expect engineers to act like automatons, and too many practices that sacrifice developer happiness and decay teams for short-term delivery.

To discuss how to fix these negative practices that too often damage our industry, I was joined by 3 experts in making the transition from churn and burn software development to more successful, human-centric development. 

Here are the 6 major takeaways from my conversation with Kelly Vaughn, Director of Engineering at Spot AI; engineering leadership coach Lena Reinhard and VP of Engineering at Range, Jean Hsu.

1. Humanize Interviews

Sometimes, we must remind each other that developers are knowledge workers, not robots. During our conversation, Kelly shared her view on one of the roots of this problem: the belief that engineers shouldn’t be required to code as part of the interview process. 

Her reason? Such tests don’t reflect actual working conditions. After all, when was the last time anyone stood over your shoulder at work and watched you code? Instead, she advocates for more problem-oriented system-design interviews that showcase how candidates think. 

Jean aligned with this, saying interviews should focus more on what it’s like to work with a person instead of how technically strong they are. However, humanizing interviews starts before the interview itself -  it means thinking about what your job descriptions and interviews cater to: Do they support people who have kids? People who already have a second job? Or do they hone in on “super passionate” developers who often have more free time?

2. API for Humans

Beyond interviews, Jean thinks that treating your working developers as humans is one of the industry’s biggest gaps. People moving into leadership and management roles are not trained to communicate and figure out, “Hey, what’s important to this other human?” She recalls one communication workshop where a person shared the takeaway “I feel like I just learned an API for humans.” 

Kelly Vaughn brings a unique perspective to this discussion - that of a  trained therapist. She leverages this training to monitor behavior and patterns of speech to see when interventions are needed and to understand the needs of her developers. It’s interesting to compare this approach to other managers who don’t get the same in-depth training in communication and in improving their emotional intelligence. So many times we promote developers to managers and actually set them up for failure. As a leader, it’s crucial to view developers not just as resources but as complex humans so that you can help them understand what they really want and how to create mutual value as part of the team. If we solely focus on the value to the business - and not the developer experience in building that business value - we sacrifice for short-term productivity bursts and decrease retention rates, causing major issues and costing the business money in the longterm.

One of my favorite examples of how to approach this dichotomy comes from Jean - one of her engineers told her they were having challenges balancing full-time work with other goals. This engineer was talented and a valuable member of the team, so Jean worked with them to transition them into a part-time role that let them have more time back for personal projects and more closely fit what they were looking for. This kind of relationship is challenging to develop, but when done right can both deliver for the business's needs and recognize each human's unique challenges. 

3. Can a Dev Manager Be Non-Technical?

With this focus on communication and humanization vs. technical skills, the natural next question is whether or not developers need to be led by managers with technical skills. From Lena’s experience, many great engineering managers are people who haven’t been developers and likely never will. It doesn’t take someone from a technical background to enjoy working in tech and understand the motivations of their developers. Yet we continue to see companies where leaders seem to think that the way to fill gaps is pattern matching their engineers. They’re making people leaders who have similar skills or behaviors to their subordinates or who excelled as an individual contributor without necessarily having leadership skills. This contributes to engineers who struggle or burn out in poorly-fitting roles.

Part of the joy of engineering leadership is seeing your engineers grow. Part of letting them grow is to stop fixing for them and start coaching them to do the solving themselves. And when you come from a non-technical background, that temptation is less, which is part of why many great managers are not from a technical background.

4. Bringing Your Full Self to Work

Our panelists views one-on-ones not as a place to give performance advice, but as a place for engineers to share their dreams, personal endeavors, and concerns. Kelly, Lena and Jean all felt that one-on-ones were a powerful tool for leaders to break through the dehumanizing barriers of software development as production line. In fact, because of Kelly’s background as a trained therapist, she views a successfull one-on-one as something close to the therapy, though she cautions this approach doesn’t fit everyone.

However, just like a therapy session, a good one-on-one should be individualized, confidential, difficult to cancel and devoid of surprises. A leader also needs to bring their whole self to the meeting, or the employee won’t bring their whole self. 

Lena resonated deeply with this. It can be tricky for people to bring their whole selves due to culture, and a leader should figure out what their employees’ boundaries are between personal and work life. It’s also important to recognizes that it’s not just regional or company culture, but also generational culture that affects those boundaries. At Range, Jean’s team report their mood for the day as well as what they’re working on during check-ins. She shared a story where she was explaining this process to another older engineering leader and that that  person laughed in surprise that people would want to share something like mood in the workplace. 

Jean feels strongly that the way a company talks is really representative of how they view their employees. For example, consider when companies call it “resource allocation” instead of “how employees spend their time.” In a higher-level position, you need to watch the way you talk and how you’re feeling about the people who work for you.

5. Metrics

Kelly had a great example of humanizing vs. dehumanizing metrics: time to close a ticket vs. the impact of closing a ticket. The latter is much more powerful and speaks more to the nuance of what’s going on with a team. Metrics shouldn’t just track information, but also give people something to look forward to. People want to be doing their best work and as I’ve written, we can use metrics to improve productivity without sacrificing developer experience

You can get a feel for how humanizing - or dehumanizing - a company is by what metrics they use when measuring their devs. For example, lines of code is a dehumanizing metric because it’s meaningless to the actual value a developer can bring. One key to humanizing metrics is making sure the metric is something that a developer is aware of and has direct influence over. Kelly had a great example of humanizing vs. dehumanizing metrics: time to close a ticket vs. the impact of closing a ticket. The latter is much more powerful and speaks more to the nuance of what’s going on with a team. 

As we talk about ad naseum at LinearB, metrics should focus more on team performance than individual performance. Metrics shouldn’t just track information, but also give people something to look forward to. People want to be doing their best work and as I’ve written, we can use metrics to improve productivity without sacrificing developer experience

6. Burnout

Another crucial challenge that stops people from doing their best work is burnout. Jean shared about a time when her company shut down for a short break and people were hoping everyone would come back from the break refreshed. But the break was amid the COVID-19 pandemic, and instead of returning refreshed, she came back tired. During a morning check-in, she shared how tired she still felt and how the short break didn’t make up for months of pandemic stress. One of her direct reports told her later how relieved they were that Jean shared, because they felt the same way! Acknowledging the elephants in the room is crucial as a leader; everything can’t always be rosy and your team wants to feel seen in the challenges you share.

Another important thing to understand about burnout is that it’s not just something you need to accept: Kelly pointed out that burnout is recognized as a mental health syndrome. Knowing that, leaders must be aware that cultural influences impact people’s willingness to talk about mental health, including regional and national cultural considerations. Your team members may not want to talk about it, so you have to look for signs before the burnout hits full force. Address these signs as soon as you can, and give the employee the time and the space they need to heal from it. 

You’ve also got to manage upwards around burnout: When the pandemic hit, many companies said, “We care about you,” but didn’t take action. Instead of reducing capacity to 80% and telling people they could be less productive during that time, they tightened goals. They worried more about their performance than their employees’ humanity. As a leader within your organization, you need to raise your voice in leadership discussions and challenge the organization's negative actions by showing that there is a better way to lead.

Humanizing Means Performance

Humanizing developers is critical and isn’t divorced from performance. As Jean says, it’s not like you can say, “Let’s just get the team running; then we can focus on caring about them.” Caring about your team allows them to perform with great results! 

Watch my whole conversation with Jean, Kelly, and Lena on our YouTube 👇

A 3-part Summer Workshop Series for Engineering Executives

Engineering executives, register now for LinearB's 3-part workshop series designed to improve your team's business outcomes. Learn the three essential steps used by elite software engineering organizations to decrease cycle time by 47% on average and deliver better results: Benchmark, Automate, and Improve.

Don't miss this opportunity to take your team to the next level - save your seat today.

Leadership in engineering can be challenging to get right. Even the most successful acknowledge that it took time to hone their skills. Just like with software issues, it’s important to take stock and gain wisdom from engineering mistakes to strengthen your organization and accelerate its growth.

We spoke with four engineering leaders who shared humorous of their professional screw-ups—with takeaways that you can apply to your professional development.

Lesson 1: Always Double-Check

The Leader: Daniel Marashlian, now the Co-founder and CTO of Drata

Early in his career, Daniel helped build the learning management system for a community college. After about a month on the job, he began to earn their trust and was granted access to more resources.

While helping a customer out and in the database, he saw an error and issued a delete statement. But a semicolon was missing—because it wiped out the entire student database. Luckily, senior members of the team rallied to help him fix the issue.

Only for Daniel to take everything down again.

Don't just take my word for it; take Daniel's from the video above—you should always double-check. This advice may seem simple, but following it will save you a lot of headaches in the long run.

Lesson 2: Know When To Automate

The Leader: Luca Rossi, now the Founder of Refactoring.fm

Luca's previous startup offered a way for people to shop around and reserve travel at the best available rates. In the past, they worked with the meta-search approach. Eventually, they decided to close the funnel within their website by allowing people to pay and book tickets on their platform.

However, since they felt it would also be a very intensive engineering activity, they decided to carry it out in a lean way. To start with, even though they integrated a payment gateway so that customers could pay for their tickets on the site, staff members still had to manually book the tickets on the transport company’s site when a booking came in. I'm sure you can guess what happened—as soon as they saw any sort of scale, their lives became a hell of booking 'shifts' with customers potentially showing up at any moment and team members on call to book them on the back end.

They made the mistake of not planning for what would come next. After deciding to release their solution as fast as possible, they failed to prepare for the challenges it would create for them.

There are always new problems to face in a rapidly growing company. It’s best to deal with them when they’re still small. If not, it might be too late. Something you don't automate at a small scale will only continue to grow in magnitude having untold impacts on efficiency and employer morale.

Lesson 3: Organize Teams Around Solving Problems

The Leader: Shweta Saraf, now Director of Platform Engineering at Netflix

Shweta shared with me an experience where she managed an eight-person team of engineers with extensive knowledge and inherited another team that excelled in the front-end and user experience. She had to think about how the teams could best cooperate to increase productivity and speed up the process of getting things done. So, they decided to reorg to a full-stack team: they took a couple of people from the back end, with domain expertise, and people with front-end knowledge and put them into a team.

However, the team bombed because they were too focused on fixing things in the back end. When the front-end specialists on a full-stack team complained that there weren’t enough stories to work on, it was a sign that they saw learning to code in the stack as too daunting.

From this, Shweta realized the importance of knowing the why behind any design or reorg you undertake as a leader. Full-stack teams may be successful in some contexts, but it doesn’t indicate they’ll be effective in others. It's important to take a 'people-first' approach and understand the needs and behaviors of your team members as well as provide a sense of ownership over the outcomes of their work.

Lesson 4: Understand Which Metric Measures Success

The Leader: Chris Downard, now the Vice President of Engineering at GigSmart

Being in a leadership position in engineering is challenging since you often have to roll out new projects while introducing your team to new tools. Chris joined GigSmart when the company was employing various platforms to pull stats and fine-tune its metrics. However, the amount of data was overwhelming team members who couldn't easily see a distillation of key points of emphasis.

Data is great, but it doesn’t help people make the best decisions until it’s put into context and presented as information. For instance, one developer had anxiety over their commits since they could see their commit activity. That’s the metric they zeroed in on for how well they were performing. This developer believed that the number of commits they pushed each day indicated their level of activity and productivity. But it really wasn’t. A high commit volume does not translate to a high acceptance and low rejection count.

As Chris shares in his video, GigSmart learned the lesson of what not to do when rolling out tools internally. Too many tools create the wrong kind of motivation—you need to align your platform to not just monitor vital metrics but to equip team members and managers with the knowledge they need to identify what's important. To solve this, Chris implemented software delivery management platform LinearB to shift how they show engineering metrics to the team; now, everyone has access to the information they need, but they can be intentional about what they’re looking at.

Moving on from mistakes

Nearly every great leader believes in continuous improvement for themselves and for their team. You can't have improvement unless you acknowledge—like these amazing leaders—that there are things to improve!

If you're looking for a surefire place to start improving your engineering team, dive deeper into another pitfall too many engineering leaders face with my Dev Interrupted co-host Dan Lines' blog: How to run a data-driven dev team—without being a performance tyrant.

Do you really need developer experience tools? Yes, you do, and we'll show you why: Your devs are mentioning their code is constantly stuck. They’ve been pushing code, but reviews are taking forever. So by the time the code gets back to them, they’ve already mentally moved on. 

On top of that, your CTO has seen that your cycle time has increased, and wants you to formulate a plan to reduce it without eating into the budget. Clearly, you’ve got a lot to do. 

You’ll need to roll up your sleeves and start working on your developer experience (DX) — a surefire way to help devs work better, leading to massive improvements in your PR processes and cycle times. A better DX will also help you figure out what’s putting a wrench in your system, so you can get to improving your engineering benchmarks across the board. 

But you don’t need to do all the heavy lifting yourself! One part of DX is using the best developer experience tools to make the process as smooth as possible so you can keep up with demand, even if you can’t hire more devs. 

In this article, we’ll show you some of the best developer experience tools around so you can save weightlifting for the gym!

Table of Contents

Top 11 Developer Experience Tools

Developer experience isn’t a set list of requirements. It’s a methodology that helps developers complete tasks as easily as possible, whether they’re pushing code to reviews or implementing common features without doing it all from scratch.

For you, it means empowering your team with the tools that help their overall development process — from ensuring code doesn’t stay stuck in PR limbo, to streamlining processes and improving important metrics like cycle time.  

A good developer tool isn’t there to de-stress software developers — it’s there to improve their workflow and environment. So here are eleven DX tools we think can help you and your other devs!

1. Netlify

Netlify provides an innovative and quick route to using your APIs and tools of choice, enabling devs to collaborate and develop the best sites and apps. It’s a CI/CD infrastructure tool backed with automation and a powerful CLI to sync all your devs’ production environments.

Netlify also adopts a hands-off approach, which improves devs’ experience. This DX tool’s smooth setup system also allows devs to jump between environments when needed, cutting down on tedious upkeep. And this translates to an overall better developer experience. 

This great DX tool empowers you and your team to use all the tools you know and love, integrating nearly anything with an API. The Netlify CLI also ensures all the devs on your team have identical environments, eliminating the hassle and time spent on setup.

2. Retool

Retool offers the fastest way to build internal web apps for your team’s needs. It allows you to read data from almost any database, including relational databases like PostgreSQL and MySQL or NoSQL databases like MongoDB and Firebase. This DX tool also offers a robust drag-and-drop system to create no-code web apps in minutes.

You can definitely use this platform to build a great developer experience. And when devs can whip up internal tools, they’ll have everything they need for success. Teams will also have the data or tools they need for a specific part of their workflow. And this is a huge +1 to their experience. 🆙

3. Auth0

Building custom authentication in your source code can pose huge security risks, so it’s a pretty bad practice. But with Auth0, devs can create feature-rich authentication without risking your customers’ data. 

This developer experience tool also gives your teams more options, like built-in bot detection, SSO logins, and role-based access control. All these features come in a simple package that works with nearly any programming language. Auth0 has made considerable strides in making its DX platform as easy to use as possible. 

The tool also gives all your teams the same functionality, whether they use no code, low code, or pro code methods. This means your devs will have the same result no matter what, and they won’t struggle to create a custom solution that works for them. Talk about major time savings and productivity boosts! 

Buff doge and weak doge meme, with buff doge saying: working with developer experience tools
Get massive gains from using developer experience tools!
Source: Imgflip.com

4. Flightcontrol

AWS is a definite powerhouse for dev teams, but it isn’t known for its warm embrace. It’s more like a mean personal trainer, electro-shocking you to hit your personal best in burpees. But Flightcontrol aims to free you from that grip, giving you complete control and ownership over your AWS, so you can create a platform that works with you, not by you.

Flightcontrol also provides flexibility with a GUI- or code-based configuration approach to your deployment services and environments. This tool even gives devs all the power between GitHub and AWS, automating the tedious tasks you all know and hate. And with those annoyances out of the way, your devs have more time to push code.

5. Port

Port understands the goal of platform engineering is to provide the best DX possible. So they designed their tool to go as far as possible to ensure it with their internal developer portal. Port provides an organized catalog containing details about all your software, services that use your software, and environments hosting these services. This developer experience tool lets you see what you’ve deployed and where. This way, you gain insight into your overall architecture, development lifecycle, and your team’s collective knowledge.

These insights can also give you actionable information to spot bottlenecks in your processes and eliminate them, so devs can be as productive as possible. This combination of visibility and control substantially improves DX.

6. PlanetScale

Databases are complex and terrifying for some devs, but they don’t have to be. Enter PlanetScale, an advanced serverless MySQL platform. This DX tool leverages the power of Vitess — the tech that helps YouTube scale to hundreds of millions of videos — to change the database landscape for the better. 

PlanetScale allows teams to host and manage MySQL databases with incredible scaling and flexibility, so you don’t need to worry about the tiny details of database management. PlanetScale also helps you concentrate on application development instead of putting in administrative or operational effort to maintain your app-dependent MySQL database. 

In a nutshell, this developer experience tool reduces the tedious work devs have to do, substantially improving DX and productivity. PlanetScale helps your devs simplify tedious everyday tasks, which in turn boosts productivity. 

Check out this discussion with PlanetScale CEO Sam Lambert, where he talks about the annoyances of enterprise SaaS and how it affects DX:

7. Render

Render offers a unified platform for building and running all of your apps and websites. With Render, you can select services like web apps, static sites, messaging queues, databases, containerized apps, and jobs scheduled for deployment. 

You can also deploy these services in seconds and even update your apps or websites when you have a patch or new versions to deploy. Render is basically the zero DevOps cloud platform because it eliminates DevOps work. In doing so, Render enhances DX by reducing the friction that comes with building and deploying services. 

8. HostedHooks

HostedHooks is a webhooks service platform whose JSON API and integrations make triggering webhook events from your applications simpler than ever. All webhooks with HostedHooks are encrypted with SSL and guard against replay, forgery, and man-in-the-middle attacks. 

With HostedHooks, devs can also set up mock webhooks to give users more options overall, and it can pass data to send notifications to the team when needed. This developer experience tool helps expand communication with minimal effort, so nobody gets left out of the loop. 

9. Doppler

If you’ve ever felt overwhelmed juggling multiple app or environment secrets, passwords, and .env files, Doppler can come to the rescue. Doppler is a SecretOps platform known for handling secrets effectively and securely across environments, devices, and teams. This tool also lets you put your apps, sites, or environments’ secrets management into production within minutes.

Doppler is simple to use no matter what tech stack you have, which enriches your DX. It also reduces the time developers spend configuring their environments, so they can focus their efforts on getting things done. And we all know that devs are happiest when they’re coding .

10. Prefect

An entirely new method of automating dataflows, Prefect is an open-source orchestration platform. Prefect allows you to use your current infrastructure to run programs and protect data. It also gives you comprehensive control and monitoring capability over your workflows.

Your developers can rely on Prefect to handle scheduling, infrastructure management, failures, logging, monitoring, concurrency, and more. Prefect’s cloud platform can also get data pipelines or workflows up and running with little effort. And that’s a prefectly — err, perfectly — good way to smoothen your team’s tasks and improve developer experience.

10. gitStream

As I’ve already noted, devs are happiest when they’re coding, but a close second might be when their PR finally gets merged. Merging devs = happy devs. And happy devs = more productive devs. 

gitStream is a continuous merge tool that uses workflow automation to optimize the PR review process and improve your merge frequency. Repo-owners can configure rules that classify each pull request and automatically route that PR down a unique merge path. These rules can automatically find the right reviewer, check for service deprecation, add context tags, and more.

With gitStream, you can codify your merge policies and use policy-as-code to standardize and audit certain best practices. And when you automate PR routing, you can achieve the level of code quality necessary for the ongoing success of your org. It’s truly a win-win for you and your devs. 

Check out this video on our YouTube channel where LinearB co-founders, Dan Lines and Ori Keren, explain gitStream!

How to Choose the Right Developer Experience Tools

Achieving a positive developer experience will improve how developers work. And ultimately, this will boost their morale and improve your developer retention rate. Developer experience tools contribute to a perfect balance of coding and non-coding tasks among your devs, lifting devs up so they can complete their jobs as easily as possible. DX tools also automate some non-coding tasks in your software development lifecycle. 

Regardless of the tech stack you choose, offering a great DX should be at the forefront of your developer platform. All of the tools we’ve covered work in some way to make the day-to-day easier for your team members. For example, if you choose Netlify to build and deploy your apps and sites, and Prefect for data pipeline development, you can also use gitStream for managing your PR process. The best part is that gitStream works well with all the tools we mentioned above. It’s also free, so you can go ahead and start using it without passing by the finance department. 

Setup gitStream on your GitHub repo today

A good SRE engineer will tell you your service is never down. A great SRE engineer will tell you that’s not what you should be measuring. In fact, they’ll tell you their job is customer service. 

Site Reliability Engineering (SRE) has grown immensely popular with many of the world’s largest tech companies, like Netflix, LinkedIn and Airbnb employing SRE teams to keep their systems reliable and scalable.

Along the way, SRE engineers have become one of the most sought after engineering roles in tech. 

The role is traditionally understood as ensuring that services are reliable and unbroken, but reliability and uptime aren’t perfect metrics. Perhaps what organizations should be asking themselves is what their customers think of their service. 

Wandering down to your engineering department and asking your SRE team about customer satisfaction is a good place to start. 

Their answer just might surprise you. 

History of SRE

In practice, Site Reliability Engineering has been around for a while. In the past its functions were covered by roles that had names like production ops, disaster recovery, testing or monitoring. The rise of cloud computing facilitated a need for more engineers in production. The complexity only grew as more organizations transitioned from monolithic infrastructures to distributed microservices. 

Modern Site Reliability Engineering originated at Google in 2003 with the work of Benjamin Treynor, who is seen as the “father” of what we now simply call SRE. Treynor, who coined the term, was a software engineer placed in charge of running a production team. With the goal of making Google’s website as reliable and serviceable as possible, he asked that his team spend half their time on operations tasks so they could better understand software in production. This team would become the first-ever SRE team.

“Ben Treynor said, I'm paraphrasing, ‘[SRE] is essentially like throwing a software engineer at an operations problem’, right? Because you come from that developer mindset, that design and, you know, you think about all of these things. So think about it as a developer but apply it to an operational type of problem.”

- Brian Murphy on the Dev Interrupted podcast at 4:26

Why not uptime?

So why shouldn't you be too concerned about your uptime metrics? In reality SRE can mean different things to different teams but at its core, it’s about making sure your service is reliable. After all, it’s right there in the name. 

Because of this many people assume that uptime is the most valuable metric for SRE teams. That is flawed logic. 

For instance, an app can be “up” but if it’s incredibly slow or its users don’t find it to be practically useful, then the app might as well be down. Simply keeping the lights on isn’t good enough and uptime alone doesn’t take into account things like degradation or if your site’s pages aren’t loading. 

It may sound counterintuitive, but SRE teams are in the customer service business. Customer happiness is the most important metric to pay attention to. If your service is running well and your customers are happy, then your SRE team is doing a good job. If your service is up and your customers aren’t happy, then your SRE team needs to reevaluate.

A more holistic approach is to view your service in terms of health. 

The Four Golden Signals

As defined by Google, these are the four golden signals of SRE. If these can be managed effectively, then you probably have a healthy system. 

Establishing system health

“The best way to get started is just measuring stuff, you know, just getting the baseline of what's healthy, what's not healthy, what looks like health, and then you can start working from there.”

- Brian Murphy on the Dev Interrupted podcast at 10:49

It can be difficult to know whether or not your organization should consider forming an SRE team, or what your next steps are if you’ve already made the decision. 

Again, think of your decision in terms of a holistic approach, not just your uptime. If you have high uptime, that’s fantastic, but what you should be establishing is a benchmark. 

Using the four golden signals to guide you, establish what you think a healthy system should look like and set your benchmark. Keep measuring over time and you will begin to see the areas that are good or require more work. 

These measures will help inform all of your future decisions. Perhaps your organization is ready to roll out new features or make choices around expanding your service. 

Critically, the health you establish provides insights into customer happiness. If things look good you probably have happy customers. 

Internal customers

When done right SREs aren’t just making customers happy, they’re making the lives of developers easier too. Nothing is worse than having to stop because there’s a problem in production. Good SRE teams can shield dev teams by focusing on major hotspots.

If the fires are being managed before they are out of control, it allows developers to keep pushing out features. It even gives them the freedom to keep breaking things, if necessary!

When things do break, or require a slowdown, a dialogue can occur. A good SRE understands that the developer who wrote a piece of code understands it better than anyone. The model for good internal customer service is an SRE who brings in a developer, gives them ownership of the code they created, and offers to help them fix it.

Happy customers are the best customers

Whether you already have an SRE team or are thinking about forming one, remember to think beyond the engineering - think about the customer. 

Ask yourself if your customers are happy and if you would describe your service as healthy. Remember to think about your own teams as well, your developers will thank you for it. 

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

Discover Our Most Popular Podcasts
Join the Dev Interrupted discord

To fight the wars of the future the US Air Force tasked a small group of software engineers with a simple job - revolutionize the way the military thinks about software development.

The group tasked with this not-so-tiny problem came to call themselves “Kessel Run” after the famed smuggling route used by Han Solo in Star Wars.

Since starting in 2017, the team at Kessel Run has expanded to include over 1,300 people across multiple locations, helping build, test, deliver, operate and maintain cloud-based infrastructure and warfighting software. These applications are used by airmen worldwide and represent the future of warfare.

That’s because the wars of the future will be fought with software and system architecture as much as any other weapon.

What is Kessel Run? 

Han Solo smuggles DevOps in the Department of Defense.

“[Kessel Run] was kicked off about four years ago as a way to prove that the Department of Defense didn't have to be terrible at building and delivering software, regardless of being within the world's largest bureaucracy.” - Adam Furtado, on the Dev Interrupted podcast at 1:35

As an Airforce organization, Kessel Run delivers a wide variety of mission capabilities to warfighters around the world, utilizing industry best practices around DevOps and Agile. At the time of its inception, it represented such a radical departure from the normal way of thinking within the Department of Defense (DoD) that people joked it would have to be “smuggled” into the DoD.

That’s how Kessel Run came to earn its name - a scruffy team outfitted with a mission to upend a stodgy and cumbersome bureaucracy. 

A shift in thinking needed to start with culture. The team at Kessel Run decided to bring a startup like mentality to the behemoth that is the federal government with a goal of introducing modern software methodologies at scale. Pockets within the DoD were practings things like continuous delivery, but prior to Kessel Run, previous attempts to adopt modern software principles had largely failed. Warfighters weren’t getting the capabilities or tools they needed. 

Problem Solvers

One of the biggest institutional problems that Kessel Run was tasked with trying to improve were the Air Force’s Air Operations Centers. Spread around the world across twenty two locations, these organizations manage all the details that involve fighting an air war. Everything from strategy, to planning, to tasking aircraft to perform certain actions, to providing real time intelligence data and feedback, are handled at Air Operations Centers. 

The challenge was modernizing these centers while maintaining operational readiness and current hardware - much of which was 20 to 30 years old. All of the hardware across these locations came with its own integrated software, built from various third party sources over decades. 

To tackle this challenge the team at Kessel Run applied the principles of Gall’s Law, which states that all complex systems that work evolved from simpler systems that worked. 

By starting small and focusing on rapidly achievable solutions, they began to see the network effects of their actions. Small, precise fixes can have tremendous impacts on an organization and are less prone to failure than attempting systematic change overnight. 

 “So we knew that using Gall’s Law in history, that we needed to start small, in order to make this work. We couldn't just have a big bang approach to replace this entire system. Right? You did that by chipping away at some core parts of the system from a user functionality perspective.” - Adam Furtado, on the Dev Interrupted podcast at 13:31

Practical Success

One of the first small changes achieved by Kessel Run was with the Air Force’s air refueling program.

A remarkable acrobatic feat performed at more than 20,000 feet above ground, at speeds close to 400 miles per hour, replenishing the fuel of an aircraft is dangerous but necessary work. Everyday, fighter jets and bombers rendezvous with fuel air tankers to perform air-to-air refueling before continuing on with their mission. 

Optimizing the details of such a delicate dance would be difficult, but the folks at Kessel Run believed they could do it. First, they needed software engineers. One of the problems of developing software at the federal government is a lack of engineers. Or rather, a lack of native engineers that can be found in-house. Historically speaking, the government outsources everything to contractors. 

Scrounging the Air Force for active duty software engineers scattered across separate programs, Kessel Run was able to stitch together it’s own homegrown software engineering team.

With their mission in hand, they set to work building an initial application nicknamed “Jigsaw” to improve the air refueling process. By optimizing every aspect of the process from the timing, to the altitude, Jigsaw became an enormous success. Within a year of implementation the Air Force was saving $12.8 million a month on fuel. 

Refueling Jets is expensive.

Tiny, targeted successes like these continued. But Kessel Run was up against more than just inefficient programs. 

A New Way of Thinking

Changing company culture is notoriously difficult. Changing culture inside the world’s largest bureaucracy is as hard as it gets. 

The most difficult problem that Kessel Run had to tackle wasn’t the lack of software developers, or the difficulty of integrating third party software applications, or figuring out how to optimize and build combat applications, it was how to communicate with their peers in the DoD. 

Part of the difficulty was due to the security implications of such work. The production environments are all on classified systems, making things like cloud implementation and tooling availability difficult.  

However, navigating the business side of the DoD was always the most challenging. In the past 30 years the government has spent over a billion dollars trying to update their systems to provide the best capabilities possible to warfighters in order to prepare for a war that may never happen.

Until Kessel Run, the government didn’t have much to show for their efforts. A perception existed that new software methodologies and practices were just the next iteration of technologies that overpromised and underdelivered. It took a lot of trust to explain that doing something in a more agile way or using DevOps, would actually reduce risk and increase success for the organization.

“The problem we have is we go and talk about how deployment frequency is going to buy down risk for us. That sounds counterintuitive to everybody in the world, particularly in a military environment, where they're like, ‘What do you mean? Change is scary. I don't change stuff.’ So we're having these kind of counterintuitive conversations around why moving to this way of working is less risky and increases our chances of success.” - Adam Furtado, on the Dev Interrupted podcast at 6:39

Solving that problem came down to nothing more than old fashioned relationship building. It took years of evangelism and continued success, but eventually Kessel Run started to win the approval of the right people in the right places. 

Proof is in the Pudding

From starting as an organization with only 5 software engineers, to expanding into a program that currently has over 1300 people, Kessel Run has proven itself to be an ingenious concept: bring startup culture to an old organization in need of modern ways of thinking. 

Government has never been the place that attracted the top talent in technology, but with Kessel Run it’s become that. They provide access to the newest technologies, competing with some of the best companies in the industry. 

They do have one ace up their sleeve when it comes to hiring: fighter jets. And those are pretty cool. 

If you want to learn more about the history and story of Kessel Run, consider listening to the Dev Interrupted podcast featuring Adam Furtado, Kessel Run’s Chief of Platform. 

Dev Interrupted is a weekly podcast featuring a wide array of software engineering leaders and experts, exploring topics from dev team metrics to accelerating delivery. 

Join the Dev Interrupted Community

With over 2500 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 >>

Dev Interrupted Discord, the new faces of engineering leadership

To call Google a titan of the tech industry would be an understatement. Their name has become synonymous with the internet itself. The very act of retrieving information from the internet - the core functionality of the internet and its most basic purpose - is known simply as “Googling” something. On their road to becoming the web’s biggest search engine and a moniker for the internet itself, Google also pioneered much of what it takes to grow a company at scale. 

On the Dev Interrupted Podcast Google Senior Engineer’s Hyrum Wright and Titus Winters, shared their lessons learned from programming at Google with LinearB Co-Founder and COO, Dan Lines. Both engineers have a deep understanding of the principles behind software development: Hyrum is semi-famous as the "Hyrum" of Hyrum's Law; while Titus is responsible for 250 million lines of code that over 12,000 developers work on.

But what lessons can we take from their interview - and their book Software Engineering at Google: Lessons Learned from Programming Over Time? How can we apply those lessons to our own projects? I’ve pulled out the core takeaways from their interview and condensed them so that any developer or company, be they responsible for 2,000 lines of code or 2,000,000, can learn something from Google’s roadmap. 

Why listen to Google

In spite of their enormous success and scale, Google doesn’t pretend to have all the answers; this lack of presumption is exactly the thinking that has made them the titan they are. Previous success is no guarantee of future success and no one understands this better than Google.

One thing that Google is very good at is not accepting how everyone else does it as the one true way.” - Titus Winters, on the Dev Interrupted podcast at 20:35

It’s easy to assume that events and conclusions are foregone, or that one event naturally follows another. Yet this is rarely the case. Most of the time people are working towards a specific outcome, and it’s not until later that the outcome is apparent contextually. This is true in life and software development. 

Google has spent the past couple decades approaching everything they do as trial and error, learning what does and does not work, and trying to institutionalize the things that do work. This is not a straight path.

This mindset is obvious in Hyrum and Titus’ interview. Titus uses the analogy of Lewis and Clark to explain how the software development process at Google has unfolded. 

“They say Lewis and Clark explored the Louisiana Purchase, by which we mean, they took one path out and one path back, which is not exactly mapping, but in a similar way, we're trying to give an exploration/trip-report/map.” - Titus Winters, on the Dev Interrupted podcast at 6:17

He’s admitting that Google doesn’t have all of the answers; that Google’s path isn’t the only path to success; that other paths may be superior to Google’s; and that their path may not work for every business. But, with decades of experience, Google has learned a thing or two along the way, and maybe, just maybe, we can all learn something from the path they have trailblazed.  

After all, there aren’t many companies in the world that have hundreds of millions of lines of code. 

The 3 Pillars of Software Engineering at Google

“Anyone can change a line of code or change 10 lines of code. But how about changing 10,000 lines of code or 100,000 lines of code in a reasonable time? - Hyrum Wright, on the Dev Interrupted Podcast at 17:15

With so much code to manage, Google has made maintaining their code a strategic goal. Code must be fresh and able to sustain changes to the code base for business or technical reasons. To best allow for this, they have identified 3 concepts that they believe are core to software engineering. 

1.Time

All of the hardest stuff that software engineers are going to have to deal with like skew version, backwards compatibility, issues with data storage, dependency management, upgrades and many more, are all problems created by time. Once dev teams realize this, it will change their perspective on how best to write code.  

For instance, if you are going to get rid of your code within one or two years, then you probably don’t need to worry too much about making changes or upgrades to it in the future. But if you are going to write code that will remain in use after five or ten years, then you may want to approach it differently. 

If dev teams want their code base to last, they need to think about constructing code so that it can sustain changes within an organization’s lifespan. This fundamental realization allows time to peacefully coexist with the second pillar. 

2. Scale

How your system scales is a relationship with time. Scaling isn’t a new problem and Google has been at the forefront of pushing scale their entire existence. For instance, email existed before Gmail and search engines existed before Google, but Google’s brilliance was their ability to scale these technologies better than their competitors. It’s the root of their success. 

To beat their competitors they adopted a mindset of scaling as a process - a continual evolution. 

As a company grows, all of its operations expand and that continued expansion requires more resources, which begets even more resources still. This means growth cannot occur superlinearly because if it does, eventually a company will consume all of its resources maintaining the status quo.  

The key takeaway is to make sure your codebase and software both scale sublinearly, that way if your codebase doubles or triples you won’t need six times as many engineers just to maintain your systems. (Sublinear scaling refers to team growth that occurs more slowly than the number of supported services of a company. Superlinear growth is the opposite - with team growth outpacing the number of supported services.

3. Trade-offs and Costs

After taking into consideration the best practices around time and scale, what is left is good decision making. Just as Hyrum and Titus note in their book, “in software engineering, as in life, good choices lead to good outcomes.”

However, no organization has perfect data on which to base every decision, and therefore must strive to make the best decisions they can with the most data possible. People need insights into what an organization finds impactful.

For instance, if an engineer spends a week on a project, it should probably be a project the organization considers a priority. Because if it is not, then no matter how perfect the code, it probably wasn’t the best use of the engineer’s time. Brain power should be devoted to the most difficult problems, not where a semicolon should be placed. The cost of incorrectly evaluating trade-offs is failing the 1st two pillars. 

Coming Home

While Hyrum and Titus may not be Lewis and Clark reborn, they have a valuable story to tell about trial and error in the Information Age.

How a company scales is likely to define how it differentiates itself from its competitors and whether or not it will be successful. A company that can scale sublinearly will thrive, all others will stagnate as victims of their own success. 

Minding the principles of these modern-day explorations into the wilderness of code will help any organization keep an eye on the most valuable resource: time. But remember just as Lewis and Clark found one path forward, they didn’t find the only path forward. 

We can all learn something from Google, but never forget the path forward is your own.

Join the Dev Interrupted Community

With over 2500 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 >>

Dev Interrupted Discord, the new faces of engineering leadership
Darren Murph, Head of Remote at GitLab

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

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.

Join the Dev Interrupted Community

With over 2500 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 >>

Dev Interrupted Discord, the new faces of engineering leadership
Shweta Saraf, Senior Director of Engineering at Equinix


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

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.

Join the Dev Interrupted Community

With over 2500 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 >>

Dev Interrupted Discord, the new faces of engineering leadership

INTERACT is the biggest thing Dev Interrupted has done yet.

An interactive, community-driven, digital conference on September 30th - by engineering leaders, for engineering leaders. 1 day, 10 speakers, 100s of engineers and engineering leaders, all free.

1 day, 10 speakers, 100s of engineers: Dev Interrupted's Interact Conference

Why attend?

Speaker Lineup

Sessions and more information to be announced over the upcoming weeks - register now to save your spot. 

🎉The #InteractDI Afterparty: Hosted by Dzone🎉

Immediately following the event, join our growing engineering leadership community for an afterparty in Discord hosted by Dzone. Click here to join.

______________________________________________________________________________________________________________________________________

This event wouldn’t be possible without our Presenting Sponsor, LinearB, and our Presenting Partners, DZone, and Daily.dev.

Presenting
Sponsor

About LinearB

Metrics alone don't improve dev teams. Software Delivery Intelligence (SDI) helps dev teams continuously improve by turning insight into action. Unlike top-down engineering metrics tools which become shelf-ware, LinearB is a dev-first platform and provides value to every member of the team. Development organizations using LinearB's SDI cut their Cycle Time in half after only 90 days. The result for developers is less bureaucracy, fewer interruptions, and more time to build. The result for teams is fewer process bottlenecks and accelerated delivery. Activate Software Delivery Intelligence for your dev team in 5 minutes at linearb.io.

Premier Partners

About DZone

DZone.com is one of the world’s largest online communities and a leading publisher of knowledge resources for software developers. Every day, hundreds of thousands of developers come to DZone.com to read about the latest technology trends and learn new technologies, methodologies, and best practices through shared knowledge. 

About daily.dev

The fastest growing online community for developers to stay updated on the best developer news. Together they supercharge developers’ knowledge and empower better software.

About Dev Interrupted

Dev Interrupted is the premier community for software engineering leadership and continuous improvement. We publish our podcast weekly, maintain a Discord Community of more than 2,000 engineering leaders, host monthly events, including our new quarterly INTERACT conference, publish articles, create videos, and much more. 

Join the Dev Interrupted Community

With over 2500 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 >>

Dev Interrupted Discord, the new faces of engineering leadership

Stay in the loop!

Sign up for our weekly newsletter