Pivotal Software recently released the Benchmark report, a survey conducted with Longitude Research and Ovum with more than 1,600 respondents across six regions (Australia, Germany, Japan, Singapore, UK, and US) and five industries (Automotive, Banking, Insurance, Retail, and Telecoms). The Benchmark provides a quantitative framework of measurable indicators designed to gauge how well an organization builds software that delivers business value.

Why you should take the Benchmark:

When you complete the Benchmark survey, you get a customized result that you can share with members of your team, which can unlock conversations around how to be more software-driven. If your team is tired of fighting fires, answering texts on weekends, manually patching, and fighting for budget, this can be a great tool to get going in the right direction.

Here are the results for a fictional insurance company, SafetyCo Insurance. Let’s dive in to see what kind of data the Benchmark can provide the good people of SafetyCo.

First, let’s look at how SafetyCo’s budget compares to others:

SafetyCo has a fully committed IT budget, which is unfortunate, as our research found that leaders in software development are able to rapidly and reliably address changes in direction in service of the business. But SafetyCo does have a high percentage of their budget set aside for ad-hoc software, which provides room for creative solutions and innovation.

You want to improve product development

Product Development provides a comparative snapshot of software development teams’ productivity and efficiency. Because so much depends on the unique circumstances of each individual company, there are no ideal absolute numbers of developers or applications. Ratios may be a better guide to development efficiency — the size of the developer team to that of operations staff or the number of developers per application, for example. In product development, a lower developer-to-application ratio, a lower defect rate, and continuous deployment, among other attributes, suggest higher levels of efficiency and productivity.

One metric of software development efficiency is having a high ratio of developers to operators. In this chart, we see that SafetyCo has slightly higher than average ratio of developers to ops and QA staff.

You want to reduce your change failure rate

This is when things start getting real. Our analysis of the responses suggested that software leaders demonstrate a low percentage of new software launch or upgrade delays due to defects from low-quality software. Here’s how SafetyCo stacks up:

That’s a higher percentage of delayed launches not just for their industry but compared to the overall Benchmark cohort as well. But now we know one area that requires improvement.

You want better scalability

To succeed in today’s digital environment, IT must provide apps and services on-demand and explore all options with minimal friction. We found that leaders strive to attract developers and ramp productivity linearly with personnel as well as rapidly scale their applications to handle demand. You’ve got to assess how quickly and easily an organization can scale software applications along with the underlying infrastructure.

Let’s imagine a good problem to have: the number of users for your apps is poised to double thanks to an upcoming focus on sales. How well would SafetyCo be able to handle the load?

That level of disruption might be something the organization wants to prevent.

You want to go fast forever

Ah, speed — we all want our ideas to move quickly. One way to measure velocity is to calculate how long it takes a small team to get a feature of a critical app into production. Here’s how SafetyCo would do:

That’s almost twice as slow as industry peers! Our research found that high-performing incumbents are able to move quickly and reliably respond to changes in direction in service of the business.

But another factor for speed is having a modern architecture. We’ve found that cloud-native organizations (i.e., those that are fluent and comfortable in deploying and maintaining apps on a combination of public and private clouds) have applications that perform better, are more resilient, and are easier to manage.

So how does SafetyCo stack up?

Well, let’s just say there are areas for improvement.

This is just a sampling of some of the insights the Benchmark can provide into where your team stands compared to your competition and technology teams at large. And although some of this can seem like intense news for SafetyCo to process — at least now we know some major areas we can improve.

Digital transformation is not just a one-time discussion; it is ongoing, and the Benchmark can spotlight which areas that need work. And don’t worry, we’ve seen it all — there are solutions to every problem, whether it’s through training, hiring, better infrastructure, or a combination. We’re here to help.

Take the Benchmark now. See you how measure up in the digital future.

How to Measure Software’s Ability to Deliver Value was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post was written by Maya Rosecrance, Software Engineer at Pivotal London and Sarah Connor, Software Engineer at Pivotal London

Pair programming is at the center of everything we do at R&D at Pivotal. The Redis team pairs every single day with two keyboards, two mice, two monitors, and one computer. We have no remote members, and for the most part there is only someone that ‘solos’ when we have an odd number of people for the day. The benefits of pairing are undeniable as context is shared more easily and two pairs of eyes result in less mistakes and higher quality code. However, sometimes pairing can be uncomfortable, or pairs can have an uneven level of experience or context, or, simply, the pair can be mismatched in terms of assertiveness and personalities. It’s something that we usually don’t take much time to reflect on other than a throwaway comment of the flavor that the driver/navigator balance in the pair was off. The next day, the pair will split up and possibly not match up again for another week so the conversation can be easily lost. In order to force ourselves to have these conversations and to reflect on our pairing culture, we ran an experiment over two weeks.

The Experiment

Every day, we chose one of five techniques and used it for the day. These techniques were inspired by this blog post by a former Pivot.

The goals:

• More evenly split time driving and navigating.
• Provide a structure for less assertive drivers.
• Enable faster context sharing. Often, when one pair member has more context on a portion of the codebase, they would dominate the driving possibly leaving the navigator lost as to how to move through the codebase.

At the end, we had a full team retrospective to discuss the effectiveness of each technique.

Pairing Roles

Pair programming traditionally involves two people acting as either a driver or a navigator. The driver is the person with their hands on the keyboard and the navigator is the person that provides a birds eye view of the direction of the work. The benefits and distinctions separating the work dynamics in this way have been widely discussed. Each of these techniques focused on the transition point between the roles.

Techniques:

Pomodoro

The dependable study technique, Pomodoro is where a timer is used to signal the switch between pairs and taking breaks. Typically this is 25 minutes of work followed by a 5-minute break.

Pros:

• Breaks make a natural reflection point on the existing work.
• It’s the technique with least mental overhead to determine pair switching.
• Both people in pair take snack, bathroom, and phone breaks at the same time.

Cons:

• Requires an external app or browser plugin that needs to be setup.
• Timers are by nature noisy which can be disruptive to the office at large.
• Forced breaks can interrupt pair flow.

We found that this pairing technique had very wide applications but there was mixed feedback on the breaks themselves. One member found that they initially felt the breaks were disruptive but as the day progressed, they felt more natural.

Ping Pong

The classic Ping Pong technique where one person writes a failing test, they switch roles, then the other tries to implement the minimum necessary code in order to pass the test. They will then write the next failing test and the cycle continues.

Pros:

• Works well with TDD.
• Gamifies the coding process.
• Affirms what the last person did and ensures the pair are both on the same page.

Cons:

• Hard to apply when the piece of work does not involve tests.

One of our favorite techniques for pairing when doing TDD, but sadly not easy to use for operations oriented work.

Switch on Google

Switch any time the pair wants to research something further. This is also meant to help reduce the impulse to separate and research individually.

Pros:

• Very useful as a hybrid addition to task-list or ping pong when one of those went on too long.
• Can be applied to switch on a lot of things: new theory, visit to third party tool, opening the manual, etc.
• Indicates that the driver has reached the end of their understanding.

Cons:

• Requires cognitive overhead to know when to switch as pairs would forget to switch or had difficulty splitting up long research pieces.
• Difficult to use for low complexity stories.

Taking the switch on Google in a literal way proved to be disastrous for one pair as they found that Google searches came either far apart or quickly in sequence. The technique proved especially useful during exploratory stories where neither pair had a lot of knowledge or context. It also helped to alleviate the strain involved in researching as a pair as neither person was driving for too long.

Task List

The pair decides on a set of tasks that need to be accomplished and switch after each task is accomplished. Tasks can be created, modified, or deleted as the pair progresses.

Pros:

• Very agile way of working on a story.
• The task list is helpful as documentation.
• Forces the pair to break down the story into bite-size pieces of work.

Cons:

• Not all tasks are of similar size or scope so can lead to unbalanced pairing.
• If the task list is too long, it may be difficult to glean information from it.

A universally applicable technique for stories. We found the discussion around forming the tasks to be a big strength of this technique and led to more thought out approaches.

Pairmate/One-keyboard

A small item like a stuffed animal or tchotchke can be used to signal who is navigating. The navigator holds the item to signal that they are not to touch the keyboard until that item is passed off to the other. Alternatively, the item can be removed altogether and the pair shares a single keyboard which they pass back and forth.

Pros:

• One keyboard version is very strict as the navigator is not able to impulsively grab the keyboard.
• Allows the driver to learn the navigator’s keyboard shortcuts.

Cons:

• Easy to forget to pass the token back and forth. The keyboard solution did not have this as an issue.
• Frustrating at times if the navigator has to dictate something they could accomplish quickly but is not easy to communicate.

We found the one keyboard method to be more applicable than token passing. It was the most dogmatic technique of the bunch but because of it strictness was the most effective in allowing reflection of our practice of pairing. It was also very frustrating at times.

Conclusion

Overall, the pair programming experiment was useful in allowing us to reflect on our dynamics and individual approaches to pairing. It enabled us to understand better how to approach our pairing and gave us techniques to get over the awkward pauses that arise when one person is at a natural stopping point but still has their hands on the keyboard.

For more information or access to the assets used in this blog click here.

Credit for Redis Dino mascot: Denise Yu

Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.

What’s the Best Way to Pair? was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

Letting go is sometimes difficult. But that’s what developers at Garmin are learning to do.

The only way to release software on a daily basis, and sometimes multiple times per day, is to automate as much of the delivery pipeline as possible. At Garmin, developers are used to shepherding code from idea to production manually. To respond to customer feedback and get new features to market faster, Senior Software Engineer Jonathan Regehr and team are slowly introducing automation into the company’s development process.

This includes automating unit testing, which is where letting go comes in.

“That’s going to be a huge cultural shift as teams are like, ‘Nobody’s touched this [code]? We don’t have to test it?’ Well, yeah, we’ll test it, but we’re going to try to do it in as automated a fashion as we possibly can,” Regehr said in an interview at Cloud Foundry Summit 2018.

It’s all part of Garmin’s digital transformation initiative, which began in earnest in 2016. Since then, the company adopted Pivotal Cloud Foundry as their cloud-native platform of choice. The operations team uses the platform to automate a number of tasks, such as automatically scaling application instances up and down as traffic fluctuates — this keeps Garmin running during the holidays, when lots of new devices are being activated. Now it’s the developers’ turn to get in on the automation game.

“We’ve been working really hard to make sure that we have things tested to the point where, ultimately, we get… all of the manual steps out of the pipeline and we’re actually deploying from development to production with no manual intervention in between,” said Regehr.

By letting go of manual testing, developers at Garmin are spending more of their time learning from customer feedback and developing new features.

That’s not all Regehr had to say. Watch the full interview below for more on Garmin’s transformation efforts.

Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.

At Garmin, Developers Are Learning to Let Go and Love Automation was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s easy to get swept up with the idea of autonomous cars. No one wants to be stuck in traffic or deal with a long commute home at the end of a long day — autonomous vehicles to the rescue! When Jeff Kelly talked to Alois Reitbauer, VP and Chief Technical Strategist and Head of Innovation Lab at Dynatrace, at the Cloud Foundry Summit, the tech executive described “autonomous IT” and how it will make all software-related jobs easier.

Reitbauer explains: “So our idea is that in the future, you really don’t want to run your IT infrastructure, you don’t really want to take care of a lot of your applications. The way we see it, human intervention really becomes the exception rather than the rule.”

He imagines a future where, when setting up a new application’s infrastructure, you’ll be able to state: okay I want this new feature, my customers need to be able to use it, but I really don’t care how it gets there. If the app doesn’t arrive, the underlying platform should also be smart enough to be able to take care of any issues.

Reitbauer goes on to describe Dynatrace’s artificial intelligence layer, and how it integrates with modern cloud platforms like Cloud Foundry. Watch the full interview in the video below:

Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.

Autonomous IT with Dynatrace was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

Speaking at the Greenplum Summit at PostgresConf, Scott Yara couldn’t help be reflective. It’s been almost 30 years since the start of the Postgres project and community — and what a ride it’s been. Several years after Postgres, Yara and Luke Lonergan brought their two companies together to form Greenplum, an open source and massively parallel database system built for analytics.

When talking about the community and their role in shaping the company, Yara said: “Postgres delivered so many useful features and a broader community of users that were interested in finding new ways to use Postgres. So I don’t think we could have been successful without it.”

Now, Greenplum is part of Pivotal, and the team is operating with greater efficiency and productivity than they ever have before. When asked about what’s exciting about Pivotal Greenplum, Yara said “we’re starting to see… the business demands that these analytical systems we’ve been sort of building over the last 10 years, they need to be more closely connected to the applications that eventually consume them.”

This is where big organizations can really benefit. “At the end of the day, if we’ve moved the applications onto [Pivotal] Cloud Foundry, but we still haven’t touched the database system, and those database systems are still managed the same way that they’ve been over the last 20 years, then we really haven’t solved the whole problem.” But Yara goes on to explain the solution, as he sees it, “I think that there’s this big push in the database community as a whole to try and make database systems so that they can be what we’re calling container native — that they can be provisioned and scaled and managed with the same efficacy that we have enjoyed on the application side over the last 5 years.”

But that’s not all Yara had to say about database efficiency; watch his whole conversation with Jeff Kelly below:

Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.

Scott Yara Explains Why Data Tells The Story was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some overnight successes hide the decades of work it takes to get there. That’s the perception that Tony Baer, a Principal Analyst at Ovum, has of Postgres, an open source object-relational database management system that started in the 1980s. Built to Adapt correspondent Jeff Kelly caught up with Baer at PostgresConf recently and they had a lot to discuss.

When it comes to embedded analytics — making it easy for people, or machines, to make real time data-informed decisions, Baer said “The need has always been that we needed to make smarter decisions. It’s just that in the past, the technology didn’t allow us to do that.” While this has been the case at tech companies for years now, bigger companies can now partake thanks to cloud technology democratizing access of embedded analytics to everyone.

Data privacy has been a rising topic, especially with European GDPR regulation impacting companies across the world, and more data being made available. When it comes to anonymized data released for analysis, Baer says “There’s also the reality that even if you anonymize records, it is very easy to basically track all the digital exhaust that you leave… anonymized records can be de-anonymized.” He went on to say how this has affected Ovum’s business: “There’s no question that basically that Ovum clients are coming to us and asking us how can we basically avoid becoming news headlines. There’s a very heightened awareness of that.”

Baer also had tips for enterprises looking to get started with advanced analytics: ask other business units what data they need. “Is there other information in terms of [customer] buying habits or their proclivities that you might be interested in basically piggybacking on them? From there you kind of sort of gradually expand the use cases. So I would basically say take an incremental approach.”

To hear about the other trends (microservices, containers, open source) that were discussed, you’ll have to watch the video below:

Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.

Getting Started with Advanced Analytics was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

Coding is a new gold rush of sorts. With programming jobs growing 12% faster than the market average and a high average salary, coding isn’t solely the domain of computer science majors anymore. People from a wide variety of backgrounds, from writers to teachers to small business owners, are “rewiring” their careers and taking up coding, via code academies and self-instruction. And companies are recognizing that it’s not just coding skills that make a successful software engineer: they should also know how to communicate, to empathize, and to stick with tough questions. Those with the determination and curiosity to pivot their career are just the type for the job.

We talked to a few of Pivotal’s software engineers who took a less-than-traditional path into software. Here are their stories:.

Alex Basson

Location: New York, NY

Former Role: Teacher

Current Role: Engineering Manager, Pivotal

I had taken two trimesters of CS courses in college, but that’s it — I was a math major, and my MA is in math, as well. I had never contributed to any open source projects, I’d never worked professionally as a programmer, and I had never shipped an app of my own. In other words, there was no reason at all for a potential employer to believe I had any qualifications as a programmer.

I met my friend Tim while we were teaching together — he was a Cornell CS grad, and he taught AP Computer Science. He left teaching to become a professional developer two years before I did, and when he decided to move on from his job, he put in a personal word on my behalf with his boss and colleagues. He also gave me a programming challenge: to build an iOS app that consumed the Google images API and displayed the resulting images in response to a user query. His reference plus my demo app were enough to get me an interview.

Personally, though, I struggled to believe in my own qualifications. I had been programming as a hobbyist for years, but mostly during the summers and a bit on weekends. I didn’t think I knew enough to succeed in a professional setting, and I almost didn’t apply for the job for fear that I’d be laughed out of the room. Overcoming this took the support and persuasion of my wife, who convinced me that I had nothing to lose by trying, and she was right.

Teaching influenced how I write code in that I am always striving for easier-to-read, more obvious code. As a teacher, I came to appreciate just how differently every individual understands and comes to an understanding of the same idea, and a big part of my job was learning different ways to present the same idea so that it would make sense to different people. In other words, communicating complex ideas is a huge part of what teaching is all about, and that same effort — trying to express complex ideas simply — constantly informs the code I write.

The so-called “soft” skills I developed as a teacher to be immensely valuable in my work as a consultant. Working collaboratively, working with clients from a wide range of backgrounds and skills, working with people who sometimes have different motivations and agendas all of that comes into play as a consultant on a daily basis, and I honed those skills working with adolescents and their parents, along with my professional colleagues in education.

The advice I’d give to someone becoming a developer is to build software and ship it — even small, silly apps. To contribute to open-source software. In short, to get your hands dirty and develop your programming skills through practice.

David Edwards

Location: New York, NY

Former Role: Endangered language revitalization

Current Role: Software Developer, Pivotal

Much of what WAYK (a comprehensive method for revitalizing endangered languages and skills) does to help communities is teach techniques for faster learning and teaching. Community members use these techniques to more quickly acquire language, and then to more efficiently share it with other community members. But many of the techniques we use for learning and teaching language work just as well for other domains. So when I’m diving into a new tech stack that I haven’t worked with before, or explaining an advanced concept to someone I’m pairing with, or discussing at standup how we’re going to pair up on outstanding items of work, I have a host of specific techniques in mind that I can bring to bear to move faster. (Things like, “prove your understanding by applying in a new context”, “find three concrete examples”, “prefer pairing someone with just-enough-context and almost-enough-context to pairing an expert with a newcomer”.)

Endangered Languages and Soft Problems

My advice to people switching careers is that there is no such thing as magic, and talent is often overrated. There are tricks and techniques for effective software development, just like there are tricks and techniques for cooking or gardening or getting organized, and you don’t have to be any kind of mythical talented programmer to learn them. When it gets hard, don’t lose heart — the problem isn’t that you aren’t cut out for this, you just need to learn the relevant technique. As a corollary, never forget to pay attention not just to what you are doing, but how you are doing it. When you work with skilled developers, watch for the techniques they use to find solutions, not just the solutions themselves.

Elena Sharma

Location: San Francisco, CA

Former Role: Writer

Current Role: Engineering Manager, Pivotal

Since I was a little kid, I’ve been obsessed with reading and writing — I wanted to consume and produce stories. I didn’t immediately choose to study English, instead waffling over almost ten choices, but ultimately it seemed the natural choice since I felt that English, at its core, spanned everything. I’d be studying how to think, write, and speak — nothing seemed more valuable to me.

One of the reasons I vacillated for so long about what I’d major in is because I had so many different interests. Over my college years, I started to realize that I couldn’t only take courses where the outcomes felt highly subjective, such as “furthering a discourse”. I loved the logic of my philosophy classes, and the beautiful simplicity at the core of complexity in my math classes. I took an introduction to computer science class and realized that with software engineering, I could combine creativity, communication, and logical reasoning. I was hooked.

I think there are a lot of parallels between writing and software engineering. To start with, English involved writing academic essays: given a system and its set of data (such as a novel), the writer creates an architecture that works within that system (a thesis statement about how to interpret selected pieces of the novel), having to ensure that the architecture is logical, each piece building on the previous piece by passing along the right messages. Analyzing literature meant reading between the lines and finding hidden complexity. Talking about literature meant taking large, complex ideas and rephrasing them constantly, making sure you were being clear to the consumer of your information (the person you were talking to). Creative writing meant thinking about the intended audience for the writing/product; potentially a large amount of research (like Googling, or using StackOverflow); breaking down a concept and transforming it into executable pieces. I could go on, but mainly I think English/writing and software engineering have so much overlap because they’re both about thinking.

I tell people to learn how to be comfortable being uncomfortable — you can’t store everything in your head, that’s what computers are for. Trust your gut — if you love analyzing and solving problems, then keep at it. Engineering software is often highly complex, but everything can be broken down into small chunks of logic in the end that you will be able to understand. Most of all, have fun with development: play around with technologies, research different ways of thinking, explain to others what you’re doing — you’ll learn how to talk about software engineering, and how to think.

Andrew Wright

Location: Tokyo, Japan

Former Role: Financial Marketing

Current Role: Software Engineer, Pivotal

I wasn’t happy in the financial services industry. I felt like my work wasn’t helping anyone, apart from shareholders. I spent a lot of my free time reading tech industry news and programming on the side, so I decided to try and do what I enjoyed. I had a strong urge to build things. I studied mathematics at university and when I graduated, I didn’t know what I wanted to do. I applied for a large number of graduate jobs in a variety of industries. Investment banking just happened to be one of the applications that was successful. That got me started on that career path. When I realized I actually wanted to be a programmer, I was already several years into it.

I had a family that I was supporting, so I was nervous about changing careers because I knew it would be difficult, if not impossible, to start a new career with the same salary. Indeed, my first job as an engineer was at a startup in Japan where I started out making roughly half of what I was getting before. I couldn’t have made the career change without the support of my wife, who became the primary earner for the family for several years.

A big obstacle was convincing potential employers to hire me in a role that I had no experience with. I had done some programming at high school, taken some computer science courses at university, and done some programming, but I didn’t have any experience as a professional software developer. In order to demonstrate that I could do it and have something that I could show employers, I decided to build something. Every morning I woke up an hour or two before my wife and son and worked on an iPhone app. I had to teach myself everything. The app was called My Tokyo Navi and it finds train routes in Tokyo. I haven’t touched it for years, but it still makes a bit of money even now, perhaps because it works offline. After I released the app, I used it to demonstrate my ability and managed to get a couple of job offers.

I think everyone says it but few people do it enough: network. I got my break by attending the Tokyo iOS meetup and talking with someone there. Go to meetups of all the things that you’re interested in. If you can, try to build things to show people what you can do. I chose to build an iOS app but these days it feels like everyone has a hobby app so maybe other areas would be better to pique an employer’s interest.

Bebe Peng

Location: New York, NY

Former Role: Mechanical and Applied Sciences Engineer

Current Role: Senior Software Engineer, Pivotal

I first wanted to become a mechanical engineer doing FIRST robotics after school. There’s something invigorating about building something with your two hands and seeing it work out there on the field. I wanted to design and build those things from scratch. In the workforce, I realized there was a lot less creation in the day-to-day job. There were crazy feedback loops. For example, to procure a common replacement screw that you can buy off the shelf at a hardware store I would have to create paperwork, get that paperwork approved by my management, send it to the government for funds approval, wait for procurement to come through, load-test the screw, write a procedure to replace the screw, get that procedure approved by my manager, the also get approval from the government, walk the screw from the load-testing facility to the trade workers with the procedure, and then wait for the work to be signed off. Replacing a screw took about 3 months or longer from when the problem was reported, to when it was fixed.

A Day in the Life of a Pivotal Engineer

What attracted me to programming was that fast feedback cycle. I can code a line, and literally see the results on the screen within seconds. With CI/CD, I can release reliable production ready software as often as I wish. The bulk of my previous job was getting ready for the defueling and decommissioning of the USS Enterprise. As a part of that work, I had to write a lot of procedures for mechanical work nuclear systems. Procedure writing is a lot like coding. Coding is basically a written procedure for a computer. Well-written procedures are written so that another human can easily understand.

My advice is to take time and focus on quality, and you will keep learning on the job. It’s a good investment to focus on maintainability.

Check out Pivotal’s careers page for exciting opportunities!

Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.

ReWired: Stories from the Indirect Path to Coding was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

“Star Wars was a phenomenon the likes of which certainly the entertainment industry had never seen.”

—Howard Roffman

Transcript

Michal Lev-Ram: I don’t start every interview with going back to the ’80s, I promise, but in this case it’s applicable. So you started in 1980 at Lucasfilm, just very quickly give us a brief overview of how your career trajectory went with the company, and you recently retired, so good timing for us.

Howard Roffman: Yeah, two months into retirement now.

Michal Lev-Ram: So far, so good?

Howard Roffman: So far it’s great. I’m loving it. Yeah, my career took a severe left turn when I got recruited to Lucasfilm. I had gone to school to be an attorney, I was practicing law in Washington D.C., minding my own business. Not terribly happy about it, but I wasn’t at the point of making a big life choice, and one night I got a call from a friend of mine who said, “How would you like to go to work for George Lucas?” The first question I had was, “What would George Lucas want with somebody like me?” There was no connection, but it turned out that there was a mutual friend, who was the general counsel of Lucasfilm, they were looking for a smart young attorney —

Michal Lev-Ram: Were you a Star Wars fan?

Howard Roffman: No, actually I wasn’t at that point. I was a George Lucas fan ’cause I liked American Graffiti very much, but Star Wars I didn’t quite get at that point. Things would change, but they flew me out to Los Angeles at the time, interviewed me, made me an offer on the spot, and all of a sudden I was in a very different —

Michal Lev-Ram: Galaxy far, far away?

Howard Roffman: Yeah.

Michal Lev-Ram: How were those early years? What was the culture like? What was the—it’s early on to have even started thinking about expanding from the core, right?

Howard Roffman: It was an amazing time for a lot of reasons. We were the kings of the mountain. Star Wars was a phenomenon the likes of which certainly the entertainment industry had never seen. I started the week that The Empire Strikes Back came out. There was a lot of doubt about will a sequel to that movie work? Everybody knew how successful Star Wars was, but it worked in spades, and then Return of the Jedi. We had the sense of not being able to do no wrong, so there was this beautiful myopic culture of infallibility, but it was also a very small company at that time.

Michal Lev-Ram: About how many people?

Howard Roffman: For the corporate part of it, there were about 70–75 people and then there was Industrial Light of Magic, which was our special effects house that had a couple hundred people at that point, so it was very small. George Lucas was somebody who was not reluctant to shake things up. He really understood that change was a way of life, and that he needed to be a change agent. Very shortly after I started, he fired the entire senior management, which was a good thing for the company, and a great thing for me. It changed my life.

Michal Lev-Ram: What was your mandate early on at the company?

Howard Roffman: The official mandate was just to do contracts. I was doing merchandise agreements, I did Harrison Ford’s agreement for Raiders of the Lost Ark. It was all these little things, but I was getting pulled into the general management of the company, so in a lot of ways my mandate became keeping things together while we are going through this tumultuous period.

Michal Lev-Ram: Then after, when was the decision made because at some point even the company went through a phase where the vast majority of revenue was actually on the licensing front, so when did that evolution happen?

Howard Roffman: For that initial period of the original trilogy, we were doing great, but in 1983, when Return of the Jedi came out, George also announced that he was getting divorced and going out of the Star Wars business, that he wasn’t gonna make any Star Wars movies, and that ground things to a halt.

Obviously the world didn’t stop. Our original audience was getting older, so much of our business was built around kids at that time, and kids grow up. The new generation was moving in, there was a lot of competition in the marketplace all of a sudden, syndicated television was coming on board, and that’s where kids were gravitating to, and Star Wars sales just plummeted at that point.

By 1985, you couldn’t give away Star Wars merchandise, and we had to make a decision to go underground, just turn things down, not try to drive the market so much. It wasn’t until the early ’90s that we really started to look at how do we bring Star Wars back. That was the pivotal time where we evolved into something that was 100% driven by theatrical movies to something that was driven more by consumer products.

“We had to recognize that our audience evolved.”

—Howard Roffman

Michal Lev-Ram: Okay, so walk us through the process, if you had a process, for once that got up and going. Did you have some kind of system for what you would do, what you didn’t do?

Howard Roffman: In retrospect, I had a brilliant process. When it was happening at the time, it was live and evolving, but the basic framework was that we had to recognize that our audience evolved, so if you were a 10 year old in 1977 when you saw the film originally, and that was the core audience, certainly the audience that was buying product. By 1990, you’re either finishing college, starting your career, starting a family, you’re at a very different life stage, and we started thinking, if people are still interested in Star Wars, what would interest them at that stage of their life? That’s when we started to think about things like continuing some of the stories of the characters in the films through novels ’cause we, at that point, we were out of the theatrical film business. So we looked at publishing as a very important way of reengaging the audience at this new life stage.

Michal Lev-Ram: Were there things you said no to?

Howard Roffman: There have always been things we’ve said no to. We get so many proposals for different things. One of the temptations of something as ubiquitous and powerful as Star Wars is that everybody wants a piece of it, so there’s a lot of greed at work and over enthusiasm and maybe things that just aren’t right for the ground.

Michal Lev-Ram: Maybe a more interesting question is what’s one thing that something that you said yes to, which you regret later…

Howard Roffman: I’m not sure that I can think of something … A specific thing that I regretted, there were definitely some partners that we went into business with that we regret going into business with because they just weren’t … Either they didn’t get Star Wars enough, or they didn’t really have the wherewithal to serve the consumer in the way that we needed for a brand like Star Wars.

30 Years of Tech Transitions

Michal Lev-Ram: So I think we tend to think of creative innovative companies as companies who move quickly, but putting together a movie, especially one with so many special effects and huge production teams, and everything that goes … Huge budgets, of course, takes a few years, and as we’ve seen especially recently, sometimes it takes even longer than was originally intended, so how do you guys … How did you internally balance that need to constantly innovate, and be creative, and give something new to this really loyal fan base?

Howard Roffman: You definitely have to look at the pre-Disney acquisition and the post-Disney acquisition because pre-Disney, we had the luxury of being a completely private company. We had one shareholder named George Lucas and that was it. So we served him, we weren’t driven by quarterly results or any of the things that drive public companies. It was very clear in the scheme of things that George was the person who was driving, making the films. So he worked according to his own schedule, and we had to work around that.

Michal Lev-Ram: Were there any downsides to that by the way?

Howard Roffman: There’s always downsides to everything. The original plan when George said he was going back to make the prequel trilogy was that the first one would be released in 1997, and that got moved to 1998, and then finally got moved to 1999. It completely wreaked havoc with all of our plans, with most of my life at that point, but it also forced us to come up with other ideas for what do you do to keep the plate spinning? What do you do to keep the audience engaged? Because we were very conscious of moving from this period that was driven by consumer products into a period that was once again gonna be driven by theatrical films, and the prospect of engaging, deeply engaging a new generation.

“We wanted it to be one universe, we really felt strongly that that is what it needed to be.”

—Howard Roffman

Michal Lev-Ram: Okay, so you brought up Disney as you guys probably know, Lucasfilm was bought … Was it 2013?

Howard Roffman: 2012.

Michal Lev-Ram: 2012, so just a few years back, and now there’s a movie coming out every year. In your experience, in the last few years at the company, how has that changed things? I’m sure there have been massive changes, but the schedule that you guys are now on …

Howard Roffman: It was funny to hear Michael Dell talking about how speed is a factor because that definitely happened when Disney acquired us. We were on a very constricted production schedule before, and as you say we went to one film a year. In addition to that, the creative center of the company completely changed.

Before it was George Lucas, George exited the company, all of a sudden you had Kathy Kennedy who was a very talented filmmaker and producer, but she’s not George Lucas. She understood that she was playing a different role, so she had to assemble a creative bench in a way that we never had before. So you have a lot of people weighing in, not always people who have the same deep understanding of what the Star Wars saga is about, particularly mythologically, and some of the reasons that it appeals so deeply to people. It was a little bit more filmmaking by committee, and then because of the amount of content, there were a lot of questions about where should the content go.

Up to that point, Star Wars had pretty much been a space soap opera where you had a certain group of characters that you were invested in, and you were following their continuing adventures. But now we’re in this paradigm of some of those, but also spinoff movies that tell ancillary stories. So what it’s meant is that everything that’s done with Star Wars right now, is a never been done before. What’s the amount of consumer products that should be out there? What’s the frequency of the movies? What should they cover? You’re getting new learning experiences every year. It’s really dynamic, it’s really interesting, it’s a bit scary especially for an old timer like me.

Michal Lev-Ram: So you were like I’m outta here?

Howard Roffman: No, no, no, no, no. I enjoyed the ride a lot, but after 37 years of doing it, there were other things I wanted to do with my life, so yeah. I have the highest respect for Disney and for all the filmmakers that are involved in this. It’s an amazing group of people.

Michal Lev-Ram: Any questions? It can be related to what you do, or it can be purely a Star Wars question. Yes.

Audience #1: Hi, I’m asking purely Star Wars question. I’m Enrique with the Defense Innovation Unit down in Silicon Valley. So okay, so you have a brand that has a massively rapid fan base, including people here wearing Star Wars socks, which I’m not wearing mine today, but —

Michal Lev-Ram: Wow.

Howard Roffman: Oh wow. Very good.

Audience #1: You got a rapid fan base, it seems like nowadays the way Disney handles Star Wars canon, very well controlled, very tight, but back in the ’90s when it’s a blueprint of books and games and other things, how did … Do you internally manage —

Howard Roffman: Yes.

Audience #1: True, or did you let the fans dictate? How do you guys —

Howard Roffman: No, no, no. We controlled it very tightly, and that was one of my mandates ’cause when I began the spinoff publishing program, it was a sacrosanct rule that everything had to relate to each other, be consistent to each other, and of course be consistent with the movies, which were canon. That was different from the way that Star Trek had done things, and we were pretty religious about doing that. Our biggest problem was a guy named George Lucas because he didn’t buy into … Necessarily buy into the spinoff fiction and game program, and all the alternate universal that we were creating.

We wanted it to be one universe, we really felt strongly that that is what it needed to be, but George as the filmmaker didn’t want to be beholden to somebody else’s creative vision. So we would have very interesting skirmishes ’cause we had a bunch of stuff that became, for the fans, pretty much canon about what happened after Return of the Jedi, what different places in the galaxy were called, and lots of different things, and if he was proposing to do something in the prequels that contradicted that, we would have long debates that usually ended, at least in the first session, with “I don’t care, this is what I’m doing,” and maybe in the fourth or fifth session it’ll be, “Well, alright, we could change it this way.” That was how it operated. Now that everything is controlled by one central committee, we can have cannon that applies across everything, so don’t judge us too harshly, please.

“Who shot first? I think it’s really clear.”

—Howard Roffman

Michal Lev-Ram: Other questions? Yes.

Audience #2: I have a regular question. Who shot first?

Howard Roffman: Who shot first? I think it’s really clear. Now look…that was a very unpleasant controversy. Clearly, Han shot first because he understood that if he didn’t he was gonna be shot first, and that was … that would be the end of things. And George went through this little moment in the course of doing the special edition in 1997 where he questioned the morality of that. Maybe without too … Maybe he should’ve questioned more what Han Solo’s character was, but he came to a conclusion that he then wasn’t that comfortable with, and it’s been changed several times since. I don’t know if you followed the frame counts around that little cut there, but it has gotten way more attention than it deserves.

Death of the Cubicle Farm

Audience #3: Can you walk us through … How did Jar Jar Binks actually come out and become a thing?

Howard Roffman: That’s a very neutral way of describing it. Well George … When he was writing episode one, was definitely enamored with the idea that you could create living creatures through CG, that could do things, and have appearances that could not be created in the practical world. So he put a lot of CG characters into that movie, and he was kind of looking at the antecedent of R2D2 and C3PO as comic relief, and feeling that he needed a new comic relief in the movie, and he came up with that character.

We were all … It was interesting ’cause when the movie was being shot, you didn’t really quite know what the character was gonna be. We knew what the physical look was … The guy who played him on set, Ahmed Best was literally wearing a stationary mask that was about a foot over his head, so the people would have the right eye lines, and Ahmed spoke in that voice, but George kept saying “Oh we’re gonna replace the voice. We’ll have Robin Williams record it,” or something like that, and much like with C3PO, where he was intending to replace the voice. When it came to post producing the film, he tried a bunch of different voices and finally decided that Ahmed’s voice was the perfect Jar Jar and had that kind of patois that Jar Jar has, and he really liked it.

Within the company, we had screened the film obviously way before it came out, there were some diametrically opposed camps as to whether Jar Jar was a great thing or whether Jar Jar was gonna be a PR disaster for us and not particularly embraced by people. Of course, it was George’s company, and he won out, so the film went out with Jar Jar.

I have to say, we were pretty surprised by the intensity of the reaction against him. It has … In some ways it’s tempered with time, and the thing that was very important to understand even back then was the … Where the polarization occurred ’cause the people that really hated him were fans of the original trilogy. That … You just wouldn’t of seen anything like that in the original trilogy. Kids liked him a lot until it became not cool to do it, which was one of the effects of a lot of people in the culture saying, “No, that’s not cool.” So probably more information than you wanted to know.

Michal Lev-Ram: Do you ever do an interview where Jar Jar doesn’t come up?

Howard Roffman: Yeah. So far we have two very outlying questions that are really interesting, though. Thank you.

Michal Lev-Ram: Thank you so much, Howard.

Howard Roffman: Thank you, Michal.

This video was filmed at the Built to Adapt conference in Sausalito, California. The transcript was edited for clarity.

Messing with a Classic was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

“The car is utilized four percent of the time. So it’s utilized less than some of those servers that you have sitting in that data center when you move to the cloud.”

—Raj Kapoor

Transcript

Michal Lev-Ram: What’s your take on—your prediction for autonomous vehicles?

Raj Kapoor: It’s here.

Michal Lev-Ram: Yeah.

Raj Kapoor: It’s happening.

Michal Lev-Ram: I had a feeling you would say that.

Raj Kapoor: Yeah.

Michal Lev-Ram: Not 10 years out.

Raj Kapoor: If you go to Phoenix right now, our partner Waymo is live, driverless. And it’s not from one specific route. It’s around a very large area.

Michal Lev-Ram: How many of you have been in an autonomous vehicle? Raise your hand. Okay, you need to invite a few people out to Phoenix apparently.

Raj Kapoor: They’ll be plenty of opportunities in 2018.

Michal Lev-Ram: Let’s start a little bit of a higher level overview of what your mandate is at Lyft.

Raj Kapoor: Sure. First of all, Lyft is a company. Mission is very clear, which is to improve people’s lives through the best transportation. Notice, that’s not just about ride sharing. I think the long term vision of Lyft is that people want to get from point A to point B. And we’re passionate that they can get there without owning a car. So if you think about cars, it’s probably the biggest waste of money that we’re facing right now as a generation. It is the second largest expense, after food, for a household.

The car is utilized four percent of the time. So it’s utilized less than some of those servers that you have sitting in that data center when you move to the cloud. There’s something fundamentally wrong about that. And, also, in addition to that, we’re seeing that it’s causing some societal problems too, which is that the congestion that I’m sure a lot of your experience in cities is at an all time high. Admissions and what we’re doing about climate change is also a big consideration there. So we think that the solution is really about moving about more efficiently, but making the experience and making the price point something that consumers are excited about.

Lyft started back at Zimride. My history there is a little bit different because I was actually an entrepreneur, then I was a VC, then I was an entrepreneur. And while I was a VC, I invested in Zimride. So I was on the board when it was about a 15 person company and then recently joined as chief strategy officer full time because I got so excited about what they’re doing. But really Lyft started out with looking at this transportation problem and seeing we could be more efficient.

Our founder, Logan Green, while everyone else was drinking a lot of beer at college, he was on the transportation board at UCSP. And he was trying to figure out and solve solutions around how can we get buses to be more full, why aren’t people sharing rides more. So he created what’s called a ride board, just like there’s a job board, and that was Zimride. And that was the company that I originally invested in. But like most great companies that are created, you never end up doing the thing that you started out doing. We pivoted.

The issue with Zimride was that people were using it, but how often do you need to go from San Francisco to LA? What we found was there was a much bigger problem intracity to go across the street and to go to work every day, etc. That use case was a lot more frequent. We saw that this little company called Uber was doing this thing with black cars. We thought, “Why not let this person over there that has a car that has space in there, why not let them drive? Why not make everyone a driver in doing it?”

So we launched it, fully illegally by the way. This was a big moment at the board. “This seems like a good idea, but it’s illegal. Should we do it?” And the answer was yes. We got it out the door, and the demand was just through the roof. Since there, the history’s been exciting. We’ve had a great year this year. We’re up to probably around triple the market share that we had. We’re doing over a million and a half rides a day. So things are moving in the right direction.

To bring it back to what you’re saying, it’s about improving people’s lives. And the next generation, which is really exciting is in transportation, is around autonomous. This is an interesting challenge for a company like Lyft. If you think about some of the large technology companies, they were disrupting another company that was not in their industry. For example, Facebook was thinking about how could I change the publishing world or Google in that case as well.

In our case, we have over 800,000 drivers that are making a living. So making this transition to something that is inevitable, that consumers want, that’s safer, that we can do more efficiently is something that’s important for us to do. But I think we have to do it with a lot of care both from a safety perspective, but also in terms of managing that workforce that is going to be needed for a very, very long time. The growth in our industry is such that for the next decade, we think we’ll have more drivers. It’s not that drivers are going away any time soon.

Michal Lev-Ram: I know you guys have also talked about the role of the workforce once autonomous is becoming more and more ubiquitous and that there might be other roles that you could provide for a workforce, so we can get to that later.

Raj Kapoor: Sure.

“When you’re operating a fleet the size that we are, the amount of data that we can bring into improve the software is massive.”

—Raj Kapoor

Michal Lev-Ram: But talk about … you explained some of the earlier iterations of the company. It’s very recent that you guys have really invested in coming out with developing your own autonomous, your own AV technology. I know you oversee partnerships, but talk about the thought process behind that because you have a partnership with Waymo. You’ve got several partnerships on the automaker/manufacturer side. Why build out some of the underlining technology to power AV yourselves?

Raj Kapoor: Yeah, there’s a couple of reasons. First of all, the future is very uncertain in terms of who is going to be the winner. Is this going to turn out to be a winner take all scenario where there’s one company that has the best software? And as you all know, it’s not just the software, it’s the data that’s gonna be powering and improving that software. Is that gonna be the case? Is it gonna be multiple companies. So, one was that there’s an uncertainty in the future, and this is our core business. We can’t just leave it up to a potential partnership.

Two is that we bring a lot to the table. The Lyft today in 2017 has an amazing brand, an amazing culture where we are. People want to come and work for us. So as a result, when we started these efforts to build our own system as well … we call it Level Five Engineering Center in Palo Alto. We’re at about 120 percent above recruiting in probably the most difficult area to recruit right now. I estimate there’s probably about five or 6,000 autonomous engineering jobs that need to be filled by probably 200 qualified people in doing it, that have experience in making that happen.

And so, I think getting the talent in the right place is important. The second piece that we bring to bear is the data that’s there, as I mentioned. We have 800,000 drivers. We’re doing over a million rides a day. What’s going to matter is how that system is able to perceive the world, and make decisions, and work through scenarios, and make sure that it’s handling those scenarios correctly, which means how much real world data can you get? When you’re operating a fleet the size that we are, the amount of data that we can bring into improve the software is massive. And it’s not really something that a lot have. We feel like we can bring that to the industry.

The other piece is that we have a lot of partners, and we kind of bifurcate it. There’s the open platform, which is the Waymo’s of the world, the Ford that we announced, NuTonomy, Drive AI, and others that are going to be announced. And then, we have our Level Five Engineering Center. Our belief is, we’re not trying to create something entirely proprietary that we’re going to take over the world. We just want to make sure that the building blocks are going to happen. That they’re going to be something that everyone can use. That the data’s available.

One example I’ll give you is that, today we all use Google Maps, and it can get you around. It’s great for your feed. It’s great if you’re driving. It doesn’t work in an autonomous vehicle. We need a map down to the centimeter to know where you are. So that’s one of the challenges that a vehicle has.

So now the entire industry has to recreate maps in the high definition level in doing it. So we’re in a position where we have all these drivers in now 370 cities around the country. We can be generating that map while those drivers are earning an income as well at the same time. So it gives us that advantage in doing it.

30 Years of Tech Transitions

Michal Lev-Ram: So, just real quick, walk us through some of the other building blocks because there’s a lot that goes into the recipe of now developing this on your own.

Raj Kapoor: Yeah. And I think there’s a simplistic way to think about an autonomous car. First of all, this would not have happened if it’s not right now at this moment in time where there’s so many technologies that have intersected, whether it’s machine learning in neural networks, and computer vision, and compute power going down.

So what does a car need to do? The first thing it needs to do … it asks itself several questions. First of all, where am I? And this is a concept called localization. It need to know where it is down to a centimeter. And, usually, it relies on an HD map. GPS only gets so far. It uses multiple sensors in it’s map to lock in and say, “Okay, this is exactly where I am.”

Now, it asks the next question is what do I see around me? Now, it’s using usually computer vision, but usually, you can also use radar. And you can LIDAR is a very big new technology. It’s basically a laser that’s pointing, that’s bopping around and creating a 3D map, a point cloud of what’s there. And we fuse all of those technologies, and then overlay it with some machine learning to say, “Oh, I can do object detection. Okay, that’s a person. That’s a static object, which is a stop sign. This is a road marking that’s there.” So it makes those determinations.

Then it has to think about what’s static and what’s dynamic. And now it does planning. It says, “Where is that dynamic object going to move in the next millisecond or the next second?” And it has to predict and make a prediction of where that object is moving. Then it has to ask the question of what do I do now based upon my environment, based upon a global objective in my map that I want to get to my destination. But I have to think about what I do for the next centimeter or two. Do I slightly turn the left? Do I go fast? Do I slow down? Where am I?

And you can imagine that this problem becomes harder and harder the faster that the car is going because its reaction time has to be very, very fast in doing it. So once it figures out what it’s going to do … and usually that is also an application that you can have of neural networks that can help you solve that problem. Then it actually has to execute the instruction. And this has to translate back into actuation. And a lot of cars now are being built with drive by wire systems. In fact, we got one delivered where I literally used a Nintendo controller to drive the car around because everything could be done by wire.

So that’s what we need, that kind of level of reliability in doing it. And then it goes and plays that over and over again. And then it takes all that data back and pushes it into the cloud. We analyze it. We run it through 10 times the amount of simulations and permutations on it, make the system better, flash the new software into the car. And that car is collecting potentially like a half a terabyte of data in a couple hours. So the scale at which we’re collecting data, processing data, and trying to make decisions has never really been done before, which makes it such a grand challenge in doing it.

So those are the technologies that are there. It involves the cloud. It involves compute in the car. One of the challenges that Detroit has is that … to put this full stack of technologies today cost about … my estimate is about $250,000. Now there’s no way you’re going to go to a Mercedes dealership and buy an add-on for $250,000. They estimate that the consumer even in the luxury segment is willing to pay about 10 or $15,000. So we need to see the cost of all of that compute, the cost of all of that hardware and software come down so that it can work.

The good news for ride sharing is that we’re not utilizing a car 4% like a consumer. We’re utilizing a car 80 percent. So my cost of what we can have in a vehicle can be a lot cheaper. So that poses a challenge for our industry because we need to develop this technology and throw it on top of existing cars because if we wait around for the passenger market, the consumer market, we’re going to be waiting for years. So that’s why you see all of us in this industry, including Waymo and ourselves, building stuff on top of existing cars because not for a long time will cars be coming off with the autonomous technology.

“Right now, 40,000 deaths a year in the United States, 1.3 million worldwide. 94 percent are due to human error. 94 percent. And with vehicle to vehicle communication and autonomy that’s there, you could reduce that down to practically nothing. And what happens then to insurance?”

—Raj Kapoor

Michal Lev-Ram: You mention that there’s a lot of uncertainty in the industry and a lot that needs to be figured out still. Where do you think this whole huge nebulous ecosystem could … what do you think it could look like a few years out? What’s the role of … GM is trying to do on its own a lot of what you’re describing regarding the stack, and you’re also partnering with them. So talk about the role of the auto manufacturers, the role of the ride sharing services, the role of insurance companies. How should they be thinking about this and their part in the ecosystem?

Raj Kapoor: So first of all, we are at a state in our industry … and this is a massive, massive opportunity. $2 trillion is the domestic opportunity for consumer transportation. So as a result, every player in the space is almost … it’s like their strategy is thrown up in the air right now. They’re trying to figure out what they should be doing. Should they be a mobility service provider? Should we be making cars? Should be vertically integrating into providing insurance? Everything is really up for grabs right now.

And that’s why you’re seeing lots of partnerships, and the next day you’re seeing partnerships with people that they though they weren’t going to partner with. And the next day you’re seeing different business models that are coming out. So none of this has been really settled. The other challenge that’s there in the industry is that nothing is really standard space today. So if I take one particular proprietary LIDAR, and I’m developing my perception software and all the way down the stack, it’s very specific to that.

Now if a new piece of LIDAR comes in, I have to retrain all those neural nets that are there. I have to also change some of the software, and I have to run it through a massive amount of testing and certification. Because the difference here is this is not just sitting in a data center. This is on wheels, and it could kill someone. So we have to have the redundancy of an airplane in our system.

So we’ve got usually two compute systems and a fail over system that can just take it to the curb in terms of making that happen. So my point there is the complexity and the lack of standards are causing a lot of vertical integration and partnerships of maybe I could use this technology. So some of that I think will play out over time in making that happen.

Now when you think about the larger ecosystem, there’s the vehicle, there’s the technology in the vehicle, but the impacts that autonomous are going to make happen like you’re alluding to are far reaching. So insurance is one of them certainly. Right now, 40,000 deaths a year in the United States, 1.3 million worldwide. 94 percent are due to human error. 94 percent. And with vehicle to vehicle communication and autonomy that’s there, you could reduce that down to practically nothing. And what happens then to insurance?

But there are other second order effects. So the city of Los Angeles estimates that they’re making about $250 million a year in revenue from parking tickets, speeding citations. That goes away. And the problem is that funds police, that funds schools. How are they going to now make up for that that’s there. The other effect is on cities. In Los Angeles, roughly 15% of all the real estate is parking. If you don’t need to park your car or you don’t own a car, what happens to all of that real estate? How do you redesign that? What happens to car dealerships?

So there’s a lot of open questions around where it is, but there’s going to be an opportunity for a lot of people in this ecosystem that’s going to be there. But we are going to go through a gut wrenching decade or so where everyone is jostling for a position.

Once in a Generation Shift

Michal Lev-Ram: Okay. Questions for Raj.

Michal Lev-Ram: Go ahead.

Audience #1: How will present thinking will be mended because that’s going to be a massive challenge? Something fatal happens and the government says no. Then you have to stop the business. So how do you think that you deal with that?

Raj Kapoor: Yeah, so first of all, so far the United States is moving in the right direction with having a federal safety standard where they’re setting out guidelines, which are still be developed. And then it is upon the industry to adhere to those guidelines. And when there are issues, they can go in and inspect and shutdown programs if necessary. So that’s how safety standards work.

Now from an indemnity perspective, I do believe it’s going to come down to the owner of the network, who is responsible at the end of the day that has that consumer relationship that’s there. And like in many products, there’s multiple companies in the supply chain and you do a root cause analysis to figure out and apportion out liability. So I don’t think there’s that much different than how complex products work today.

Michal Lev-Ram: Does that answer your question?

Audience #1: Yeah. if you come from a healthcare industry… If that company pays a billion dollars for one death, then how do these companies are going to pay a billion dollars cash back to that person?

Raj Kapoor: And that’s going to be an important question that consumers are going to ask before they step into an autonomous vehicle.

Audience #1: Yes.

Michal Lev-Ram: Yeah?

Audience #2: What do you think about the new comment on Tesla’s strategy and where do you think that will end up?

Raj Kapoor: Which particular part of Tesla’s strategy?

Audience #2: It’s that they’re outfitting all the cars with the gear to capture the data regardless of whether or not you’ve subscribed. And then can they, with their quality of radar and vision, can they achieve a level of performance that you think you could achieve with a different order of magnitude of investment in a vehicle?

Raj Kapoor: So there are kind of two separate questions there. One is Tesla has a strategy of collecting data and also potentially then enabling their owners to go into the ride sharing business. You’re sitting at home, and your car’s making money for you and coming back home. That’s a big cultural change, but regardless I think one of the challenges that people have to understand is one of the critical things in our business is wait time. Three minutes is the magic number. Got to be below three minutes. In order to hit that wait time, you need to have a lot of cars that are available in lots of sections of town.

Autonomous technology is not zero to one. It’s not what Google is doing right now in Phoenix even is perfect. It works in certain conditions. Every year we’re going to expand the operating envelope with that. So for a decade or longer, you’re going to have to have human drivers. And this is where I think we come in with 800,000 of them, which is going to make a difference. Second question was more technology, which is they’re trying to be zero LIDAR, much cheaper by the way. Because LIDAR today is very expensive to do it, 25 to $50,000 even $75,000.

There’s an open question as to whether that can work because vision is not good under all conditions that are there. And it’s certainly is not the safest approach today. If it evolves in that direction, maybe.

“Autonomous technology is not zero to one.”

—Raj Kapoor

Audience #3: How do you think about autonomous vehicles in the context of last month?

Raj Kapoor: So I think it’s absolutely an opportunity. And there’s some interesting startups that I’ve seen that are taking a totally different form factor for the robots. They could have a much smaller form factor. It is a much simpler problem because you don’t have to worry about a human being inside. You just have to worry about the last 50 feet and how you handle that. You could have a drone come out or you can have the person always come in there in doing that. But there’s a significant opportunity.

And then the other piece of it is that our business is driven by peaks just like most utilization businesses. And so the question is what do our vehicles do off peak? And delivery is certainly an option that’s there. It’s less of an issue in my opinion for what we have today because our drivers can be 100% utilized. And they’re coming on when they’re business versus us having a fixed asset, but that changes then in the world of autonomous.

Audience #3: How do autonomous vehicles deal with all the non-autonomous vehicles that are out there?

Raj Kapoor: Very carefully.

Audience #3: It’s a challenge, right?

Raj Kapoor: It’s a challenge, but it’s also been proven … there’s a study at MIT that even with a couple percentage points on the road of autonomous vehicles, you significantly alter the congestion and the safety because of the butterfly effect of it as well. So it doesn’t take a full turnover of the fleet for it to work.

Audience #4: Decision making. Are you doing machine learning models on the edge or just setting the data back to the cloud for the current process?

Raj Kapoor: Right now, this is what’s exciting. There’s totally different approaches. I’ve seen a company that takes in raw data from its sensors outputs accelerator and driving instructions. Then there others that break down into the four different things like for planning, prediction and have different models that are there. One of the biggest challenges you all know around machine learning and neural nets is that how do you diagnose when there’s a problem? How can you go back and troubleshoot?

So the bigger that envelope is that it’s covering, it can be challenging especially with liability issues or safety issues that happen. So it’s happening. Everything is happening at the edge centrally. There also has to be enough compute in the car because you can’t rely on network connectivity.

Data in Aisle 3

Audience #5: So looking at the future, what do you see as the role for autonomous personal air vehicles?

Raj Kapoor: To me, there’s just a whole other order and layer of challenges that are there from regulatory perspective, from a noise perspective, from an energy consumption perspective. I think it’ll happen at some point, but we are far from it. We have so many exciting challenges in land based autonomous vehicles that we’re focusing our energies on that.

Michal Lev-Ram: Other questions? So let me ask you one.

Raj Kapoor: Sure.

Michal Lev-Ram: You talked at length about the technology stack and one thing I think is interesting about your approach at Lyft is that you guys are also paying attention to the in car experience. And the company … Raj told some of the origin story about one of the founders, Logan. There’s another co-founder who came along a little bit later, John Zimmer. And it wasn’t Zimride because of John Zimmer by the way. It was Zimbabwe, right?

Raj Kapoor: Zimbabwe, yeah. Just coincidence.

Michal Lev-Ram: But they met eventually. Yes, very coincidental. But, anyways, but John Zimmer really came from the hospitality industry and that’s something that has been part of the DNA. If you’ve been in a Lyft from early on, the experience was different and you guys tried to create this very friendly environment. So how do you take those routes and advance that and expand it into this new technological era that you guys are going into?

Raj Kapoor: Yeah, that’s a really good question. So backdrop again what we have today. In ride sharing today, the real source of differentiation that we can do because we don’t really control the vehicle. It’s the driver’s vehicle. It is the quality of the driver and that personality of the driver. And that’s what we focused on at Lyft, and the culture, and the community around drivers. I almost guarantee if you walk into a Lyft today and ask them who do you like driving for, what do you enjoy more, you’ll get 8 out of 10 times that they’ll say Lyft because of that reason in doing that.

And it goes back and forth between the passengers and the drivers. So in the autonomous world, there isn’t a driver. There could be other forms of people in there. Either could be concierge. There could people that are helping. Let’s assume that there’s no one in there. The experience still matters. What matters is reliability, ETA, price, and experience. We think we have a really exciting opportunity to differentiate on experience, to bring some of that culture in that ethos.

One of the things that comes in is that Lyft from day one has been around shared. Shared results in about 25 to 30 percent cheaper price of ride if you share it with someone that you don’t know. People thought we were crazy. Over 50 percent of all rides in San Francisco are now shared. In every market where we offer it, it’s not about 40 percent of all rides. People are doing it the first time because of price. The second time because they like the experience of actually talking to a human being rather than looking at their phone. Amazing.

But I think we’re back. And so we see this opportunity to bring that human element in it, but it’s not just that. We’re going to now consider not cars as vehicles, but cars as cabins like you think about air travel. What’s going to matter for you is what are the amenities in there. I need to sleep on this ride. I want to play poker with three of my friends on this ride. I want the entertainment experience with 7.1 channel surround sound on this ride. I need the most optimal office with the best connectivity on this particular ride.

I need to have a six person soccer team that’s on this ride and entertain them while they’re going. So the opportunities because we freed up the time now in the vehicle and what you can do in there are going to be many. So the ability to differentiate on what you do during the ride becomes even more significant.

Michal Lev-Ram: All right. I think we’re all looking forward to that and especially to not having to drive. I think we all love driving. We don’t like commuting. That’s the problem. But thank you so much, Raj. We are out of time.

Raj Kapoor: Thank you.

Michal Lev-Ram: Appreciate you being here.

This video was filmed at the Built to Adapt conference in Sausalito, California. The transcript was edited for clarity.

Flying Cars to go With Our 140 Characters was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

“You have people starting at your companies next week, next month, next year, and all of them will start with empty email boxes, so completely cut off from the conversations that happened before they got there. And in the cases of large companies that have been around for a while, that can be hundreds of millions, billions, tens of billions of messages. And that’s a just completely insane approach to the basic knowledge management of that day to day communication.”

—Stewart Butterfield

Transcript

Susan Hobbs: Slack has been the new darling for a while now, but you’ve really got the numbers to back that up. I was looking, you have 6 million daily active users in more than 100 countries. 55% of those users are outside the united states, from my understanding, so not only do you have like a super solid foundation, but you’ve plenty of room to grow. 43% of these Fortune 100 companies use Slack, one of them is Liberty Mutual.

John Heveran: Indeed.

Susan Hobbs: Which was founded in 1912 and still going strong, growing. So, when I look at Slack, Slack was born organically as a communication tool from Tiny Speck. We talked about that a little bit earlier today. Could you explain channels and how this type of communication is different and better than maybe what we’ve used before?

Stewart Butterfield: I would love to. So, before I do, how many of you know that you’re customers of Slack? How many of you suspect that you might be unofficially? That’s pretty good. That’s an on top of it group of CIO’s.

The difference between channels and email, or addressing a message to a channel instead of addressing it to an individual or group of individuals, is that it’s much more accessible than it would otherwise be. So there’s a couple of things that 10, 20 years from now will seem crazy about the use of email in corporate environments and email definitely has its place, I don’t think it’s … We’re gonna have it for another many decades, or maybe even for many thousands of years to come. But, there’s 2 huge disadvantages to the use in team based work, and 1 is that messages are trapped in inboxes, so people just don’t see them. You’re having this conversation and there’s a constant tension between on the one hand, I’d like to be kept in the loop so please CC me, and on the other hand, I get way too much emails so quit CC-ing me on everything.

And then the second one is you have people starting at your companies next week, next month, next year, and all of them will start with empty email boxes, so completely cut off from the conversations that happened before you got there. And in the cases of large companies that have been around for a while, that can be hundreds of millions, billions, tens of billions of messages. And that’s a just completely insane approach to the basic knowledge management of that day to day communication.

So, channels in contrast are pulled rather than pushed, depending on how you look at it. They’re accessible even if they’re not actually being accessed by everyone on the team. And I’ll give just one quick example. We have accounts dash customer name, for all of our big customers, and we were closing Oracle, who’s now our second biggest customer about 3 months ago. And I was doing this demo and I could go and see where we’re at with the vendor approval process, the security review, the negotiating the terms, redline MSA back and forth. And, that’s great, so I didn’t have to ask someone and compile a report and send it back. But it wasn’t just me who had access, it was everyone at the company, theoretically. Including engineers who were working on features that were blocked. We’re blocking the deployment at Oracle. And there’s … That context is invaluable and you never know exactly what context is gonna be important, and we can come back to that later.

Susan Hobbs: Cool. So, John you use Slack at Liberty Mutual, and actually, Stewart you use Liberty Mutual at Slack.

Stewart Butterfield: That’s true. We just switched providers.

John Heveran: Thank you.

Susan Hobbs: Can you tell me a little bit about how you use Slack as a tool? And do you like it? Why do you like it? Why do you not like it?

John Heveran: Sure, love it. Everyone should get it. But no seriously, this was a, from the ground up. Our engineers basically started using it and said, “We absolutely want to use it more pervasively.” We we’re doing a lot more agile development across the organization, and it really had taken off. It had taken off in terms of the free version, so, as was mentioned earlier, in terms of the conversion was, people wanted, the developers wanted to convert to — well I should say, the managers wanted to convert to the corporate version for some security and data retention reasons.

But one of the things was, it was really about the ease of use. And, every engineer was … When we upgraded to an enterprise agreement, in the early days we had some issues with our single sign on internally, nothing as a result of Slack but more of kind of how we implemented it. And we almost had a revolt, right? The developers were like, “Screw it. I’m going back to the free version, gimme a call when you’re ready. But I am not losing this productivity.” And it really was this idea that I could be in touch with everyone on my team or other teams seamlessly. Whether I was on my phone, on my work laptop, on my personal laptop, wherever it was. And it was a really compelling value proposition, that kinda snuck up on us honestly, and again, this idea of empowering the engineers in the company. Which is a new concept for a company like Liberty Mutual to really start to empower that community, and we’ve learned an awful lot with it.

“ We were entering a completely new area of the market. And the mantra was, act like a startup… And it really changed both the business’ expectation of what you could achieve with a development organization”

—John Heveran

Susan Hobbs: Now, Slack’s not the only new enterprise tool that you’re familiar with. You headed up a bold experiment at Liberty Mutual, where you brought something to market in just 7 months, which is unusual for what it was. I’d love for you to share, with the room, about …

John Heveran: Sure

Susan Hobbs: About what happened.

John Heveran: We were going into a new business. We were extending our benefits business. This is a business that provides employers, long term, short term disability, other hospital coverage, other types of benefit products that you would use through you’re own company. We were entering a completely new area of the market.

And the mantra was, act like a startup. And so the first step was sitting down with that business leadership team and saying, “Okay, so if we’re really gonna do this, then that means its full agile, full dev ops, release the production daily, every developer owns their code through production. You know, all the things that Pivotal and others, and I’m sure Slack do. Which was very unusual for a company like Liberty. And the business leadership team was impressed, and was impressed with the pitch and said, “Sure, we’re all in.”

And so the first step was, well how are we gonna do this? And we didn’t hold a meeting or a committee to decide, we opened an AWS account and started coding. Now, that kinda freaked out some people, but we got past that, we worked past that, the business was our ally in that. And we took … From nothing to a full insurance platform, so quote to cash, claims, billing, everything, all financial transactions, everything, native in AWS in 7 months and went live. And it really changed both the business’ expectation of what you could achieve with a development organization and it really helped jumpstart what we were doing internally and some of these ideas that were, in pockets and they were nascent but to be able to see the art of the possible in the large companies that many of the folks here represent.

We hear about these things, we read about these things, its like, “Well, its not really possible in my environment,” and we were able to do it. And that team and a number of other teams would never turn back, well, if we made them turn back they would leave so we’re not gonna make them turn back.

Susan Hobbs: So, how do you overcome, and this is for each of you, how do you overcome the nobody ever got fired for buying X argument.

John Heveran: No, I mean, I think our culture has changed dramatically in the last 2,3 years. Through a number of … And this isn’t the only the experiment in the new business launch that I mentioned. And this has been, this kind of constant evolution and, one success, and there’s been some snafus, some failures. But, the beauty of this team is releasing over 1000 times a week to production. The beauty is they screw stuff up but, they can redeploy it. And all of the things that Pivotal and others talk about, it really is real and it’s about just giving people that freedom. So, the culture is rapidly shifting so that it’s not, I wouldn’t say it’s perfect but it’s not so much that, if you don’t go with the marquee thing you’ll be kind of banished.

Susan Hobbs: What about you Stewart? How do you approach this as somebody coming in as a relative newcomer.

Stewart Butterfield: I got this from Jeff Smith who was CEO of IBM until maybe 8 months ago or so. IBM’s our biggest customer so we’re very grateful, and he had a real agenda. And my lack of experience in this domain had me a little bit surprised of that. Like, how he didn’t view his role at IBM as one that was just supporting and enabling the use of technology, but he wanted to see wholesale change, and there’s 380,000 employees there. And, they have tens of thousands, bigger than my hometown, whole groups of people to move over from one methodology to another methodology.

And what’s interesting, you look at both ends of the spectrum, so all of you presumably, have some kind of agendas. No one is an executive and says, “Things are fine exactly as they are, steady on, we don’t intend to change anything.”

The other hand you look at what its like to be an “end-user” inside of these organizations, just a regular employee. TV show The Office, the movie The Office Space, Dilbert, all of the common tropes of modern corporate life are, bosses are a bunch of idiots, I don’t know what’s going on, and usually there’s that missing context and what do the executive want? They want alignment, they want shared consciousness, they want to break down silos. The interesting thing is it’s exactly the same thing. The people literally want … The bosses and the workers all want exactly the same thing so the force of that bottoms up, swell that you’ve experienced, and the force we see often we see from executives, like in a top down motion towards Slack is, it breaks right through that, no one gets fired for X. And also I think that we’re, more or less, a new category, and things are changing pretty rapidly so there isn’t a big incumbent that we’re displacing. Other than email, and no one really owns email.

John Heveran: Right.

“If you educate people about security and really what you’re trying to kind of prevent, they’ll come up with creative solutions.”

—John Heveran

Susan Hobbs: Yeah. So, because communication is happening in all these new places, how do you keep it secure?

Stewart Butterfield: By hiring great security people. And doing our ISO 27001. So, what’s interesting is a lot of the concerns were not what we originally anticipated.

So, very few breaches, very few actual incidences of data loss are like there’s a black VT100 terminal with green text and people are doing crazy network hacks. It’s a lot of either bad actors internally, or poorly implemented processes or poorly supervised processes. And, one of the big concerns from customers was, this massive increase in transparency, so, going from like, I have 3 basis points of percentage access to all the communication that’s happening in the company, to 30%, or something like that. That’s a many orders of magnitude more access to information. Now there’s a lot of people seeing stuff that I didn’t want them to see in the first place. So, DLP can cover a small number of easily pattern matched data types. But then there’s a new, almost like a sociological change that you have to have happen inside the company so that people take a little bit more responsibility for the kind of conversations they’re having and at what scope. I would say that 95% of the security and policy related concerns are just like the regulatory and compliance concerns, in other words, they’re about people as opposed to software.

Susan Hobbs: And, what have you found?

John Heveran: Yeah, I mean, I think people are a generally inherently good. And as humans we have this natural tendency for self-preservation, right?

Susan Hobbs: Mm-hmm (affirmative)

John Heveran: So, you can not get in a car accident if you never drive your car. It may inhibit your ability to travel, but you don’t swerve into oncoming traffic because there’s a bad outcome. And so I think it’s about this, and what I like about Slack is the access to information and treating people like adults and kind of giving them some guidelines, they can make the right decisions.

People are releasing code to production, like I said, 1000 times a week and it’s not willy nilly. They’re trying to make sure that it’s completely checked, that the quality is there, and does every now and then something go wrong? Yep, you can change it. That’s the beauty of software. You can change it quickly, if you’re set up in that model. And I think the other thing is, if you educate people about security and really what you’re trying to kind of prevent, they’ll come up with creative solutions. So, when we did this new business launch. They developed all the services in AWS. There’s not a single console access to anything. It’s all controlled through code. You can’t deploy unencrypted services, it’ll automatically shut it down. Those are just things you can engineer in, and about educating people what the outcome you’re trying to achieve, generally, engineers love to kind of solve those problems and then share them so that other people can learn from ‘em.

Susan Hobbs: So this is how you’ve re-architected your platform to be cloud native?

John Heveran: Absolutely, and we did with a … We built a lot of software ourself, but we did it inherently with a pretty monolithic third party insurance suite, that we run completely in the cloud. And, at times, I had more problems with them than I did internally, because we were kind of pushing them into this. They’ve now completely converted. They’re redesigning their platform to be 100% cloud native. But they were nervous as a software company about the lack of control that they were giving up.

“Usually people show up on their first day on the job and they’re introduced to a couple peers, they know their manager, and they begin to start to triangulate the actual social structures. Almost like a process of echolocation…”

—Stewart Butterfield

Susan Hobbs: Interesting. So, Stewart, you talked about how on day 1 an employee comes in and you’ve got a company like Liberty Mutual, or any of these companies in the room, and if all of the data is siloed in email, then its like, “Oh yeah, maybe I should send you a few of these things, maybe there’s a Wiki or something that like exists from years ago. How does that really work, when I come and show up on day one, and Slack’s implemented in this enterprise, how do I know where to go look? Does somebody tell me? How does all that happen?

Stewart Butterfield: Yeah so there’s a lot of … Usually people show up on their first day on the job and they’re introduced to a couple peers, they know their manager, and they begin to start to triangulate the actual social structures. Almost like a process of echolocation, like you say something and you see who responds. And, slowly discern who really makes the decision, who knows the answers to what kind of questions. That stuff happens a lot faster. So usually, well managed Slack using organization, there are a set of channels. People have created user groups, if this is your role you’re automatically added to a bunch and then search should be relatively easy and then you start to discover and then there’s a little bit of word in mouth.

But, being able to just have the scroll back over what’s happened in the last couple months for either the closest working group, you know, the 5, 8, maybe 15 person, and then the slightly larger groups, either functional, business unit related. They’re having those conversations, super valuable. But, maybe even more valuable is starting to detect the social patterns, like the expectations around response times, how serious versus how freewheeling the conversation is in the different channels. And people come up to speed way faster.

Susan Hobbs: That’s great. So, ultimately, I think that this kinds of things that we’ve been talking about so far have talked about changing the bottom line satisfaction for people in their jobs, right? So, in today’s competitive talent market, how do we better serve the people who’ve joined our team to better create that kind of loyalty and make it something that they really wanna be a part of.

John Heveran: Well, its interesting. We’ve done a couple things that … I think it’s even surprised us in terms of how well they were accepted. So, first we went and we implemented flexible work schedules, which, if you’ve never worked in an insurance company, you haven’t worked. I’m just gonna tell you that right now. So, to say we’re rule followers is an understatement. So, this idea of, well what do you mean they can set their own schedule, if they talk with their manager. And so we did this and 3 years later, it’s the number 1 customer, kind of, satisfaction metric. All new employees, I talk to interns, summer interns, new hires, college hires, they all cite that as the number 1 reason. We just introduced a new, much more generous leave program. Rave reviews from employee base.

Susan Hobbs: Parental leave, right?

John Heveran: Parental leave, yes, yes, parental leave, yes. And so, I think, like the experiment we took in the technology we tried some of these things ’cause we were really trying to challenge some of the status quo, and just really surprised how much it took hold. And it wasn’t small groups or small it is, how pervasive the openness to it was.

Susan Hobbs: It sounds like a lot of what we’ve been talking about actually boils down to just trust. Trust of the people that we work with, trust that the people can handle these kinds of freedoms of information, of being able to deploy things. I think that’s really, really interesting. So, in the whole, future of work, that we were titled to talk about, and also to what Aaron with AI being terrifying,

John Heveran: Yeah

Stewart Butterfield: Yeah, and useful right? Yeah.

Once in a Generation Shift

Susan Hobbs: And good, and good. So, last week my former colleague, Sam Altman, proposed an idea on Twitter for feedback called, American Equity. I don’t know if any of you saw this or if any of you follow Sam, but basically he was saying, each U.S. citizen should get a share of the U.S. GDP each year. And the initial feedback that I saw when I went and did this search and kind of poked around was like, “Oh, you’re just re-skinning universal basic income.” And while there might be some truth to that, I believe that those of us in the Silicon Valley who are quote, unquote, disrupting. Really there’s a lot of people who have a strong conscience about what this innovation looks like, what does our future workforce look like, and how does the speed of automation affect that? So, maybe Stewart you could answer, is the future of work less jobs, or different jobs, or…

Stewart Butterfield: No I don’t think so. You look, 150 years you can see the whole U.S. workforce has rolled over it’s jobs 3 or 4 times. Everyone approximately was a farmer in 1820 in the United States. Now there’s 1.9% of the population that works in agriculture, and those jobs are totally different, and this is actually interesting. We were talking about this before, Henry Ford could walk around the factory and look at stuff that just seemed like it was inefficient. That this person’s walking back and forth a lot, we should move these two things together, or split these jobs up. Knowledge work is a lot less easy to inspect, and it’s less tangible, it’s hard to know exactly what’s going on, it’s really hard to spot those efficiencies. But definitely people change what they’re doing.

There’s this, I wish I was clever enough to have come up with this, but, Benedict Evans at Andreessen Horowitz pointed out that this 1960 movie called, “The Apartment,” Jack Lemmon, Shirley MacLaine. And, Jack’s job is to sit at a desk. He’s got an electromagnetic adding machine, he’s got a typewriter, people come by with a little trolley, a sheaf of papers, they hand it to him, he looks it up, he performs a bunch of calculation, he types up the results, and hands it out. And there’s these incredible shots in the movie of just rows and columns of desks that stretch out into infinity. What is he? A cell in a spreadsheet. I mean, in an absolutely literal, very straightforward sense, the whole floor of this office building is like one worksheet, and the whole building is like a giant Excel file.

And no one does that anymore. We joked about this a little bit, hopefully there’s very few people doing that exact job now. Probably around the same number of employees, hopefully a lot more efficient. And, it’s like we’re 7 steps away from universal basic income, which is probably a good idea. But, those jobs are just not gonna go away. There’s always the opportunities. When we think about AI, I agree with everything Aaron had to say, really less about replacing the human, and more about augmenting. So, most of you are close enough to my age that you probably remember Texas Instruments’ calculators being introduced into schools. So, like there was one point where you should learn how to do arithmetic by yourself, and you shoulda learn how to do long division, and then you can just immediately forget how to do long division forever. Some of us are blessed with good arithmetic ability in their heads, and that can be very useful, but mostly it doesn’t matter. It’s mostly better that you learn how to use a calculator, you learned how to use Mathematica, if that’s your thing, you learn how to use Excel. And you let the computers do what computers are better at.

I think there’s a huge opportunity, just around, and I’ll wrap this up, I apologize. But, the 30%, and I’m making that up of knowledge worker time that is spent finding the answers or asking the questions around basic factual issues. Like, who is this person’s manager, like you mentioned, what is our revenue for this unit in this quarter? Who has a good contact at this customer company, even like, where is the paper for the copier? That kind of stuff.

But a lot of it is … We’re not actually applying human intelligence and human creativity. We’re doing these rote things. To the extent that technology is able to help there, I think there’s huge upside. We have this experience as consumers where you start typing your query into Google, you type 1/3 of it, it’s already predicted what you were gonna ask, you hit enter and then like 700 milliseconds later, the result is one boxed. Unfortunately, it’s actually much harder when you have less data to search, and you have less interactivity from humans and fewer people involved. But we’re, and I don’t mean Slack specifically, we and the people who have 500 times our R&D budgets are making some progress on these problems.

And imagine in the future where rather than people getting pestered, like constantly peppered with these questions that they have to … Or going to, trying to find the person who knows the answer in their 180,000 person company. Infinitely patient bots, who have perfect memory, who aren’t bothered or disturbed by this and can just answer the same question, same stupid question, over and over and over again. How do I do my 401k something, something? Where do I go for whatever? And that, as mundane as that might sound, I think, is the source, potentially, of double digit productivity increases over the next 20 or 30 years.

“We went to our business partner, and pitched this idea and tried to set a realistic expectation of just what it would be like. But it felt like a lot less control and a lot less certainty, right? But in the end, it was more.”

—John Heveran

Susan Hobbs: Cool. Does anybody have a question for Stewart or John before we wrap up?

Audience #1: I’ll take one. Game Neverending, are you gonna take another stab when you’re through?

Stewart Butterfield: The background for the question is, me and some colleagues started a game company, failed. We made Flickr. We started again, it failed. We made Slack. No, I’m done. This is good.]

Susan Hobbs: No, no third time?

Stewart Butterfield: Twenty or thirty years.

John Heveran: Third time’s the charm.

Stewart Butterfield: Yeah, no. Too hard.

Susan Hobbs: Alright.

Audience #2: Chat bots, actually inside Slack, for real chat bots

Stewart Butterfield: Yeah.

Audience #2: Can we take whatever Mutual does without employee abuse? We haven’t seen yet ubiquitous, in this customer base, people do that inside Slack? But everyone using Slack and then their using CD next to it, do you see that as being the next logical place for Slack to go?

Stewart Butterfield: Yeah, I think, for a lot of the AI stuff, chat bots as a way of doing stateful query construction. ’Cause some people, for most people, it’s hard to construct a query that’s gonna find exactly what you want, especially with a whole bunch of operators. So, if you can refine what you’re looking for, your questionable you are looking for, in the context of a conversation with a chat bot, I think that’s great. A lot of it is chat bots that have 0 intelligence. And they don’t even have ELIZA from 1965. But that’s okay, because I don’t want them to, I just want them to be notified.

We have a help desk system that’s totally integrated with slack. I put in a ticket, I get a response back from the bot. I can respond to that, but it’s not a conversation. Like, we’re not friends or anything like that. It’s just a better update mechanism for those kinds of notification, and I think we’ll see huge amounts of implementation of that kinds of stuff. So, it’s surfacing a work flow.

And it really can be as dumb as a notification, and that can make a huge difference to your life, ’cause you think about, you get an email from your HRIS or from your expense tracking system. Click the link, browser opens, app starts to load, you get bound SSO, you auth, you come back, and then you’re allowed to press accept, or approve, or reject, or whatever it is. That can just come in the message itself, and you can approve or reject it in the context of the message without a separate authentication step. That’s not chat bots like, they’re smart. But, its chat bots like they’re useful.

John Heveran: Yeah, I completely agree, and I think chat bots are the best and the worst thing that are out there right now. In terms of all those examples, perfect. It’s this kind of extrapolation of, and they’ll be able to do everything. And I’m like, “If you can develop a chat bot that can talk to my mother, and understand what question she’s asking, I wanna invest.” Right? ’Cause she calls customer service and it’s this whole conversation, and she’s not gonna, it’s very narrow. I love my mother, okay?

Susan Hobbs: Well, there’s one other thing that I actually wanted to kind of wrap up with you John, and that was in this whole big experiment that you did, there was something about the way that you prepared for it that really spoke to me and I think that this applies to anybody in this room, I think it applies to startups, especially when they get to that first, kind of like, breaking point when you get that many people and you hit all those little spots along the way. And, that was how you approached this as leadership in doing something like this.

John Heveran: Yeah, we went and it was a gamble. We went to our business partner, and pitched this idea and tried to set a realistic expectation of just what it would be like. But it felt like a lot less control and a lot less certainty, right? But in the end, it was more. So, we got them really engaged from the get go, to where they were bought in and they were out there promoting and pushing. And so, whenever we ran into an internal obstacle, we were a unified voice. So the leadership team was set on, what are the objectives, and then the other part was, they got out of the way for the rest of it. We were very clear about what success looks like, in a very kinda tangible, measurable way. And then we let the teams decide how to achieve that success, right? They knew they had to achieve certain implementation goals, certain sales goals, and then it was, go figure out what the best way to do that is.

Susan Hobbs: So, you did the work up front?

John Heveran: Absolutely.

Susan Hobbs: Well that’s great. Thank you both so much for coming and being here.

This video was filmed at the Built to Adapt conference in Sausalito, California. The transcript was edited for clarity.

Death of the Cubicle Farm was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.