It’s important to remember that investment isn’t a completely altruistic act. While investors clearly want to encourage innovation, a primary motivation is to see a return on that investment. At the end of the day, they’re gambling that your idea will make them money.

This can make investing in true innovation tricky. True innovations are those rare game-changing technologies that revolutionize an industry. They’re notoriously difficult to spot. How often have you heard that people thought Apple would fail when they released the first iPhone or didn’t believe in Facebook when it first went public? True innovation rarely looks revolutionary to begin with. So how do investors spot which ideas are worth the effort?

We spoke with Jason Warner, managing director at Redpoint Ventures, to understand the reasoning behind investments and why investors are so picky.

1. Typical SaaS companies are easy to invest in, but true innovation doesn’t follow the same model

When developers start searching for investment, it can often be discouraging. While investors might not understand the intricacies of every technology company they invest in, they can at least spot the trends. They know and understand how a Software-as-a-service (SaaS) company grows.

If a company is growing, it has a very familiar pattern. And so investors can be quite confident that they’ll see a return. They’re much more willing to take a risk and ‘YOLO’ an investment.

“SaaS companies are really well understood in terms of how they grow,” explained Jason. “There is no real investor challenge to understand that if a company is growing 2x and its enterprise sales look good then … [investors] can just “yolo” invest into them. Because they understand what these companies look like … It’s all just Excel spreadsheets.” -On the Dev Interrupted Podcast at 40:29

2. Investors often wait until the first round of funding, but developers need seed funding

If you’re developing a revolutionary piece of technology, then it’s likely that you need investment to get you off the ground. However, it’s difficult for investors to sort the good from the bad. How do they know you’ll be successful, without a few years of revenue behind you? It’s a catch 22 situation. You need the investment to get those first few years, but the investors need to see a few years before they’re willing to invest.

Look at how Netflix completely surprised the world. Nobody predicted that it would change how we watch video (most of all Blockbuster, who fatefully ignored the potential). This is a trend that harks back decades. Online shopping, personal computers, the television, even electric light bulbs were all disregarded when they were first conceived.

These industry-changing innovations need investment much earlier than typical SaaS companies. And spotting what works is more of an art than a science.

“[Investors] miss the fundamentals. They can see the ones that are the trends,” Jason said. “It should [then] become obvious in the next round or the round after that from other investors … oh yeah, that is a great company.” -On the Dev Interrupted Podcast at 41:18

3. Developers need to seek out companies like Redpoint for seed investment

If you have a truly new idea, you’ll need to find an alternative to the usual investors. A company like Redpoint, which focuses on giving seed funding, is much more likely to take the time and actually investigate whether your technology will be a success.

It will take longer, of course. And it might not be the full amount you need to get your business started. But it’ll be what you need to begin building a proof of concept, get those first few years under your belt and start pitching to other investors.

“[If you’re] talking to a Redpoint investor, you should be flattered,” Jason explained. “What we’re thinking is that you are a majorly important company in the future. You have the potential to land … If Redpoint invests in you, we want it to basically mean that we think of you as a new primitive on the Internet or in whatever sector that you are in. And other people are going to build upon you.” -On the Dev Interrupted Podcast at 41:35

Listen to the full conversation

If you’d like to learn more about what Jason thinks and how to secure yourself an investment, catch the podcast on our website.

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

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

Listen and subscribe on your streaming service of choice today.

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

Hiring neurodiverse developers can be challenging, particularly for smaller companies that are less experienced at hiring. This isn’t because you need an entirely new process or that neurodiverse people are inherently trickier to interview. It’s that small flaws in your hiring process get exacerbated. Obstacles that cause neurotypical people to stumble, become outright blockers to a neurodiverse person.

So we asked Matt Nigh, data engineering manager at UW Medicine, to give his tips on how to make sure your hiring process suits everybody.

“I think there are companies that other organizations could mimic,” Matt explained. “I would look at Google as one of probably the best that I’ve experienced.”-On the Dev Interrupted Podcast at 25:50

1. Interview processes should be conversational

If you use a lot of formal language, jargon and needlessly complicated words, you’ll make it much harder for your interviewee to understand what you want them to do. It also makes the interview artificial and cold, which can lead to unnecessary stress and anxiety in your interviewee. This is true for everybody, but for a neurodiverse developer, it can be much more potent.

 

“The most inclusive interview process I ever experienced was at Google,” Matt said. “And the reason I felt they had such an inclusive process is that it was wildly conversational. They were incredibly good at explaining what they were asking and what they were looking for. And to me, it was an incredibly friendly process.” -On the Dev Interrupted Podcast at 24:10

2. Neurodiverse developers prefer straightforward and clear instructions 

When giving instructions, particularly in practical tests, it’s important to make sure that you’re being clear and straightforward. Leaving ambiguity can cause problems, especially for neurodiverse developers. That ambiguity can distract away from the actual task at hand. The clearer your instructions, the better you’ll test a developer’s actual skills.

 

“I would say the reason I failed the system design interview was (and this is an example of what autism will do during an interview) it was the first system design interview I ever had. And I spent half the time trying to understand the language that the individual was using, rather than solving the problem, trying to make sure we’re just on the same page with what we were saying,” Matt said. -On the Dev Interrupted Podcast at 24:40

3. Neurodiverse developers need diverse recruiters, and stick around for longer once hired

Everyone has their own biases. While we should all strive to overcome those, it’s not always possible. The best way to avoid those problems is to make sure your interview team is diverse. Some coping mechanisms and strategies can seem strange to a neurotypical recruiter at first.

For example, someone with ADHD might ask you to repeat points or be typing as you speak. While it could initially look like they’re answering emails or not paying attention to you, it’s more likely that they’re taking notes to make sure they follow your instructions properly. The more diverse your recruiters, the fewer false assumptions you’ll make.

“Most recruiters are used to looking at neurotypical applicants, and they essentially have mental flags that come up with certain things, certain questions or anything like that,” Matt said. “Companies should ask: Do I have inclusive recruiters? So say, for example, at Google, they had incredibly inclusive recruiters. I was recruited by a deaf individual, for example. So this person very clearly understands me and anything that was going on.”-On the Dev Interrupted Podcast at 25:13

4. Neurodiverse developers could be more productive, and worth changing your processes

A program at Hewlett Packard Enterprise hired over 30 neurodiverse people in software testing roles at Australia’s Department of Human Services. The initial results from the program seem to suggest that those testing teams are 30% more productive than others, according to an article in the Harvard Business Review, called neurodiversity as a competitive advantage.

 

It would seem that, while a neurodiverse person might struggle in some areas—like the social anxiety brought on by an interview—they could exceed in others, such as pattern recognition.

Watch the full interview

If you’d like to hear more from Matt on neurodiversity in software development, you can watch the full podcast on our channel.

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

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

Listen and subscribe on your streaming service of choice today.

Discover Our Most Popular Podcasts
Join the Dev Interrupted discord

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<

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

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

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

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

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

2. Inclusive workplace culture draws in better talent

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

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

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

3. Inclusive design’s influence is set to explode

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

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

Design is changing… Moving towards a more inclusive future

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

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

__________________________________

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

 

You're Invited to INTERACT on April 7th

Join engineering leaders from Netflix, Slack, Stack Overflow, American Express & more at LinearB's virtual engineering leadership conference, INTERACT on April 7th, 2022.

1 day, 20 speakers, 1,000s of engineering leaders - all driven by the Dev Interrupted community. If you are a team lead, engineering manager, VP or CTO looking to improve your team, this is the conference for you!

>Learn more here<

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.

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:

 

______________________________________________________________________________________________________________________________________

If you haven’t already joined the best developer discord out there, WYD?

Look, I know we talk about it a lot but we love our developer discord community. With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>

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

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

 

Focus Area 1: Trust, Collaboration and Communication

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

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

 

Focus Area 2: Information collection, compartmentalization and sharing

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

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

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

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

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

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

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

______________________________________________________________________________________________________________________________________

If you haven’t already joined the best developer discord out there, WYD?

Look, I know we talk about it a lot but we love our developer discord community. With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>

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

______________________________________________________________________________________________________________________________________

If you haven’t already joined the best developer discord out there, WYD?

Look, I know we talk about it a lot but we love our developer discord community. With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>