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 👇

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.

Learning to code doesn’t mean you have to become a programmer. Coding is one of those professions with a lot of transferable skills: logic, clear thinking, problem solving, and attention to detail, to name just a few. So learning a programming language can open up a whole range of opportunities, even if you decide to veer away from becoming a developer.

We spoke with Peter Bell, founder and CTO at CTO connection, on our podcast to see what avenues are open to those that learn how to program. Here’s what he said.

Be an individual contributor

If you enjoy programming, but don’t enjoy the management side of the role, then you’ll want to look into becoming an individual contributor (IC). An IC is someone who focuses on the actual programming, without any of the management responsibilities. In the past, this wasn’t a viable career path. But things have changed.

“It always used to be like: Hey, if you want to make more money and, you know, make your parents proud, then you've got to go become a manager and stop doing the thing you're actually good at. Which is writing code,” Peter explains. “So it's good that we've got the dual-track career path, now.”

-On the Dev Interrupted Podcast at 04:43

Now, if you want to focus solely on being a programmer, that’s a viable option.

Get into management

The fact that we now have a dual-track career path means that if you’re particularly extroverted or enjoy training others up, you can choose to head in that direction. Sure, you won’t be coding as much. But your coding knowledge will help make sure that you can train up your team, and understand what they need to work on.

On a similar vein, it’s worth considering overseeing an entire product. This is where you can take that extra step away and really think about the user experience. What makes the best sense for them? How should this piece of software work? How do all these pieces fit together? A product manager needs the skills of any manager, but also needs to be able to think about the actual experience.

“Somebody who has a solid technical background who moves into product, it's another way of scaling your impact, because now you can think about the user experience and the flows without having to be like: Dammit, I got the semi-colon in the wrong place,” Peter explains. “So you get what the geeks are talking about, but you can actually focus on the impact for the users... You can still talk thoughtfully about, you know, how are we going to run this in a Kubernetes cluster and how are we going to think about, you know, real time stream queries against the data source?” 

-On the Dev Interrupted Podcast at 05:06

Being able to take a step back away from the day-to-day coding can be great for those that enjoy reviewing code and looking for errors. When developing products, you won’t spend as much time writing new code, but you’ll get to think through the problems at a more abstract level.

Train or consults others

Another role, which can suit those that prefer the freelance life, is to move into training or consultancy. Companies are always looking to teach their staff about new techniques and languages. So if you have a knack for passing on your skills, you’ll be in high demand. In fact, Peter described on the podcast how he started off by writing blogs about ColdFusion. 

“I started presenting a technical conference around the US and around the world, and then I realized, once I got to a certain point, that people would pay me to do this,” Peter says. “I've been on the other side where I'm paying someone to come in and talk about Redis or whatever. And I'm always saying to myself: This is really expensive, but we're still paying for it.”

-On the Dev Interrupted Podcast at 06:36

Being able to pick up a new language or technology quickly is a skill that not many have. So if you can do it, you can easily go into consultancy or training and earn a substantial salary. For example, Peter explains that large companies will often pay between $10,000 and $15,000 for a single day training 30 engineers. If you can pull it off, and leave those engineers with the right skills, you only need a few jobs to make a good living.

Try being a sales engineer

If you’re someone who enjoys working with people and thinking about the overall architecture of a project, rather than the fiddly details, then you might have more impact if you become a sales engineer. This role is all about understanding a product inside and out, giving demos and presenting the facts. The best sales engineers are the knowledgeable ones.

“It’s this intersection between understanding computers and being able to speak to a human. And it’s a relatively rare trait,” Peter says. “It seems engineering is awesome because what you do is you get to go and hang out with other geeks, and understand their problems.”

-On the Dev Interrupted Podcast at 13:20

So rather than focusing on coding, then coming back in six months with a finished product, you get to have those high-level talks. What are your big pain points? What are the issues with your engineering flows? How might this tool or product reduce cycle time? Which can often be a lot more rewarding and enjoyable.

Check out the podcast

These are just some of the jobs that are available to you, once you know how to code. But if you’d like to hear more about what Peter talked about, listen to 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.

Discover Our Most Popular Podcasts
Join the Dev Interrupted discord

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.

Discover Our Most Popular Podcasts
Join the Dev Interrupted discord

Fact: Over 26% of adults in the United States have some sort of disability. To ignore such a massive part of the population would be ill-advised for any company, legally, financially, and above all, ethically. How can you stay ahead of the curve when it comes to maintaining a progressive and responsive organization? 

We reached out to two experts - Alwar Pillai and Perry Trinier of Fable – on the topic of designing products that have inclusivity for people with disabilities at their core. Here are the 3 things they think every engineer, developer and product designer needs to know about inclusive design and how it will inevitably affect the future of their companies.

1. Inclusive design has already brought us Alexa, Siri and countless other smart gadgets

Often times people assume that tech companies are driving innovation through focus groups or trying to cater to the average consumer, but that’s not always true. Some of the greatest recent innovations in tech have been found by designing technology to be as accessible as possible to people with disabilities. By keeping the designing process inclusive, you maximize potential for growth.

Alwar Pillai: Each of us today use technology that’s been designed for assistive technology users first, from as simple as an electric toothbrush, which is designed for people with motor impairments, but this is something that everyone uses now… you have voice to text was for people with disabilities again. And now we have... Siri, and Alexa, and like dictation, and all of that existed because it was designed for people with disabilities first, so it is already proven that when you practice inclusive design, and design for the edge cases, there is that broader impact.

2. Inclusive workplace culture draws in better talent

When you put inclusivity and accessibility at the front lines of your work culture and development process, you not only maximize your potential customer base but increase your pool of applicants and make your workforce more efficient. Some of the best talent in the world of inclusive design comes from people who use accessibility technology daily. Maximizing your accessibility to potential employees gives your company the best shot at finding the right person for the job. What does it mean today to build an accessibility first dev culture? 

Perry Trinier: I think it's like sort of the opposite of saying that accessibility is an afterthought. In this case, accessibility is absolutely primary. And it's also like a shared understanding on the team that accessibility isn't an extra feature or like a defect that they can backlog. It's just a table stakes dimension of the quality of what they build, and that they kind of aren't finished building what they're doing if it's still inaccessible.

Alwar Pillai: There's a lot of barriers when it comes to trying to build an inclusive team, to just the workplace tools that are out there, you know?... And so we've had to do a lot of... custom workarounds for some things. But it has resulted in every single person in the team understanding the impact of accessibility and taking that extra initiative and make sure whatever they're sharing with... each other internally is easily accessible to everyone.

3. Inclusive design’s influence is set to explode

There seems to be a cultural divide when it comes to inclusivity and many companies are hesitant to make the necessary changes to fuel a more accessible work culture. Making the effort to enact real change is necessary for the health of your business and the respect of the individuals who need accessible technology. More and more individuals and companies are seeing the need to stay current with inclusive design or, better yet, lead the way to establishing new and exciting ways to stay inclusive.

Perry Trinier: I think it's important to invest in helping the team members to build the knowledge and specifically set goals for reports to, for example, complete a course in accessibility. It's an important skill, just like security and performance are for front-end developers. And it should be treated in that same way for professional development. And there are tons of resources online courses on LinkedIn, Udacity. And there are lots of blog posts and talks by experts in the community like Marcy Sutton, and they’re directed to developers, like front-end developers who just need to learn what they need to know to be able to test their interfaces and to build experiences that everyone can use, so I would say that's the place to start is just with building up that capability.

Design is changing… Moving towards a more inclusive future

There is a fundamental gap in what is provided and what is needed for many people who use accessibility technology. The way of the future is to practice an inclusive design culture and keep every person in mind in your design process. 

Alwar Pillai: The way we build digital products right now is broken. There is a digital divide between the experiences of people with disabilities and people who are able bodied. And we as people who are part of engineering teams and engineering cultures, it's our responsibility to make sure we change the way we build products and make the process more inclusive, so that more and more people have access to the products that we're building.

If you want to know more about Fable and their ability to help your company evolve and grow while staying accessible to everyone, please visit www.makeitfable.com. Be sure to listen to and review this interview’s podcast and many others on Apple Podcasts, Spotify, Stitcher, YouTube or any of your favorite podcasting apps. Also, be sure to join the Dev Interrupted Discord community where we have conversations about topics just like this going all week long.

There is very little formal guidance for new engineering managers. When I first moved from an individual contributor (IC) to an engineering manager (EM), I found myself struggling to find training resources. 

I want to change that - and I hope this article will serve as a small start in that direction. As an engineering leader at Mark43, I do a lot of mentorship and coaching for engineers who aspire to move to engineering management and early-tenure engineering leaders. Here are a couple of initial focus areas that a first time EM can build upon.

Focus Area 1: Trust, Collaboration and Communication

As a new engineering manager, your first 90 days are crucial. You quickly realize the need to gain trust while rapidly building relationships and rapport -- not only with your colleagues and your direct reports, but also with all the other discipline stakeholders. As an engineer, you spend 80% of your time with your engineering team, focusing on the engineering aspects of your role. But in a management position, you spend perhaps 50% of your time with your fellow engineers. The other 50% of your time is spent with people who are stakeholders representing cross-functional disciplines such as product, design + UX or the QA department if there is one. 

In addition, there are other teams like people ops, recruiting, platform, customer support, customer success and deployments. Hence, you need to build relationships early on because to achieve collective success your team needs each discipline aligned to a common goal.

Focus Area 2: Information collection, compartmentalization and sharing

As an engineering leader, the amount of cross-communication and information that will be made available to you will rise exponentially. Whether that is pre-set routine meetings, ad-hoc situations or some form of change management – there will be a plethora of details that you will hear, will need to act upon or will need to pass around within your team. These new job duties  will become your day-to-day reality as an engineering manager.

To succeed, you should have a structured way to capture all the information that you are going to be exposed to throughout the day. Unlike pre-COVID times when in-person collaboration allowed us to get away with not thinking about some collaborative processes, you now need to be intentional about your remote organizational design to drive collaboration and communication. So for example, if you are in a one-on-one and you hear something of interest, you need to be able to make the connection that maybe this is something that I should bring to the wider group, or this is a follow-up item for me to take action upon later. You need to make sure that you are staying on  top of all your conversations.

 The takeaway here is that becoming an active listener is a crucial skill for an engineering manager. Being a good listener is not enough because the role of an EM is to surface key information both from your team and for your team. 

Being situationally aware is also important. This skill will help your future self when you need to recall something a day or week later. There are so many different people and so many different topics of conversation that occur everyday that it can be difficult to keep everything straight. I recommend keeping some sort of documentation or making an immediate action item list. This simple habit will pay dividends with time. There are lots of different note and action item taking systems - find the one that works for you.

To wrap things up, here is my simple 3-item checklist to improve your first 90 days as an EM:

  1. Observe and adapt vs be rigid and impose
  2. Build connections and gain trust early on
  3. Stay technical but do not spend a lot of time implementing technical solutions

If you keep this checklist in the front of your mind as well as keeping your eyes and your ears open, you will excel at being an EM. A good EM understands that their measure of personal success is their ability to foster team success - and team success is only possible with trust, collaboration and communication. 

Join the Dev Interrupted Community

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

Dev Interrupted Discord, the new faces of engineering leadership

If you want to learn from some of the best engineers and engineering minds in the business, register for INTERACT: the community-driven, digital conference designed by engineering leaders, for engineers leaders. This single day conference will feature 10+ speakers, interactive sessions and a community built by 100’s of engineers and engineers leaders, all for free. 

In our rapidly changing technology landscape, it can be difficult to maintain a competitive advantage. Challenges present themselves daily and staying ahead of your competition can feel daunting. At the INTERACT conference for engineering leaders on September 30th, we’ll be exploring two of the most impactful ways that have emerged for companies to differentiate themselves - streamlining engineering processes and maintaining high developer velocity.

These drivers of success make companies more innovative and productive while enhancing team performance and alignment, and two of the key talks at INTERACT focus on solving these challenges:

Both of these talented individuals will be appearing at INTERACT on September 30th to share why engineering processes and developer velocity are critical to business success.

Let’s take a quick look at what these two will be presenting.

A sneak peak at Maria’s viewpoint on streamlining engineering processes

At its core, an organization is nothing more than a collection of moving parts. A combination of people and resources moving towards a common goal. Delivering on your objectives requires alignment at the highest levels - something that becomes increasingly difficult as companies scale.

Growth increases team sizes creating more dependencies and communication channels within an organization. Collaboration and productivity issues can quickly arise in a fast-scaling environment.

It has been observed that adding members to a team drives inefficiency with negligible benefits to team efficacy. This may sound counterintuitive but is a result of the creation of additional communication lines, which increases the chance of organizational misalignment.

The addition of communication lines brought on by organization growth also increases the risk of issues related to transparency as teams can be unintentionally left “in the dark.” This effect is compounded if decision making is done on the fly, especially if multiple people are making decisions independent of each other.

In order to maintain overall business alignment, clarity and structure, the implementation of business processes becomes necessary. By defining these processes, your organization will be able to thrive as it scales, unburdened by its own growth as if it were still a small startup.

In effect, processes allow us to codify our success, providing us with systemic and scalable ways to repeat behaviors that lead to success and avoid past mistakes.

The processes that help scale engineering organizations, the implementation of these processes, the effect of these processes, and the 3 most important processes for scaling, will be shared by Maria during her discussion with me at INTERACT.

An excerpt from Henrik’s talk

In early 2020 Microsoft conducted an exhaustive survey of over 400 of the largest companies around the world. The goal was to understand the impact of developer velocity on business performance. A follow up to this survey was then performed in May of 2021 to validate the findings of the original survey.

They found a direct correlation between high development velocity and business impact. The business impact of developer velocity was substantial. Companies with the highest velocity had 4 to 5 times higher profit margins than the companies with the lowest velocity. The companies with high velocity were also more innovative and productive.

The first survey attempted to capture the best overall picture of drivers of velocity. While the second survey sought to identify the impact of Covid on developer velocity and whether or not the shift to remote work impacted the findings of the initial survey.

Companies that were successful in both surveys shared several key similarities. Chief among them were technological updates and organizational practices such as:

Henrik and Dev Interrupted Community Leader Conor Bronsdon will be diving into all of Microsoft’s research findings into developer velocity - and what engineers can learn from these findings - during his presentation at INTERACT.

INTERACT: September 30th, 2021

If you want to learn from some of the best engineers and engineering minds in the business, register for INTERACT: the community-driven, digital conference designed by engineering leaders, for engineers leaders. This single day conference will feature 10+ speakers, interactive sessions and a community built by 100’s of engineers and engineers leaders, all for free.

Not only will you have a chance to have access to Maria and Henrik’s research but also to other brilliant engineering leaders like:

Don’t miss your chance to learn from these great engineering leaders. We look forward to seeing you on September 30th, remember to save your seat!

Register now for INTERACT

Join the Dev Interrupted Community

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

Dev Interrupted Discord, the new faces of engineering leadership

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

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

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

Here are 5 of their most inspiring lessons:

Always be delegating

Brendan Burns, Corporate Vice President at Microsoft

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

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

Remote first, not remote friendly

Shweta Saraf, Senior Director of Engineering at Equinix

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

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

Leadership with empathy

Ben Matthews, Director of Engineering at Stack Overflow

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

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

Comparison leads to unhappiness

Kathryn Koehler, Director of Productivity Engineering

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

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

Avoid meetings

Darren Murph, Global Head of Remote at GitLab

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

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

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

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

Listen and subscribe on your streaming service of choice today.

Discover Our Most Popular Podcasts
Join the Dev Interrupted discord

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

Dev Interrupted Discord, the new faces of engineering leadership

 

Three phases of a controlling engineering manager

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

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

How much control is the right amount of control?

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

A bit of context… 

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

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

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

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

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

My three phases of controllingness 

Phase 1

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

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

Phase 2

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

Phase 3

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

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

Phase 2 is just as bad as Phase 1 

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

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

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

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

Engineering metrics - a tool for good and evil 

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

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

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

 

What do non-managers think about all this? 

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

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

Join the Dev Interrupted Community

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

Dev Interrupted Discord, the new faces of engineering leadership

Stay in the loop!

Sign up for our weekly newsletter