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.

The Weekly Interruption is a newsletter designed for engineering leaders, by engineering leaders. We get it. You're busy. So are we. That's why our newsletter is light, informative and oftentimes irreverent. No BS or fluff. Each week we deliver actionable advice to help make you - whether you're a CTO, VP of Engineering, team lead or IC  - a better leader.

It's also the best way to stay up-to-date on all things Dev Interrupted - from our podcast, to trending articles, Interact & our community Discord

Get interrupted.

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.

The Weekly Interruption is a newsletter designed for engineering leaders, by engineering leaders. We get it. You're busy. So are we. That's why our newsletter is light, informative and oftentimes irreverent. No BS or fluff. Each week we deliver actionable advice to help make you - whether you're a CTO, VP of Engineering, team lead or IC  - a better leader.

It's also the best way to stay up-to-date on all things Dev Interrupted - from our podcast, to trending articles, Interact & our community Discord

Get interrupted.

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

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

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 enjoyed this article and you would like to learn more about the work that I do at Netflix, I invite you to come join me at INTERACT on April 7th

This will be the second time that I have sat down for a panel discussion hosted by Dev Interrupted. I love being a member of the Dev Interrupted community because they are such an amazing resource. If you are a team lead, engineering manager, VP or CTO looking to improve your team, come to INTERACT and check out the community - I promise you will learn something.

Pretend you are watching your favorite show on Netflix: Sit back, relax & watch as I share the stage with other amazing engineering leaders from places like Slack, Stack Overflow, American Express, Outsystems, Drata & many more.

>Register Here<

A good SRE engineer will tell you your service is never down. A great SRE engineer will tell you that’s not what you should be measuring. In fact, they’ll tell you their job is customer service. 

Site Reliability Engineering (SRE) has grown immensely popular with many of the world’s largest tech companies, like Netflix, LinkedIn and Airbnb employing SRE teams to keep their systems reliable and scalable.

Along the way, SRE engineers have become one of the most sought after engineering roles in tech. 

The role is traditionally understood as ensuring that services are reliable and unbroken, but reliability and uptime aren’t perfect metrics. Perhaps what organizations should be asking themselves is what their customers think of their service. 

Wandering down to your engineering department and asking your SRE team about customer satisfaction is a good place to start. 

Their answer just might surprise you. 

History of SRE

In practice, Site Reliability Engineering has been around for a while. In the past its functions were covered by roles that had names like production ops, disaster recovery, testing or monitoring. The rise of cloud computing facilitated a need for more engineers in production. The complexity only grew as more organizations transitioned from monolithic infrastructures to distributed microservices. 

Modern Site Reliability Engineering originated at Google in 2003 with the work of Benjamin Treynor, who is seen as the “father” of what we now simply call SRE. Treynor, who coined the term, was a software engineer placed in charge of running a production team. With the goal of making Google’s website as reliable and serviceable as possible, he asked that his team spend half their time on operations tasks so they could better understand software in production. This team would become the first-ever SRE team.

Ben Treynor said, I'm paraphrasing, ‘[SRE] is essentially like throwing a software engineer at an operations problem’, right? Because you come from that developer mindset, that design and, you know, you think about all of these things. So think about it as a developer but apply it to an operational type of problem.” - Brian Murphy on the Dev Interrupted podcast at 4:26

Why not uptime?

So why shouldn't you be too concerned about your uptime metrics? In reality SRE can mean different things to different teams but at its core, it’s about making sure your service is reliable. After all, it’s right there in the name. 

Because of this many people assume that uptime is the most valuable metric for SRE teams. That is flawed logic. 

For instance, an app can be “up” but if it’s incredibly slow or its users don’t find it to be practically useful, then the app might as well be down. Simply keeping the lights on isn’t good enough and uptime alone doesn’t take into account things like degradation or if your site’s pages aren’t loading. 

It may sound counterintuitive, but SRE teams are in the customer service business. Customer happiness is the most important metric to pay attention to. If your service is running well and your customers are happy, then your SRE team is doing a good job. If your service is up and your customers aren’t happy, then your SRE team needs to reevaluate.

A more holistic approach is to view your service in terms of health. 

The Four Golden Signals

As defined by Google, these are the four golden signals of SRE. If these can be managed effectively, then you probably have a healthy system. 

Establishing system health

“The best way to get started is just measuring stuff, you know, just getting the baseline of what's healthy, what's not healthy, what looks like health, and then you can start working from there.” - Brian Murphy on the Dev Interrupted podcast at 10:49

It can be difficult to know whether or not your organization should consider forming an SRE team, or what your next steps are if you’ve already made the decision. 

Again, think of your decision in terms of a holistic approach, not just your uptime. If you have high uptime, that’s fantastic, but what you should be establishing is a benchmark. 

Using the four golden signals to guide you, establish what you think a healthy system should look like and set your benchmark. Keep measuring over time and you will begin to see the areas that are good or require more work. 

These measures will help inform all of your future decisions. Perhaps your organization is ready to roll out new features or make choices around expanding your service. 

Critically, the health you establish provides insights into customer happiness. If things look good you probably have happy customers. 

Internal customers

When done right SREs aren’t just making customers happy, they’re making the lives of developers easier too. Nothing is worse than having to stop because there’s a problem in production. Good SRE teams can shield dev teams by focusing on major hotspots.

If the fires are being managed before they are out of control, it allows developers to keep pushing out features. It even gives them the freedom to keep breaking things, if necessary!

When things do break, or require a slowdown, a dialogue can occur. A good SRE understands that the developer who wrote a piece of code understands it better than anyone. The model for good internal customer service is an SRE who brings in a developer, gives them ownership of the code they created, and offers to help them fix it.

Happy customers are the best customers

Whether you already have an SRE team or are thinking about forming one, remember to think beyond the engineering - think about the customer. 

Ask yourself if your customers are happy and if you would describe your service as healthy. Remember to think about your own teams as well, your developers will thank you for it. 

_____________________

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is based on an episode of 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.

 

Continuous Delivery isn’t about how fast you can deliver, it’s about the outcome your delivery achieves. Bryan Finster, author of the 5-minute DevOps series and founder of the DevOps Dojo, joined our Dev Interrupted Discord community to answer your questions about outcome-based development, continuous delivery, and why failing small is better than failing fast. 

Bryan is currently a Distinguished Engineer at Defense Unicorns but has also worked for Walmart as a systems analyst and eventually became a staff software engineer for Walmart Labs. He had previously appeared on the Dev Interrupted Podcast to further talk about these subjects as well as the most common pitfalls dev teams find when trying to optimize their delivery process. Listen to the episode here:

This Community AMA took place on January 8, 2021 on the Dev Interrupted Discord.

Necco-LB: 📢📢 Community AMA📢📢   @everyone 

Topic: Outcome-based Development with @BryanF (Bryan Finster)

Bryan, thanks for joining us today!

Bryan Finster: Thanks for having me!

col: Bryan... great quote. "A developer is a business expert who solves problems with code." Thank you. Tremendous concept.

Bryan Finster: Thanks. That's who we are. We aren't Java spewing legos. If we don't understand the business, the code won't.

Rocco Seyboth: YES!! @col Love it. @oriker says "a business decision is made with every line of code"

Bryan: Exactly. How does this change improve the bottom line. Even more, how does it improve the lives of our customers?

Necco-LB: We really enjoyed having you on the podcast to talk about Outcome-based development and what continuous delivery should be trying to achieve. I was hoping you could explain to use what Outcome-based development means?

Bryan: It's just focusing on the outcomes. It's pointless to focus on how we do things if the outcomes are poor. It's also about Hypothesis Driven Development. The act of defining the expected value before we attempt to deliver it and then measuring for that value. Instrumenting the application to see how close we get so we can adjust. I frequently see people just being feature factories, pounding out changes that no one needs. That just costs money and increases support. We should be deliberate about what we do and say "no" when the value isn't obvious.

Cocco: When it comes to delivering value to the customer sooner, what things do you commonly see teams worrying about that they perhaps shouldn't (or not worry about, when they should?)

Bryan: "I can't release this! It's not feature complete!" No, get the incomplete change out there and make sure it doesn't break anything.

Necco-LB: You mentioned during the podcast that Pride is the best metric ever. Can you explain that a little bit?

Bryan: If I own the business problem, own the solution, own how to make it better, own the outcomes and see people getting value from my work, then I have pride in what I do. I want it to be good. I want it to be secure and stable and I want to continuously improve it.

Necco-LB: When you talk about outcome-based development you often talk about the things that need to happen before hands touch the keyboard. What are some of those things?

Bryan: We need to understand the value we are trying to deliver and we need to define how we expect to deliver that value at the detail level. It's not enough to write a vague user story. We need testable outcomes that we agree should deliver that value. Behavior Driven Development is the most effective tool I've found for that. We also need to make sure we aren't trying to deliver ALL of the value at once. What if we are wrong? We usually are, statistically. So, what is the smallest, highest value thing we can deliver to find out? Sometimes the right answer is to stop at that point. Invest in the outcomes, not the plan or the work.

_____________________

Read the unedited AMA and join in the discussion in the Dev Interrupted Discord here! With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. Join the community >>

Dev Interrupted Discord, the new faces of engineering leadership

_____________________

Cocco: What patterns/trends do you see in teams who can deliver the outcomes they want? (Are there common factors in teams you've seen that move from struggling -> successful?)

Bryan: Yes. Actual continuous delivery and product ownership. They can deliver small changes daily and they have ownership of what those changes are. They have the safety to challenge things without fear and they are not pushed so hard that there is no time to think of better ideas. Software development is a mental activity, not typing.

Necco-LB: You work with a lot of different teams at the DevOps Dojo. What are some of the most common pitfalls preventing a team from optimizing their delivery process?

Bryan: They are given the wrong problems to solve. They are asked to solve stupid problems like "how many changes did you make today?", "How many stories did you complete this sprint?", They don't know how to work as teams because they are incentivized to work in silos. So, requirements are poorly defined, testing suffers, speed suffers. They need to be solving the business problem. What is measured will change. Be careful what and how you measure.

Necco-LB: What are some first steps a team can take if they want to become more outcome focused?

Bryan: Focus on the business problem and get close to the user. Empathize with them and what value they need. This really applies to anything. If you don't respect your customer, you won't need to worry about them for very long.

Necco-LB: What is the role/responsibility of the developer in this outcome-based development model?

Bryan: On a good development team you have engineers and product ownership. Engineers ship working solutions. They know they are working because they tested them, delivered, them and observed that their tests were accurate.

Rocco Seyboth: In 5 Minute DevOps you talk about observing what high performing teams do then modeling other teams to the same process and behavior... how do you reconcile that with the belief that every team is different and should have the flexibility to do things their own way?

Bryan: Actually, I advocate against cookie cutter templating of teams in that post. We should standardize on improving outcomes.

Necco-LB: Friends, that's just about the top of the hour. Bryan has a real job that needs to get done, but feel free to keep the questions coming asynchronously throughout the day - he'll be popping in and out to answer them. Bryan - thank you so much for joining our community today and answering our questions!

Bryan: Just some contact links to leave and I want to thank everyone for the conversation. I love talking about these topics.
https://www.linkedin.com/in/bryan-finster/

https://bdfinst.medium.com/

_____________________

Starved for top-level software engineering content? Need some good tips on how to manage your team? This AMA is based on an episode of 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.

Dan is the founder of Tellspin, an on-call scheduler in Slack for DevOps and developers (https://tellspin.app). Helping workspaces reduce their contact footprint, resolve incidents faster, and regain deep focus.

Code smell is a way to describe code that hasn’t aged well and has the potential for a lot of issues.

It usually is the source of a lot of hot fixes or workarounds keeping it functional. My most common reflex is to rewrite it. However, if I’m not careful, I’ll waste an entire day and not improve anything.

After a decade of programming, here are my 7 steps to reduce code smell gradually.

Step 0: Admit there is a problem

I start to recognize my code is smelly when I start saying things like “that time only took an hour.”

I’m usually doing something simple, like adding another field to a form or another schedule for a customer. I quickly add in code because it feels like the easiest thing to do and ship the feature. There are so many other things on my plate, I don’t have time for this, I’ll say to myself.

By the 5th or 6th hour I’ve hacked the same spot, I realize, had I rewritten it sooner, I would have actually saved time. 

Step 1: Identify spots to clean

Smelly code is so disorganized.

Is it really smelly or do I just not understand it? It’s very tempting to always default to a rewrite. If I write all the code, I’ll understand it. But who is to say the next person who looks at it will?

Similar to profiling code to identify the slowest spot, I work to identify the place that smells the most. Are there sections of the code that new devs are always struggling with? Are there frequent small changes that require touching lots of different files or methods?

Creating a list of smelly code helps identify which sections of code need the most attention.

Step 2: Pick the worst spot

Smelly code is like dirty dishes.

With a stack of dishes, I’ll plug my nose until I dispose of the rotting food that’s causing the stink. It was easy to blame the whole pile, but for the most part, all of the other dishes are fairly clean. They don’t need immediate attention. The rotting smell came from something I forgot to clean off when I was in a hurry.

When there is a piece of code that’s really rotten, it’s often hidden somewhere in the pile. Maybe an abstraction went too far, spreading a hundred lines of code across dozens of files.

I keep in mind that I need to fix the worst smell; most of the other code is good enough and doesn’t need my immediate attention. 

Step 3: Resist the urge to do everything

Smelly code is never-ending.

Perhaps the hardest part of improving a code base is scoping it to one thing. It’s so liberating to finally get a chance to clean up, that I can easily take it too far. I’ll think, “While I’m at it, I might as well clean up this… oh! and that other thing needs fixing too.” 

Resist! Do not do everything. 

If I try to tackle everything, I’m not going to finish. Even more likely, it’s not going to pass code review. It’s better to do one piece at a time - ya know, like eating an elephant. 

Step 4: Make sure it’s better

Smelly code has edge cases.

Inevitably, in the process of rewriting, I discover why the code was written that way in the first place. I might even stumble across a can of worms. At that point, I realize my not-so-dimwitted co-worker wasn’t as dumb as I thought (or even more likely, I discover I was the one who wrote the code originally 🤦‍♂️).

 After learning all the edge cases, I’ll be tempted to walk away.

Step 5: Don’t immediately give up

Smelly code is messy to work with.

I’m frustrated imagining how far away the current code is from a better solution. I’ve got the code in my head, I know the edge cases, and I’ve got the context. It’s important not to give up as the solution may be right around the corner.

I keep thinking about it while I go for a walk. Maybe even take a break. Solutions often come to me while I’m on walks or in the shower.

Step 6: Use the co-worker bobblehead

Smelly code needs attention.

I steal my co-worker’s bobblehead and explain aloud what I’m doing. In the process, I figure out what I've missed or overlooked. 

If a bobble head isn’t available, I resort to using my actual co-workers. (I’m checking my assumptions by walking them through what I’m thinking step by step.)

Step 7: Publish or throw in the towel

Smelly code can improve.

At the end of my steps I have a complete solution or I’m banging my head on the keyboard. If it’s the first, I push the change and take a breath of fresh air. If it’s the second, I commit it to a branch and plan to revisit another day. Sometimes we can’t have nice things.

Rinse and repeat

The depth I go into each step changes based on complexity or how critical the code is. Sometimes I can run through each of the steps in a few minutes, other times it’s spread out over a few weeks. It really depends on what I’m working on.

Running through these steps helps me gradually improve my code. There’s nothing better than finally getting a fix for some smelly code merged and into production. Sometimes we can have nice things.

Dan Willoughby is the founder of Tellspin, an on-call scheduler in Slack for DevOps and developers (https://tellspin.app). Helping workspaces reduce their contact footprint, resolve incidents faster, and regain deep focus.

_____________________

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.

 

 

Presenting a Dev Interrupted Community AMA - Adam Furtado - Chief of Platform at Kessel Run - Answering your questions about scaling Kessel Run

How will the wars of the future be fought, and who is heading these advancements in technology? Back in 2017, the US Air Force created a program called Kessel Run, which aids war fighters in the realms of DevOps, Agile, and UX, and the head of this project was an analyst by the name of Adam Furtado. In February of 2021, we interviewed Adam on the Dev Interrupted Podcast and shortly afterward hosted an AMA on our community Discord server.

Adam is the Chief of Platform at Kessel Run, and his story of how he almost single handedly led the US Air Force from 1970's software delivery methods to modern DevOps is one of the most incredible episodes of Dev Interrupted we've had. Adam talks about translating engineering to military officials and how he had to shift his mindset from application development to creating a system of systems. Listen to the episode here: 

This Community AMA took place on February 26, 2021 on the Dev Interrupted Discord.

Necco-LB: 📢 📢 Community AMA📢📢   @everyone

Topic: Scaling Agile & DevOps

We're getting started in 15-minutes! Adam Furtado joins us to share his experience and expertise in scaling his organization (Kessel Run) from 5 >> 200+ developers!

Necco-LB: Let's get this thing started! @here

Welcome to our little community Adam! I can honestly say your episode of Dev Interrupted this week was one of the most interesting episodes I've produced.

Adam Furtado: Thanks for having me! I'm happy to hear that.  Fighter jets are inherently cool.

Necco-LB: I don't think anyone can argue with that. To start things off, Adam can you give the community some quick context about Kessel Run? How many developers in your organization, what you’re building, etc.

Adam: Sure thing, KR is an Air Force organization proving that government-led software development will lead to better mission outcomes than outsourcing our software to companies that specialize in building airplanes (and using the same processes for their software).   We build applications for warfighters to more efficiently strategize, plan, execute, task and assess the complexities of air campaigns. We have grown to about 1300 people… I’d guess. 400 of those are developers.

luisfernandezbr: Adam. What are the top 5 tech/dev metrics that you consider important to measure on a dev team? (Not product metrics like MAU, MRR).

Adam: I think they change as an organization changes... but for the most part I love the DORA 4... I think when used properly (and together!) it can tell you quite a bit about where you need to invest in your organization.  The relationships between the metrics are what drives the value and I think often get forgotten about.

Necco-LB: Were you looking at different things (metrics or ways of visualizing work) when KR was smaller vs today?

Adam: For sure. I led most of our app development at first and we were/are an XP shop.  Our teams were always very diligent about pulling the next story from the top of the backlog etc., so we never really had a WIP problem.  When I moved over to lead our platform org, they were using a poorly-executed pseudo-scrum model and all of a sudden all of the DeGrandis/Kersten/Kim stuff I have been reading my whole career started to make a ton more sense.  In building internal services, it was amazing to be able to see why work visualization matters and SEE the constraints building up.  I'm so glad that I made the switch to build the empathy needed to be a more effective leader.

Necco-LB: Sounds like a big jump indeed. I have to say I’m wicked curious about how software development is different from within the military vs. the corporate environments most of us know.

Adam: Traditionally, the DoD was a case study in poor waterfall dev.  Years of requirement development by people very removed from the work, leading to a contract being put in place that could only feasibly be won by a big defense contractor, years of development to "deliver" the "finished" software to be tested by separate government test organizations for a year or so and then "fielded" manually by folks traveling around the world putting CDs in machines. We've proven that all that risk avoidance actually INCREASES risk and we've had it backwards all along.  To biggest thing we focused on early was how to reach Continuous Delivery with the heavy GRC requirements that we have in Defense (and rightfully so).  So we worked with a forward-leaning IT leader in the Air Force to create and pilot the first Continuous Authority to Operate in the DoD.  So instead of an approval to deploy to classified systems at the "end", we got our processes approved so everything coming out of our org was approved to go into those production environments.  That’s prob the most unique thing.

luisfernandezbr: How you measure the evolution of your dev teams? And what initiatives and practices you use to grow them (like Dojo's etc)? What content do you recommend about DeGrandis/Kersten/Kim?

Adam: Deploy Frequency, Lead Time, Mean Time to Restore and Change/Fail Rate... Accelerate is the bible on this one (Forsgren, Humble, Kim)... Phoenix and Unicorn Project for Gene Kim's take on how to transform IT to DevOps approaches in big, slow companies... Making Work Visible by Domenica DeGrandis is a fantastic book on understanding what keeps us for being as productive as possible.... Mik Kersten's Project to Product on increasing flow.  There are a ton of others, but that's a good start.

_____________________

Read the unedited AMA and join in the discussion in the Dev Interrupted Discord here! With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. Join the community >>

Dev Interrupted Discord, the new faces of engineering leadership

_____________________

drdwilcox: Thanks for joining us. During the podcast episode you talked about gaining momentum with some early wins. How did you keep that momentum going?

Adam: We struggled there, to be honest. The early wins were so much easier to "sell" to stakeholders.  "There wasn't an app before... now there is.  So I'm impressed". The first year we were deploying MVPs left and right and were the Belle of the ball.   However in building large scale systems, we started focusing a lot more on our infrastructure, data models, optimization, internally efficiencies... and things that were providing real value- but weren't as visible.  Those things are a lot less interesting to stakeholders. The Government has a very output-centric approach to value.  We have focused on building an outcome-driven organization, so there is always a conflict when discussing what is or isn't valuable.

drdwilcox: I don't think it's just the government, to be honest. I have the same struggles in my private company. Output as defined by Product are sexy, all the other things are not. What was effective for you in getting the stakeholders re-engaged?

Adam: It's still a work in progress, to be honest.  We constantly harp on the risk of NOT transforming in this way.  The 2018 National Defense Strategy hits on this hard and all of our Senior leaders are pushing the same message.  So that has been really helpful.  General Brown, AF Chief of Staff, has done a great job of being clear about where we need to drive, so that allows us a bit of a trump card when we come into contact with someone who is trying to hold back progress.

Necco-LB: That idea of selling to stakeholders is really interesting, especially in the military. What did you have to say or do to convince your higher-up that  the counter-intuitive dev methodologies like releasing more frequently was worth a try?

Adam: We had no support early on.  The incentive process in the military rewards people who follow the rules and work within the system.  We sort of worked quietly off to the side on a project nobody really cared about to prove the value once delivered.  Once we got that delivered… we had MASSIVE dollar savings, so we started to be loud about it.  In fact, we were told not to use the “Kessel Run” moniker by higher ups… we decided to do it anyway and started promoting pretty hard.  By the time our first FastCompany article came out, all those senior leaders changed their tune and now they will say they were supporters all along. I am constantly doing that translation/evangelism work. And in the military, people swap out of positions every year or so generally, so some new person will get dropped in with no idea what’s going on and we need to start over again.  “Nope, the cloud is a real place…” Continuous Delivery has broken every gov process.  The test community doesn’t know what to do or look for… Requirement Managers don’t understand their place.  Configuration Management is just…. Different now.  I don’t need some guy managing a spreadsheet of what versions of software are deployed where.   We are in a weird transition period right now. In a lot of ways those stakeholders are sick of hearing from me.  I'm sure they hear Charlie-Brown-teacher-voice when I try to discuss this stuff at this point.  So we have worked on finding the proper champions in higher up places to do that work for us.  The very top of the Air Force totally gets it.  It's everyone in between who need to keep their head down to keep rising in the ranks.  (Tale as old as time...)

Necco-LB: Geez, what a thing. I can't believe you have the energy to continuously fight these battles within your own organization.

Cartoon of two people "Yeah so - don
Read more about Kessel Run and smuggling DevOps into the Department of Defense

Adam: Someone once told me a story about this dad who brought his family to the beach.  They had this big, pink inflatable bunny that the kids were using in the water.  Every so often the bunny would deflate and the kids would run back up the beach to the dad and he would huff and puff and blow it back up.  Kids would be happy and go back in the water.  An hour later, kids are back again and the dad is blowing it back up.  This person said "that is what innovation in the government is like".  Every once in awhile you need someone or something to "pump up your bunny".   The work I do is so exciting and fulfilling, all the BS that I have to deal with, all the money that government employees are leaving on the table, the bureaucracy ends up being worth it.

Necco-LB: That is a great analogy. Reminds me of how you talked about the mission driven culture at KR on the podcast. Can you talk about why you believe the culture of your organization is so important? And any advice you might have for organizations who are bifurcated?

Adam: Organizational alignment is incredibly important.  One place we have struggled is that we put such an emphasis on teams, that teams built strong individual identities.  They were empowered to solve their problem, but over time became less concerned about other teams' problems.  This was never more evident than working with the ops/platform teams.  The app teams knew what their users needed and all they cared about was meeting their needs.   Meanwhile, we had a whole organization with organizational outcomes that were the priority.  Let to a lack of empathy across teams and the communicate at the seams of teams was challenging. We are still digging ourselves out of that, but one thing we focus on is that mission-driven culture.  All it takes is a day like yesterday, with airstrikes in Syria, to level-set everyone on the seriousness of our work.  The mission aligns the teams towards a common goal and common outcomes.

luisfernandezbr: Adam. Thanks for the great tips. What were the big challenges that you had when increasing the dev team?  Things like knowledge sharing, share learning and maintain quality and excellence. Could you share some tips about this, if it is the case?

Adam: We sucked at all those things.  That mission-driven culture led us down the unenviable path about feeling so much pressure to deliver and support our users, that tech debt mounted and documentation suffered.  We struggled investing in automation in favor of getting short term wins.   The last year we have really rebalanced and ensured that we are providing space for our teams to organize their time better.  None of it was intentional, but regardless of what we said, we (leadership) were giving off the vibe that teams couldn't possibly slow down to invest in tech debt or spend time focusing on automating toil away.  We have had to be super clear that it is EXPECTED that teams work at a sustainable pace, invest in their code bases, invest in their professional growth and personal health and be okay saying "no". We have a lot of military members on our team, so saying "no" to your superiors is always a culture change we have to work on internally.

Necco-LB: Working on technical dept and automation vs. new features is something everyone can relate with for sure. I think we'll let Adam get back to his far more important job at Kessel Run. One last question, if someone here wants to get involved with Kessel Run, where can they go? Should they reach out to you?

Adam: This was fun- thanks for having me.  You can follow me on Twitter at @adamsfurtado or you can reach out directly at afurtado@kr.af.mil.  To follow along with KR, you can follow @kesselrunAF on most social media platform. I'd also like to plug that we are currently hiring for a bunch of roles from product leadership to engineers.  It's an incredible place to work and you can make a real impact.  Please take a look and reach out to me with any questions! Thanks again!

Antonette: Job opportunities at Kessel Run here: https://grnh.se/3201d1713us

_____________________

Starved for top-level software engineering content? Need some good tips on how to manage your team? This AMA is based on an episode of 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.

Dev interrupted Discover our Most Popular Podcasts - with a variety of headshots from former speakers

Putting employees and your community first should be a crucial priority for every organization, and it shouldn’t exist only in principle - it must exist as an actionable goal. Fostering a community within your team creates a foundation for high-performance, but it only works if you lead people-first.

At Stack Overflow, the level of collaboration between engineers is a step above any other organization I have seen. It takes conscious effort on the part of leadership to foster a work environment that puts employees first. Managers should choose to put people first, because it’s the right thing to do, not just a vague claim to a cliche. 

Thankfully, we live in a world where the data demonstrates that caring for people first is also the economic thing to do. No one has ever done a better job because they were scared, stressed, or worried about their future; especially in jobs centered around creativity and problem solving such as software development.

This commitment to people is the leadership philosophy behind Stack and helps guide our decision-making and our workplace culture. It also helped us to create Collectives™ on Stack Overflow. To get there, we needed a successful engineering team and culture - here’s how we built it. 

Indicators of team health

Common metrics that organizations tend to follow are often a symptom of a team’s performance, but not necessarily the whole story. Velocity, predictability, bug rate, etc should be viewed as an indicator of team health, not as a goal to be achieved; sometimes the best indicators to follow are subjective, and relative to the people and teams. 

After all, what does success look like? If people are getting what they need, agreed upon expectations are being met, and team morale is high, that’s real success. If this kind of people-driven success is occurring, you’ll start to notice that things like velocity time and predictability will naturally improve and not the other way around.

For the record, predictability should never be the goal. The end goal should always be to create value for your customers and/or your community. Any team - or manager for that matter - can make predictability look good if they are making sure that they never fail a given estimate on paper, but that’s not an indicator of good product creation.

If you're actually producing value, and you have a well run team, predictability will follow. It's a side effect, a symptom of good team health. 

Servant Leadership

At Stack Overflow, we’ve had long talks about what metrics we feel provide valuable feedback and those we believe are valuable to track. Numbers are important and should not be ignored, but again, they should not be the standalone goal. Tracking the right metrics should facilitate introspection for your organization and leaders would do well to keep this in mind. If we have a bad sprint, it tends to trigger us to think, “what went wrong?” and “how can we improve this for next time?” instead of thinking this was a failure of certain individuals.

For instance, if you had a sprint where you achieved a really high velocity, you should celebrate that success. But at the same time, you should be asking yourself what led to that success. Was there a behavior that changed? Not everything is internal. Sometimes external factors, a pandemic as an apropos example, influence successful team metrics just as much as internal ones do. Remember to look behind the metrics to see what’s impacting team members.


As far as following specific methodologies is concerned, try not to get hung up on the little things; analysis paralysis occurs is often a huge drain on performance and focus of the team. Time spent sitting around and arguing about whether something is a three point or a four point story is not productive. Call it a four and keep moving. Good leaders should keep their developers developing, while removing any hindrances to their performance, ideally before it is even on their radar.

Building a team and your product

If you’ve been around software development long enough, I’m sure you’ve had the experience of joining an organization where everything is dictated in a top-down approach. This kind of “my way or the highway” thinking ultimately undermines your teams and makes your organization rigid in an industry that is far more creative than some like to admit. 

A good manager will do their best to accommodate their teams, even if that means allowing a team to communicate or operate in a way that is not established within an organization. Recently, one of my most productive teams started to struggle after the project we were working on started to shift. A lot of the QA and code review work associated with the stories became large and unwieldy and the common practice was to have that wrapped in with the dev story. That makes sense after all, the former can’t ship without the later. Eventually we just tried separating out the more cumbersome tasks into their own stories. The immediate and biggest reaction was from folks overly invested in the metrics: we just doubled our stories and made it appear that story cycle time virtually doubled. The instinct was to say “this is a step backward. Undo it all,” but that would be ignoring what's going on behind the metrics: more work was getting done, and the bug count dropped. As those were saying we need to go back because the metrics showed team health was bad, my response was to just change the metrics to accurately reflect our healthier team that chose their own workflow.

Adopting this mindset as a manager provides huge returns for your organization. People are happier when they are not being forced into something that doesn't fit. With team members that control how they work, on their own and especially with each other, comes higher value creation.

Work-life Balance

I have never met anyone that works better when they’re worried about what’s going on in their personal life. I’ve found this over and over in my career as a developer and eventually a manager inspired me to write about it. People who are under stress feel strained to come up with strong solutions and tend to generate less errors. Those people who say “this person just works well under pressure” are really just saying “This person's performance doesn’t fold as much as others once emergencies happen.” That's a good quality for them, sure, but nothing an team should brag about; that should be embarrassing that it happened enough that some people have reputations around crises.

Work-life balance is not something a company sacrifices, that’s zero sum thinking. It’s been shown time and again that the opposite is true. Providing people with things like leave, and an investment in their mental health has more for an organization’s productivity than filling out timesheets ever will. At Stack we have a policy of unlimited sick days, no questions asked. If you need a day, we trust you to be able to take care of yourself. 

When you take care of people they will work better and faster - that’s also what they want to do. Regardless of the stereotypes people will often hear from naysayers who balk at the idea of unlimited sick time, the folks who just want to phone it in and game the system are the minority. So much so, that spending the effort considering how to manage the time a person takes a sick day when they aren’t sick is probably more of a time sink than how much it will happen. 

By choosing to be invested in your people’s health, an organization chooses to be a place that values its employees. When you avoid zero sum thinking, getting trapped in the idea that if employees are benefiting the company must be losing, you begin to realize that working with, instead of against, those you represent leads to happier people and a better bottom line. 

We took all these leadership principles and applied them to Collectives

At Stack Overflow, we’re quite a flat company. And I don’t mean this by measuring the number of levels between an engineer and the CEO (it’s 4, for the record), but people of all levels have a voice in product decisions. Engineers are heavily involved in what we build and how it is built. Being a company built for engineers and driven by engineers is a huge part of why Stack Overflow is successful. 

This success has allowed a beautiful community to thrive on our public platform, but we are always looking at how best we can give back to that community. How do we help our community grow? How do we make those experiences more meaningful? Those are the questions that guide us at Stack. 

“Anything that fosters our users’ ability to help each other and to benefit from it. That's always a homerun.” - from the Dev Interrupted Podcast at 34:54

With that in mind, we’ve launched Collectives, a new way for the community to interact with the maintainers of the technology they use most. 

As I discussed on the Dev Interrupted Podcast, Collectives are dedicated spaces on Stack Overflow where you can find the resources (including questions and technical articles) and trusted answers you need, faster, by centralizing that content and connecting you with the product experts and trusted users. For instance, if you have questions about Google Go, you can get answers directly from those who help maintain the language.


I am extremely proud of the work that went into this, and the work that we continue to do to make it something our users can enjoy. Like all new adventures, there is a constant feedback loop we work through to try and keep making Collectives, and Stack Overflow, a better and more welcoming place. 

It is still the Stack Overflow you know and love

The Beta release of Collectives was a huge success. We’ve seen over 20,000 users join Collectives on Stack Overflow and start collaborating since the launch in June. That said, we know we don’t have a Collective for everyone (yet). For users that don't want to take part, or haven't found a Collective that they're excited about yet, their Stack Overflow experience is not going to change.

For instance, we're not changing accepted answers, whether it comes from Google (our new partner) or not. If people don't vote for an answer, it doesn't get accepted. Content moderation will be treated the same way. Moderators will interact with content from sponsored users just like they would anyone else. 

“I think the most positive thing about it is that people aren't losing the site that they love, and that we're really proud of.” - from the Dev Interrupted Podcast at 33:22

With our community update, organizations will be able to improve the visibility and detail of content being created around their technologies, and users will be able to find more relevant and accurate answers they can put to use solving problems while being better recognized for their contributions. Ultimately providing both organizations and users with more actionable insights. 

These efforts allow Stack to build better communities because after all that’s really what we do: we are in the business of building communities. 

Collectives do just that. 

_____________________

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is based on an episode of 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.