Hiring neurodiverse developers can be challenging, particularly for smaller companies that are less experienced at hiring. This isn’t because you need an entirely new process or that neurodiverse people are inherently trickier to interview. It’s that small flaws in your hiring process get exacerbated. Obstacles that cause neurotypical people to stumble, become outright blockers to a neurodiverse person.

So we asked Matt Nigh, data engineering manager at UW Medicine, to give his tips on how to make sure your hiring process suits everybody.

“I think there are companies that other organizations could mimic,” Matt explained. “I would look at Google as one of probably the best that I’ve experienced.”

-On the Dev Interrupted Podcast at 25:50

1. Interview processes should be conversational

If you use a lot of formal language, jargon and needlessly complicated words, you’ll make it much harder for your interviewee to understand what you want them to do. It also makes the interview artificial and cold, which can lead to unnecessary stress and anxiety in your interviewee. This is true for everybody, but for a neurodiverse developer, it can be much more potent.

“The most inclusive interview process I ever experienced was at Google,” Matt said. “And the reason I felt they had such an inclusive process is that it was wildly conversational. They were incredibly good at explaining what they were asking and what they were looking for. And to me, it was an incredibly friendly process.”

-On the Dev Interrupted Podcast at 24:10

2. Neurodiverse developers prefer straightforward and clear instructions 

When giving instructions, particularly in practical tests, it’s important to make sure that you’re being clear and straightforward. Leaving ambiguity can cause problems, especially for neurodiverse developers. That ambiguity can distract away from the actual task at hand. The clearer your instructions, the better you’ll test a developer’s actual skills.

“I would say the reason I failed the system design interview was (and this is an example of what autism will do during an interview) it was the first system design interview I ever had. And I spent half the time trying to understand the language that the individual was using, rather than solving the problem, trying to make sure we’re just on the same page with what we were saying,” Matt said.

-On the Dev Interrupted Podcast at 24:40

3. Neurodiverse developers need diverse recruiters, and stick around for longer once hired

Everyone has their own biases. While we should all strive to overcome those, it’s not always possible. The best way to avoid those problems is to make sure your interview team is diverse. Some coping mechanisms and strategies can seem strange to a neurotypical recruiter at first.

For example, someone with ADHD might ask you to repeat points or be typing as you speak. While it could initially look like they’re answering emails or not paying attention to you, it’s more likely that they’re taking notes to make sure they follow your instructions properly. The more diverse your recruiters, the fewer false assumptions you’ll make.

“Most recruiters are used to looking at neurotypical applicants, and they essentially have mental flags that come up with certain things, certain questions or anything like that,” Matt said. “Companies should ask: Do I have inclusive recruiters? So say, for example, at Google, they had incredibly inclusive recruiters. I was recruited by a deaf individual, for example. So this person very clearly understands me and anything that was going on.”

-On the Dev Interrupted Podcast at 25:13

4. Neurodiverse developers could be more productive, and worth changing your processes

A program at Hewlett Packard Enterprise hired over 30 neurodiverse people in software testing roles at Australia’s Department of Human Services. The initial results from the program seem to suggest that those testing teams are 30% more productive than others, according to an article in the Harvard Business Review, called neurodiversity as a competitive advantage.

It would seem that, while a neurodiverse person might struggle in some areas—like the social anxiety brought on by an interview—they could exceed in others, such as pattern recognition.

Watch the full interview

If you’d like to hear more from Matt on neurodiversity in software development, you can watch the full podcast on our channel.

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.

Grammarly has a simple but ambitious mission: to improve lives by improving communication. Every day, our AI-powered writing assistance helps 30,000 teams and 30 million people communicate clearly and effectively wherever they write.

But behind our technology is a team of engineers. Until recently, our engineers focused exclusively on building a product for consumers. When I came aboard to lead new initiatives as the Director of Engineering for Grammarly Business and Grammarly for Developers (expanding our product to support teams, organizations, and third-party developers), it was clear Grammarly approached full-on hypergrowth.  

Then the pandemic changed everything. Suddenly, we found ourselves transitioning to a remote-first organization amid hypergrowth hiring and onboarding. The company doubled in the past year to over 500 team members, and my teams have grown even faster. 

To be successful, we needed to spearhead initiatives that solved two problems. The first involved people: How could we successfully maintain a culture reflecting Grammarly’s EAGER values in a remote world? The second was technical: What tools and practices would enable our team members to thrive? 

Transitioning to remote

Historically, Grammarly has had an in-person culture. We have four hubs—in Kyiv, San Francisco, Vancouver, and New York. But when I joined in July 2020, everyone was remote. Few assumed it would stay that way, but the “return to normal” kept getting pushed further back. Eventually, Grammarly adopted a remote-first hybrid model. 

With “remote-first,” Grammarly team members work primarily from home. However, we continue to believe in-person interaction builds trusting relationships and a supportive culture that fosters innovation. So our offices became collaboration hubs where face-to-face meetups will also take place each quarter.  We made this decision based on our progression as a company; because we felt we’d learned how to communicate and collaborate effectively and saw advantages to the remote-first model.

Keeping it personal 

I look forward to meeting people in person at our first team-based meetup next year, but with my quickly growing team split between Kyiv and North America, we need to constantly build and maintain personal connections.

“I've onboarded fully remotely. I've only met four of my coworkers in person.”

- Dev Interrupted podcast at 19:33

Thus, we’ve tried our best to foster a thoughtful approach to team bonding at Grammarly—which signals that breaks and fun are important, too. 

Some example approaches: 

• Events celebrating everyone’s individuality and encouraging personal connections
• Coffee/donut chats, compliments of Grammarly
• Virtual hackathons

Our events motivate people to break from work and connect with each other. Activities range from educational to creative and silly, including an Indian cooking class during Diwali, a graffiti workshop, a cocktail class, a Halloween costume competition, and Grammarly’s twelfth-anniversary talent show. This personable approach also translates to how we chose the tools for remote collaboration.

Finding the proper tools

Setting hypergrowth teams up for success requires investing in the right tools and processes. As often as possible, we try to implement asynchronous communication and development best practices. Proper tools that facilitate organizational transparency are critical for alignment in a remote-first company.

Fewer people are required in Zoom calls because we share recordings and notes in open Slack channels. For collaboration and stakeholder alignment, our Engineering teams use Confluence for documentation, Jira for issue tracking, and Figma for collaborative interface design. Architecture and whiteboard sessions occur in Miro, while team retrospectives happen in Parabol. 

The archival component of these tools is invaluable; new and old team members alike can discover information through Glean, which gives us aggregated search across all our tools and content. 

Embracing the talent diversity potential of remote work 

One of the most exciting opportunities with remote work is in finding hidden talent in overlooked geographies. Silicon Valley gets all the attention, but it’s not the only region with great software engineers. There’s plenty of talent out there just waiting to be found. 

“Genius is evenly distributed by Zip Code, but opportunity is not”

- Mitch Kapor, Kapor Capital

Finding talent in other locations also leads to more organizational diversity. Whether that diversity is racial, ethnic, socioeconomic, or generational, diverse teams are going to improve your product. I’m a huge believer in diverse teams for two reasons: 

1. Better problem-solving than homogenous teams: I’ve witnessed this in my career, and it’s been proven with studies. Creativity naturally flows from visible and invisible diversity. Companies embracing differences will achieve better outcomes because the ensuing creative conflict helps you innovate and build better products. 
2. Stronger empathy for the customer: In Grammarly’s case, building writing assistance for the world’s 1 billion English speakers makes diversity in engineering critical. For example, those speaking English as a second language often visualize the language differently, leading to feature ideas that wouldn’t occur to primary English speakers. 

You need a diverse team to build the right product for a broad audience. We’re excited to use recruiting tools like SeekOut and partner with organizations like Elpha and AfroTech to help us connect with and hire engineers from underrepresented groups. 

Onboarding

But hiring isn’t enough! Many organizations are too focused on hiring, at the cost of onboarding. How we onboard folks and make them feel welcome is critical to their long-term success at Grammarly. 

A small test of our onboarding process is whether new engineers can push code in the first week. If they can, it’s a signal the dev environment is well documented and has minimal friction. The faster people can be productive, the more confident they feel, which ultimately boosts team morale. 

That said, onboarding is about more than pushing code. Engineers are encouraged to meet people and learn the product before they feel pressure to deliver. New engineers have a Getting Started Guide that includes who to meet and links to resources. Managers check in daily to answer questions. They also pair with a non-engineering Culture Buddy plus a mentor from their team so they can get to know all aspects of Grammarly life. 

Thoughtful onboarding during hypergrowth helps new team members build connections, which leads to better team health in the long term. 

Staying Grounded 

My advice to any organization about to engage in hypergrowth is to remain thoughtful. Think about hiring, onboarding, your processes, how you measure success, and how you want your employees to feel when they join your team.

Remember, too, that diversity is more than a checkmark or an abstract goal. Diverse teams will be your strongest asset. They will push creative boundaries—and in doing so will build the best possible product with the best possible outcomes. 

_

Want to join us in helping 30,000 teams at thousands of companies succeed through effective communication? We’re currently hiring for roles across the Grammarly Business and Grammarly for Developers teams.

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 >>

Three years into my software engineering career I was loving life. I could fix anything in the codebase with no doubts in my ability. I was confident, too. Most 24 year olds are. When I was offered the opportunity to become a dev team lead I jumped at the chance. With so much confidence, what could go wrong?

The first few months hit me like a freight train. I might have been a good developer, but I wasn’t a good leader - not yet. It was a humbling experience that I continue to grow from to this day. Great leaders understand that learning is a process that evolves over time, but only if you open yourself up.

In the past year as the host of the Dev Interrupted podcast, I have had the pleasure of interviewing and learning from some of the best engineering leaders in the business.

Here are 5 of their most inspiring lessons:

Always be delegating

Brendan Burns, Corporate Vice President at Microsoft

Brendan is widely known as one of the co-founders of Kubernetes. But he is also responsible for managing over 650 engineers at Microsoft. Even though Brendan takes time to schedule as many one on ones as possible - sometimes as many as 14 in one day, and something he views as a priority as more teams become remote - he knows such large teams can only be successfully managed through delegation.

Let go of the instinct to jump into every project. It’s ok if your teams make mistakes. They’re going to learn, but only if you give them the space and agency to grow. Stepping away from micromanaging can feel scary, but it will set your organization up for long term success and your employees will thank you for it.

Remote first, not remote friendly

Shweta Saraf, Senior Director of Engineering at Equinix

Shweta had the unique experience of undergoing a fully-remote acquisition during the pandemic.  Her small team was acquired by Equinix, the largest data center company in the world. As if this adjustment wouldn’t have been difficult enough on its own, Equinix wanted Shweta and her team to teach them - an organization with over 30,000 employees worldwide - how to implement remote work best practices.

To be as successful as possible with this transition they chose to embrace remote work completely. There would be no half measures. If they were going to become a remote work company, they would be remote first - not remote friendly.

Leadership with empathy

Ben Matthews, Director of Engineering at Stack Overflow

Ben wants leaders everywhere to know that no one has ever done a better job because they were scared, stressed, or worried about their future. Especially not in jobs centered around creativity and problem solving like software development. Providing people with benefits such as mental health days does more for an organization’s productivity than measuring hours worked ever could.

When you take care of people they will work better and faster - that’s also what they want to do. Everyone wants to be successful. Value creation happens when people are provided for, not when they are treated like widgets.

Comparison leads to unhappiness

Kathryn Koehler, Director of Productivity Engineering

Kathryn believes that what’s being delivered is ultimately of greater importance than how something is being delivered. Though she is in charge of making sure engineering teams at Netflix run smoothly and efficiently, she takes great care when evaluating a team’s performance. She understands that productivity isn’t simple math.

That’s because every project is different. The customer base is different, the use case is different, personas are different, and where a team is within the software development life cycle is different. Ranking teams against each other shouldn’t be the goal. Success is best measured in context, not in competition.

Avoid meetings

Darren Murph, Global Head of Remote at GitLab

Darren tells anyone that will listen there is a quick way to improve your meetings: make them harder to have. He believes people deserve to be able to focus on their work. No one wants to sit on video calls all day. Zoom fatigue is real. Focus should remain on critical day-to-day functions, not on hopping in and out of meetings that leave you feeling exhausted and unproductive.

Leaders should embrace tools like Slack that allow teams to gather consensus asynchronously. Reserving synchronous time for purposeful meetings like making decisions or sharing important status updates.

---

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.

A year ago I wrote an article for Dzone titled The Rise and Fall of a Senior Developer. Filled with personal anecdotes and stories from my years as a software engineer, the article was a critique of industry practices surrounding the somewhat controversial issue of ranking programmers’ seniority.

I realized that I might sound like an elitist dinosaur patronizing the upcoming generation of software engineers. A sort of “back in my day we did things differently” mentality that every generation seems to age into. 

So you can imagine my surprise when the article became not only my most popular submission, but caught the eye of Dan Lines, host of the Dev Interrupted podcast. 

In a follow-up to my article from last year, I’d like to share some of the takeaways from my discussion with Dan and discuss whether or not some of these hiring practices have changed in the past year. 

The rise of remote work is truly changing the landscape of hiring developers and finding talent. But are companies better able to find The True Senior Software Developers in 2021?

What is a "senior" developer?

There is no objective measure of a senior developer. Everything is dependent upon the specific work environment a developer finds themselves in. A humorous analogy could be the movie Idiocracy.

Seniority is determined very differently in an environment where your superiors have less knowledge and experience than yourself. Likewise, in a highly technical environment filled with experienced individuals, for instance, Tesla’s autonomous car team, you might discover seniority is determined by different standards. 

My most pragmatic answer is to say that it really depends on where you are and that hopefully your organization isn’t being run completely incompetently. 

To me a senior is someone who has mastered their domain beyond a majority of their team. That's probably the safest way for a manager to define how to find a senior developer: quantify the average level of knowledge on their team, and seek somebody who is above that average.

Being good at your job doesn’t make you senior

Not everyone hired at a company can be a senior developer but that’s a good thing because you don't want everybody to be at the high end of the spectrum. You need a team which is properly varied and has people with all levels of skills to fill in all the niches and gaps in your development process.  

Very often, companies just need someone who is good at React or proficient in TypeScript, able to adapt well to a team, understand a project, pick up tasks and implement them efficiently. That’s a good developer - not a senior developer. Those are things that you would expect from any member of a team because that’s what you pay people for.

I believe that when you're looking for a senior developer, you should be evaluating well above average. Unfortunately, it seems many companies advertise for senior developers, in the hope that they will somehow filter out the noise and get the most talented people, simply because they made it clear they were searching for senior candidates.

Of course every developer that shows up to an interview is going to say “I am a senior developer, a god amongst men.” Why? Because that’s what everyone wants to hear! 

That's probably a reason why seemingly 90% of advertisements for developer positions are for seniors, while the reality is that on a team there are only a few seniors. 

Experience isn’t everything

Though a year has gone - and you, dear reader, find yourself with another year of experience - that’s not an indication that you have magically become a senior developer. My belief that experience matters but is in no way an indicator of being a senior developer hasn’t changed.

Let's be honest, somebody can be a lazy bum for ten years and by sheer luck navigate through corporate realities and get away with it. As I said before: 

“10 years of JavaScript is just as good of an indicator of me being a senior programmer as 10 years jail time for armed robbery is an indicator of me being a law professor.”

Years of experience are needed, but I would never use them as the sole indicator of being a senior.

Where are we today?

Now that we have recapped, where are we today?

The rise in remote work is changing the hiring landscape and the development process. Companies are beginning to shift more teams to asynchronous development or hybrid models. These changes might be well-received by individuals but what will the long term impact be on hiring practices? 

It’s my opinion that companies are way too focused on the hottest frameworks, coolest tricks and fancy techniques, while forgetting the bigger picture, the concepts and principles behind software engineering and languages.

In the interview process applicants will claim to be Angular senior developers because they have an understanding of how to set up Vuex state store or fetch data from REST service using Axios, but having no idea about observer pattern, how asynchronous JavaScript actually works and are ignorant about prototype inheritance.

All these fancy things, they come and go very fast. But fundamental knowledge stays with us much longer, and if needed, allows us to learn all these transient frameworks, fads and fashions. 

Companies need to train themselves to filter out the noise. Don’t hire for passing fads. Look to hire developers with strong fundamentals because those are difficult to teach. If a candidate is good at something, even if it’s not the particular framework or language you are looking for, you should not dismiss them.

A real-life example

When I arrived in Ireland, I began applying for jobs and got interviewed by two gentlemen who started grilling me at the whiteboard. At some point during the interview I interrupted and said, “Guys, I think you have the wrong person here. I came to Ireland with a background as a .NET with a specialty in C sharp.” They wanted someone proficient in Python and I had never worked with it professionally. 

What they said next completely blew me away:

“We understand you don’t know much Python but we like your way of thinking, we see you are a brilliant C sharp programmer.”

Then they allowed me to take the test assignment for the interview in my preferred language of C sharp. Once I finished, they brought in a colleague from another floor who was a C sharp expert, he looked at my work, gave his approval, and they hired me on the spot. 

After about half a year, I was actually teaching Python to junior developers on the team.

I was taken by this honest approach to logic and hiring. They recognized an expertise in me even if it wasn’t exactly what they were looking for. 

There’s no replacing good fundamentals

It’s possible that the past year, and the continued evolution it has brought to remote work and remote dev teams, has caused more companies to jump at the chance to hire senior developers who claim they are experienced just because they put “managed remote dev teams for x years” on their resume. 

But when I watch events like this remote engineering panel, it is my hope that more people in the industry are adequately identifying The True Senior Software Developers, by avoiding the pitfalls of buzzwords and fad languages to hire exceptional individuals. 

While the fads and fashions of 2021 won’t be around forever, good fundamentals aren’t going anywhere (remote work might not be either.) Stick to hiring principles with an emphasis on expertise, but avoid having so narrow a view as to overlook talented individuals, and remember to always give honest feedback.

Not everyone is a senior developer, but if we’re honest with ourselves and our abilities, we can all take the steps to get there! 

If you’re interested in this topic, you can find more content like this on my blog at https://letsdebug.it.

Also consider checking out Dev Interrupted, 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 >>

 

Everyone loves free stuff, right?

Even better when that free stuff is both fun and adds value. That’s what Dev Interrupted’s upcoming event - The New Leaders of Remote Work - by engineering leaders, for engineering leaders - is all about.

Join us from 9am-10am PST on August 11th for another great panel discussion with:

• Darren Murph Head of Remote at GitLab & Guinness World Record Holder as the most prolific blogger ever
• Lawrence Mandel Director of Engineering at Shopify & Hockey Enthusiast
• Shweta Saraf Senior Director of Engineering at Equinix & Plato Mentor
• And the Panda himself, Chris Downard VP of Engineering at GigSmart

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.

Want to learn from the new leaders of remote work? Then this livestreamed Dev Interrupted Panel is the event for you.

<Register here>

We're excited for the future and very thankful to have you on this journey with us. You can always reach me for feedback (or site bug reports!) via our developer Discord community or on our Twitter.

Thanks for everything -

Conor Bronsdon

Community & Content Lead, Dev Interrupted

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 >>

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. 

• Read how LinearB, Dev Interrupted community sponsor, automates team improvement with engineering metrics that matter. 
• Listen to Chris Brookins, VP of Engineering at Appcues, explain how they use metrics for good.
• Watch Dana Lawson, VP of Engineering at Github, Kathryn Koehler, Director of Productivity Engineering at Netflix, and Charity Majors, CTO at Honeycomb, share which metrics help drive team improvement. 

 

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 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 >>