devopsy.kinsta.cloud

Tag: DevOps Leadership

  • Three Ways You Can Embrace Curiosity to Climb the Career Ladder

    Three Ways You Can Embrace Curiosity to Climb the Career Ladder

    As the product manager of a high-growth startup, my role has evolved quickly over the past four years. When we started the company, in a garage along one of the many Amsterdam canals, I found myself doing everything from writing code to taking out the trash and ordering dinner for the late nights in the office. Since then, our team has grown rapidly and we are now in a beautiful office where we are proud to host global brands—something we didn’t do in the garage.

    When I joined MessageBird, it was a small company so we each wore many hats and shared responsibilities. Regardless of the hat we wore at any given time, each person stepped up and took the opportunity to learn new skills to help the company reach the next level of success. As the company has grown, I’ve grown along with it. I started as a developer and now, four years later, I am managing product development for our platform of communications solutions.

    As I think back to how I got here, there were three key practices that paved the way.  In addition to never saying no to a job—even if it wasn’t in my job description—I’ve found that nurturing these three practices can go a long way to building a career.

    Ask the Long-Term Questions Early and Often

    When asked to select from a list of 34 attributes that represent their top strengths, 76% of product managers chose “always learning,” and 64% selected “curiosity.” When coupled with a long-term focus, a learner’s attitude is a strong asset for personal growth. At a startup, prioritization of efforts at any time can mean the difference between success and failure. Part of my success was born from simply asking why. Why are we building this now? What customer pain are we solving? Why this focus over that one? Asking why early and often forces a team to slow down and think through whether they are focusing on the right outcomes. And, it’s helped me prioritize my time to have the most impact.  

    Be a Dreamer, but a Critical One

    Whether working as a developer or as a product lead, rallying the team around our mission and potential is critical to success. One of the most effective ways to do this is to dream big—and encourage the team to do the same. Imagining what could be is not only fun, but it helps us aim high. While we dream big, we remain critical of our ideas and open to the input and criticism of others. As we take in new input and ideas, we adjust our thinking but remain persistent on the end goal. To make an impact in a growing company, it’s important to keep one foot planted in solving current customer challenges. But, that doesn’t mean you shouldn’t keep an eye on the future and dream big.

    Acknowledge that You Don’t Know What You Don’t Know

    Growth and leadership are recognizing when you don’t have all the answers and having the confidence to admit it. I’ve learned that the best ideas don’t typically come from one brilliant mind, but rather from the collaboration of several minds. MessageBird was founded in the Netherlands which is a very small country. In fact, two hours in any direction and you’re in a different country with a different language and a different culture. As such, we’re fortunate to have over 30 nationalities represented. Naturally, different backgrounds bring different perspectives and different sets of knowledge. It’s a culture that has given us an edge because the diversity of thought enables us to see challenges from very different viewpoints.

    I’ve come to learn that not knowing something is OK as long as you stick to the pursuit of knowledge and validation. You will make some mistakes along the way, but don’t get stuck on what you don’t know. Let not knowing drive you to learn.

    Embracing curiosity, dreaming big and working together toward solutions are the best ways I’ve found to solve customer challenges and move your career forward at the same time. Hopefully, these tips help you drive yours forward, too.

    — Joey van Ommen

  • Leadership Role in Adding Test Automation to Existing Environments

    Leadership Role in Adding Test Automation to Existing Environments

    Leadership is the foundation for all agility. I’ve written elsewhere extensively on a model that works well for the new environment in which we find ourselves: the need for tens or hundreds of very smart people, doing things that have never been done before with new tools, working with people they may not be familiar with.  These creative, expert people make dozens of decisions a day that few others see in real-time, turning ideas into code that must run flawlessly and execute complex business processes. Quite a leadership challenge.

    The leadership model I’ve articulated is simple. Leaders at all levels should focus on rigor (good decisions based on options and data), alignment (everyone rowing in same direction) and efficiency (respecting everyone’s valuable time). Getting the right people, with the right skills and the right kinds of interactions, is more valuable than having the right process and tools. 

    For software agility, we know reducing the friction between development and productive use is a powerful leverage point. This general area we now call DevOps. Coming from the application space as I do, my primary focus has been on test automation. How can we at very low cost continually ensure that our evolving software is ready to be deployed to production (or production staging, if we are doing periodic bundled software deploys)?

    I’ve recently watched a team introduce test automation into an existing application environment. Great leadership was demonstrated throughout by multiple team members. Let’s examine the steps taken and point out the leadership that made it happen.  

    Set the Target

    Team and organizational leaders laid out a clear vision of the business benefits and their support for the initiative. This was the culmination of several months of learning, communication and cost/benefit analysis. Leaders gained alignment based on rigorous analysis.

    Ensure Adequate Leadership and Technical Skills Are in Place

    In the run up to the inception of the work, leaders hired an experienced testing leader, who in turn hired a couple engineers to do the work. Because the environment was a common one in the industry (Salesforce was a big part of it), the leaders sought the best expertise they could find, and wound up engaging an external specialist firm to get them going. People over process. 

    Define the Technical Architecture

    The new team leveraged the knowledge of the consultants and some of their engineering partners to examine options and select an approach. They shared the options and analysis with their team and leaders and gained consensus and understanding. In the process the approach was fine-tuned. The team demonstrated rigor and efficiency and gained alignment. One key of their success was the “towering technical expertise,” a lean product development term, brought by the consultants.

    Deliver Incrementally

    For this item, I will describe the solution chosen, since the specifics will be of interest to this audience. The vision was to train the product owner/systems analysts to write acceptance criteria for each user story (which was the unit of development here) in the stylized language Gherkin. As the development was done during a sprint period, the test team would take the Gherkin and write automated tests for the test tool Cucumber, which would drive execution in Selenium. The execution would be automatically connected to the deployment of new code using Jenkins.

    The team wanted to avoid disrupting the existing flow until the risk was reduced based on proven results. Accordingly, they began by building automation for existing software, proving that the vision worked in practice, and gradually completed the regression suite and started to catch up to work in process that hadn’t been released. Excellent leadership for agility was demonstrated again, driving rigor through proof of the concept and laying the groundwork to get the rest of the team aligned.

    Get the Rest of the Team to Change

    Once the test team caught up to being able to do in-sprint automation, they needed to tackle the training and acceptance of a new way of writing acceptance tests (in Gherkin). The great results they demonstrated helped influence the product owners and systems analysts to give it a try.

    Continuously Improve

    As the creative period of designing the test automation approach and getting into production came to an end, a new period of measurement and continuous improvement began. Here we have another foundational element of leadership for agility: understanding where we have repeatable flows where process really is the key, and where we have a creative endeavor in which the focus on people and interactions must rule. In a sense, the team transitioned from a product development effort to a manufacturing-like flow, and they accordingly changed their approach.

    Conclusion

    Sometimes we make the mistake of thinking that getting to efficient DevOps is all about tools and processes. My experience is that to the contrary, leadership is the key. As the first value of the 2001 Manifesto for Agile Software Development states, “People and interactions over process and tools.”

    — Michael K. Levine

  • Untapping the Potential of DevOps, Part 3: Keys to Success

    Untapping the Potential of DevOps, Part 3: Keys to Success

    Over the course of this series, we’ve talked about some of the common mistakes we have seen organizations make as they either launch or continue their journey into the world of DevOps. But just as it is important to understand the pitfalls that may happen during a DevOps transformation, it is perhaps even more important to know what the key indicators are that drive success. With that in mind, here are a few tried-and-true tactics for making the most out of your DevOps initiatives.

    Start With Automation

    One of the most powerful areas of impact for DevOps is in driving automation. It accomplishes several things: it increases the velocity of the development pipeline, it can reduce the number of errors or potential errors in code and it often frees up time for developers, allowing them to focus more on creating value and less on repeatable and mundane tasks. By ensuring that DevOps automation goals, including CI/CD, test automation, monitoring, Infrastructure as Code and GitOps are included at the outset of projects, you can better set up your organization for successful software development and delivery—both in the short term and for the long haul.

    Strong Communication

    When it’s all boiled down, DevOps is like any other advanced business tactic as it relies on strong communication to deliver the most success. As the name implies, DevOps engineers must bridge the worlds of development and operations, so to be truly effective they need to possess fluency in both worlds. Can you have success if you have engineers who are only strong on one side of the equation? Technically, yes. But you will not maximize the amount of value from your DevOps initiatives without stakeholders who can adeptly manage both sides. Additionally, communication with the business and other non-technical sides of the organization is critical. The entire organization should be on board with DevOps, with clear visibility into the transformation—your successes and challenges will come from frequent, effective communication.

    Adhere to Processes

    DevOps is process-driven, particularly as organizations scale. To work effectively, and to serve real enterprise environments, creating and adhering to processes is key. While automation is important for the rapid delivery of value, effective change management is important for sustainable development and system operations. Process and compliance are an important part of sustainability for large environments. It is also extremely important for organizations where compliance is vital—think industries such as finance, medical and government. By implementing and adhering to well-defined processes, you can avoid future headaches or rework that will slow down the pipeline.

    Leadership Buy-in

    The most impactful changes have one thing in common: strong leadership. Leadership dedicated to delivering customer value and understanding the software’s prominent role in delivering that value is key. Organizations that cling to outdated methods of development and delivery (i.e. waterfall) lead to slower delivery of value, which is the ticket to extinction. DevOps also benefits greatly from having leaders within the organization who serve as champions for change. By keeping a finger on the pulse of your organization from within, you can better practice change management, identify potential weaknesses earlier on and make your DevOps initiatives work for you.

    DevOps can be an extremely effective way to deliver the most customer value from your software pipeline. By keeping these four key indicators in mind, you can better position your team for success and enjoy the benefits of your DevOps journey.

    — Jonathan Fries

  • 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

  • ‘Not My Problem’: A Big Problem for DevOps Teams

    ‘Not My Problem’: A Big Problem for DevOps Teams

    Not my problem (NMP) – (n)
    1.    a statement, or position, of apathy expressed by those who perceive they are external and unaffected by a negative predicament. While sometimes warranted, it is typically uttered by those who perceive themselves as powerless; can’t be bothered; are too lazy, or are selfish non-contributing leeches. See also “complete cop out”
    2.    an attitude that will stymie attempts to implement DevOps in your organization and will thwart success
    3.    (archaic) Actually not your problem

    While perhaps it’s become more frequent in our culture of relative indifference, some of our oldest stories bear witness to how timeless the phenomenon “not my problem” is. For example, in the the biblical story of Cain murdering Abel, God asks Cain afterward, “Hey Cain, I can’t find Able. Do you know where he is?” Cain responds famously, “Am I my brother’s keeper? (NMP)” It crosses country borders and language barriers, too: A transliteration of the same sentiment in Polish is, “Not my circus, not my monkeys.”

    And we’ve all been guilty of thinking it at work: “That’s not in my job description,” “I’ve got to focus on my own projects rather than bail that person out,” “That’s the Sales team’s role.” These thoughts pass uncharitably through most of our minds, despite most of our unwillingness to say something so callous to a person we witness being affected by our indifference.

    It would be naïve to think that this cultural indifference was held at bay by DevOps teams, all united under the same goal of turning out quality product in the most efficient ways. Unfortunately, the NMP problem can pervade even the most motivated and scrappy teams, and it has a unique power to dismantle attempts at positive culture-building on those teams, which are necessarily built on the core values of sharing and learning.

    To have DevOps teams that embody these fundamental characteristics, we have to shift the individual and team perceptions of the ownership of success and failure. It can no longer be an Ops or Dev or QA or InfoSec issue. It has to be OUR issue.

    Here are some key items that I have found fundamental to combating NMP in my teams:

    1.    Change Starts with You

    If you don’t want to see NMP present in your team, you need to ensure you are not a contributing source. Before ending your day, dedicate at least a few minutes of reflection to the day’s interactions. Did you actively seek out and identify areas where you can be of assistance? Upon reflection, did you miss an obvious chance to help someone on your team? Keep a daily journal and try to list these things. This will help instill the behavior into your normal regimen.

    2.    Culture is What You Tolerate, not What You Mandate

    We have all been a part of “hoorah” speeches where we hear the “we are a team” speech; perhaps we have given them ourselves. We have also walked away from said speeches with a cynical demeanor, knowing that they are just words and everyone is out for themselves. While words are important, words without action are just noise. As a leader, you need to communicate your “No NMP” policy, and you need to act upon it. If you are the manager of a team, you must be willing to take corrective actions against people who continue to exhibit a NMP attitude. If you are a member of a team, you must be willing to hold your teammates accountable. Apathy kills. It takes time and patience to repair NMP behavior; sometimes, however, you might need to part ways with the source of NMP. As a manager this may mean letting someone go, or as a team member it can mean letting your team go.

    3.    Everyone’s a Leader

    As readers of my blog know, I do not equate leaders to managers. I am sure that most of my readers have lived that experience firsthand. But having a non-NMP team requires us all to be leaders, even if your manager is not. We must actively try to identify areas of weakness and and areas of improvement and seek out ways to address them and turn them into areas of strength. Sometimes that even means mentoring your manager. Yes, I know this can be tricky, but good managers will be receptive and open to constructive feedback. If you manager is not and is instead a source of NMP, see  No. 2, above.

    Many companies and teams have been eaten up with the cancer of NMP. There aren’t enough team-building events and “trust falls” to counteract a culture where some people break for the door while others work to resolve an issue. Because it is this behavior that causes the whole culture to collapse. It can’t be “All for One, and One for All (except Bob, because he’s a selfish jerk).”

    It’s incumbent upon all of us, as team members and as managers, to fight the NMP battle. The culture of our teams most certainly is our problem.

    About the Author / Adam Bowen

    Adam is a technology leader with over 15 years of experience in technical, sales, and senior leadership roles. As the senior member of the Office of the CTO at Delphix, Adam works with other thought leaders executives of the Global F100 to eliminate key business constraints through innovative new processes, offerings and technologies. Adam serves as an evangelist on behalf of Delphix to communicate the company’s vision, values, and ideas with customers.

  • DevOps Chat: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

    DevOps Chat: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

    Our first podcast of 2017 is with Aruna Ravichandran, co-author of DevOps for Digital Leaders. Of course when not authoring books or helping financially challenged but gifted students attend college, Aruna is a VP of DevOps marketing at CA Technologies. I have interviewed Aruna before on DevOps TV and discussed her career that has seen her go from a million lines of code contributor at HP and Juniper to business line executive.

    Aruna is a very interesting person who also has some great things to share. That is why I think you will find not only this DevOps Chat interesting, but her book as well.  Also, we will be doing a full hour Q & A with Aruna on January 17th that you can sign up and attend for free. If you like this interview, don’t miss the webinar. Also, if you would like to download the book you can here: http://www.apress.com/us/book/9781484218419

    In the meantime, as is usual on our DevOps Chats below is a streaming audio of our Chat with the written transcript below. Enjoy!

    Alan Shimel:                Hey everyone, Alan Shimel here with our first DevOps chat of 2017 and we’re lucky to have Aruna Ravichandran, a VP DevOps Marketing at CA Technologies. Aruna welcome.

    Aruna Ravichandran: Thank you Alan. Thanks for actually having me. I’m excited to be here with you.

    Alan Shimel:                Well, you are leading of 2017 so we’re going to set the bar high right away Aruna and hope to live up to it.

    But Aruna, truth be told, we don’t have you on today in your VP of DevOps role: you’re here as Aruna the author today and we’re going to talk about a book that actually came out I guess towards the end of last year but it’s still out there and we’re going to be doing a webinar on it later this month, and I wanted to really talk to you about that a little bit.

    The book is called DevOps for Digital Leaders. Correct?

    Aruna Ravichandran: Yes, that’s correct.

    Alan Shimel:                And why don’t – just from the get-go why don’t you give our listeners a little bit of an overview of what the book is about.

    Aruna Ravichandran: Sounds good. So this book is called DevOps for Digital Leaders, it’s all about how one can reignite their business with a modern DevOps-enabled software factory. I embarked on this journey on writing this book almost about a year-and-a-half ago along with two of my co-authors Karen Taylor as well as Peter Waterhouse.

    We looked at all the different books within the market – there is no dearth for books in the market when you think about DevOps – but what we saw was that even though there are so many different books in the market nothing really talks about some of the pain points which we constantly encounter customers asking us when we talk to them.

    Some of the pain points which customers constantly ask us are, “I want to be able to start this journey called DevOps. How do I start? What should my journey be? Where can I start? How do I develop? What should be my maturity model?” And so that’s one question which we constantly get across the board.

    Second pain point which we have heard from customers is, “How do I actually measure the success of DevOps? What kind of metrics can I use? How is success actually going to look like which I can report back to my management chain that whatever initiative I have embarked on with DevOps is now actually successful?”

    So we talked to several – over 100-plus customers – we learned from their experiences on what metrics are actually used and what is actually built practically in the industry and shared those in the form of use cases as well as actual metrics in the book.

    So the book primarily focuses on DevOps adoption in terms of a journey as well as what are some of the key metrics one can actually use in order to embrace DevOps.

    Alan Shimel:                Great. Aruna you hit on a couple things that are kind of near and dear to me. One is something that I’ve spoken about and talked to people now for a while which is too many people – you know, DevOps is so hyped and so many people are positioning DevOps to be, you know, it’s this great, white unicorn that’s crapping out rainbows for everyone but it doesn’t always work like that, right?

    There are failures, there are challenges, there are hurdles, and not everyone who just wants to do DevOps can wave a magic wand and become a DevOps factory or a modern software factory. So I’m glad to hear that this is kind of something that you guys are exposing in the book.

    The other thing is, you know, in almost three years of doing devopsy.kinsta.cloud now I find that our listeners, our readers learn the most from listening to how their peers have dealt with stuff: so case studies, case scenarios and these kinds of things. So the fact that you had access to hundreds – literally hundreds if not thousands – of customers who CA Technologies – CA has worked with – really gives us some great insight.

    Can you give our listeners a little bit of a taste for the kind of – I know you call them case scenarios – and they’re kind of case studies, right? – can you give us a little flavor for what those are like?

    Aruna Ravichandran: Yeah, absolutely. So if you look at the book it’s organized across the entire software factory. Let’s say if you think about customer deployments DevOps basically goes all the way down from planning to requirements to development, testing, release, and then into operations.

    And so what we did was we talked to – we interviewed several different practitioners who are existing CA customers, sometimes we even talk to non-CA customers – understood the role DevOps plays in terms of culture and collaboration as well as the toolsets which they’re actually leveraging in order to implement DevOps within their companies.

    And we looked at – we _____ the use cases around the whole software delivery to the chain. So if you look at the book – even though we talked with several thousand customers – you know, we couldn’t basically put all those case studies within the book, so what we did was we broke up the book across the entire software delivery chain and there is a chapter dedicated for every aspect of the software factory starting from planning to development to testing to release to operation and we leveraged one customer example on how they actually implemented DevOps best practices along with the underlying toolset and what are some of the metrics or the results they actually got in terms of being able to show what success actually looks like.

    Alan Shimel:                Got it. So Aruna I wanted to touch on another aspect of DevOps adoption that you hit on in the book, and that is the idea that not everyone started their DevOps journey at the same time or are going at the same speed or at the same rate, right? Some organizations are relatively mature in their DevOps adoption and DevOps practices: others are still talking about starting. So is there something for everyone in the book or do you need to be sort of on-your-way DevOps expert to really get value?

    Aruna Ravichandran: No. So, you know, like I said because we knew that there is no clear-cut framework, right – like if you think about I-_____ there is a very prescriptive framework in terms of where you can actually start and how you can actually end. With DevOps one can start many different ways.

    So what we actually did was we looked at some of the best practices a lot of the customers have actually implemented and built a framework in terms of a maturity model and we shared that as best practices.

    So if you think about accelerating the maturity we talk about, you know, three different examples of how customers could actually start. The first way is to basically build an end-to-end release management system; and the second one is to how can you operationalize with feedback loops going all the way from Dev to Ops and vice versa.

    And the last one is how could you actually optimize the continuity stability pipeline?

    So we shared some of the best practices in terms of where one can actually start and how they can actually modify their processes to give them a lifecycle regardless of where they want to start. They could start in Dev and end in Ops; they could start with Ops and make changes to Dev. But we shared some of the best practices in terms of maturity model which customers can actually implement.

    Alan Shimel:                Excellent. Aruna, again, we only have 12 minutes or so on these podcasts but we’re going to spend about an hour – 45 minutes plus 15 minutes in questions – on an interactive Q&A webcast with you on this subject.

    And I just wanted to, in our remaining time here, remind everyone or let everyone know that the webinar is scheduled for January 17th – so about two weeks from today or so – a little less than two weeks – at 2:00 PM Eastern Time. And within these show notes – if you’re listening to this on Sound Cloud or iTunes – within the show notes there we’ll have a link to the webinar. And if you’re reading along or listening on devopsy.kinsta.cloud we’ll have a link to the registration there as well. You can get to the registration on devopsy.kinsta.cloud – go to the webinar section and of course it will be listed there.

    But importantly Aruna I wanted to mention the book itself is free, correct, for download?

    Aruna Ravichandran: So the software version of the book is free. If they want to get the hardcopy they can buy it through Amazon or through our publisher which is Apress. I also want to call out and say that if they buy a hardcopy version of the book we are donating all the proceeds – the royalty from the book are being donated to a nonprofit corps Foundation of Excellence – the Foundation of Excellence’s mission is to award university scholarships for exceptionally talented but economically underprivileged high school graduates in India in order to embrace stem carriers.

    And so they can either go through the softcopy of the book or they can download the hardcopy and that all of their contributions are going to be donated to the nonprofit.

    Alan Shimel:                That’s great Aruna. Fantastic. I also want to mention that for those who register and attend our webinar we are going to give out ten signed copies – signed by Aruna and her co-authors – to ten folks who attend the webinar. I have to mention that those are US-based folks only as the logistics of mailing hardcopy books make it prohibitive to send them across the oceans. But ten US attendees will win signed copies of the book and everyone who attends will get a link to download the soft version, and of course you can buy the hardcopy version – the hard-book version on Amazon or Apress. Again, we can register that at devopsy.kinsta.cloud.

    Aruna, we’re almost here at the end but just to give some of the people – some of our listeners a little tease of what we’ve got going on. I know there’s some CA-sponsored DevOps research that’s due out shortly and that kind of reinforce this idea that organizations that do DevOps are doing better. Can you give us a preview or you’re not allowed yet?

    Aruna Ravichandran: I can give a little bit of preview. But what I can say is we did our research with one of our analyst vendors and partners with over 1,200 participants around DevOps and what I can say is that 87 percent of DevOps adopters have reported an improvement in customer experience.

    There is a lot of rich statistics which we uncovered as a result of that particular survey and we will be able to share the results from that particular survey report on January 11.

    Alan Shimel:                Great. Maybe we can speak about it a little bit on the webinar for January 17 as well – or incorporate it into –

    Aruna Ravichandran: Absolutely we will.

    Alan Shimel:                That sounds great. Well, Aruna, we certainly look forward to the webinar on January 17, but more, you know, as importantly, congratulations on authoring or co-authoring what sounds like a great book, and kudos actually for your donating the proceeds of the book to a worthy cause: I think it says a lot about who you are and what are the kind of reasons behind that, so thank you.

    Anything else before we wrap up?

    Aruna Ravichandran: Nope. I’m very excited to partner with you in order to share our experiences around writing this book and the journey, and hope that this book will be insightful for all of our DevOps practitioners who are embarking or are already on their way within DevOps.

    Alan Shimel:                Okay. Well, Aruna Ravichandran, co-author of DevOps for Digital Leaders, thank you so much for appearing on this episode of DevOps chats and we look forward to our interactive Q&A webinar on January 17 at 2:00 PM with you to continue our discussion. Thank you.

    Aruna Ravichandran: Thank you Alan.

    Alan Shimel:                Thank you. This is Alan Shimel for devopsy.kinsta.cloud and we’ll see you soon on another DevOps chat.

    — Alan Shimel

  • Enterprises still struggle to leverage IT as a tool to innovate

    Enterprises still struggle to leverage IT as a tool to innovate

    When trying to build great organizations today, it’s no longer sufficient to simply be agile enough to respond to meet today’s market demands. No. While that may have been good enough a decade ago. Today, enterprises need to be able to anticipate market changes and use technology to innovate ahead of the market.

    As readers of devopsy.kinsta.cloud know, DevOps, continuous integration, and continuous delivery are all approaches that enterprises use to drive the business outcomes they need through the use of technology.

    This ability to respond more rapidly to market dynamics is one of the big reasons why enterprises have embraced cloud services. It’s also why they are increasingly embracing APIs, mobile, big data analytics, and more. But it’s not always easy to get these moves right.

    Consider the demands enterprises face building their mobile applications. Despite best efforts, these apps too often don’t solve the business need they intended, and don’t deliver the new abilities initially sought. They build applications that attempt to accomplish too much, and end up being overly complicated and largely unused as a result. Or they take old habits, such as desktop and mainframe apps and squash them onto mobile devices without giving any thought to how the app may be used on that form actor.

    I started thinking about all of this when recently reviewing the results of a survey conducted by the Business Performance Innovation (BPI) Network, an executive advocacy organization, which found that there is a big disconnect between the understanding business leaders have when it comes to their knowing that they need to innovate – and the ability to actually do so.

    This brought me back to a discussion I recently had with Brian Katz, then the head of end user experience and innovation at Sanofi. He spoke about how good app design is one of those things that are crucial to driving business innovation today, but enterprises don’t often don’t get their apps built right. This is because they end up developing complicated apps that people don’t actually use instead of developing apps that their users really need.

    That observation parallels the findings in the BPI Network Study Accelerating Business Transformation Through IT Innovation, which found that from the C-suite out to operational units, senior managers want to implement technologies to increase agility, improve customer experience, and make their companies more competitive. The 250 respondents said:

    • 65% say technology has become “far more important” to their organizations in the past five years. Another 28% see it as “somewhat” more important.
    • 47% say they’re spending more time on understanding strategic implications of new technologies, and another 40% say they’re “working on it.”
    • The three most-pressing IT imperatives were: improve responsiveness to ever-changing business requirements (37%); Focus on digital experience as a competitive advantage (30%); and delivering applications faster, better, and at a low cost (30%).
    • Three areas that would benefit most from transformative technologies: Operational efficiency and effectiveness (52%); Customer experience, monetization and retention (33%); and Organizational alignment, culture and collaboration (28%).

    When it came to data center and cloud transformation, they found:

    • Top three benefits of data center and cloud transformation: Increased agility and responsiveness to business changes (70%); Greater cost efficiencies (57%); Faster time to innovation for new applications (46%)
    • How executives plan to change their data centers: Migrate to hybrid IT that blends traditional data centers with the cloud (45%); Modernize and upgrade (45%); consolidate servers (32%)
    • Three most transformative technologies to give a competitive advantage: Real-time intelligence from embedded sensors – IoT (34%); Always on, highly scalable and web based models (33%); Social media data mining and more efficient engagement (29%)

    However, business managers are not satisfied, generally, with what they see as the slow pace of innovation in their IT organizations:

    • Only 14% rate the level of innovation in IT organizations as “very high” vs. 15% that chose “poor.” Most gave middle ratings: “making progress” (37%) or “good” (32%).
    • How well is the IT organization executing mandate to transform and become a more strategic, responsive and a valued business partner? Only 15% said “very well” while 10% said “poor.” Most were in the middle: 28% said “good” and 44% said “making progress.”
    • What business metrics would you use to evaluate IT performance and effectiveness (top 3): Reliability, scalability and security of IT infrastructure (43%); Ideas and solutions for furthering business performance (40%); Quality and timeliness or app delivery (35%).

    The lackluster view of the role of technology and the ability to innovate at levels business leaders expect was surprising, to me. It’s not as if using technology to differentiate is something that is new to business. It’s not. It’s something we’ve been doing for decades now, and one would expect enterprises would be generally better at it than they are. With that in mind, I reached out to Dave Murray, head of thought leadership at the BPI Network regarding these survey results. You can find that interview here.

  • DevOps Leadership Series: Compliance, Testing, and Rugged

    DevOps Leadership Series: Compliance, Testing, and Rugged

     

    This past week, I headed to London for the Rugged DevOps event, where I had the chance to catch up with a few more industry thought leaders.

    Screen Shot 2015-06-10 at 9.22.55 AM

     

    First, I caught up with Gareth Rushgrove from Puppet Labs, who also runs the DevOps Weekly newsletter.  In this episode of the DevOps Leadership Series, Gareth explains why the importance of security tests within DevOps practices is going to be a big topic for years to come. Gareth anticipates that “In five years time we will look back on this and ask ‘why were we not always doing this’?”

    https://www.youtube.com/watch?v=ktpkmGv5gX4

     

    I then caught up with Helen Beal, Head of DevOps at Ranger4, where she discussed the importance of DevOps and security.  While the two ultimately need to work hand and hand, she voiced concerns about DevOps practices sometimes circumventing controls that are essential to a business’s safety. She also said that DevOps supports security in a number of ways: from making things consistent to relying on more automation.

     

    https://www.youtube.com/watch?v=W4Zs1SSjGFs

     

    Finally, I caught up with Justin Arbuckle, Vice President, EMEA & Chief Enterprise Architect at Chef. He discusses key trends he expects to see in over the next 9-12 months regarding compliance and security.  Justin explains that compliance as a core driver of DevOps is something that will start to shape our conversations over the next year, whereas the two have previously been seen as contradictory. He believes that we will see that high velocity organizations are able to improve compliance continuously, and tells us to look out for the changing role of the security officer in 2015.

    https://www.youtube.com/watch?v=ojEOqRJey2o

     

    Next up in the series, I head to the United States Capitol, Washington DC, for DevOps Days DC.

    NOTE: If you have missed any of the other videos from this series, you can find them here.  (We’re up to 15 so far).