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 👇
As an engineer, you might have learned the basics from textbooks or watching a series of tutorials.
Managing engineers is different and isn’t something that can be mastered from simply reading a book.
In my experience, the only proven way to learn is by plugging into the collective wisdom of smart people who have done the hard work of actually managing engineering teams.
That’s why I was so happy to speak with Ian Nowland of Datadog.
With 20 years of engineering industry experience — 10 of which have been in management positions — Ian developed a unique approach toward engineering management, encapsulated in seven categories.
These seven categories of engineering management are based on his own software-engineering experience, which includes 10 years at Amazon and are designed to help managers successfully direct, satisfy and retain employees, as well as maintain a healthy company culture.
Some of the central components of Ian’s framework include taking the ego out of mistakes, developing a learning mindset towards management, and building social capital between teams.
We’ll dig into this more below.
Using the 7 Categories of Engineering Management
People often refer to the three P’s when it comes to management: 1) People; 2) Process; and 3) Product.
But Ian believes that’s limiting when you’re thinking about management in engineering and doesn’t account for the full range of engineering activity.
Instead, Ian believes it’s more helpful to consider the following:
- People: Are people happy and growing in what is being built?
- Engineering: How are things being built? This is about focusing on how your engineers get stuff done and how well those processes work — like the efficacy of a team’s code-review process.
- Product: Are customers satisfied by what’s being built? Ian also refers to this category as “portfolio management.” It’s about communicating with an engineering team about their roadmap, what milestones they plan to explore in that year or quarter, and what story they want to tell through their work.
- Partners: Do your partners understand and agree with all of the above? It’s important to foster healthy relationships between teams and any affiliated groups across the company.
- Execution: How are things getting built? Managers have to think about what has to be done and how they should organize teams to meet annual milestones.
- Operations: Once your product/org is built, is it going to keep running? Operational processes, like scrums or sprints, are crucial to the success of a software engineering project, so it’s important that managers ensure these processes are effective and efficient.
- Company: Does the company align with all these answers? It’s every engineering manager’s responsibility to reflect their company’s culture. A manager’s actions (or inactions) will set a precedent for their teams and direct reports.
The “Miss” Approach For Managing Engineers
Ian believes that when you’re managing engineers, there’s a lot to oversee. There are tons of opportunities for mistakes along the way — they can and will happen. But Ian’s found that it’s through making mistakes — or “misses” — that everyone gets to improve.
A “miss” occurs whenever something goes wrong that could’ve been prevented. But here’s the key: Don’t think of a miss as a mistake — it’s a teaching moment.
It’s a subtle mindset shift. Instead of focusing on the mistake (which can be damaging to a person’s ego), view it as an opportunity for growth.
When you start thinking in terms of misses, it becomes easier to digest. It’s like: That’s okay, I’ll get it next time. Ian found this especially effective for people with perfectionist tendencies (and I’m the first to admit I definitely fall into that category).
Using a Miss To Build Social Capital (aka Get What You Want)
Ian provided a beautiful example to illustrate what he was talking about.
Let’s get specific. Looking at the categories, here’s a miss I experienced in a previous job when dealing with partners at the company.
At the time, I was managing a software team that was in charge of a network device. A previous manager had made the decision to use a different vendor, and the network team basically said: we’re out. As you can probably tell, there was some friction between the two teams. By the time I started working with this group of software engineers, it was clear they were in over their heads.
I went to the woman who was the head of the network device team to ask if we could turn this over to her team — after all, software engineers have no business running networking devices. Since we were using our own vendor and her team was busy, she didn’t agree.
At an earlier point in my career, I would have felt frustrated and left it at that. But past misses (and the seven categories!) have taught me to look at the bigger picture. In this case, she’s well-intentioned and doing the best she can.
Considering the importance of building good relationships between teams, I focused on that. At one point, I even volunteered one of my engineers to help her with a software project to build goodwill.
About a year later, I approached her again to ask about taking over this particular network device. This time the answer was yes.
What changed? We’d built up some trust. We’d taken opportunities to show her that we were trying to do the right thing for the company (by helping her out), and so we’d established the social capital to get a positive response when we made an ask.
Want to hear what Ian learned from other misses? Listen in at 11:50 to hear about a miss in execution and how he came back from a project that went off the rails.
Does It Work? Measuring Success
When it comes to measuring impact, Ian doesn’t believe there’s a universal measure of success — it’ll change according to the situation.
Engineering leader Michael Lopp has written about management in terms of “organics and mechanics.” Ian tends to sway toward being an “organic,” which is essentially intuition-driven.
In his current role, Ian oversees a lot of managers. One of the main things he looks at is whether the managers are surfacing misses early — before they feel like a surprise.
When you manage a lot of different people, your job is to delegate well. The number of surprises is a good indicator of whether everyone is on top of what they’re responsible for — if there are few surprises, you don’t need to get too involved and that things are going well.
When measuring operations and delivery goals, these are areas where it makes sense to apply different standards. For example, objectives and key results (OKRs) are helpful the higher up you go on the organizational chart. When evaluating managers, Ian wants to know: Did they accomplish what they set out to do? If not, why didn’t it work out as expected?
Ian says you wouldn’t expect a team lead to care about OKRs; a team lead should be more concerned with measuring scrum.
Engagement surveys can be helpful for surfacing sentiment. But Ian doesn’t find them helpful for differentiating between a teams’ level of happiness versus its level of impact.
One-On-One Meetings Should Be Fluid and Unique
There’s much written about one-on-one meetings between managers and their employees, and rightfully so. It’s an important interaction for any coaching relationship. But a by-the-book approach to one-on-one meetings isn’t always a recipe for success.
The thing to keep in mind is that there’s no one-size-fits-all approach to these meetings. One-on-ones should be about helping engineers find unique solutions to their unique problems, rather than trying to present a milquetoast solution. At times, you might need to play the role of advisor, listener or coach. A fluid approach that is authentically yours is best.
Ian also recommends managers use open-ended questions to guide these conversations. For example, he’ll start a one-on-one meeting with something like, “Hey, someone else has this opinion about something that you are or aren’t doing, what do you think?”
This opens up the conversation so that they don’t think that you’re attacking or trapping them. Instead, it helps them gain different perspectives on their career path or a work-related problem.
How To Avoid Burnout Among Engineers and Managers
Lots of engineers tend to burn out in their twenties. But for Ian, it took a lot longer. It wasn’t until Ian was mid-career when he realized that his workload was no longer sustainable.
He was taking on too much work, and was such a perfectionist that he couldn’t and wouldn’t delegate that work to other people. He had been working way too hard for too long. He felt a sense of powerlessness: Ian went from eager and motivated to unmotivated and uninspired.
Eventually Ian realized that he had to slow down and find a solution to being overworked because he was, in fact, burned out.
For managers, the best advice for avoiding burnout is to first focus on delegating as much as you can. This will free up more time for you to focus on avoiding misses.
People grow through delegation — so you want to enable your direct reports to make the mistakes for themselves so that they can anticipate and avoid them next time (and hopefully not burn out in the process of learning this all). This article is based on an episode of Dev Interrupted, featuring expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery.
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.
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.
Over the last ten years, technology has become more sophisticated. Faster. Smaller. More powerful. But it isn’t just our technology that’s evolving at a rapid pace. Our culture, attitudes and politics are all changing, too.
So what could the next ten years look like? How might businesses change to keep up with technology? We spoke with Jason Warner, managing director at Redpoint Ventures, to get his thoughts on the matter.
“Ten years is an interestingly long, but also short time horizon,” Jason explained. “It’s likely we’ll see a complete company cycle, maybe two macroeconomic cycles.”
-On the Dev Interrupted Podcast at 10:29
1. Organizations will invest more in compliance and security
There have been a lot of large changes in recent years. People are working from home. Political tensions are high. And almost every device collects data about us. In all these cases, security is important. Securing our businesses, our national secrets, and our private lives.
It all leads to an inevitable conclusion. Jason believes that chief compliance officers will become commonplace, even in small companies. Protecting data is going to become a primary concern, for governments, businesses and people. Because, as the world gets more digital, we’re going to see more and more cyber attacks.
“Trends that I see happening are an increased awareness and investment in things like compliance and security. I think that if companies don’t have a chief compliance officer now, they likely will in the future,” Jason said. “I think it’s interesting when you see the geopolitical environment of how we might have to invest in more sophisticated tooling for national security. But more than that, it’s like understanding that we’re no longer a single micro-geo unit called the United States.”
- On the Dev Interrupted Podcast at 11:03
2. Companies will focus on loyalty and subscriptions over one-off sales
The standard business model is outdated. In the past, technology companies sold software, they gave customers the software and that was the end of the transaction. But now, it’s more about building communities and regular interaction with your customers. It’s about subscriptions, regular payments or even donation models, seen on popular platforms like Twitch. Software isn’t a product any more. It’s a service.
But almost every company these days is a technology company. Just look at what’s happened to the taxi industry. The model has completely changed, simply because the technology has evolved. The old model won’t completely disappear, but we’ll see more and more industries move into a subscription model as new technology takes over.
“Selling is about adoption first and selling second. Someone’s got to reach for you first,” Jason explained. “Then, they’re going to find a value problem, then they’re going to want to give you money if they’re finding utility out of you.”
- On the Dev Interrupted Podcast at 11:21
3. Hardware is, and always will be, just as important as software
With every new innovation, we place more demands on the hardware we’re using. The more advanced our software becomes, the more powerful our hardware must be. But right now, most companies rely on international trade to build key components. With tensions rising, it’s likely that we’ll see companies begin to bring these resources closer to home, securing their supply chain in the process.
“There’s interestingly a lot more emphasis on investing in hardware again,” Jason said. “And America in particular owning its hardware manufacturing, which I think is obviously good.”
-On the Dev Interrupted Podcast 11:41
Watch the full interview
If you’re interested in what else Jason had to say about the next ten years, and what challenges society faces, you can watch the full podcast on our site.
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!
Chaos Engineering might sound like a buzzword - but take it from someone who used to joke his job title was Chief Chaos Engineer (more on that later) it is much more than buzz or a passing fad - it’s a practice.
The world can be a scary place and more and more companies are beginning to turn to Chaos Engineering to proactively poke and prod their systems and in doing so are improving their reliability and guarding against unexpected failures in production and unplanned downtime.
During my career I dealt with my fair share of outages, including one that caught me mid-song during a bout of karaoke and far too many that woke me up at 02:00. As the co-founder and CTO at Gremlin, I do my best to make sure no other engineers have to suffer sleepless nights worrying about their product.
But the question remains, what is Chaos Engineering and where did it come from?
A Short History
The spiritual predecessor to Chaos Engineering is often called by a much more widely recognized name - disaster recovery. The focus when this practice was introduced is much the same as today: proactively suss out production problems by injecting failure.
Netflix’s Chaos Monkey is probably the most well publicized Chaos Engineering tool as it arguably kickstarted the adoption of Chaos Engineering outside of large companies, but this has led to the erroneous belief that Netflix invented the practice. In fact, the practice was already widely in use amongst the titans of technology.
Over a decade ago during my time as a Lead Software Engineer at Amazon, we implemented several crude practices designed to inject failure into our systems. The most rudimentary of which was employed by a man called Jesse Robbins, who earned the nickname “Master of Disaster” by running through data centers pulling out cables.
Let’s just say the practice has evolved a lot since those early days and your data center cables are much safer these days.
What is Chaos Engineering?
“What Chaos Engineering really is, is the art, if you want to call it that, of introducing controlled chaos.”
- 2:16 on the Dev Interrupted podcast
At its core, Chaos Engineering is a disciplined approach of identifying potential failures before they have an opportunity to become customer facing outages.
It is a practice that lets you safely test your assumption about how your systems will behave under duress by actually exercising resilient mechanisms in a controlled fashion. You literally "break things on purpose" to validate and build resiliency. The end goal of Chaos Engineering is not to inject arbitrary failure into a system, but rather to strategically inject turbulence to enhance the stability and resiliency of your systems.
How Chaotic is Chaos Engineering?
I always tell people that Chaos Engineering is a bit of a misnomer because it’s actually as far from chaotic as you can get. When performed correctly everything is in control of the operator. That mentality is the reason our core product principles at Gremlin are: safety, simplicity and security. True chaos can be daunting and can cause harm. But controlled chaos fosters confidence in the resilience of systems and allows for operators to sleep a little easier knowing they’ve tested their assumptions. After all, the laws of entropy guarantee the world will consistently keep throwing randomness at you and your systems. You shouldn’t have to help with that.
How do I Start?
One of the most common questions I receive is: “I want to get started with Chaos Engineering, where do I begin?” There is no one size fits all answer unfortunately. You could start by validating your observability tooling, ensuring auto-scaling works, testing failover conditions, or one of a myriad of other use cases. The one thing that does apply across all of these use cases is start slow, but do not be slow to start.
What I mean by this is to start testing across just a few nodes versus impacting your entire fleet. We refer to the impacted area as the “blast radius” and we highly recommend starting with a small blast radius (the number of systems impacted) and increasing it over time.
By starting small you allow yourself to gain confidence in both the experiments you are running and your systems. Of course your risk tolerance is also a factor of how large a blast radius your organization will use.
For instance, a large banking institution with millions of customers has a much lower risk tolerance than a tech startup with a couple hundred customers. In that case, they would want to run experiments in a programmatic way and would need to be very explicit about communicating to the rest of the organization what tests are going to be run and when to avoid any unplanned 2am or 3am disasters.
Eventually you want to get to the point where all of this is automated, a process we refer to as “continuous chaos.” Starting small with automation could be something as simple as taking out a single node; then taking out five nodes; then ten; and so on. Eventually you automate the process at a level you are comfortable with.
“Ultimately you want to be able to handle any of this random chaos being thrown at you, because that's what the world is, it's entropy, it's degradation”
- 7:35 on the Dev Interrupted podcast
No Tolerance for Downtime
When I founded Gremlin, it was just myself and my co-founder developing the first iteration of the product. The business looked very different then and I jokingly referred to myself as the “Chief Chaos Engineer” responsible for implementing code that was mostly used by enterprise companies. Many of these companies came to us because they had reliance thrust upon them by the US government or they had top-down reliability standards and they wanted a tool to help them shore up their systems.
As the company began to evolve, so did the customer base. These days it’s not just Fortune 500 companies that care about reliability, it’s everybody. Planned downtime is a relic of days gone by. It is no longer acceptable to espouse planned maintenance windows as part of development lifecycles and customers don’t have the patience for products they rely upon to spend any time unavailable. Companies recognize this dynamic - and it’s not a hard one to miss.
Seemingly our appetite for technology has gone up exponentially while our ability to stomach downtime has drastically decreased. Customers expect that your product is always working, always running. If your product is down because of outages then there are ten other similar products waiting in the wings to take their money.
Making Lives Better
Visibility is high these days and companies don’t need the publicity that comes with making any unforced errors, let alone to be subject to errors not of their making. No one wants to be blown up on Twitter because their product isn’t working or because one of their downstream dependencies or their cloud provider had an unexpected outage.
By preparing for the worst, we can be at our best as an industry and can be prepared when disaster eventually comes knocking. That’s why when an unexpected outage occurs or there is a production failure customers will never even know it happened.
I often joke that we are the engineers’ engineers because many of us know that feeling of being jolted from a dream at 03:00 by our pagers, groggily wiping our eyes and whipping out the laptop to go dig through a sea of monitoring dashboards and logs. It’s not fun and it’s exactly why I founded Gremlin. Because there is a better way to approach operations than merely sitting back on our haunches and waiting for the next outage. Chaos Engineering not only helps to protect against the randomness of the world, but also teaches people how to build more reliable software. And if enough people build more reliable software, we build a more reliable internet.
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.