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

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

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

1. Humanize Interviews

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

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

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

2. API for Humans

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

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

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

3. Can a Dev Manager Be Non-Technical?

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

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

4. Bringing Your Full Self to Work

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

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

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

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

5. Metrics

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

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

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

6. Burnout

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

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

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

Humanizing Means Performance

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

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

A 3-part Summer Workshop Series for Engineering Executives

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

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

This article is based on an interview with Kubernetes co-founder Brendan Burns who appeared on the Dev Interrupted podcast.

The success of Kubernetes was never preordained - it took years of work.

While today it has grown to be one of the largest and most popular open source projects and become the go-to API for building cloud-native applications worldwide - it almost wasn’t even open source. 

Since its start in 2014, Kubernetes (an open-source orchestrator for deploying containerized applications) has transformed from a tiny project co-founded by three people, Joe Beda, Craig McLuckie, and Brendan Burns, into a production-grade infrastructure that powers large-scale production applications in various fields, from machine learning to online services. 

Created with the intent to simplify the task of building, deploying, and maintaining distributed systems, it allows people the world over to achieve new levels of velocity, agility, and reliability. Over the years, Kubernetes has grown into a large, successful open-source community - but it was a long journey getting there.

What is a container?

Before jumping into the history of Kubernetes, let’s first define a “container” because it often has a broad set of meanings. 

Fundamentally, a container is the process of taking an application and packaging it, building a binary representation of the pieces that make up that application like the software, configuration files, etc., and having a protocol for distributing it around the world. 

There are three pillars of what became known as containers: 

How it started

When we interviewed Kubernetes co-founder Brendan Burns on the Dev Interrupted podcast, he told us that as an engineer, he found himself gravitating towards spaces with opportunity. While working at Google, he noticed that Cloud had a lot of white space and thought it would be an attractive space to work in. At the time, he led a small team of about seven engineers and decided to transition his team over to Cloud. 

At the same time, his eventual Kubernetes co-founders Joe and Craig created Compute Engine, the virtual machine product for Google Cloud, and the three of them began to work together in Google’s Cloud division. While Joe and Craig focused on compute, Brendan worked in config management on things like CloudFormation and Terraform. 

Ideas were starting to coalesce, and the three of them were witnessing the challenges people faced trying to adopt Cloud - a far too difficult process. There were also some internal systems at Google, in particular a system called Borg, a cluster manager that’s still used today, that served as the initial inspiration for the three developers as they dreamt up Kubernetes. 

However, none of it would have been a reality without Docker.

Docker changes everything

As a prerequisite to the functionality of Kubernetes, people needed to be motivated to build container images and run containers. Docker was the startup that came along and convinced people why they should care about containment. All of a sudden, a use case existed, and an amazing opportunity presented itself. 

Docker didn’t have a lot of experience at scale, and they were focused on one machine, with a container and daemon on that machine - what they were lacking was orchestration. If a system was built that could act as a container-orchestrator, it represented not only a massive opportunity to change the market but to change the entire cloud landscape. 

When you think about what it takes to deploy an application up to the cloud or even to an on-premise collection of machines, it’s a lengthy process. It requires you to package up an application, distribute it, keep it running, have load-balanced traffic between the various pieces of the application, and an API to tie it all together. 

Prior to Kubernetes, some of these systems were in place, but nothing like today. Kubernetes is responsible for mainstreaming the idea of a distributed systems application environment for building and constructing distributed systems that span machines far and wide.

With the need for orchestration realized, the next step was selling the idea to executives.

Selling open source

Convincing people that it was possible and a good idea was pretty straightforward. There were folks at Google who understood what Joe, Craig, and Brendan were trying to do. The real battle was fighting to make Kubernetes open source. As Brendan shared in our interview, they had a lot of internal arguments at Google about it being open source. 

Mostly it came down to money and control. From a business perspective, if a product or system is massively successful and you’re the only one who can sell it, then you’re in a great position. Conversely, Brendan told us that he always felt that Kubernetes would only be massively successful if it had an ecosystem, and the best way to foster an ecosystem was to make it open source. 

This viewpoint is centered around the community that comes together to build the software. An amazing community formed early on of people who helped build docs, who helped build tutorials, who would talk about their work at conferences, and then an ecosystem of companies that were betting their whole business on the success of Kubernetes. Startups began popping up, saying things like, “Well the prerequisite for using my monitoring software is that you have a Kubernetes cluster.” All of the attention and goodwill formed a sort of virtuous cycle around Kubernetes.

Success has a way of looking easy

Soon enough, Kelsey Hightower, principal engineer for Google Cloud and Brendan’s co-author of the book Kubernetes: Up and Running: Dive into the Future of Infrastructure, came along and started doing a ton of evangelism and driving attention towards Kubernetes

It can be easy to look back and assume that it was easy, because Kubernetes just took over. It's present in every major public cloud at this point, people expect it to be in new systems. But the truth is that in those early years, it took a lot of hard work to build and evangelize Kubernetes. 

Brendan shared with us that his hope for the future is that the bits of Kubernetes sort of fade into the background. It’ll be there, and it’ll be important, but it won’t be talked about or thought about from day to day because, as he puts it, “There’s so much more that needs to be built.”

Thanks for reading! If you want to stay up-to-date with what top engineering leaders are thinking about, subscribe to the Dev Interrupted Substack.

You'll get access to weekly articles, podcasts, and news from the best engineering leaders in the industry. Enter your email below to subscribe and be a part of our growing community!

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: 

  1. People: Are people happy and growing in what is being built? 
  2. 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. 
  3. 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. 
  4. 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. 
  5. 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. 
  6. 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. 
  7. 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.

Managing by Missing from Ian Nowland

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.

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.

Discover Our Most Popular Podcasts
Join the Dev Interrupted discord

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.

Discover Our Most Popular Podcasts
Join the Dev Interrupted discord

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! 

If you’re a developer, or a developer team lead, this article offers you actionable insights from a research study conducted by McKinsey & Microsoft that delves into the relationship between Developer Velocity and fundamental business outcomes, such as revenue growth, operating margins, and how quickly a business can innovate.

Microsoft worked with McKinsey on this study to further our understanding of the critical role that developers play in the success of organizations around the world. As a company that deeply understands the impact of developers, we’re excited to share these results, and hope the findings will grab the attention of senior business leaders. Our message for them is simple: orienting your organization to prioritize and empower the success of developers is a decisive competitive advantage.

Before we dive into the results, let’s take a moment to define Developer Velocity. This terminology refers to the pace at which a team of developers can deliver innovative software that is loved by end users. Developer Velocity goes well beyond the simple pace of delivery though. It’s about helping business leaders understand the value of providing world-class developer tools, structuring working groups to promote autonomous productivity through Agile and DevOps practices, and incentivizing innovation through a culture that fosters psychological safety.

The Developer Velocity Index (DVI) was created for this study as a quantitative measure to enable a comparison of Developer Velocity at 400+ global companies. The next step was evaluating the impact of Developer Velocity on business outcomes that matter to every senior business leader. In short, the research study demonstrates that companies scoring in the top 25% of the Developer Velocity Index experience 4-5x faster revenue growth, 20% higher operating margins, and 55% higher levels of innovation.

Top 5 Drivers of Developer Velocity

While the results of the full research study are intriguing, for the sake of brevity, let’s focus here on the top 5 drivers of Developer Velocity. And if you’re interested, you can find all the details of this research through the “Learn More” links provided at the bottom of the article.

#1 Developer Tools

Organizations in the top quartile of Developer Velocity invest in developers by providing access to world-class developer tools. Specifically, these companies provide developers with a flexible choice of integrated developer environments (IDEs), collaboration software, and continuous integration and delivery (CI/CD) tools that support each stage of the software life cycle. Another common tendency among top companies is enabling non-developer employees to create applications through low-code and no-code platforms, thereby protecting the time of their software engineers to focus on more challenging tasks. The rewards of these investments become obvious when you consider that these top 25% of companies achieve developer satisfaction and retention rates that are 45% higher than the bottom 75% of companies.

#2 Organizational Culture

The most critical cultural attribute shared by the top 25% of companies is creating an environment of psychological safety. This means establishing a shared belief that incentivizes risk-taking through experimentation and embraces failure through learning and knowledge sharing. This approach fosters innovation and continuous improvement, which becomes particularly effective when paired with a customer-centric philosophy. These top companies also frequently recognize the efforts of their developers, taking the time to publicly acknowledge and reward individual and team achievements.

#3 Product Management

Highly effective product management is a differentiator that’s increasingly valuable for the top 25% of companies. Along with managing budgets and project timelines, the role of a product manager focuses on delivering a compelling experience for end users. This job function requires a unique blend of business acumen, technical understanding, customer experience, and interpersonal skills that are necessary to deftly influence others towards desired outcomes. Hiring, training, and retaining skilled Product Managers should be treated with the same strategic significance as finding the right developers for your team. The most successful teams of developers also embrace a mindset wherein they take turns stepping into the shoes of the Product Manager to better understand the problems facing their end users and the solutions they can develop to address those challenges.

#4 Developer Experience

Best-in-class organizations do the best job of hiring, incentivizing, educating, and retaining talented people by deeply considering their internal developer experience. It begins by recruiting top developers with a compelling value proposition to join the team and continues by building programs that support continuous learning and set clearly defined career paths. Another critical step is structuring the organization around smaller developer teams to prioritize autonomy, loosely coupled architecture, and the implementation of Agile and DevOps best practices. Finally, introducing formal processes that encourage transparent dialogue and measure team health through regular surveys create an important feedback loop for the organization to listen to their developers and understand how to improve their experience.

#5 Open-Source Software

Companies in the top 25% of DVI that adopt open-source software and encourage their developers to contribute to open-source observe three times the impact on innovation compared to the organizations in the bottom 75%. Here we learn that embracing an open-source mentality has a significant multiplying effect on innovation for companies that are already leaders in Developer Velocity. And it should be reinforced that embracing open-source means adopting open-source software, motivating employees to contribute to open-source communities and projects, and adopting a similar internal sharing philosophy that is commonly referred to as InnerSourcing.

I hope this article has inspired ideas that you can bring back to your role as a developer, or developer team leader. Below are links to the full research study by McKinsey, along with a short-form (5 Questions) and long-form (10-15 Minutes) assessment tool with results from each that provide actionable guidance to help you accelerate the Developer Velocity of your organization.

Learn More:

Join the Dev Interrupted Community

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

Dev Interrupted Discord, the new faces of engineering leadership

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

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

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

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

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

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

What is a "senior" developer?

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

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

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

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

Being good at your job doesn’t make you senior

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

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

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

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

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

Experience isn’t everything

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

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

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

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

Where are we today?

Now that we have recapped, where are we today?

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

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

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

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

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

A real-life example

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

What they said next completely blew me away:

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

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

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

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

There’s no replacing good fundamentals

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

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

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

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

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

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

Join the Dev Interrupted Community

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

Dev Interrupted Discord, the new faces of engineering leadership
 

Managing the software development process has been likened to herding cats. In other words, you can’t really do it, but you can sure give it the old college try. 

It’s no secret that managing the development of a software project is an imprecise science. Here are nine truisms that I’ve learned over the years that have helped me to understand the limitations of our ability to manage the strange world of software development projects.

1. Estimates Are Always Wrong

Whether you estimate something at one hour or one year, your estimate is wrong. That’s just the way it is. They won’t necessarily be extremely wrong — they might only be a little bit off — but they will be wrong.

If you look at a bug report and think, “That will take an hour to fix,” it almost certainly won’t take an hour. It might take 45 minutes, it might take three hours, but the chances of it taking exactly an hour — even give or take a minute or two — are slim. Now, you might say, “about an hour” instead. That’s a better estimate because actual, precise estimates are wrong.

Now for short projects that might take an hour, this isn’t a big deal. But…

2. The Bigger the Project, the Less Accurate Your Estimate Will Be

The bigger the project, the less precise the estimate will be — especially if estimation takes place at the very beginning of the project. As with the hour estimate above, if you estimate a project at a year, it might take nine months or 36 months. In some cases, it might take five years. There is no way to know when the project is starting out.

The bigger the project, the more “unknown unknowns” there are. There are usually more people involved. That is, as a project’s size increases, there are more variables and more things that will happen that you cannot anticipate. All of these things will add time to the project that you can’t plan for at the beginning because by definition you don’t know that they are going to happen.

3. Focus and Concentration Are Our Most Valuable — and Scarcest — Commodities

When building software, the single most valuable thing required to complete a project is the ability of the developers on the team to concentrate in an undistracted manner.

The fewer distractions, the more productive the team will be. It’s really that simple. One of the main responsibilities of a software development manager is to reduce the number and duration of distractions to the team.

Software developers, when left alone, can be quite productive. When they are interrupted — whether for meetings or by people asking questions or anything else — they can lose that productivity very quickly. We all know about “flow” and how hard it is to get into the flow and stay there. That flow time should be valued like bitcoin and protected as such.

4. Hofstadter’s Law Is the Truth

Hofstadter’s Law is stated as follows:

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.” — Wikipedia

This is related to estimates, but it’s important to note the beauty of this aphorism. You can pad your estimates because you think it will help buy you time to get things done. You can add in extra factors, plan for “unknown unknowns,” and increase your estimates to take into account the belief that it will take longer than you think, but in the end, it will still almost always take you longer than you think to get a project done.

5. You Can Only Run in the Red for Very, Very Brief Periods

You can demand the team put in more hours, come in on weekends -- all those “crack the whip” kinds of things -- and you might get some (very) short-term gains out of that.

But if you try to make it the norm — if you try to run your team's engine at the red line of RPMs on a consistent basis — you will burn out the engine. You will see diminishing returns pretty quickly. Employees will leave. People, like race car engines, cannot be overstressed for extended periods of time without breaking down.

6. Brain Time Is More Important Than Butt Time

This one is so important, I wrote a whole blog post about it.

Nothing will decrease productivity more than demanding Butt Time (i.e. that your developers be seen sitting in their chairs for hours on end). You can measure Butt Time and feel like you’ve got a metric that will really show how productive people are being. But you’d be wrong. Demanding Butt Time will demoralize a team that really wants to spend Brain Time.

Brain Time is what really matters. Think about it this way: Let’s say you are a manager and it is most important for you to see your team sitting at their desks “working.” You wander around the office seeing those developers sitting in their chairs, pounding away at their keyboards. All is well with the world.

But then you run across one developer, and they’re just sitting there staring at their screen. That’s it. They’re sitting and staring. For like half an hour. What the heck! They’re not doing a thing!

But of course, they are. They’re thinking. They’re spending Brain Time solving a very difficult problem. Maybe they even get up and wander around the building for a while. In the end, they sit down, type 11 lines of code, and mark a user story complete.

Did they meet your “Butt Time” criteria? No. Did they produce an elegant solution to a very difficult problem? Yes.

Butt Time proves nothing. Brain Time means everything.

7. Hardware Is Cheaper Than Developer Time — Way Cheaper

Developers are expensive. You pay competitive salaries to attract top talent. An hour of their time is not cheap. Despite this, many companies don’t realize the incredible value of an hour of a developer’s time and skimp on hardware for the team.

But come on, computers are expensive! That extra RAM will bust the budget for hardware!

Well, it might bust the budget, but that’s because you’ve got a budget problem.

Look at it this way: Let’s say that you pay a developer $100,000 a year — or around $50 an hour. Let’s say they spend an hour a day waiting for the compiler to do its work. However, you could add some RAM and a faster processor to that developer's machine and cut that time down to 45 minutes a day. You save 15 minutes a day. At 200 days a year, that is 50 hours. At $50 an hour, that is $2,500 saved per developer per year. But what if the incremental cost of the faster machine is $500?

You get the point. If you have 20 developers, getting the faster machine saves you $40,000 for a $10,000 investment. That ought to be a no-brainer.

And that is only for the faster compile times. Everything else they do will be faster as well.

If your budget doesn’t allow for faster machines, then you need to adjust your budget.

8. If You Haven’t Read “PeopleWare”, Then You Aren’t Really a Software Development Manager

As far as I’m concerned, there is but one book that will teach you how to manage software developers: Peopleware by Tom DeMarco and Timothy Lister (be sure to get the third edition…).

This book is excellent, insightful, to the point, clear, and pulls no punches. It is full of wisdom about managing software projects and software developers. It is timeless.

Read it.

9. Quality Is a Perception — Not a Bug Count

This one is really hard to accept.

Here’s the basic premise: You can have close to zero bugs in your bug tracker and people can still think your software is buggy. You can have a large number of bugs in your bug tracker and people can think your software is as solid as a rock. There’s no correlation between the number of bugs in your tracking system and the perception of the quality of your software.

Now I’m not arguing that you shouldn’t try to reduce your bug count — quite the contrary. But in the end, your software can only be said to be of high quality if your customers perceive it that way — and your bug count won’t necessarily dictate that. Weird, huh?

And while we are on the subject, what does it mean to have a “high” bug count? What is the definition of “high” when your codebase has 100,000 lines of code? 5 million lines of code? Who’s to say?

Embrace Flexibility

Bringing a software project in for a safe landing on a short runway is a challenging and difficult proposition under the best of circumstances. Add in the ambiguities and all the things that can go wrong along the way, and it’s a miracle anything gets done. Development managers need to be flexible and take things as they come

The trick is to accept and understand those ambiguities and to work with them — not against them. Accepting these nine truisms will help with that.

Sponsored by LinearB

Want to reduce a lot of that ambiguity?  LinearB can closely track what is happening in your software pipeline, enabling more brain time, and automating things that require butt time. 

Book a demo today and find out how you can drastically reduce your code delivery times and continuously improve your development process.

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