devopsy.kinsta.cloud

Tag: culture

  • Using AI to Shift Production Wisdom Left

    Using AI to Shift Production Wisdom Left

    In my recent blog, Revolutionizing the Nine Pillars of SRE with AI-Engineered Tools, I indicated that AI could assist in shifting the wisdom of production to the left. In this blog, I’ll explain in more detail how AI-engineered tools can be used to improve the pillar that I call SRE culture.

    AI Use Cases for Shifting SRE Culture Left

    Shifting the “wisdom of production” to the left is all about bringing production considerations into the development process as early as possible. Here are some use cases where AI can help facilitate this shift, along with specific challenges and AI tools that can assist.

    Predicting System Behavior: Predicting system behavior under various conditions can be difficult, especially as systems grow more complex. AI can help by analyzing historical data and predicting system behavior. Tools like Splunk can use machine learning to provide these predictions and facilitate earlier decision-making.

    Automated Code Reviews: Manually reviewing code for potential production issues can be time-consuming and error-prone. AI can automate this process, identifying potential issues more quickly and accurately. Tools like DeepCode or Codota use AI to analyze code and identify potential issues.

    Security Vulnerability Detection: Identifying security vulnerabilities early in the development process can prevent costly and damaging breaches in production. AI can analyze code to identify potential vulnerabilities that might be missed by human reviewers. Tools like Snyk or WhiteSource can help with this.

    Performance Optimization: Predicting how code changes will impact performance can be challenging. AI can analyze changes and predict their impact on system performance. Tools like Akamas leverage AI to automate the performance optimization process.

    Dependency Analysis: Identifying how changes in one part of a system will impact other parts can be difficult. AI can analyze system dependencies and predict the impact of changes. Tools like FOSSA can help in automating dependency analysis and identifying potential issues.

    Resource Allocation: Predicting resource needs for new features or changes can help prevent resource shortages in production. AI can analyze resource usage patterns and predict future needs. Tools like Turbonomic or Densify use AI to optimize resource allocation.

    User Experience Optimization: Predicting how changes will impact the user experience can help prevent negative impacts in production. AI can analyze user behavior and predict the impact of changes on user experience. Tools like FullStory or Crazy Egg can provide AI-driven insights into user behavior.

    RoadMap to SRE Wisdom

    A practical implementation roadmap for introducing AI tools to help shift wisdom to the left may include the following steps.

    Identify Needs and Goals: Start by identifying the areas where shifting wisdom to the left could have the most impact. This might include areas where issues are frequently discovered late in the development process or where manual processes are time-consuming or error-prone. Define clear goals for what you hope to achieve by introducing AI in these areas.

    Research Tools: Once you’ve identified your needs and goals, research the AI tools available that could help meet those needs. Consider factors like the tool’s capabilities, integration with your existing systems, cost and support options.

    Evaluate Tools: Based on your research, select a few tools to evaluate more thoroughly. This could involve setting up trials or demos, speaking with the tool’s developers or other users and assessing how well the tool meets your needs.

    Pilot Implementation: Once you’ve selected a tool, start with a pilot implementation on a small scale. This will allow you to learn how to use the tool, identify any potential issues or obstacles and understand the tool’s impact before rolling it out more broadly.

    Training: Provide training for your team on the new tool. This could include formal training sessions as well as ongoing support as they start using the tool.

    Monitor and Adjust: After the tool has been implemented, monitor its use and impact. This could involve tracking metrics related to your initial goals, as well as soliciting feedback from your team. Use this information to make any necessary adjustments to your use of the tool.

    Expand Use: Once you’re satisfied with the results of your pilot implementation, expand the use of the tool to other areas of your organization. Continue to monitor its use and impact and make any necessary adjustments.

    Repeat: Technology is constantly evolving, and there may be new tools or features that could further improve your ability to shift wisdom to the left. Periodically revisit your needs and goals, and repeat this process to continuously improve your processes.

    Summary

    Shifting the wisdom of production to the left is an essential strategy for modern IT organizations, but it’s a journey that requires thoughtful planning, the right tools, and a commitment to continuous learning and improvement. As we’ve explored, there are several compelling use cases for leveraging AI in this transformative process. Whether it’s predicting system behavior, automating code reviews, detecting security vulnerabilities, optimizing performance, analyzing dependencies, managing resources or enhancing the user experience, AI tools are helping organizations tackle these challenges more efficiently and effectively.

    While embarking on this journey may seem daunting, a well-crafted implementation roadmap can help make the process manageable and rewarding. By identifying specific needs and goals, researching and evaluating the right tools, piloting their implementation, providing comprehensive training and consistently monitoring and adjusting their usage, organizations can successfully adopt AI tools to shift the wisdom of production to the left. With continued effort and commitment, this transformation can lead to more informed decision-making, more efficient processes and, ultimately, better outcomes in production.

  • How Open Source Can Enhance Developer Experience

    How Open Source Can Enhance Developer Experience

    Developer experience (DX) is becoming more and more of a competitive advantage among developer-facing tools and platforms. A great developer experience that’s easy to follow and implement can truly help a software tool stand out from the crowd.

    Simultaneously, open source software is all the rage. In fact, a recent StackOverflow survey found open source software (OSS) to be, by far, the most revered and proven technology trend.

    With that in mind, what are the synergies between developer experience and open source? And how can building in an open source format aid the developer experience for your public-facing toolsets and internal development platforms?

    I recently met with Adam Frank, SVP of product and marketing at Armory, to explore the state of developer experience and open source adoption. According to Frank, open source can bring numerous DX benefits. Below, we’ll explore these areas and consider why organizations might benefit from adopting more open source within their developer-facing initiatives.

    The State of Developer Experience and Open Source

    So, what is the state of developer experience, and why is it important now? Well, DX is continually leveraged to help improve agility and competitiveness in the market. In addition to granting differentiation, DX also enables more flexibility, helping users switch from one tool to another if necessary.

    “Developer experience is at the forefront right now because technology and change are moving faster than ever before,” said Frank. “Companies need to focus on DX as a competitive advantage to survive and thrive.” At the same time, open source can help organizations move quickly and iterate more efficiently.

    Yet, historically, open source has not been associated with fantastic DX. Most of us have at least one horror story of an open source project simply going belly-up without warning. It’s common for an OSS tool to lack comprehensive documentationor suffer from a lack of funding for ongoing maintenance, zero customer support and deprecated modules. Some tools that developers directly download and contribute to may not possess a quality DX emphasis, says Frank.

    However, the status quo for OSS has undoubtedly evolved over the years, he adds. Nowadays, there are more established groups, like Linux Foundation’s Cloud Native Computing Foundation (CNCF), with specific Technical Oversight Committees (TOCs) to oversee individual projects. The maturity of OSS ownership now ensures core projects stay relevant and receive continual support—not to mention ongoing developer experience enhancements.

    On the other side, OSS is often absorbed by a platform team to enable their internal developers to move faster or ship more code, says Frank. From this perspective, open source communities give platform engineering the opportunity to contribute back to the project, helping them solve deeper-level problems that are more specific to their environments.

    How Open Source Can Enhance Developer Experience

    Not all IT leaders are sold on the idea of building in a transparent, open source model. Yet, this enhanced transparency can bring dividends in the long run, especially where developer experience is considered. Frank shared some of the benefits of adopting open source.

    Receiving Feedback From The Community

    “As a product manager, you want as much feedback from your users as you can gather,” said Frank. Receiving user feedback is a great way to fix DX issues, and OSS gives you that on a larger scale. By adopting open source, you benefit from collecting insights from your customer base and the developer community at large. This can translate into a broader range of use cases, which can significantly improve projects and overall experience.

    Increasing Ecosystem Transparency

    Building in a more transparent and open fashion so that everyone has the ability to submit pull requests can also help you work together with potential partners. This makes it easier to develop third-party integrations that ensure the broader ecosystem can work together. By decreasing the barrier to entry through OSS, you provide others with the ability to solve more problems around developer experience.

    Streamlining the Developer Toolchain

    “Developers want to innovate; they want to solve problems,” said Frank. Open source can also help expose inefficiencies in the developer toolchain and, notably, many open source CI/CD tools are often leveraged to automate deployment and increase efficiency. The end result is that developers can focus on innovating their own competitive advantage. “Making the deployment aspect of the developer lifecycle really seamless can significantly improve their experience,” he said. Therefore, any tools or extensions around CI/CD are an excellent area to consider open-sourcing.

    Increasing Flexibility

    Another benefit of the open source model is that you have far more flexibility than off-the-shelf proprietary software. As a customer, you don’t have to wait to submit enhancement requests. With OSS, you can fork a project or quickly collaborate with the maintainers. This equates to making fixes far quicker and providing the ability to customize developer experiences to the tasks at hand.

    Best Practices to Ensure Open Source Improves DX

    Open source provides many key benefits that can enhance software development and delivery. But, this should be taken with a grain of salt, as best practices still must be followed to ensure open source enhances, not hinders, developer experience.

    For example, Frank mentions that simplicity should be a guiding light. “Have simplicity for the user experience design in the forefront of everything you’re building and thinking about,” said Frank. Adopting simplicity should help ensure developer-facing materials are structured well and documented in an easy-to-comprehend manner.

    On that note, open source projects will require standards around areas like good documentation and well-written APIs that abide by contracts, said Frank. Anything less will hinder developers and confuse them with disparate data formats. On that note, he has witnessed OpenTelemetry emerge as a common way to unify data that systems produce with standard formatting, which increases the observability of these environments.

    Lastly, it’s critical to hire talent with experience in open source. Bringing in folks that have knowledge of how OSS communities operate will make onboarding easier and encourage safer open source security practices as well.

    What the Future of DX and OSS Holds

    Open source appears to aid developer experience in many ways, from driving more innovation, opening software up to feedback and developing a closer-nit developer community. But what does the future of developer experience and open source look like?

    According to Frank, we will likely see increased data standardization that makes it easy to work with various projects and data formats. OpenTelemetry, for example, makes aggregating logging easier. We’ve also seen standardization around OpenAPI Specification for describing web APIs. Another example is FinOps Foundation’s FOCUS specification to unify cost analysis.

    Open source tends to leverage open source. And as the industry continues to coalesce around open standards, we’ll likely see more robust, compatible layers of abstraction emerge throughout the market, Frank predicts.

  • Things We Should Acknowledge, Part Three: Remotely Good

    Things We Should Acknowledge, Part Three: Remotely Good

    This installment of my off-and-on “Things We Should Acknowledge” series is going to focus on an area that most DevOps teams are skirting, but increasingly will not be able to: Remote work.

    For background, I have worked remotely for decades; my experience spans Fortune 100s, publishing companies and startups—and that’s just full-time work. I’ve worked for a ton of vendors and publications as a contractor, too.

    I will start by making clear my stance on remote work—a stance I’ve happily talked with people about since long before COVID-19 measures made remote work a regular thing. You either thrive working remotely or you wither. There is a small group in the center that can make it work with some effort, but inevitably that effort becomes routine and those in the middle become part of one of the two groups.

    Because people drift toward one of two camps, we get the currently popular stance on, well, everything, which is polarization. But we shouldn’t. Just like positions and people that should/should not be in meetings to resolve problems or people who should/should not have direct reports, we should consider positions and people that remote work is best for.

    And post-pandemic, the vast majority of DevOps roles can be performed effectively in a remote position. That leaves us with the people question. Mostly. Note: There are organizations and roles that need to be local; those are not a topic of this blog. The 99% of other roles/orgs are.

    This topic gets really ugly, pretty quick. If a significant portion of every organization goes remote, city centers in several metropolises will die. That is not conjecture; you can go look into commercial real estate in any information worker hub. It is in a massive slump (and calling it a ‘slump’ is being nice), with occupancy circling the drain and property values plummeting. That is largely because formerly high-demand real-estate is not needed in the volume it was.

    That should not be the concern of any given corporation. It is the corporation’s responsibility to see to shareholder value, not the real estate market (unless they are invested in real estate, which many large organizations are). But if orgs are keeping any offices downtown, it becomes an issue about safety. In other words, it’s about if the collapse of the market means the offices become less safe for workers, regardless of investment. This is not a decision-making bullet point, but it does inform actions. I have a ton more to say on this topic, but it’s a side bit, so for now, this is enough.

    For people who thrive working remotely—and a lot more people now know that about themselves than knew that five years ago—being forced into the office is a non-starter. I have been offered astounding positions at organizations on both coasts over the years, but the ones that came with the “…and you have to move here” demand—I immediately turned down. More people are doing that; some of them truly great employees.

    So, like it or not, DevOps teams are going to have to consider whether all being in the same building is more important than hiring the most qualified co-workers. That is a team/management/corporate decision and always has been. I consider any “We all do this one thing” stance—from “We’re an X shop” to “We don’t do remote” to be a negative, but I don’t have to make these decisions for an organization.

    It does need to be part of the conversation, though. Because the work environment is unlikely to return to pre-pandemic standards, no matter how much some want it to. The more organizations are willing to work with both remote and on-site employees, the more options those employees—your potential coworkers—have. That changes the dynamic, even in light of recent layoffs, because the new job hunt is not tied to “local” anymore.

  • Are you Being ‘Nice’ to Your Developers? Think Again

    Are you Being ‘Nice’ to Your Developers? Think Again

    As a developer, you’ve learned your craft. From your fingers comes the magic that builds the applications that run the world. You can literally create something from nothing! And not just software programs. You can create value that means revenue for your company. You’re a revenue machine — no, you’re a god, creating anything that’s needed! That is, you could be if you could spend all of your time writing that magical code. But this dream is not so simple. If you’re like most developers, you’re spending way too much time on other things, such as:
    ● Meetings
    ● Dealing with interruptions
    ● Security hassles
    ● Operations
    ● Debugging
    ● Fighting with infrastructure
    ● Burnout

    Every minute you’re dealing with any of those, you’re not making magic. Because you’re human, that is going to make you unhappy.

    If you really are a developer and not just imagining you are, you already know all of this. Now let’s turn our attention to those of you who are responsible for developers. Because it’s your job to make them happy.

    Yes, it is, if you want them to keep working productively for you and add value. Luckily, it’s within your reach to do so. It will benefit you, add value to the organization and, most importantly of all, the employees themselves.

    Simply put: If you want to get value from your developers, you have to be nice to them. If you expect them to pour themselves into you and into the company, you must first prioritize them and invest in them. Success can only be realized and achieved by a happy balance of developers who are motivated to create.

    Do you know who feels more motivated than anyone else? Who will always go above and beyond?

    Those who are appreciated.

    So let’s get started.

    Increased Productivity and Value

    The most obvious issue is productivity. The reality is that software development can be an arduous mental task, and when developers are unhappy, it will inevitably affect their productivity—especially when they spend mental cycles on things that are not directly related to the task at hand.

    Even if they’re not spending work time searching for another job (or quiet quitting), they’re probably thinking about what could be different and mentally grumbling about it every time something comes up that irritates them.

    By treating developers well and eliminating those annoyances as much as possible, you prevent that problem and get 100% of their attention.

    And there are other productivity benefits, as well. When developers trust their company and their co-workers, it fosters greater collaboration between those developers and business stakeholders. It also engenders greater creativity, which can lead to innovation and value above and beyond what you are expecting them to deliver.

    Retention

    The most obvious issue when it comes to developer happiness is, of course, retention. After all, if you’re not nice to your developers, you should expect them to leave for other jobs. If the Great Resignation taught us anything, it’s that it is human nature to move along if dissatisfied.

    That may not seem like a big deal to you, but think about the implications if your developers are leaving in droves. Never mind the turnover costs, what about the inevitable delays as you bring new developers up to speed? Hiring and training are arduous, time-consuming endeavors. And if turnover is bad enough, you may never be able to actually complete anything because nobody ever gets a chance to build up a good head of steam.

    Compare this to a company with a dedicated team of happy developers who are motivated to grow and innovate for themselves, their team and your organization.

    Which organization do you think is going to come out on top? Yes—the organization with the happier team of developers is probably going to have a competitive advantage—and a big one!

    When developers are happy, they are likely to be loyal to your company. That loyalty means they stay long enough to become experts in what you do, making them more likely to create the kinds of innovations that move the company forward for added value.

    But most of all, can you really afford to have your best employees leave and take all of the knowledge they’ve gained with them, potentially to a competitor? Probably not.

    Maintaining a Good Reputation

    All of this adds up to reputation; get a bad reputation in the developer world and it is going to be hard for you to attract top talent. In a world where technology changes so fast, it’s already difficult to find developers who have stayed with one technology long enough to become experts. You need to take advantage of every tool you can to make it easier. Your reputation can be one of them—if you treat your developers right.

    But there’s another reason to protect your reputation among developers: It could easily bleed over to your reputation among your customers. If you’re a big company, word of your treatment of developers may spread. If you’re not so big, and you have enough developer turnover, some of your former employees may work for prospective customers or know someone who does.

    Today, customers are trying to be socially responsible by buying from companies that ‘do the right thing.’

    Without much effort, you can be one of those companies by trying to foster developer happiness. Ultimately, it’s not that difficult.

    How to be Nice to Your Developers

    Fostering developer happiness doesn’t have to be a hugely expensive proposition. It’s not always about huge paychecks (though they do help smooth out some rough edges). Some things you can do to be nice to your developers include the following.

    1. Provide what they need: Developers should be able to spend as much of their time as possible actually coding; make sure they have the tools that they need so that they’re not having to improvise or struggle with creating infrastructure. For example, engaging a ZeroOps partner can take some of this off their plates.

    2. Eliminate distractions: Even in ideal situations, it can take as long as 20 minutes for a developer to get back into their train of thought every time they’re interrupted. Try to provide an environment with as few distractions as possible.

    3. Foster a training-centric culture: Developers need to feel as though you have their best interests at heart, and one way to do that is to help them learn new skills. And there are multiple benefits for you: For one, it’s much easier to train your existing people in an in-demand technology (such as Kubernetes) than it is to hire someone who already has those skills. For another, training your entire team in these new technologies can unlock creative ways of solving problems.

    4. Help developers understand how their work relates to the customer: While it can be tempting to expect developers to simply do what you ask them to, when they understand why they’re doing it, they’re much more likely to feel invested in the work.

    5. Listen to ideas: Your developers are at the heart of what you’re trying to do. It’s very possible that they have a new way of doing something or an idea for something that could help your company. Even if you don’t end up going forward with the idea, your developers need to know that you respect them enough to listen.

    6. Respect work-life balance: Developers have a reputation for working long hours and many even take pride in it. But it’s not always the most efficient way to get things done. A tired developer works more slowly and makes more mistakes. Be flexible and make sure that you’re not overloading your people with more than they can reasonably accomplish. If your developers have to work 70, 80 or 100 hours a week to meet deadlines, you either need to hire more people (if you can find them) or find a way to partner with other organizations to take things off their plate. (See number one).

    All of these things make for a positive work environment that enables your developers to work their magic for you, day in and day out, making something from nothing and moving you forward the way nobody else can.

  • The Business Case for DevOps Culture

    The Business Case for DevOps Culture

    Culture is nebulous. It encompasses all the behaviors and attitudes of an organization, from overarching business values down to the individual actions of an employee. Because culture is transient, it’s unique to every business, feels difficult to change and is even harder to measure. This can make it frustrating to see DevOps research continuously name ‘culture’ as the critical factor for DevOps success.

    Many teams are left wondering what a ‘successful’ culture looks like and struggle to pinpoint what changes they should make. While there isn’t a one-size-fits-all approach to cultural transformation since every business is different, there are three key traits of high-performing DevOps teams: Buy-in to the DevOps process, collaboration and continuous improvement.

    But even once you’ve identified how your team can embody these traits, it can still be difficult to put forward a case for improving culture when it’s so difficult to measure its returns. By linking each of these traits to measurable impacts on the wider business, it’s possible to make a strong business case for improving your DevOps culture.

    Buy-In Makes Your Business More Resilient

    No organization can foster a successful DevOps culture without buy-in from the whole team. Buy-in not only encompasses an understanding and acceptance of the DevOps process but is also a commitment to getting it right.

    Without cultural buy-in to the DevOps process, team members are more likely to circumvent established procedures. Following a DevOps process should overcome unnecessary downtime and failed releases, but neglecting the proper release management strategy will stop your team from seeing these improvements and hinder your ROI.

    Team buy-in to DevOps makes your release process far more resilient. With a common appreciation of and investment in DevOps, teams are far more likely to follow the planned and robust process. This attitude allows businesses to see far higher ROI. For example, Veolia, the energy and utilities giant, secured a 500% return on their DevOps investment within one year of buy-in to a new approach. Team buy-in is the first step you need to take in improving your DevOps culture—it’ll ensure the technical resilience of your processes necessary to secure ROI.

    Collaboration Makes Your Business More Efficient

    DevOps doesn’t just encourage collaboration between Dev and Ops teams—it encourages all team members to work together across functions and share responsibility.

    When only one team member has the expertise or responsibility required to move through a stage in your DevOps process, there’s a single point of failure. If this team member doesn’t have the capacity to unblock others, then the process is slowed and time is wasted. Collaboration and knowledge-sharing can overcome this bottleneck by empowering team members to handle a greater scope of the process. This avoids the significant costs that come with increased labor and missed opportunities by removing the pressure on individuals and drastically increasing the efficiency of the whole system. You’ll see an accelerated project delivery, which will be faster in getting value to your end users and see quicker ROI.

    Further, collaboration across the entire release process encourages all team members to remain mindful of compliance, which ensures you’re practicing DevSecOps at each stage of your release. Rather than handing development over to the dedicated compliance team once it’s complete, shared responsibility ensures that it’s baked into the DevOps process, saving time that could be needlessly spent at the end of development reworking to meet compliance stands. In the 2022 State of Salesforce DevOps Report, teams who self-reported as ‘excellent collaborators’ managed to avoid data and metadata loss in that year’s DevOps process, whereas only 25% of very poor collaborators could say the same. Excellent collaborators were much faster to restore when needed and significantly more likely to state that backups were their responsibility.

    To sum up, collaborative development teams are better at supporting the business growth needed to draw in customers. You’ll be able to sustain this growth, as efficient and secure releases will improve customer retention.

    Continuous Improvement for Your Team and Business

    Many teams only think about digital transformation when their process begins to fail, meaning the necessary changes require a disruptive overhaul of their whole system. Teams that nurture a culture of continuous improvement will make incremental improvements to their system, which avoids drastic ad-hoc changes and ensures the business will see continual value from gradual tweaks.

    It’s difficult to identify a singular ‘best DevOps system,’ as best practices are constantly shifting, but it is easy to realize that something could work better. Teams that reflect on their own systems and keep abreast of the latest tech trends can continually implement process improvements that amount to significant adjustments in the long term. This ongoing optimization of the DevOps process means no stasis and no need for disruptive and costly upgrades every few years.

    Developing your own team members not only creates a better DevOps process but also empowers team members to fill knowledge gaps, lessening the need for costly expert hiring or consultancy. Further, hiring and onboarding is a huge cost, which can be reduced by the morale and retention boost that comes with upskilling and collaboration. This will be critical as companies look at hiring freezes in the upcoming recession.

    Proving that small behavioral shifts can help maximize DevOps ROI will strengthen your business case for DevOps culture and create an agile team that can adapt as the landscape changes. Eventually, your DevOps ROI will become synonymous with your culture.

  • Tools and Strategies to Drive a Developer Culture of Collaboration

    Tools and Strategies to Drive a Developer Culture of Collaboration

    Agile methodologies such as DevSecOps have instilled collaborative habits in many development teams. But developers still struggle to work effectively with other stakeholders in the development process. And hybrid work environments have made collaboration that much more challenging.

    In fact, across departments, employees cite collaboration issues among the chief difficulties of hybrid work, recent research shows. Workers experience deficits in team collaboration, working relationships and connection with the organization’s culture.

    A key problem for developers is connecting information silos as they interact with quality assurance (QA), site reliability engineering (SRE), product management, and lines of business. Developers need to span their own data chasms, too, as they use a wide range of siloed technology tools. In fact, 68% of developers encounter a knowledge silo at least once a week. It’s no wonder they say their two biggest challenges are fragmented information (46% of respondents) and lack of tool integrations (45%).

    There are enough stumbling blocks that your development teams probably aren’t achieving a true culture of collaboration. A culture of collaboration means that collaboration is the default mode of work–with cross-functional teams aligned, team members engaged and productive, and projects consistently achieving desired outcomes.

    As much as collaboration is built on human relationships, technology can help, especially in hybrid work environments. In particular, a collaboration platform purpose-built for technical and operations teams is fundamental to building a developer culture of collaboration.

    Automation + Integration = Collaboration

    Computers are very good at performing repetitious tasks quickly, accurately and consistently. Humans are not. They are, however, well-suited to creative activities and qualitative decisions.

    An effective collaboration platform will automate workflows so that software handles rote tasks. Team members are then freed for deep conversations that lead to better decisions and outcomes.

    Playbooks are a great way to leverage automation to improve collaboration, and your collaboration platform should include them. Playbooks are essentially digitized checklists that, with a single click, route workflows through predefined steps to complete a task.

    For example, it’s not uncommon during development for a code issue to be identified that needs to be escalated for resolution. Typically, this involves redundant texts, emails and phone calls to identify the right decision-makers, plus multiple manual steps for reviews, approvals and status updates across stakeholders and conversations.

    That can all be automated in a collaboration-platform playbook. A single click can launch an automated process to escalate the issue to appropriate team members. Workflows take place in the background, quickly and accurately, while developers continue with their collaborations.

    But developer collaboration isn’t only hampered by manual tasks. It’s also held back by a lack of integration across software tools. Developers, QA specialists, business analysts and other stakeholders use many purpose-specific technology tools. These range from Google Docs to Microsoft Excel, from Figma to Jira to GitLab. So many standalone products used by so many teams result in capability and data silos.

    A useful collaboration platform will unify these tools under a single pane of glass. That way, all team members can continue to work with software that’s purpose-built for their needs, yet all can benefit from integrated access to tools in one context. Combining disparate capabilities in a common context lies at the heart of good collaboration.

    Secure and Collaborative

    Of course, any development project involves intellectual property (IP) and other sensitive data that your organization must protect. It’s imperative that your collaboration platform provide strong security and access control.

    General-purpose collaboration products typically are cloud-based, meaning software-as-a-service (SaaS) offerings hosted by the vendor. That doesn’t always meet the needs of industries such as finance and the public sector that must comply with strict regulatory requirements for data protection.

    A collaboration platform for technical and operations teams should offer an on-premises option. That way, you can retain ownership and control of sensitive data.

    This level of security does more than simply safeguard your IP. It also encourages collaboration because team members know they can communicate and work together freely without running afoul of internal policies or external regulations. Built-in access controls should ensure that each team has access to the data it requires, but only to the data it needs to contribute to the project.

    Digital Tools for Analog Connections

    Ultimately, effective team collaboration is built on personal relationships. An effective collaboration platform will encourage human interaction through virtual check-ins, get-togethers and other digitally enabled means of “analog” connection. That could be as simple as providing a rich palette of customizable emojis that allow for personal expression and help to reveal the person behind digital communication.

    At a more sophisticated level, project retrospectives should be built into your collaboration platform to evaluate process and performance for continual improvement. Retrospectives should be blameless so all team members can benefit from learnings without feeling censured. A playbook can provide predefined guidance on meeting purpose, scope, timeframe, budget and so on. Approached this way, retrospectives provide an opportunity for team-building and strengthening of personal connections.

    Hybrid work environments for developers will continue for the foreseeable future. So will the strategic importance of developer collaboration. A purpose-built technical and operational collaboration platform can help ensure that development teams perform in a culture of collaboration and drive successful application development outcomes.

  • Complexity is Still With Us

    Complexity is Still With Us

    We have come a long way and had a lot of improvements over the years, but we still struggle with the ability to simplify things faster than we create complexity. It isn’t enough that each new wave of Really Important Bits™ comes with its own issues and layers and complexity; we also haven’t been cleaning up our previous Really Important Bits™ projects. We haven’t cleaned up the successful ones and we haven’t cleaned up the failures.

    It is time to start. Honestly, we are looking at an extended stretch of ‘Do More With Less,’ and we need to get our houses in order. Want to do more with less? Start by standardizing. Yes, that one project that used Really Important Bits™ (or its companion product Really Cool Tech™) was neat and all, but keeping a technology and its layers and pieces laying around for a single project is not great management. In fact, it isn’t management at all; it is letting things happen. I’d call it chaos, but then we’d have to have a whole conversation about Dungeons & Dragons and, frankly, it is happening in the forum of the overall enterprise architecture so it’s not actually chaos, it is simply excess technical debt.

    DevOps was never meant to be a destination, but on this cross-country road trip, our IT car will get filled with garbage if we don’t take the time to clear out the Really Important Things™ of last year or the last management team or the latest merger. We cannot continue to layer more on without relieving pressure somewhere. AI has the potential to offer some pressure relief in some areas, but we were already behind, so for a variety of reasons, it isn’t the silver bullet we need. Those reasons are simple–it is less secure to leave 50 different ways to do the same thing laying around. AI is resolving some problems and freeing up time, but you’re still wasting time and money on redundant or unused Really Important Things™.

    Some things simply cannot be cleaned up without a massive investment. That’s fine—I hope after years of using DevOps methodologies you have them on a list of things that you’d like to upgrade/replace, but it just isn’t feasible to do so. Focus on the things that you can simplify. The famous low-hanging fruits are fine, just like simplifying things in the early days of DevOps meant that each piece of low-hanging fruit freed up more time to focus on other issues, the same is true now that the low-hanging fruit is generated from DevOps. Or DevOops, in some cases.

    How did I get here, you ask? I was writing a simple overview of Git, CI/CD, DevOps, DevSecOps, GitOps, etc., etc. for a newer technologist, and realized that in between those important parts are a whole lot of tools and technologies we thought were important, but which are no longer terribly useful or necessary. I did her the favor of not including the by-the-wayside technology spaces and product markets. I removed the complexity, you could say.

    And keep rocking it. No matter how far along you are in your IT career, you can look back at all of the things you have learned. Apply that learning to simplifying and improving. Reduce overhead by reducing redundancy and look forward to the next Really Important Thing™ you’ll get to learn about. Keep improving—both your knowledge and the environment. And we’ll keep cheering you on.

  • Solving the Culture Conundrum in Software Engineering

    Solving the Culture Conundrum in Software Engineering

    The one crucial ingredient underpinning our transition to a digital-first economy, more than any other, is software. That’s why software engineering has become one of the world’s most in-demand professions. In the UK alone, the median salary for the role has increased 13% year-over-year as businesses look to stay ahead of the competition and attract the very best IT talent. But the high salary often isn’t consistent with where software developers stand in the business; many organizations still view them as suppliers rather than as crucial players in their success. Based on the current speed of transformation, we know that demand for software engineering is only going to increase. So business and technology leaders need to urgently consider vital cultural changes to help better integrate software development teams within the wider organization. But what exactly should they be?

    The Development Dilemma

    Agility has quickly emerged as a competitive advantage as businesses strive to deliver on customer expectations quickly and effectively. That’s heralded the rise of DevOps, which aims to write high-quality digital solutions more efficiently and have the ability to continuously update in a secure and low-risk way.

    The practice is already accelerating feedback loops in the software development of digital solutions on a wide scale, meaning new software is brought into production as fast as possible and with reduced risk. As a result, today’s successful businesses are now releasing software updates multiple times a day. The figure even runs well into the tens of thousands for tech giants like Amazon and Netflix. However, other businesses are struggling to keep up with the speed the market demands, largely due to a lack of clear communication, ways of working and integration between software developers and the wider business. It’s a dilemma that needs immediate attention if businesses are to remain at the competitive edge.

    Developers are too often left to deal with huge monolithic pieces of work, which require them to write code for months on end without it being road-tested. This inevitably leads to mistakes that are found only once the updates have already been released to market creating a ripple effect throughout the organization. It’s an all-too-common scenario that demonstrates business leaders’ clear lack of clarity and understanding about the colossal value adopting a DevOps culture can deliver for the wider business, including its customers.

    Take financial institutions looking to introduce a new offering, for example, such as a new mortgage product. Without a collective approach to development, getting the backend systems up and running for a product can take up to six months. But modularising the options and breaking down the functionality can shorten timelines to weeks.

    Business leaders must look to create unified, cohesive and cross-functional teams that work together on projects that are broken down into simplified and localized components that can be easily integrated together without a negative impact on each other. It might seem like a small strategic change in working practices, but its impact on the speed and efficacy of software development can be enormous.

    Revisiting Personalities and Processes

    The role of the software engineer has changed; it is no longer about writing code in isolation without much regard for or knowledge of how it benefits the business. Developers work better when they have clarity about the direct impact their work will have on achieving business goals and on the bottom line. It’s down to business leaders to communicate these challenges and goals (in other words, understand the “why”) to help software developers understand what they’re trying to achieve. But doing so in a way that moves towards a better working culture requires a new approach to building and managing software development teams.

    The first step is casting aside the negative stereotypes many have of software engineers and celebrating the intellectual and cultural diversity within their teams. Diversity of personnel brings a diversity of personalities, which is crucial to creating more inclusive cultures that accept and welcome all characters with open arms. While this may seem obvious, what is often overlooked is the impact diversity can have on stimulating and increasing innovation.

    Improving the diversity of development teams helps unlock multiple ways of responding to and analyzing the challenges brought forward by business leaders. After all, each individual has an array of different soft and hard skills based on their learning, development and experience. So, encouraging individuals to bring their characters and personalities to their roles is crucial; it ensures each and every stakeholder in the development process is empowered to contribute, feels inherently valued, and is able to challenge existing assumptions, helping deliver a more robust end product.

    Recognizing and harnessing this spectrum of skills also helps bridge many of the barriers to development that exist within businesses. Some software engineers, for example, might struggle to communicate technical updates in a way the wider business can understand, but tapping into another individual’s strong communication skills can help unite teams–and entire businesses-around one, holistic digital strategy.

    Channeling Change to Deliver Better Outcomes

    Clearly, cultural change is needed to embed software engineering at the core of modern business. But revisiting project management practices is also imperative to continually deliver software that provides value to the business, the world of scientific management and Waterfall delivery methods is no longer appropriate for the development of digital solutions. With such a heavy reliance on digital services, businesses—and, consequently, developers—need to be able to make changes with minimal effect. So, eschewing monolithic projects and encouraging cross-functional teams is essential. Not only does it reduce the need for sweeping software updates, but it negates the risk of a project failing to meet the initial brief, which could ultimately impact the entire business.

    By reviewing organizational processes, and bringing the wider business and software developers together, we can create teams that deliver digital solutions effectively and quickly, so that every user, whether internal or external, reaps the benefits of a more sophisticated approach to software engineering.

  • For Engineers, Meetings Waste Time and Money

    For Engineers, Meetings Waste Time and Money

    Meetings can be the lifeblood of any organization, allowing coworkers to check in with one another, exchange ideas and solve problems. But, for engineers moving up the career ladder, the mounting number of meetings expected of engineering managers can end up being a distraction that does more harm than good.

    Research from Clockwise recently examined data from more than 1.5 million meetings over the course of a year involving more than 80,000 software engineers at more than 5,000 companies around the world. Our analysis, which aggregated and anonymized the information, found that large and growing companies in particular are putting themselves at a competitive disadvantage by distracting some of their most valuable talent from doing important work.

    Engineers Spending More Time in Meetings

    The 2022 Engineering Meeting Benchmarks report showed that as software engineers move into management and spend significantly more time in meetings, they lose more than nine hours a week of what the report referred to as focus time—uninterrupted blocks of at least two hours to focus on deep work.

    That loss comes at a cost that can erode an organization’s bottom line. Engineering managers overwhelmingly say that focus time makes them and their teams faster and more productive, according to a related global survey of about 150 of them. Perhaps even more importantly, 76% traced a direct path from more focus time to more revenue.

    And as companies grow in size, so does the meeting “coordination tax.” In the hotly competitive tech world, that can put larger companies at a disadvantage compared to their smaller, nimbler rivals. Engineers at smaller companies have significantly more focus time—nearly six more hours per week–and spend three fewer hours in meetings than their counterparts at large companies.

    The Pressure of Meetings

    We all have our complaints about the seemingly endless proliferation of meetings in modern business life, and many other kinds of professionals certainly need uninterrupted time to be creative. But these pressures are especially acute and costly for engineers. They are often the most expensive part of a team’s budget, and the consequences of diminished time for deep work can be dire. A single misplaced character in a line of code, for instance, can result in a massive bug affecting an entire organization. In 2012, for example, a programming oversight caused Knight Capital Group to execute a series of erroneous automatic trades, resulting in a loss of $440 million in 45 minutes—and a $12 million fine from the Securities and Exchange Commission (SEC). More recently, a few missing characters in a programming update shut down Skyscanner, a travel search engine and booking platform, for more than four hours.

    Leaders need to be aware of the burden that they put on their teams with well-meaning but less-than-useful meetings. The engineers in the Clockwise analysis averaged 19.6 focus hours each week compared with 10.9 hours in meetings and 6.3 hours between them, something we call “fragmented time.” As they move into management, their meeting time soars to 17.9 hours while their weekly focus time plummets to 10.4 hours.

    And those averages don’t tell the whole story–there’s a very wide distribution depending on the organization. At some distracted businesses, engineers are clocking in with fewer than 10 focus hours a week, while elsewhere the most productive teams get 20 or more.

    Meeting Culture

    It’s easy for leaders to become convinced that they need to have a slew of meetings each week–one-on-ones, daily standups, planning sessions, scrums to coordinate across teams–but the cumulative impact can turn a calendar into something resembling Swiss cheese. Traditional meetings are obviously important–we need to talk to one another and work things out–but there’s also a big opportunity for businesses to try a new approach.

    It can be as simple as eliminating those annoying, unproductive 15- to 60-minute gaps in your schedule by holding meetings back-to-back. Other experiments in meeting culture could include instituting no-meeting days. Or deleting every other occurrence of a regularly scheduled meeting. Or try asynchronous working practices through apps like Loom or Slack Audio that allow participants to respond to presentations or messages on their own schedules, rather than as a group in real-time.

    In 2020, for instance, the company Loom—using its own remedy internally—switched its regular all-hands meeting to an asynchronous format on the theory that real-time meetings should be reserved for conversation rather than simple information sharing from a small group of people. Staffers watch short, prerecorded videos of updates from presenters when it’s convenient for them, and then participate in a company-wide Q&A in real-time. This approach allows the company to take advantage of everyone being together to engage in discussions and exchange ideas, Graham Gawthorne, then a member of Loom’s business operations team, wrote in a company blog post.

    It’s a practice that starts at the top. When scheduling, leaders need to take a good, hard look at their team’s calendars and, rather than just grabbing any empty space that shows up, consider how to leave individual contributors the blocks of time they need to actually do their work. Keep in mind that studies have shown that it takes roughly 25 minutes to refocus and get back on track after an interruption, and that task switching can take up 40% of a team’s productive time.

    And leaders need to preserve enough focus time for themselves, too—rather than trying to be perpetually available to their team members. If they’re not creating space in their own calendars to solve the larger problems, they’re probably not doing what managers should: Helping their teams to thrive.

    I don’t know a single engineering leader whose boss isn’t asking, “How do we go faster? How do we do more with what we have?” with even greater urgency in these economically challenging times. The Clockwise analysis suggested that the answer, for many of us, is to stop ping-ponging from one meeting to the next and give your teams what they need most: Time to focus on their work.

  • Why You Need to Empower Your Developers

    Why You Need to Empower Your Developers

    In recent years, the demand for software developers worldwide has increased. However, in 2020, when the pandemic hit, many CIOs pulled back considerably on their IT spending. This trend has quickly reversed. In 2022, worldwide IT spending is expected to reach $4.4 trillion. Additionally, according to the U.S. Bureau of Labor Statistics, employment in software development is projected to rise by 22%.

    Although organizations across several industries are increasing investment into IT, the supply of technology talent has struggled to keep pace. With the demand for creativity, developers understand their importance and can better dictate their terms — including higher salary compensation and enhanced benefits. Organizations that don’t meet these expectations risk losing coveted talent.

    Remote work continues to be a top priority for many developers, along with great company culture. To create a positive work environment for developers, business leaders must offer a culture that makes tech employees feel a sense of belonging and purpose while working remotely. Many developers also want opportunities for growth and the ability to provide agile and innovative toolsets to help increase productivity and collaboration.

    Let’s discuss some of the ways modern organizations can still empower developers and how business leaders can build a workplace culture that attracts some of the best developers in the business.

    Provide a Supportive Digital Workplace

    Open source usage has increased significantly in the workplace and continues to be a formative resource for developers. The open source community provides many new technologies that developers seek and even require in order to work at the top of their abilities. For example, open source provides some of the most popular programming languages available, including Javascript, C+++, and Python. The presence of multiple languages makes it easier for developers to write code and produce high-quality work efficiently.

    Open source communities help developers build their skills and allow them to customize their technology stacks, as a result allowing them to optimize their productivity and learn different techniques from other open source projects. There is little to no debate that open source is critical to the tech industry and developers. Embracing open source can increase satisfaction and create a better workforce overall.

    Inspire Collaboration Among Software Developers

    In the past, office perks such as free food and collaborative social areas were used to attract new employees and retain current employees. However, in the remote work world, these can no longer remain a priority. Instead, business leaders should prioritize the holistic professional experience that their organization provides its employees. For developers, in particular, building this experience falls on CIOs and IT leaders to ensure they are providing workplace satisfaction, modern technology and flexible processes. To do so, they need to focus on tools that promote productivity and communication.

    Most employees are familiar with the workflow software and collaboration tools that many workplaces provide. Without these offerings, remote workers would feel confused by their workload at the worst and adrift from their co-workers at best. For developers, however, these general collaboration tools won’t cut it, as they are poorly suited for engineering workflows. General collaborative software doesn’t offer the ability for deep customization, nor do they adapt natively to deploy on-prem or in the private cloud. As a result, developers have little to no use for these tools.

    And that lacking sense of utility makes a crucial difference. Developer burnout is at an all-time high and inefficient workflows can keep teams from performing at their best. Or, worse, it can frustrate individual employees, leading to lower retention rates and less attractive offerings for prospective employees. Business leaders looking to offer developers an improved working environment should provide a more integrated, developer-oriented tech stack.

    Empowered Software Developers are Productive Developers

    While the market has changed, for many developers, fragmented tools remain a top productivity challenge. Investing in modern tools and programming languages while also removing tech complexities are the keys to improving productivity and simultaneously creating a better developer experience. This is why organizations must implement open source applications so developers can have complete visibility and control over the entire stack.

    With tool fragmentation causing a number of distractions, developers can become frustrated and spend time responding to every individual incident. This poses the threat of a developer losing their love of the work. By doing away with fragmentation from old technology and selecting relevant solutions, business leaders allow developers to do what they do best: Develop software.

    When organizational leaders empower their developers, they in turn find their product teams are more productive and feel more tied to the organization as well as their customers and each other. Thus, what is best for developers is best for the organization at large.