Tag: remote

  • Navigating the World of Distributed Workforces

    Navigating the World of Distributed Workforces

    The ever-changing software development landscape continues to bring new opportunities and challenges to developers and businesses that hire developers in equal measure. Whether it’s breakthroughs in quantum computing, extended reality development fueling growth in the gaming industry or the deepening complexities engulfing the regulatory landscape, there’s a lot in store for the DevOps community in the coming year. Developers will become increasingly crucial for businesses aiming to future-proof their bottom lines. Tech companies, especially, must grasp the significance of accommodating a distributed workforce to address the diverse needs of a rapidly evolving market.

    Distinct from the conventional understanding of ‘remote’ work, a distributed workforce refers to a deliberately formed team structure that operates from various geographical locations. This model, propelled by technological advancements, is set to evolve significantly, transforming communication and collaboration across distances into a seamless process integral to the developer’s journey.

    What’s Driving the Distributed Workforce Trend?

    There are many reasons behind the popularity of distributed workforces, but some of the main drivers behind 2024’s expected growth include:

    ● Global expansion: As businesses grow globally, having a distributed development team allows organizations to tap into a deep understanding of the essence of a particular language, country or market. This local expertise and cultural awareness contribute to better market penetration and customer satisfaction.
    ● Legal and security considerations: Some industries may have stringent regulations requiring staff and all sorts of contractors and vendors to be of a particular nationality or have a physical presence in specific regions. Compliance with these regulations is easier to achieve by strategically distributing team members across relevant locations and ensuring adherence to legal and security requirements, all while maintaining operational efficiency.
    ● The need for 24×7 operations: By placing team members across different time zones, organizations can ensure continuous coverage throughout the day and round-the-clock productivity.
    ● Cost optimization: By mixing teams from higher and lower-cost regions, businesses can create a cost-effective structure.
    ● Talent availability: The distribution of the workforce is highly influenced by the talent shortage; for example, in the UK. As some geographical locations are known for their expertise in certain industries and technologies, organizations look to these areas for access to a wider pool of skilled professionals.

    Ongoing and Future Challenges

    While more and more organizations recognize the benefits of a distributed workforce, it’s not without its challenges—both for the businesses employing the model and the in-house developers adjusting to it.

    For businesses: These may include having the HR capacity to effectively manage talent recruitment, retention and relationships in the context of near-/offshoring, shortly followed by legal and security concerns. Hiring remote workers while navigating legal frameworks across different locations and ensuring the security of intellectual property and collaboration terms are challenging.

    Additionally, businesses must grapple with extending corporate social responsibility, equality and representativeness initiatives to destinations where local traditions and business environments may not align with standards set in the location of the organization’s headquarters. The traditional ‘offshore’ model—where time zones don’t align—coupled with project fragmentation across various sites, makes asynchronous collaboration, is also a key challenge.

    Retaining talent within distributed teams is another significant hurdle, as methods effective locally may not suffice, requiring new retention strategies. Then, even with these in place, the time required for onboarding becomes crucial for quickly integrating effective replacements or extensions to existing teams. All of this underscores the importance of vendors who possess expertise in managing these aspects within remote teams and are poised to apply and develop these essential skills on a broader scale.

    For in-house developers: When transitioning to a distributed workforce, there may be difficulties in conveying ideas leading to misunderstandings or delays, struggles in adapting to new collaboration tools and technologies such as virtual collaboration platforms or challenges in working collaboratively due to the lack of spontaneous in-person interactions.

    Without effective communication strategies and time given to developers to adapt to new norms, practices and expectations, maintaining team cohesion and engagement can be more demanding in a distributed setup.

    Security concerns also sit with in-house developers as well as business leaders, as they must ensure the security of ideas, code, setup and sensitive information, all while adapting to what may be new security protocols and practices established for the distributed work environment.

    Meeting the Evolving Demands of Distributed Workforces

    Addressing these challenges requires a proactive approach that establishes good communication, collaboration and a supportive remote work culture.

    Alongside using the skills of recruitment vendors, who play a pivotal role in meeting the evolving demands of distributed workforces, employee training and up-skilling is crucial, especially when transitioning from a local to a distributed team within an organization.

    Training programs should focus on clarifying the reasons and goals behind the shift, defining roles and responsibilities post-transition, establishing effective communication protocols and channels and offering recommendations for practices that enhance the overall effectiveness of the new distributed setup. A training approach such as this will ensure that employees not only understand the strategic objectives but also acquire the necessary skills to thrive in a distributed work environment.

    Preparations should also focus on introducing new tools and methodologies for remote work, of which there are already plenty available, with more advanced tech expected in the upcoming year. Examples include:

    ● Employer of Record platforms: Platforms that facilitate compliance with legal requirements are experiencing substantial growth. The future is likely to see these platforms evolving to address not only legal aspects but also HR-related needs, offering more comprehensive solutions for managing distributed workforces.

    ● Remote collaboration tools: While high-speed internet and standard video conferencing tools have become commonplace, the emphasis will shift towards more advanced tools. Virtual windows and other innovative collaboration technologies will play a crucial role in enhancing the remote work experience and fostering better communication and collaboration among distributed teams.

    ● Team performance and delivery measurement practices and tools: As businesses strive for efficiency and effectiveness in managing distributed teams, tools that measure team performance and project delivery will become increasingly important. These tools, integrated into existing project management systems, will provide automated metrics and insights. Some forward-thinking vendors are already leveraging such methodologies to enhance remote team management.

    ● Advanced project and time management tools: Beyond basic project and time management tools, businesses will adopt more sophisticated solutions to streamline workflow, enhance productivity and track progress effectively. Automation in these tools will become essential for managing distributed teams and ensuring seamless collaboration.

    With a host of challenges, tech and demands—all of which are continually evolving—the key takeaway here is preparation. Only well-prepared development teams will be able to navigate the complexities of a distributed work environment successfully and see businesses ready to reap the benefits.

  • A Distributed Workforce is the New Normal

    A Distributed Workforce is the New Normal

    The pandemic emphasized and improved what we have known for decades: A team does not need to be centrally located to be productive. This varies based on the people involved and roles being fulfilled, but honestly, lots of people can work just fine from home, a coffee shop, the pool …

    And while we could debate the wisdom and usefulness of lockdowns forever, they did drive organizations that had never considered distributed work to actually take the plunge. Many are returning to centralized organizations, but a significant number of employees have moved to where they would like to live to work from home, and some of those employees will not be back.

    I normally avoid reference to any contentious societal discussion, but the lockdowns and pushback directly impact us in IT. The circle that was our network had already expanded to include public cloud, hosting providers and SaaS providers. Now it includes all of those plus some–perhaps only one or two, perhaps many–home offices. And that is unlikely to change, no matter how hard an organization tries. If nothing else, motivated individuals will want to work from home after hours, and if they are salaried, the organization will support that approach—meaning we in IT will have to support that approach.

    A deep look at what that implies is necessary. One of the things that having a sudden “work from home or shut down” mandate imposed upon companies did was make security an afterthought. For the first couple of months of 100%-remote work, we saw crazy numbers of access misconfigurations that caused breaches. That’s just the easy one. Your source is in a publicly accessible repository. Are the tools to access that source secure? Are you sure? What about SaaS? Is there a method other than user-generated passwords required to access each SaaS? Do you even know what SaaS systems business users have adopted? Does the organization use password management? It is necessary since SSO isn’t covering everything, and really can’t.

    The same is true for accessibility. Management teams started with, “Let’s get people working,” because the alternative to people working was layoffs or even corporate bankruptcy. If you paid any attention at all in that timeframe, you heard the horror stories of IT going to employees’ houses and setting up or troubleshooting corporate desktops that went home. It was an ugly time, and only afterward did organizations start to consider options for handling communications. Is it policy to have someone go to a nearby coffee shop when their connection is down, or is that a day off? Can they work without connectivity and then upload afterward? Most organizations still don’t have coherent policies in this regard, allowing teams to decide. In fairness, not every employee is great at working from home, so it is possibly the best option to have team leads deal with failed communications issues … But a corporate policy or guidelines should still be developed, and technical solutions like satellite backup should also be considered.

    Organizations rushed to WFH and then rushed to return-to-office (RTO). Your job is to make sure that, with all of the rushing, things are stable and secure. You’ve been rocking it all along—don’t let shifting corporate priorities drag you down now.

  • Best of 2022: Return to the Office? Nah.

    Best of 2022: Return to the Office? Nah.

    As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    I was watching Charlene O’Hanlon’s interview with the CRO of Rollbar, discussing the slow growth of “return to office” policies. High-tech, because we are more mobile, had more options than many people—the janitor, for example, must be physically at their job to do it. High-tech employees did not have that issue—or if they did before the pandemic, they certainly didn’t after a few months of lockdowns. And now our infrastructure allows us to work from anywhere.

    One of the things that some companies are considering is requiring that all employees come back to the office. I rarely say things super bluntly, but this time, I need to be blunt.

    Fight that tendency if it shows up at your organization. At this point in history, that way lies corporate doom. Okay, maybe not doom, exactly, but certainly bad things. Some people back in the office is fine, a choice about coming back to the office whenever your state/provincial/local government decides to allow it? Fine. A required return for everyone? No.

    Of course, one cannot make such a blunt statement without an explanation. Do I think that remote work is somehow better for the company? No. Some people are more productive working from home, while others are distracted by the many non-work things around them that they want/need to do. So it is a mixed bag that requires monitoring. In all my years working from home and mentoring others just starting to do so, I’d say this split is closer to 50/50 than you might think. To paraphrase a sergeant from my army days, “Those who most want to are sometimes those who absolutely should not.” He was talking about living off-post, which is outside jurisdiction in much the same way that working from home is. And I’ve found some truth in that statement when applied to WFH. In fact, one interesting thing for me to watch were the success rates for companies that went 100% WFH. It’s gone better than I expected, probably because it was a broader swath of staff than just those who wanted to.

    So why would it be better if I, who have worked from home for more than 20 years at a number of different companies, think it’s a mixed bag?

    Hiring and retention.

    We know that we’re short-staffed. We know that it is hard right now to find any flavor of IT peep, but it’s brutally hard in InfoSec and pretty tough in DevOps. A decent percentage of employees is going to want to keep working from home, and in the current environment, they can change jobs faster than you can say “retention bonus” if you give them a reason. I don’t have hard numbers, but let’s assume a hugely conservative 10% of IT staff preferred working from home. Can you afford to lose that number of your staff? Or even half that number, assuming some won’t leave? Probably not, considering the openings versus employee counts we’re currently seeing. More to the point, can you afford to never hear from that percentage of applicants because they don’t want to work somewhere that mandates their physical presence in the office? From talking to people, it seems money doesn’t resolve this issue. Working from home is a tangible benefit, and whatever a company offers, the next one might match with the WFH option.

    There was a slow change going on in IT, where a significant percentage of staff were working at least part-time from home; the pandemic just sped that process up—shifted it left and iterated, so to speak, and now HR and management are going to have to deal with this reality head-on.

    I’ve felt that some of the positions I’ve held at some of the organizations I’ve worked at/for were best performed on-site. But we have enough successful 100% virtual companies now to acknowledge this might be a corporate culture issue and not a “job fit” issue.

    I don’t know how companies will handle it, but absolutism is not the way forward here, IMO. Charlene and Michael Davis had some thoughts on WFH and returning to the office you might want to listen to.

    After all, you all are kicking it, and I know some of you don’t want to go back to the office. Can your org afford to lose you? Not if there is an easy way to avoid it.

  • How Impact Mapping Can Align Remote Teams for Success

    How Impact Mapping Can Align Remote Teams for Success

    Impact mapping is ideal for creating effective cross-functional groups in a remote work environment

    Around the globe, teams have been adjusting to the current remote work environment. Those adopting a DevOps way of thinking may have had an easier time adapting to the rapidly changing situation.

    Yet, even for organizations used to remote work, there’s often a natural disconnect that crops up between teams that can hamper initiative planning and product launches. While teams within organizations may be conducting daily standups and adhering to agile ceremony cadences, communications pipelines tend to be more fragmented.

    As such, without a proactive and concerted communications and planning effort in place, it can be challenging for everyone to have a clear understanding of their organization’s objectives, let alone visibility into the work being done by their colleagues. Without this understanding, they run the risk of duplicating work or overlooking key performance metrics, and not delivering products that drive value for their customers.

    At a time where organizations are planning 2021 initiatives, impact mapping can help. This graphical strategic planning practice can be leveraged at any level of an organization that is looking to identify clear goals, build better lines of communication and map out the resources it will take to meet corporate initiatives.

    So how can organizations and teams take advantage of impact mapping?

    The 4 Elements of an Impact Map

    The goal or initiative: This should be specific and measurable. For example, “Increase customer satisfaction by 20% over the next 12 months.”

    The actor: The people or things that influence the eventual outcome. An actor can be a team member, but it can also be a piece of software or a group of people (e.g.: customer service).

    The impact: An assessment of behavioral changes necessary to achieve the goal. For example, a behavior change could be a decrease in the number of units a customer returns to the business.

    The deliverable: Any changes (or work items), platform updates and/or product features that will need to be created or improved to achieve the goal. In this case, reach the desired impact and increase customer satisfaction ratings by 20% over the next 12 months.

    To create an impact map, a facilitator and business owner gathers a team of sponsors across the business. This could include product teams, operations, finance and sales. Over the course of several hours (or, sometimes, weeks) the initiatives are brainstormed and prioritized. Utilizing a digital whiteboard, such as Coggle or Google Jamboard, all team members are invited to be engaged and to contribute.

    The net effect is that all team members can be on the same page when it comes to the overall strategic goal behind the initiative and their unique roles in the process. When the prioritizing is complete, they can go forward and continue to work together to deliver the right features to align with the objective.

    Before that happens, there are additional steps that take place during the impact mapping process that play a vital part in the ultimate success of an initiative. Let’s take a closer look at a few of those steps.

    Building a Team

    As the goals, actors, impacts and deliverables become clear, so, too, will the resources that an organization will need to make the ultimate outcome a reality. Those resources may include individuals from various parts of the organization.

    For example, it may be determined that one of the best ways to increase customer satisfaction is to significantly decrease the number of bugs in a product. That might necessitate a higher level of involvement from security teams in the development and planning process. Getting these teams involved early will save time and reduce risk as their input is incorporated into the design from the very beginning, helping to create a compliant, bug-free product that will better deliver on customers’ expectations.

    The number and type of team members will vary based on the product and the goal. In some cases, teams may include members versed in user experience strategies, while in others it may be DevSecOps team members. Whatever the use case, once the team and roles have been established, everyone involved in the product will have a clear view of what they’re expected to do, and how their work aligns with the rest of the team and drives toward achieving the goal.

    Improving the Development Process

    Impact mapping can also be useful for identifying areas of improvement in the development process. It sheds light on areas that teams may not otherwise realize need work. For instance, perhaps team members will discover they need to implement higher quality tools or make changes to their integration testing processes. Or, their developers need better training on Kubernetes Operators so they can automate and expedite the deployment of applications.

    These deficiencies and others can be discovered before they end up impeding development. By creating more transparency in these areas, teams can focus on addressing them prior to delivery, resulting in a secure and more stable product that meets its objectives.

    Facilitating Better Communication and Collaboration

    The impact mapping process encourages collaboration and the sharing of ideas that can, in turn, spur other ideas. Through collaboration, team members can help each other solve problems and find new ways to address the impact and deliverable phases of the process.

    Closer collaboration also allows team members to help each other become more comfortable with any changes that might be necessitated by the impact mapping process. This could include the adoption of new technologies that the team may not initially be comfortable using.

    Consider if the development process calls for the team to adopt new technologies that will change their workflow processes. Such a move could take many people out of their comfort zones. But if everyone understands the reasons behind the change and a willingness to test it out, the change becomes more palatable. By working together, they can collaboratively troubleshoot issues and adopt new best practices for using the technology.

    A Good Solution for a Remote Environment

    While impact mapping sessions have been delivered in conference rooms or large meeting spaces with sticky notes and markers, the practice can also enable alignment when used in a remote environment. Being on-screen instead of in-person can actually bring out participation among members who might otherwise be shy or reluctant to volunteer ideas in a room full of their colleagues or managers, where they may be hesitant to speak their opinions. Team members may feel more anonymous in a remote environment and feel more comfortable speaking freely.

    In short, impact mapping is ideal for creating effective cross-functional groups in a remote work environment. No matter where they are located, everyone will have a better understanding of what they need to do—both individually and collectively—to create applications that deliver value to their businesses.

  • Remote Organization Model for the Win

    Remote Organization Model for the Win

    As the head of Sonatype’s product development engine, I’ve spent the last six-plus years scaling and hacking on the design and evolution of our fully remote organization. Over this period, we’ve learned a lot about what works, why it works, how to keep things running smoothly and what should be avoided. But none of that would matter at all if it were not for the fact that the fully remote organizational model gives us significant competitive benefits.

    Results

    As a small and growing company, we’ve had—and continue to have—an impact globally on software development, where roughly $2 trillion is spent each year. Our products and services are used by millions of developers every day with users of our open source Nexus Repository Manager, now in the millions, growing 68 percent last year.

    Remote Org - 01.jpg

    It is rare to have the ability to blaze trails that end up materially helping the world do something better. That’s the epitome of meaningful work, and it’s awesome to be part of it. Sonatype has significantly influenced the way software is developed not just once, via contributions to Maven and its numerous progeny including npm and NuGet, but twice, with the Nexus Repository Manager. And a third big innovation is well underway, with competitors working furiously to try and catch up. Nexus Lifecycle lets development teams automate the effective use of open source.

    These innovations with their consistent themes of “Better software, faster” were the work products of our fully remote product team.

    What Does the Team Think?

    There has been a steady stream of innovations and the business is growing, but how do the members of the Sonatype team feel about the company and the environment within which they are working? Can we accelerate progress and continue scaling the organization?

    We are currently rated an A+ (4.9/5.0) and have been trending up over the last year. The high scores here are indicative solid engagement by team members and positive trends are effectively leading indicators of future engagement levels. Additionally, our overall annualized employee retention rates have been >95 percent for the past three years in an industry where the norm is 77.6 percent retention. The remote model certainly doesn’t seem to be hurting us here.

    Remote Org - 02.jpg

    Side note:  The dip in the ratings graph was us breaking through a scale point that required some notable changes in organizational design.  It seems change is still challenging regardless of the remote model.

    The Remote Model

    It is still early days for the remote model. The remote organization design is not a common pattern for venture capitalists to match against. For VCs, unfamiliar patterns equate to unknown risk and I’ve been asked about this during board meetings. “Are we riding a tiger here? When are you going to open a local R&D center?” I will readily admit, I had some healthy skepticism very early on; however, my experiences as we have continued to scale have reinforced my position that this is a material competitive advantage for us.

    While this is by no means a scientific assessment—Sonatype is invariably a single data point—what follows is at least based on a small mountain of empirical data collected as our product team has scaled beyond the 100-person mark. And I can see an appealing path to 500 and beyond.

    Fallacies

    Remote Org - 03.jpg

    “People just work better when they can interact face to face.”

    Right … There is so much wrong with that statement that I just smile when I hear it, and I hear it often. While this judgment might seem intuitively correct on the surface, it is not based on anything but gut sense and is always made by people that have no significant experience with a fully remote model. These folks usually have experience or have heard about experiences with the (fatally flawed) mix of co-located and remote models. These are destined to fail for reasons covered a bit later.

    What does “work better” mean, anyway? (Yes, those are often the exact words used.) This statement is extremely narrow in scope when you consider broader workday activities. In a typical office environment, how often do you absolutely need to interact face to face to be effective in achieving organizational goals?

    Don’t get me wrong. The high-bandwidth exchange of information possible via face-to-face interaction can be extremely beneficial in the more limited cases it is needed and cannot effectively be compensated for through other means. But there is no reason that people cannot get together this way with the remote model. In fact, we do this multiple times per year.

    What is conspicuously ignored here is the material “tax” tied to persistent, often ad hoc, face-to face-interactions, which are often (poorly) compensated for by headphones, closed doors and other distraction-reduction techniques.

    “You have no idea if people are just off screwing around.”

    While I don’t hear this one as much as I used to (is Taylorism finally dying?), do your visual senses really answer this when everyone is on site together? Ever hear of the “boss” key? Regardless of organizational model, you have to be able to trust and verify. There are certainly mechanisms for accountability that don’t require standing over someone’s shoulder. Expectations must be clear and people must have what they need to achieve what is expected. This is standard stuff that has nothing to do with co-located or remote scenarios.

    Upsides

    There are a number of key benefits that collectively lead to significant gains in organizational effectiveness. The communications are balanced and self-optimizing, distractions are reduced, quality of life is higher and the number of amazing people you can recruit is enormous.

    Effective Communications

    The most significant benefits I’ve seen in the remote model stem from the level communications playing field that emerges. Everyone is equally “disadvantaged” in not having ready access to high-bandwidth face-to-face interaction. The people we have hired have been quite adept at compensating for this, and we have not had to specifically select for this ability in our hiring.

    Another subtle but material advantage is that all communications endpoints are equidistant. It is just as easy to communicate with someone on your team as it is someone on another team or someone in a different department or even the CEO. Everyone is a phone call, email, chat message or video chat away.

    It is also largely unappreciated (until you’ve experienced it) how many advantages offset the “limitation” of infrequent face-to-face interaction. First, the communications pathways that form are very often driven by business necessity versus seating location, political motivations, after-work interest or other factors. Second, at least in a product development context with a bunch of technical people that just want to get stuff done, there is more focus on the work and the corresponding results than the political or social aspects of the workplace. Finally, as noted earlier, you can still get together—and should. These engagements are targeted, focused and effective rather than the more ad hoc engagements in the co-located setting. We hold these get-togethers when kicking off significant initiatives and we also get the entire organization together for our annual (open spaces format) meetup.

    We also (judiciously) allow people to shift between teams as resource needs ebb and flow, which strengthens the overall fabric of relationships organizationally. It is hard to quantify the benefits here—and they likely span all organizational models—but this reinforces optimal communications and has been very beneficial as we have scaled. We have a far more ambulatory group of people with an extensive network of personal and professional relationships and diversity of expertise across our technology portfolio.

    Life is Good

    Not having to contend with a soul-sucking, energy-consuming commute on a daily basis is a major quality of life benefit for people. This also comes paired with plenty of options for a more reasonable cost of living for members of the team.

    There is something that you do need to watch out for, though. There can be a tendency for people to burn the midnight oil. While this might sound like a big benefit to members of the C-suite, product development is ultimately an ultra-marathon. You have to watch for signs of burnout and ensure people that are falling victim sufficiently dial things back to their maximum sustainable pace. The cost to replace a talented member of the team is far greater than the short-lived incremental productivity of someone working too much.

    Near Infinite Expertise

    Hiring the right people is a perennial challenge in any discerning organization, especially when you are just starting out. In a co-located model, you are competing in specific geographies, often with better-capitalized companies that have a lot of brand recognition. In the remote model, the number of amazing people you can connect with is effectively infinitely larger. We are able to open a really big door. When you are also able to eliminate the commute and offer challenging work that matters, a lot of exceptional people can be convinced to walk through it.

    One Note of Caution

    Time zone overlap is a key consideration. There must be adequate overlap and we have this around the U.S. Eastern time zone.  We span 10 time zones overall, from Central European Time to U.S. Alaska Time, and that is a stretch in some respects. Team members at the edge compensate by shifting earlier or later into the work day when needed, and this has worked well. Regardless, sufficient overlap is critically important. Spreading out any further than we are today is likely untenable, as the time shifting would likely lead to unsustainable quality-of-life challenges for people that are geographically distant.

    Avoid a Mixed Model at All Costs

    While scorned by many when she abolished remote working at Yahoo, Marissa Mayer was ultimately right to unify the model … she just chose the wrong model! (Actually, she probably didn’t, given the existing scale.) You can’t effectively mix co-located and remote models across an organization. This is because it is impossible to create a level communications playing field, or maybe you could but the effort required to level the field would drive effectiveness to zero. It’s simply human nature at work.

    Co-located members end up forging stronger communications channels and the channels with remote members weaken. Remote members become more isolated as seemingly innocuous interactions among the co-located people occur without them.

    This isn’t to say that people can’t work from home occasionally in the co-located model. This certainly works. However, you cannot achieve optimal organizational communications at scale with a primarily remote group of team members mixed with a co-located group.

    Perhaps you can mix modes, as long as you have a consistent mode across individual autonomously operating teams. We have not tried this, but I also sense this is not without material challenges and I have heard of some failures. I’d argue that many of the challenges tied to offshore development share similar root causes, leading to debilitating communications imbalances.

    At scale, there is still the equivalent of a team (or teams) that ultimately support these autonomous teams, often with some members of these supporting teams being part of the autonomous teams as well. This forces you to contend with a mixed co-located and remote model one level up and likely leading to (again) imbalanced communications. While this perhaps can be made to work, the real question is whether it can work with a sustained, high degree of effectiveness at increasing levels of scale. I remain skeptical.

    Compensating Mechanisms

    While there are significant benefits, the remote model has some challenges. These are the kinds of things you might expect, but thankfully, there are effective ways to respond.

    Product development is a team sport and the remote model affords a lot of opportunity to go off on your own. The lone wolf might flourish for a bit, but to scale, you need people who will reach out to others and solve problems with them, proactively. While this is true in any organization, I’ve found that it requires more vigilance to keep this in check in the remote model. Do not let bad habits develop.

    Similarly, it’s more difficult to stay mad at someone when you see them on a daily basis. I think most humans are probably about 99 percent irrational and 1 percent rational. Unicorns might have a 90/10 split. Regardless, many of us are absolutely amazing at seeing negative things that just are not there. The remote model can exacerbate this, and it can “take a village” to keep everyone grounded in reality (rational thought) rather than assuming the worst and starting a downward spiral. Just being aware of this goes a long way, making it easier to keep the irrational majority in check. Having a “no a-holes policy” is certainly useful, but pretty much anyone can still appear to be acting like an a-hole at times. Don’t console those griping about someone else. Push them toward reconciliation.

    The Lounge

    We created a chat room many years ago called “The Lounge,” a sort of virtual water cooler. Many other remote organizations have done similar things, and for us, this has been enormously beneficial in bringing “humanity” into the remote workday. It also helps connect people in otherwise distant parts of the organization. While it is not the same as getting together with people in person, it goes a long way in giving people a social outlet during work. Abuse has not been a problem, either.

    We’ve more recently started a number of special interest groups and guilds, all of which have their own chat rooms along with more topical banter. And most recently, we created a Google Hangout version of “The Lounge,” which has been a surprisingly effective social exchange. It seems hearing and seeing real laughter goes a lot further than reading “LOL” or observing some emoticon or emoji.

    Get Together, Live

    As noted a few times already, it’s important to get people together, in the same location, at key points. This is common advice in most of the other literature I’ve seen on remote models. These face-to-face meetings strengthen individual relationships that tend to slowly erode over time given exclusively remote interaction. We’ve found that a year is just too long and I’ve picked up on subtle cues from the organization as we have approached the nine-month mark. While there are numerous factors in play, my experience tells me that six months is likely the sweet spot for this. The timing might vary from organization to organization depending on the nature of the work, but reasonably strong social bonds are an important factor in holding everything together.

    Online Interaction

    In addition to getting together, the effective use of video goes a long way for multi-party exchanges. Body language is often useful, especially in the cases where vigorous discourse is needed. For 1:1 interaction where you don’t need to exchange visual information, voice is a personal preference, primarily because with my wireless headset I can walk around, keep my blood flowing and concentrate far better, really listening and picking up on subtle cues voiced by the person on the other end. Random factoid: My FitBit reports that I’ve walked a few half-marathons during some days without ever setting foot outside.

    Wrapping Up

    When contemplating a fully remote model, be prepared to go all-in at the point you do. Do not, under any circumstances, attempt a mixed co-located/remote model. That is a certain path to failure. Beyond a certain organization scale, the fully remote model is likely impractical if not impossible to migrate to effectively. I have no empirical data to support this, but if your organization is fewer than 20 people, the challenges of adapting to the remote model are going to be simpler. Beyond this scale, there is inevitably a lot more organizational complexity, not to mention business risk tied to the short-term productivity drop as everyone adapts and learns how to work in the materially different operating context. I’m not stating outright that you won’t be able to make the move beyond 20, but you should expect the challenges to be far greater and the time to stabilize longer.

    With the experiences I have had and the advantages we’ve realized with Sonatype’s remote organization, I cannot imagine choosing the co-located model if faced with the challenge of scaling an enduring product development organization from early days. I still have fond memories of sitting in a bullpen environment on University Boulevard in Palo Alto years ago. Without a doubt, the bullpen is a great model at the outset, when things are fluid and the requirement for high-bandwidth exchanges is nearly constant. However, the moment you are ready to scale beyond that initial bullpen, remote should be a serious consideration.  If you are growing, the option won’t be available for long.

    — Mike Hansen

  • Four Inspiration-Killing Concepts That Need Redefining

    Four Inspiration-Killing Concepts That Need Redefining

    Software engineering is a creative process, and creativity cannot be measured by the hour. It can be measured only by the value of the contribution. Yet, a majority of companies still measure productivity by hourly contributions. Companies treat the development process as if it still existed in the days of the assembly line, and all we needed to do was to affix 100 widgets a day. This mindset pisses off developers, kills inspiration and causes developers to quit.

    So, how do we measure progress in our companies? How do we ensure that we can increase our probability of success? These are necessary questions for businesses, and it’s easy to see why companies cling to the rules of the past. It’s all we know. And it is a big gamble to change. After all, shareholders and such.

    It will take true visionaries to rewrite the rules. And although many new companies are doing wonders for changing the way we define work, we still have a long way to go. So the question now stands: What does the ideal dev process look like in the future? It might be helpful to attribute new words to the dev process to help us gain better understanding.

    New definitions for the Internet Era

    Task → Contribution

    Approval → Collaboration

    Workplace → Remote

    Workers → Culture

    Task → Contribution

    Remove the worker from the assembly line, and give them a seat at the decision makers’ table.

    This trend has already started in the open-source community. What used to be a to-do or a task is now an “issue” on GitHub or GitLab. If you think about it, task implies, “You got to do this whether you like it or not!” It’s involuntary but necessary involvement; you being creatively engaged with the task is optional. We embraced this unnecessary definition and are justifying it for no reason.

    We have established that creative workers don’t like to be told what to do and how. We should have contribution meetings where creative workers decide what they would like to work on. Unfortunately, many decisions are made in meetings where business owners pre-decide needs and delegate to managers to distribute tasks among engineers. If you want to lose creativity in your team and make everyone feel bad, this top-down approach works exceptionally well. We see the Band-Aid solutions to this top-down approach all over the place now. The manager needed to find ways to motivate workers. How? Ping pong tables! Free laundry! Ice cream! You get the idea. Most creative people see right through that garbage. It’s only novel to inexperienced recent grads who have yet to understand how the real world works.

    You will not have an engaged workforce unless you empower them and let them decide how to give value to the company. The easiest way to achieve this is to communicate transparently to the company what the business requires and give a detailed description as to the reasoning. From there sit back and watch the engineers chime in and say, “Hey, can I do that?” or, “What about this other problem we have?” I believe we could then change the perception from, “This is what I’m expected to do,” to “This is what I’m contributing to the company and I’m passionate about it.”

    Approval → Review

    This change is also apparent in the open-source world, when you submit your changes to a source code repository, your peers can take a look at it and see if they can contribute to its quality. In the past, this process was called “approval” and now is called “review,” where in fact your peer is approving the piece of code you’ve written. Approval implies. “I have authority over you,” whereas review says, “I’m going to help you get this done.”

    Workplace → Remote

    Dave Gray makes some really interesting points about how we make decisions in his book, “Liminal Thinking: Create the Change You Want by Changing the Way You Think.” He suggests that we only have the ability to make theories, judgments and beliefs based on our personal experiences. And even in our experiences we are only able to process a minuscule sliver of the information available.

    picture1David Gray’s diagram of how we come to our understanding of what the obvious choices is in a situation.

    If we apply this idea to the way we feel about our workplace, then we can quickly see the we are reducing the number of creative solutions available to our workforce. If everyone one of your creative workers gets to work from 9 to 5 at the same desk doing relatively the same thing daily,  they will start narrowing their understanding of what is possible. Just imagine what different solutions might arise if your employee is sitting outside at a lake or in a crowded bar. Their experience would change, thus their well of experience deepens, and their concepts of what is possible, multiplies. Make sure your developers experience new things, both as individuals and as teams. This doesn’t just mean offsites for team-building. It means, let them follow their gut, and work from wherever they need from time to time. This doesn’t mean let them go solo and unplug for days at a time. They need to stay plugged into the team and be a contributing part to the culture, but they need to balance that with building fresh perspectives so they can contribute to the collective experience of the whole.

    Workforce → Culture

    Yes, I know. “Culture” is one of those buzzwords that now cause people to roll their eyes so far back in their head that they fall out. But it’s important to know why the concept is important in relation to the old idea of “the workforce.” When management thinks of its developers as “workers,” the developers are immediately dehumanized and turned into pawns. They are expendable and indistinguishable as creative minds. They act out of fear from punishment and rarely take chances.

    We are no longer cogs in the corporate machine. Our ability to take risks can make the difference between being one of the 99 startups that fail, or the one tech company that succeeds. Managing culture as opposed to a workforce means that we can focus on enabling workers to be as creative as possible. We can focus on nurturing collaboration and honest feedback. A healthy culture is one that is transparent and communicative. A workforce could give a rat’s ass about making positive change. A culture is a living breathing thing that everyone contributes to and improves. A culture is owned by the collective. A workforce is owned by a man in a suit at the top of the tower. Screw the man. Power to the people.

    Conclusion

    Now that we have an understanding of why we must redefine our terminology, it’s time to start defining practical ways to make the switch for each term. In my upcoming writings I will start to lay out practical ways to make the switch in your company.

    About the Author / Devrim Yasar

    devrim_yasarDevrim is the CEO of Koding, a San Francisco-based software development automation platform vendor. Connect with him on LinkedIn and Twitter.

     

  • The Pros and Cons of Remote Work in Ops

    The Pros and Cons of Remote Work in Ops

    Remote work in Ops is divisive. The perks of working from home, your local coffee shop or wherever can be quite obvious to engineers and contributors. But some team leaders and company execs aren’t buying into it. One faction sees it as a way to do better quality work. Another has watched deadlines and motivation fall by the wayside because of unresponsive remote workers.

    What are the advantages and disadvantages of remote work? What should you consider before you take the plunge into flexible hours and asynchronous communication?

    Why Do Companies Go Remote?
    Company leaders worry that remote work erodes culture. Workers fret that colleagues and reports don’t get enough done outside the office. And team leaders lose sleep chasing down time-sensitive updates and deliverables.

    Remote work can definitely present some challenges. So, why do companies go remote? Several find it can provide serious benefits when implemented properly.

    By considering remote workers, businesses are able to attract high- quality talent from a larger pool of candidates – that’s especially important in the technology and software world where recruiting top-notch engineers is often a company-level initiative. If your company is based in a geographically competitive market, this opens doors and extends your reach to premier candidates outside of that area. It also goes the other way around – engineers who don’t live in tech-focused cities are given opportunities to be a part of those companies and cultures and aren’t penalized simply for where they live.

    Some contend remote policies produce better work. GitHub argues that code doesn’t follow a 9-to-5 schedule. Remote work can enable engineers to write great code during their peak hours of energy, focus and productivity, rather than on a set schedule that doesn’t play to their strengths. Because all employees – and engineers – are different, remote work provides the option to hone that creativity and focus outside of normal working hours.

    Since we’re so used to operating online, both in our work and personal lives, remote work embraces that to make employees more efficient. Remote workers communicate asynchronously.In other words, they respond to messages and transcripts when it makes logical sense, without interrupting serious tasks or disrupting intense focus. Another plus taking communication online is that it naturally leads itself to fewer meetings, and more doing. You’d be surprised how much you can cover in a three-minute chat via Skype, Slack, Campfire or another communication tool.

    That’s to say nothing of fostering a more enjoyable work environment. Plenty of people believe remote work improves morale. Who doesn’t want to work flexible hours and code when they’re in the zone?

    Finally, remote work supports inclusivity and diverse teams. What are the chances that every single person who can meaningfully contribute to your company just happens to live within a short commute? Not only do distributed teams open up opportunities for skilled workers who live outside of tech hubs, they also make it easier for people to work around family and other obligations.

    For some close-knit teams, there’s no difference between chatting in Google Hangouts and meeting on-site in a conference room. Going remote helps everyone get more done, more efficiently and on their terms.

    How Do You Get Started?
    Remote work may not be for every company. Your business needs or culture might not work best in a distributed environment. But if you do want to give it a try, there are some basic ways to start.

    Using the right tools is key. 37signals, the company behind Basecamp, literally wrote the book on remote work, and most of their team works remotely, using the company’s Campfire chat client to aggregate company communications and keep everyone on the same page. Email works for some conversations, but project management tools like Asana, Trello, Basecamp and JIRA let you add state, metadata, and delicious permalinks to everything that needs to get done.

    Be judicious about which tools you pick, though. Text, video and voice all have pros and cons. You’ll need to use communication channels that make sense for your company’s work style. For instance, when teams that are used to face-to-face stand-ups switch to typed messages, there can be miscommunication and misinterpretation. You’ll get more value out of the tools that enhance your in-office interaction methods. You might have to adopt several tools for your needs: The developer team at Hanno, a user experience company, uses nine different tools to work remotely, including Basecamp, Slack and Google Hangouts.

    While tools are important, they’ll only take you so far. You need to develop strong foundational relationships among teams, colleagues and management before implementing remote work policies. In-person relationships set the tone for remote ones. Try to grab a beer or lunch with your colleagues – it will help form healthy relationships and ensure remote work is truly effective. If your team is completely distributed, try to get together once every quarter or two to reconnect, put faces to Slack handles, and build culture. The plane tickets and hotels may seem a little pricey, but they’ll pay off in productivity and morale.

    And as with many other tests, start small first. Maybe you have a smaller engineering team that’s used to working this way already – let them test drive with a couple days per week so one piece of the company has a chance to hash things out before rolling out more widely. As GitHub points out in this post on how the company works remote, if something doesn’t work, just ditch it in favor of something that does.

    What Should You Consider When You Go Remote?
    Just because everyone’s excited to go remote doesn’t mean you have a bright out-of-office future ahead. Remote work comes with its fair share of challenges and considerations.

    If remote work isn’t ingrained into company culture, problems won’t be far behind. Projects can be delayed because dispersed teams aren’t used to communicating in a timely fashion with out-of-office colleagues. Discontent might simmer if in-office workers view remote teams as slackers. Subcultures can also easily form among remote and non-remote employees.

    Communication presents another daunting obstacle. Teams outside the office might over-communicate, while on-site workers bristle at a deluge of messages. Conversely, remote workers might fail to communicate enough, furthering the perception they’re not getting much done. As mentioned at the USENIX LISA 14 conference remote work panel, refrains of “your team’s never in the office” might become all too common.

    In the end, interpretation matters. For remote policies to work, employees in-office and outside need to understand that they’re both working hard toward a common goal, even if their methods differ. But that doesn’t happen on its own: you need to implement the tools, processes and culture to make it a reality.

    The bottom line is that remote policies work for some organizations and not others. What matters is finding a sustainable organizational culture that leads to business success, whether you do it from behind a desk or at home in your pajamas.