Containers Trend Report. Explore the current state of containers, containerization strategies, and modernizing architecture.
Securing Your Software Supply Chain with JFrog and Azure. Leave with a roadmap for keeping your company and customers safe.
Development team management involves a combination of technical leadership, project management, and the ability to grow and nurture a team. These skills have never been more important, especially with the rise of remote work both across industries and around the world. The ability to delegate decision-making is key to team engagement. Review our inventory of tutorials, interviews, and first-hand accounts of improving the team dynamic.
Welcome to SPACE Developer productivity is a complex subject for which there is no magic bullet. However, economic pressure, increased market competition, and shorter delivery circles force many organizations to improve their efficiency and open up new models of operations. Measuring, maintaining, and eventually improving engineering productivity in an increasingly hybrid workplace are important discussions many organizations are having right now. As a result there are more and more companies investigating how to do more with the resources they have, how to remove bottlenecks in their processes and how to enable developers to be productive. Empirical evidence and understanding of productivity drivers are forming at the same time as some myths and misconceptions are getting debunked. One of the approaches that got a lot of attention is the SPACE framework. We give the background on it and explain some of its key concepts. Moreover, we give some additional examples of the application of SPACE in your organization. Introduction to the SPACE Framework “The SPACE of Developer Productivity” is a framework by authors from GitHub, the University of Victoria, and Microsoft that has gained attention because of its practical and multi-faceted approach. The authors debunk common productivity myths and misconceptions and then present drivers for developer productivity. They present those drivers structured as a holistic multi-dimensional model. Moreover, the authors show some example productivity metrics as well as counter-indicators. For convenience, we present a summary of the SPACE framework and give some assistance on how to utilize increasingly popular engineering intelligence to kick-start your SPACE tracking and reporting. Developer Productivity: Myths and Misconceptions Some misconceptions and myths are clarified by the authors of the SPACE Framework early on: One obvious myth is that (developer) productivity is not a one-dimensional metric. There is no single number that defines productivity and any approach that is too simplistic will provide little insights. Not only that but different organizations and different teams might be best served with a different set of KPIs to focus on. We will go into this a bit later. Software development is a team sport. As such, individual metrics are less relevant; in fact, can be counter-productive. What matters is the performance of teams or the organization as a whole. Also, we might add, not absolute numbers are essential but trends and the observability of countersignals highlighting problems to address. Outcomes are more important than output. While harder to quantify, the ability to ship customer-relevant features is obviously more important than just churning out code. As a result, pure activity metrics are not sufficient to make good productivity estimates. Having said all this, it is worth highlighting the value of measuring nonetheless: A good set of measurements can give insights into how the organization is performing, how it is trending, and which areas can improve. Moreover, key indicators are not only valuable to management, but if used correctly give a voice to engineering at the same time. Developers like to have evidence to show the value they bring to their teams and the organization. People generally like to show their worth and like to improve processes and themselves where they can. Having that evidence at your fingertips helps to improve self-worth and in turn, improve organizational productivity. The SPACE Framework Explained SPACE stands for Satisfaction, Performance, Activity, Communication, and Efficiency and reflects the multi-dimensional approach proposed by the creators. We summarize those in the following. The 5 SPACE dimensions are: Satisfaction and well-being: This dimension measures how satisfied development teams and individuals are with their tools, processes, and the work environment. For instance, are the right tools and resources in place to perform tasks efficiently? Are teams protected from overload or do individuals suffer from potential burnout? Is the management structure and environment supportive of growth and productivity? Performance: This relates to the actual outcomes created by teams and the absence of blockers to create those outcomes. For instance: What is the customer acceptance and satisfaction of features shipped? How did we improve on that over time? How did we improve our overall quality? Performance is closely related to organization and team performance and satisfaction to contribute to overall efficiency. Activity: As mentioned above, outcomes are preferable to output, but activity or output are often good proxy metrics that still enable some useful indicators – and especially counter indicators. This can be the release cadence, build system performance, or the number of incidences to manage. Simply speaking, do we get stuff done? And how did we improve over time? Communication and Collaboration: Effective collaboration and team cohesion has been shown as a significant contributing factor to developer productivity. For instance, brainstorming, collaboration, aligning on goals, and participating in outcomes improve productivity. Counter to these are scenarios where individuals work against each other, shift blame around, or feel abandoned by their management. Efficiency and Flow: It is one thing to produce valuable outcomes, but how efficient can we be in doing so? A key indicator is how much individuals and teams can be “in the flow” of performing their work; how much they can be free from blockers, interruptions or delays. The “flow” is something a lot of organizations are starting to pay attention to on a process or organizational level already. This shows up as a company’s Value Stream Metrics or DORA metrics. These are concepts that are often used to communicate with the executive team or even the board. Organizational Dimensions Lastly, the SPACE framework makes a distinction of where the productivity measures are taken and applied these are: Individuals: Helping individuals to feel more productive is important, but this is often best done by setting the right process, organizational, and team environments. As we have seen above, micro-managing individuals does not have the best impact and often does not produce the desired outcomes. Teams: Well-performing teams are at the core of well-performing organizations. Setting the right environment, context, and feedback loops for teams has been shown to improve productivity significantly. System: Improving processes, systems, and organizational metrics helps to improve the overall organization efficacy and deliver better outcomes to customers faster. These are high-level indicators that help to drive better performance across the board. This concludes the summary of key dimensions for the SPACE framework, but it is worthwhile to read the original article linked earlier. Next, we provide some examples augmented by our own experience that can easily be measured. SPACE Framework: Example Metrics Satisfaction For satisfaction and well-being, there are numerous ways to measure how things are going within the organizations. These can be explicit metrics such as: Results on NPS from formal or semi-formal surveys Quick emoji-like responses to survey emails, ticket support cases, or internal portal features: Retention rates of engineers and engineering managers These metrics require, however, dedicated effort and resources to implement, maintain and analyze/report on. While this is feasible in some organizations, this is often not the first step in moving to a SPACE process. Proxy metrics have been shown to be useful to equate with a certain level of satisfaction or rather the opposite, are indicators of frustration. Examples are: CI build failure rates and recovery times: Means; potential pain of waiting and uncertainty Code review cycles and review delays: The pain of context switching Bug numbers and issue fix times: The pain of customer dissatisfaction While proxy metrics are not suitable for more personalized sentiment analysis or sentiment around organization and management issues, they can highlight common triggers for frustration and dissatisfaction. Moreover, proxy metrics are often an easy starting point as they are a matter of mining existing data and do not require introducing new workflows or additional potentially distributing tasks. Performance The authors of the SPACE framework highlight a number of proxy metrics for performance around code reviews and related activities. This includes: Code review velocity/acceptance rates: How quickly/consistently are we delivering outcomes? Items shipped (epics/features/story points): How much do we get done? Reliability of infrastructure/product/build systems: Do we have infrastructure bottlenecks preventing us from performing? Again, while this does not necessarily give a complete picture all of the above metrics provide useful signals to gauge overall performance. Activity While performance measures the outcomes, activity is more focused on outputs. These are metrics that are typically easy to obtain, examples are: The number of code reviews completed Number of PRs done The number of issues/story points completed Time spent on development activities Deployment frequency Activity items are those that can often be accessed from data in your engineering tools and infrastructure. These metrics are especially useful when extracted continuously and automatically for reducing any friction and developer overhead, while at the same time being aggregated to teams or organization level for monitoring and trending. Communication/Collaboration Metrics in this category are a bit more open to interpretation and one needs to be careful when introducing any proxy metrics. While it is possible to detect negative signals, the converse is harder. A highly collaborative team is something that often cannot be determined by numbers alone and requires good personal management skills. Nonetheless, some proxy metrics that have shown to be beneficial are: Code review scores/number of reviewers/number of review cycles: Are reviews well distributed, include several active people per PR, and comment more than “LGTM”? Do numbers reflect a sense of collaboration and not blame shifting as it might be evident in long review cycles between the same people? PR cycle times: Are we efficient and work together well or are there any obvious blocking stages? Knowledge/review graphs: Is there a wider network of collaboration or do we have knowledge islands? Efficiency/Flow One of the key categories around developer productivity is the “flow” engineers are in, but also the flow enabled by supporting infrastructure and team processes. There are both positive and anti-signals that can be measured such as: PR velocity and trends Development cycle time Build times and reliability Blockers and delays in code reviews Aging of backlogs and ticket state changes Measuring flow, efficiencies, as well as blockers, is something that can be well approximated by hard data. Example Snapshot of SPACE Report in Logilica Summary Overall the SPACE framework introduces a multi-faceted approach to developer productivity. Looking both at some key dimensions of what productivity means, but also across individuals, teams, and the organization as a whole. Metrics to measure SPACE dimension can be direct or indirect through proxy data. The great thing is that many data points already exist in some shape or form in organizations and can be data mined. This can be done, for example, by in-house productivity engineering teams themselves or with the help of increasingly popular software engineering intelligence (SEI) platforms.
Jira is one of the most flexible and customizable Project Management tools on the market. It’s also built from the ground up with Agile in mind making it one of the best solutions for managing Sprints in Scrum. What Is Scrum, and How Does It Fit Into Jira? Scrum is a lightweight Project management framework. It is designed to break down a large body of work into iterative increments. Scrum was initially introduced as a way of improving collaboration in teams that are working on solving complex problems. In essence, the Scrum team breaks down the entire project into Sprints – short, time-boxed periods during which a Scrum team is to deliver an agreed-upon number of increments, AKA functional features. All five of the scrum events, such as sprint planning, daily Scrum, sprint review, and retrospectives, take place during the Sprint. The Scrum framework is incomplete by design. However, it encourages the process of continuous learning and improving through your work. Your decisions will be based on observation, ability to adapt, and a fair bit of common sense. You can learn more about Scrum from the Scrum guide and on Scrum.org. For now, I’ll assume you know the basics and focus on the elements directly applicable in your Jira instance. The Scrum Team The average Scrum team has three roles: Product owner, Scrum master, and Developers. The Product Owner is accountable for the product value a Scrum team delivers. This person shares the goals of Sprint and should answer any questions the dev team might have regarding the product or users. PO is also responsible for Jira Themes & initiatives, Epics, and User Stories. Regarding Jira, the Product Owner is responsible for translating the project plan into Jira, Jira roadmap design, backlog management, and prioritization. The Scrum Master acts as the team’s coach. This person observes everyone’s activities and helps deliver a successful result. In addition, Scrum Master facilitates standups, helps to keep the scope in check during sprint planning, and hosts retrospectives. Regarding Jira, the Scrum Master is responsible for the Sprint board. He is usually the admin on the project and helps ensure that the cards are updated and flow through the established Jira workflow. Developers deliver the work during the active Sprint. First, they have to determine what they can deliver during a Sprint. To them, Jira is a board with tasks they can contribute to. Product Backlog Typically, the Product Owner creates the first batch of User Stories that are added to a backlog. These stories will be generalized as their main goal is to introduce a certain vector to the development process. Think of it as a place to store concepts and ideas. They may (or may not) become TODOs that will shape the product. You can access your backlog in Jira from the backlog tab in the sidebar. You’ll then have to scroll down past planned sprints. Sprint Backlog According to Jira best practices, after the initial user stories are refined, the team can agree to add them to the Sprint backlog. This is a separate pool of tickets that you’ll be working on during one Sprint. You’ll only want to add those stories that are immediately actionable. You don’t have to cover 100% of the acceptance criteria at this stage, but make sure that the team understands the story well enough to be confident in their ability to deliver the result. Many companies use the INVEST method to set this Definition of ready in stone. You’ll want to move your issues from the backlog to the Sprint backlog in Jira after the Sprint planning session. Story Points Jira issues have a custom field for Story Points. Engineers use them to measure the complexity of a story. The discussion regarding how many stories point a story is worth happens during the Sprint Planning meeting, and the complexity is based on effort, uncertainty (engineers not being sure how they can deliver a feature), and risk. The team will be burning these story points by completing the issues. How does this work? The team discusses the work they need to do before the Sprint begins. Then, all of the stories are reviewed and assigned story points based on their complexity. When the team commits to a Sprint, we know the stories we will be working on and their “worth” in points. The team burns down stories that have met the Definition of Done by the end of the Sprint. Any stories that have not been completed are moved back to the backlog, refined, and potentially re-estimated. These stories can then be moved back to Sprint if the team decides to do so. When this practice is consistent for each Sprint – the team will learn their velocity (the number of story points they typically burn during a Sprint) over time. How Long Should a Sprint Take? A Sprint is always fixed in time. Teams do this to create consistency and accurately estimate the scope they can deliver throughout one Sprint. The nature of Scrum encourages teams to decide the perfect length of a Sprint that works for them based on Empiric evidence. The main point is to understand why you need a time-boxed Sprint. Force prioritization. You start thinking about what is the most important feature you want to deliver when you have a defined time frame to complete a body of work. Demonstrate progress. The timeboxed iterations give an opportunity to regularly demonstrate progress on completed work. This gives a clear understanding of what’s going on in the project to the business side and boosts team morale. Avoid perfectionism and motivate closure. When you have an established deadline for the Sprint, you plan things accordingly. You won’t have the time to try to make things perfect. Improve planning. It’s easier to plan things for an established duration, especially if you have a couple of completed Sprints under your belt and know the scope the team can handle. Continuous feedback. You have an opportunity to constantly give and receive feedback in an iterative and time-boxed Sprint. You can decide on the optimal length of a Sprint. Base this decision on the specifics of the product/project, team maturity, team size, and the factors mentioned above. I would say that the optimal sprint length is when you can deliver a feature within your defined timebox. In this way, all the factors above start working for your team, and you are making the most value of your sprints. Sprint Planning We’ve touched on the subject of Sprint Planning before. So let’s look at it in more detail. The Sprint capacity planning session is the meeting when you decide which tickets should make their journey from the product backlog and into the Sprint backlog. Every Sprint planning session is unique, but all must focus on answering three primary questions: Why is THIS Sprint valuable? What can we deliver during this Sprint? How will we deliver the work we’ve planned? Answering these questions will help you refine your stories. You’ll know their priorities and have an approximation of how much work each of them will require. The trick to Running a Sprint Planning session successfully is making sure that the whole team is prepared. The Product Owner needs to have a clear understanding of Sprint’s goals. They should select the stories for the Sprint Planning session with this concept in mind. The Scrum Master can help by asking probing questions and ensuring the scope doesn’t end up overblown. And the developers can use their analytical skills to try to understand stories, potential solutions, and the complexity of implementation. How To Set up Sprints in Jira Let’s face it, Jira has many issues with its UI. Sometimes finding the right button to enable or start something can be nothing short of a herculean feat. Case in point: finding closed Sprints is a hustle. Luckily, starting a new Sprint is as simple as ABC. Navigate to the backlog from the sidebar and click the bright blue “Start Sprint” button once the issues from your Project backlog are refined, prioritized, and moved to the Sprint backlog. Clicking on the “Start Sprint” button will open a pop-up window where you’ll fill in the details of your Sprint, such as: Name of the Sprint Duration: You can select a desired duration from the drop-down menu Start date/end date And the goal of the Sprint. Note that fields that are marked with a red asterisk are mandatory. Parallel Sprints in Jira Parallel Sprints can be a useful tool when you’d like to run several Sprints from the same backlog. This functionality can come in handy when you want to separate your teams, like developers and designers, while still working on the same goal. Running parallel Sprints is slightly easier in team-managed projects. You can create as many of them as you need from the backlog. Once you’ve created your parallel Sprint – click on the “Start Sprint” button. This will create a new active Sprint in Jira simultaneously. You can then select the Sprint you want to see on the board from the drop-down sprint selector. Setting up parallel sprints in a company-managed project is a bit trickier. You’ll need a user with global Jira Admin permissions. This user can do the following if you are running your instance on Jira Data Center: Select Administration (⚙️) > Applications, then scroll down the page to the Jira Software section. Under Jira Software configuration, select the Parallel Sprints checkbox. And the following steps apply to Jira Cloud: From the global navigation, select Settings () > Products. Under Jira Software configuration, select the toggle for Parallel sprints. ‼️Note: The velocity chart will not show the velocity per team. How To List All Sprints? I’ve seen people trying all kinds of crazy things with “Sprint JQL.” Sometimes it works for them; sometimes, it doesn’t. In my experience, JQL is best used for issues only. However, based on the Sprint field, you can use the following string to list all Sprints and the issues within them. This can be handy when you are looking to review previously closed Sprints. Sprint in (closedSprints(),openSprints()) AND project = “XYZ” Yet, there’s a much simpler way of listing and reviewing your sprints – the Sprint report. The limitation to this convenience comes from the fact that the report is limited to company-managed projects, and it is also board-specific. That being said, it will show you the list of your Sprints along with associated issues. You can use the Sprint Burnup Chart in team-managed projects to achieve the same goal. How To End a Sprint in Jira? Technically, ending a Sprint is a matter of two clicks. First, go to your backlog tab and click on the “Complete Sprint” button. Clicking this button kicks off a different Sprint event – the Sprint Retrospective. This is a meeting where the whole Scrum team inspects how the Sprint went. Use this time to talk about individual performance, interactions, and processes. Try to find ways where you can improve or optimize something or maybe even adjust your Definition of Done. We typically follow a format where each team member lists the “goods” and the “improves.” This format of feedback works wonders as it gives everyone a chance to cherish a job well done while offering an opportunity to voice their opinion on things that might have been smoother. Once you complete a Sprint, your incomplete issues will be moved into the backlog. How To Measure Relevant Sprint Metrics in Jira? While we are on the subject of reports, Jira offers a handy selection to help you analyze your team’s performance to adjust scope or make more accurate plans and estimates for the future Sprint. When talking about Sprints, there are three major reports you should focus on: Burndown chart: This report compares the number of Story Points that are left versus an approximation of an ideal burndown rate. Burnup report: This report is the opposite of the burndown chart. It compares completed work (the number of burned Story Points) versus an ideal burndown rate and the scope. Velocity chart: You can use this chart to plan your future sprints based on the amount of work that is typically done during a sprint. Apps That Help Run Sprints Smart Checklist: A Jira Checklist allows you to build actionable checklists and checklist templates. You can use them to enforce accountability and standardization. The app shines when you need to design and refine your stories allowing you to add clear and visible Definition of Done and Acceptance Criteria checklists to your issues. Planning Poker Online: This tool helps the team assign story points to their issues. The trick is that each member of the team assigns a certain value to an issue incognito. Then, when the cards are revealed, you’ll see whether the team has achieved a consensus regarding the complexity of the task. If you have different opinions – great. There’s room for discussion. The app has a Jira integration which makes it easy to include it in your process. Easy Retro: This App helps run Sprint retrospectives. It offers a board that’s similar to the one you are used to seeing in Jira. The difference is that the lanes are dedicated to things that went well, things that require improvements, and to actionable items or the things you can improve in the next Sprint. Easy Retro also offers surveys that help with gathering feedback.
Engineering success inevitably translates into product success. But how can engineering success be measured? How do teams introspect on the project's progress and find ways to steer through deadlines with software quality intact? The answer is Engineering KPIs. Most managers track engineering KPIs within a specific, contextual framework like the SPACE research. But the model is not omnipresent, and most teams want to evolve further and have personalized goals and trackers in place. Using specific measurement frameworks becomes crucial with constantly evolving engineering teams’ work processes —effort alignment, improving work processes, and maximizing efficiency. But why spend so much time tracking some metrics? Today, we will cover the importance of engineering KPIs and which 10 KPIs you should look for. Why Are Engineering KPIs Important? KPIs or key performance indicators are used to measure engineering success and work progress and ensure all key parts of an engineering project are moving. For instance, if a team's goal is to improve communication, then KPIs could be the number of meetings held to solve blockers, code review score, and PR merge time. Engineering KPIs assist managers to: Track Goals: KPIs allow engineering managers to set specific metrics for project goals. This keeps the teams focused and eliminates deviation. The manager can decide on 3-4 KPIs for each goal and then quarterly or monthly track these for improved work progress visibility. Align Effort: With KPIs, teams can work in a set direction and aim at goal-oriented metrics. With pre-decided KPIs, teams can track their work progress in a specific, quantifiable manner. For instance, when you track the code churn rate, the team can save time and effort on unproductive and experimental codes. Allocate Resources: KPIs are goal-oriented metrics that enable engineering managers to identify blockers and wastages. That's how team leaders can identify grey areas and optimize resource allocation. Improve Consumer Experience: KPIs allow managers to track specific metrics that prioritize the organizational goal. This leads to better product quality and better team cohesion. It results in better customer experience and satisfaction. Increase Efficiency: KPIs identify the blockers in the engineers' workflow, be it burnout, increased code churn, or increased cycle time. The managers can analyze and fix these issues timely with KPIs. Optimize Workflows: KPIs allow the managers to identify bottlenecks in the work processes. So, whenever the devs are struggling, it is easy to point out the right cause. As a result, the managers can optimize the workflows to fix these bottlenecks and boost productivity. The managers should make data-driven decisions to achieve organizational goals with optimum resource utilization. KPIs allow you to use definitive measures to base decisions and improve workflows instead of resorting to ambiguous tactics. Engineering KPIs fill you with the relevant information for finding gaps to make informed data-driven decisions. Now that we discussed why KPIs are important let us see what all KPIs an engineering leader, manager, or team head should track. Top 10 KPIs for Engineering Manager To Get Insights Into Dev Workflow Data-driven decisions are not about looking at some data available and making decisions henceforth. Smart managers align KPIs with the team and organization goals and track them to improve existing workflows. This increases the scope of improvement and helps to achieve organizational goals instead of just daily tasks or individual goals. Here are ten KPIs that engineering leaders shall add to their analytics software. 1. Cycle Time Cycle time measures the time taken by an engineering team to create and deploy a code. It enables managers to analyze the speed and performance of engineering teams. A low cycle time can create healthy engineering teams and boost innovation. A high cycle time can lead to poor dev satisfaction and an inability to achieve goals. Optimizing the cycle time requires work data and insights about engineering teams. Hatica helps managers to track cycle time to identify bottlenecks and accelerate product delivery. They can easily track the time from the start to the code deployment. 2. Effort Allocation Effort allocation is a development strategy where the managers look into how much time to allow for new development vs. quality improvement. Devs continuously working on projects needs to find a balance between new features and improving current products. Teams can alternate cycles of adding functionalities and improving existing systems. 3. New Engineering Hire Ramp Time This metric analyzes how much time a new hire takes to familiarize themself with the running projects. The managers should aim to reduce new-hire ramp time to boost efficiency and productivity. This can be tracked by looking into pull requests by new engineers. The team should be supportive during the code reviews. Overall, the manager should optimize the onboarding process to reduce new-hire ramp time. 4. Dora Metrics Dora metrics involve: Deployment frequency: measures the number of deployed codes. This can range from multiple deployments in a day to once per month or 6 months. Change failure rate: indicates the percentage of low-quality codes deployed that further require improvements. This can range between 0-60% depending upon the team's performance. Mean time to restore or MTTR: time to restore the product or service post any defect. It ranges from 1 hour to 1 week or month as well. Cycle time to track the time period from writing code to final deployment. Engineering teams should aim to optimize the metrics for faster product delivery and customer satisfaction. 5. Dev Throughput Dev throughput includes the number of features or tasks a team ship to production. One way of tracking dev throughput is through: Code churn: measures the code rewritten or deleted within 21 days of merging. Productive throughput: measures the code that didn't churn within 21 days. Efficiency: percentage of code that didn't need any rewriting or deletion. All these combined looks at how many codes were ineffective and led to wastage. 6. Dev Maker Time Maker time is the focus time when an engineer works without any distractions such as meetings, etc. It aims at reflecting the time distribution of an engineer's day. High maker time ensures devs are working on what they love most- code without having to run for meetings and interviews. High maker time is proportional to high developer productivity in an organization. The manager should keep maker time of at least 120 minutes in one slot to ensure devs are unhindered by any external disturbance. 7. Bugs Filed and Resolved Bugs are the number of faults or errors in code or product delivered. It is advisable to document each bug for future reference and quickly fix it in case of recurring errors. 8. Uptime Uptime refers to the duration when the product runs efficiently. It is crucial to maximize uptime for customer satisfaction. In case of prolonged downtime, the customer might switch or create a negative brand image. Engineering managers should figure out bottlenecks and optimize the number of tickets to enhance uptime. 9. Sprint Burndown and Release Burndown Sprint and release burndown indicate the work progress and the amount of work left along with ideal work progress. The release burndown shows the team's progress within all the sprints, while the sprint burndown highlights only the current sprints. It works well for teams with consistent sprint duration as it is easier to collect and analyze data. This helps in work progress visibility and effort alignment. 10. Developer Well-Being Tracking developer well-being is critical for a healthier work environment and managing dev burnout. Only when devs are fully plugged into a project they can deliver work success. However, often due to poor visibility, managers cannot figure out their dev's work patterns and cannot do much to preempt signs of stress or burnout in developers.
AI's impact on Agile Project Management and Scrum Mastery will go from "interesting" to "total game-changer" faster than you think. My team and I have spent years at the intersection between AI and software creation. As a result, we have some fascinating conversations with product managers, product owners and project managers, Scrum masters, and the like. Probably people like you. So I wanted to write about the direction in which AI is taking agile, scrum, and project management. Excellent AI is still very green. Not all this tech is ready, but I will stick my neck out and say it will be in the next six months. TL;DR: Don't leave it until it's too late to explore how to integrate AI safely. Agile Planning Your development team is in the middle of a crucial sprint, and suddenly, an unforeseen issue arises, disrupting the entire project timeline. In tech, such hiccups can cost you dearly in terms of time and resources. Plus, you must figure out how to explain this to management and potentially your customer. But what if AI could help you anticipate and mitigate potential challenges before they even occur? Enter AI-powered predictive analytics. By tapping into historical data and employing advanced machine learning algorithms, predictive AI solutions can analyze patterns, identify trends, and forecast potential obstacles in your project's path. Let me give some examples. Estimations: Human estimates are flawed by nature. We're just not wired to do it. AI will enable realistic sprint planning, release planning, and better resource allocation. Risks: AI will be able to spot risks and bottlenecks far more consistently and – on average – faster than humans can. That means you can mitigate them before they cause problems. Prioritization: AI-powered analytics will be able to prioritize and adaptively reprioritize your product backlog efficiently. There will be far fewer overheads to this process when driven by AI, and it'll spot dependencies and keep everybody strategically aligned on what matters automatically. Collaboration The backbone of any successful Agile team lies in collaboration and effective communication. But keeping everyone on the same page is a huge time drain. Miscommunication (and its consequences) is among the most-mentioned frustrations of the PMs I speak to. That grows exponentially as the complexity (of projects and teams) increases. And that is not to mention the hours out of every day that engineers and PMs spend catching up on Slack or Teams, fishing through old messages to find resources, or working out what work has been done on other areas of the project. That time spent on information-seeking is, for most teams, necessary. But I think AI will turn that "time spent" into "time wasted." Let me illustrate: No more trawling. AI will be able to understand everything happening on every project you're working on and surface the important information from the tools you use, like Jira, Slack, Teams, and GitHub. All-knowing AI. LLMs are now more than good enough to allow you to ask any question you like about project progress, risks, or the like and give you a concise, actionable answer. Fewer, better meetings. For one thing, there should be no need in an AI world to spend time in meetings on progress updates or summarizing data. Instead, meetings will be more strategic and creative. I don't know many people in software who wouldn't leap at this one. Continuous improvement Continuous improvement is inherent to the agile methodology, the agile manifesto. It's all about enhancing your team's efficiency, productivity, and effectiveness with each sprint. I think AI represents an opportunity for a significant shift – or "step up," if you like – in how continuous improvement happens. Let's look at what this could look like for your team. 1. Quality: It's already possible to support processes like code review and deployment with AI, and the development process itself has a wealth of tools available. 2. Performance insights: AI is already available to help you understand your team's performance, identify patterns, and make data-driven decisions to improve your processes. It will be far more adept than humans at everything from high-level insights to highly granular and specific insights. Use them to pinpoint areas for improvement. In addition, it’s real-time and has almost no time overheads, which speeds the whole thing up and means the agile planning process can be far more dynamic. 3. Resource allocation: Make sure everyone is working on the tasks that align with their skills and strengths – or even their opportunity for growth. It's a win-win. You boost productivity, and your foster a more supportive culture. What Next? Let's turn down the hype for a moment. Right now, embracing AI to overhaul traditional project management and Scrum practices isn't an absolute must-have. After all, much of the tech is very green, with many AI tools in Beta or still using old underlying models (like GPT-3, which is fine but isn't going to change the world.) So you’re probably not losing significant ground over your competitors. However, This clock is ticking faster than any figurative time bomb I can remember. It will be a matter of months, not years, before at least partial adoption of AI software development tools is no longer a luxury but a necessity. Adopting and integrating the right tools safely will be the greatest challenge for team members who make decisions about tools for the agile cycle. It's pretty much a full-time job to keep up with advancements in AI.
Building a new version of your product is an exciting endeavor, but it can also be an overwhelming one. In the earliest days of a startup, there tends to be little formal structure in place, which is usually for the best! Everyone’s wearing numerous hats and just trying to get the product and company off the ground. It’s a time of innovation and creativity. When we built the first version of our product, we didn’t have a dedicated product team. That changed with version two, bringing new opportunities and challenges along with it. Through trial and error, we moved through several iterations of workflow, communication, and reporting. The key was balancing input from both the engineering and product teams while also balancing planning and innovation. We learned a lot from this endeavor and, in addition to successfully updating our core offering, gained some important insights about how to set yourself up for success even (and especially) as your company grows. With that in mind, here are my top three tips for success to stay on track as your engineering and product teams grow. 1. Center the User To successfully build a new product, your engineering teams and product team must be in alignment. Of course, alignment can happen in many ways. If you simply have the engineering team taking orders from the product team, it will likely result in a worse outcome. Instead, the best way to align engineering and product is to make sure both are focused on users. Equip both teams with sufficient knowledge about the pain points and needs of users, so they can be checking in with the product from a user perspective on an ongoing basis. Consider a situation where an engineer suspects that following directives from the product team will result in clunky UX. They don’t necessarily have to solve the issue, but they should raise the concern. I’ve seen engineers do this quite effectively — asking if it’s possible to simplify the design, for instance. This speeds up development and, in the end, results in a product that is more valuable to users. By centering users, you’re aligning the goals of both teams and empowering engineers to push back and innovate when necessary, as opposed to simply nodding along and building exactly what the product team suggests. 2. Prioritize Reporting Alignment also comes as the result of ongoing communication. To that end, I suggest implementing a weekly reporting system. When both the product and engineering teams are being vocal about what they are working on each week, it helps everyone stay on the same page and makes the two teams feel more like one. Some updates might include: What are people working on at the moment, and what have they achieved? What else is left? What roadblocks or hurdles have slowed down work or might do so in the week ahead? Once again, both teams should be contributing updates. In the past, there were times in which there was tremendous communication within each team but a lack of communication outside of them. Sometimes, we failed to update the roadmap when a feature was complete. Other times, a product might be released as a minimal viable product, so it was considered complete on the roadmap, but the reality was a little different. Being proactive about, first, making sure the roadmap reflects the reality of the work taking place and, second, making sure communication happens on an ongoing basis is extremely helpful. To make reporting sustainable, choose a platform that’s easy to use. At Prefect, we conduct weekly reporting in a Slack channel. We also sync up quarterly to review larger goals and check our progress against them. 3. Leave Room for Innovation Speaking of the roadmap, one of the most difficult things to balance when the building is how much engineers should stick to the roadmap versus going off-script to build something they’re more excited about. The only way to know if you’re following the roadmap too closely is to have a strong connection with your engineers and to speak with them on an ongoing basis. Ask them: Do they feel like they've got the space to go and be creative, or do they feel like all of their time is taken up with roadmap items and prescriptive work? Of course, there are times when you need to follow the roadmap almost exactly, whether because of a deadline or user demands. When the roadmap has been disclosed to the board and current customers, swaying from it can be more challenging because several audiences are counting on the agreed-upon direction. At the same time, being too prescriptive about particular features can be really harmful to both the product and the morale of the engineering team. A 50/50 balance is a good goal. Is about half of your engineering team’s work creative or self-directed, or are they simply managing requests and checking boxes? The Bottom Line New workflows can feel daunting, but they’re also opportunities. If there’s one key takeaway, it’s that balance is paramount. As your product and engineering teams grow, it’s imperative to strike the right balance between adhering to the roadmap and allowing for creativity. But the first two tips— ongoing communication and alignment (by having everyone focus on the user) lay the foundation for finding this balance. That’s not to say challenges won’t arise. But with the help of these tips, your product and engineering teams will be better suited to handle them — and primed for making the best possible product in the process.
Is self-management an essential building block on an organization’s path to business agility or a nice-to-have cultural twist to, for example, keep teams happy and attract new talent? While many people, particularly at the management level, are skeptical about the concept, I am convinced that organizations need to descale and regroup around aligned, autonomous, self-managing teams in a complex environment. Ultimately, only the people closest to the customers’ problems can solve those within the given constraints while contributing to an organization’s sustainability. Please continue reading and delve into the reasons that support self-management. The Top Ten Business Reasons To Embrace Self-Management Here are my top ten reasons why self-management is essential for developing new products in complex environments and addressing customer needs: Increased innovation: Self-management fosters a culture of creativity and experimentation. Team members are empowered to take risks, try new ideas, and learn from failures, leading to more innovative solutions for customers. Greater adaptability: In a complex environment, change is inevitable. Self-managed teams are more agile and can adapt to new situations, pivot their approach, and respond to customer needs more effectively than traditional hierarchical teams. Improved communication: Self-management promotes open and transparent communication within the team. Transparency ensures that information is shared effectively, leading to better collaboration and problem-solving. Empowerment and autonomy: Self-management empowers individuals and teams to make decisions and take responsibility for their work. This autonomy leads to higher job satisfaction and increased commitment to the organization’s goals. Moreover, it attracts talent from other organizations. Faster decision-making: Self-managed teams can make decisions quickly without waiting for approval from multiple levels of management, accelerating the development process and enabling more immediate responses to customer needs. Better problem-solving: Self-managed teams work close to customers and have a deeper understanding of their needs. This proximity enables them to identify and address problems more effectively than a management-driven approach. Resilience and risk mitigation: Self-managed teams are better equipped to identify and address potential risks early in development. This proactive approach to risk management helps build resilience and ensures more predictable outcomes. Continuous improvement: Self-managed teams focus on continuous learning, improving, refining processes, and iterating on products within the given constraints of the organization. This commitment to constant improvement ensures that products evolve to meet customer needs. Higher engagement: When team members own their work, they are more engaged and motivated. This ownership leads to increased productivity, better quality work, and a more substantial commitment to meeting customer needs. More efficient use of resources: By allowing team members to allocate their own time and prioritize tasks, self-managed teams can use resources better, improving productivity and reducing waste. Now that we have established the usefulness of self-management from a business perspective, the question is: how do we get there? (Spoiler alert: Your teams won’t become self-managing by contracting McBoston to roll out a new initiative.) Why the Change to Self-Management Cannot Be Outsourced While external consultancies may support your organization’s effort to become an agile organization due to their broad experience with other clients, real change can only come from within an organization. Any change effort needs to include people, give them a voice, and convince them that change is in their best interest: “Agile” cannot be pushed; it needs to be pulled. Consequently, avoid relying on external consultants. Instead, to foster self-management within the organization, consider the following suggestions: Redefine leadership roles: Shift the focus of management from controlling and directing to supporting and enabling teams. Managers should help remove obstacles and provide resources for self-managed teams to thrive. Managers need to move on from problem-solvers on behalf of their teams to become servant-leaders who strive to make their teams successful. Internal agile champions: Identify and empower individuals with experience or interest in agile practices. These internal champions can advocate for and drive the adoption of self-management practices across teams. Agile training and education: Invest in training and education for employees at all levels, including workshops, online courses, or even certifications, to help them better understand and apply agile principles and self-management practices. Coaching and mentoring: Encourage experienced agile practitioners to coach and mentor others, helping to create a culture of learning, sharing, and fostering the growth of self-managed teams. Foster a culture of trust and transparency: Encourage open communication and collaboration across all levels of the organization. Transparency will build trust among team members and empower them to take more ownership of their work. Regularly inspect and adapt: Conduct periodic Retrospectives and assessments to gauge the progress of self-management adoption. Use the insights gathered to inspect and adapt the approach, ensuring it aligns with the organization’s unique needs and culture. Incremental adoption: Start small by implementing self-management practices in a few pilot teams. Learn from their experiences and gradually expand self-management adoption to other teams as they become comfortable with the new approach. Encourage cross-functional teams: Form cross-functional teams that bring together individuals with diverse skills and backgrounds. This encourages collaboration and knowledge-sharing and fosters self-management. Provide the necessary tools: Equip teams with the tools and resources to collaborate, plan, and track their work effectively. This could include agile project management tools, communication platforms, and continuous integration and deployment systems. Celebrate successes and learn from failures: Recognize and celebrate the accomplishments of self-managed teams. At the same time, encourage a culture of learning from mistakes and iterating on processes to improve continually. By focusing on these strategies, an organization can foster self-management among its teams and embark on its journey to become agile. Conclusion Self-management is essential for developing new products in complex environments and addressing customer needs. By embracing self-management, organizations can foster innovation, adaptability, and a stronger customer focus, ultimately leading to better products and satisfied customers. Moreover, adopting self-management also offers tangible benefits to shareholders by increasing efficiency, promoting innovation, and enhancing adaptability, ultimately driving growth and success for the organization. What is your experience with self-managing teams? Please share with us in the comments.
I’d like to share a complete guide to how to hire and interview engineering managers. I’ll cover every step of the process and even include a sample interview plan you can use. I think you’ll find a lot of surprises and some genuinely useful templates and questions to use. This approach can be used for other roles as well. Figure Out What Role You’re Interviewing For First of all, you need to be really clear on what you’re looking for. Hiring an “engineering manager” isn’t actually possible. There are many different ways that role is defined. So you need to figure out the role you’re actually hiring for. I have a post on the many forms of Engineering Manager. Read it, and figure out the areas of responsibility for your engineering managers. Determine Which Assertions You’re Making After you’ve figured out what archetype of manager you’re hiring, you next need to write down the specific qualities and skills you’re looking for. I call this “assertion-based interviewing” because you’re making a list of things you would like to assert are true about the person you’ll hire. A few example assertions are: Has product engineering experience in a startup environment. Understands our product area well. Shows an ability to break down projects into smaller pieces that can be incrementally delivered. Each of these is an area you’d like to assess with the candidate. But you can’t do everything, so you’ll need a list of prioritized assertions you care about. You can read about how to create a list of assertions, and this general approach, in my post on Coordinating your interviews with assertion-based interview plans. Create the Interview Format Your next step is to design the interview flow. If you’re working with an internal or external recruiter, they’ll probably be the first person the candidates talk with. What steps happen after that? You should have as few steps as possible. So, I like to define interviews with these steps: Others will often insist on adding steps. For example, a founder or VP might want to interview finalists. Ideally, you will have three steps, but four can be okay. If you’re getting above that, your process is too onerous. Note that sometimes you’ll schedule the final interviews over multiple days. To save time for your interviewers, you can add a “circuit breaker.” Do a quick evaluation of the candidate after the first day. If it’s trending really poorly, stop the interview from proceeding to the second day. Create an Interview Plan Based on the type of Engineering Manager, and the list of assertions you’ve come up with, you can then define an interview plan. You can start with my template for an Engineering Manager interview. This is based on an Engineering Manager interview for someone that is responsible for People, Projects, and Process. You will want to modify this based on the role and your individual needs. Start from my template. This is for Engineering Managers that are responsible for People, Projects, and Process. You can modify it as you see fit. Determine Who Will Do the Interviews After you’ve put together a draft of the interview plan, you’ll need to put people against each of the interviews. I recommend pairing people on interviews. Although it’s expensive to do so, I find that people often get into a rut with how they interview. Then their practices won’t improve, and you’ll get weird results from your interviews. Pairing also increases the number of people that are trained to interview. And you can ensure that good notes are being taken. You’ll also learn a lot from interviews where the two people present give different feedback on the candidate. I had an interview recently where two people interviewing a candidate at the same time ended up giving completely opposite feedback: a strong yes, and a strong no! You can learn a lot from that. Become Best Friends With Your Recruiter Set up some time with the recruiter you’re working with. And talk through the interview process. Make sure you’re really clear on who will be doing what. I’ve found a wide variety in the expectations of recruiters. Some do a lot more than others. The best recruiters I’ve worked with can own parts of the process for you and have a good mind for improving that process continually. Other great recruiters have been able to take on an increasing amount of screening interviews. But there are also a lot of different places a recruiter can focus, and you should be clear on how much they’re doing sourcing, candidate screening, scheduling for candidates, and so on. I usually set up weekly half-hour sessions to talk through how things are going and make improvements. One thing I like to do is to request a few things from the recruiters that can speed up the whole process. This ultimately can make them more successful because it can reduce the amount of time it takes for them to fill a role. And that’s often something they’re evaluated on. But it can also demand a lot of their time, which can reduce their ability to focus on the role. But I have a list of things I’ve seen improve hiring speed that I like to float by them whenever I can. Set up Communication Channels per Role At a recent role, a recruiter suggested that we set up a Slack channel for each of the roles we were interviewing for. We were having a lot of communication that was happening in side channels. This streamlined our communication significantly and is now something I recommend. It’s important to set up expectations for what can be communicated in the channel. For example, you don’t want people biasing other candidates. But typically, that’s not a major challenge. Then Do a Kickoff, Where You Go Through What You’re Looking For Whenever I introduce a new role we’re interviewing for, I like to do a kickoff meeting. It’s typically an hour-long meeting where I talk through the position. I talk about what we’re looking for and go through the interview plan. I do sometimes schedule this after we’ve kicked off interviewing because it can be difficult to schedule so many people. But it’s important to get this in place within a week or so of the role being opened. Schedule Time To Meet With Each of the Interview Sections, Go Over the Interview and Customize It Together After I kick off the interview, I aim to meet with all the interviewers and go through their part of the interview. And ask them to refine their part of the interview. Honestly, I sometimes skip this step or schedule it a few weeks later. But I think it’s important. Why? You want to make it clear to the interviewer that they own their portion of the interview and that they can alter the format of the interview. And this extra step will result in improvements to the interview that will pay off in the quality of the assessment. After Each Screen, Calibrate With the Recruiter I’m usually the person doing the hiring manager screen. Sometimes the screening interview doesn’t go well. At those times, I look for any signals that I can share with the recruiter. I like to share my feedback after every screen with the recruiter. So I’ll post my notes, then say whether or not the candidate will proceed to the next steps. And most importantly, if they didn’t proceed to the next step, I try to mention anything that would be helpful to the recruiter as they’re talking to future candidates. For example, I might say: “Interview with Lisa went quite well. Proceeding to interview” “I’m passing on Ari. Nothing I can think of that we can calibrate on in future recruiter screens – they seemed like a reasonable candidate”. “I’m passing on Jeff. He didn’t seem like he had enough experience in unstructured environments. That might be worth screening for in the future. Let’s talk on Wednesday about that.” After Each Final Interview, Do a Debriefing Session Most debrief sessions on candidates are dull affairs. Instead of just reiterating the feedback everyone wrote down, use this candidate debrief session format. My goal is to get a good signal on whether a candidate should go to a larger, more expensive interview. So, I view the hiring manager screen as a shallow version of the whole interview. So after each debriefing session, I consider whether I need to tweak my screening interview. I’ll often learn about things I could be screening for. For example, if I see that I’m not doing a good enough job screening the technical skills of candidates, I might talk with the person doing that interview and figure out what I can ask during the hiring manager screen. Thank You The idea of a communication channel per role is something Mailani Burton came up with when we worked together.
We are all well aware that better interaction is essential to the success of any project. Along with adhering to Scrum Values, the expectation for Scrum teams is to have seamless communication and improved team collaboration. As a Scrum Master, I’ve worked with a variety of teams that have distinct dynamics. Some were extroverts, while others were introverts. Let me clarify that an introvert is not someone who never communicates or is always silent. An introvert is someone who prefers to be silent because of some reason. Introverts can also be excellent leaders. Before we can discuss improving the communication of introverts or less communicative team members in our Scrum teams, we must first define the terms “introvert” and “extrovert.” Given that we’ve already discussed introverts, I’d like to add Simon Sinek, who mentioned Susan Cain and her definition in one of his talks. “It is about energy; An introvert loses energy in social interaction, an extrovert gains energy from social interaction.” An introvert wakes up in the morning with five coins. With every social interaction, they spend a coin. At the end, they are depleted. An extrovert wakes up with no coins. With every social interaction, they gain a coin. At the end, they feel rich. Returning to our original topic, let’s talk about the dynamics of introverts in Scrum teams and how Scrum Masters can help them so that they contribute more effectively in terms of on-time communication and collaboration. As a Scrum Master, you’ve probably seen situations where, during a user story/requirement walk-through, whether in Sprint Planning or Backlog Refinement session, a few team members would not even speak up or put forward their views for any questions or to give their opinion on a particular discussion. Sometimes you don’t even know if they exist (thanks to virtual calls and working from home) or if they really grasped the real ask from the customer. The real reason is they may be struggling to communicate how they feel, and they may have wanted to say something but are afraid to talk. BUT…do you understand they’re SHOUTING very loudly…Yes, a deafening sound that we cannot hear on the outside but inside their heads. Wanting to convey their thoughts and inner feelings but unable to do so due to a variety of factors such as fear, hesitation, believing that the question is irrelevant, and so on. Most of the articles I read or videos I watch about what the Scrum Master should do in these situations are somewhat startling to me, and I completely disagree with them when they suggest not intervening during the main Scrum events and other meetings like Sprint Planning, Daily Scrum, and Backlog Refinement sessions. As we know, Scrum Masters are more than just servant leaders or facilitators; they are True Leaders as per the latest Scrum guide. So, as a Scrum Master to your Scrum teams, be an anchor while also being a strong speaker when necessary. Intervene and ask if they need any more inputs from the PO/BA, such as screengrabs, attachments, wireframes, clarifications on acceptance criteria, and so on, to remove any ambiguities and unknowns at the beginning of the Sprints and allow them to identify any risks or dependencies before beginning design, development, or testing. Pre-Covid, almost all of the teams had face-to-face interactions, so it was simpler to understand the teams’ body language or inhibitions. However, most teams are still working virtually post-Covid, and it is extremely difficult for anyone to understand the intent of someone on the other side of the virtual call window. Some of us are already making efforts to get these less communicative Scrum team members to open up. We are attempting to put ourselves in their shoes, assisting them in understanding that you are always available to them and coaching them by referring to Scrum Values, as well as encouraging them to speak up during key discussions. Until this point, it is understood that every Scrum Master can ask questions during the backlog refinement and Sprint Planning sessions to determine whether these individual team members are clear with the clarifications, and one can also motivate them to open up, be collaborative, and let the communication flow. But, as I previously stated, there will be some individuals who are hesitant to speak during meetings and who do not understand the requirement during walk-throughs. One simple reason could be that they believe it is too early at that stage to ask any questions, but this is just one of many reasons. Let us continue to coach them to be open during calls or emails with the PO or any of the other Scrum team members. Also, advise them to interact during the calls, even if it is not an excellent point, and to not be overly concerned with their language at the time, but to simply put out their questions and see whether they are speaking in context with the requirement or not. Team members that are introverted by nature will take some time to understand when we try to coach them on better team communication. They may also feel offended at times because it is impossible for anyone to abandon their natural tendencies and demonstrate a complete change in character all at once. Furthermore, today’s teams include members from a variety of cultures, locations, and ages. Also, like Scrum, we all agree that any change in behavior will occur only empirically. My main goal is to accomplish it in a way that I’ve been doing for a long time, and I have seen a good success rate. So, what are our other options? How do I do that ?… … After every Sprint event (and sometimes even Daily Scrum), I would have a regular, in-person, face-to-face connection with these team members to see if they had any unknowns or ambiguities in understanding the requirement or if they had any other issues. By demonstrating empathy with clean language and clear communication, I aim to provide confidence and ensure they feel psychologically protected. I’d also ask whether they require any special assistance from other team members or another walk-through from PO. I never directly ask them to change their nature or character, but I do encourage them to improve their social culture by attending training such as Social and Communication Skills for Introverts, encouraging them to try and make new friends within teams or organizations, and motivating them to be a part of meet-up groups either in-person or online. Personally, I believe that the points described in this paragraph are important and close to my heart because I have done these things for myself and have observed some progress in myself. Yes, I’m a natural introvert. If the readers believe any of these suggestions will be beneficial for your coaching, begin initiating with your uncommunicative team members and try to discover the reasons for their lack of responsiveness. As they become stronger communicators and team collaborators, continue to assist them in establishing the Scrum values of Commitment, Focus, Openness, Respect, and Courage. It will also make it easier for the other team members to work with these persons in a comfortable environment. And without a doubt, this will be an enabler to the project in accomplishing the Sprint goals and Increments.
Nowadays we live in a world ruled by trending topics, and sometimes we forget the basics like being more effective and productive. I see more and more how companies' technology leaders look for new technological products or new architectural patterns to solve the company's needs, and they forget that working hard can provide strong efficiency principles for their organization. Have you ever wondered how many hours your team works on irrelevant or unnecessary tasks? Squads and engineers are usually people involved in their work and make a great effort to achieve their goals, but many times a large part of this effort is dedicated to tasks without any business impact. C-levels, engineering managers, or tech leaders should be focused on increasing engineers' productivity. Effectiveness and productivity can be increased with the help of ChatGPT, Data Mesh, or Cloud, but you can also increase it by promoting a strong company culture oriented to increasing focus time for our engineers. In the last few months, I have also seen a wave of companies that are requesting their employees to come back to the office, as they have realized remote work is not efficient. In my opinion, the problem is that we have brought the inefficiencies of the office to remote work and sometimes we have even increased them. Main Noise Generators There are several noise generators in our day-to-day. The following are the most important: Message systems such as Slack, Discord, or Teams. Meetings: People love them. The emergent tasks: Everything is important and urgent. Message Systems A few years before the pandemic, message systems such as Slack, Discord, or Microsoft Teams were not the main communication channel for companies that did not work remotely. The main communication channels were email, phone calls for urgent issues, or to go to a workmate's desk: Managers spend a lot of time reviewing emails and replying to them, but always in an asynchronous way. At the office, managers or principal engineers had always people sitting next to him/her solving doubts three or four times a day. In those days and for the engineers of those companies, working at home meant an amazing amount of focus time. The world has changed a lot in the last few years. Many companies have adopted remote work, but not many of them applied any good practices; they projected their way of working in the office to the remote model. In addition, nowadays, we are continuously unfocused because of mobile and social media applications, and unfortunately, this is being transferred to society as a whole and to the way we work. New message systems are great communication tools that make communication easier and more effective. If we were to use these tools in a good way, we could increase productivity. But often these tools generate a lot of noise and unfocus people's attention. These are some of the symptoms of improper usage: There are too many messages all day in general channels. People usually reply the messages instantly. Several engineers of the same squad reply to messages during the same hours. Requests, incidents, and emergent tasks are requested and resolved in global channels. We do not have to stop using them, but we do need to use them better and try to guarantee focus time for our teams. The message systems have to be an asynchronous chat for most of the team, and of course, there are special cases like support teams or on-call engineers that should be focused on the chat. Tips to Improve Some recommendations to improve efficiency: Reduce and optimize the number of public channels, since the more channels there are, the more noise is generated. Set times for posting messages on general channels regarding global communications, for example early in the morning. On the public squad channel, always establish an on-call person. It is a fully asynchronous system, except for the channels used for on-call and incidents. Policy for muting non-priority channels. Meetings There are three main characteristics of meetings: People love to create meetings because it is a way to socialize. Meetings kill productivity. There is always time for another meeting. This problem has increased a lot with remote work. At the office, these meetings were usually done in the meetings rooms so there were physical restrictions. If there were no available rooms, there were no meetings. Remote work and the new communication tools have eliminated these physical restrictions, so now there are more meetings than ever. These are some of the symptoms of improper usage: Often several people are not paying attention or participating in the meeting. Many brainstorming meetings. Managers with a full calendar of meetings. Many mid-morning meetings. People do not come prepared for meetings. No documents or very long documents, without clear goals, business value, or impact analysis. Many meetings with more than 6 people. In addition to sharing the agenda and goals, it is a good practice to write a summary of the contents and share it before the meeting. This helps people to establish the messages they want to convey and the rest of the participants to prepare for the meeting. Often this prevents the meeting and can be solved asynchronously. Here is an exercise to check the productivity of the meetings we have in the coming week: On Monday morning, we have to review all the meetings scheduled for the next 7 days. We are going to create a table with the following information: Meeting name. Meeting description. Date and duration. Number of people Are the agenda and goals indicated? What are my goals for this meeting? Were the meeting goals achieved? Were my goals achieved? Has a follow-up meeting been scheduled? Good and bad decisions were taken in the meeting. What do we need to improve at the next meeting? After a month, analyze the results and share them with the team. Tips to Improve Some recommendations to improve efficiency: Set hours of guaranteed focus time without meetings. For example, if everyone works in the same time zone and similar hours, avoid meetings in the mornings. All meetings must have a previous document summarizing the topics to be discussed, who is responsible for each point, what is the goal, and the information required to work on it. The premise of resolving points in the asynchronous model should always be applied and the meeting should only be scheduled if it is really necessary. A clear example is the reporting meetings; you do not need to create meetings to analyze the progress. Firstly, you should review it asynchronously, and if you have doubts that require a meeting, then you plan it. If the meeting is not prepared, it is better to cancel it even during the meeting. Don't worry about being honest. Unprepared meetings are useless. Reducing the number of meetings requires difficult decisions because most of them love to meet. Emergent Tasks These tasks are unplanned but can be very important. All teams have emergent tasks, usually, operation and support teams have more but engineering teams work on product development too. The following tasks are an example: Security bug. Incidents with business impact. Request from the manager. Support to clarify customer questions. Unplanned tasks change the focus of the team and often involve significant cognitive changes. There are four main problems in managing these tasks: Are always urgent for the person requesting them, and sometimes it is difficult for teams to know what the real priority is. generate chaos, often a large part of the team is working on them. When they are extended over time, they generate a lot of demotivation in people. A lot of time is dedicated to tasks that have no business value or high impact. We have to define a management model for these types of tasks that will end up generating a big impact on the team both in terms of effort and value delivery. The time of our teams is a limited resource and should be invested in tasks that add business value. There are many tasks that if we don't execute, surely no one will ask about them. Tips to Improve It is important that these recommendations are aligned with the company's OKRs and agreed upon at the company level: Allocate a percentage of weekly effort dedicated to this type of task, except for serious incidents with business impact. Assign a rotating role for the management of such tasks and prevent them from impacting the focus of the team. Define a must information for this kind of request such as: Summary Description Priority Business impact Expected resolution date Alignment with OKRs Define a decision matrix to determine what is important and what is not. The Eisenhower matrix is a good example method for prioritizing tasks. Conclusions I see many companies requesting their engineers to come back to the office and abandon remote work stating that employees are less productive. Many CEOs are analyzing how new AI solutions can increase the productivity of their engineers in many cases without having analyzed or tested the real value of these solutions on engineer day-to-day, I don't think these are the only solutions but the easiest and most obvious ones to choose. More focus time means more productivity and that should be one of our goals as managers. Promoting a culture in our organization where the focus is an important part is key to achieving success in the most optimal way possible. Productivity starts primarily with the C-levels, directors, and managers because they are the main ones responsible for promoting culture and also one of the largest generators of noise.
Considering a lot of demand for the various skill sets of people for upgrading existing systems or for new projects, it is very challenging to prepare the best team for the project. A few successful processes could improve the situation; I have listed some of them below and hope they are helpful. Self-Awareness The most important aspect of learning is self-awareness. As a leader and an individual, the team must know the strengths and areas of improvement. Learning begins only when you are aware of your weakness. Once you know, there are weaknesses; the situation will never allow you to sit on them. Instead, it will continuously push you to take steps to come over weaknesses. Retrospective Once you are aware of strengths and weaknesses, you could take retrospect and find out more about the areas of improvement. The retrospective is a very important process about yourself, the team, and the existing process, and learning from it is a foundational requirement for success. It is important to have data on the strengths and weaknesses of your team so that you can define the best strategy and lead the team to success. Product Roadmap and Industry Trend As an individual and as a team, you could be in a perfect situation considering the current requirements of the industry or customer needs. However, the skill gap analysis must be done considering your future industry trends and customer needs. As an example, there is a buzz about AI/ML; it could be ChatGPT or any other similar trends. Assessing yourself in such contexts will give you a better sense of the skill gap. You and your team would be doing great with on-premises deployment architecture; however, the industry trend would be on cloud development. Questioning yourself on your team's skill set related to the cloud would give a sense of the skill gap. Training Approach 1. Data Collection and Identifying the Gaps Identifying the current skill set of your team through surveys, team meetings, and capturing the data, as explained below. By keeping yourself or a team member or a process in the center and analyzing the strength and weaknesses, list down strengths and weaknesses. The process can be as follows: Prepare the Roster (people or processes) Programming Skills Project Management Skills Soft skills Design and Architecture Status of the team member (Beginner, Developing, Mastered) for the skill. While preparing the list of skills to measure must consider two aspects: Current Requirements Future Requirements Update the status for all the team members. Once the skills level data is captured for all the team members, it is important to make them into buckets like current demand and future demand. 2. Define the Learning Paths Based on the categorization of the skill gaps, you can define the learning paths. Using your L&D tools, you can assign these learning paths to your team members to complete them. To make it effective implementation, reward and recognition is one of the important tools 3. Learning Partnership In case you are not equipped with content, you should identify a partner who can provide the content required for your skill gaps. 4. Learning Path Types Upskill The upskill learning path is mainly focused on learning new skill sets, but they are in the same domain of expertise. For example, the developers could be learning languages and tools required for the new requirements. Training is an important aspect of team development. We must have a predefined set of training for the team member's growth based on the skill gaps. We should continuously run them to be prepared the future requirements. Tools and technologies are changing so rapidly, and we need to keep team members ready for the new skills required by the customer. Training can be two methods: Internal External Every team usually has a few people enthusiastic trainers by nature; we should identify them and encourage them. They are generally very passionate about training. It will help both from an organizational perspective and also achieve efficacy in the training. The internal training concept will help to develop leadership and communication skills for the team members. To make the best use of external training, it is important to prepare the team on foundations so that the training can be utilized effectively. As part of internal training, we should encourage learning by motivating team members to learn and share concepts. This builds strong bondage among the team members. Once team members have understood the concepts and basics through our internal training, we could hire external trainers/specialists to train the advanced or specialized topics. With this approach, it will have two advantages: Team members are ready with basics and can absorb advanced topics easily. Less expensive and deep dive. Reskill The Reskill learning path is mainly focused on training your team members on the new domain of expertise. The leaders/Managers must try to identify potential team members who are ready for the next positions. They will be doing a fantastic job and achieving mastery in their current role. We must identify them and reskill them by providing the necessary training required for the next role. It will help them to understand the next role more effectively, and will be successful in the next role. Many times, the people who are successful in their current role will be failed in the next role. It is mainly because the requirements for the next role might not be the same as the current role. We must support them by providing the necessary training for the next role as well. Keeping the skill matrix up to date, upskilling, and reskilling the workforce will help embark on new projects with different skill set requirements. It will also help in building next-level leadership for the organization.
Gene Kim
Author, Researcher, Speaker, Director, DevOps Enthusiast,
IT Revolution
David Brown
Founder and CEO,
TORO Cloud
Otavio Santana
Software Engineer and Architect and Open Source Committer,
Zup
Tanaka Mutakwa
VP of Engineering,
Names and Faces