devopsy.kinsta.cloud

Tag: engineering teams

  • 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.

  • Designing Engineering Teams for Scale

    Designing Engineering Teams for Scale

    As a senior engineering manager who has taken many companies from just a few engineers to entire teams at global scale in hypergrowth, I have learned quite a few lessons along the way on coping with growth and scale on a diversity of fronts. I put my thoughts down to help senior technical people with deep knowledge in code, system architecture and more, who would like to understand how to take their career to the next level. I hope this will provide some insights on how to design not only your systems but also your teams to support the business for scale.  This blog post is based on my keynote talk from DevOpsDays Tel Aviv 2018.

    What Do You Think About When You Hear ‘Scale’?

    Let’s start by framing the meaning of “scale.” When defining scale, the first thing that most technologists will likely think about is additional traffic or users. The first thing that comes to mind is likely distributed systems, event traffic, more clients using the same system and so on. This scale is well-known and you can find many excellent posts and talks on this subject and learn from many companies that went through the process of scaling their systems.

    But there are additional types of scale. Here’s how you, as a senior engineer, can learn to identify which one is relevant and how you can help your company tackle it.

    Scaling challenges are diverse, and if I had to categorize them into three primary categories they would be the three “T”s:

    1. Traffic
    2. Team
    3. Territories

    Let’s deep dive, and see what are the characteristics of each, the unique challenges from a technical perspective and how you, as a leading technologist, can help. More importantly, though, is how to avoid scaling-related mistakes like the ones I made and have learned from over the years.

    Scaling Challenge 1: Traffic

    We will start with the most commonly known scaling challenge: traffic scale.

    This one is probably the easiest to identify. You will start feeling growing pains when you see an increasing number of events coming into the system, a growing number of concurrent users and the number of registered clients, among other tell-tale signs.

    This will start to present a number of technical challenges; for example, services will fail to serve, there will be database performance degradation, exponential growth responses—sometimes 50x—from the AWS Elastic Load Balancing service and more.

    The most important thing when triaging your issues around traffic scale is to remember that the priority is to be ready to support more traffic so users will still be able to get served, even if there are many more users, so focus on anything that relates to maintaining uptime. This means you must be ready to scale the web services and all other real-time functionality for peak loads. To do so, auto-scaling is mandatory, as well as elastic real-time databases. Offline processes, on the other hand, can be delayed if needed and catch up asynchronously when the traffic load subsides.

    As much as I hate to say it, while we always need to be cognizant of technical debt and be sure we’re on track to closing these deficits, code quality and refactoring can take a lower priority at times of load, as you might actually find yourself rewriting services from scratch and you just might need different service architecture altogether.

    What about the team?

    Well, with the growth of traffic usually comes the need to add more team members, so a sufficient number of team members can focus on scaling the infrastructure, while you still have enough attention to work on the business road map. This is the right time to think “DevOps” and create dev tools so the work can be more efficient and you might be able to achieve more with fewer people.

    You will also need more money for your infrastructure services, and you need to be ready for that. Scale costs money, and traffic scaling is translated automatically to your data center or cloud provider’s monthly invoice. It might mean that you also have to start thinking about using cost-saving services and optimizing your usage.

    Scaling Challenge 2: Teams

    The second type of scale comes with growing pains of human capital: team scaling.

    While this may seem obvious, in many cases, companies tend to ignore the impact that the growing team has on the system itself.

    Hiring becomes a scaling issue when your team needs to double in a year. Even going from five to 10 people is significant growth. Many leading technologists tend to ignore this type of scale and look at it as a managerial problem. This is not true; if you see yourself as part of the R&D leadership you should take a prominent role in this scaling.

    These are several tech challenges for this growth:

    1. Additional functions might be introduced to the team. For example: I tend to hire more generalists as the first team members, and get more specialists when the team grows. In addition, QA engineers might be hired only after there is already a full team of developers and they might need different tools.
    2. In many cases, manual processes just don’t scale with growing teams. Things that used to be done manually on the production database, for example, might be OK when it is just you but should be automated when there are now four people working with you.
    3. In some cases, the system architecture should be changed to enable more people to work effectively. This is a big one: Your system architecture was working well for a small-sized team, but now that there will be many more hands working on the same code base it becomes much more complex to manage. Some companies take the approach of having the same code base for everyone and forcing the engineering quality by using code reviews, testing and more. Some teams decide to split a service into separate services, so each team will be in charge of a sub-service. I prefer to split services, as it makes team ownership more explicit.
    4. Knowledge sharing and best-practices should be formalized. From my experience, investing in very good first training pays off. The format that I usually use is on the job training, using a dedicated buddy from the team who guides the new team member on coding tasks, with increased autonomy. This method enables the learning of the system from the inside alongside business-related sessions, including self-reading technical material for relevant technologies. Avoid overly complex best practices and make the time to replace them with scripts or well-written instructions.

    The most important thing is for new people to be productive. It is crucial that each new team member can write code, test and deploy it, exactly the same as before. It doesn’t make sense to hire new people who are less productive.

    This is the right time to invest in a good automatic testing mechanism and good automatic build and deploy.

    You know your company best, and in some cases, team scaling comes as a result of traffic scaling. If this is not the case, then you might need to leave the traffic scaling aside at this point.

    You have to be very careful with team growth. In some cases, you may be able to use external services or automation to reduce team growth. For example, instead of hiring more DevOps engineers, you can consider using hosted solutions. It might cost a little more than the non-hosted solution, but it might save you valuable hours on maintenance.

    Scaling Challenge 3: New Territories

    The third challenge is territories. As a company looks to expand beyond its primary geographic region to additional regions, the new challenges arise not only with sales and organizational structures but also with technology. Let’s take an example of an organization currently serving clients in the U.S. and expanding to the EU:

    1. GDPR: in the U.S., California and New York were the first to establish GDPR-like laws, while EU countries have already implemented privacy laws.
    2. Language and culture: The EU has different languages, which might affect your product.
    3. In regulated environments, such as FinTech and HealthTech, the product can be different when moving from the U.S. to the EU.

    It is pretty straightforward to understand if you are facing territory challenges that are outside of sales and customer support when you start talking about considerations such as data protection and other regulatory considerations. Tech challenges can be different from company to company, depending on your business area:

    1. The location of your production environment. This largely was a performance issue and might still be the case when your system is highly sensitive to performance. In most other cases, there are other considerations to decide if and where you need additional data centers when expanding to new territories. It can be a result of the regulations and specific needs of your clients. In such cases, you need to specify the cost of having an additional data center for the business. This is not just extra money but also complexity and product needs that can be much more difficult, such as having the same user in two different environments at the same time while keeping everything in sync. In most cases, the legal team can find reasonable solutions to keep only one data center, and it will make your life easier. It is important to have this discussion and it is your role as a leading technologist to lead it.
    2. Data consideration. Different countries can have different regulations for data privacy and data protection. It might be easiest if you agree with the business people to keep the most strict rules for everyone.

    The most important thing is for you to understand what is really mandatory and what is more “nice to have” from a legal perspective and the regulators.

    In case you don’t already support i18n, this is the time. Try to avoid additional production environments, if they are not absolutely mandatory.

    Below is the way I break it down to try to analyze how to use technology for different types of scaling.

    Here are a few questions to help you understand how to identify your company’s unique situation.

    You should start by asking yourself, “Is this temporary, or here to stay?”

      • Do you see this trend going on for a few months?
      • Do you see this change supporting a significant amount of sales in the pipeline?
      • Do you think that entering into the new territory is just the first step before foraying into other regions in the world?
      • Does your team plan to double itself according to next year’s budget plans?

    If your answer is yes to most of these questions, then you are talking about scaling challenges.

    Now that we understand that we have a scaling problem, let’s understand the type of scaling. Go back to the three Ts and ask yourself:

    • Is it traffic?
    • Teams?
    • Territories?
    • Or maybe a combination of a few types together?

    Failing at Scaling

    I’ve had my share of scaling through the years. It is a lot of fun to work in a growing company and take part in the scaling process. However, in some cases, hindsight is 20/20 to understand you may not have handled it ideally. This has happened to me more than once, and I’m proud of my mistakes because they afforded me the opportunity to learn and grow.

    Let me share a few:

    1. Like many companies, LivePerson started with a monolith. It was a Java-based web application that handled all the incoming visitors’ traffic, as well as chats, operators and more. Around 2012, as the team grew and experienced quality challenges; we collected all the unit tests together with some additional integration tests and decided that it should run as part of the build. The build process would compile the Java code, perform additional steps and run the entire test suite before it declares failure or success. It was a great idea and enabled us to see not only that the code compilation went well but also that the tests are running and nothing breaks. The only thing that ruined the party, though, was that the entire process took 30(!) minutes. It meant that instead of waiting 10 minutes for the compilation, we added another 20 minutes every time a bug fix was deployed to the testing environment. It was a great idea, but it added even more time to the “already too long” build process.
    2. At AppsFlyer, we had a real-time reporting system from the very first day. It was one of the more important business offerings and marketing people would buy this service to analyze their campaigns as they go. This system was built when the company had just a few small clients and was based on MongoDB in a sub-optimal solution by increasing counters. As the company had more and more clients—particularly more huge ones—the system was not holding up with the traffic very well and we experienced outages once every few weeks. We added more compute power, split the cluster and more. This gave us some air for a few more months, until one day two of our biggest customers couldn’t fetch data for the entire week(!), and could only see today’s data. That was the moment I understood that I made a mistake and that we had to build the next generation in time.
    3. And here is one scaling mistake I made in my house … My ceiling has collapsed after three days of non-stop rain last year. My roof was stable for many winters, but it got older and eventually couldn’t keep up with the nonstop rain. We found ourselves putting bowls under the ceiling and cleaning the floor from the rainwater at 3 a.m. Saturday. It turns out, you can also have production problems at home.

    Be Brutally Honest!

    Now it is the time to be honest with yourself!

    Do you find yourself saying things such as, “We can’t do this task”? “Our infrastructure can’t support the new challenge”? Evolving into a leading technologist, you should be able to communicate the complexity in business terms and come up with alternatives and trade-offs.

    This is a topic for a whole new article, but it is important to open the right discussion with the business and express the technical needs in words that will enable non-technical people to understand. Saying things such as “The current system doesn’t support an additional payment method, and we will need to spend time to refactor it before going to EU,” or, “We see that additional clients are planning to use the product in the coming few months, so we will need to spend time to enhance the architecture and maybe replace the database technology to be able to support the 10x scale,” is better than just saying things like “This is hard.”

    It is crucial for the business to understand the complexity and trade-offs before taking any decision, and it enables you to impact the decision. It also provides you with inside information about what trade-offs are acceptable and what cannot be sacrificed under any circumstance at your company. You need to be very careful here and put on the table the technical changes that hold the company back. The ones that are very cool but not really crucial for the scaling should wait.

    Plan and Execute

    Once we have identified whether this is long-term scale and the scale type, and mapped the gaps, now it is time to create a plan and execute it.

    I’m not going to say this is an easy feat, but you start by taking small steps. As always, technology is the enabler for the business’s growth, and your plan should reflect this. It should contain all the scaling-killers and only them. It means that in some cases, you have to put aside the industry best practices for a later stage and stick with things that still work for you. For example, the monolith that your company started with might still be valid if it is not your crucial scaling point. Splitting it can be pushed to a point in time when it becomes the crucial scaling-killer.

    There is no magic, just constant hard work.

    Finally, make sure you don’t perform too many changes at once, as there are always unplanned things that will break at scale. Also, don’t forget simple but life-changing things such as automation and auto-scaling, talking to other senior engineers who experienced the same scaling before to learn from their mistakes and plan for small iterations.

    Working in a fast-growing company is a lot of fun. You are probably facing different technology scaling challenges, which provide opportunities for growth and learning and some adrenaline boosts. I hope this post helped you to understand not only how to help your company, but also how to scale your career.

  • Clubhouse Aims to Simplify Software Project Management

    Clubhouse Aims to Simplify Software Project Management

    Clubhouse Software today announced it is adding a Clubhouse Iterations module to its project management application to make it easier to plan sprints involving product and software engineering teams.

    Mitch Wainer, chief marketing officer for Clubhouse Software, said Iterations will be included as part of its project management application service, which aims to bridge the divide that often exists between software development teams and the lines of business for which they are building applications.

    Wainer said the company’s namesake project management software makes it easier for non-technical professionals to participate in the same project management workflow as a development team, rather than requiring them to become conversant in a project management application designed for software engineers, such as Jira. Clubhouse’s approach eliminates silos that get created when two teams within the same organization rely on different project management applications, he said.

    Clubhouse Iterations goes a step further by surfacing what teams need to focus on as priorities and timetables change within a specific project, added Wainer.

    Clubhouse Iterations allows users to define sprints using start and end dates, and the tool then sends reminders so the team can reserve time to focus on specific projects, he added.

    Organizations that have successfully embraced DevOps almost invariably seek to extend those processes beyond the software development team. In theory, at least, the entire business should aspire to become more agile. However, the project management software many DevOps teams employ today is too complex and intimidating for the average business executive. Rather than forcing business users to learn how to master these applications, a case can be made for a more intuitive set of project management tools for both software development teams and the product managers they ultimately serve. Wainer said Clubhouse is already being used within 2,000 organizations to address that issue.

    Wainer also noted the Clubhouse Software also has no bias as far as continuous integration/continuous delivery (CI/CD) platforms are concerned. Clubhouse is designed to integrate with multiple CI/CD platforms via application programming interfaces (APIs) to enable the development of custom workflows that include, for example, integration with real-time conversations occurring via the Slack service.

    Next up, Wainer said Clubhouse intends to improve the search capabilities it provides on the platform and offer more sophisticated reporting tools.

    In the meantime, the rise of DevOps would not be possible without the capabilities enabled by project management applications. But the agile nature of DevOps processes is forcing providers of project management software to make their applications both more dynamic and accessible. Those advances, in turn, make it easier to bring new members on board to the DevOps team.

    Project management software may not always be viewed as the linchpin around which most software development processes are constructed. Without some form of project management application, however, most DevOps processes would have devolved into utter chaos a long time ago.

    — Mike Vizard

  • 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

  • There is No ‘I’ in Team: Transitioning Engineering Teams into a DevOps Model

    There is No ‘I’ in Team: Transitioning Engineering Teams into a DevOps Model

    As the pace of development and business continues to scale, teams need an agile and collaborative work environment to succeed. Moving to a DevOps model is a critical part of setting your engineering teams up to succeed, but making the transition can be challenging for many companies.

    What’s the deal? – Why you need a DevOps model

    DevOps is a movement in the software world  that focuses on collaboration between developers and operations, customer empathy and infrastructure automation. In traditional models, developers write code and then hand it to operations teams to deploy and and run in a production environment. This often leads to a lack of ownership between the two teams (“It worked on my local box!”) as well as a slower pace of development. In a DevOps model, by contrast, the two teams work closely with each other, and toward common, customer-facing goals – developers take ownership of their code even while it’s in production, and operations teams build tooling and processes that help developers write, test and ship code faster and more easily.

    By breaking through traditional developer-operations walls, development happens faster and with more customer empathy, ultimately resulting in a better customer experience and a happier team. Rather than seeing the other team as a gate or obstacle, if done right, developers and operations see each other as teammates working to deliver value to the customer and business.

    Unfortunately, introducing DevOps culture and practices to your company isn’t easy. Big changes to long-entrenched silos can generate resistance, and business leaders are often scared of the costs that come with change. To combat these concerns and hesitations, we’ve highlighted a few tips for transitioning to a DevOps model.

    Start with Collaboration – what’s working and what’s not?

    At the heart of DevOps is improved collaboration between your Operations and Development teams. You’re probably not starting from a vacuum, though – look at and talk about the best examples of how your operations and software development teams are collaborating today. Are there particular dev/ops groups that are already working tightly together, championing great communication or doing joint planning? Focusing on what is already working and how to make it work better, rather than what’s broken, keeps things positive and more likely to succeed.

    You could set up a group brainstorming session to discuss, or have one-on-one conversations with individual team members, depending on the format that you think will help people open up more easily. This article highlights opportunities for collaboration across the application delivery lifecycle, and could provide a useful framework for asking questions and identifying opportunities.

    In addition to the state of collaboration, you’ll also want to look for process successes and breakdowns in how you deploy and maintain applications, services and infrastructure. Identify the biggest opportunities for improvement – do your builds and test take hours? Are your 20 development teams all competing for the same three staging environments? Being able to quantify the impact of these pain points can help defend the transition to business stakeholders who may not have as much on-the-ground context about your teams’ pain points.

    It’s also important to build an understanding of the different perspectives operations and development teams may have. If your organization has traditionally been very siloed, thinking about other teams’ goals when planning and prioritizing may be a new mindset. Sharing each team’s objectives and what success looks like for them can help build this understanding and empathy. Focus on transparency (a framework like OKRs can help) to avoid conflict from mismatched assumptions about priorities.

    Create a plan  

    Once you’ve identified opportunities to improve the collaboration and workflow between developers and operations, it’s time to create a specific plan. Pick key opportunities and identify the first few steps to make a difference. Courtney Nash recommends starting with a group of people who are receptive to the vision and picking a small product or service as a test-bed. When implementing big changes, it helps to start small and scale from there after proving success.

    Engineers are not always known for their people skills, but transitioning to DevOps is as much about people as it is about process and tools. Throughout this whole process, you’ll want to be investing key stakeholders in your team and company in the transition. Change management sounds awfully corporate, but at it’s heart, it’s about making sure you build support for your projects and goals by collecting input from key stakeholders: gathering their feedback and goals, sharing and re-shaping your plan based on their input, and communicating your progress with them. It’s always easier to work in silos with people that already agree with you, but for lasting change, you’ll need to invest in building support across teams and throughout your organization.

    Finally, pick realistic timelines and objectives. It’s important to note that some effects of the change may take longer to realize as people ramp up on new tools and ways of working. Don’t discount or neglect the amount of time required for training, and try not to be fazed if the first project you pick doesn’t turn out to be a good one. As Courtney Nash mentions, Nordstrom.com realized their first project was not ultimately the right one to start with. Importantly, they didn’t give up, instead choosing a different, better-suited application.

    Measure and reflect

    While it’s rare for timelines in complex systems to happen exactly as planned, it’s important to timebox your work so that you can measure and reflect on how it went.

    After the specific milestone you’ve chosen, bring stakeholders together and run a retrospective. There are a lot of great resources out there to help with good retrospectives, but regardless of approach, make sure you make an intentional space to look critically at your results, celebrate success, and think about how you’d like to change or iterate the process for the future.

    When reflecting on progress, it’s important to be candid and honest while assuming the best intentions of your teammates. You are guaranteed to make mistakes – that’s inevitable with any new process – but remember (and help others remember) that you’re all working toward the same purpose and share a common set of values and goals.

    Don’t give up

    Adopting DevOps is a big change for an organization, and there will be bumps along the road. At the end of the day, though, the rewards of tighter collaboration among teams and a more empathy-driven engineering culture can be really powerful, and will show in product quality, velocity and team morale.