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:
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.
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.
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:
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.
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!
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.
I try not to get involved in arguments - but when a debate started in the Dev Interrupted Discord about if exceptional continuous improvement (CI) or continuous delivery CD) makes a group agile or not, I had to jump in. I’ve helped build many high-performing teams with agility, and I know that neither CI/CD nor Scrum makes an organization Agile.
It’s Not What You Do, It’s How You Respond
Probably my favorite way I’ve ever heard someone describe agility was that it’s about moving away from believing we can predict and plan everything to sensing reality and responding to it instead.
Consider two extremes. In the “predict and plan” view of the world, we build a feature list, come up with screens, represent that in a backlog, and dutifully execute in two-week chunks. This approach focuses on accurate plans and predictions in the early stages. Mistakes in the early stage compound rapidly later on.
Are these folks agile? What did they sense and respond to?
A different group has a sense of problems to solve and their relative importance to one another. This group decides the goal for their next investment in a sprint. Every day they look at what happened and determine if they need to change course. They frequently shift direction mid-sprint because they’ve learned something new. Are they agile? What are they sensing and responding to?
Both teams are following Scrum’s rules, but one has lost all its ability to respond to new information, and the other, while it seems chaotic, is using near real-time data to guide their next steps.
Regardless of how you do it, agility is a lot more like the second group than the first. You can tell this not by the meetings they have or titles like Scrum Master, but rather by the frequency with which they make decisions that significantly change their direction.
You Have To Have Working Feedback Loops
A way to detect weakness in a group’s pursuit of agility is to examine the strength and length of their feedback loops.
Scrum is a framework, which is a weird way of expressing that it has a few useful pieces and room to figure feedback loops for yourself. The parts it does have, though, are a series of events and structures that provide feedback loops.
A feedback loop is an activity where you can pause to look at the results at the end. A chef that tastes their own food as they prepare it creates a feedback loop. A chef that never tastes their own food or waits until the dish is finished to take a taste, does not.
If you think about the events of Scrum in terms of feedback loops, every activity has a counterpart that closes the feedback loop. Sprints have Retrospectives, Increments have Reviews, and each day has a Daily Scrum.
All too often a Sprint Review is nothing more than a team saying they did a bunch of stuff with no actual feedback happening. The same can be said of Retrospectives, where the team produces many stickies, but no change manifests. The Daily Scrum Is a daily feedback mechanism, but all too often reduced to merely a task status update.
Scrum puts the potential to leverage these feedback loops in place, but they don’t work by themselves. So you can easily wind up with a team building a two year roadmap, executing on that roadmap, but never recognizing the signals that there is actually no market for what is being built.
Sponsored Section
One way to ensure quick feedback loops internally? Cutting the review time for code in your development process. WorkerB developer automation tools by LinearB can give your team proactive notifications of changes in their PRs and update developers on long PR review times while correlating the PR to the relevant project issue.
I often see groups espousing that they are agile because of some activity they do or capability they have. In fact, that very behavior is what inspired me to write this article.
It can be tempting to look at agility as a feature list or series of checkboxes that, if you complete enough, you’ll summit the mythical agile mountain. But if those things aren’t so important, are the rules important at all?
Well, they are, but it’s just not enough.
Organizations and teams put a lot of emphasis on getting the basic structure of Scrum in place but tend to get into the rut of standing pat with those structures, and so the promise of agility remains elusive. These groups similarly work hard to cut things that they’ve been told are not agile anymore. Basically, they focus too much on the form, and not enough on the function.
You have my permission and support to keep using work-breakdown schedules as you pursue agility.
On the one hand, you need the form to be correct, or you can’t get the benefit. On the other, if you only follow the form, you stand in place.
So with my teams, I look to see if our process is “alive.” With a clear purpose for each activity, I can quickly see which of them are exhibiting signs of weakness that will disrupt feedback. Then I can intervene and bring the form back to accomplish its purpose.
For example, in a talk I give about Daily Scrums, I say, “The purpose of the daily scrum is to begin the day’s collaboration and coordination towards a sprint goal.” Most daily scrum meetings miss the mark of that purpose.
Looking at things from this angle, we can mature our forms and get the benefit back.
Change Takes Time
There is a fascinating intersection between these concepts where we recognize we want to address weaknesses in how we practice agility, but have difficulty estimating how to move forward and how long these changes will take.
One aspect to this is that we do need those forms to be in place before we can sense and respond to it. In my experience, a change in these forms takes about three months to normalize in a group.
When I introduce more advanced concepts like Test-Driven Development or Work-in-Progress Limits, I introduce those forms and also hold them in place for three months. This time frame might feel slow, but it comes down to how we as people handle change.
What we’ve done in our past is what frames what makes sense to us today. Our brains crave that feeling that the world works a specific way. When we disrupt that, people’s instincts are to reject the change. Even if it is a rational and logical change, we’ve disrupted what is normal. The three month adjustment period seems to be enough to allow change to take hold and for a new normal to be realized.
During that whole time, though, the form has to be sustained.
So as much as adherence to form can be a trap, it also is the scaffolding for change.
Learn to be Comfortable with Change
My honest advice for leaders who want to make things a bit better is to get really comfortable with microscopic change for a while.
An example might be phrasing a question differently -- a small change.
Take an honest look at how you view things working best along a spectrum of plan and predict and sense and respond. Make sure to compare how you think you do to the actions that actually take place. There is usually a disconnect there.
Next, look at an opportunity within the existing forms to strengthen a feedback loop. Using something as simple as phrasing a question differently -- a small thing -- can completely alter the course of a Review or Retrospective or Daily Scrum. A thoughtful question that encourages feedback can easily improve things..
From here, you can continue this pattern of making small adjustments to how you and others move towards sensing and responding and leveraging the forms of Scrum to become truly agile.
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 >>
In the past year-and-a-half, going remote has been the primary goal and focus for many companies and individuals. The beginning of the remote work overhaul was rocky to say the least but now that all this time has passed and workplaces have figured out how to work with it and not make it an utter mess- Is it worth keeping? Is it better than being in-office? Should remote work be a standard for dev teams, and in-office be secondary?
Well, that depends on a couple of factors. With some feedback from the Dev Interrupted Discord community, let’s dive into the advantages and disadvantages of remote work.
The Disadvantages
Team bonding is difficult
“It's not impossible or anything, but I've found it's so unbelievably easy to bond with a team in person doing regular lunches and such. (...) I miss being able to see someone frustrated or struggling with something and walking over to them with a couple other people and saying "let's head to lunch and clear our heads." You build bonds very quickly when you do demonstrable human things to reduce someone's stress.” - Discord User The Panda#2143
Jumping off from what The Panda said, the first major disadvantage that many people will voice is a lack of genuine team bonding when your team is fully remote. It requires much more active effort to bond with your teammates over Zoom. Being around another person naturally speeds up the bonding process much more than occasionally messaging someone because you need something.
When working remote, your team needs to be intentional about team bonding. An excellent way of maintaining some form of social bonding is to have a weekly meeting where you can just sit down and chat with your colleagues, talk about what you did on the weekend, maybe occasionally host a “show and tell” of your own. Figure out what fun little trinkets your colleagues collect! Another popular weekly meeting idea are “coffee talks”, which are informal breakout rooms hosted on Zoom that can be hopped into or out of at will.
Team leaders also need to be sure to regularly schedule fun events - whether in person or online - to bond team members. This could be a happy hour where everyone gets shipped a cocktail kit and makes them together, or a digital magic show, an in-person meet up, or something else.
Video Call Dread
Sometimes, it is just the most inconvenient thing to be forced to have to sit around in a conference call several times a day to get things done. Text is confusing, unclear. But you have to discuss things somehow, so you end up calling. And calling. And calling- is it just me or is it simply exhausting to sit around with the “important work meeting” looming overhead in between everything you do? Even many industry leaders and remote work proponents discuss what they often refer to as “Zoom fatigue.” In a recent remote work panel hosted by LinearB, video call dread was highlighted as a major downside of remote work.
“My kid’s school over the last year has been trying to keep us involved, and one of the ways they’ve done that is booking these Zoom sessions in the evening. I notice when I get [to the meeting] I just don’t want to be there. I’ve been on video all day long.” - Lawrence Mandel, Director of Engineering at Shopify
One of the biggest appeals of remote work is that you have so much freedom to do things on your own time and create focus time, but it is nearly impossible to feel comfortable doing a different activity for a while when you’re still in “work mode”.
So while in reality you do focused work for 4-5 hours, mentally you’re still working the whole 8-9 hours. The meetings and work you do aren’t consecutive and are instead the equivalent of a car starting and stopping in a traffic jam. Every hour or two, you have to sit up and move .5 metres before you sit around and do something else again. It gets exhausting.
Despite everything, remote work is still built around the idea of being in an office for nearly half the day. Which really shouldn’t be a surprise, as remote work was never about changing the working hours, but the expectation often comes with it.
Lack of printer access.
Okay, Really, this isn’t the biggest disadvantage but it's something that I, as a young man under the age of thirty, found highly amusing. I can guarantee that a majority of people today just don’t own a printer. And that makes sense, you generally don’t have to print a lot these days! Though, in many cases, having an on-paper copy of a digital file is reassuring to have. (At least for me, I prefer having paper copies of important documents over a file on my desktop!) If you’re going to be working remotely, you may have to invest in a printer. Or hope there’s a copy-shop near you. You really don’t realize how convenient having a printer at work can be until you’re forced to work from home.
You’ll also likely be forced to learn the true cost of printer ink if you haven’t already. Oh dear.
The commute was a benefit!?
For many people, the commute is a huge issue. Especially if you have to drive a car, or take public transport. In cases like those, getting to work remotely and avoiding that mess is great!
“I miss my commute. It was a 10-20 minute bike ride depending on the route and the weather. I would do it year round in a winter climate, and I always was very happy about the forced fresh air in the winter. The idea of jumping on a bike in subzero snowy weather seems terrible until you're out there, so it made the fresh air and exercise happen.” - Discord User ParksideBrad#9930
To some hardy souls like ParksideBrad, the commute was actually a beneficial and nice thing. Either way, losing that two-birds-one-stone manner of exercising and getting to work can be a noticeable hit to your daily schedule. While this can be solved by just exercising on your own time- it’s harder to have to intentionally build that into your routine. It’s hard to exercise without reason ( “Getting healthier” isn’t really the best motivator for many, even if it's important.), so using “Going from point A to point B while exercising” as a manner of getting that important movement in is a very valid way of keeping yourself healthy mentally and physically.
The Advantages
No commute? Perfect! (Sorry, cyclists!)
Alright, so sure, I did just write that the commute could be a benefit for those that like to exercise. But really, for a majority of people it was always a pain. Getting an extra hour to yourself in the morning is a significant bonus as you don’t feel the need to rush yourself out of bed to avoid any traffic. And getting extra time to yourself just throughout the day? Honestly, the following words by some of our community members emphasize how much better a lack of a commute is for many people:
“With no commute and no office tying me down, it's easy to work from just about anywhere the internet exists. This facilitates living in new places, experiencing new things - which is amazing! ” - Discord user NobilityPNW#7631
"One big disadvantage of Remote Work: avoiding commute times! I do not miss commuting at all! I save a ton of time that I can use for work or for work/life balance and necessary tasks. I'm also significantly more flexible." - Discord User Conor#3700
More hours in the day are dedicated to you
Your 24 hours in the day are not the same as Beyoncé.
This is a sentence that often gets thrown around in the following way: “You have the same 24 hours in the day like [insert celebrity or billionaire here]”. Sure, you both have 24 hours to do everything in the day. But the allocation of those hours is vastly different. Because unlike Beyoncé, you can’t hire people to do your cooking, laundry, cleaning, etc, for you. You don’t get to leave all the painstakingly long chores and commutes to others.
But thanks to remote work, a lot of these things get a little less bad. Sure, you’re still working at home, but you can take breaks. You can control your activity, your time. You decide if you want to go take a brief pause to play a short game with your kids, or if you want to have a coffee with your partner. You get a chance to spend more time with your home social groups, your family, your loved ones.
“I was on a call with Dan Lines recently talking about Linear B and my 6 year old came into the room and attacked me with a nerf sword. It was short lived, not terribly disruptive, but it felt good to me knowing he had access when he needed it (I survived unscathed). For most of his life I was gone 60-80 hours a week or traveling around the country. Since we went fully remote, we are very close and he feels sad if I have to go downtown for the odd meeting once a month. It has changed our family for the better and when I feel a stronger connection to my family and like their needs are being met, I can focus all my excess energy on whatever I want.” - Discord User The Panda#2143
You finally get a printer
Congratulations! You have a reason to buy a printer. Hopefully it’ll last you for the next two decades at minimum. May the prices of ink cartridges remain low for you.
The flexibility of work-locations
Being able to work wherever at any point in your workday is an incredible advantage, especially if you struggle to stay focused being in an office environment. Having the chance to get away from the “ADHD poison” that noisy offices often are… Sitting at a quiet cafe in the park, or working from the couch at home with your beloved cat purring away, it all makes for a much better environment. And then being able to change that on a whim when you decide you’re no longer comfortable? Even better. After all, this is the easiest way for a company to support employees that may need a calmer environment to work in.
But this isn’t even just about being comfortable- it also means that if there are any issues you’re having in your home (such as construction), or your internet is down, you can still stay in touch by being able to connect anywhere else. Rather than having a whole office-outage take out several hours (or potentially, days) of work because something went wrong with the network or power.
Allowing for remote work makes you disability-friendly
This is not just for people who are disabled that apply for the job, but also for those that may become disabled during their time working in your teams. Unfortunately, life isn’t perfect, and a sudden health issue could turn out to heavily impair your wellbeing. Before remote work was standardized, if you could no longer go into work on a daily basis you would most likely end up having to quit your job. But now, maybe you can still work with your disability as long as you’re at home. Or as long as you can take frequent breaks, which are made far easier in the comfort of your own home.
The Conclusion
There’s certainly more advantages to remote work compared to the disadvantages, but this is a case where the disadvantages shouldn’t be left unaddressed.
The disadvantages often fall into real problems that have some half-solutions. But honestly? The best solution might be to reduce the amount of in-office days, and have an option and support for full remote for those that need it. Most people would be happy to go into the office for just a few days a week while staying remote for the rest. And let’s not forget that this’d be the perfect way to allow people to continue wasting printer ink at the office instead of having to invest in their own.
In the end, you must admit that giving employees agency over their hours tends to leave them happier and with a more positive outlook on their jobs.
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 >>
INTERACT is the biggest thing Dev Interrupted has done yet. An interactive, community-driven, digital conference on September 30th - by engineering leaders, for engineering leaders. 1 day, 10 speakers, 100s of engineers and engineering leaders, all free.
Why attend?
Incredible speakers: You’ll hear from engineering leaders who have scaled teams - 4 VPs of Engineering, 2 CEOs, and 1 CTO - sharing their successes and failures.
It’s Interactive: We’re not just talking about live Q&A. Meet the speakers in Discord, vote to influence the sessions, share your opinions, and be part of real-time content discussions with other engineering leaders.
Continuous Community: Learning and growing doesn’t stop when INTERACT is over. The Dev Interrupted Discord Community has 1,500+ engineering leaders sharing ideas and helping each other every day.
Metrics alone don't improve dev teams. Software Delivery Intelligence (SDI) helps dev teams continuously improve by turning insight into action. Unlike top-down engineering metrics tools which become shelf-ware, LinearB is a dev-first platform and provides value to every member of the team. Development organizations using LinearB's SDI cut their Cycle Time in half after only 90 days. The result for developers is less bureaucracy, fewer interruptions, and more time to build. The result for teams is fewer process bottlenecks and accelerated delivery. Activate Software Delivery Intelligence for your dev team in 5 minutes at linearb.io.
DZone.com is one of the world’s largest online communities and a leading publisher of knowledge resources for software developers. Every day, hundreds of thousands of developers come to DZone.com to read about the latest technology trends and learn new technologies, methodologies, and best practices through shared knowledge.
The fastest growing online community for developers to stay updated on the best developer news. Together they supercharge developers’ knowledge and empower better software.
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 >>
