devopsy.kinsta.cloud

Tag: workplace

  • How to Manage and Engage Remote Engineering Teams

    How to Manage and Engage Remote Engineering Teams

    As engineering teams look to remain remote or hybrid, executives need to fundamentally change how these teams are managed. After tackling the tactical aspects of a distributed workforce—like home office equipment, a comfortable space where employees can get work done and reliable meeting, calendar and communication tools—more nuanced issues come into play.

    Before the COVID-19 pandemic, when a minority of engineering team members worked remotely, those team members knew that they needed to make a concerted effort to connect and to be part of the group. When the majority are remote, however, the expectations of offsite employees have shifted dramatically. For organizations that had built their business with an in-person team, this brings up entirely new questions of communication, culture, loyalty, problem-solving and retention to the forefront.

    Fundamentally Shifting Engineering Team Structure

    Inspiring change requires fundamental shifts in the ways engineering teams work. Our own engineering teams have experimented with some changes that have proven effective, including:

    • A globally revised team structure that embraces a culture of autonomy and breaks larger engineering teams into smaller groups. Smaller groups help engineers feel more engaged, valued and empowered; it keeps meetings short and focused and allows for more parallel streams of work.
    • Overhauling our design process to get a champion or ‘anchor’ from the dev team involved in key features early on. This anchor is responsible for translating product and design requests into technical specs and is the de facto technical lead of the feature. Having this role rotate between team members for each feature means each member gets a chance to grow their skills as a technical lead.
    • Assigning dedicated designers to smaller groups to empower them to make small adjustments mid-flight. This would allow standups to operate as mini working sessions to iron out technical details that would normally be resolved through ‘shoulder taps’ or in-person quick questions.
    • Placing a strong emphasis on sprint retros as a way to make real changes to the way work gets done. When used in conjunction with an initiative to empower devs, sprint retros became a powerful tool to get dev feedback on improving the process.
    • Keeping teams accountable by encouraging transparency and clear communication as a tradeoff for their autonomy. We encouraged note-taking and regular updates, as well as clear goal-setting from the teams at the beginning of each sprint. By holding teams accountable to the goals that they set, it became easy to see when things were and were not working.
    • Experimenting with a four-day workweek to see if we can drive both greater happiness and productivity. This was perhaps the boldest of our experiments; we demonstrated trust in our team and set clear expectations around outcomes rather than hours. This has motivated our team and raised their morale in crucial ways at a time when switching jobs was both tempting and easy.

    Hacks That Worked in Person

    What are some of the things that worked in the office? This list will be different for each organization; for us, it was group brainstorms, in-person one-on-ones, summer Fridays and ongoing vibe checks. Here are some of the ways we hacked these to make them work for remote teams:

    • Group brainstorms: Digital whiteboards like Miro or Mural have been great. Digital sticky notes, too. This has enabled distributed engineering teams to contribute either all at once or asynchronously.
    • Summer Fridays: Give people the afternoon off even if it isn’t technically “leaving the office early.” Or try having everyone shut off notifications on Friday (or Monday morning) so they can get some undisturbed work done before shutting off for the weekend. Monthly mental health days off for the whole company can be a great idea too.
    • In-person one-on-ones: With Zoom, something is definitely lacking. Try spending half the one-on-one meeting chatting casually about things other than work.
    • Vibe check: Open office hours dedicated to work culture; surveys from time to time to gather quick informal feedback or think about other ways to elicit ongoing feedback from every employee, including engineering teams.

    Generate Culture and Well-Being

    What keeps most employees at companies is social bonding, inspiring projects and the possibility for growth. A question a lot of executives at previously onsite organizations are asking themselves is, “How do you fulfill the need for social bonding when most employees, including your engineering team, are remote?” In other words, how do you bond socially and do so remotely? Two goals we have identified are getting team members talking outside of work while avoiding Zoom fatigue issues and ongoing opportunities to share personal successes with colleagues.

    Some of the ways we have built culture are:

    • Having (non-mandatory) Friday lunch and games like trivia, Jeopardy!, games or online games
    • Different ongoing events like photography challenges, health challenges and even an at-home Iron Chef-style cookoffs.
    • Having leaders share how they spent their weekends and time off. We believe in demonstrating a healthy work-life balance from the top down and encouraging our team to take the time they need to unplug and recharge.
    • Figuring out how (and how not) to surface urgent issues via Slack; working on a system to avoid pinging people after hours for non-urgent issues.

    Above All, Manage With Empathy

    These last two years have been exhausting for most people. Hands down, the best way to manage and engage the people you work with—no matter if they are in engineering or marketing—is to be empathetic to the difficulties that they may be going through outside of work. Executive teams can make all the tactical changes to their teams they want, but without managers that really care about their teams, you will inevitably fail to keep the best people around. Empathy-driven leaders lift their team members up and drive the kind of culture people want to be part of.

  • Will Devs Return to the Office?

    Will Devs Return to the Office?

    Charlene O’Hanlon and Michael Davis, CRO at Rollbar, discuss findings from a recent developer survey exploring how devs feel about the return to the workplace. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Charlene O’Hanlon: Hey, everybody. Welcome back to TechStrong TV. I’m Charlene O’Hanlon, and I’m here now with Michael Davis, who is the CRO at Rollbar. Michael, thank you so much for joining me. I appreciate it.

    Michael Davis: Thank you, Charlene. Great to be here.

    O’Hanlon: Well it’s great to have you here. I am really fascinated about a recent developer survey that you guys came out with regarding their attitudes toward going back into the office, and that’s always a hot topic among organizations no matter what they do. A lot of companies are grappling with just the aftermath, if you will, of the pandemic and the return to the workplace. If you rewind about 12 months ago, we were hearing stories about companies deciding that they were never going to have their employees come back and they were going to work remotely 100 percent all the time.

    And a lot of organizations, or a lot of employees I should say, kind of took those cues and decided that they just were going to go and move wherever they wanted to. And so now a year later companies are saying, “Well maybe we should come back into the office at least part time.”

    Davis: Yeah. Right.

    O’Hanlon: So there have been a lot of kind of ping-ponging I guess, for lack of a better term, and I truly believe that the rest of this year there’s going to be a lot of fallout from organizations dealing with employees who are no longer able to come into the office because of their location. But I’m interested in finding out what you guys found in your survey regarding that and some of the other findings that maybe surprised you.

    Davis: Yeah. That’s a great intro, although I might push us back even before COVID. I think this is especially relevant for a lot of the software development teams that we work with. If you go back before COVID, we had customers where their entire teams of developers didn’t even own a laptop. They were literally in the office all the time, every day. And so not only are companies now wrestling with this transition post COVID, but they had a huge transition they went through pre COVID, right? And that certainly put a lot of stress and strain on the companies, but more importantly on the actual developers themselves.

    And so here we are now coming to the end of this, as you’re describing, and we’re going through another transition. And I agree, I think what the survey starts to show is that this is not going to be black or white type of thing. It’s not going to be all of one or the other for many of the reasons you already mentioned. The survey was very clear in that first off it said 77 percent of developers were definitely significantly impacted by COVID and what this meant for them, and now as you start to interview folks and do the surveys you find that it’s a real mixed bag. You have folks who’ve enjoyed the freedom, enjoyed that flexibility, and have started to adjust to that to some extent.

    But I think one of the most interesting findings is that they’re missing that face-to-face component of their work. And if you think about developers and what they do, this is a team sport, right?

    O’Hanlon: Right, right.

    Davis: They’re really missing that day-to-day, face-to-face interaction, and especially given the sort of raised stakes, which is another thing that came out of this survey. What we found was sort of this external pressure on development was even raised higher. Why? Well, because customers are needing to interact with companies through software. So there’s even more pressure on building more software faster. So these are some interesting things that we saw sort of pulling against each other.

    O’Hanlon: So what do you think is the answer here? I understand that developers crave that face-to-face. I also see people who are now dealing with a level of social anxiety that maybe they never had dealt with before in their life. If you’re a year away from somebody or large groups of people it can be tough to reintegrate yourself into that environment. And as much as we all say I can’t wait for things to get back the way that they used to, we can go to concerts, we can go shopping and not have to worry about wearing a mask or whatever, you put people in some of these situations and it’s difficult for them. Some more than others.

    Some are just like, yeah, whatever, you know, let’s just go back and it’ll be fine the way that it was. But I’m not sure when people say I want to work with all these people, I want to get back into the scrum, I want to do this and do that, I’m just not sure when they actually do it that that’s really what they wanted. Do you think that there’s going to be maybe buyer’s remorse if you know what I mean?

    Davis: Yeah, there could be. My guess – and again, it’s based on some of the survey data we’re seeing – you do have this mixed feeling about your sort of life balance isn’t necessarily all you thought it would be by being home all the time. But I think you’re going to see the same thing. If we went back full time in the office people would be feeling that same kind of pressure around the commute and the things that go with that. So my gut says that now that companies have adjusted and people have adjusted more to being away, we’re going to see this hybrid environment.

    You’re going to see more of an environment where people are going to be in the office at certain times, but they’re going to have the ability to work from home at certain times, which again, carries its own set of things. We’ve seen lots of investment in tools, Zoom being one of them we’re on right now, but there’s a long way to go. Because the other thing the survey showed was that by having these distances it’s harder to get those answers, let’s say, as a developer that you might need in the moment. When someone’s not two cubicles away from you, you have to hope that they’re on Slack. And if they’re not, then you’ve got a delay and a problem.

    So I think the next thing we’re seeing is we’re seeing more investment in additional tools, in additional types of processes that help this hybrid environment more.

    O’Hanlon: Do you think that we’re going to see an increase in these distributed workforces on a full-time basis either as a direct result of the mass exodus during the pandemic or just because they can, that they’re recognizing that maybe we don’t have to be in the office all the time? Or Joe left and he can do it full time, so I’m going to do the same thing and what are they going to do?

    Davis: Right.[Laughs]

    O’Hanlon: Take away my birthday? It’s going to be one of these – I think there’s going to be this push-pull. And so I’m wondering do you agree with me? Is this something that very might happen? And what do you kind of see? How can organizations – how do you expect them to react to that?

    Davis: Yeah. And I would add to the points you made one other thing, which is companies I think have learned that once you remove this need for everyone to be in the office all the time this also starts to free up your ability to recruit more broadly and it gives you flexibility to bring on the type of people you want wherever they sit, right?

    O’Hanlon: Right.

    Davis: So I think that’s going to play in as well, and that’s why I think it really will be this hybrid environment. So what can they do about it? Well, they’ve got to be really mindful about how people work and they’ve got to be investing. Companies have to be investing in the right kind of tools. I’ll toot our horn a little bit here. Rollbar is about this sort of platform that gives you visibility across your teams on specific errors that you have in your code.

    That’s one example. If companies have tools like that in place, now you don’t have to be sitting two cubicles away. You’ve got the data you need right in front of you, real time, to be able to make those kind of decisions. That’s one example. There’s many, many more, but it’s going to be thinking about these workflows somewhat differently and making sure you have the right processes and data so people can operate more efficiently.

    O’Hanlon: Yeah. It’s going to be an interesting year I think as we do kind of transition back to life post COVID or even the final throes of COVID, because so much happened over the last 12 years and it was a lot for all of us to process. And now for us to kind of quote/unquote go back to the way things were I just don’t think it’s ever going to happen. I don’t think that we’re ever going to be back the way things were before COVID, and so that means a lot of changes within organizations and among employees and their understanding of work and how they approach it on a day-to-day basis. I think there’s going to have to be a lot of giving in, if you will for companies, that they’re going to have to take a brand new tack when it comes to hiring and retaining their employees.

    But employees also need to kind of understand that at the end of the day there’s a job that needs to be done and sometimes the best way to go about doing that job is to maybe be in the office or be face to face. So there is no one-size-fits-all solution here. Michael, great results. Were there any other things that popped out of the survey regarding developers and how they view work or work/life balance or salary or anything like that that you guys covered in this survey?

    Davis: We didn’t really touch on salary so much. I think the big takeaway points were just how pervasive the impact was on developers and what they were trying to do. That was the first thing. The second thing then was this notion that a lot of that sort of stress and strain that was associated with this was, one, just a normal transition, but also this higher demand for software, which I don’t think necessarily any of us really predicted, and that is added to what’s already software in the world. Every company is a software company kind of thing, right? So that’s the challenge, and that’s the challenge that Rollbar and other companies are working to help this community with, because it’s tough. It’s a tough job.

    O’Hanlon: Yeah. And to your point, I don’t think anybody expected it, but do you think that it’s going to be sustainable? I mean, is this something that’s going to be kind of the new normal, if you will? At least not may necessarily from a product – well, even from a productivity standpoint, but do you think the demand is going to remain as high as it has been over the last 18 months or so?

    Davis: I just have no doubt about that. I mean, there was already an incredible pressure on the system. These teams are already feeling lots of external pressure about being able to deliver features and functionality faster, right? We’re all hearing about iteration speed. And so I don’t have any question now that – again, I think companies have learned that maybe they don’t need the same kind of retail presence to serve their customer base. Which again, puts just more pressure on the need for software.

    So yeah, this all feeds into I think even a more challenging environment, but certainly a rewarding environment because these people are at the center of the epicenter right now of everything.

    O’Hanlon: Yeah. But I do worry about burnout. I do worry about the fact that – I think a lot of people really rose to the occasion at the beginning of the pandemic and all throughout it because they did recognize that there was a value to it. They could actually see how their work was impacting their company. And I’m not sure that once we go back to kind of whatever, whatever we’re going to call it, that that is going to sustain, and it’s really going to give developers and other employees for that matter kind of the push that they need. And it does concern me that we may very well see mass burnout among developers, and that could be bad for everybody.

    Davis: You’ve given me a great transition to one thing I wanted to mention, which is the next thing we’re going to be working on is some analysis around developer productivity. So I think you’re right on, spot on. I think that’s the next concern. I mean, it’s already a concern, but now it’s even more accentuated. DevOps was already a mixed bag in terms of developer productivity. I won’t spill anything, but we’re going to do a deep dive there and hopefully we’ll have some more great data for you.

    O’Hanlon: Well, come back and have the conversation with me when that’s ready, because I would love to continue this conversation. There’s a lot going on in the space right now and it’s got so much more to do with just business, the business side of things. There’s a real human element to all of this and I think it’s very important that organizations keep that in mind at the end of the day and so much more. But Michael, thanks for talking to me about this survey and the results of this one.

    Fascinating stuff, and it’ll be interesting to see how the rest of the year plays out in terms of everything that we’ve discussed today. So thanks again for your time. I appreciate you being here.

    Davis: Thank you. Thanks for the chance to talk to you. Bye-bye.

    O’Hanlon: Alright. Alright, everybody. Please stick around. We’ve got lots more TechStrong TV coming up, so stay tuned.

    [End of Audio]

  • DOES 2019: Understanding the Effects of Burnout

    DOES 2019: Understanding the Effects of Burnout

    If you work in the IT field, cybersecurity, the startup world or any other high-pressure job, you or someone you know has probably suffered from burnout in one form or another. If so, you already know that burnout is a real condition with significant consequences. In fact, the World Health Organization (WHO) recently recognized burnout as an occupational phenomenon.

    The WHO describes burnout as follows:

    Burn-out (sic) is a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed. It is characterized by three dimensions:

      • feelings of energy depletion or exhaustion;
      • increased mental distance from one’s job, or feelings of negativism or cynicism related to one’s job; and
      • reduced professional efficacy.

    I have been on the road pretty much constantly for the last three or four months (no, I am not trying to say I suffer from burnout). We have covered lots of great conferences. One of the best, as usual, was Gene Kim’s DevOps Enterprise Summit in London. We have about 30 videos from the conference up on the Digital Anarchist site. Of those interviews, my favorite is the one in which I had a chance to sit down with three PhDs to discuss the issue of burnout. I say three PhDs not just to throw around titles—these are three recognized experts in their field.

    The trio of panelists are:

    Dr. Christina Maslach — Probably the foremost authority in the world on burnout.

    Dr. Steven Spear — Senior Lecturer at MIT Sloan School and the Engineering Systems Division at MIT.

    Dr. Nicole Forsgren — Founder of DevOps Research and Assessment, now part of Google.

    This interview is a little bit longer than most, slightly more than 30 minutes. But I think it is well worth your time to hear what these three experts have to say on the issue of burnout and workplace fatigue.

    In addition to our interview on the Digital Anarchist set, I am also happy to include the panel discussion these three folks had on the main stage of DOES London with Gene Kim.

    More importantly, if you or someone you know is suffering from burnout symptoms, please reach out for help and do something about it. You are not alone.

    Don’t forget! DevOps Enterprise Summit Las Vegas 2019 is happening Oct. 28-30 at The Cosmopolitan Hotel. Be sure to register here if you haven’t already and join us for the premier event for technology leaders of large, complex organizations implementing DevOps principles and practices. You can also preview the event by watching presentations from past DevOps Enterprise Summits.

    — Alan Shimel

  • What Do We Do When Everything is Automated?

    What Do We Do When Everything is Automated?

    Recently, I came across a study the caused me to think beyond the day-to-day world of code-slinging in which I live. According to the study conducted by Center for Business and Economic Research at Ball State University in Indiana:

    “Almost 88 percent of job losses in manufacturing in recent years can be attributable to productivity growth, and the long-term changes to manufacturing employment are mostly linked to the productivity of American factories.”

    Just translate the term “productivity of American factories” into the word “automation” and you get the picture. Other workers are not taking jobs away from the gainfully employed, machines are.

    This is not a new trend. It’s been going on since before Eli Whitney invented the cotton gin. Industry creates machines that do the work of humans faster, cheaper, with more accuracy and with less failure. That’s the nature of industry; nothing new here. However, what is new is rate by which the displacement of human beings from the workforce in happening.

    The Bureau of Labor statistics projects that by 2024 the U.S. economy will need 50 percent less car mechanics, 42 percent less telephone operators, 26 percent less postal clerks and 20 percent less parking enforcement officers. Or, to put it another way, cars will be better at self-repair, call routing technology will get better at conducting verbal conversations with humans, self-service postal machines will get better at taking care of human transactions in the post office and parking meters will know how to write tickets.

    Here’s another another point to ponder. As the quality and reliability of self-driving vehicles improve, it’s not far-fetched to imagine self-driving trucks becoming the norm on the nation’s highways. How many truck drivers will be displaced once self-driving trucks are everywhere?

    Also, think about this: As Uber and Lyft mature in the business landscape and self-driving cars become commonplace, the ride-share companies will replace human driven vehicles with self-driving vehicles. Then, Uber or Lyft will start to offer a pricing model that is flat fee for 24/7 service with unlimited mileage. So, to keep it personal, imagine Uber/Lyft offering me a deal in which I pay $150 a month to have all my driving needs taken care of. Or, I can continue to pay the $400 it costs me for my car lease and insurance coverage (yes, I lease a modest vehicle). Which way do you think I will go? Spend $400 for the pain of driving in a car in LA traffic or spend $150 to get where I need to go while I read a book in the back seat? Me? I’d fork the car over in a New York minute.

    As if this isn’t startling enough, try this one out: Walk down your street. See all those cars parked on the side of the road. In the near future, using the Uber/Lyft automation scenario, they won’t be there any longer. Any car made will be used 24/7. All this translates into less cars doing more work. And less demand for cars means less cars being made. Less cars being made means less people working making cars. You get the picture.

    What about software? Let’s take a scenario that is part of my day-to-day coding world, logging. In the old days, you’d log to a file on disk. Over time, that log file got so large that a human would need to move the file manually onto an archive disk so as to not eat production space. Somebody comes along and says, “Hey, I can write a piece of code that watches the size of the log file and moves it automatically when the file gets too big.” So much for the person doing the manual file move. But, still, you had to keep adding capacity to the archive machine, which typically meant a human walking down to the server room and twiddling with some hardware. Then a someone has a great idea, “Let’s use this thing called cloud storage as a back-end for a log collection service. We’ll leverage the elastic capacity features of cloud storage and write out logs to that service. Hell, why make a service? We’ll subscribe to an existing one and save the development costs.” Thus, no more humans needed to monitor capacity, move files, write incidental scripts—any of it. In terms of logging, a bunch of automation is doing the work a lot of humans used to do. Is this progress? Might be. But the trend is unmistakable, so much so that I have no problem imagining a future in which 90 percent of work that used to be done by humans is done by low-cost, automated, robotic, labor.

    We’ve always been on our way to automating everything. The only difference between then and now is that now we are really, really close to full automation. Asking the question, “What will we do when everything is automated?” is no longer fantastic, it’s essential.

    So what will we do?

    “Simple,” you say. “We’ll retrain the displaced workers.” Really? Many of us in the software game know that notion of retraining is a joke. If you are not constantly learning the new stuff, you are out of work. For a knowledge worker, continuous learning is an ongoing requirement for commercial viability. And, the baseline from which you are learning is very high. In other words, you need to know a lot to get the basics of how to write a deployment script in Ansible that runs against AWS. And, even as you are learning that basic technique, somebody is already creating a technology that will make the technique you are learning obsolete.

    So back to the question, what do we do?

    First, let’s do the obvious. When near total automation has the result that there is no longer any work for most humans to do, we need to come up with other means of survival. Survival in the modern world means having money to live on. Charles Murray suggests in the Wall Street Journal that we plan to implement Universal Basic Income. Finland is starting a pilot project based on the idea. Other countries are experimenting too. Universal Basic Income is a program in which citizens of a state are provided with a base income on which to live. Some programs vary basic income according to income produced otherwise. The common thread is an understanding that jobs are not plentiful and that depending on one for survival is not realistic.

    The notion of Universal Basic Income is not that new. It’s been around since the 1960’s, proposed by folks such as Milton Friedman as the negative income tax.

    Second, we need to address the elephant in the living room: the birth rate. In the old days when agriculture and small, private farming was a major industry in the United States, having a large family made sense. You needed your family members to work the land. As the Industrial Revolution created demand for factory workers regardless of age, large families still made economic sense. But now the trend is that we need less people to do more. Thus, having large families becomes counterproductive to the economy overall. Yes, there are certain sensibilities out there that encourage large families and adherents to such thinking have large families as a matter of choice. Still, many families end up with large families for reasons other than intention. It just sorta happens.

    Thus, to ensure that humans have a chance at a viable existence in a fully automated world, implementing effective family planning policy and practice becomes as useful to the society of the near future as the anti-smoking efforts that started in the 1960s does today. I am not advocating draconian, government mandated family planning. We cannot legislate family size anymore than we could smoking behavior. Rather, we need to create a social condition in which the wisdom of the idea prevails.

    Finally, we need to address the need for human dignity in a fully automated world. For better or worse, we need to accept that in the near future the traditional relationships between demand, productivity and income no longer may be applicable. The old days of human workers making stuff and getting paid for their product or labor are coming to an end. Yet, one of the intangible benefits of the old days was the dignity and satisfaction that went with pulling your weight and earning your keep. Being able to provide for yourself and your family defined your worth in your own eyes as well as those around you. This need for dignity will remain no matter how the technical and economic landscapes evolve.

    When I started to doing the research for this piece, I asked others in the know to respond to the prospect of a world that is fully automated. One the people I talked to was Phillipe Kahn, founder of Borland, Starfish Software, LightSurf Technologies and most recently, Fullpower Technologies. Here is his response:

    “I remember being in India and watching a construction site: Lots of people, elephants, activity. I asked, ‘Why don’t you all use bulldozers and tractors and prefabricated concrete parts?’ The answer was enlightening: ‘How would this community make a living with dignity?’ That’s the whole paradox that we are dealing with: Productivity versus dignity for communities that could be unemployed for generations.”

    There is a difference between work and labor. Work is an activity a human does to give one’s life meaning. Labor is what a human does to survive. In the old days work was your avocation, labor was your vocation. Some humans were fortunate enough to have their activities be both avocation and vocation. Others went to work in factories, farms and offices to earn a buck. They pursued other interests at other times. But whether you sang in the New York City Opera full time or in the choir on Sunday morning, the dignity of your work, bringing music to the ears of other humans, was in full force.

    So, the final part of answering the question, “What do we do when we’ve automated everything?” is this: Preserve the dignity of the person and the community. A fully automated world will be a wealthy world unless we blow it up. Productivity produces wealth. That’s the way it is. Regardless of who is or what is the owner of the wealth—government, corporation or private citizen—sharing will become more important than ever. Concretely, this means allocating a significant amount of money to people and organizations that do work that has little or no commercial value, but extraordinary amounts of human value. When it comes to commercial value, the machines will have that end of the economy covered and then some. However, stuff that has little commercial value—curing low occurrence diseases, space exploration, academic research, expanding the arts—this is where human activity can excel.

    In the old days we had a notion called the commonwealth, that shared space where our individual assets grew. We shared some to get some. In the automated future it might have another name. But no matter the name, it will be a place where humans work with dignity in communities and most labor is the left to automated robotics. If not, the common thread of our individual survival might indeed be nothing more than alms for the poor while automation creates wealth for a few.

    — Bob Reselman