The FIFTH EPISODE of Dev Interrupted––the Hebrew Edition has DROPPED. In this episode, Yishai Beeri, CTO at LinearB, chats with Eti Dahan Noked, VP R&D at Wilco about skilling up your engineers...how this differs from regular training and onboarding, and who's responsible for the success - managers or the engineers themselves? Eti shares some interesting insights both from her own career experience as an engineering leader, and her current role at Wilco, the platform built for skilling up engineers.
We can’t believe we’ve already reached the FIFTH excellent episode in the series, and we wanted to do a quick recap, ICYM our previous episodes on a diversity of topics that were really fun to record and full of excellent advice from seasoned engineering leaders in the industry.
Episode 1: Adi Shacham-Shavit
In our first episode, “Is the VP of Engineering Just a Glorified Project Manager?”, one of the most seasoned engineering leaders in the Israel community––Adi Shacham-Shavit SVP R&D at Transmit Security, drops deep wisdom on the many different aspects of engineering that have changed and evolved over the past two decades ––everything from process and practice through culture, quality, and ownership.
She takes a deep dive on how the VP Engineering today needs to bring a lot more business value and perspective, than the common misconception of just being “a glorified project manager”. Today this role has a much greater responsibility of translating and connecting engineering work to the company vision and purpose, she gives some tips on how to do this, and ultimately why this creates better engineers.
Episode 2: Linoy Shkuri
In episode two, Linoy Shkuri, R&D Manager at up and coming finserv startup Justt, talks about the joy of working in a SaaS company, and the fun with tinkering with really exciting new dev tools built with developer experience in mind in the episode “Why should you care about Developer Experience in a young, fast-growing startup?” She shares why it’s important to take a meaningful part in your local developer communities––as developers and companies, and to never be afraid to fail at something new today. Just be ready to pick yourself up, dust yourself off and fix it.
An important takeaway that Linoy shares is that as engineering managers we need to think about what will make our developers’ time memorable and meaningful––how to make sure they understand that they have grown in their time at this company.
Episode 3: Nofar Ben Kereth
Our third episode with Nofar Ben Kereth from Cloudinary, “Deciphering the R&D Operations Manager Role” takes a look at an emerging role in growing engineering organizations––R&D Operations, similar to product operations in product management and marketing operations in marketing. The R&D ops role comes to fill a void of the many non-specific, and oftentimes organization-wide challenges that growing companies need to overcome.
Nofar did an excellent job of demystifying what this role consists of, what’s in scope and out of scope, how this role interfaces with other similar ops roles in the company (have we mentioned product ops), and even how to motivate and drive folks to align with processes when they aren’t your direct reports.
Episode 4: Daniel Korn and Karni Wolf
In our previous episode of Dev Interrupted featuring Karni Wolf, Senior Engineering Manager at Snyk, and Daniel Korn, Director of Engineering at Lemonade––who together also lead the Engineering Managers IL community. This episode, “Congrats! You’re a Unicorn! But wait till you hear about these engineering challenges” is chock full of wisdom from two seasoned engineering managers in unicorn companies, that takes a look at engineering leadership in a rapidly growing and hyper-scale startup. Karni having grown with the company, and Daniel coming into a unicorn from a scale-up (later turned unicorn - BigPanda) provide different perspectives of evolving into a unicorn, and conversely landing in a unicorn.
They share some of the trials and tribulations, and things they’ve learned on the way, and provide some tips for aspiring engineering managers and engineering leaders in growing companies.
We have more great episodes coming that will focus on ICs and how they interface with engineering managers, Dev Advocacy from a senior perspective and interfacing with engineering managers and much more. Make sure to stay tuned…and we’re always looking for more guests, so REACH OUT HERE if you like to nominate a guest for the show.
Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.
Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.
Listen and subscribe on your streaming service of choice today.
At Netflix, we don’t just think about productivity - we engineer it. There’s an entire team within Netflix dedicated to productivity. I lead the Develop Domain along with my Delivery and Observability Domain peers, and together, we make up Productivity Engineering.
I recently sat down with the Dev Interrupted podcast to discuss all things productivity, how I run my team, and how other managers should view employee success. Here’s how we think about it at Netflix:
Can productivity be engineered?
In short, yes! Productivity is not a generic term for team performance or a perfunctory buzzword used during team meetings. The productivity team is an actual organization. The work we do is foundational to Netflix’s development teams. Productivity Engineering lives within the broader, central Platform organization.
The role of the Productivity Engineering team is simple: we exist to make the lives of Netflix developers easier. Abstracting away the various “Netflix-isms” around development, delivery, and observability, productivity allows devs more time to focus on their domain of expertise.
“We are sort of like the nerds’ nerds, if you will, enabling them to use our platforms and tools so that the work that they're doing is focused on studio and streaming, without thinking about everything that's under the hood.” - On the Dev Interrupted Podcast at 2:31
With the recent addition of Gaming to the list of Netflix’s pursuits, the resulting focus becomes even more important.
Practically speaking, it’s the role of Productivity Engineering to help with things like coding, testing, debugging, dependency management, deployment, alerting, monitoring, performance, incident response, to name a bunch. Netflix utilizes the concept of a “paved road,” the frameworks, platforms, apps, and tools we build and support to keep our devs rolling. The idea is to keep workflows streamlined and enable developers to operate as efficiently and effectively as possible. If the road ahead is cleared of obstacles, you’re going to get to where you need to go faster and with support along the way.
It’s also about helping developers enjoy the ride. To abuse another metaphor, a sound engineering experience should be like dining at a fine restaurant. If done right, you rarely remember the waitstaff, have a hard time finding something you like, or worry about how they prepared the food; you simply enjoy the experience. If Productivity Engineering is doing their job, they act as the restaurant and waitstaff with developers as the customer, providing nothing short of a beautiful end-to-end experience.
Measuring Outcomes vs. Output
Measuring all of that productivity can be hard, and there’s no one unicorn measurement to rule them all. Hence, developer productivity teams should focus on impact and outcomes. Above all, Netflix focuses on customer satisfaction. Our philosophy is that while how something is delivered is important, the impact of what’s delivered is ultimately of greater importance.
"If you're running around a track super-fast, but you're on the wrong track, does it matter? So really, what are you delivering? How you're delivering is important. But if that thing that you're delivering is ultimately doing what you want it to do, that's the most important thing."
- On the Dev Interrupted Podcast at 5:05
In this model, the outcome always wins over output or activity. For instance, standard productivity deployment metrics (DORA) as applied to our customers become an important proxy for measuring our success. Key Performance Indicators (KPIs) for productivity are viewed as a reflection of a team’s performance as it relates to customer satisfaction.
I’m a big fan of the SPACE framework, developed by Nicole Forsgren, for precisely this reason. How are our customers doing in terms of Satisfaction, Performance, Activity, Communication, and Efficiency? The answer to those questions reflects how we’re doing as a Productivity organization.
"This is our strategy, these are our hypotheses around, how we're going to improve our customers' productivity. Are those things paying off? And if you can't measure them in some way, who knows? Right? So yeah, we're getting a little more hardcore about this."
- On the Dev Interrupted Podcast at 24:17
Key metrics provide productivity teams with a holistic view of performance by establishing benchmarks. Understanding that everything needs to be viewed within the proper context, it’s difficult to improve as an organization if nothing is measured or tracked.
Comparing Productivity
Comparing developers’ productivity across teams is a thorny subject at best and downright dangerous for team morale at worst. As the old saying goes, “Comparison is the thief of joy” or what I typically say, “comparisons lead to unhappiness”, or with my kids “eyes on your own paper!”.
The productivity teams at Netflix take a contextualized view of dev teams rather than relying solely on raw data. Every project is different, the customer base is different, the use case is different, personas are different, and where a team is within the software development life cycle is different.
It’s a basic understanding that comparing apples to oranges is not good math. A team that is just starting out and building something new, is going to look very different than a team with a mature product. By recognizing this, it becomes almost impossible to rank teams against each other because very rarely, if ever, will teams be doing the same thing, in the same space, the same way, with the same people.
Even a measurement of an outcome pertaining to customer satisfaction (CSAT) is not straightforward. At Netflix and across the industry, we’ve found that satisfaction for internal teams skews lower than satisfaction for customer-facing teams.
The reason? Teams within Netflix are their own harshest critics. When attempting to gauge the performance of an internal team vs a customer-facing team, it’s understood that the internal team is almost always going to score lower on satisfaction, even if both teams are equally effective.
Context is everything. Measuring productivity means being mindful of context.
Pushing Productivity
Any company that wants to be successful must understand how to measure its success. Productivity doesn’t count for much if an organization is not moving towards desired outcomes.
By viewing productivity as more than just a concept or a raw set of data, the hard-working teams at Netflix have turned productivity into an actual apparatus. It is a living, breathing team of human beings whose devotion to empathetic efficiency improves customer satisfaction and dev team quality of life. I am incredibly proud to lead these teams, and I sincerely hope the work we do inspires other organizations to improve their developers’ experience.
And if you want to be as productive as Netflix, remember that metrics are only as good as their context!
Chaos Engineering might sound like a buzzword - but take it from someone who used to joke his job title was Chief Chaos Engineer (more on that later) it is much more than buzz or a passing fad - it’s a practice.
The world can be a scary place and more and more companies are beginning to turn to Chaos Engineering to proactively poke and prod their systems and in doing so are improving their reliability and guarding against unexpected failures in production and unplanned downtime.
During my career I dealt with my fair share of outages, including one that caught me mid-song during a bout of karaoke and far too many that woke me up at 02:00. As the co-founder and CTO at Gremlin, I do my best to make sure no other engineers have to suffer sleepless nights worrying about their product.
But the question remains, what is Chaos Engineering and where did it come from?
A Short History
The spiritual predecessor to Chaos Engineering is often called by a much more widely recognized name - disaster recovery. The focus when this practice was introduced is much the same as today: proactively suss out production problems by injecting failure.
Netflix’s Chaos Monkey is probably the most well publicized Chaos Engineering tool as it arguably kickstarted the adoption of Chaos Engineering outside of large companies, but this has led to the erroneous belief that Netflix invented the practice. In fact, the practice was already widely in use amongst the titans of technology.
Over a decade ago during my time as a Lead Software Engineer at Amazon, we implemented several crude practices designed to inject failure into our systems. The most rudimentary of which was employed by a man called Jesse Robbins, who earned the nickname “Master of Disaster” by running through data centers pulling out cables.
Let’s just say the practice has evolved a lot since those early days and your data center cables are much safer these days.
What is Chaos Engineering?
“What Chaos Engineering really is, is the art, if you want to call it that, of introducing controlled chaos.”
- 2:16 on the Dev Interrupted podcast
At its core, Chaos Engineering is a disciplined approach of identifying potential failures before they have an opportunity to become customer facing outages.
It is a practice that lets you safely test your assumption about how your systems will behave under duress by actually exercising resilient mechanisms in a controlled fashion. You literally "break things on purpose" to validate and build resiliency. The end goal of Chaos Engineering is not to inject arbitrary failure into a system, but rather to strategically inject turbulence to enhance the stability and resiliency of your systems.
How Chaotic is Chaos Engineering?
I always tell people that Chaos Engineering is a bit of a misnomer because it’s actually as far from chaotic as you can get. When performed correctly everything is in control of the operator. That mentality is the reason our core product principles at Gremlin are: safety, simplicity and security. True chaos can be daunting and can cause harm. But controlled chaos fosters confidence in the resilience of systems and allows for operators to sleep a little easier knowing they’ve tested their assumptions. After all, the laws of entropy guarantee the world will consistently keep throwing randomness at you and your systems. You shouldn’t have to help with that.
How do I Start?
One of the most common questions I receive is: “I want to get started with Chaos Engineering, where do I begin?” There is no one size fits all answer unfortunately. You could start by validating your observability tooling, ensuring auto-scaling works, testing failover conditions, or one of a myriad of other use cases. The one thing that does apply across all of these use cases is start slow, but do not be slow to start.
What I mean by this is to start testing across just a few nodes versus impacting your entire fleet. We refer to the impacted area as the “blast radius” and we highly recommend starting with a small blast radius (the number of systems impacted) and increasing it over time.
By starting small you allow yourself to gain confidence in both the experiments you are running and your systems. Of course your risk tolerance is also a factor of how large a blast radius your organization will use.
For instance, a large banking institution with millions of customers has a much lower risk tolerance than a tech startup with a couple hundred customers. In that case, they would want to run experiments in a programmatic way and would need to be very explicit about communicating to the rest of the organization what tests are going to be run and when to avoid any unplanned 2am or 3am disasters.
Eventually you want to get to the point where all of this is automated, a process we refer to as “continuous chaos.” Starting small with automation could be something as simple as taking out a single node; then taking out five nodes; then ten; and so on. Eventually you automate the process at a level you are comfortable with.
“Ultimately you want to be able to handle any of this random chaos being thrown at you, because that's what the world is, it's entropy, it's degradation”
- 7:35 on the Dev Interrupted podcast
No Tolerance for Downtime
When I founded Gremlin, it was just myself and my co-founder developing the first iteration of the product. The business looked very different then and I jokingly referred to myself as the “Chief Chaos Engineer” responsible for implementing code that was mostly used by enterprise companies. Many of these companies came to us because they had reliance thrust upon them by the US government or they had top-down reliability standards and they wanted a tool to help them shore up their systems.
As the company began to evolve, so did the customer base. These days it’s not just Fortune 500 companies that care about reliability, it’s everybody. Planned downtime is a relic of days gone by. It is no longer acceptable to espouse planned maintenance windows as part of development lifecycles and customers don’t have the patience for products they rely upon to spend any time unavailable. Companies recognize this dynamic - and it’s not a hard one to miss.
Seemingly our appetite for technology has gone up exponentially while our ability to stomach downtime has drastically decreased. Customers expect that your product is always working, always running. If your product is down because of outages then there are ten other similar products waiting in the wings to take their money.
Making Lives Better
Visibility is high these days and companies don’t need the publicity that comes with making any unforced errors, let alone to be subject to errors not of their making. No one wants to be blown up on Twitter because their product isn’t working or because one of their downstream dependencies or their cloud provider had an unexpected outage.
By preparing for the worst, we can be at our best as an industry and can be prepared when disaster eventually comes knocking. That’s why when an unexpected outage occurs or there is a production failure customers will never even know it happened.
I often joke that we are the engineers’ engineers because many of us know that feeling of being jolted from a dream at 03:00 by our pagers, groggily wiping our eyes and whipping out the laptop to go dig through a sea of monitoring dashboards and logs. It’s not fun and it’s exactly why I founded Gremlin. Because there is a better way to approach operations than merely sitting back on our haunches and waiting for the next outage. Chaos Engineering not only helps to protect against the randomness of the world, but also teaches people how to build more reliable software. And if enough people build more reliable software, we build a more reliable internet.
Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.
Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.
Listen and subscribe on your streaming service of choice today.
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 >>
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/
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.
Following a recent interview on the Dev Interrupted Podcast, OutSystems CEO and founder Paulo Rosado joined us to chat about his path to founding the company, advice for successful leaders, and the growing threat of technical debt. The conversation below has been edited for length and clarity.
Tell us about OutSystems' founding story. What inspired you to start the company?
In February 2021, OutSystems was valued at $9.5 billion dollars - but it certainly didn’t start out that way. The idea behind OutSystems was decades in the making, and its mission stems from what I observed after moving to Silicon Valley back in the mid-nineties.
My journey in technology began when I graduated with a degree in computer engineering from Universidade Nova de Lisboa in Lisbon, Portugal and moved to the US to get my Masters in Computer Science from Stanford. Afterward, while working in Silicon Valley, I began to understand just how much of a problem technical debt was.
While working on a very large engineering team, we were faced with tackling a gigantic project in Java and I realized the issues of releasing and maintaining code sustainably. The lack of productivity in the software development process was appalling. Fixing this problem is ultimately what motivated me to found OutSystems.
Before founding OutSystems, there was a small company I founded and later sold, which focused on internet and intranet projects. It wasn’t a bad company, but we kept failing. Projects were never delivered on time or on budget.
We would think to ourselves, “We’re smart. How is this possible?” Our inclination was to blame the requirements of the project, labeling the scope as incorrect and adjust from there. However, we began to realize that the companies hiring us for these projects wanted us to make changes as we were developing in response to rapidly changing environments.
The issue we began to face was the continual accumulation of technical debt. We would reach first production and realize we had built something users didn’t want, requiring us to go back and rework the stuff we had just built.
“We came up with this realization that the problem was not that the requirements up front were wrong. The problem was that the cost of changing wrong requirements, which are a fact of life, is very high.”
- on the Dev Interrupted podcast at 6:03
This phenomenon was occurring in 90% of projects at the time. Things were always over budget and always late.
Today, it’s easy to take this for granted because concepts like Agile, DevOps, CI/CD are mainstream. But at the time, you had to build software the same way you build a bridge.
Why is technical debt a challenge for companies now? How has this problem changed?
Technical debt has become a large problem for businesses, and one that only compounds with time. Tech debt doesn’t have a singular cause - it’s the accumulation of several factors.
Over the course of my career, I’ve seen first-hand the complexity brought about by the evolution of software development. For instance, we’ve seen an explosion of languages, paradigms and frameworks that can all be used to achieve a solution. Often these languages are dispersed with no connections between them, so tracking these dependencies requires a great deal of sophistication.
In addition to this, turnover within the development team is a critical problem that leads to technical debt. The moment a company loses a developer, the knowledge accrued by that developer also departs the company. The hole left behind is complex, including code, frameworks and intent behind how their systems are structured.
It’s been my experience that a lost team member can take as much as 20% to 30% of the fundamental knowledge of a system with them. Reverse engineering their work is both time-intensive and inefficient.
Companies have tried to corral this problem by investing in coding standards. While these constraints can help mitigate the loss of a valued developer, our research indicates turnover remains a significant problem.
OutSystems recently released a study on the effects of technical debt. What were its findings?
Recently, OutSystems surveyed 500 large companies around the world to examine the cost of technical debt facing businesses and uncover the challenges companies face as they confront its causes. The results from the companies surveyed were many of the same things I’ve observed throughout my career.
It’s important to note that while the causes of technical debt have largely remained the same, the pace at which technical debt occurs has grown substantially.
“And so it's a hack, right? What we call a hack at OutSystems, they did a hack to just release the software quickly. And those hacks compound into technical debt.”
- on the Dev Interrupted podcast at 27:11
The survey we conducted isolated three major causes of technical debt. They are as follows:
- The amount of developer frameworks. An increase in frameworks leads to an increase in technical debt.
- Developer erosion. Employees leaving an organization and taking legacy knowledge with them.
- Compromises in quality of architecture and code. Often caused by a shortsighted view that what needs to be done now is more important than long-term stability of the codebase.
In the past, companies believed they could buy their way out of this problem, but that strategy has proven ineffective. The reality is, the most successful companies must build the software they require to meet their business needs.
Simply purchasing what you need doesn’t solve your problems because even purchased systems must be cobbled together, requiring unique API’s, unique UI’s, unique portals, and unique mobile applications.
Does OutSystems play a role in helping companies cut tech debt?
The core of what we do at OutSystems is focused on tackling those three fundamental problems. We understand that technical debt amasses slowly over time, through a myriad of decisions that appear much smaller at their onset than their totality would suggest. Once these “tiny” decisions become a major problem, they inhibit investment in current operations and future innovations.
The increasing pressures of today’s fast-paced business environment often push companies toward decisions that spiral into technical debt. The good news is that by creating a development process that marries short-term deadlines with long-term strategic goals, it’s possible to “pay down” that debt.
I believe that any company is capable of whittling away technical debt with the correct tools and processes, and I founded OutSystems because companies shouldn’t have to choose between building fast and building right.
To learn more about technical debt, how to combat it, and what to expect in the future, you can download the 2021 Technical Debt Report 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.
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.
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 >>
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.
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 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.
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 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.
Grammarly has a simple but ambitious mission: to improve lives by improving communication. Every day, our AI-powered writing assistance helps 30,000 teams and 30 million people communicate clearly and effectively wherever they write.
But behind our technology is a team of engineers. Until recently, our engineers focused exclusively on building a product for consumers. When I came aboard to lead new initiatives as the Director of Engineering for Grammarly Business and Grammarly for Developers (expanding our product to support teams, organizations, and third-party developers), it was clear Grammarly approached full-on hypergrowth.
Then the pandemic changed everything. Suddenly, we found ourselves transitioning to a remote-first organization amid hypergrowth hiring and onboarding. The company doubled in the past year to over 500 team members, and my teams have grown even faster.
To be successful, we needed to spearhead initiatives that solved two problems. The first involved people: How could we successfully maintain a culture reflecting Grammarly’s EAGER values in a remote world? The second was technical: What tools and practices would enable our team members to thrive?
Transitioning to remote
Historically, Grammarly has had an in-person culture. We have four hubs—in Kyiv, San Francisco, Vancouver, and New York. But when I joined in July 2020, everyone was remote. Few assumed it would stay that way, but the “return to normal” kept getting pushed further back. Eventually, Grammarly adopted a remote-first hybrid model.
With “remote-first,” Grammarly team members work primarily from home. However, we continue to believe in-person interaction builds trusting relationships and a supportive culture that fosters innovation. So our offices became collaboration hubs where face-to-face meetups will also take place each quarter. We made this decision based on our progression as a company; because we felt we’d learned how to communicate and collaborate effectively and saw advantages to the remote-first model.
Keeping it personal
I look forward to meeting people in person at our first team-based meetup next year, but with my quickly growing team split between Kyiv and North America, we need to constantly build and maintain personal connections.
“I've onboarded fully remotely. I've only met four of my coworkers in person.”
- Dev Interrupted podcast at 19:33
Thus, we’ve tried our best to foster a thoughtful approach to team bonding at Grammarly—which signals that breaks and fun are important, too.
Some example approaches:
- Events celebrating everyone’s individuality and encouraging personal connections
- Coffee/donut chats, compliments of Grammarly
- Virtual hackathons
Our events motivate people to break from work and connect with each other. Activities range from educational to creative and silly, including an Indian cooking class during Diwali, a graffiti workshop, a cocktail class, a Halloween costume competition, and Grammarly’s twelfth-anniversary talent show. This personable approach also translates to how we chose the tools for remote collaboration.
Finding the proper tools
Setting hypergrowth teams up for success requires investing in the right tools and processes. As often as possible, we try to implement asynchronous communication and development best practices. Proper tools that facilitate organizational transparency are critical for alignment in a remote-first company.
Fewer people are required in Zoom calls because we share recordings and notes in open Slack channels. For collaboration and stakeholder alignment, our Engineering teams use Confluence for documentation, Jira for issue tracking, and Figma for collaborative interface design. Architecture and whiteboard sessions occur in Miro, while team retrospectives happen in Parabol.
The archival component of these tools is invaluable; new and old team members alike can discover information through Glean, which gives us aggregated search across all our tools and content.
Embracing the talent diversity potential of remote work
One of the most exciting opportunities with remote work is in finding hidden talent in overlooked geographies. Silicon Valley gets all the attention, but it’s not the only region with great software engineers. There’s plenty of talent out there just waiting to be found.
“Genius is evenly distributed by Zip Code, but opportunity is not”
- Mitch Kapor, Kapor Capital
Finding talent in other locations also leads to more organizational diversity. Whether that diversity is racial, ethnic, socioeconomic, or generational, diverse teams are going to improve your product. I’m a huge believer in diverse teams for two reasons:
- Better problem-solving than homogenous teams: I’ve witnessed this in my career, and it’s been proven with studies. Creativity naturally flows from visible and invisible diversity. Companies embracing differences will achieve better outcomes because the ensuing creative conflict helps you innovate and build better products.
- Stronger empathy for the customer: In Grammarly’s case, building writing assistance for the world’s 1 billion English speakers makes diversity in engineering critical. For example, those speaking English as a second language often visualize the language differently, leading to feature ideas that wouldn’t occur to primary English speakers.
You need a diverse team to build the right product for a broad audience. We’re excited to use recruiting tools like SeekOut and partner with organizations like Elpha and AfroTech to help us connect with and hire engineers from underrepresented groups.
Onboarding
But hiring isn’t enough! Many organizations are too focused on hiring, at the cost of onboarding. How we onboard folks and make them feel welcome is critical to their long-term success at Grammarly.
A small test of our onboarding process is whether new engineers can push code in the first week. If they can, it’s a signal the dev environment is well documented and has minimal friction. The faster people can be productive, the more confident they feel, which ultimately boosts team morale.
That said, onboarding is about more than pushing code. Engineers are encouraged to meet people and learn the product before they feel pressure to deliver. New engineers have a Getting Started Guide that includes who to meet and links to resources. Managers check in daily to answer questions. They also pair with a non-engineering Culture Buddy plus a mentor from their team so they can get to know all aspects of Grammarly life.
Thoughtful onboarding during hypergrowth helps new team members build connections, which leads to better team health in the long term.
Staying Grounded
My advice to any organization about to engage in hypergrowth is to remain thoughtful. Think about hiring, onboarding, your processes, how you measure success, and how you want your employees to feel when they join your team.
Remember, too, that diversity is more than a checkmark or an abstract goal. Diverse teams will be your strongest asset. They will push creative boundaries—and in doing so will build the best possible product with the best possible outcomes.
_
Want to join us in helping 30,000 teams at thousands of companies succeed through effective communication? We’re currently hiring for roles across the Grammarly Business and Grammarly for Developers teams.
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
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:
- Full Research Study: McKinsey & Company - How software excellence fuels business performance
- Short-Form Assessment Tool for Developer Velocity (5 Questions)
- Long-Form Assessment Tool for Developer Velocity (10-15 Minutes)
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>