“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.
The typical model of business needs rethinking. Traditionally, businesses run in a rather industrial structure, almost militaristic. There are layers upon layers of management, with large gaps between the people who do the work and those who control the strategy. While this can work well in certain sectors, like manufacturing, it’s not ideal for a more innovative company.
So we talked to Bob Ritchie, VP of Software at SAIC, about an alternative way to structure business: the team-of-teams model. In this model, the leadership of the company creates smaller teams that manage themselves. And instead of presenting specific targets, the leadership gives each team a problem to solve. That can range from managing our customer service to making a new product.
“A top heavy and top-down micro-management ecosystem is just not what resonates today with knowledge work and thought work that an art form like software development is,” Bob says. “So the team of teams model presents a different concept. Instead of having this hierarchical command and control, the leadership strategy pivots to creating an environment where there’s a shared vision and a shared mission.”
-On the Dev Interrupted Podcast at 5:10
With more autonomy, teams are happier, more productive and work much more efficiently. But what do companies need to do to switch to this model?
Give autonomy through a shared vision
The first step is to make sure that the leadership team has a clear vision. What are you trying to achieve? This needs to be simple and summarize the ultimate aim of the company. Once you have that vision, everything else can begin to fall into place. You can allow teams to find their own way to an answer, which might be a solution you never would’ve dreamt of. Just make sure to give each team a set budget.
“Teams are granted a level of autonomy that then lets them define and discover their own purpose in where they fit in that vision,” Bob says. “Oftentimes it then provides invaluable feedback on how that vision needs to be altered based on what they’re seeing as opposed to that historical: I’m-just-being-told model.”
-On the Dev Interrupted Podcast at 5:47
This autonomy is key to the team-of-teams model. When you give creative and innovative people freedom to explore a problem, they’re much more likely to find a novel approach.
Give problems, not tasks
When you’ve brought together bright minds and talent, there’s no need to set specific tasks. You simply give the team a goal: a problem to solve. With small teams, they can easily organize themselves and make sure that they’re working productively. They might not solve it how you originally intended, but it’ll get solved.
“The Team of Teams model gives you that flexibility and I’m not telling you what to do, I’m giving you a problem to solve,” Bob says. “When it comes to execution in a dynamic landscape, Team of Teams is almost always better.”
Sure, in some situations like the medical world, there’s a definite correct answer. Things must happen in a set way. But Bob adds:
“In the software world, I can’t think of a case where anyone knows the right answer … To say definitively: Build me exactly this in exactly this time and this will be your guaranteed result.”
-On the Dev Interrupted Podcast at 19:18
Keep only four levels of hierarchy
But if you’re only going to give people objectives, and not set tasks, you need to make sure that individual employees are never more than four steps away from the CEO. Too many layers in between the worker and the CEO causes problems. So if you start to get too many levels, it’s time to start breaking your teams down into smaller groups.
“There has to be that cohesion of vision and purpose, and as you add layers between the individual contributors on the team to that CEO’s vision, you start to dilute the messaging,” Bob says. “So when I say: ‘there’s a problem, go solve it.’ They have a frame of mind and you know what our organization is striving towards … It really prevents that communication breakdown.”
-On the Dev Interrupted Podcast at 15:39
Invest in your teams
Once you have your teams set up and can trust them to get on with a task, it’s time to start investing in them. Train them up. Help them grow as individuals and workers. Do that, and the whole team will improve.
“The foundational responsibility of leaders is to create an environment where your teams can thrive,” Bob says. “So I think continual learning is such an important dimension … If I don’t have the opportunity at work to find some level of mastery in a craft, I’m going to seek an opportunity where I can go get that.”
This is another reason why the old model doesn’t work. It makes people cogs in the machine, who don’t get those opportunities to master their craft and feel fulfilled.
“If you’re not, as a leader, investing in those teams to stay as sharp as possible, you’re doing a disservice to your teams. Eventually, your team skill sets are going to erode,” Bob says. “Carve out time for your folks to not only have access to content, but actually immerse in it.”
-On the Dev Interrupted Podcast at 20:50
Let teams self-police
When teams are set up correctly, and have a good mix of skills, they’ll choose their own leaders. Perhaps through a vote. They’ll also often decide among themselves whether someone needs more training or needs to leave the team for good.
“The team self-polices to some degree. So if something gets escalated, it’s only in the cases where the team hasn’t been able to self-adjudicate,” Bob explains on the Dev Interrupted Podcast at 8:44.
They’ll often elect their team leader, too. Which is good if someone wants to step back from that leadership role for a time or give someone else a chance to prove themselves. All these things are easier in the team-of-teams model.
Stop looking for the perfect person
Another advantage of this model is that you don’t need to be looking for someone with all the skills. It’s often much easier to find an individual that slots neatly into a team, or five people that form a new team, than to find that one perfect person.
“Maybe it’s not the perfect person, but it’s a perfect fit on this team because of personalities and principles and values,” Bob says. “Even if they don’t become that perfect person that I was looking for, they’re still going to be a valuable contributor to that team.”
-On the Dev Interrupted Podcast at 32:31
It also makes it much easier to look for people who might need a little training, but you can always develop into a much stronger candidate. This opens up the pool of talent you have available to you.
Hear the full talk
This advice only scratches the surface of how organizations can make their business more efficient and productive. You can find out much more about the team-of-teams model and how it applies to business by listening to our podcast.
It’s important to remember that investment isn’t a completely altruistic act. While investors clearly want to encourage innovation, a primary motivation is to see a return on that investment. At the end of the day, they’re gambling that your idea will make them money.
This can make investing in true innovation tricky. True innovations are those rare game-changing technologies that revolutionize an industry. They’re notoriously difficult to spot. How often have you heard that people thought Apple would fail when they released the first iPhone or didn’t believe in Facebook when it first went public? True innovation rarely looks revolutionary to begin with. So how do investors spot which ideas are worth the effort?
We spoke with Jason Warner, managing director at Redpoint Ventures, to understand the reasoning behind investments and why investors are so picky.
1. Typical SaaS companies are easy to invest in, but true innovation doesn’t follow the same model
When developers start searching for investment, it can often be discouraging. While investors might not understand the intricacies of every technology company they invest in, they can at least spot the trends. They know and understand how a Software-as-a-service (SaaS) company grows.
If a company is growing, it has a very familiar pattern. And so investors can be quite confident that they’ll see a return. They’re much more willing to take a risk and ‘YOLO’ an investment.
“SaaS companies are really well understood in terms of how they grow,” explained Jason. “There is no real investor challenge to understand that if a company is growing 2x and its enterprise sales look good then … [investors] can just “yolo” invest into them. Because they understand what these companies look like … It’s all just Excel spreadsheets.”
-On the Dev Interrupted Podcast at 40:29
2. Investors often wait until the first round of funding, but developers need seed funding
If you’re developing a revolutionary piece of technology, then it’s likely that you need investment to get you off the ground. However, it’s difficult for investors to sort the good from the bad. How do they know you’ll be successful, without a few years of revenue behind you? It’s a catch 22 situation. You need the investment to get those first few years, but the investors need to see a few years before they’re willing to invest.
Look at how Netflix completely surprised the world. Nobody predicted that it would change how we watch video (most of all Blockbuster, who fatefully ignored the potential). This is a trend that harks back decades. Online shopping, personal computers, the television, even electric light bulbs were all disregarded when they were first conceived.
These industry-changing innovations need investment much earlier than typical SaaS companies. And spotting what works is more of an art than a science.
“[Investors] miss the fundamentals. They can see the ones that are the trends,” Jason said. “It should [then] become obvious in the next round or the round after that from other investors … oh yeah, that is a great company.”
-On the Dev Interrupted Podcast at 41:18
3. Developers need to seek out companies like Redpoint for seed investment
If you have a truly new idea, you’ll need to find an alternative to the usual investors. A company like Redpoint, which focuses on giving seed funding, is much more likely to take the time and actually investigate whether your technology will be a success.
It will take longer, of course. And it might not be the full amount you need to get your business started. But it’ll be what you need to begin building a proof of concept, get those first few years under your belt and start pitching to other investors.
“[If you’re] talking to a Redpoint investor, you should be flattered,” Jason explained. “What we’re thinking is that you are a majorly important company in the future. You have the potential to land … If Redpoint invests in you, we want it to basically mean that we think of you as a new primitive on the Internet or in whatever sector that you are in. And other people are going to build upon you.”
-On the Dev Interrupted Podcast at 41:35
Listen to the full conversation
If you’d like to learn more about what Jason thinks and how to secure yourself an investment, catch the podcast on our website.
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.
Flow can mean many things but when it comes to workflow it usually refers to that feeling, discussed by Mihaly Csikszentmihalyi, when you enter a state of intense focus and lose yourself in an activity.
Video games are a great example. They take advantage of this feeling to keep you immersed, which is why it’s so easy for gamers to “lose time” and just get wrapped up. The same feeling usually drives your most productive and best work.
When you manage developers, their workflow should be treasured and valued. That’s why, to improve developer focus, it’s vital to avoid weighing them down with minor interruptions or non-urgent pings.
“Flow is characterized as this experience where the task that you're doing is perfectly matched to the skills that you have.”
-Katie Wilde on the Dev Interrupted Podcast at 7:51
1. Acknowledge that it take 23 minutes for devs just to get into flow
Did you know that it takes 23 minutes to get into a flow state? For some people it takes even longer. That means that for every question, disruption, email, and interruption that you or your coworkers are subjected to, it could be half an hour of productivity down the drain. We talked to Katie Wilde, VP of Engineering at Ambassador Labs, about how she manages workflow
“Say you got a Slack ping, and you're like, “oh, I'll just ask a question.” How long does it take you to find the thread again? What's that total interrupt time? It's 23 minutes…that's been measured.”
-on the Dev Interrupted Podcast at 11:11
2. Defrag dev calendars
Some interruptions are unavoidable but many of them aren’t. Planning your calendar in a way that works around the needs and workflows of your team is necessary to maximize everyone's productivity.
For instance, scheduling meetings on days when weekly meetings already occur can help preserve focus time by not disrupting other working days.
Devs need to communicate with their managers on what times they have available away from normal workflow and then it’s up to engineering leaders to plan around those schedules. As a dev leader, you have to look at your devs’ calendars, not your own, and react accordingly.
“If you're a manager, when you're scheduling, don't look at your calendar, and then find a time and then see where you can slot the engineer in…look at the engineer's calendar and see, where can you tack the meeting on that it is after another meeting, or it is maybe at the start of the day, the end of the day… and ask them!”
-Katie Wilde on the Dev Interrupted Podcast at 12:31
3. Suck it up - schedule your work around focus time
When managing large numbers of devs, it can seem like a chore to work around many different schedules or attempting to get meetings done only on specific days. We asked Katie what her trick to juggling so many different calendars and meetings was, and she had one thing to say: “Suck it up.”
Devs are the backbone of software production and it’s important to prioritize their productivity whenever possible. To help them stay on task and be able to really focus on their work, they need to have meetings planned around their day - not yours.
Providing consistency for your devs - meeting them when they are ready, available, and focused - helps them maintain a flow state and maximize productivity. But more than that, it’s the right thing to do. Devs want to build cool stuff, not have their days ruined by their own calendars.
Katie says it best:
“That might mean that, as the manager, you have a little bit weirder hours. I hate to say this, but kind of suck it up… There's no way to get around that.”
-on the Dev Interrupted Podcast at 13:23
Watch the full interview-
If you would like to hear more about how managers can work around a developers schedule and other great insight from Katie Wilde, check out the full podcast on your favorite podcasting application, Apple Podcasts, Spotify, Stitcher, YouTube.
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.
In a typical manufacturing company, a supply chain is the chain of companies that you rely on to make your product. For example, a mobile phone manufacturer buys processor chips from a supplier. That supplier needs to buy a part from another manufacturer. And that manufacturer relies on yet another company for the raw metal.
But what is the software supply chain? And how do you keep it secure? We spoke with Kim Lewandowski, co-founder and head of product at Chainguard, to explain the details.
Your software supply chain is more complex than you think
The software supply chain can be complicated. Mainly because it’s difficult to know how far it reaches. Take a simple example: If you use Salesforce to keep track of your customers, you store your customers’ data on Salesforce’s servers. Not a problem, surely? But Salesforce could have a breach. And what about the servers themselves? Those servers might run on Windows. If that has a security bug, hackers have another way in. How about the software that Salesforce uses to host its website? If that is hacked, you have yet another breach.
“When I think of the software supply chain, it’s all the code and all the mechanics and the processes that went into delivering that core piece of software at the end,” Kim explained. “It’s all the bits and pieces that go into making these things.”
-On the Dev Interrupted Podcast at 11:28
Keeping the software supply chain secure involves checking who has keys
The important part of keeping your supply chain secure is making sure that you track down what you’re using. And checking that they’re secure and reliable. Every new third party can be a potential problem. If you don’t do your due diligence, you won’t know what risks you’re taking.
As Kim explained, a favorite analogy of hers is thinking about doing construction work on your own home.
“You have a contractor. Well, they need keys. They have subcontractors. You give the keys out to all their subcontractors. Who are they? Where are they from? What materials are they bringing into your house?”
-On the Dev Interrupted Podcast at 12:09
The more third party tools you use, the more out of control it can become
It all comes down to accountability. It can easily start spreading rapidly. One third-party tool that you use to create your software might rely on five separate third parties. And you don’t know what code they’ve got hidden under the hood. Your keys are suddenly all over the place.
The only way to keep it under control is to remind yourself to check and to do regular audits of the services you use. Kim believes it’s helpful to think of every new tool as a package coming to your home.
“How is your package getting to your house?” Kim said. “What truck is it riding on and who is driving those trucks?”
-On the Dev Interrupted Podcast at 12:44
Get the full conversation
If you’d like to learn more about the software supply chain, and how to make sure that yours is secure, you can listen to the full conversation with Kim over on our podcast.
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.
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.
At Netflix, we don’t just think about productivity - we engineer it. There’s an entire team within Netflix dedicated to productivity. I lead the Develop Domain along with my Delivery and Observability Domain peers, and together, we make up Productivity Engineering.
I recently sat down with the Dev Interrupted podcast to discuss all things productivity, how I run my team, and how other managers should view employee success. Here’s how we think about it at Netflix:
Can productivity be engineered?
In short, yes! Productivity is not a generic term for team performance or a perfunctory buzzword used during team meetings. The productivity team is an actual organization. The work we do is foundational to Netflix’s development teams. Productivity Engineering lives within the broader, central Platform organization.
The role of the Productivity Engineering team is simple: we exist to make the lives of Netflix developers easier. Abstracting away the various “Netflix-isms” around development, delivery, and observability, productivity allows devs more time to focus on their domain of expertise.
“We are sort of like the nerds’ nerds, if you will, enabling them to use our platforms and tools so that the work that they're doing is focused on studio and streaming, without thinking about everything that's under the hood.” - On the Dev Interrupted Podcast at 2:31
With the recent addition of Gaming to the list of Netflix’s pursuits, the resulting focus becomes even more important.
Practically speaking, it’s the role of Productivity Engineering to help with things like coding, testing, debugging, dependency management, deployment, alerting, monitoring, performance, incident response, to name a bunch. Netflix utilizes the concept of a “paved road,” the frameworks, platforms, apps, and tools we build and support to keep our devs rolling. The idea is to keep workflows streamlined and enable developers to operate as efficiently and effectively as possible. If the road ahead is cleared of obstacles, you’re going to get to where you need to go faster and with support along the way.
It’s also about helping developers enjoy the ride. To abuse another metaphor, a sound engineering experience should be like dining at a fine restaurant. If done right, you rarely remember the waitstaff, have a hard time finding something you like, or worry about how they prepared the food; you simply enjoy the experience. If Productivity Engineering is doing their job, they act as the restaurant and waitstaff with developers as the customer, providing nothing short of a beautiful end-to-end experience.
Measuring Outcomes vs. Output
Measuring all of that productivity can be hard, and there’s no one unicorn measurement to rule them all. Hence, developer productivity teams should focus on impact and outcomes. Above all, Netflix focuses on customer satisfaction. Our philosophy is that while how something is delivered is important, the impact of what’s delivered is ultimately of greater importance.
"If you're running around a track super-fast, but you're on the wrong track, does it matter? So really, what are you delivering? How you're delivering is important. But if that thing that you're delivering is ultimately doing what you want it to do, that's the most important thing."
- On the Dev Interrupted Podcast at 5:05
In this model, the outcome always wins over output or activity. For instance, standard productivity deployment metrics (DORA) as applied to our customers become an important proxy for measuring our success. Key Performance Indicators (KPIs) for productivity are viewed as a reflection of a team’s performance as it relates to customer satisfaction.
I’m a big fan of the SPACE framework, developed by Nicole Forsgren, for precisely this reason. How are our customers doing in terms of Satisfaction, Performance, Activity, Communication, and Efficiency? The answer to those questions reflects how we’re doing as a Productivity organization.
"This is our strategy, these are our hypotheses around, how we're going to improve our customers' productivity. Are those things paying off? And if you can't measure them in some way, who knows? Right? So yeah, we're getting a little more hardcore about this."
- On the Dev Interrupted Podcast at 24:17
Key metrics provide productivity teams with a holistic view of performance by establishing benchmarks. Understanding that everything needs to be viewed within the proper context, it’s difficult to improve as an organization if nothing is measured or tracked.
Comparing Productivity
Comparing developers’ productivity across teams is a thorny subject at best and downright dangerous for team morale at worst. As the old saying goes, “Comparison is the thief of joy” or what I typically say, “comparisons lead to unhappiness”, or with my kids “eyes on your own paper!”.
The productivity teams at Netflix take a contextualized view of dev teams rather than relying solely on raw data. 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.
It’s a basic understanding that comparing apples to oranges is not good math. A team that is just starting out and building something new, is going to look very different than a team with a mature product. By recognizing this, it becomes almost impossible to rank teams against each other because very rarely, if ever, will teams be doing the same thing, in the same space, the same way, with the same people.
Even a measurement of an outcome pertaining to customer satisfaction (CSAT) is not straightforward. At Netflix and across the industry, we’ve found that satisfaction for internal teams skews lower than satisfaction for customer-facing teams.
The reason? Teams within Netflix are their own harshest critics. When attempting to gauge the performance of an internal team vs a customer-facing team, it’s understood that the internal team is almost always going to score lower on satisfaction, even if both teams are equally effective.
Context is everything. Measuring productivity means being mindful of context.
Pushing Productivity
Any company that wants to be successful must understand how to measure its success. Productivity doesn’t count for much if an organization is not moving towards desired outcomes.
By viewing productivity as more than just a concept or a raw set of data, the hard-working teams at Netflix have turned productivity into an actual apparatus. It is a living, breathing team of human beings whose devotion to empathetic efficiency improves customer satisfaction and dev team quality of life. I am incredibly proud to lead these teams, and I sincerely hope the work we do inspires other organizations to improve their developers’ experience.
And if you want to be as productive as Netflix, remember that metrics are only as good as their context!
Everyone has their own definition of true leadership. What I didn't understand at the start of my leadership journey was that each of us is a leader. Regardless of intent, we influence and impact our communities, industries, workplaces, and relationships. Yet, often we don't understand the importance or impact of simply being present. So I wanted to write a message to anyone looking to grow into engineering leadership. This was the letter the younger version of myself needed and I hope that it will highlight the importance of self-empowerment in your journey.
To Whom it may concern,
Anyone remember by history has taken it upon themselves to venture down their own path. In some instances, these individuals stood their ground and continued forward in the face of violence, war, political and economic systems, beliefs, and stereotypes never before challenged. And so they changed the perspectives and consequently the lives of individuals around them. These individuals didn't stand out by being just like everyone else. Instead, they took up the metaphorical shovel and paved their path by taking actions in alignment with what they believed and desired.
Impact is Power
I want to bring attention to the notion of impact. These leaders influenced others to pursue their own paths even when they weren't speaking. By simply showing up in their spaces and picking up the shovel, they allowed others to do the same. These leaders understood what others would have to do to take up their own shovel and make way for their path. This is progression. This is the beginning of leadership. This is power.
No leader does anyone in their community good - whether leading an engineering team, organizing a non-profit, or elsewhere - by hating themselves, fearing their strengths, and refusing to take action where necessary.
Empowerment is the currency for operating with a sense of agency. There are at least two things you need to empower others: the first is power, and the second is integration. Power comes from authority and authorization and we can have internal and external centers of focus. Understanding how power and agency work allows for integration, and we can only begin to empower others when we include, communicate, invite, and co-create.
Leaders maximize their potential for impact. As an engineering leader, you get to facilitate and help lead the team to success.
The Emotions of a Leader
Let all that I've shared sink in. Just by being where you are today, you have proved that anyone else can do it. There's no escaping the power of impactful leadership. So let's share how our emotions and energies inevitably amplify the potential for success.
Leadership communities tend to focus on developing characteristics such as compassion or empathy in leadership, yet these traits alone don't make a leader in a workplace. Sometimes, these traits can cause us to take actions that neglect our boundaries, goals, and purpose. Therefore, we should consider how these traits can help us process our emotions and invest our energy properly into needed action. Leadership traits are like water. They allow us to flow and direct our energy. These traits don't substitute for the core strength of a leader.
When we can understand the impact and effect of authentic leadership, we can feel pleasure, motivation, pride, and joy for the work we do in the world. Leadership gets to be and feel good.
There are no shortcuts to realizing what leadership will mean to a leader because it's everything: joy, sacrifice, compassion, celebration, risk, gratitude, accountability, perspective, setbacks, success, etc. It's more than who we are as an individual, and it gets to be whatever you want it to be.
Empathy and compassion allow us to make our leadership feel good for others as well. For example, engineering managers that understand why it feels good for engineers on a team to deliver well-understood and maintained code on time, and make space to introduce specific practices that ensure these conditions are met.
The Core of it all, asking the hard questions
Every leader needs a purpose. How do we want to show up in the world? What do we want to create? What impact do we want to leave behind? These questions are important because how can you expect impact, integration, and success if you don't get them right? We'll all face setbacks, mistakes, conflict, and confusion. The core foundation of leadership is purpose. We mentioned self-empowerment earlier, but power is also derived from purpose.
It's similar to building a snowball. First, we have to pack the core tightly before adding additional layers of snow. Else we risk crumbling. And like snow, our goals and purpose can change.
I encourage aspiring leaders to consider what it means to be an individual contributor, a leader, an engineer, a project manager, a product manager, and anyone else on your team. Then, ask the hard questions and start to forge an answer, even if it's not the right one the first time around.
In closing
Leadership doesn’t happen overnight. Making it a reality means taking up a shovel and doing the hard work. It means continually empowering yourself, connecting and investing in others, and asking hard questions. Our software code is always in the pursuit of being understood, loved and in service to others. As an individual in an engineering manager or leadership capacity, we influence to make this a reality for our teams, communities, and industry—best of luck to those seeking true leadership.
This letter shared some insights into power, connection, and purpose as a leader. I hope it was useful to anyone looking for some encouragement related to being a leader in their capacity. Please feel free to connect with me if you enjoyed this piece or have any questions.
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 >>
