Dan is the founder of Tellspin, an on-call scheduler in Slack for DevOps and developers (https://tellspin.app). Helping workspaces reduce their contact footprint, resolve incidents faster, and regain deep focus.
Code smell is a way to describe code that hasn’t aged well and has the potential for a lot of issues.
It usually is the source of a lot of hot fixes or workarounds keeping it functional. My most common reflex is to rewrite it. However, if I’m not careful, I’ll waste an entire day and not improve anything.
After a decade of programming, here are my 7 steps to reduce code smell gradually.
Step 0: Admit there is a problem
I start to recognize my code is smelly when I start saying things like “that time only took an hour.”
I’m usually doing something simple, like adding another field to a form or another schedule for a customer. I quickly add in code because it feels like the easiest thing to do and ship the feature. There are so many other things on my plate, I don’t have time for this, I’ll say to myself.
By the 5th or 6th hour I’ve hacked the same spot, I realize, had I rewritten it sooner, I would have actually saved time.
Step 1: Identify spots to clean
Smelly code is so disorganized.
Is it really smelly or do I just not understand it? It’s very tempting to always default to a rewrite. If I write all the code, I’ll understand it. But who is to say the next person who looks at it will?
Similar to profiling code to identify the slowest spot, I work to identify the place that smells the most. Are there sections of the code that new devs are always struggling with? Are there frequent small changes that require touching lots of different files or methods?
Creating a list of smelly code helps identify which sections of code need the most attention.
Step 2: Pick the worst spot
Smelly code is like dirty dishes.
With a stack of dishes, I’ll plug my nose until I dispose of the rotting food that’s causing the stink. It was easy to blame the whole pile, but for the most part, all of the other dishes are fairly clean. They don’t need immediate attention. The rotting smell came from something I forgot to clean off when I was in a hurry.
When there is a piece of code that’s really rotten, it’s often hidden somewhere in the pile. Maybe an abstraction went too far, spreading a hundred lines of code across dozens of files.
I keep in mind that I need to fix the worst smell; most of the other code is good enough and doesn’t need my immediate attention.
Step 3: Resist the urge to do everything
Smelly code is never-ending.
Perhaps the hardest part of improving a code base is scoping it to one thing. It’s so liberating to finally get a chance to clean up, that I can easily take it too far. I’ll think, “While I’m at it, I might as well clean up this… oh! and that other thing needs fixing too.”
Resist! Do not do everything.
If I try to tackle everything, I’m not going to finish. Even more likely, it’s not going to pass code review. It’s better to do one piece at a time - ya know, like eating an elephant.
Step 4: Make sure it’s better
Smelly code has edge cases.
Inevitably, in the process of rewriting, I discover why the code was written that way in the first place. I might even stumble across a can of worms. At that point, I realize my not-so-dimwitted co-worker wasn’t as dumb as I thought (or even more likely, I discover I was the one who wrote the code originally 🤦♂️).
After learning all the edge cases, I’ll be tempted to walk away.
Step 5: Don’t immediately give up
Smelly code is messy to work with.
I’m frustrated imagining how far away the current code is from a better solution. I’ve got the code in my head, I know the edge cases, and I’ve got the context. It’s important not to give up as the solution may be right around the corner.
I keep thinking about it while I go for a walk. Maybe even take a break. Solutions often come to me while I’m on walks or in the shower.
Step 6: Use the co-worker bobblehead
Smelly code needs attention.
I steal my co-worker’s bobblehead and explain aloud what I’m doing. In the process, I figure out what I've missed or overlooked.
If a bobble head isn’t available, I resort to using my actual co-workers. (I’m checking my assumptions by walking them through what I’m thinking step by step.)
Step 7: Publish or throw in the towel
Smelly code can improve.
At the end of my steps I have a complete solution or I’m banging my head on the keyboard. If it’s the first, I push the change and take a breath of fresh air. If it’s the second, I commit it to a branch and plan to revisit another day. Sometimes we can’t have nice things.
Rinse and repeat
The depth I go into each step changes based on complexity or how critical the code is. Sometimes I can run through each of the steps in a few minutes, other times it’s spread out over a few weeks. It really depends on what I’m working on.
Running through these steps helps me gradually improve my code. There’s nothing better than finally getting a fix for some smelly code merged and into production. Sometimes we can have nice things.
Dan Willoughby is the founder of Tellspin, an on-call scheduler in Slack for DevOps and developers (https://tellspin.app). Helping workspaces reduce their contact footprint, resolve incidents faster, and regain deep focus.
Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.
Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.
Listen and subscribe on your streaming service of choice today.
How will the wars of the future be fought, and who is heading these advancements in technology? Back in 2017, the US Air Force created a program called Kessel Run, which aids war fighters in the realms of DevOps, Agile, and UX, and the head of this project was an analyst by the name of Adam Furtado. In February of 2021, we interviewed Adam on the Dev Interrupted Podcast and shortly afterward hosted an AMA on our community Discord server.
Adam is the Chief of Platform at Kessel Run, and his story of how he almost single handedly led the US Air Force from 1970's software delivery methods to modern DevOps is one of the most incredible episodes of Dev Interrupted we've had. Adam talks about translating engineering to military officials and how he had to shift his mindset from application development to creating a system of systems. Listen to the episode here:
This Community AMA took place on February 26, 2021 on the Dev Interrupted Discord.
Necco-LB: 📢 📢 Community AMA📢📢 @everyone
Topic: Scaling Agile & DevOps
We're getting started in 15-minutes! Adam Furtado joins us to share his experience and expertise in scaling his organization (Kessel Run) from 5 >> 200+ developers!
Necco-LB: Let's get this thing started! @here
Welcome to our little community Adam! I can honestly say your episode of Dev Interrupted this week was one of the most interesting episodes I've produced.
Adam Furtado: Thanks for having me! I'm happy to hear that. Fighter jets are inherently cool.
Necco-LB: I don't think anyone can argue with that. To start things off, Adam can you give the community some quick context about Kessel Run? How many developers in your organization, what you’re building, etc.
Adam: Sure thing, KR is an Air Force organization proving that government-led software development will lead to better mission outcomes than outsourcing our software to companies that specialize in building airplanes (and using the same processes for their software). We build applications for warfighters to more efficiently strategize, plan, execute, task and assess the complexities of air campaigns. We have grown to about 1300 people… I’d guess. 400 of those are developers.
luisfernandezbr: Adam. What are the top 5 tech/dev metrics that you consider important to measure on a dev team? (Not product metrics like MAU, MRR).
Adam: I think they change as an organization changes... but for the most part I love the DORA 4... I think when used properly (and together!) it can tell you quite a bit about where you need to invest in your organization. The relationships between the metrics are what drives the value and I think often get forgotten about.
Necco-LB: Were you looking at different things (metrics or ways of visualizing work) when KR was smaller vs today?
Adam: For sure. I led most of our app development at first and we were/are an XP shop. Our teams were always very diligent about pulling the next story from the top of the backlog etc., so we never really had a WIP problem. When I moved over to lead our platform org, they were using a poorly-executed pseudo-scrum model and all of a sudden all of the DeGrandis/Kersten/Kim stuff I have been reading my whole career started to make a ton more sense. In building internal services, it was amazing to be able to see why work visualization matters and SEE the constraints building up. I'm so glad that I made the switch to build the empathy needed to be a more effective leader.
Necco-LB: Sounds like a big jump indeed. I have to say I’m wicked curious about how software development is different from within the military vs. the corporate environments most of us know.
Adam: Traditionally, the DoD was a case study in poor waterfall dev. Years of requirement development by people very removed from the work, leading to a contract being put in place that could only feasibly be won by a big defense contractor, years of development to "deliver" the "finished" software to be tested by separate government test organizations for a year or so and then "fielded" manually by folks traveling around the world putting CDs in machines. We've proven that all that risk avoidance actually INCREASES risk and we've had it backwards all along. To biggest thing we focused on early was how to reach Continuous Delivery with the heavy GRC requirements that we have in Defense (and rightfully so). So we worked with a forward-leaning IT leader in the Air Force to create and pilot the first Continuous Authority to Operate in the DoD. So instead of an approval to deploy to classified systems at the "end", we got our processes approved so everything coming out of our org was approved to go into those production environments. That’s prob the most unique thing.
luisfernandezbr: How you measure the evolution of your dev teams? And what initiatives and practices you use to grow them (like Dojo's etc)? What content do you recommend about DeGrandis/Kersten/Kim?
Adam: Deploy Frequency, Lead Time, Mean Time to Restore and Change/Fail Rate... Accelerate is the bible on this one (Forsgren, Humble, Kim)... Phoenix and Unicorn Project for Gene Kim's take on how to transform IT to DevOps approaches in big, slow companies... Making Work Visible by Domenica DeGrandis is a fantastic book on understanding what keeps us for being as productive as possible.... Mik Kersten's Project to Product on increasing flow. There are a ton of others, but that's a good start.
Read the unedited AMA and join in the discussion in the Dev Interrupted Discord here! With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. Join the community >>
drdwilcox: Thanks for joining us. During the podcast episode you talked about gaining momentum with some early wins. How did you keep that momentum going?
Adam: We struggled there, to be honest. The early wins were so much easier to "sell" to stakeholders. "There wasn't an app before... now there is. So I'm impressed". The first year we were deploying MVPs left and right and were the Belle of the ball. However in building large scale systems, we started focusing a lot more on our infrastructure, data models, optimization, internally efficiencies... and things that were providing real value- but weren't as visible. Those things are a lot less interesting to stakeholders. The Government has a very output-centric approach to value. We have focused on building an outcome-driven organization, so there is always a conflict when discussing what is or isn't valuable.
drdwilcox: I don't think it's just the government, to be honest. I have the same struggles in my private company. Output as defined by Product are sexy, all the other things are not. What was effective for you in getting the stakeholders re-engaged?
Adam: It's still a work in progress, to be honest. We constantly harp on the risk of NOT transforming in this way. The 2018 National Defense Strategy hits on this hard and all of our Senior leaders are pushing the same message. So that has been really helpful. General Brown, AF Chief of Staff, has done a great job of being clear about where we need to drive, so that allows us a bit of a trump card when we come into contact with someone who is trying to hold back progress.
Necco-LB: That idea of selling to stakeholders is really interesting, especially in the military. What did you have to say or do to convince your higher-up that the counter-intuitive dev methodologies like releasing more frequently was worth a try?
Adam: We had no support early on. The incentive process in the military rewards people who follow the rules and work within the system. We sort of worked quietly off to the side on a project nobody really cared about to prove the value once delivered. Once we got that delivered… we had MASSIVE dollar savings, so we started to be loud about it. In fact, we were told not to use the “Kessel Run” moniker by higher ups… we decided to do it anyway and started promoting pretty hard. By the time our first FastCompany article came out, all those senior leaders changed their tune and now they will say they were supporters all along. I am constantly doing that translation/evangelism work. And in the military, people swap out of positions every year or so generally, so some new person will get dropped in with no idea what’s going on and we need to start over again. “Nope, the cloud is a real place…” Continuous Delivery has broken every gov process. The test community doesn’t know what to do or look for… Requirement Managers don’t understand their place. Configuration Management is just…. Different now. I don’t need some guy managing a spreadsheet of what versions of software are deployed where. We are in a weird transition period right now. In a lot of ways those stakeholders are sick of hearing from me. I'm sure they hear Charlie-Brown-teacher-voice when I try to discuss this stuff at this point. So we have worked on finding the proper champions in higher up places to do that work for us. The very top of the Air Force totally gets it. It's everyone in between who need to keep their head down to keep rising in the ranks. (Tale as old as time...)
Necco-LB: Geez, what a thing. I can't believe you have the energy to continuously fight these battles within your own organization.
Adam: Someone once told me a story about this dad who brought his family to the beach. They had this big, pink inflatable bunny that the kids were using in the water. Every so often the bunny would deflate and the kids would run back up the beach to the dad and he would huff and puff and blow it back up. Kids would be happy and go back in the water. An hour later, kids are back again and the dad is blowing it back up. This person said "that is what innovation in the government is like". Every once in awhile you need someone or something to "pump up your bunny". The work I do is so exciting and fulfilling, all the BS that I have to deal with, all the money that government employees are leaving on the table, the bureaucracy ends up being worth it.
Necco-LB: That is a great analogy. Reminds me of how you talked about the mission driven culture at KR on the podcast. Can you talk about why you believe the culture of your organization is so important? And any advice you might have for organizations who are bifurcated?
Adam: Organizational alignment is incredibly important. One place we have struggled is that we put such an emphasis on teams, that teams built strong individual identities. They were empowered to solve their problem, but over time became less concerned about other teams' problems. This was never more evident than working with the ops/platform teams. The app teams knew what their users needed and all they cared about was meeting their needs. Meanwhile, we had a whole organization with organizational outcomes that were the priority. Let to a lack of empathy across teams and the communicate at the seams of teams was challenging. We are still digging ourselves out of that, but one thing we focus on is that mission-driven culture. All it takes is a day like yesterday, with airstrikes in Syria, to level-set everyone on the seriousness of our work. The mission aligns the teams towards a common goal and common outcomes.
luisfernandezbr: Adam. Thanks for the great tips. What were the big challenges that you had when increasing the dev team? Things like knowledge sharing, share learning and maintain quality and excellence. Could you share some tips about this, if it is the case?
Adam: We sucked at all those things. That mission-driven culture led us down the unenviable path about feeling so much pressure to deliver and support our users, that tech debt mounted and documentation suffered. We struggled investing in automation in favor of getting short term wins. The last year we have really rebalanced and ensured that we are providing space for our teams to organize their time better. None of it was intentional, but regardless of what we said, we (leadership) were giving off the vibe that teams couldn't possibly slow down to invest in tech debt or spend time focusing on automating toil away. We have had to be super clear that it is EXPECTED that teams work at a sustainable pace, invest in their code bases, invest in their professional growth and personal health and be okay saying "no". We have a lot of military members on our team, so saying "no" to your superiors is always a culture change we have to work on internally.
Necco-LB: Working on technical dept and automation vs. new features is something everyone can relate with for sure. I think we'll let Adam get back to his far more important job at Kessel Run. One last question, if someone here wants to get involved with Kessel Run, where can they go? Should they reach out to you?
Adam: This was fun- thanks for having me. You can follow me on Twitter at @adamsfurtado or you can reach out directly at afurtado@kr.af.mil. To follow along with KR, you can follow @kesselrunAF on most social media platform. I'd also like to plug that we are currently hiring for a bunch of roles from product leadership to engineers. It's an incredible place to work and you can make a real impact. Please take a look and reach out to me with any questions! Thanks again!
Antonette: Job opportunities at Kessel Run here: https://grnh.se/3201d1713us
Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.
Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.
Listen and subscribe on your streaming service of choice today.
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.
Consider checking out Shweta Saraf’s thoughts on the topic of remote first, and not remote friendly, in the video below!
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 >>
The office of the 20th century is a testament to design. A great deal of thought goes into the layout of a building. How are the offices laid out? Where are the elevators located? Where will teams meet? But the focus on co-located office space is quickly becoming a relic of the past. To meet the challenges of the 21st century GitLab's Head of Remote Darren Murph is pushing organizations to put just as much thought into their remote work structure as they would an office building.
For many companies, the transition to this mindset comes with difficulty. They've shifted into remote work as a necessity, but maintain the 20th-century ‘office-first’ mindset. While this is passable and can work, it's not ultimately taking advantage of the key benefits of a virtual atmosphere.
To take advantage of the shifting dynamics, GitLab is using their own platform to consolidate all of their virtual collaboration. Providing a single source of truth, GitLab has designed the virtual version of a central hallway where all work is funneled. This breaks down organizational siloes and enables the GitLab team to collaborate with maximum efficiency, by making sure that everything is as visible and as transparent as possible for everyone in the organization.
A company’s ‘central hallway’ is going to look different from organization to organization, but the takeaway for all remote organizations and engineering leaders should be the importance of de-siloing information across your organization. This will encourage virtual collaboration and boost creativity.
Meetings that Support Remote Culture
A Chief People Officer once asked Darren, “How do we make our meetings better?” His response? “Make them harder to have.”
Darren believes that you should have as few meetings as possible because people deserve to be able to focus on their work. From this belief flows the practice of using tools like Slack or Microsoft Teams to gather consensus asynchronously, and then reserve synchronous time for meetings where only decisions are made or important status updates are shared.
This has the effect of focusing a team’s attention which is important as teams become distributed around the globe, and time zones become a greater issue. It's far too easy for your entire day to be meeting with teams across your organization, with people coming online in various time zones to fill your day. Instead, the focus should remain on having critical day-to-day functions performed asynchronously - with meetings taking a back seat.
In addition to focusing an organization's efforts, being thoughtful about structuring remote work also reduces meeting fatigue. We’ve all experienced being on Zoom or other video conferencing software continuously throughout the day. Not only is it inefficient and distracting, but it can lower your company morale and leave you exhausted and feeling like you didn't accomplish anything during the day.
Darren’s ideas may have seemed radical just a couple of years ago. But he and the folks at GitLab are pioneering - and thriving - in today’s remote environment. The office of the 21st century is undoubtedly going to be virtual, so remember to put as much rigor and thought into your virtual work structure as you would if you were designing a building.
To learn more about how GitLab and other companies transitioned to remote work, check out Dev Interrupted's Remote Work Panel on August 11, from 9-10am PST.
Interested in learning more about how to implement remote work best practices at your organization?
Join us tomorrow, August 11, from 9am-10am PST for a panel discussion with some of tech’s foremost remote work experts. This amazing lineup features:
- 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
Don't miss the event afterparty hosted in discord from 10-10:30am with event speakers Chris and Shweta, as well as LinearB team members Dan Lines and Conor Bronsdon.
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 >>
Shweta Saraf, the Senior Director of Engineering at Equinix, has a particularly interesting remote work story: she experienced a fully remote acquisition during the pandemic.
Her former employer - Packet - was acquired by Equinix, a huge company with more than 30,000 employees and over 200 locations around the world. Suddenly, the small team at Packet who were experts at remote work found themselves in the position of trying to onboard not just themselves at a new company, but onboard an organization of 30,000+ to the principles, structure, and best practices of a fully remote work environment. Because Equinix is the largest data center company in the world, operating data centers and office hubs all over the globe, the switch to remote work had to be as seamless and efficient as possible.
One of the key areas Equinix first looked to be efficient was in their meeting practices. They began what they refer to as ‘Better Way Wednesdays’ (their name for a best practice also utilized by Shopify) as a way to better inform employees and leadership. These meetings paired with a monthly business memo, capture the state of business along with key achievements, challenges or blockers, and give senior leaders KPIs and metrics.
This practice made it possible to cut down on the number of weekly status meetings, where the same information is passed on in different formats or through different levels of abstraction. The investment in this practice paid off immediately. Teams found that the “Better Way’ meetings would often only take an hour, but would save tons of time across the board. It also had the added benefit of reducing zoom fatigue. More focus time and better communication were realized by a single meeting shift.
The biggest focus Equinix implemented was asynchronous communication, because of the many time zones involved and the number of people all over the world, including engineering teams. Rather than restrict productivity to a specific set of time zones, async communication gives employees the agency to be held accountable for completing their work on their own time. Meaning that it is no longer necessary to align employees on separate continents onto the same Zoom call if that information can be transcribed in a chat app.
However, for companies where office culture is strong, with ceremonies happening in-office, it can be a learning process to adapt to working completely remote. With Packet’s experience aiding the transition for Equinix, a cross-synergy of ideas was realized. Employees from both companies found themselves questioning former agile ceremonies, such as stand-ups and retros, and whether these can be done asynchronously, or if they require a meeting at all. The merger resulted in an easier working environment for everyone.
Equinix, a company of tens of thousands of employees and hundreds of locations, transitioned to remote work successfully during the pandemic not because they were remote-friendly, but because they adopted a mindset of remote-first. Meaning that a developer on the other side of the globe could participate meaningfully and not feel left out. While not every company underwent an acquisition during the pandemic, Equinix's journey to a fully-remote organization is a familiar story for many tech companies this year. To learn more about Equinix and how other companies transitioned to remote work, check out Dev Interrupted's Remote Work Panel on August 11, from 9-10am PST.
Interested in learning more about how to implement remote work best practices at your organization?
Join us tomorrow, August 11, from 9am-10am PST for a panel discussion with some of tech’s foremost remote work experts. This amazing lineup features:
- 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
Don't miss the event afterparty hosted in discord from 10-10:30am with event speakers Chris and Shweta, as well as LinearB team members Dan Lines and Conor Bronsdon.
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.
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 on our 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 >>
Who says developers and dev team leads can't be the life of the party? Come see for yourself why the Dev Interrupted Discord and Podcast have emerged as the go-to community for engineering leaders. Our developer discord has grown from 0-1300 engineering leaders in just the past 8 months, and our community is attracting the attention of CTOs and VPs of companies like Netflix, GitHub, and Gitlab.
We're incredibly honored that so many people are finding this community valuable and we’re excited to keep the party rolling with our newest launch: devinterrupted.com - whether you're a developer, a dev team lead, a CTO or VP of Engineering - we want you to feel welcome.
We've built the Dev Interrupted website to serve as the central hub for our growing community. Our mission is to create the most active and engaged community of engineering leaders possible - and to give our community the opportunity to contribute and learn more.
The Dev Interrupted Site Includes:
- A centralized repository of our podcast episodes with background info
- Video clips and talks with engineering leaders
- Articles and guest posts from leaders in the engineering community (Like this open source article by Logz.io's VP of Engineering Doron Gill)
- Our community events page
As members of our community, we also want to give you some visibility into what's on the horizon for Dev Interrupted.
On Our Roadmap:
- Q&As with leaders and community members
- More guest articles from community members
- Live podcast recordings
- More Discord events
- Podcast episodes with leaders like Slack’s VP of Engineering Rukmini Reddy
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 on our 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 >>