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.
In my role as an engineering manager, I know making the leap from an individual contributor (IC) to engineering manager (EM) is not a promotion. Instead, it’s a different career track. What we are discussing here is a fundamental difference in terms of the responsibilities of the roles. What you do as an engineering manager versus what you do as a developer is fundamentally different. There is a possibility that you might not write code altogether. A promotion means continuing to do the same thing, while being paid more to do it. Becoming an engineering manager means transitioning to a different role with different responsibilities. In other words, a separate career track.
First, let’s break down our target audience into two groups. One group who is transitioning into engineering management. And then, the second, folks who have been made engineering managers recently. For those who are still considering, this decision could be made due to a couple of factors. It could be tenure-based, it happens in many companies where you are the senior-most engineer, or you have spent a fixed amount of time. The company or the team believes that you're ready for managerial responsibilities, asking you to make the switch. This is a more traditional track that we see. Alternatively, there's a more interest-based approach that you could be even at a mid to senior software engineer level.
An important clarification with this is when to use the term "tech lead" and "engineering manager" interchangeably. The Tech Lead is a system owner, and the Engineering Manager is more of a team/people manager equally. So the former is responsible for the overall success of the architecture while the latter is responsible for the team success, motivation and morale of the people they manage.
There are some key signals regarding both the tracks (IC & EM) to be aware about. They are:
1. Amount of coding time
Are you able to compromise on the technical output that you will end up with as an engineering manager versus a strong engineering IC? If you are coding 60 to 70% of your time currently, let's say it's going to reduce to 0 to 30% of the time. Yes! ZERO is a reality in this case. I have spent months where I'm literally not doing any coding in my role. There are EMs out there who would say they are able to still do coding and remain technical in terms of writing code day in, day out with an EM role. But, honestly, I don't believe that is a scalable practice.
If you are still taking on critical hands-on development tasks as an engineering manager, you run the risk of becoming a bottleneck for your team. For instance, if you are not available during the week, you need to do a lot of performance reviews or you are in some strategy meeting.
2. Focus time vs meeting time
Are you okay with spending 50-75% of your time in meetings and tackling action items? If a company is in a hiring mode or if there is a performance review season, or if there is just any ad hoc conflict that comes up, or mentorship in your one-on-ones with direct reports, there are many meetings/commitments. This is especially true now with remote culture and distributed teams. The amount of context needed to succeed in this role is quite high.
3. Definition of success
Are you okay with the definition of success becoming vague? What I mean by that is, as an engineer and an individual contributor, there were days where my code would pass, I would complete the feature, the build was great, I would get a dopamine boost at the end of the day and I could say, "Wow, it's a productive day!" Basically, I could see clear output as an engineer when I completed a task, or my work was released.
As an engineering manager, it's difficult to define what success looks like for you personally, because there are no metrics which tie to individual engineering management. For an engineer, it is lines of code or the amount of work you completed, features you pushed, zero bugs introduced. All those things are great success indicators for a strong engineer.
For an engineering manager, you must find your own metric set of what success is, which is ‘maybe there was no conflict in the team this week’, ‘maybe there was no deadline that was missed this week’, ‘maybe there is no question in terms of the meeting’ that I had with the stakeholders, and everybody clearly understood the requirements that were there for that week. Overall, it becomes abstract, and you need to self-identify what success looks like.
Sponsored Section
Want a better understanding of your success as an engineering manager? Need to understand how your team is performing? LinearB automates your teams metrics program so you can drive continuous team improvement - and provides your developers with tools to help improve, orchestrate, and automate their work.
Are you okay with the mindset of being an enabler versus a creator? As an engineer, an individual contributor, you have dedicated time to implement features. It’s your job to create things. However, as an engineering manager, you are responsible for enabling the creators to do their job. So, you are unblocking the team, you are giving clarity to the stakeholders, you are giving clarity to the team, you are providing updates to the leadership, you are sharing updates with other teams. Thus, you are enabling a lot of information sharing and removing bottlenecks for your teams and team members.
For me, it's clear that the engineering management and leadership track is a parallel career ladder on a separate track. It is a lateral move in that sense. It's not a vertical move and it's important to know the difference. The good part? In my experience, it is worth attempting to become an engineering manager because if it doesn’t suit you, you can always go back to being an individual contributor.
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 >>
Everyone has their own definition of true leadership. What I didn't understand at the start of my leadership journey was that each of us is a leader. Regardless of intent, we influence and impact our communities, industries, workplaces, and relationships. Yet, often we don't understand the importance or impact of simply being present. So I wanted to write a message to anyone looking to grow into engineering leadership. This was the letter the younger version of myself needed and I hope that it will highlight the importance of self-empowerment in your journey.
To Whom it may concern,
Anyone remember by history has taken it upon themselves to venture down their own path. In some instances, these individuals stood their ground and continued forward in the face of violence, war, political and economic systems, beliefs, and stereotypes never before challenged. And so they changed the perspectives and consequently the lives of individuals around them. These individuals didn't stand out by being just like everyone else. Instead, they took up the metaphorical shovel and paved their path by taking actions in alignment with what they believed and desired.
Impact is Power
I want to bring attention to the notion of impact. These leaders influenced others to pursue their own paths even when they weren't speaking. By simply showing up in their spaces and picking up the shovel, they allowed others to do the same. These leaders understood what others would have to do to take up their own shovel and make way for their path. This is progression. This is the beginning of leadership. This is power.
No leader does anyone in their community good - whether leading an engineering team, organizing a non-profit, or elsewhere - by hating themselves, fearing their strengths, and refusing to take action where necessary.
Empowerment is the currency for operating with a sense of agency. There are at least two things you need to empower others: the first is power, and the second is integration. Power comes from authority and authorization and we can have internal and external centers of focus. Understanding how power and agency work allows for integration, and we can only begin to empower others when we include, communicate, invite, and co-create.
Leaders maximize their potential for impact. As an engineering leader, you get to facilitate and help lead the team to success.
The Emotions of a Leader
Let all that I've shared sink in. Just by being where you are today, you have proved that anyone else can do it. There's no escaping the power of impactful leadership. So let's share how our emotions and energies inevitably amplify the potential for success.
Leadership communities tend to focus on developing characteristics such as compassion or empathy in leadership, yet these traits alone don't make a leader in a workplace. Sometimes, these traits can cause us to take actions that neglect our boundaries, goals, and purpose. Therefore, we should consider how these traits can help us process our emotions and invest our energy properly into needed action. Leadership traits are like water. They allow us to flow and direct our energy. These traits don't substitute for the core strength of a leader.
When we can understand the impact and effect of authentic leadership, we can feel pleasure, motivation, pride, and joy for the work we do in the world. Leadership gets to be and feel good.
There are no shortcuts to realizing what leadership will mean to a leader because it's everything: joy, sacrifice, compassion, celebration, risk, gratitude, accountability, perspective, setbacks, success, etc. It's more than who we are as an individual, and it gets to be whatever you want it to be.
Empathy and compassion allow us to make our leadership feel good for others as well. For example, engineering managers that understand why it feels good for engineers on a team to deliver well-understood and maintained code on time, and make space to introduce specific practices that ensure these conditions are met.
The Core of it all, asking the hard questions
Every leader needs a purpose. How do we want to show up in the world? What do we want to create? What impact do we want to leave behind? These questions are important because how can you expect impact, integration, and success if you don't get them right? We'll all face setbacks, mistakes, conflict, and confusion. The core foundation of leadership is purpose. We mentioned self-empowerment earlier, but power is also derived from purpose.
It's similar to building a snowball. First, we have to pack the core tightly before adding additional layers of snow. Else we risk crumbling. And like snow, our goals and purpose can change.
I encourage aspiring leaders to consider what it means to be an individual contributor, a leader, an engineer, a project manager, a product manager, and anyone else on your team. Then, ask the hard questions and start to forge an answer, even if it's not the right one the first time around.
In closing
Leadership doesn’t happen overnight. Making it a reality means taking up a shovel and doing the hard work. It means continually empowering yourself, connecting and investing in others, and asking hard questions. Our software code is always in the pursuit of being understood, loved and in service to others. As an individual in an engineering manager or leadership capacity, we influence to make this a reality for our teams, communities, and industry—best of luck to those seeking true leadership.
This letter shared some insights into power, connection, and purpose as a leader. I hope it was useful to anyone looking for some encouragement related to being a leader in their capacity. Please feel free to connect with me if you enjoyed this piece or have any questions.
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 >>
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 >>
Have you ever attended an event in which you were asked to give advice to someone starting something new (career, baby, wedding)? Whenever confronted with that question, my answer is "don't take people's advice." Not because all advice is bad, but because all people are different. I am unique, and some advice applies to me, and some not. Here are some of the items people have advised me, and why they may, or may not work.
1. “Don’t be too technical... or not technical enough.” Both? Sure… I cannot tell you how many times when functioning as a systems engineer, I was told, “You know how developers are…" Well, yeah, I coded for many years. And how often do we hear that the stereotypical engineer should not be a manager because of social awkwardness or the inability to delegate? I feel that it helps a team to have someone with hands-on experience lead them - somewhere in the middle is the best.
2. “Don’t bring treats to the office.” I can’t tell you how many articles say that if you bake cookies you’ll never reach “the corner office.” Why not? I guess baking gives the impression of being a submissive woman. People play golf, collect baseball cards, even brew beer. It is a hobby. And I love to bake. I made the most amazing ginger molasses cookies for a birthday last year. (Recipe at the end of the article!) It is also a stress reduction technique for me. In a former job, we did a management simulation for a class. We found that one way to keep morale up was to feed your team. Overtime? Get pizzas! Celebrate birthdays and accomplishments! We did really well in that exercise (until we were confronted by a debilitating snowstorm). But if I’d listened to the bad advice of many people - I wouldn’t bring treats to the office!
3. “Be assertive.” It is important to be assertive. And I am much more so than I was coming out of college. And maybe if I were better at saying no, I would not be writing this article… However, as the adage goes, “you catch more flies with honey than you do with vinegar.” On another note, there is something to be said for allyships, or the “good cop/bad cop” method. If I can keep the team happy and engaged, and someone else in the management chain or my tech lead may sometimes need to help me get a point across, would that be a bad idea? It shows teamwork and trust. Don’t over-index on assertiveness at the expense of collaboration and learning.
4. “Shoot for the corner office.” I have no desire to be in that space, figuratively or literally! I sit with my team and don’t mind interruptions (OK, maybe I need a “usually” on the interruptions). The past few assignments, I have been lucky enough to have the “Wal-Mart Greeter” desk, so I can be aware when people come by with issues, and I can experience the team banter. The idea of aiming at a corner office as a goal alienates you from team members.
5. “Working part-time hurts your career.” I worked part-time for almost twenty years, and was home after every school day to make sure my daughters were fed, taken care of, and got their homework done. How did that affect my career? Well, I got fewer raises and fell behind my full-time colleagues. But I learned to multitask, I learned time management, and I ended up with two amazing strong daughters who followed in my footsteps to become engineers themselves. You get to decide what’s important for you - and working long hours is not always the right thing for many people.
6. “Don’t have interests outside of work.” I am a big hockey fan, I read, I take nature walks and photos. I love live music, my favorite being metal. Again, how many stories do I have of people who think of me as a mellow music person (is it the cookies?) But, think about this, if you had a stressful day of work, and you are headed home in your car with the radio on, would it be more satisfying to hear, “You Don’t Bring me Flowers” or “I Sleep with One Eye Open?” You can guess my answer! Focusing solely on work will not only detract from your ability to connect with colleagues, it’ll create a life that you won’t fully enjoy.
7. “Look like a manager.” I will put it out there; not only am I female, but I am old, I am overweight, and I have blue hair. This is probably where I could go on a diversity rant. I’ll just say that the more uniform your team is, the more likely you’re missing out on some important outside-the-box ideas and perspectives. It’s far more important to be good at what you do and a strong team leader than to look the part.
So next time you give or take advice, or assume you know the job of someone you see in the office or the grocery store, think about what makes us, us; not what about us makes us who we or others think we should be. Appearances aren’t everything - and listening to the wrong advice can be worse than not taking advice at all. . . .
In a large bowl, beat brown sugar and butter until blended. Beat in egg and molasses. Combine the flour, ginger, baking soda, cinnamon and cloves; gradually add to brown sugar mixture and mix well (dough will be stiff). Cover and refrigerate for at least 2 hours.
Preheat oven to 350°. Shape dough into 1-in. balls. Roll in sugar. Place 2 in. apart on greased baking sheets.
Bake until set, 9-11 minutes. Cool for 1 minute before removing from pans to wire racks.
This article was written exclusively for Dev Interrupted.com by Judy Johnson, an active member of the Dev Interrupted Discord community.
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 >>
Everyone loves free stuff, right? Even better when that free stuff is both fun and adds value. That’s what Dev Interrupted’s upcoming event - The New Leaders of Remote Work - by engineering leaders, for engineering leaders - is all about.
Four remote engineering leaders join Dev Interrupted to share their insights and perspectives on the future of remote work - and how to successfully hire, onboard, and work remotely.
Join us from 9am-10am PST on August 11th for another great panel discussion with:
Darren Murph Head of Remote at GitLab & Guinness World Record Holder as the most prolific blogger ever
Lawrence Mandel Director of Engineering at Shopify & Hockey Enthusiast
Shweta Saraf Senior Director of Engineering at Equinix & Plato Mentor
And the Panda himself, Chris Downard VP of Engineering at GigSmart
Dan Lines, COO of LinearB, will be moderating a discussion with our guests on how they lead their teams remotely, how the current workplace is changing, and what's next as the pandemic continues to change.
Want to learn from the new leaders of remote work? Then this livestreamed Dev Interrupted Panel is the event for you.
<Register here>
We're excited for the future and very thankful to have you on this journey with us. You can always reach me for feedback (or site bug reports!) via our developer Discord community or onour Twitter.
Thanks for everything -
Conor Bronsdon
Community & Content Lead, Dev Interrupted
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 a company with 100 employees, there can be over 10 individuals with some form of neurodiversity such as ADHD, Autism, Dyslexia, or others.
While neurodiversity exists on a spectrum of intensity for each person, it’s still a significant number of people that could easily not be able to be working to their full potential because of poor accommodations. And according to acas.org.uk, 1 in 7 adults are neurodivergent. So how can you help make your teams and offices friendlier and less hostile to these employees?
Fresh from the Dev Interrupted discord, we’re taking a look at what the Dev Interrupted community has to say about handling neurodivergence in the workplace.
Hold open dialogs with your employees
“I'm the neuro-divergent individual at my work. ADHD and Anxiety disorder. After my concussion last year I now have vertigo. The big thing is overcoming the stigma and asking for what I need (and being honest with myself about what I can do). I've found my employer very accommodating. I would suggest that companies have open dialogs about it so employees are comfortable to come forward.” - Discord member JimMCKeeth
An open dialog with the employees of your company and teams regarding neurodiversity can indeed be a great help--Not just for anyone who is confirmed to be neurodivergent! Awareness makes it so that people can learn how to accept, understand, and work with people with neurodiversity.
Reducing stigma and myths regarding certain disorders such as ADHD, where one common belief is that adults cannot have it because of the mental image of ADHD only being present in young hyperactive children, is highly important! Knowing that your team members can understand how you function and how they can best approach you if you’re needed for something can prevent a lot of unnecessary distress and conflict.
As a simple example: Imagine that you have a colleague named Brian. Brian has problems switching tasks on a whim because of his ADHD. He needs to mentally prepare himself for each task and carefully convince his brain to focus on the task at hand.
Now imagine that you have an impromptu meeting, and Brian has to be there. The meeting is happening right now, so you go up to him and tell him to come to the meeting. Brian had no time to mentally prepare for a task-switch, and may be left frustrated and unfocused afterwards.
So what should you do instead?
Let’s say that Brian told the team that he has trouble suddenly switching tasks, and requested that you avoid making him have to do so unless absolutely necessary. Instead of having the meeting happen right at the moment that the majority agreed it would happen, you could agree to have it happen in 5 minutes, and give Brian a heads up.
5 minutes can already be enough time for Brian to be able to mentally prepare to switch tasks, as he can then finish up the segment he was working on and move onto the meeting instead.
Of course, Ideally, you’d have most of your meetings planned out a few hours before they happen instead, as that way you can prevent having to cause any potential issues in the first place.
I can personally say that being aware of the difficulties my colleagues can experience, and them knowing what difficulties I may have, has made our ability to work together much more smooth. It’s far too common for people to experience constant frustration because we’re expecting to be talking and working with neurotypical people, however by being considerate and understanding towards each other's struggles, we can reduce friction and create a more positive experience for everybody involved.
Actively support the individual
“I had an employee a few years ago with PTSD from time in the Marines. We worked together to make sure that he had a place where he could work, and also to make sure that everyone knew how to understand him. He is a great guy, but could seem severe and prickly if you just looked at him, which tended to keep people away from him. Communication with those he worked with, and some really easy interventions on my part, helped him to have a very successful time with us. I remain friends with him today.” - Discord member Drdwilcox
While making the team aware of how to go about handling neurodivergence is one part of bringing a comfortable environment, it is equally important to give focused attention to the employee in question. Approaching them when they seem to be struggling, working together with them to see what could help them, and discovering what their needs are.
This is something that I wished had happened more throughout my own life, even before I knew of my own ADHD, because even if you don’t know that someone has it you can often notice that something is off when looking at how they’re performing. And usually, they’re underperforming!
Even if you know that none of your employees or colleagues have any disorders, it never hurts to check in with them when you can and make sure that nothing is holding them back. As a review study of burnout prevention programs states, 80% of all programs successfully reduced cases of burnout in individuals. Imagine how much help individualized support could provide!
Making the workplace less hostile
Open-plan and noisy offices, my mortal enemies.
Many people can tolerate an open plan office that often comes with an array of little annoyances, some even actually quite like it for the social aspect. But they’re poison to people with ADHD, who already struggle with keeping themselves from being a distraction from their own work.
It doesn’t help trying to hold your developers accountable when there’s distracting noise being made. So what sort of accommodations for ADHD can you provide?
“I hate asking people to stop making noises. So I don't, and when I can't take it anymore it comes out in bad ways, like giving people dirty looks. Yes, we can talk to people, but then I'd be doing it all the time. And I might be the only one, so now I'm that guy who's always bugging people. Why not just ask people to be considerate? Take off your headphones and put them on the desk. Can you hear any noise out of them? Then they're loud and everyone else can hear them.” - Discord Member Scothannen
Confrontation can be a difficult thing to do for people that have disorders that affect their ability to socialize, such as individuals with autism. Having to constantly tell people to be quiet or to tone something down is a lot of work and can also strain relationships with coworkers who might just get annoyed- Especially if there was no agreement regarding noise in the office.
If possible, having a space where employees can move to that is meant to be total silence is one solution. A quiet room--similar to how some trains have silent cabins. If you want to be in an undisturbed area, you can go work there instead of the main area. This isn’t a realistic solution for every company though, some simply don’t have the space to do this or need high-powered workstations versus a portable laptop.
Providing noise-cancelling headphones is another solution, but that comes with the problem that people will come by to disturb you by tapping you on the shoulder instead. Perhaps having a simple “Do Not Disturb” card that is easily seen on the desk, where there is a mutual understanding to not go and tap the person on the shoulder. That way one can differentiate between a colleague that is alright with being disturbed while having their headphones on, and a colleague that really isn’t.
All in all, it all boils down to three words: Communicate, Support, Reduce. As long as you can actively communicate with your team about neurodivergence, and you actively offer support and look for feedback from neurodivergent individuals, you’re already taking several steps that many would never even consider. With time and experience you can then learn and work on how you can prevent any issues that your neurodivergent coworkers could end up dealing with, and while it may be impossible to completely eliminate a problem you can certainly reduce the stress.
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 >>
