Tag: workforce

  • What Is the Future Workforce and How Will it Impact DevOps Teams?

    What Is the Future Workforce and How Will it Impact DevOps Teams?

    The rapid changes in technology, work patterns and demographics are ushering in a new era for the labor market known as the future workforce. In this context, DevOps teams—tasked with developing and delivering software quickly and efficiently—are facing novel challenges and opportunities. 

    This article will explore the key characteristics of the future workforce, from remote working to the gig economy, and explores how these changes will impact the roles, practices, and skill sets of DevOps teams. Understanding these dynamics is crucial for both staying competitive and fostering innovation in an ever-evolving professional landscape.

    What Is the Future Workforce?

    The future workforce refers to the evolving nature of the labor market, shaped by factors such as rapid technological advancements, demographic shifts, and changes in work patterns and organization. It’s a concept that’s important to understand given its profound implications for businesses, employees, and society at large.

    The future workforce is already here, and it’s changing the way we work. With every passing day, traditional work models are being challenged and redefined, leading to a professional landscape that’s increasingly diverse and dynamic.

    By exploring the future workforce, you’re not just preparing for changes that may affect your career or business. You’re also discovering opportunities for growth and innovation. Whether you’re an employee looking to future-proof your career, a business owner seeking to attract and retain top talent, or a policymaker aiming to foster economic development, understanding the future workforce is crucial.

    The Composition of the Future Workforce

    Remote Workers

    One of the most significant shifts in the future workforce is the rise of remote workers. As technology continues to evolve, more and more people are choosing to work from home or any location of their choice. This trend is driven by many factors, including the desire for a better work-life balance, the need to save time and money on commuting, and the opportunity to work in a more comfortable and personalized environment.

    Remote working isn’t just good for employees; it’s also beneficial for businesses. Companies that embrace remote work can tap into a global talent pool, reduce overhead costs and increase productivity. 

    However, managing a remote workforce requires a different set of skills and strategies. For instance, businesses must invest in technology to facilitate communication and collaboration, establish clear expectations and performance metrics and foster a culture of trust and accountability.

    Gig Economy

    Another key feature of the future workforce is the gig economy, characterized by temporary, flexible jobs often facilitated by digital platforms. The gig economy includes a wide range of work arrangements, from freelance work and contract-based projects to short-term jobs and on-demand services. In the gig economy, you’re not tied to a single employer or a rigid work schedule, giving you greater flexibility and control over your work.

    The gig economy offers many benefits, such as the ability to earn additional income, the flexibility to work when and where you want, and the opportunity to pursue a variety of work experiences. However, it also comes with challenges. Gig workers often face job insecurity, lack of benefits, and financial instability. Therefore, navigating the gig economy requires careful planning and management.

    Diverse Demographics

    The future workforce is also marked by increasing diversity. This includes not just racial and ethnic diversity but also diversity in terms of age, sexual orientation, disability status and other characteristics. As society becomes more diverse, so does the workplace. This trend reflects not just demographic shifts but also changes in societal attitudes and legal frameworks.

    Diversity in the workforce is not just a matter of fairness and equality, it’s also a business imperative. Numerous studies have shown that diverse teams are more innovative, creative, and effective. Companies need to foster an inclusive culture, implement fair recruitment and promotion practices, and address unconscious bias and discrimination.

    Future Workforce and the Implications for DevOps Teams

    As the nature of the workforce evolves, DevOps teams, traditionally centered on rapid and efficient software development, are increasingly distributed across various locations and time zones. This shift towards a distributed workforce presents unique challenges and opportunities for DevOps practices.

    Distributed Team Dynamics in DevOps

    The essence of DevOps lies in a continuous cycle of collaboration and improvement. In a distributed setting, this requires enhanced communication strategies to ensure that team members are consistently aligned with project goals and timelines. Utilizing collaborative tools and platforms becomes crucial in bridging the geographical gaps. Regular virtual meetings and real-time collaborative environments are pivotal for maintaining team cohesiveness.

    Continuous Integration and Deployment (CI/CD) in a Distributed Setting

    Managing a CI/CD pipeline in a distributed team demands meticulous planning and coordination. DevOps must adapt to different time zones and work schedules, ensuring that the pipeline remains efficient and uninterrupted. This involves automating as many processes as possible and establishing clear protocols for code integration, testing, and deployment, thus reducing bottlenecks and ensuring continuous delivery.

    Infrastructure Management Across Borders

    In distributed teams, infrastructure management must focus on clarity and accessibility. This means maintaining comprehensive documentation ensuring all team members, regardless of location, have a clear understanding of the entire infrastructure. Emphasizing cloud-based solutions can offer a centralized and accessible platform for all team members, thus simplifying remote infrastructure management.

    Emphasizing Security in a Distributed Environment

    Security challenges are amplified in a distributed setup, as team members may access company resources from various, potentially unsecured networks. DevOps teams must implement stringent security protocols and regular training to mitigate these risks. This includes the use of VPNs, regular security audits, and ensuring that all team members are up-to-date with the latest security practices.

    Nurturing a Unified Culture

    Despite physical distances, cultivating a strong, unified team culture is vital. This involves not just the regular technical sync-ups but also creating opportunities for informal interactions and team building. Encouraging open communication and transparency can help in building trust and a sense of community among team members.

    Skill Sets for DevOps in a Future Workforce

    As DevOps teams navigate the future workforce, there are several key skill sets that will become increasingly important.

    Security Skills

    As mentioned earlier, security will be a major concern in the future workforce. DevOps teams will need to have strong security skills, including understanding of security principles, knowledge of security tools and technologies, and the ability to implement secure coding practices.

    It will also be important to stay up-to-date with the latest security threats and trends, as the landscape is constantly evolving.

    Soft Skills

    While technical skills are undoubtedly important, the value of soft skills in the future workforce should not be underestimated. Skills such as communication, teamwork, problem-solving, and adaptability will be essential for success.

    As teams become more distributed and work becomes more complex, the ability to effectively communicate and collaborate will be key. Additionally, the fast-paced nature of technology means that adaptability and the ability to learn quickly will be highly valued.

    Collaboration and Project Management

    In the future workforce, collaboration and project management skills will be crucial. DevOps teams will need to be able to work effectively with a diverse range of stakeholders, from developers and operations staff to business leaders and customers.

    This involves being able to manage projects effectively, from planning and execution to monitoring and controlling. Knowledge of project management methodologies, tools, and techniques will be highly beneficial.

    Conclusion

    In conclusion, the future workforce will bring about significant changes to the professional landscape. As we navigate this new terrain, it’s important for DevOps teams to be aware of these changes and to develop the necessary skills to thrive. By focusing on continuous integration and deployment, infrastructure management, unified communication, and security, DevOps teams can stay ahead of the curve and continue to deliver high-quality software products.

  • Don’t Let Developer Toil Affect the Business Value of Your Apps

    Don’t Let Developer Toil Affect the Business Value of Your Apps

    It is no surprise that the world today is driven by apps. Organizations all over the world are basing their business goals on their capacity to integrate new apps quickly, and they need to constantly reimagine how they interact with and communicate with their consumers and employees to fulfill changing expectations. To do this effectively, businesses need to operate at a high level of speed and agility. But in many cases, this isn’t happening. The phrase ‘move fast and break things’ could not be further from the truth when it comes to how enterprises approach innovation today. In fact, according to Forrester Consulting, 48% of executives say they haven’t changed their applications in a year or more. One reason for this may be that organizations are dealing with a high amount of developer toil and technical debt. Developer toil is the repetitive, predictable, constant stream of tasks that support the creation of software and how it’s run, but don’t actually affect the features in the software that people use. Or in other words “any activities that don’t directly create business value.”

    Typically, developers spend too much time on processes that could be automated or even eliminated. Ironically, this toil builds up over time as their organizations prioritize shipping features rather than addressing these problems in their overall software process. While developers can change their software quickly at first, just like debt in real life, if this toil and tech debt are neglected, it takes over and consumes the organization’s ability to grow. This results in long, infrequent release cycles. A feature that seemed simple and once took just 15 minutes now takes weeks, even months, to get in front of users.

    Conducting a Developer Toil Audit

    Anything you can do to speed up your software release cycle will improve the quality, resilience and business value of your software. Continuously addressing developer toil provides a significant boost to your organization’s software capabilities. For one of VMware’s customers, addressing developer toil reduced the time taken to introduce a new feature significantly–from 400 hours to just 24 by doing a developer toil audit and addressing key factors contributing to this technical debt.

    So how can organizations overcome developer toil? One way to do this is through a developer toil audit. This is a systematic process for finding, valuing and prioritizing fixing waste in your software process. First, the process finds wasted time and process debt in how you build and release software. Second, the process then helps you justify delaying working on features in favor of eliminating and automating your software creation process. The result is speeding up your software release cycle. The more frequently you can change and release software, even with just small changes, the more opportunities you must learn what works and put those features in front of customers, employees, and other users.

    The process of conducting a Developer Toil audit includes:

    1. Asking the right questions: A great way to uncover developer toil is to ask about people’s struggles, frustrations, and even boredom in the form of a tailored question set. We advise using questions that are specific to your organization in addition to general questions like “how long does it take to perform a full build?” For example, highly regulated organizations should ask about tasks involving compliance. Once the survey is completed, you can do some quick analysis to locate and prioritize developer toil.

    2. Combine into usable metrics: You now have a single metric for each type of developer toil. And by combining all the questions you create a single metric to track overall developer toil. Extra points for creating dashboards with visualizations! As with all such aggregate metrics, these are more directional than exacting—their job is to point you to problems that should be solved.

    3. Link these metrics to business value: A simple ranking of developer toil is better than nothing. However, before deciding which developer toil to address, we recommend linking each type of developer toil to the business value created by fixing the toil. Put briefly, the value you get will be related to the time saved, and, thus, the ability to ship more features in the future.

    The less time developers spend on toil, the more time they can spend on tasks that directly benefit the business. Another way of looking at this is plain old productivity: Developers can now do more with the same amount of time.

    Another important outcome is increased staff morale. The less time developers spend on boring, repetitive work—toil—the happier they’ll be. Stronger employee hiring ability and retention are (or should be) a strategic imperative for any organization that depends on software. Morale also increases software quality: happier people make better software.

    Slow Down to Speed Up

    With the survey results in hand, you should have a pretty good idea of which developer toil to fix. The last step is to do the usual product management prioritizing to weight fixing these items with other tasks you could do. These are strategic decisions that product managers need to make. To fix toil, you need to stop shipping features to free up time. You need to slow down the business. At the start, before product managers have been empowered to make these kinds of decisions, higher-level management should be involved to calibrate how much slow down you’re willing to put up with for future agility. The calibration you’re doing is this: If I fix one item of toil and ship just one feature (instead of two) this release cycle, then in the next release cycle I can ship four features. Humans are not great at that kind of bird-in-the-hand versus birds-in-the-bush thinking, so you’ll need to figure out what works in your organization.

    Through our experience as consultants working with product teams in different industries, we’ve used Developer Toil Audits to focus and motivate product managers and developers to fix toil and speed up their release cycles and, thus, improve how their organizations build software. This directly improves the business by adding more capabilities and capacity to deliver more features, even in the short term. Each time you fix any technical debt, you gain more capacity and capabilities to create new features and improve your software. This is how you use a modern software culture to increase business agility. Or, put more simply: Less developer toil leads to better software, and better software leads to better business.

  • Full-Time Employment in the Age of Automation

    Full-Time Employment in the Age of Automation

    Back in 1930, the economist John Maynard Keynes wrote a short essay, “Economic Possibilities for our Grandchildren,” in which he predicted that in a hundred years the 15-hour work week will be commonplace. Keynes made this assertion based on two factors: first, the increase in capital due to extraordinary yields from the compound interest that was made possible by increased foreign (global) investment; second, the growth of technological achievement made necessary by the competitive forces of capitalism and made possible by the availability of excess capital.

    Keynes pointed out that these events are recent in terms of the entirety of human history, taking place over the last 500 years. Before that time, things were stagnant. Gold reserves remained static until the opening of the New World and technology, save for a few episodic breakthroughs, was pretty much unchanged. For example, the way cloth was made during the time of Joan of Arc, around 1400 AD, was not that different than the way it was made when the Roman emperor Hadrian had a wall built across northern England in 100 AD.

    But, the growing availability of money and technology changed everything. By 1920, the more affluent in the population wore factory-manufactured clothing bought in a store. Those of lesser means might still be making clothes at home, but the cloth from which the garment was made came from a factory.

    Mass-market capitalism powered by technological innovation increased human productivity on a scale unique in the human experience. Abundance on a global scale seemed a real possibility within a few generations. According to Keynes,

    “If capital increases, say, 2 percent per annum, the capital equipment of the world will have increased by a half in 20 years, and seven and a half times in a hundred years. Think of this in terms of material things—houses, transport, and the like.”

    Yet, today most people work 40 hours a week, if not more. Considering that Keynes was essentially a quant who lived and breathed data, how could he get it so wrong?

    My thinking is not so much that Keynes got it wrong, but that we’re having a hard time accepting that he might have gotten it right.

    Allow me to elaborate.

    The Facade of Productivity

    I have a theory: For the average contributor-employee in a medium- to large-size corporation (with 500 employees and more), of all the tasks he or she performs during a 40-hour week, only about half—20 hours’ worth—actually add value to the enterprise. The rest is organizational overhead. Thus, there is a good argument to be made that when you do the math, what we can call real full-time employment is closer to Keynes’s prediction of the 15-hour work week than not. The remaining time, which I call “organizational overhead,” is really just a facade of productivity.

    This theory occurred to me a while back, when I was sitting in a sprint planning meeting observing a project manager and tech-leads do task assignments. The first thing the project manager did was to determine how much time each member of the project team had available to work on the project’s tasks. The agreed-upon number was 20 hours a week.

    The 20-hours a week number struck me as strange. All members of the project team were completely dedicated to the project. They had no side work. The project was their one and only focus. What were they doing with the other 20 hours?

    I asked the project manager and he answered, “Well, they have to do things like answer emails, go to meetings and sometimes there’s some firefighting to be done.”

    Oh.

    The Amazing Ability to Absorb the Cost of Organizational Overhead

    I wish I could say that the project manager’s response was unique. But, in my experience, it’s not. I’ve been in more than one company in which meetings, email and firefighting occupy at least half of a full-time employee’s work week. And, I’ve got to tell you that, except in the rarest instance of mission-critical firefighting, most of these situations have marginal productive value.

    Granted, my theory is based on experiences that are anecdotal. The actual numbers might prove me wrong. Obviously, a thorough, quantitative study is needed. Still, whether it’s five, 10, 20 or even 35 hours a week, what’s amazing is not that employees spend a lot of time in activities that have questionable productive value, but rather, that businesses can actually operate profitably despite these ongoing time-sinks. Why? Because of automation. Machines and software are allowing people to do more work in less time—and it’s not only confined to IT.

    The Dirty Little Secret of Working on an Assembly Line

    Doubling up has always been the dirty little secret of automotive factory work. Ben Hamper revealed the details of technique in his 1986 book, “Rivethead: Tales from the Assembly Line.” Here’s how it works: Imagine that you and I work in a GM plant and do jobs at the same location on an assembly line—say, putting headlights and taillights in a car. Your job is to put in the headlights; my job is to put in the taillights. One day I notice that I can probably put the headlights and taillights in a car in the same amount of time it takes two of us to do the tasks separately. So, I propose a deal to you: I’ll do your job and my job for four hours a day in exchange for you doing the same for me. This way we can both work half time for full-time pay. We might have to pay the line foreman a small bribe to look the other way, but what the heck? The benefits are obvious, so we do it. Win-win, as the saying goes.

    How can we pull this off? Simple: as stated earlier, automation.

    Without the technology of the assembly line, we just couldn’t double up. The car needs to be brought to us for us to increase productivity to the point where one person can do the work of two. The automation of the assembly line effectively reduced our work week while maintaining our productivity, just as Keynes predicted.

    As you can see, the 15-hour work week is quite possible—and, in many cases, quite real. It’s just that the facade of productivity, which exists in larger companies, hides its existence. But, what about the smaller companies such as construction companies, law firms, small manufacturers, dental offices and software startups that employ fewer than 100 people? These types of companies cannot afford a lot of non-productive activity. How do these companies get to the 15-hour work week? Is it possible?

    My answer is yes, but the world that will need to exist to make the 15-hour work week possible will look dramatically different than the one we have today. What will that world look like? Allow me to illustrate using my neighborhood cafe, the C&M, as an example.

    The Real Implications of the 15-Hour Work Week

    My favorite neighborhood cafe is the C&M. It’s a hangout sort of place with good food, good coffee and Wi-Fi. The C&M is usually staffed by two employees during its business hours—7 a.m. to 5 p.m., seven days a week. Between them, they take orders as well as make the food and deliver it to the tables.

    Let’s do the math. Let’s figure that the actual working day at the C&M is 12 hours—10 hours of operation time and two hours of setup and cleanup. That comes out to 84 hours a week. Thus, excluding the owners’ time, the number of employee hours needed to run the C&M is 168. (two employees at 84 hours a week.) This comes out to around four people required to staff the business using the current 40-hour work week model, again excluding the owner’s time.

    Now, let’s say the business is quite profitable and the owner can afford to pay employees $20 an hour, plus health insurance. Adding in payroll tax and workman’s compensation (more than $5 an hour) plus the cost of health insurance ($400 a month, for illustration purposes), the weekly cost of each employee working 40 hours is $1,100, which translates into a total weekly labor cost for the C&M of $4,400.

    So far, so good.

    This time, let’s interpret the C&M labor situation in terms of the 15-hour work week. To cover the 168 hours per week that the C&M is operational, at a 15-hour work week per employee, the C&M needs to employee 11 people—actually, it’s 11.2 employees, but I rounded down. So, under Keynes prediction, if each employee is entitled to the established full-time compensation of $1,100 as calculated earlier, the weekly payroll for the C&M goes from $4,400 a week to $12,100—an almost three times increase, which is not an affordable number. Even though the number of employees has gone up, the odds are that the actual sales will remain the same. Instead of having to employ four people producing $14,000 a week in sales—$2,000 a day over seven days, again for illustration purposes—now the owner of the C&M will be employing 11 people to produce the same amount. Bankruptcy is imminent.

    Clearly, the C&M cannot tolerate 11 people working 15 hours a week for a full-time wage under current conditions. So much for the 15-hour work week. Well, not so fast. Let’s reimagine the scenario from a different angle: Suppose that the number of employees stays at four, but instead of working 40 hours a week, each employee works 15. What could we add to the mix to make this scenario possible? Give up? OK, I’ll tell you: robots.

    Imagine that instead of having two people on hand to set up the cafe, take orders, make the food, bring it over to tables, bus the table and then clean up at the end of the day, we had one person on hand to do what we’ll call human essential work. All the other work gets done by robots. Then, the typical interaction looks like this: Customers enter orders directly into an iPad, the robotic coffee maker gets the order and makes the double espresso, a robot in the kitchen makes the food, with the intermittent help of a human when necessary, and a robot delivers the food to the table. The one human on hand interacts with customers and picks up the slack work the robot can’t do. You can think of the scenario as the restaurant equivalent of a driverless Uber ride.

    Is such a world possible? Yes. In fact, it’s happening as you read this article. There’s already a chain of waiterless sushi restaurants in Japan. As the technology drops in price, more restaurants will make the transition.

    The 15-hour work week could indeed become a real possibility provided that two conditions exist: affordable robotic technology with a high degree of manual dexterity is available, and the employer is willing to pay the higher wages necessary to support the model.

    In the past, workers such as Ben Hamper used their ingenuity to take advantage of the reduction in labor that automation made possible. Sadly, such efforts were clandestine and deceitful. All that GM needed to do to realize a better return on labor was to speed up the assembly line. Yet, when you think about it, back then GM wasn’t doing that badly when Hamper was doubling up. 1984 was a record-setting year in sales, despite his shenanigans. Speeding up the line would undoubtedly increase GM’s bottom line. But, would it double Hamper’s take home? Probably not. (Author’s Note:  GM’s sales dropped 26 percent in 1986, but profits were still a healthy $1.06 billion.)

    So here are two questions to contemplate: As companies, large and small, adopt robotics to increase productivity, will they indeed share the benefits of the increased productivity with the average worker so he or she can enjoy a 15-hour work week? And then, should the 15-hour work week indeed become standard, what will the average person do with all this newfound leisure? As the saying goes, idle hands make fretful minds. According to Keynes:

    “Yet there is no country and no people, I think, who can look forward to the age of leisure and of abundance without a dread. For we have been trained too long to strive and not to enjoy. It is a fearful problem for the ordinary person, with no special talents, to occupy himself, especially if he no longer has roots in the soil or in custom or in the beloved conventions of a traditional society.”

    For those of you that think about such things, I will leave up to you to answer these questions. As for me, I can’t wait for the robots to take over so I can go back to my studies, full-time.

    — Bob Reselman

  • Automation: This Time, It’s Different

    Automation: This Time, It’s Different

    It took about 200,000 years for mankind to be able to figure out how to get an airplane to fly. The event took place Dec. 17, 1903, on a field in Kitty Hawk, N.C., when Wilbur Wright piloted the airplane he had made with his brother, Orville, into the air. The flight lasted for 12 seconds. The aircraft covered a distance of 120 feet. The next two flights went a distance of 175 and 200 feet, respectively. The last flight of the day covered a little more than 800 feet. The plane stayed in the air for 59 seconds, at an altitude never greater than 10 feet, before striking the ground and incurring minor damage.

    Although the flights were a significant technological breakthrough, they had absolutely no commercial value. Other forms of transportation could go further and travel for longer periods.

    Almost two years later, having learned from their mistakes, the Wright Brothers were able to keep an airplane flying for 38 minutes, covering a distance of 25 miles at a speed of 40 mph. The aircraft was 30 percent faster than a horse at full gallop, but still slower than a passenger train running at an average speed of 60 mph. Commercial viability was in sight.

    In June of 1919, 16 years after the Wright’s first flight at Kitty Hawk, Capt. John Alcock and Lt. Arthur Whitten Brown of the United Kingdom flew 1,690 miles from Newfoundland to Clifden, Ireland, in a little more than 16 hours. Fifty years later, it took 73 hours and and 5 minutes for the crew of Apollo 11 to fly the 238,857 miles from Cape Canaveral, Fla., to the moon.

    Think about it. It took mankind 200,00 years of technological progress to get a plane in the air, but only 63 years after that to travel to the moon. It’s pretty miraculous, in a way. Technology does not just move forward. It careens ahead exponentially.

     

    Figure 1: Mankind was able to travel from 12 feet to 238,857 miles by air in 63 years

    What was the stuff of science fiction in my childhood—think video conferencing—is commonplace today. And it’s cheaper than we ever imagined possible. The future possibilities of technology are limitless. Anything can come to be, given enough time.

    But, when it comes to considering artificial intelligence and machine autonomy, there are still a lot of people out there who think that the notion of machines taking over most of the jobs that humans do is far-fetched, if not daffy. According to conventional wisdom, history’s pattern is that for every job eliminated by technology, more are produced. And should machines displace humans from the workforce entirely, that day is a long way off.

    That’s what my grandmother thought. She was born in 1900. If you had told her when she was a teenage girl that the flying contraption she was reading about in the newspapers would have the result of putting a man on the moon in her lifetime, she would think you crazy, and rightly so. She had no historical precedent to think otherwise. Remember, in her day horses still pulled plows. Everything except birds and hot air balloons were land-bound. Yet, despite her disbelief, there came a time when she sat in front of a television to watch Neil Armstrong descend from the Apollo 11 Landing Module to put the first human footprint on the moon. She thought it would never happen. And yet, it did.

    Yes, the historical pattern has been that technology eliminates jobs and creates new ones for humans to do. When the automobile replaced the horse, the out-of-work blacksmiths went to work in factories that filled the ever-expanding industrial landscape. And, with each wave of technological innovation, there were the harbingers of doom predicting the demise of human labor. Each generation of naysayers uttered, “This time it’s different.” Conventional wisdom points out that it never is.

    That was then and this is now. This is the time of the autonomous machine. This time it is different.

    The Rise of the Autonomous Machine

    Machine autonomy is the ability for a device to make decisions and conduct itself independent from ongoing instruction, very much the way a human does. The most telling example is an automated stock trading program used by financial investors. The program is at work continually buying and selling stock with the goal of turning a profit. Certain safeguards are built in to prevent disaster. But for the most part, the application is left on its own to achieve its goal: to make money.

    Until very recently, machine autonomy was confined to software applications such as the stock trading example described above. However, modern robotics makes it so that not only can a machine “think” autonomously, it now also can move autonomously. The most apparent example is the self-driving car.

    Integrating physical and cognitive autonomy into machine behavior changes the game. In prior days, a taxi required a human driver to get the passenger’s destination, find the best route, drive the vehicle and collect payment for the ride. All a passenger needed to do was jump in the back seat and tell the driver where to go. The human driver figured out the rest. As technology improves, the passenger still will jump into the back seat, but in an autonomous vehicle that gets routing information and traffic conditions from a wireless connection to the internet.

    The ramifications are profound.

    For example, let’s imagine we have a diseased tree in our front yard that needs to be removed. Today, we call a landscaping company. The tree removal crew shows up, we point to the diseased tree and ask the foreman to remove it. That’s the only instruction we need to give. The landscaping crew has the ability to act autonomously to do whatever is necessary to remove the tree safely.

    Now, imagine the crew brings along a robot to help with the task. At this point, it’s safe to say that current robotic technology requires a lot of human guidance to remove the tree; the robot is more an aid than an independent worker. The robot might have no other ability than to pick up tree cuttings and take them to a truck to be hauled away. Or, the robot might be able to handle a tree-cutting tool to assist with demolition. Still, the independence of the robot it limited. Either its activities are limited to repeatable tasks limited in scope, or it can act in an ad hoc manner by taking one instruction at a time from a human. The robot is dependent on human instruction to get work done.

    However, let’s imagine that robot technology is on the trajectory of exponential innovation that has been the historic norm. Remember, in the scheme of 200,000 years of homo sapien activity, 63 years from a field in Kitty Hawk to the moon is but a blip in the historical timeline. Autonomous lumberjack robots are entirely possible.

    You call up a landscaping company. A crew of three lumberjack robots show up in an autonomously driven vehicle. These robots know everything there is to know about tree removal and they can do all the physical activities required. The “lead” robot asks you which tree needs removing. You point to the tree. The crew figures out the rest on its own, right down to charging your credit card for work done. Plausible? If you answer no, pretend you are my grandmother and you’ve just been asked whether you think it’s plausible that a man will walk on the moon in your lifetime.

    So the question remains, What happened to the human crew? Did they become data scientists? Don’t answer this question yet. We’ll get to it in moment. First, we need to talk about the next milestone on the road to complete machine autonomy: artificial general intelligence (AGI).

    Narrow AI and AGI

    In the tree-removal scenario described above, all robotic activity—autonomous or otherwise—was confined to a single task: removing a tree. The scope of work is limited. Working within a limited scope of behavior is called narrow AI (artificial intelligence).

    Examples of narrow AI are cutting down a tree, trading a stock, finding a date on Friday night, composing a song, making a pizza, etc. We’re going to see a lot of narrow AI emerge in the next few years. Venture capitalists such as Khosla Ventures, Greylock Partners and Goldman Sachs are already putting money into advancing narrow AI technologies. However, narrow AI is but a stepping stone to get across the pond to the final destination: general AI.

    Think of of it this way: If Kitty Hawk is the starting point of AI, the first transatlantic flight is narrow AI. AGI is landing on the moon.

    What will general AI look like? Let’s go back to the landscaping example.

    We’re back in your front yard sitting in some lawn chairs having ice tea on a hot summer’s night. A driverless vehicle shows up. Two robots emerge. One approaches you and asks your permission to deposit $500 in your PayPal account in exchange for cutting down a diseased tree in your front yard. “OK,” you say, “but how do you know the tree is diseased and why are you giving me $500?”

    While the second robot gets to work, the first robot responds, “The county keeps drones in the air 24/7 analyzing the landscape. A drone did a spectral analysis of your property and noticed the diseased tree. In addition to reporting back the location of the tree, the drone also included a full biological profile. If you don’t remove the tree, the disease will spread. That’s the bad news. The good news is that it’s a cherry tree. And it seems that only 10 percent of the tree is diseased. The rest is perfectly good wood. The price of cherry wood is quite high on the commodity markets right now. Also, there’s a legal statute that requires the county to reimburse property owners when a private landscape is altered for general good. So, the county sold a futures contract on the wood it can reclaim from your tree. The $500 we want to put in your PayPal account reflects your share of the revenue received from the futures contract plus the amount of the reimbursement entitlement required by law.”

    This is what AGI looks like. AGI is the ability for a machine to think in broad terms, using a multitude of knowledge domains. Combining AGI with the advances in physical robotic capabilities expected on the horizon produces a result in which machine autonomy is not only possible, but will exceed human capability.

    If you think AGI is a fantastic notion, go talk to Yves Bergquist, CEO over at Novamente. The company is actively working to improve AGI for general commercial use. One application Novamente is developing uses AGI to determine, if not create, movie scripts with a high probability for profitability. To quote Bergquist: “A story is an algorithm.”

    Making a modern-day Hollywood blockbuster is a billion-dollar undertaking. Given the choice, studios would rather not roll the dice. However, when it comes to scripts, predicting a winner is difficult. Of all the human endeavors that are tough to emulate with artificial intelligence, creative storytelling ranks high. Writing a script requires working in a multitude of knowledge domains: story, character, plotlines, scene design and historical continuity, to name a few. Narrow AI is not suited to the task. You need AGI. There’s too much to consider. In a way, it’s surprising to think of Hollywood is the perfect incubator for developing real-world AGI. But it makes sense. AGI might produce a few flops. But, it’s a whole lot safer to lose at the box office than to lose on the battlefield.

    Given companies such as Novamente, the entertainment industry might well become the incubator in which AGI is perfected. Then, if the trend in rate of technological innovation continues, eventually AGI will become viable everywhere. Then what? What happens when a machine can do everything a human does only faster and better?

    A Turkey’s Life

    Understanding the long-term impacts of a given technology has not been one of the highlights of human endeavor. As cars became commonplace, few people considered the possibility that too many would create too much carbon monoxide and thus threaten the health of the earth’s population. And nobody really thought about what was going to happen to the displaced blacksmith who was no longer needed to make shoes for a diminishing number of horses. Events just ran their course with little or no forethought.

    But, it’s getting better. Some people do think ahead. Military planners consider the improbable as do financial analysts. It’s called risk analysis. These are the people that get paid to think outside the box, so to speak. They understand the even small possibilities might happen. Whether they are heeded or not is another story.

    Today, machine autonomy is real. The possibility exists that in our lifetime automated AI will indeed be able to do everything a human does. And, the machine will do it better at less expense. There will be no new jobs for humans to do as old ones are destroyed. A machine will be able to do the new job faster and cheaper—even those jobs that require a significant amount of AGI. Then, what will happen to the humans?

    We have to think about it today!

    Sadly, few are. We are not hearing any articulation in general industry or in government, at any level, about ideas to address the the impact of automation on human employment as machine autonomy and AGI become more prevalent in the economy. It seems as though most people are relying on the old logic of the conventional wisdom.

    Conventional wisdom is easy to accept. The U.S. economy is reported to be at practically full employment levels. Employers are complaining about how difficult it is to find qualified workers. The stock market is achieving historic heights. Given history and current events, of course it’s reasonable to say there always will be jobs for humans to do.

    This assertion works until the day fully autonomous machines appear on the landscape. Then, conventional wisdom will be that which is uttered by turkeys on the day before Thanksgiving.

    What do I mean? Allow me to elaborate using a previously written analogy.

    Imagine you are a turkey on a farm. Every day the farmer comes by to feed you. This goes on for one week, two weeks, 10 weeks. Given your history, you are completely justified to predict that your future will be one of satisfying meals. It’s always been this way; how could it be otherwise? You go day in and day out predicting that the next day will be full of food and sunshine. You are correct … right up until the day before Thanksgiving.

    In other words, there are things that happen independent of historical precedent. The trick is to imagine what such events might be.

    Everybody agrees that AI is here and that machine autonomy is growing. The conventional wisdom is that, based on historical observation, there have always been jobs as technology grows. Many think the full replacement of human labor by autonomous machines is a possibility, but one that is coming in the far, distant future. When Wilbur Wright took off in 1903, my grandmother’s distant future as was 1969. Those 63 years passed in no time. She lived to see a man land on the moon. Those of us alive today are seeing the beginnings of true machine autonomy appearing on the technology landscape. A world of full machine autonomy is more than probable in the lifetimes of our grandchildren. It will happen. What will be the impact? What will they do if their labor is no longer required?

    Back in 1903, as automobiles began to chug along the planet’s roads, we missed predicting the possibility of air pollution and global warming. Today, will we allow conventional wisdom to prevail and miss preparing for the impact that full machine autonomy will have on human employment? Or will we plan ahead? Hopefully, we’ve learned from our mistakes.

    I’ll leave it to you to decide.

    Author’s Note: The analogy of prediction in terms of historical precedence is taken from the book, “The Black Swan,” by Nassim Nicholas Taleb

    — Bob Reselman

  • Four Inspiration-Killing Concepts That Need Redefining

    Four Inspiration-Killing Concepts That Need Redefining

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

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

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

    New definitions for the Internet Era

    Task → Contribution

    Approval → Collaboration

    Workplace → Remote

    Workers → Culture

    Task → Contribution

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

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

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

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

    Approval → Review

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

    Workplace → Remote

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

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

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

    Workforce → Culture

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

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

    Conclusion

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

    About the Author / Devrim Yasar

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