devopsy.kinsta.cloud

Tag: Productivity

  • Debunking Misconceptions About Engineering Management in 2020

    Debunking Misconceptions About Engineering Management in 2020

    2020 will be a year we all remember for so many reasons. It has been a year full of uncertainty and confusion, and also one in which misconceptions abound. In the world of software engineering, we feel this acutely as all eyes are on the engineering team to continue building innovative new products and solutions—maintaining the lifeline of the business—even as we grapple with new realities of universal remote work, new constraints on resources and countless distractions.

    Given all of that, it should come as no surprise that go-to-market and other business leadership has grown increasingly concerned with the performance and success of the engineering teams on which they depend. Some of their worries are legitimate, but many are merely misconceptions about the state of software engineering and the efficacy of engineering management. To help foster alignment, the Jellyfish Data Science team investigated by looking at engineering management and team data across dozens of software development teams representing thousands of engineers. Below, three important misconceptions about engineering management in 2020 are debunked.

    Misconception 1: Software engineering teams are working less or being less productive amid COVID-19, universal remote work and lack of management oversight

    The idea that teams are being less productive is not altogether unfounded. Nor is it surprising given the fact that it’s much more difficult to see what’s being built by the engineering team and how the team is being managed directly. It’s true that among the many teams sampled, productivity decreased across the board about a month or two after the shift to universal remote work (after a spike in productivity initially). However, as things have settled into a new normal, productivity metrics on engineering teams have rebounded and in many cases even increased.

    The reality is that engineers are working almost the exact same amount of time as they had been before the pandemic. In fact, the average number of coding days per week has increased 2% (it stands at about 2.2 days). The difference is that engineers are adjusting their working hours to accommodate family schedules. Peak coding hours have shifted four hours earlier, and software engineers are working longer and less regular hours during COVID-19.

    Across the board, engineering metrics suggest productivity is up relative to the same period last year. The number of commits has increased, merged pull requests are up more than 10% and the number of issues resolved has increased a whopping 8.7%. The exception here is issue cycle time, which has increased more than 21%. Engineers may be taking on meatier projects, and are working equally, if not more diligently, to ship them.

    Misconception 2: Communication on engineering teams is breaking down due to remote work during COVID-19

    Again, this worry is not unfounded, especially for older companies where co-located work was important for effective communication and for larger companies where communication is crucial to maintain business continuity across divisions and departments. But among younger, and especially software companies, the move to remote work was not so painful and communication did not break down nearly as much as might have been anticipated given the already widespread adoption of videoconferencing tools such as Zoom or Google Hangouts and messaging platforms such as Slack.

    The reality is it’s difficult to say what has happened with communication. Certainly, informal office banter and hallway catch-ups have taken a nosedive. But communication about engineering work—communication that is measurable—has actually increased, possibly enough to fill those gaps. Review and comments on pull requests, for example, have increased by 5% and 4% respectively, and Slack’s CEO reports the number of Slack messages per user per day has increased 20% (which echoes our findings that Slack messages in engineering work channels have increased). The conclusion is that while informal communication may be down, measurable communication—especially around engineering work—has actually increased.

    Misconception 3: Engineering management has lost visibility into the work their teams are doing as their teams have gone remote and they can no longer walk the proverbial “floor”

    Visibility into the work of engineering teams has not broadly decreased in recent months, but that doesn’t mean visibility is not a problem. Visibility remains a top challenge among engineering leadership.

    The reality is engineering management has had poor visibility into their teams’ work long before they went remote. According to the “2020 Engineering Management and Alignment report,” this poor visibility has led to a misunderstanding and misrepresentation at the highest levels of what types of work need to get done and how many resources they’ll require. The report found, for example, that engineering leaders polled overestimated the amount of resources available for road map and new feature work by 62%! Without a more complete understanding of what work is being done, the study asked, how can engineering leaders take corrective actions and ensure the right projects are being prioritized?

    But not all is lost in this regard. The study also found that visibility dramatically increases, by 60% on average, on engineering teams that have implemented engineering management platforms. Those teams report 16% less time spent on customer support work and 35% more time available to work on “road map work or strategic customer development—the work that moves the business forward.”

    Ensuring alignment with the business is critically important for technical leaders during times of uncertainty. If you can get ahead of these misconceptions, you will better enable your team for success now and in the future. Data-driven engineering leaders already know this to be true when times are good and resources are easier to come by. If you’re not already, strike the misconceptions your business leaders may have by sharing the realities on your team.

  • CTOs Should Embrace, Stick to a No-Meeting Day

    CTOs Should Embrace, Stick to a No-Meeting Day

    You know the feeling: You open your calendar in the morning to find a completely booked day, back-to-back meetings and not even 15 minutes of time to complete any of the items on your to-do list. In fact, your day tomorrow and the day after look just as booked.

    An HBR study conducted last year found that face-to-face requests are 34 times more successful than email when trying to effectively communicate or persuade someone. And, we all know that spending time with colleagues is critical to cultivating relationships and building company culture. But what if engineering team leaders took away just one day of these interactions to create more headspace for their teams?

    For the last seven years, I’ve opened space in my engineers’ schedules by mandating that one day per week must have zero meetings. While putting this rule into place successfully has been challenging, the benefits I’ve discovered consistently reinforce my decision to keep it alive and spread the word to other CTOs and engineering leaders.

    Here’s why you should consider implementing this rule and how your team can fully reap its benefits.

    Humans (Especially Engineers) Struggle To Re-Concentrate

    As technology advances and new tools provide us ways to reach each other faster throughout the day—and at all hours—the wealth of options to connect can cause communication overload. Add meeting after meeting into the mix, and focusing on one project without interruptions becomes nearly impossible.

    The phenomenon of feeling like you’re doing many tasks at once, but never truly finishing any of them, actually has a scientific explanation behind it: When you focus, the left and right side of the prefrontal cortex work in tandem. When you multitask, you switch between the two sides of your prefrontal cortex. Although this switch takes just a fraction of a second, it can actually take up to 40% longer to complete the same tasks than if you focused on each separately.

    While this multitasking phenomenon holds true for everyone, engineers especially feel the pain of multitasking, as most software development requires serious and uninterrupted concentration. As engineers figure out how parts of the system interact with other parts, distractions during this complex work might mean starting from scratch in the midst of a project.

    Removing meetings from the equation one day of the week provides them a window to take advantage of completely uninterrupted time. I’ve also noticed that my team now tends to organize projects of the week around this day off from meetings, reserving the no-meeting day to execute on critical tasks that require completely uninterrupted work, which contributes to increased productivity during that day. They slate in more complex work and time-consuming projects for this day and tackle smaller projects throughout the rest of the week.

    No-Meeting Days Encourage a State of Flow and Deep Work

    When people do what they love and feel passionate about their work (and don’t experience distractions while doing it), they often enter into what researchers have called a state of flow. In fact, psychologist Mihaly Csikszentmihalyi covered this topic in a recent TED talk, sharing his opinion that money can’t make us completely happy, but those who discover happiness have one thing in common: They find pleasure and lasting satisfaction in activities that encourage a state of flow. Giving your engineers just one day per week to reach this state could lead to increased and longer-term satisfaction with their overall work.

    Not only could a day without meetings enable your engineers to reach a state of flow for at least one day per week, it also could lead to enhanced skill sets. Cal Newport, a professor at Georgetown University, coined the phrase “deep work,” a state of activity performed in a distraction-free concentration zone that pushes cognitive capabilities to a new limit. By creating this deep work zone, you invite your engineers to unlock creative thinking and discover the solution to something new, simply through access to a deeper level of concentration.

    Commit to It and Stay Honest About It (I’m Talking to You, Managers!)

    The no-meeting day philosophy is not necessarily new. A number of companies talk about it in different ways, but when you look under the hood, you might find that not all managers enforce it well. I’ve discovered this lack of rule enforcement leads to a lack of employee respect for the rule.

    Therefore, it’s up to managers to weave it into their team’s culture. If you lead by example, you’ll set the tone and encourage other team members to follow.

    If you see meetings happening on a designated no-meeting day, encourage team members to move them. Re-state the benefits at recurring staff meetings (as needed) and ensure all new employees become well-versed in the benefits and reasons why the team participates in such a day. Most importantly, if you find a certain day doesn’t work well for the majority of your team, change it. Stay flexible and open to trying new ways to make this rule fit into your current team structure and schedule. The more you involve others in the creation of the rule, the more likely they’ll be to stick with it.

    Yes, every engineering leader wants his or her team to be as productive as possible. But often in striving to reach this overarching goal of peak productivity, managers miss the point: Scheduling less and taking a step back from day-to-day socialization and busyness is actually more—at least for one day a week.

    — Hector Aguilar

  • How to Become a Great Engineering Manager

    How to Become a Great Engineering Manager

    I wrote recently about the attributes of a 10x software engineer and a 20x one. Consequently, I received a few comments suggesting I create a similar list for engineering managers. I checked online and found a few articles, but none conveyed a full list in my mind. If you consider that software development efficiency has become the No. 1 priority for executives, ranking higher than access to engineering talent or capital, then I guess that’s a topic worth discussing! Engineering managers just might have the biggest impact on the productivity of their engineering teams.

    I’ll first go over the attributes for a good engineering manager, and then list what makes a great one.

    The 10 Attributes of a Good Engineering Manager

    I tried to prioritize this list, from essential to bonus. Feel free to give me your opinion on this in the comments.

    1. Be trusting

    If you refer to what destroys developer productivity most, trust is at the heart of it. Managers need to trust their team and give them some space. Micromanaging means undermining the team’s skills and ability to get things done, and therefore their motivation and self-confidence (which, by the way, they need to address difficult problems). Trust between the managers and their teams should be the foundation of their relationship. And it’s the manager’s role and job to create it, not the other way around. So first, trust your team.

    1. Emotional intelligence and ability to establish trust

    This is linked to the first point. You need mutual trust within a team for it to work well. And again, it’s the manager’s job to ensure that their team trusts them. How does the manager do this? By showing emotional intelligence.

    Engineering managers must be sure to make themselves available for questions, even if they’d rather not be interrupted. This can run counter to high efficiency, but it’s important that managers spend the time to form personal connections, so honest and open conversations happen naturally within the team and with the manager.

    Another important point is to listen to anyone and everyone. When the team gets together for a meeting to sort out a project they plan to do, everyone in the room needs to be heard and considered. The manager needs to respect any experience or insight their team can bring to the table. Any member of the team may be the most knowledgeable on a particular subject.

    Now, this is not Disneyland for sure: Managers might need to be tough and unwavering sometimes. But when that’s the case, it’s important to be transparent about the reasons to keep the hard-earned trust intact.

    1. Ability to shield the team from interruptions

    Interruptions and meetings (consider them planned interruptions) are greatly loathed by developers, and for good reason. They literally destroy their productivity. Developers love projects that move fast; they’re invigorating! Managers would do them a great service by removing distractions, ensuring that they have large chunks of uninterrupted “maker time.”

    A classic example is a really long email exchange on some technical topic with no resolution. The manager could simply put everyone on the thread in one room together for 10 minutes to get the issue resolved promptly.

    1. Ability to manage the team’s motivation

    The team’s motivation is directly linked to their output and the success of their releases. There are many ways to keep the motivation high. Here are just a few:

    • Help the team see their work through the lens of their impact on the company.
    • Don’t worry too much about failure. Things will always fail: builds, deploys, schedules missed, etc. If things fail, take responsibility and focus on the learning. The point is not to have to fix the same issue twice. This will give your team a mindset toward action and growth.
    • Celebrate every achievement, whatever its size. And credit the participants profusely.
    • Be transparent. Default to overcommunicating. While some leaders believe they need to shield their teams from things going on at the executive level to prevent distraction, there’s a difference between productive shielding and unintentionally denying engineers important company context. Managers want their teams to feel included and invested in the direction of the company.
    1. Strong work ethic and cohesion with company culture

    Work ethic means being exemplary in all the ways you expect your team to behave. Lead by example. Managers must embrace the company culture, or it will create confusion sending team members mixed signals of whether or not they should embrace the company’s culture.

    This also means shielding your team from people who don’t act accordingly. For instance, hiring someone with a huge list of qualifications and experience can still be a disaster if they have a different set of values than those held by the company. Or, unfortunately, having to let people go who are not team players or aligned with the company and team culture, whatever their skill level.

    Good managers keep in mind that the team’s productivity as a group is important, not individual performance.

    1. Advocate for change to seek positive evolution in a constant manner

    Good managers install a mindset of positive evolution within the team.  They adopt a state of mind that continuously seeks to improve a certain situation. When a process is slow or cumbersome, they try to turn that around and make it better. One way todo this is using OODA loops: Observe, Orient, Decide, Act.

    1. Ability to work with departments outside of engineering

    The language used by non-technical stakeholders might be very different than that of the development team. However, good managers don’t want to be the Single point of contact, as they would introduce a potential liability into the project—a strong dependency on them. They tend to include their team in relevant discussions, but make sure they protect the team members from continuous interruptions. Good managers try to be the First point of contact, which is a big difference from being the single point of contact.

    1. Mentoring abilities

    Effective managers are measured by the effectiveness of their software teams. Anything that they can do to make each person on their team better makes their overall teams exponentially better. And most of the mentoring is actually about matchmaking team members with high-impact projects that align with their interests, the value they want to create and how they want to grow. That’s when motivation becomes organic.

    There are already so many articles on one-on-one meetings, I won’t spend much time on them. But mentoring also happens every day at every occasion. For instance, if a manager happens to review code or explain certain conventions, they make sure to clearly explain the reasoning why the team is doing something in a particular manner. Good managers are great teachers.

    1. Technical literacy and problem-solving skills

    On the one hand, technically competent managers will have a superior handle on the work that they are managing, and will therefore be better able to make recommendations and evaluate necessary trade-offs. On the other hand, technically talented managers are often better able to garner respect from their teams. Non-technical managers may struggle to manage high-performing individual contributors, who tend to have a tough time taking orders from managers who don’t fully understand their craft.

    But, if you don’t have any engineering background, it doesn’t mean you cannot be a good—or even a great—manager. I would advise you to learn about the technical dimension of the project (with humility) through every interaction you have with your team, and possibly in your off hours. Having enough technical experience to understand the projects and the decisions, mixed with the ability to trust others with technical depth, works really well.

    1. Ability to make hard decisions and manage conflicts

    Good engineering managers will make the courageous decision, even if it isn’t popular. They don’t make the wrong decision just because it is socially right and their team suggests it. Good engineering managers focus on the road and the values they believe in, and not only on the immediate issues they are facing. They don’t just choose best industry practices because they will attract the “right” talent. For instance, managers will avoid  automatically using the latest technologies: they will weigh the pros and cons and make the best choices based on the resources and requirements of their team and company.

    How Can You Become a Great Engineering Manager?

    1. Embody the vision

    Great managers have a natural ability to visualize the future of the company and motivate others to work toward those lofty yet realistic goals. They communicate the company vision at every opportunity by illustrating it contextually in discussions. They challenge the decisions made with, “What if we had 20x more users? Would that be sustainable?” or, “Will this technology decision still be valid in 24 or 36 months?”

    1. Support your team in the short and long term

    At the end of the day, as a technical manager, your job is mostly about humans. Great managers think about supporting their team in two ways: day to day and year to year.

    Great managers help their people devise a long-term plan to be happy and productive at their company. Sometimes, engineers don’t know how to articulate how they want to evolve. This is not an issue, as great managers have built strong relationships and trust with their team members to help them uncover this part and build a plan for:

    • the skills to improve.
    • the technical/non-technical experiences they want to have.
    • how they want to increase the scope of their impact at the company.

    And, naturally, the great managers will help their people to achieve their ambitions (within or maybe even outside the company).

    1. Challenge the team to grow faster

    Great managers try to super-charge learning within their team. They know to push their people out of their comfort zone and challenge them to accomplish things they didn’t even know they could do. But in doing so, they set up strong guardrails to help their team course-correct along the way.

    For instance, one way for engineers to increase their impact is to architect and own increasingly complex technical problems requiring novel solutions. Great managers will throw their people  into the deep end of the pool, with the right mentorship and guardrails, and have them start solving increasingly complex problems immediately. They will also try to maintain a balance between more experienced and less experienced engineers, having them work together and regularly share knowledge. They want to build in opportunities to make sure these conversations are truly bi-directional.

    Another instance is estimates. Do you know this law?

    Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

    Estimating is hard. When you do it more often, you will get better at it … but you will still get it wrong from time to time. Challenging your team to make estimates is a way to get them used to getting out of their comfort zone.

    1. Embrace the differences

    Diversity is invaluable. All people are different and live different lives. This is incredibly valuable, because your users will also be different. Surround yourself with passionate people of different backgrounds. By background, I don’t only mean gender or race, but also education and past experiences. The more people in the team think differently, the more approaches your team will consider when addressing a problem, which results in better decisions. A great manager understands this and will strive to get input on the same problems from a variety of people with different backgrounds.

    1. Level up the product and engineering partnership

    Great engineering managers know to extract the essence from the user story; they focus first on the core capabilities, providing valuable input and challenging the product as early as possible. They never blame the product on complex features, or make the excuse that some things were not explained in the first place or changed 10 times. They never complain about the lack of visibility on the ideation process. They build such visibility themselves. They challenge the product team with several alternatives for the same idea. They know to explain pros and cons without deep diving into tech level and buzzwords. They help the product team make better decisions and educate them about the technical layers of features.

    1. Know themselves and educate others about themselves

    Great engineering managers have made the effort to understand how they themselves work,  behave,  think and make decisions. Being transparent with their team about these things, builds more trustful and productive relationships. They work on visibility and commitment for their own goals and tasks in front of their team members.

    1. Push their team for ownership as much as possible

    Great engineering managers tend to give more ownership of user stories to their developers. Transferring ownership to developers gives them more motivation to do a great job. Great engineering managers don’t try to own all of the responsibilities or give them all to a few select  individuals (tech leads).

    Great managers know when to give input, when to make decisions, and when to step back and allow the team to take more ownership. They promote a culture of accountability, where they trust each team member to do his or her job and never  insist on full visibility into what their team is doing.

    1. Understand the system’s bigger limitations

    Great managers understand the inefficiencies within the processes and organizations, as well as their own limitations. They share their thoughts to upper management to help the organization grow (and not only their team).

    This concludes my list of the attributes of good to great engineering managers. If you think of any I’ve overlooked or have any ideas or suggestions to add, I would love to hear your thoughts! Please leave your comments and opinions below!

    — John Lafleur

  • Preventing the DevOps Dilemma

    Preventing the DevOps Dilemma

    Clayton Christensen, in his bestseller, “The Innovator’s Dilemma,” first outlines how innovation occurs, and then why large incumbents often fail to recognize, leverage and invest in new innovations in their industries. What is interesting about his view is that failure isn’t directly correlated to simply not recognizing, or even adopting, new innovations, but rather that it occurs because these companies attempt to apply or force the innovation into existing architectures, business processes and customer bases.

    Definition of DevOps

    Perform a Google search for “DevOps” and you’ll be presented with thousands of results, each with their own nuanced definition of the term. More often than not, the discussion is around tactical approaches to “implementing or adopting DevOps,” as if it were concrete entity or a role/job title. The core goal of DevOps is really about disrupting a culture to be adaptive to the changing needs of the enterprise, and provide a strategic framework to scale and gain efficiencies.

    ‘DevOps Dilemma’

    The “DevOps Dilemma” often occurs when the cultural adoption isn’t driven by taking a fresh, holistic view of solutions and architectures, but instead automation and measurement approaches are layered on top of the current development and operations run-books. Instead of embracing true agility, this is a “waterfall-esque” approach that neither captures the true essence of the value of DevOps nor does it typically improve operational excellence and efficiency. The cultural shift toward DevOps needs to take a continuous approach where everyone is trying to improve and evolve the business by leveraging the core tenets of DevOps—collaboration, automation, measurement and sharing.

    Where To Start?

    One strategy for preventing DevOps dilemma and undertaking a successful cultural transformation to DevOps would be to do so in conjunction with a greenfield project. That assures that you don’t “bolt it onto” existing processes and methodologies. It also sends a clear message of the importance of combining effort with resources and moving dedicated focus away from the current status quo. This often also can result in creating a flexible playbook that you can use to go back and improve the areas that compose your core business. Your engineers will learn valuable new skills and rapidly evolve, and the company will be much better positioned for attracting new and developing existing talent.

    About the Author / Mike D. Kail

    Mike D. Kail is chief innovation officer at Cybric. Prior to CYBRIC, Mike was Yahoo’s chief information officer and senior vice president of Infrastructure, where he led the IT and global data center functions for the company. Prior to joining Yahoo, Mike served as vice president of IT operations at Netflix, where he was responsible for employee technology and various cloud engineering components. He has been widely recognized for his insightful industry commentary on social media Twitter, and was recently named by the Huffington Post as one of the “Top 100 Most Social CIOs on Twitter.” Connect with him on LinkedIn and Twitter.

  • Meet the Citizen Developer

    Meet the Citizen Developer

    Much has been written on the rise of citizen developers, but little about who they are and why they choose to do what they do

    The enterprise is always thirsty for new applications. More than ever, this thirst seems unquenchable. Consider a recent market analysis from Global Market Insights, which expects the enterprise application market to grow at a rate of 7.6 percent annually from 2016 through 2024. That’s a clip swift enough to more than double its 2015 $150 billion market size by 2024.

    The demand for enterprise applications—and especially for mobile apps—is so high that most enterprise IT departments can’t meet it and often have backlogs of months to more than a year.

    We’ve written extensively about how the citizen developer is now stepping up to fill this gap. Citizen developers are helping enterprises to not only close the application demand gap but also innovate more rapidly. However, we haven’t seen much regarding the nature of these citizen developers—who they are and what makes them decide to tackle app development independent of IT.

    Recently, Apple subsidiary FileMaker Inc. surveyed hundreds of citizen developers within organizations ranging from five employees to more than 1,000 employees. Those surveyed either created or were involved in the creation of custom apps, didn’t classify themselves as IT professionals and were not full-time custom app developers.

    As we’ve written before, we consider the rise of the citizen developer to be an extension of the consumerization of the IT trend, which began with endpoint devices, evolved to include many cloud services and now encompasses citizen development. Just as  users began choosing which tablets and smartphones they would use for work, many staff members now are choosing, independently, to shun old-fashioned spreadsheets and endpoint databases for higher-level, cloud-based platforms that make it possible to build applications with little to no coding.

    Why do citizen developers choose to develop work apps on their own? According to the FileMaker survey, it’s because a sizable majority—83 percent—wanted to create a better way to work, while 63 percent wanted to be more productive and 42 percent wanted to help others in their organization. Only 12 percent of citizen developers had been asked by their boss to start building apps. Currently, the citizen developer movement is self-directed and self-motivated—41 percent started developing business apps to improve their skill sets.

    So who are these citizen developers? Not surprisingly, the majority are savvy computer users with no formal background in computer science or software engineering, and 34 percent play a management or supervisory role in their organization. When respondents were asked what three words colleagues would choose to describe them, about half chose “problem solver.” Other descriptors such as “creative,” “hard-working,” “organized” and “leader” also ranked high.

    The citizen developers also reported that citizen development had a significantly positive impact on their career. Nearly half, at 48 percent, cited increased satisfaction at work, while 42 percent found that the practice increased their confidence, 29 percent received more recognition within the organization and had more time to work on efforts they enjoyed, and 26 percent felt increased motivation at work.

    Finally, because citizen developers can spot a business need and fill it quickly with an app, they are helping to fill the application demand gap in many enterprises. Eighty-two percent of citizen developers said they witnessed a reduction in inefficient tasks, 71 percent reported an increase in team productivity, and 60 percent said their apps helped to reduce data entry.

    They’re building these apps quickly, too—often building their first app in less than three months, according to 71 percent of respondents. Only 12 percent reported it taking three to six months to do so. That type of accelerated app delivery—when the idea is conceived, designed, and delivered by the users who needs the functionality—will not only help to clear app backlogs but also could become a cauldron of internal innovation.

    — George V. Hulme

  • The Impact of Automation: Considering 3 Facts

    The Impact of Automation: Considering 3 Facts

    I’ve been interested in the ramification of automation on human employment for a while now. My profession, IT, is bringing more automation to the planet every day. I would be irresponsible to not understand the ramifications of my work.

    Recently in my research I came across three facts that gave me pause. The facts are:

    1. Due to improvements in automation, it takes fewer people to create more goods and services.
    2. We are producing more good and services than we ever have, possibly more than we might ever need.
    3. Just as it takes fewer people to create goods and services, fewer people are garnering more of the wealth being created.

    The implications of these facts are dramatic and the implications are far-reaching. Allow me to elaborate.

    Fewer People Create More Output

    Consider this fact: In 1790 90 percent of the people in the United States were engaged in agriculture. Most of the people fed the population. Two hundred years later, 2.9 percent of the population was engaged in agriculture. A relatively small amount of people create enough food for all.

    Also, consider this one: In 1980 it took 26 people to create a $1 million in output. Today it takes 2.6.

    The pattern is obvious. As time marches on, it takes a lot fewer people to create a lot more wealth. Why? Automation technology. Every year we create more hardware and software that does work previously done by humans. Automation never tires and produces as much as we want, when we want. The trend is strong and consistent. The rate of innovation is increasing. And as the rate increases, more people will be displaced by machines and software. I talked about this extensively in the first article I wrote in this series.

    Let’s move on.

    We’re Producing All We Want — and Then Some

    Today China, India, Brazil, Vietnam, Indonesia, Pakistan, Thailand, Mexico, Italy and Turkey combined produce 18.5 billion pair of shoes year.  That’s more shoes made a year then there are people on the planet. (The current population worldwide is 7.5 billion.)

    Today there are 260 million cars registered in the United States,  which comes out to a little more than one car for every adult in the population.

    The number of cellphones in China in 2014 is 1.14 billion, in India there are 1 billion and in the United States there are 327 million. Just about everybody in these countries has a cellphone. And the prices keep dropping. Eventually, everybody on the planet will have a cellphone—which, by the way, has more computing power than did the computers onboard an Apollo spacecraft.

    Productivity no longer is constrained by the capacity of human labor to create goods. Whereas before the Industrial Revolution not enough goods were produced to satisfy consumer demand, today things are reversed. The modern struggle is finding enough buyers to purchase what’s been made.

    As I mentioned earlier, we’re really good at making as much as stuff as we want, whenever we want. And yet, despite this abundance, there is a problem.

    Wealth is Concentrated to a Few

    A report that came out earlier this year reveals a troubling fact: Eight people on Planet Earth own as much wealth as 50 percent of the rest of the global population. True, there is some dispute going on about the methods by which this number was determined. But, even if the number is 30 percent, the disparity in the distribution of wealth is astounding. More wealth is being concentrated to fewer people even as automation becomes more prevalent. Abject poverty may not be rising, but increased displacement of workers is. As workers become displaced, their wealth diminishes.

    Saying “Things must change” is absurd. Things will change. The question is, “What will that change look like?” Will we have a fully automated society in which there are more than enough shoes to go around, or will we still have a world in which there are those that go shoeless?

    What Do We Do Now?

    In previous articles I’ve talked about Universal Basic Income (UBI) as a possible way to address the problem of providing income for displaced workers. UBI is a viable solution, but not one that will to come to fruition in the near future. The problem is here today. So, what do we do?

    Read on.

    Economic Sustainability Over Economic Growth

    I’ve mentioned many times, there is a good argument to be made that the jobs taken away by automation are not coming back, nor will there be an abundance of new jobs to replace those taken. My prior article supports my assertion. Eighty-eight percent of job displacement is due to automation. The need for human labor is diminishing at accelerated rates. That’s the bad news. The good news is that automation has allowed us to grow our productivity more than we’ve imagined possible. But growth is not the answer. On a planet full of shoes, there are still those who go shoeless. The change we need to make is to move from an economy based on growth to one based on sustainability.

    Changing the Way We Talk About Things

    I’ve come to accept that we cannot grow our way into economic prosperity any more than we can grow our way into good health. In fact, too much growth can kill you—just ask someone who suffers from morbid obesity. So I made the change in how I talk about prosperity. I no longer use the term “economic growth.” Rather, I use the term “economic sustainability.” I am a big believer that thinking follows language. Change the way we talk about something and we’ll change the way we think about that thing. If we want to have a sustainable economy, we need to start talking that way.

    Creating Wealth for All

    Okay, I’ll come clean. I think that given the current trends, too few have too much. More wealth parity is required. But, as we have learned on the terrain, overt wealth redistribution is not the answer. We cannot tell somebody we’re going to take away a part of their wealth without upsetting them. But, we can set an example in the benefit of sharing the wealth to benefit all. We in IT have been doing it for years—it’s called open source. We learned a few years back that when we give it away, we get it back. The trick now is to go beyond IT and make the open-source mindset part of our civic sensibility.

    At some point in the not-too-distant future—say, about 20 years—we will be at almost total automation. If trends continue, there will be few with a lot and a lot with a little. People that don’t have a lot don’t have much to lose. Wealth inequality creates turmoil, unrest and overt aggression. If you think not, take a look at the excesses of France under Louis XIV which, by the time you got to Louis XVI, led to the French Revolution and the Reign of Terror. Or consider that the wealth disparity during the last generation of the house of Romanov led to the Russian Revolution. Nicholas dined in lavish halls while the serfs starved. Lenin prevailed.

    Wealth parity creates political stability and political stability creates prosperity for all. Achieving wealth parity comes about by sharing. Again, we who have code on GitHub know this. Again, the trick is to make the open-source dynamic part of our civic sensibility.

    Let me close by providing one more fact. One of the thing I’ve learned in my research is that as the population rises in a country, so does the GDP.

    Figure 1: Population growth among 9 most populous countries, 1960 -2015 (Source World Bank)

    Figure 2:  GDP Growth, 1960 -2014 (Source World Bank)

    But, again the trend is that the wealth goes upward to a few. So we have a choice. As automation increases, we can learn to share the wealth and create a world that is stable, sustainable and prosperous. Or we can keep the current trend in place, allowing the few to have the most. And because we don’t need a lot of human labor to maintain the levels of production possible, rather than risk ongoing political upheaval and civil unrest, we can just get rid of those that unfortunately are on the wrong end of the distribution curve. Their labor is no longer needed.

    Is such an idea vile and extreme? Yes, it is. Is it one without precedent? I’ll let you be the judge.

    — Bob Reselman

  • Increasing Your ‘Bionic Footprint’ with DevOps

    Increasing Your ‘Bionic Footprint’ with DevOps

    “The Six Million Dollar Man” was a 1970s TV series. In the show, NASA astronaut Colonel Steve Austin is severely injured in a crash and is “rebuilt” with bionic features that enhance his strength, speed and vision beyond normal human capabilities. The main tagline was, “We can rebuild him, we have the technology.”

    I recently was watching an old episode and it got me thinking about how the show is analogous to the genesis of DevOps—specifically, how individuals with an operations background have to “rebuild themselves” to keep up with the speed and direction of the technology industry.

    Over the years, there have been several decrees of “Unix SysAdmins are going away.” I have always firmly disagreed with that assertion. Rather, I believe that SysAdmins have to continually evolve their engineering skills to stay relevant and, more importantly, gainfully employed. It was also becoming increasingly apparent that the manual tasks of deploying infrastructure, keeping it patched, monitoring and the myriad other things a SysAdmin performs every day could not keep up with the demands of the increasing pace of the digital world and the onset of cloud computing. Infrastructure is moving rapidly to being automated and programmatically deployed and the talent needs to adjust accordingly to stay relevant.

    With many enterprises adopting the agile methodology and moving toward a continuous integration/continuous delivery (CI/CD) pipeline, the culture of DevOps became a reality. Due to the increased velocity, there became a clear need for the core tenets of DevOps culture, which include culture, automation, measurement and sharing (CAMS). In Six Million Dollar Man terms, this was simply “Better … Stronger … Faster.”

    Embracing DevOps through CAMS is similar to the superhuman enhancements that composed the rebuild of Steve Austin, which took him from man to bionic man. Here are the four ways that DevOps can increase your enterprise’s “bionic footprint”:

    Improve Culture

    Even Austin’s bionic features only got him so far; the bionic man had to rely on his team to complete his dangerous missions unscathed. The same is true in the enterprise: Building a collaborative culture is crucial for success. Culture is paramount in maintaining overall velocity without adversely affecting quality. Developers and operations teams need to function in concert to ensure a resilient application and infrastructure.

    Increase Velocity via Automation

    Automation greatly increases velocity, akin to how Austin’s bionic legs allowed him to run at high speeds and make great leaps. Automating processes saves time, money and lets your team focus on more complex tasks—a win-win for productivity gains.

    Measurement

    Steve Austin had a bionic left eye that enabled him to see in the dark as well as detect heat. This provided him precise measurements of his surroundings in any situation, enabling him to gain the upper hand against adversaries. Similarly, measurement gives insight into all aspects of the software development life cycle, application performance and other key metrics. Without insight and transparency into measurement, your team is essentially working blind.

    Sharing

    Austin had a bionic right arm that had the strength equivalent of a bulldozer. Strength and resiliency are increased by teams that work and communicate effectively made possible by DevOps.

    To summarize, I strongly believe that the mantra of “Better … Stronger … Faster” should be that of every DevOps team moving forward. DevOps’ parallel of CAMS upgrades your team’s capabilities to perform more productively. There is no end game; the objective is about continuous improvement, velocity and sustainable growth. Enterprises that want to undergo digital transformation need to adopt this cultural approach to increase their “bionic footprint” to succeed.

    About the Author / Mike D. Kail

    Mike D. Kail is chief innovation officer at Cybric. Prior to CYBRIC, Mike was Yahoo’s chief information officer and senior vice president of Infrastructure, where he led the IT and global data center functions for the company. Prior to joining Yahoo, Mike served as vice president of IT operations at Netflix, where he was responsible for employee technology and various cloud engineering components. He has been widely recognized for his insightful industry commentary on social media Twitter, and was recently named by the Huffington Post as one of the “Top 100 Most Social CIOs on Twitter.” Connect with him on LinkedIn and Twitter.

  • Foster Creative Workers, not Assembly Lines

    Foster Creative Workers, not Assembly Lines

    Why do we keep building assembly lines of creative people?

    Why do tech companies still structure their developer workforces around ideas invented during the industrial revolution over a century ago? It’s ignorant, lazy and, worst of all, it pisses everyone off. Most of these archaic ideas must die if we are to take fully enlightened advantage of the impending internet revolution.

    Internet Revolution? What?

    Before I explain my thoughts about what old ideas are holding our workers back. it is important to understand the one big similarity between the workers of the industrial age and developers of today. Both are the backbone of an exploding economy that has changed nearly everything about the way we live. Without these two types of workers, both revolutions (industrial and internet) would collapse. But this is where the similarity ends.

    For me, the most important difference between the two is that developers are highly creative and highly skilled, and are required to be highly intelligent workers. This creative worker requires a very different environment to ensure “productivity.”

    Let’s dive deeper into this idea, and see if we can uncover the problems with sticking to century-old concepts.

    ‘Work’ in the Industrial Revolution

    In 1913, Henry Ford installed the first assembly line for the mass production of automobiles. From there the industrial revolution exploded. Quality of life boomed. Life-changing products became affordable. Life expectancy increased. Everything was going up and up. (Except, of course, animals and the environment, but I’m going to stay on the subject of work.)

    The industrial revolution redefined the way we measure work. The world moved to a strict schedule of productivity, and was no longer tied to the weather or the sun. Hans Rosling shows it the best here.

    But more than 100 years have passed. We are very clearly going through another work revolution, yet we still cling to the archaic concepts of the Industrial Revolution. The nature of the work we need is drastically different. Ideas about 9-to-5 work hours, productivity, vacation and work/life balance just don’t apply to the work we are trying to do today.

    This was work back then, done by people who could do the task without creativity.

    If Henry Ford lived today, what would he do? Would he make an assembly line of computers on which programmers would write line of code and pass it down the line to the next programmer, who would do the same, until you had a complete application? If you think that’s stupid, why are we working like that? Here is a bug, go fix it! Shouldn’t we be reinventing these 100-year-old concepts instead of applying them as they are?

    Industrial Revolution ‘Work’ Causes an Unhappy Workforce

    Before the Industrial Revolution, most manufactured products were made individually by hand. A single craftsman or team of craftsmen would create each part of a product.

    Now that most assembly lines are automated, today’s work requires individuals to be craftspeople once again. We no longer hire developers just to tell them what to do and how to do it. Developers, like all creatives, don’t like to be told what to do. Creative workers like to be given a problem and they love creating a solution.

    We no longer need to make sure that our employees are working. We need to make sure that they are inspired.

    Take, for instance, the job of an overseer/manager. In the industrial age, this type of person made sure everyone was on task and meeting quotas. They were task masters, and they were often feared. Today, small startups rarely hire task masters (or as we now call them, project managers) to ensure worker productivity right out of the gate. Even if a company does hire PMs, they are no longer micromanagers; they are process optimizers. They make sure that the team is fully informed about what problems need to be solved so they can reach their highest creative potential. Today, if a tech company goes down the route of micromanagement, it loses its most talented people. This change tells us something: Today’s tech workers want to be engaged. They want to solve problems. They want to work for the sake of the creativity.

    No More 9 to 5 and Hourly Rate

    An hourly rate only makes sense when you need someone to complete the same task x times a day. If you need to assemble a thousand cars a month, then you need to make sure you can guarantee numbers. This makes hiring and firing simple: If workers can’t fill their quota, then they are replaced with those who can.

    If you work in the tech industry today, it’s obvious why the above concept is idiotic. Ask any creative worker—software developer or otherwise—when they are most productive and if it helps to be given tasks and blindly assume deadlines. They will quickly tell you that what matters most is the breakthrough, and that could happen at any time of the day. I can’t tell you how many breakthroughs I’ve had on weekends, or in the last thoughts before sleep. And once the breakthrough happens, we developers furiously code toward the finish line to test the validity of our breakthrough. No one needs to tell us to get the work done. We WANT to get the work done and we understand the business requirements; don’t worry, we won’t slip—assuming, of course, that the work is engaging and interesting.

    Let’s separate the concept from the workforce for a second. No painter sells his or her art based on the hours spent creating it. The price is based upon the value of the work in of itself. We give an intrinsic value to the final product.

    A developer could make a million-dollar contribution in a single day. Another developer could make a series of contributions over two years that made it possible for that one developer’s million-dollar solution. Both are equally valuable and necessary.

    The creative workforce should be valued similarly. It is impossible to measure productivity-ensuring work eight hours a day, five days a week. A million-dollar contribution achieved in a single day or over two years—both are equally valuable and necessary. Neither can be reached by giving tasks. They can only be reached by giving problems, and as much time as it takes to solve that problem.

    Creative Problem-Solving

    In a task-based scenario one software engineer might fix a bug quickly, but then it crashes the system next time it runs. In a problem-solving scenario, the creative thinker would figure out that this particular bug is a symptom of a large underlying problem that needs to be fixed to prevent an even larger failure. This type of creativity we seem to attribute to the arts alone. However, engineering is not different: Here is what the founder of YC, Paul Graham, who said in his amazing book, “Hackers and Painters”:

    “Like painting, most software is intended for a human audience. And so hackers, like painters, must have empathy to do really great work.”

    We must remember that just like making a new product is creativity, writing code at its core is creative work. After all, it is not the application of the paint that is creativity. It is how you decide to apply the paint that takes a creative mind. Similarly, it is not the act of coding that is important. It is how you code that is the creative part. In software development, the creativity scale may vary per problem, but if the creative aspect is not nurtured then we encourage mere task completion.

    How Do We Fix These Problems?

    First, we must work on our definitions. Now that we understand where the crux of the problem is, we can start re-engineering how we communicate our concepts of success and failure. I discuss my ideas about this in my previous article, “4 Inspiration-Killing Concepts That Need Redefining.”

    See you there.

    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.

     

  • 5 Ways to Ensure IT Service Desk Agility

    5 Ways to Ensure IT Service Desk Agility

    The agile approach is everywhere. Born in the software development world, agility means adaptive planning, ongoing development and continuous improvement. Rapid and flexible response to change is critical. It is not surprising that the best practices of agile software development penetrated into other areas, and IT service management (ITSM) is no exception.

    The Service Desk Can Be Agile

    Unless you’ve been away from ITSM for the last 10 years, you know that an agile IT service desk is flexible, automates processes for quicker incident resolution and emphasizes collaboration between technicians and interactions with users.

    But how do you adopt these seemingly tough principles to make your IT service desk truly agile? We’ve put together five simple ways to help you assess your IT service desk and move toward agility.

    Keep Interactions in Real Time

    IT service desks are constantly nestled in webs of interactions between technicians and users. It’s easy for technicians to get lost in endless emails and delay resolution. To avoid chaos and ensure timely ticket resolution, interactions should stay in real time and communication should be as proactive as possible.

    Let’s say the sales department of a company uses a sales application. But the application crashes, and the department’s users are unable to connect to it. So, they raise a ticket, and the IT admin immediately checks the server and realizes it’s down. They then check the code management database (CMDB0, which indicates that the application is also used by the finance department. Before attempting to resolve the incident, the IT admin should send a notification to the sales and finance departments to inform the users of both departments that the application is down and that the IT team is working on resolving the issue. That way, they can prevent duplicate tickets and focus on fixing the issue.

    Eliminate Productivity Leaks

    Most IT service desks are built on ITIL processes, which means that they are already efficient. But to become agile, you have to track IT service desk performance with key performance indicators (KPIs) such as lost business hours, SLA compliance and cost per ticket—all of which monitor both cost and productivity. While KPIs help you measure productivity leaks, reports help you identify their root cause. For example, your service desk KPIs indicate that there have been a lot of SLA violations. A quick look at your reports shows that a lot of time is spent gathering information rather than on finding solutions. By creating a template for common incidents or service requests, all the information you need is gathered in one place, making it easier for technicians to quickly resolve issues and meet service level agreements (SLAs). Similarly, you can reduce the time spent on routine tasks, such as assigning tickets and tasks to technicians, sending notifications to users and more, by automating these processes.

    Encourage Collaboration Among Stakeholders

    Every IT service desk has stakeholders across various disciplines and geographies. And IT service desks are often rated on how seamless the flow of information is between stakeholders. Therefore, it’s important to have a service desk that provides visibility and encourages collaboration. Let’s say that a company is running its financial application on a legacy server. To cope with increasing transactions, IT proposes a server upgrade. Since this application impacts everyone in the organization, any disruption in service will impact the business significantly. So, IT should keep all business groups and admins in the loop, ask them for recommendations on scheduling the change, ensure backout plans and inform users about the change schedule and expected downtime. An IT service desk application that provides room for this collaboration ensures a smooth upgrade with minimal interruptions.

    Establish Self-Organizing Teams

    An IT service desk is incomplete without its team. And since IT is essentially the command center of a company, it’s imperative to establish a self-organizing IT team. This starts with looking at the current team’s structure and creating workflows around it. In most IT service desks, the technicians are grouped based on their skill sets and level of expertise. So, you can easily assign a technician (or group) to a workflow that requires a certain type or level of skill. You can also auto-assign tickets to technicians or groups, assign a change manager to coordinate with different teams, automate escalation rules for complex issues, configure a backup technician when a one is not available and more.

    Learn Through Iterative Increments

    IT service desks are expected to meet the changing demands of their organizations. This means that they have to make a number of small changes over a period of time. In agile terms, this is called iterative increments. Let’s take, for example, a growing organization that has several employees joining every week. A typical employee onboarding and provisioning process requires the IT team to coordinate with different teams including HR, maintenance and administration. This can take up to 10 hours for each new employee. But, you can simplify this process by dividing the request into smaller tasks and assigning the tasks to corresponding departments. You can also automate this whole process, significantly reducing the time it takes to onboard a new employee.

    Just follow these simple steps and you will be on your way to creating an agile IT service desk that delivers quicker resolutions, increases user satisfaction and evolves with rapidly changing technologies.

    About the Author / Aparna TA

    aparnaAparna TA is a product analyst at ManageEngine, the real-time IT management company and division of Zoho Corp., and works in the ITSM products division for the flagship product ServiceDesk Plus. She keeps an eye on various IT practices and studies their impact on IT service management. In her free time she likes to relax on a couch and read the latest crime novels. Connect with her on LinkedIn and ManageEngine on Twitter.

  • Last-Mile DevOps: How to Keep Employees Happy

    Last-Mile DevOps: How to Keep Employees Happy

    Chances are that your company is embracing DevOps to make sure you can get fresh, new digital capabilities to your customers ASAP. That’s because in today’s market, you either have to be first—or quickly close any gaps between you and your more digitally innovative competitors.

    But when it comes to getting new capabilities into the hands of your own employees, things probably move much slower. That’s because your internally facing apps have to clear a hurdle that your customer-facing apps don’t: administration of access privileges that often are poorly defined and inadequately automated.

    That’s a problem. People can’t be productive if they don’t have access rights for the IT resources they need, when they need them. The growing Millennial workforce is going to be especially unhappy if IT is slow to meet their digital needs. And from a security perspective, slow administration of access privileges is also a problem—because your company must be able to automatically and immediately revoke employee access privileges the moment they’re fired or they quit.

    This automated, accelerated management of internal users’ access rights is the missing “last mile” for DevOps. And it’s something you have to address if you’re going to fulfill the needs of the business with the same excellence as you fulfill the expectations of your customers.

    What Makes the Last Mile So Tough?

    If you bank with Chase or ride with Uber, your access to your personal data is gated by your personal login. But, as a customer, you essentially use the same app as everyone else.

    Application privileges within your own company are entirely different for two reasons:

    • Privileges for your internal workforce are much more complex than for customers. Salespeople have sales apps. Your finance department uses finance systems. Your service reps may be allowed to see RMA numbers, but not SSNs. So you must quickly give each person access to only the resources appropriate to their specific role and responsibilities—or risk consequences that include lost productivity, security breaches, compliance failures and excess software licensing costs.
    • Management of internal privileges is an ongoing activity. Productivity, security and compliance demand that you provision each user account for each application with the right privileges at the right time. Privileges must be immediately and appropriately modified every time an employee is promoted or transferred. Privileges must be terminated immediately when someone leaves your company. Privileges may also have to be temporarily modified in real time due to session context—such as use of non-secure public WiFi or an access attempt from a questionable location or at a questionable time.

    Simply put, for internally facing apps, getting code onto a production server isn’t enough. You also need to automate and accelerate management of the “last mile” between servers and employees.

    What Are ‘Last-Mile’ DevOps Requirements?

    DevOps toolchains automate and monitor the software life cycle from design and development through testing and deployment on a production server. What’s missing is automated provisioning and governance of the “last mile” between the server and the individual worker.

    These tasks include:

    • Capture of current user role/responsibility profiles from HR
    • Provisioning of application-specific accounts with profile-appropriate privileges and controls
    • Self-service inputs from authorized LOB managers
    • Detection of session context (network connection, time of day, location, etc.)
    • Real-time modification of privileges based on that session context
    • Automated revocation of access privileges upon termination, transfer, etc.
    • Employee self-service for permitted optional applications and services
    • Monitoring and reporting on employee account activities and events

    Your team probably performs many of these “last mile” tasks manually. Some may also be automated using homegrown scripts. Excessive dependency on scripts is a bad practice, though. Scripts usually are poorly understood by anyone but the original writer—which makes them difficult to maintain and update over time. They also don’t typically integrate well with DevOps, HR systems or other key pieces of the app delivery puzzle. This lack of integration slows your processes down and opens the door for human error.

    Automation of last-mile DevOps makes much more sense. Automation speeds processes, reduces cost and optimizes accuracy. Integrated automation also gives you a dependable, centralized point-of-control for defining and editing policies—as well as for capturing the event logs necessary for compliance and security reporting. The right automation solution will also integrate with the rest of your operations environment (including directories, VDI, and mobile management tools) to ensure secure, reliable application access.

    Why is ‘Last-Mile’ DevOps Important?

    Most business leaders already understand why rapid rollout of customer-facing applications is so important. Unfortunately, many fail to recognize the importance of being just as fast and accurate when it comes to supporting their own workforce.

    The truth, however, is that automation of last-mile DevOps benefits your business in several important ways:

    • Improved employee productivity and engagement. Your workforce will be much more productive and more engaged when everyone has immediate access to the digital tools they need. That improved employee performance will benefit your customers as well.
    • Higher IT efficiency. The sooner you automate the many everyday service provisioning tasks that your skilled IT staff now performs manually, the sooner they can to shift their precious time and energy from routine work to higher-value projects.
    • Enhanced security and compliance. Well-defined access policies, diligent enforcement of those policies with rules-based automation and centralized logging of access provisioning activities all reduce your IT-related risks—as does immediate, automatic and complete revocation of all access privileges the moment any employee or contractor is terminated.
    • Reduced “Shadow IT.” When IT is more responsive to people’s needs, they are far less inclined to turn to alternative digital resources that aren’t properly monitored, governed or secured.
    • Greater business agility. M&A, reorgs and other organizational moves are chronically bottlenecked by manual execution of mass changes to the workforce’s digital access privileges. Rules-based automation of last-mile DevOps eliminates this agility-killing process friction.

    The bottom line: To achieve true digital agility, your company must automate the “last-mile” tasks that give your people access to the IT resources they need—when they need them.

    About the Author / Stacy Leidwinger

    stacy-leidwingerStacy is the VP of Products at RES where she is responsible for defining overall product direction, roadmap and positioning, to drive product excellence, company growth and customer success in the areas of end user computing and security. Her background is in both product marketing and product management helping to positioning B2B software companies for growth and market leadership. Prior to RES, Stacy led the product management team at Directworks, a cloud-based sourcing and supplier management solution. Before Directworks, she managed the roadmap, product positioning, and go-to-market strategy for Vivisimo, an enterprise search solution, which was acquired by IBM. While at IBM, Stacy was responsible for the integration of Vivisimo’s product line into IBM’s big data portfolio. Connect with her on LinkedIn / Twitter.