Category: DevOps Culture

  • Meet the DevOps Dozen² 2022 Honorees

    Meet the DevOps Dozen² 2022 Honorees

    We are proud to announce the DevOps Dozen² 2022 honorees. For the past eight years, the DevOps Dozen Awards have celebrated the most outstanding individuals and companies in the DevOps community and their remarkable contributions to the industry. These honorees have demonstrated their leadership and commitment to our community during the past year.

    Congratulations to all those nominated and to the honorees. All of your hard work and dedication are greatly appreciated.

    Without further ado, here are the DevOps Dozen² 2022 honorees:

    DevOps Dozen Community Awards

    1. Best DevOps Industry Implementation

    OJA DevOps Transformation and Implementation

    2. Best DevOps Survey/Analysis/Research

    GitLab 2022 Global DevSecOps Survey

    3. Best DevOps-Related Video Series (video)

    DevOps Toolkit

    4. Best DevOps-Related Audio Podcast Series

    Grafana’s Big Tent

    5. Best DevOps Book/eBook of the Year

    Purple Book

    6. Top DevOps Evangelist

    Dan Garfield

    7. Best DevOps Transformation (non-vendor)

    Natura Cloud & DevOps Center of Excellence

    8. Best DevOps Event of the Year

    2022 DevOps Enterprise Summit

    9. Most Innovative DevOps Open Source Project

    Backstage

    10. DevOps Executive of the Year (non-vendor)

    Idit Levine

    11. Best DevOps Presentation of the Year

    “Journey from 100’s of Pipelines to a Single Pipeline Ecosystem” by Ali Ravji and Prashant Parekh

    12. Best DevOps.com Article of the Year

    What A Dev Wants

    DevOps Dozen Tools and Services Awards

    1. Best End-to-End DevOps Tool/Service

    Harness Software Delivery Platform

    2. Best DevOps Repo/GitOps Tool/Service

    Red Hat OpenShift GitOps

    3. Best CI/CD Tool

    CloudBees CI

    4. Best Value Stream Management Tool

    ConnectALL

    5. Best Observability Solution

    Nobl9 Platform

    6. Best DevSecOps Solution

    JFrog Advanced Security

    Veracode Continuous Software Security Platform

    7. Best Testing Service/Tool

    Digital.ai Continuous Testing

    8. Best Kubernetes Platform/Service

    Red Hat OpenShift

    9. Best Cloud-Native Security Solution/Service

    Aqua Platform

    10. Best DevOps for Mainframe Solution

    Open Mainframe Project Zowe

    11. Best DevOps for DataOps/Database Solution

    Liquibase

    12. Best New DevOps Tool/Service Provider

    BMC Compuware zAdviser DORA Metrics dashboard

    The honorees will receive both digital badges and physical trophies celebrating their achievements.

    Winners were chosen from among the finalists with general public voting counting for 40% of the final total and our judges’ selections for 60% of the weighted total. The panel of judges went through thousands of votes to choose the winners in each category—it was not an easy task. Many thanks to our judges for making the hard calls and to everyone who has supported the DevOps Dozen² Awards by nominating candidates and voting.

    For more information, please visit the DevOps Dozen² Awards website and stay tuned for the DevOps Dozen² 2023 Awards.

  • Southwest Airlines: ‘Shameful’ Technical Debt Bites Back

    Southwest Airlines: ‘Shameful’ Technical Debt Bites Back

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    20 Years of Neglect Led to ‘Meltdown’

    Last month’s débâcle of canceled flights was caused by decades of technical debt. That’s the analysis of Columbia University professor Zeynep Tufekci. (more…)

  • Why SREs Are Critical to DevOps

    Why SREs Are Critical to DevOps

    Although a relatively new concept, site reliability engineers (SREs) have become crucial for DevOps teams, helping to solve an array of operational problems such as network availability and user experience. However, in previous years, some people have questioned the longevity of such a role. 

    This article will discuss several reasons why site reliability engineering roles are here to stay and why they have become critical to DevOps. 

    What Are Site Reliability Engineers (SREs)?

    A site reliability engineer helps connect development teams and IT operations by completing tasks previously assigned to operational roles. SREs use a range of automation tools for troubleshooting purposes, creating software systems that are both scalable and reliable.

    The role revolves around automation and standardization, as cloud systems become increasingly prevalent. SREs also play a vital role in ensuring the user experience of systems is of the highest standard.

    Why Site Reliability Engineering Roles Are Here to Stay

    Let’s take a look at two of the primary reasons SRE roles are here to stay. 

    User Expectations

    The key reason for the rise in popularity and the expected longevity of site reliability engineering roles is user experience. In the modern climate, user expectations are very high and more dedicated roles are required to help deliver a service that is not only acceptable but attempts to exceed user expectations.

    Even back in the 2010s, users were much more patient in terms of website load speeds and how quickly they could access information. Even crashes and load failures were tolerated without the user exiting a website.

    However, that has all changed due to the competitiveness of the market, as well as the growth of remote working, which has increased dependency on online resources. This means that if a service is unavailable for any period, users are unable to do their job. 

    An SRE’s role includes optimizing systems, ensuring they perform at the required level and that resources are always available to those that need them. This makes SREs critical to DevOps teams that may not have the capacity to focus on meeting user expectations sufficiently. 

    The Complexity of Software Architectures

    Another factor that has added a lot of value to the role of an SRE is their ability to provide much-needed support for software environments and architectures that continue to develop in terms of complexity. Kubernetes is one such architecture that requires dedicated attention. 

    Applications that are distributed across systems such as Kubernetes and other cloud-native platforms require specialized personnel that have the necessary knowledge and experience. Machine learning is also becoming more prevalent and requires special focus from a performance perspective. In 2020, just more than 22% of companies had machine learning models in production for one to two years.

    This level of complexity is only expected to grow further over the coming years as cloud-native systems become the norm. This is why new roles must be created that go beyond that of a normal IT engineer. 

    Challenges for SRE Roles

    Like any IT role, the role of a site reliability engineer always faces challenges that have led people to question whether SREs are a long-term solution or whether it is a niche specialization. 

    A Lack Of Opportunity Away From Hyperscale Companies

    The role of an SRE was created by hyperscale companies like Google that manage extremely large IT systems. For companies that do not have such a wide and varied IT infrastructure on a global scale, there are questions about whether such a role is necessary. 

    However, as previously mentioned, the growth of cloud-native technology shows no sign of slowing and, with this growth, opportunities for SREs at smaller organizations may arise. 

    The Role of an SRE is Considered Obscure

    The ambiguity of an SRE role can be considered a downfall in some cases, with many businesses unsure of what these professionals offer when compared to a traditional systems engineer. In many cases, SREs are deemed to be a hybrid of a software engineer and an IT operations role. 

    Fortunately, DevOps has realized the potential of SREs and their ability to provide an important bridge between developers and engineers, helping to achieve dedicated tasks to a high standard. 

    SREs Vs. DevOps

    Although both roles are connected and share some similarities, there are some clear differences.

    • Processes – DevOps has full visibility into the development environment which allows them to make changes from the initial development stages through to production. SREs, on the other hand, only have visibility into the production process, allowing them to make suggestions to ensure performance levels are maintained.
    • Implementation – The task of implementing new features on a system falls on the DevOps team. Meanwhile, SREs are tasked with ensuring the new features do not cause any system failures or impact performance during the production stage.
    • Key Focus – The primary focus of a site reliability engineer is to ensure the system’s reliability, availability and scalability. DevOps focuses on how quickly product development is completed, as well as its continuity.
    • Structure – The structure of an SRE team and a DevOps team have obvious differences. SRE teams are made up of individuals who have similar skill sets relating to development and operations. Whereas DevOps teams consist of professionals who have specific roles related to individual aspects of the project. These roles can include the team leader, product owner, cloud architect, software developer, QA engineer, system administrator, release manager and more.
    • Tools – DevOps teams often use tools such as integrated development environments (IDEs) when developing a product. These can include Jenkins (continuous integration and continuous development), JIRA (change management), Splunk (log monitoring) and GitHub (distributed version control). SREs commonly use tools such as Prometheus and Grafana (collection and visualization of metrics, such as CPU usage and available disk space), OP5 and PagerDuty (incident alerts), Ansible and Kubernetes (container orchestration) as well as a range of cloud platforms.
    • Bug Reporting – DevOps debug code whenever a bug is reported in the end product. SREs are not involved with debugging from a development perspective and are only required to perform such tasks if there is a production outage, there are infrastructure issues or perhaps if they are dealing with common AWS misconfigurations.
    • Measuring Performance – The typical metrics that DevOps uses to measure performance are deployment frequency and deployment failure rate. SREs measure service level objectives (SLOs), service level indicators (SLIs), service level agreements (SLAs) and error budgets.
    • Incident Handling – In the case of incident handling, DevOps teams work to mitigate an issue based on the feedback provided. SREs then analyze the issues post-incident, including the root cause of the issue. This is then documented and provided to the developers to fix. 

    Why SRE Roles Are Critical to DevOps – Conclusion

    As you can see, the two roles differ significantly but SREs can play a critical role in ensuring the DevOps team delivers a product that offers maximum performance. 

    The core benefits of employing professionals in a site reliability engineer capacity are high levels of product performance and reliability to meet user expectations while helping to manage complex IT architecture. 

    In the future, organizations that manage a large amount of cloud-based IT assets may struggle to deliver efficient products without such professionals. As such, demand for SRE roles is likely to grow. 

  • DevOps Must Embrace Automation in 2023

    DevOps Must Embrace Automation in 2023

    A survey of 500 engineering and software development professionals in the U.S. suggests more DevOps teams than ever need to resolve to embrace automation at a deeper level in the new year.

    The survey, sponsored by Chronosphere, a provider of an observability platform, found engineers spend, on average, more than 10 hours per week attempting to triage and understand incidents. That equates to a quarter of a 40-hour workweek.

    Overall, 96% of respondents said they spend most of their time resolving low-level issues, with 88% reporting that amount of time negatively impacts them and their careers because so much time is spent troubleshooting IT issues.

    Over a third (33%) said those issues disrupted their personal life with 39% of respondents admitting they are frequently stressed out. Just under a quarter (22%) said they want to quit.

    Chronosphere CEO Martin Mao said much of the stress DevOps teams encounter results from reliance on DevOps platforms that organizations built themselves. Platforms built and supported by a vendor today typically provide higher levels of automation that reduce overall stress levels, he added.

    The survey found that 40% of respondents frequently get alerts from their observability solution without enough context to triage the incident. A total of 59% said half of the incident alerts they receive from their current observability solution aren’t actually helpful or usable, with 49% reporting they struggled with inconsistent performance using their current approach to observability. Nearly half (45%) said their current observability solution requires a lot of manual time and labor.

    Overall, 42% of those using a vendor solution said they experienced high-severity incidents quarterly or more compared to 61% relying on a platform they built. Among organizations not using a vendor solution, the majority said they would consider doing so to enhance team productivity (61%) or improve reliability (54%).

    Stress levels are likely to increase as organizations deploy emerging cloud-native applications. A full 87% of respondents said cloud-native architectures had increased the complexity of discovering and troubleshooting incidents.

    During challenging economic times, it’s more critical for DevOps leaders to understand the total cost of building and maintaining platforms, said Mao. Many organizations decided to build their own platform at a time when there was no other viable option. The manual processes required to support those platforms result in a higher cost of labor that impedes the ability to scale workflows cost-effectively, he noted.

    It’s not clear how big an appetite for change any organization that has built their own DevOps platforms may have in 2023. The challenge is that the initial cost of swapping in a commercial platform may appear high given the fact that the legacy platform is already deployed. However, the cost of the acquisition of a new platform needs to be weighed against the total cost of ongoing operations. A lot of soft costs show up in, for example, higher turnover rates for DevOps professionals that are likely to find a more rewarding job elsewhere that is less tedious. One way or another, at the start of 2023, it’s apparent there are more hard DevOps questions than ever that need to be asked and answered.

  • Best of 2022: Agile/Scrum is a Failure – Here’s Why

    Best of 2022: Agile/Scrum is a Failure – Here’s Why

    As we close out 2022, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    Welcome to The Long View—where we peruse the news and strip it to the essentials. Let’s work out what really matters.

    This week, something a bit different: I’m devoting my entire column to Agile and Scrum. They’re increasingly getting a bad reputation, being associated with the worst aspects of toxic workplace culture: Sexism, racism, burnout, micromanagement. (more…)

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    ZipRecruiter

    CapitalOne
    New York, New York
    Lead Software Engineer
    $190,950 to $225,278

    Monster.com

    UMD Energy Solutions
    Bonita Springs, Florida
    AWS Cloud Engineer
    $140,000 to $150,000

    Dice.com

    Cox Communications
    Atlanta, Georgia
    Lead DevOps Engineer
    $105,700 to $176,100

    Indeed.com

    Northrup Grumman
    Dulles, Virginia
    Senior/Principal DevOps Engineer
    $104,600 to $157,000

    SimplyHired

    Visa
    Miami, Florida
    DevOps Engineer
    $85,000 to $120,000

  • Best of 2022: How DORA Metrics Can Measure and Improve Performance

    Best of 2022: How DORA Metrics Can Measure and Improve Performance

    As we close out 2022, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    A technology company’s most valuable assets are its people and data, especially data about the organization itself. By knowing what data to track over time, engineering leaders can measure how efficiently their DevOps teams are operating and enable them to maximize their value stream to deliver the best possible product to end users.

    After years of research, Google’s DevOps Research and Assessment (DORA) team identified four key metrics for evaluating a team’s performance:

    1. Lead time for changes
    2. Deployment frequency
    3. Mean time to recovery
    4. Change failure rate

    DORA metrics have now become the standard for gauging the efficacy of software development teams and can provide crucial insights into areas for growth. These metrics are essential for organizations looking to modernize and those looking to gain an edge against competitors. Below, we’ll dive into each metric and discuss what they can reveal about development teams.

    Lead Time for Changes

    Lead time for changes (LTC) is the time between a commit and production. LTC indicates how agile a team is—it not only tells you how long it takes to implement changes but how responsive the team is to the ever-evolving demands and needs of users. The DORA team identified these benchmarks for performance in their Accelerate State of DevOps 2021 report:

    Elite performers: Less than one hour

    High performers: One day to one week

    Medium performers: One month to six months

    Low performers: More than six months

    LTC can reveal symptoms of poor DevOps practices: If it takes teams weeks or months to release code into production, there are inefficiencies in their process. One can minimize their LTC through continuous integration and continuous delivery (CI/CD). Encourage testers and developers to work closely together so everyone has a comprehensive understanding of the software. Consider building automated tests to save more time and improve the CI/CD pipeline.

    Because there are several phases between the initiation and deployment of a change, it’s wise to define each step of the process and track how long each takes. Examine the cycle time for a thorough picture of how the team functions and further insight into where they can save time.

    One should be careful not to let the quality of their software delivery suffer in a quest for faster changes. While a low LTC may indicate that a team is efficient, if they can’t support the changes they’re implementing or they’re moving at an unsustainable pace, they risk sacrificing the user experience. Rather than compare the team’s Lead Time for Changes to other teams’ or organizations’ LTC, one should evaluate this metric over time and consider it an indication of growth (or stagnancy).

    Deployment Frequency

    Deployment frequency (DF) is how often you ship changes; how consistent your software delivery is. This metric is beneficial when determining whether a team is meeting goals for continuous delivery. According to the DORA team, these are the benchmarks for Deployment Frequency:

    Elite performers: Multiple times a day

    High performers: Once a week to once a month

    Medium performers: Once a month to once every six months

    Low performers: Less than once every six months

    The best way to enhance DF is to ship a bunch of small changes, which has a few upsides. If deployment frequency is high, it might reveal bottlenecks in the development process or indicate that projects are too complex. Shipping often means the team is constantly perfecting their service and, if there is a problem with the code, it’s easier to find and remedy the issue.

    If a team is large, this may not be a feasible option. Instead, one may consider building release trains and shipping at regular intervals. This approach will allow the team to deploy more often without overwhelming your team members.

    Mean Time to Recovery

    Mean time to recovery (MTTR) is the average amount of time it takes your team to restore service when there’s a disruption like an outage. This metric offers a look into the stability of your software, as well as the agility of your team in the face of a challenge. These are the benchmarks identified in the State of DevOps report:

    Elite performers: Less than one hour

    High performers: Less than one day

    Medium performers: One day to one week

    Low performers: Over six months

    To minimize the impact of degraded service on your value stream, there should be as little downtime as possible. If it’s taking your team more than a day to restore services, you should consider utilizing feature flags so you can quickly disable a change without causing too much disruption. If you ship in small batches, it should also be easier to discover and resolve problems.

    Although mean time to discover (MTTD) is different from mean time to recovery, the amount of time it takes your team to detect an issue will impact your MTTR—the faster your team can spot an issue, the more quickly service can be restored.

    As with lead time for changes, you don’t want to implement sudden changes at the expense of a quality solution. Rather than deploy a quick fix, make sure that the change you’re shipping is durable and comprehensive. You should track MTTR over time to see how your team is improving and aim for steady, stable growth.

    Change Failure Rate

    Change failure rate (CFR) is the percentage of releases that result in downtime, degraded service or rollbacks, which can tell you how effective a team is at implementing changes. As you can see, there is not much distinction between performance benchmarks for CFR:

    Elite performers: 0-15%

    High, medium and low Performers: 16-30%

    Change Failure Rate is a particularly valuable metric because it can prevent a team from being misled by the total number of failures they encounter. Teams who aren’t implementing many changes will see fewer failures, but that doesn’t necessarily mean they’re more successful with the changes they do deploy. Those following CI/CD practices may see a higher number of failures, but if CFR is low, these teams will have an edge because of the speed of their deployments and their overall success rate.

    This rate can also have significant implications for the value stream: It can indicate how much time is spent remedying problems instead of developing new projects. Because high, medium and low performers all fall within the same range, it’s best to set goals based on the team and the particular business rather than compare to other organizations.

    Putting it All Together With DORA Metrics

    As with any data, DORA metrics need context, and one should consider the story that all four of these metrics tell together. Lead time for changes and deployment frequency provide insight into the velocity of a team and how quickly they respond to the ever-changing needs of users. On the other hand, mean time to recovery and change failure rate indicate the stability of a service and how responsive the team is to service outages or failures.

    By comparing all four key metrics, one can evaluate how well their organization balances speed and stability. If the LTC is within a week with weekly deployments but the change failure rate is high, then teams may be rushing out changes before they’re ready, or they may not be able to support the changes they’re deploying. If they are deploying once a month, on the other hand, and their MTTR and CFR are high, then the team may be spending more time correcting code than improving the product.

    Because DORA metrics provide a high-level view of a team’s performance, they can be beneficial for organizations trying to modernize—DORA metrics can help identify exactly where and how to improve. Over time, teams can measure where they have grown and which areas have stagnated.

    Those who fall into the elite categories can leverage DORA metrics to continue improving services and gain an edge over competitors. As the State of DevOps report reveals, the group of elite performers is rapidly growing (from 7% in 2018 to 26% in 2021), so DORA metrics can provide valuable insights for this group.

    But remember that data will only get you so far. To get the most out of DORA metrics, engineering leads must know their organization and teams and harness that knowledge to guide their goals and determine how to effectively invest their resources.

  • Best of 2022: We Must Kill ‘Dinosaur’ JavaScript | Microsoft Open Sources 3D Emoji

    Best of 2022: We Must Kill ‘Dinosaur’ JavaScript | Microsoft Open Sources 3D Emoji

    As we close out 2022, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: JavaScript is a bloated barrier to progress, and Microsoft’s emoji are on GitHub. (more…)

  • Best of 2022: 6 Top Technology Trends to Watch

    Best of 2022: 6 Top Technology Trends to Watch

    As we close out 2022, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    Technology trends simply cannot be ignored in today’s dynamic environment. As the world enters a post-digital era, organizations are exploring disruptive technology trends. Artificial intelligence, machine learning, intelligent process automation, advanced analytics, and robotic process automation (RPA) are among the top DevOps technology trends to watch. According to a survey by Accenture, 94% of IT and business experts reported that emerging technologies have accelerated firms’ innovation pace in the last three years. 

    Winning This Decade in the Context of the Next Normal

    This decade continues to witness further development in technology, as innovation transforms industries such as insurance, banking, and healthcare. It is crucial to look beyond seeking operational efficiency and decreasing cost — particularly as customer expectations, regulatory requirements and business landscapes are rapidly evolving. 

    Take a look at six vital technology trends that have gained momentum in today’s hyper-digital world: 

    Trend 1: Artificial Intelligence (AI), Machine Learning (ML) – Integrating Intelligence 

    Technologies like AI and ML have existed for some time, but only now have they started maturing from their perception of “interesting” to “organizationally effective.” Artificial intelligence and machine learning are digital transformation catalysts, and some of the capabilities that fall under this technology include pattern recognition, natural language processing and sentiment analysis. Artificial intelligence has become increasingly important because it provides companies with a competitive edge, is cost-effective and allows them to future-proof themselves. 

    Trend 2: Predictive Analytics – Harnessing New Opportunities 

    In this digital-savvy environment, it has become crucial for organizations to employ tools like predictive analytics.  An advanced form of data analytics, it’s used to extract information and predict trends, behavior and activities with precision. It is increasingly being introduced across industries as it optimizes productivity, helps understand customers better, identifies revenue opportunities and areas of attrition. Financial institutions have already begun to deploy predictive analytics, helping them customize the product offerings, detect fraud and identify new opportunities for cross-selling.

    Trend 3: Low code – Accelerating Innovation 

    Gartner forecasts that low code application platforms will be responsible for 65% of application development activity by 2024. Organizations are rapidly leveraging low code to cater to the growing needs of the digital-first customers, deliver mission-critical and enterprise-grade applications quickly and respond rapidly to unforeseen scenarios. 

    Trend 4: Intelligent Process Automation (IPA): Unifying Processes

    Another technology trend that has paved its path in the digital world is intelligent process automation (IPA). IPA is a group of technologies that work together to organize and digitize the end-to-end business processes and the customer journey. The key drivers of IPA are the need for continuous improvement, retaining data consistency and bridging existing silos.  The technology offers several benefits to an organization, such as reducing error rates, unifying operations, and accelerating processes, but more importantly, assisting in streamlining employee and customer-facing journeys.  

    Trend 5: Contextual Content Services – ECM: Leveraging Context in Content

    Contextual content services, an evolution of traditional enterprise content management (ECM), play a key role in powering automation initiatives. The right tools in ECM like intelligent taxonomy and cognition can bring context to business processes. Empowering users to make smart decisions with relevant information ensures accurate data extraction, and mitigates risks by managing the overall content lifecycle. 

    Trend 6: Robotic Process Automation (RPA): Improving Productivity 

    Robotic process automation is rapidly becoming an integral cog in the wheel of the end-to-end digital journey of organizations. RPA can be the last mile of process automation — or in between — but is key to streamlining and optimizing customer-facing and back-office tasks. The use of bots helps automate repetitive tasks and liberate knowledge workers to focus on other value-added tasks.  The capabilities of RPA offer several benefits, including faster turnaround times, process optimization, sustaining consistency and increasing employee productivity.  

    Future-proofing the Enterprise

    A close eye on the different technology trends can help enterprises leverage the right tools to optimize their business processes and adapt to the changing market needs. Technologies like low code platforms, advanced analytics, AI, and ECM are already being implemented by some organizations to stay ahead of the competition. Ensure your enterprise is tapping into these technology trends to thrive in the next normal.

  • Best of 2022: Making the Move From Developer to Team Lead

    Best of 2022: Making the Move From Developer to Team Lead

    As we close out 2022, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    After working in their role for some time, software developers may wonder what career opportunities await them beyond coding. Certainly, taking the next step is not obligatory. Some people feel comfortable remaining developers for their entire professional careers.

    However, for those who wish to explore other options, there are a number of different growth paths to choose from—whether it’s working as a solution architect, a Scrum master or a product owner, just to name a few examples.

    Another option to consider is a team lead—considered by many to be a position that is a culmination of long-time efforts, passion and dedication as an IT specialist. But is becoming a team lead an opportunity that an ambitious developer should consider?

    What Makes a Great Team Lead?

    Unlike developers, who usually work on a specific aspect of a project and communicate mainly with other developers, team leads—as the title suggests—are focused on coordinating the activities of and collaborating with the entire team. They also spend far less time dealing with technical issues. A team lead is a leader, a representative and a manager of the team and, as such, their responsibilities involve communicating with both the team members and stakeholders within and outside the company.

    A team lead is the first person a developer would go to when a problem occurs and is the person responsible for suggesting a solution. Bug fixes, tooling and library choices or thoughts on how to approach a specific code-related problem—these are the team leads’ specialties since their technical knowledge and experience are what propelled them into a leadership role in the first place.

    The Go-To Point of Contact

    If you want to improve an application or a test, the team lead is the person to talk to about it. They should know the ins-and-outs of technology solutions and be able to explain to less-seasoned developers why something works and something else doesn’t, or why it may be a good idea to do X instead of Y.

    This doesn’t mean, however, that they are all-knowing. Asking other experienced developers for their insight, opinions or to share their knowledge is something good team leads do without fear of losing their authority. They should always be open to other people’s suggestions and welcome innovative ideas.

    In addition, team leads should think about a project as a whole, including all the people who are working on it. They can direct developers’ efforts and tell their teams what to pay attention to while making improvements, sharing best practices and taking care of code infrastructure and project architecture.

    When to Step Up

    It seems obvious that experience, knowledge, passion and communication skills are all things that ultimately make a good team lead. And these skills aren’t developed overnight—they often start as junior engineering or DevOps professionals and gain technical, social and leadership skills before they can guide an entire team or teams.

    Sometimes, this progression is a natural consequence of an individual’s personality and work style. A team may notice that one member has more extensive knowledge and/or that one particular person is a natural leader who can motivate others and direct their activities. At other times, team leads emerge spontaneously because of their technical knowledge or they volunteer to gain valuable experience.

    For a developer, taking the next step may seem like getting thrown into the deep end. But many current developer skills will be useful in their new role.

    For instance, attention to detail—something most developers are known for—can be invaluable as a team lead. Relentlessly analyzing and improving code, for example, is likely to come in handy in a team lead’s work.

    The Importance of Soft Skills

    Technical know-how, experience, passion, hard work and conscientiousness are the keys to becoming a successful team lead, but it’s also necessary to enjoy working with other people.

    A team leader’s job requires communication, collaboration and people skills more than ever before. Collaborating with team members as well as other stakeholders within and outside the company means that a team lead is a central figure in the IT and business processes. Being tech-savvy is great, but leading a team goes far beyond that since it’s about knowledge and experience and being able to communicate about that knowledge and experience.

    Another key competency is fluency in English. Using English for coding purposes and communicating in English are two different things. As a team lead, you must talk to your clients and team members, many of whom work remotely and may be in different countries. Of course, you can develop your language skills as you go when you’re a team lead; as with most skills, learning by doing can help with confidence and fluency.

    Building language skills can happen simultaneously with building technical and interpersonal skills. Knowledge of various technologies, frameworks and functionalities; experience in working with them; finding ways to change and improve things—all of these give team leads a good reason to practice language skills by talking with colleagues, supervising projects and advising their stakeholders within and outside the company.

    Making the Move to Team Lead

    With their bottomless willingness to work harder, learn more and take on more responsibility, team leads are an incredibly important role in software development. If you feel that constant development—both technical and interpersonal—is the right course of action for you, then consider becoming a team lead.


    Paulina Gatkowska, test automation lead and Robert Musil, Python team lead at STX Next contributed to this article.