Team Management

Three primary methods for measuring team productivity are the SPACE framework, DORA metrics, and Goals/Signals/Metrics (GSM). The SPACE Framework for Team Productivity In a recent research paper by Nicole Forsgren and her colleagues, “The SPACE of Developer Productivity" (2021.), the authors defined a framework as a systematic approach to measuring, understanding, and optimizing engineering productivity. It encourages leaders to take a comprehensive approach to productivity, communicating measurements with one another and connecting them to team objectives. The five aspects are used to categorize engineering productivity, called the Space Framework. S: Satisfaction and Well-Being Here, we measure whether our team members are fulfilled and happy usually by using some surveys. Why do we do this? Because satisfaction is correlated with productivity. Unhappy teams that are productive will burn out sooner rather than later. P: Performance This is also hard to quantify because producing more code in a unit of time is not a measure of high-quality code or productivity. Here, we can measure defect rates or change failure rates to measure it, which means the percentage of deployments causing a failure in production. Every loss of output will harm the productivity of a team. Also, if we count the number of merged PRs over time, it's correlated to production. A: Activity Activities are usually visible. Here, we can measure the number of commits per day or deployment frequency, i.e., how often we push new features to production. C: Collaboration and Communication We want extensive and effective collaboration between individuals and groups for a productive team. In addition, productive teams usually rely on high transparency and awareness of other people's work. Here, we can measure PR review time, quality of meetings, and knowledge sharing. E: Efficiency and Flow With flow, we measure individual efficiency to complete some work fast and without interruption, while efficiency means the same but on the team level. Our goal is to foster an environment where developers may experience and keep the flow for the longest possible period each day while also assisting them in feeling content with their routines. To implement the SPACE framework, the authors recommend aligning three areas with company goals and team priorities. First, when a team selects a measure, this reflects team values. Here, we want to start from team-level metrics, and when we succeed, we can roll it out to the broader organization. Example metrics (“The SPACE of Developer Productivity,” N. Forsgren et al., 2021) DORA Metrics for Team Productivity One other way to measure team productivity is DORA metrics. With these metrics, we are evaluating team performance based on the following: Lead time for changes is the time between a commit and production. Elite performers do this in less than one hour, while medium performers need one day to one week. Deployment frequency is how often we ship changes. Elite performers do this multiple times per day, while medium ones do it once a month to once every six months. The mean time to recovery is the average time it takes your team to restore service when there’s an outage. Elite performers do this in less than one hour, while medium ones do this in a day to one week. The change failure rate is the percentage of releases that result in downtime. Elite performers are 0-15%, while medium performers are 16-30%. The lead time for modifications and the deployment frequency reveal a team's velocity and how quickly they react to the constantly changing needs of consumers. The stability of service and how responsive the group is to service outages or failures are indicated by the mean time to recovery and change failure rate. Comparing all four essential criteria, one can assess how successfully their company balances speed and stability. Goals/Signals/Metrics (GSM) For Measuring Developer Productivity Yet, there are other productivity frameworks, too, such as “Goals/Signals/Metrics (GSM)” metrics from Google. In this framework, you first agree that there is a problem worth solving, then we set a goal on what we want to achieve and decide which statements, when actual, would note that we are making progress (signals). Finally, we arrive at metrics we want to measure but focus more on the desired outcome, not just the metric. For example, the goal could be “Make sure that engineers have more focus time,” signals could be “Engineers report fewer cases of meeting overload,” while metrics could be “Engineer focus time.” For metrics, you can build a team Dashboard that will collect them in one place, so it’s easy to analyze them. You can check out this video from Google if you'd like to learn more about this method.

Hiring junior engineers is challenging. I’ve seen so many junior engineers get hired but then be supported poorly. There is a lot to write about this topic, but today I’d like to highlight a wonderful writeup by John Hyland on what is the best example of new engineer hiring I’ve encountered. John set up and ran the “Ignite” program for several years, and shares how it ran. It’s kind of perfect! How the Ignite Program Works The junior engineers are hired (either in cohorts or continuously). They go through a project-based onboarding for two weeks. The project is designed to introduce the basics of working with internal systems: Git, JIRA, standups, code reviews, retros, and so on. They’re assigned mentors. They go through several rotations with teams. These last for several weeks. They work on real work for those teams, contributing in a couple of defined ways. They have various social and networking meetings, such as an alumni event, so new engineers can see what it looks like to be successful and also build social connections within the company. After a few rotations, they’re placed on a permanent team. There are a lot of interesting hacks they used to make this program work, so I highly recommend it if you’re interested in the topic! What I like best about this program is it just seems so effective: Advantages for Companies Save money: These programs can pay for themselves. It’s less expensive to hire newer engineers. If successful, these programs can make it possible for engineering organizations to tilt hiring towards less experienced engineers, potentially saving significant amounts of money. Companies that are able to more successfully harness less experienced engineers will have a competitive advantage over other companies, due to improved cost efficiency. New engineers can have a higher retention rate than those with inferior onboarding. Better value delivery: Better onboarded engineers will deliver value sooner and better, producing more value. The program increases internal connections within the company and across teams, which can lead to innovation and better collaboration. Onboarding can be a way to address high importance, but low criticality work, like tech debt. This can improve long-term company performance because these things tend to drag down long-term delivery if left unattended. Companies can benefit from greater internal diversity (which has been shown to improve product quality and decision-making). Less disruption: New engineers are better-oriented and less disruptive to their teams. They’re able to contribute almost immediately. Advantages for New Engineers They are more likely to succeed. They feel more valued because they’re contributing more to the company. They understand engineering processes so feel less disoriented as they join teams. They are a better fit for their teams because they’ve had the chance to see a couple of options. They have a cohort of fellow junior engineers they can network with and get support from. Advantages for the Industry Creates a better pathway for engineers to succeed and grow: The trades have well-established apprenticeship programs — these could fill a similar niche in software. Improves diversity and inclusion in our field Applicability This program is most appropriate for medium-sized companies or larger ones, but it mostly depends on how quickly you’re hiring. At New Relic, we did it when we were well over 60 teams, but it could be done at an earlier stage. “If you hire at least 20-30 engineers annually, it’s likely that 10-15 of them could be early career, which is easily enough to justify putting some resources into doing a good job with it… That’s a higher ratio of early career engineers than many companies go with, and depending on the specific kind of engineering the company does, that may be reasonable. So, you’ll want to adjust those ratios to whatever you’re comfortable with, and consider what resulting hiring rate is needed to warrant an early career hiring program based on your particular circumstances.”- John Hyland That said, a lot of the lessons from this can be applied to earlier-stage companies. I think the design of this program is a really good thing to emulate. Further Reading To read John's three-part series, you can start here: "Running New Relic’s Ignite Program, Part 1 - Hiring". Thank You John Hyland is a former colleague of mine and the author of the post I feature here. Contact them if you’re interested in further details after reading this post. I suspect they’d jump at a chance to do similar programs at other companies, and even to help others who are doing so.

Starting a new company is difficult. How difficult? So difficult that an estimated eight out of ten don't last beyond their fifth year. For software development companies, things may be even harder than that. The reasons for that are manifold. For one thing, many software development firms depend on a single product to fuel their bottom lines at the outset — and there's quite a bit that can go wrong with immature software products. That reality means that anyone running a software development startup has to execute a perfectly choreographed high-wire act if they want their company to survive long enough to thrive. Doing that, however, requires vigilance, powered by as much real-world operational data as possible. However, not every software development startup knows which KPIs to watch to gauge their overall health and odds of success. To remedy that, here are the three most relevant KPI categories to software development startups and five specific KPIs every one of them should track. The Three Relevant Types of KPIs Broadly speaking, the KPIs that software companies should track fall within three major categories. They are: Performance Metrics This is the KPI category that encompasses every facet of the company's operations. It includes things like productivity metrics, project completion metrics, and efficiency statistics. Together, this category helps the business get the most bang for their budgetary buck. Financial Metrics This KPI category includes everything there is to know about the company's financial condition. It includes things like net profit metrics, budget accuracy metrics, and revenue statistics. It's the category that gives managers a broad view of the company's overall health. Customer Metrics For early-stage software startups, the customer metrics KPI category won't be too complex to track. This is because most software startups only have a few key customers to speak of. However, KPIs like customer lifetime value are a part of this category, and this is essential data a software firm can use to conduct reasonably accurate revenue forecasting. Five Key KPIs for Software Startups to Track Within the categories above, there are about five key KPIs that every software development startup should track. Doing so can give them the perspective they need to make smart decisions and improve their odds of long-term success. Here's what they are. 1. Revenue Concentration For software startups, there's almost no financial metric that's more consequential than revenue concentration. It's a KPI that refers to where the company's revenue is coming from and how its spread amongst the customer base. This is critical because it lets managers know how much of a financial blow the loss of an important customer or two would be. Broadly speaking, a business risks failure if any one of its customers accounts for 10% or more of total revenue or if its largest five customers make up 25% or more of its revenue base. Therefore, tracking revenue concentration can alert managers to the need to broaden the business's customer base to insulate it against a catastrophic loss of revenue. 2. Customer Churn Rate While it's useful to know what percentage each customer represents of a software startup's revenue base, that information is meaningless unless you can estimate the odds of losing a customer. That's where the customer churn rate KPI comes into play. It's a measurement of how many customers the business should expect to lose over a given period. This information is critical to informing new budgets and revenue forecasts, as well as for helping the company know what to invest in marketing and customer retention efforts. In other words, it tells the startup if they can depend on their loyal customers or if they need to go all-out in securing new ones to keep money coming into the business. 3. Customer Lifetime Value Customer lifetime value is a KPI that goes hand-in-hand with revenue concentration. It's a metric that helps a business to know, relatively speaking, how valuable each of its customers really is. As previously mentioned, this is critical information that the business needs for its revenue forecasting. But that's not all. It's also a KPI that can help guide parts of the software development process — especially change adoption and feature development. The bottom line is that software businesses need to be sensitive to the demands of valuable customers. So, if a large customer needs a particular new software feature or some additional workflow flexibility inside a product, it's a good idea to give it to them. Customer lifetime value data can act as a way to prioritize customer change requests so the most important customers always get what they need out of a given product. 4. Release Burndown The next important KPI comes from the performance metrics category. It's release burndown. This is a measure of how well the business's software development teams are keeping up with release schedules. It's an important way that managers can maintain visibility into the work cadence taking place within a given software project. The reason this is important is that most software customers need predictable software release schedules, be they monthly or quarterly. In both cases, release burndown data can help a software development company set release schedules they can actually fulfill. Otherwise, they run the risk of making promises to customers that they can't keep, and that's usually a one-way ticket to startup failure. 5. Wasted Effort The wasted effort KPI refers to an efficiency metric that lets a software development company know how much money they're spending on tasks that ultimately don't make it into their final software products. This includes work on features that never end up in a product or on rewriting code in ways that don't explicitly improve a product. It is estimated that software development teams around the world waste a cumulative $1 billion every day on such wasted efforts. Keeping track of the costs of wasted effort can help software development firms identify decision-making processes and parts of the development workflow that need rethinking. It can help them to run as lean as possible, which is essential for any software startup that wants to survive its early stages. The Bottom Line Obviously, it goes without saying that a software development startup needs to churn out quality software if it wants to survive and thrive. However, history is littered with development firms that made great software but failed because they couldn't parlay it into actual revenue streams. By monitoring the KPIs above, a software startup manager can keep their company on a path to sustainable success.

In today's fast-paced software development landscape, the need for efficient communication and collaboration has become paramount. As organizations strive to achieve seamless integration and delivery of software, DevOps has emerged as a key methodology. However, managing communication channels effectively within a DevOps environment can still prove challenging.To address this challenge, the concept of SlackOps has gained popularity. SlackOps combines the power of Slack, a popular team collaboration tool, with the principles of DevOps, enabling teams to streamline their communication and enhance collaboration. By leveraging SlackOps, organizations can optimize their DevOps workflows, leading to improved productivity and efficient software delivery. Understanding SlackOps and Its Benefits for DevOps At its core, SlackOps refers to the practice of utilizing Slack as a communication hub within a DevOps ecosystem. Slack, with its rich set of features, fosters real-time communication, centralizes information sharing, and promotes cross-team collaboration. Integrating Slack into a DevOps environment can bring numerous benefits to the table. First and foremost, SlackOps enhances transparency by providing a centralized platform for all team members involved in the software development process. This enables developers, operations personnel, and other stakeholders to stay informed about project updates, bug fixes, and feature enhancements. With Slack, team members can easily share progress updates, code snippets, and documentation, ensuring everyone is on the same page. Additionally, Slack allows teams to organize discussions into channels, ensuring that relevant conversations are easily accessible and searchable. This not only improves knowledge sharing and documentation but also fosters a sense of community within the DevOps ecosystem. Team members can join channels specific to their areas of interest or expertise, enabling them to engage in focused discussions and exchange valuable insights. Furthermore, SlackOps facilitates timely and efficient decision-making. With Slack, team members can instantly exchange ideas, share insights, and collaborate on problem-solving. The real-time nature of Slack enables quick feedback loops, reducing the lag between identifying issues and resolving them. This, in turn, accelerates the software development lifecycle, enabling teams to deliver high-quality software faster. In addition, Slack's integration capabilities empower teams to connect various tools and systems. By integrating with popular project management tools, version control systems, and continuous integration/continuous deployment (CI/CD) pipelines, teams can monitor the progress of deployments, receive notifications, and trigger automated actions. This seamless integration streamlines the development process, ensuring that team members are always up to date with the latest changes and enabling them to respond to critical events in a timely manner. Moreover, SlackOps promotes cross-team collaboration and breaks down silos. By providing a platform for communication and collaboration, Slack enables developers, operations personnel, and other stakeholders to work together seamlessly. Team members can easily reach out to each other, regardless of their physical location, fostering a culture of collaboration and knowledge sharing. This cross-team collaboration not only improves the quality of software but also enhances the overall efficiency and productivity of the DevOps ecosystem. In conclusion, SlackOps is a powerful practice that leverages the capabilities of Slack to enhance communication, transparency, and collaboration within a DevOps environment. By centralizing information sharing, facilitating real-time communication, and integrating with various tools and systems, SlackOps empowers teams to streamline their development processes, accelerate decision-making, and deliver high-quality software efficiently. Leveraging SlackOps to Streamline DevOps: Use Cases The effective adoption of SlackOps begins with a holistic understanding of the DevOps workflow and the specific pain points that need to be addressed. By strategically integrating Slack into the existing workflow, organizations can unlock its true potential. Monitoring: One way to leverage SlackOps is by integrating it with existing DevOps monitoring tools. By configuring Slack to receive notifications from these tools, teams can stay informed about system health, performance metrics, and any incidents that might occur. This allows for rapid identification and resolution of issues, leading to enhanced reliability and quality of software.For example, imagine a scenario where a team is using a monitoring tool to track the performance of their application. With SlackOps, they can set up notifications to be sent to a dedicated channel in Slack whenever the application's performance drops below a certain threshold. This ensures that the team is immediately alerted to any issues and can take action to resolve them promptly. The ability to receive real-time updates through Slack not only improves the efficiency of the team but also promotes collaboration and knowledge sharing among team members. Deployment management: By integrating Slack with CI/CD (Continuous Integration/Continuous Deployment) pipelines, teams can automate notifications about deployment status, code changes, and test results. This improves visibility and accountability among team members, reducing the risk of miscommunication and enabling faster responses to potential failures.For instance, let's consider a scenario where a team is using a CI/CD pipeline to automate the deployment of their application. With SlackOps, they can configure notifications to be sent to a specific Slack channel whenever a new version of the application is deployed. This allows the team to stay updated on the deployment status and be aware of any issues that may arise during the process. By having this real-time information readily available in Slack, team members can quickly collaborate and address any problems, ensuring a smooth and efficient deployment process. Here’s an example of how to integrate Github Actions CI/CD to Slack. Code changes: This means that when a developer pushes new code to the repository, a notification can be sent to the relevant Slack channel, allowing the team to review and provide feedback on the changes. Similarly, when automated tests are executed, the test results can be automatically sent to Slack, providing the team with immediate visibility into the quality of the code. Incident management: By creating dedicated incident response channels and configuring integrations with incident management tools, teams can centralize communication during critical situations. This enables faster coordination, better incident tracking, and seamless collaboration between developers, operations personnel, and other stakeholders, ultimately leading to reduced downtime and improved service reliability. Moreover, in incident response channels, teams can set up automated notifications that alert relevant team members when an incident occurs. These notifications can be customized based on severity levels, ensuring that the right people are informed promptly. Additionally, by integrating with monitoring and alerting systems, SlackOps enables real-time monitoring of system health and automatic creation of incident response channels when anomalies are detected. Cross-team collaboration: Slack provides the flexibility to create channels for different functional groups within the organization, such as development, operations, and quality assurance. By joining relevant channels, team members can engage in focused discussions, share expertise, and work towards common goals. This fosters a culture of collaboration and continuous improvement within the DevOps ecosystem. Furthermore, SlackOps facilitates knowledge sharing and documentation. With its searchable message history and file sharing capabilities, teams can easily access past conversations and reference materials. This helps in onboarding new team members, troubleshooting issues, and maintaining a knowledge base that can be accessed by all stakeholders. Overall, leveraging SlackOps in DevOps workflows offers numerous benefits. By integrating Slack with existing monitoring tools and CI/CD pipelines, organizations can improve communication, collaboration, and visibility within their teams. This leads to faster issue resolution, enhanced software quality, and increased overall efficiency. With the power of SlackOps, organizations can streamline their DevOps processes and achieve greater success in their software development endeavors. SlackOps and DevOps: The Challenges While SlackOps offers an incredibly effective way to automate and streamline DevOps processes, it is still bound to the knowledge and context that the operator or administrator of the system is able to feed it. In many ways it's a new and improved workflow automation system with a built in chat interface. What does this mean? While a significant improvement on the traditional workflow automation approach, SlackOps is still context-less, and bound by the limitations that users must know exactly what they are looking for and know precisely how to ask for it in order to receive the benefits of self-service. What is the significance of this? For the purposes of DevOps self-service, context is everything. When a consumer of DevOps wishes to provision themselves a new machine, check the status of a CI/CD job, roll back a Kubernetes deployment, access a sensitive app, or troubleshoot an ailing cluster, there are a lot of context gathering that go into the decision making process prior to taking the action, or allowing for automation. If a user rolls back the wrong cluster, they can accidentally take down a production environment, and if someone provisions a GPU based instance where a smaller compute instance is suitable, then they are wasting a lot of money. And allowing or disallowing access to a sensitive app can either create a security concern if it is a bad actor or otherwise slow down important operations for a good actor.

In today's dynamic business world, leadership involves blending technical expertise with adaptive skills as organizations confront unprecedented challenges and opportunities. This article explores the definitions, traits, applications, and imperatives of combining both leadership styles to effectively guide teams and companies towards sustainable growth. Understanding Technical Leadership Technical leadership encompasses the traditional aspects of management that involve expertise, knowledge, and skills directly related to the core functions of a business. A technical leader is someone who excels in their domain, possesses deep subject matter expertise, and can provide expert guidance to their team. These leaders are often well-versed in the specifics of their industry, possessing a solid grasp of best practices, technologies, and methodologies. They are capable of making informed decisions based on data, analysis, and established protocols. One of the central tenets of technical leadership is efficiency. Leaders with strong technical skills can optimize processes, streamline operations, and drive innovation within their field. They are adept at solving complex problems, often leveraging their expertise to identify and implement solutions that enhance productivity and quality. However, while technical leadership is essential, it does come with limitations. Relying solely on technical prowess can lead to a narrow focus, overlooking broader organizational dynamics and human factors. Additionally, in an ever-changing environment, technical skills can become outdated, necessitating a constant commitment to learning and adapting. The Essence of Adaptive Leadership Adaptive leadership, on the other hand, revolves around the ability to navigate uncertainty, ambiguity, and change. It is a leadership approach that focuses on guiding teams and organizations through transformational periods. Adaptive leaders are skilled at fostering resilience, encouraging creative problem-solving, and inspiring a culture of continuous learning. Adaptive leaders excel in communication and emotional intelligence. They possess the capacity to connect with their teams on a deeper level, empathizing with their challenges and aspirations. This ability to understand and relate to individuals creates an environment of trust, openness, and collaboration. Adaptive leaders empower their teams to innovate and adapt in response to emerging challenges, seizing opportunities that might have otherwise been overlooked. Crucially, adaptive leaders do not shy away from disruption; instead, they embrace it. They understand that change is constant and often unpredictable, and they champion the idea that setbacks can serve as stepping stones toward growth. This mindset enables organizations to remain agile and responsive, positioning them to thrive in dynamic markets. However, while adaptive leadership is invaluable, it can sometimes lack the concrete direction that technical expertise provides. The emphasis on flexibility and change may occasionally lead to uncertainty or a lack of clarity regarding immediate goals and strategies. Integrating Technical and Adaptive Leadership In an era marked by volatility, uncertainty, complexity, and ambiguity (VUCA), the demand for leaders who can bridge the gap between technical excellence and adaptive resilience has never been greater. The most effective leaders recognize that a harmonious integration of these approaches yields optimal results. Consider a scenario where a software development team is tasked with creating a groundbreaking application. A technical leader within the team understands the intricate nuances of coding languages, software architecture, and performance optimization. Their expertise ensures that the application is efficient, secure, and aligned with industry standards. However, the landscape of software development is in a constant state of flux. Emerging technologies, changing user preferences, and evolving market dynamics necessitate an adaptive approach. An adaptive leader in this context would guide the team through iterative processes, fostering an environment where experimentation and learning are encouraged. They would listen to user feedback, track market trends, and pivot the development strategy as needed. By merging technical and adaptive leadership, the team benefits from a comprehensive approach. Technical excellence ensures a solid foundation, while adaptive leadership enables the team to pivot, innovate, and respond effectively to emerging challenges and opportunities. Culture of Technical and Adaptive Excellence To truly harness the power of technical and adaptive leadership, organizations must cultivate a culture that values both approaches. This begins with leadership development and training programs that emphasize the acquisition of technical skills alongside the cultivation of adaptive qualities. Mentorship and cross-functional collaboration can also play a pivotal role in nurturing a balanced leadership approach. Pairing emerging leaders with seasoned professionals allows for the transfer of technical expertise while exposing them to the nuances of adaptive decision-making. Furthermore, organizations must encourage a growth mindset that celebrates learning and embraces change. This includes creating platforms for continuous skill development, promoting open dialogue, and acknowledging the value of both technical mastery and adaptive resilience. Conclusion The evolution of industries and markets necessitates leaders who can seamlessly integrate technical expertise with adaptive resilience. While technical leadership offers efficiency and problem-solving grounded in domain knowledge, adaptive leadership equips organizations to navigate uncertainty and capitalize on change. By harmonizing these two approaches, organizations can position themselves for sustainable growth and innovation. Technical mastery forms the bedrock of competence, while adaptive leadership ensures the organization remains agile and responsive. As industries continue to transform, the synergy between technical and adaptive leadership will be the linchpin that propels organizations toward enduring success in an ever-changing world.

At least weekly, I am asked for feedback or thoughts on a recent commercial interaction, most obviously for one-time transactions with a company rendering services; e.g., lawn service, gutter cleaning, teeth cleaning, financial, etc. Year over year, these requests increase (prefaced with, "And anything other than 5's is considered a failure...") and you start questioning the value-add. Tipping is a form of review. Returning or repeating customers are definitely a review of the services provided. Is there any actual value? But I digress. . . Image Source: "White Collar, c. 1940 - Linocuts by Giacomo G. Patri" by Thomas Shahan 3 is licensed under CC BY 2.0 In the United States, employee performance reviews are fairly de rigueur and pervasive for most jobs, especially for white-collar positions, but have you ever asked yourself what is achieved? Leaders can't wait to discuss ongoing problems if the problems would worsen. Performance improvement plans are often a precursor for firing chronic under-performers (except at Netflix). Career roadmap discussions or changes in career goals need to happen more than once per year. So what is the intended purpose of an annual performance review? My manager at my second full-time job started my review with the following statement: I have not done my job if you hear anything that we haven't previously discussed.- Jim D, CSC Consulting manager I found this incredibly useful and insightful, and often share this with managers and peers: feedback - positive or negative - should be in the moment, relevant, and continual for maximum impact. Of course, that assumes your manager actually tracks your work, which I've discovered is often not the case: multiple managers have asked me to write reviews for their peers! Performance reviews, in my opinion, are a perfunctory, HR activity rather than anything useful, and in the last 15 years, I have basically stopped any active participation, just the bare minimum effort to keep my manager out of trouble. My Turning Point I completed my first full year at Fortune 50 Company X, and, as expected, the new calendar year starts the performance review cycle. Performance reviews are serious business here: formalized, 360-degree feedback, scored, and time-consuming. If the scuttlebutt is correct, each year the lowest 10% are released to challenge and refresh the employee base. Personally, I'm not concerned: I've mastered the business domain, I've contributed positively to my project, my team functions at a high level, and I've expanded my reach into other parts of the org. The wrap-up meeting with my manager confirms this: I am top 10% for my role across the entire organization. Congrats, keep up the good work, we're lucky to have you. Whoo hoo! At the same time performance reviews wrapped up, project senior leadership changed, and managers meet with the new leaders to introduce themselves, their teams, and their responsibilities - normal stuff. My manager used the just-completed performance reviews to start the discussion about each person on her team. When it was time to discuss me, unprompted the new leader stated, "Scott likes to make people feel stupid." Wha?!? I had no idea where this comment came from: I had not met or worked with her previously, she hadn't yet been formally introduced, and my initial meet-and-greet was two weeks out. My manager was surprised and also had no idea what her opinion was based on. I was not specifically targeted, and there were others similarly surprised by her opinions. Regardless, I went from high performer to scum-of-the-earth overnight and realized quickly that image rehabilitation was difficult if not impossible. And If That's Not Enough... I've had other experiences that just further enhance my thoughts on the worthlessness of performance reviews. Mandatory Deflation After a poor fiscal year, one company instructed leaders to reduce review scores by 10% to reduce the annual bonus payouts. Wrong approach: performance reviews should reflect the quality (or lack thereof) of your work and a way to achieve corporate goals. Instead, I would have expected a proactive message from the president: I know everyone has worked really hard over the last year, and despite your hard work fiscally it's been a rough year. Therefore, I need to let everyone know that bonuses will be smaller than in recent years, for everyone at all levels. You should not take a reduced bonus personally: we must be fiscally responsible to better position ourselves for improvements this year. I know this is tough, but I hope you understand. Unfortunately, the company was not proactive and instead chose to game the system, frustrating everyone. Mismatched Role Expectations One company hired architects as Director Without Reports to ensure competitive salaries and bonus structures for their technology leaders. Unfortunately, the performance review scoring expected directors to manage direct reports, and therefore architects scored lower compared to other directors because of this. Our manager fought hard and diminished the impact, but it still impacted our raises, end-of-year bonuses, and opportunity for growth. Despite ongoing discussions, HR seemed incapable of understanding and made no changes to better reflect a reality they didn't grok. Unnoticed Non-Participation By now, I was totally jaded on performance reviews and did as little as possible, enough to not cause problems with my manager: complete self-review but don't provide any information; sign the printed review without reading or discussing; click whatever is necessary to move workflow along. I now knew this was to please HR and otherwise a complete waste of time. More recently, my overall self-review comment was: I am a penguin, prove me wrong. The first time I was surprised that no one noticed: not my immediate manager, not his director who supposedly reads reviews for all direct and indirect reports, not senior leaders who make salary/bonus decisions based on reviews. Not a peep, even when I didn't provide any other information. Leaders knew their team and had preconceived notions: the trusted, the hard workers, the laggards, the losers. No amount of formal performance review process would change that, but HR required the formality and so they went through the motions. Final Thoughts Let me be clear: for all the managers who dread performance review season and make the minimal effort required, there are those who view performance reviews as important to employees and make the commensurate effort. My wife believes her teams deserve reviews that are insightful, thoughtful, and personal, and spends hours on each person. Her meetings with each person look back at achievements - personal, team, organization - and forward-looking at upcoming projects and goals, and is a continuation of the one-on-one meetings held throughout the year. The result: a high-functioning team that understands business challenges, expectations, business, and personal goals. Perhaps my thoughts on performance reviews would be more positive with strong management earlier in my career, but unfortunately, that didn't happen. Now, in the later stages of my career, I've learned how to get my work done with and without the expected management support. Is it ideal? No, but it's the reality, and as such performance reviews have fallen off my list of things to trust.

Project management and program management are two essential concepts in the world of business and management. They both play a critical role in the success of any organization, as they help ensure that projects and programs are completed on time, within budget, and to the satisfaction of stakeholders. While they are similar in some ways, project management and program management differ in their scope and focus. In this article, we will discuss the differences between project management and program management, their importance, and the key skills required to be successful in both roles. In today’s fast-paced business world, managing projects and programs is a critical function for organizations to ensure the successful delivery of products, services, and initiatives. Project management and program management are two essential disciplines that play a crucial role in ensuring the success of any organization. In this article, we will delve into the differences between project management and program management and how these two disciplines work together to help organizations achieve their strategic objectives. What Is Project Management? Project management is the process of planning, executing, monitoring, and controlling a project to achieve specific goals and objectives within a defined timeline and budget. It involves organizing and coordinating resources, managing risks, and communicating with stakeholders to ensure that the project is completed successfully. A project is a temporary endeavor designed to produce a unique product, service, or result. Project management is critical to the success of any project, regardless of its size or complexity. A good project manager can ensure that the project is completed on time, within budget, and to the satisfaction of stakeholders. They must be able to manage resources, resolve conflicts, and adapt to changing circumstances to ensure that the project stays on track. The Key Skills Required for Project Management Planning and organization: Project managers must be able to develop detailed project plans that outline the scope, objectives, timelines, and budgets of the project. Leadership: Project managers must be able to motivate and inspire their team to achieve the project goals. Communication: Project managers must be able to communicate effectively with stakeholders, team members, and other stakeholders to ensure that everyone is on the same page. Problem-solving: Project managers must be able to identify and resolve problems that arise during the project. Risk management: Project managers must be able to identify and manage risks that could impact the project’s success. Project management involves planning, executing, controlling, and closing a specific project within a defined scope, timeline, and budget. It is a temporary effort that is undertaken to achieve a unique objective, such as building a new product, implementing a new system, or launching a marketing campaign. Project management follows a standardized process that includes initiating, planning, executing, monitoring and controlling, and closing phases. Initiating: During this phase, the project’s objectives, scope, and deliverables are defined, and the project team is identified. Planning: This phase involves developing a detailed project plan that includes the project’s scope, timeline, budget, resources, risk management, and communication plans. Executing: This phase involves executing the project plan and ensuring that the project is on track to meet the defined objectives. Monitoring and controlling: During this phase, the project’s progress is monitored, and corrective actions are taken to keep the project on track. Closing: This phase involves completing the project, documenting the lessons learned, and transitioning the project deliverables to the operations team. Project management requires strong leadership, communication, and technical skills to manage the project team, stakeholders, and vendors effectively. A project manager is responsible for delivering the project on time, within budget, and with the desired quality. They must be able to handle risks, issues, and changes that may arise during the project’s execution and communicate effectively with the project team, stakeholders, and sponsors. What Is Program Management? Program management is the process of managing multiple related projects that are designed to achieve a common goal or objective. It involves coordinating the projects, managing resources, and ensuring that they are aligned with the organization’s strategy and objectives. A program is a group of related projects that are managed in a coordinated way to achieve strategic objectives. Program management is critical to the success of any organization, as it helps ensure that projects are aligned with the organization’s strategy and objectives. A good program manager can ensure that resources are allocated effectively, risks are managed, and the program’s goals are achieved. The Key Skills Required for Program Management Strategic thinking: Program managers must be able to think strategically and align the program’s objectives with the organization’s strategy. Leadership: Program managers must be able to inspire and motivate their teams to achieve the program’s goals. Communication: Program managers must be able to communicate effectively with stakeholders, team members, and other stakeholders to ensure that everyone is on the same page. Resource management: Program managers must be able to allocate resources effectively to ensure that projects are completed on time and within budget. Risk management: Program managers must be able to identify and manage risks that could impact the program’s success. Program management is the process of managing multiple related projects that are designed to achieve a strategic business objective. A program is a collection of projects that are interdependent and contribute to a larger goal, such as a product line or a business transformation initiative. Program management focuses on coordinating the various projects within the program to ensure that they are aligned with the program’s objectives and that the program is delivered on time, within budget, and with the desired quality. Program management involves a similar process to project management but at a higher level. The process includes initiating, planning, executing, monitoring and controlling, and closing phases. Initiating: During this phase, the program’s objectives, scope, and deliverables are defined, and the program team is identified. Planning: This phase involves developing a detailed program plan that includes the program’s objectives, scope, timeline, budget, resources, risk management, and communication plans. Executing: This phase involves executing the program plan and ensuring that the projects within the program are on track to meet the defined objectives. Monitoring and controlling: During this phase, the program’s progress is monitored, and corrective actions are taken to keep the program on track. Closing: This phase involves completing the program, documenting the lessons learned, and transitioning the program deliverables to the operations team. Program managers must have strong leadership, communication, and strategic skills to manage multiple projects effectively. They must be able to align the program’s objectives with the organization’s strategic goals, manage dependencies between projects, handle risks and issues that may impact the program’s delivery, and communicate effectively with stakeholders and sponsors. Differences Between Project Management and Program Management Project management and program management are two related but distinct disciplines used to manage different types of initiatives within an organization. Here are some of the key differences between project management and program management: Scope: Project management focuses on delivering a specific output, while program management focuses on delivering a strategic business objective that requires multiple related projects. Project management is typically used for shorter-term initiatives, while program management is used for longer-term, more complex initiatives. Timeline: Project management has a defined start and end date, while program management may be ongoing and have no set end date. Project management is focused on delivering a product, service, or result within a specific timeline, while program management is focused on achieving a strategic goal over a longer period. Budget: Project management typically has a fixed budget allocated to the specific initiative, while program management may have a larger budget that is spread across multiple projects within the program. The budget for a project is usually allocated to a specific outcome or deliverable, while the budget for a program is often used to achieve a strategic objective that spans multiple projects. Deliverables: Project management is focused on delivering specific outputs or deliverables, such as a new product or service, while program management is focused on achieving a strategic objective that may require multiple deliverables from multiple projects. The deliverables for a project are often well-defined and specific, while the deliverables for a program may be more flexible and evolve over time. Team Structure: Project management typically has a smaller team structure that is focused on delivering a specific outcome, while program management may have a larger team structure that spans multiple projects and requires more coordination and communication. Project managers are often responsible for a specific project team, while program managers are responsible for coordinating and communicating with multiple project teams. Risks and Dependencies: Project management typically has a defined set of risks and dependencies that are specific to the project, while program management may have multiple risks and dependencies that are spread across multiple projects within the program. Program management requires a higher level of risk management and dependency management to ensure that all projects within the program are aligned and working towards the same strategic objective. Conclusion In summary, project management and program management are both important disciplines that are used to manage initiatives within an organization. Project management is focused on delivering a specific output within a defined timeline and budget, while program management is focused on achieving a strategic business objective that requires multiple related projects. While there are some similarities between the two disciplines, there are also significant differences in scope, timeline, budget, deliverables, team structure, and risk management that must be understood and managed by project and program managers.

The management of a project might be difficult and complicated. Regardless of your level of expertise, there are techniques to boost your project management performance. It may be useful to view some advice if you're new to project management. You can frequently find yourself contacting seniors as a project manager to get wise project management advice so that you can manage projects more effectively. We do, in fact, comprehend the challenge. Every day, project managers juggle an excessive amount of duties while making their presence known in several locations. They are in charge of several things, including goal analysis, project process creation, team communication management, and more. However, managing a project is not simple and calls for appropriate project management abilities, team member coordination, and various expertise, including an understanding of motivation theories, etc. Here are some suggestions for effective project management training and delivery. 1. Basic Requirements Before you start the process, create a map of the important project needs. Will each phase require routine stakeholder approvals? Will a given project call for a certain skill set? The criteria can include whatever your project may require, including a list of important project stakeholders, a project schedule, project deliverables, resource needs, managing clients for external projects, and much more. To keep everyone on track from the outset of a project and address any inconsistencies as soon as possible, compile a list of the essential project needs. 2. Method of Critical Path The Critical Path Method (CPM) requires all critical tasks to be identified and planned to complete the project with minimal delay. The Project Manager shall draw up a roadmap that comprises four basic steps based on this methodology. First is to list all major tasks required to complete the project, then estimate the time that will be taken by each task, after that identifying dependencies between tasks and finally planning the end result. These details are used in regulating the important stages, the longest series of tasks needed to complete the project. The path plays a critical role and must be followed by the project team to meet the deadline. 3. Automation To improve your workflow, automation may be just what you need at times. Automation may even become your best friend as a project manager! It takes over work that doesn't need to be done so you can focus on the most important work that needs your expertise. Allocating resources, updating task progress, and sending real-time alerts and notifications are all examples of automation. If you don't incorporate automation into the project execution stage, your processes may be slowed down, which could delay the project's completion. As a result, implementing automation to set dependencies, provide real-time task alerts, and display current task progress is a cost-effective approach to project management. 4. Being Agile Projects are finished using the agile technique in brief periods of time known as iterations. The team is required to submit the required deliverables at the conclusion of each iteration. Agile is well-liked because it enables the team to make essential adjustments as they go along rather than waiting until the project is finished. The agile technique uses brief work stages that necessitate regular testing, reevaluation, and other adjustments. The backlog contains a list of all the tasks that need to be completed, and before each cycle, the project managers give priority to the work. When a project may experience several modifications, this procedure is beneficial. Agile enables teams to change or redefine priorities in response to demands from customers or stakeholders while the project is still in progress. Scrum and Kanban are two sub-frameworks that have embraced this feature. Teams typically mix agile with other project management methodologies like scrum, Kanban, waterfall, or lean in order to produce the necessary deliverables while adopting the agile manifesto. It is used in the building, advertising, and pharmaceutical industries in addition to the software industry. 5. Understand Your Project The project manager is responsible for compiling, comprehending, and ensuring the stakeholders' approval of the project's requirements. Make sure that it includes a budget and a timeline that will cover the project's needs. Set a timetable for when to start, what to do, and when to finish the project, but be open to alterations. Flexibility does not require proactive planning; rather, it necessitates reactive measures that enable you to adapt to the change before it is too late. The job of the project manager does not end there. Check out the PMP online certification training to learn more about the roles and responsibilities. You can let your team members work how they want to in order to complete the tasks you've given them. However, a comprehensive schedule must be established and followed throughout. The team members must know how to implement project management methodologies such as agile, Kanban, and Waterfall that serve the needs of their project, team, and organization and implement it across all projects and processes. 6. Keep a Plan B We always start a project with a well-designed plan and a lot of hard work, but still, we face challenges in completing the tasks involved. This is the time when we require a plan B or an alternative plan. Choose alternate options for the project's most fundamental components. Even though there may be a lot of variables in your project, focus on the main parts first and worry about the details later. If you have a risk plan, it can help you deal with problems that don't come up. It can also show members of the team that you are well-prepared for the project. 7. Analyze After completing the project successfully, take some time to reflect on your strengths and weaknesses and unwind. After the project has been completed, the project managers of many businesses meet with the entire team to celebrate the project's success as well as to discuss what went wrong and how they can improve. If the meeting is just a meeting, make sure the mood stays upbeat. While projects are ongoing, the majority of successful project managers continue to address all of their concerns. Your team will remain engaged and motivated by this. In any case, both are beneficial and will help you and your team perform better in future endeavors. Keep in mind that you are the project in charge, so act as such—no other team member should be able to claim authority over you. It is your responsibility to bring out the best in your team members and to go above and beyond in the process. You serve as their mentor, coach, and motivator in addition to the project manager. Despite the difficulty, maintain your composure and strength during turbulent times. A good leader must perform this task. 8. Kanban The Kanban method has its origins in the manufacturing sector. An analysis tool called a Kanban board will be used to analyze the flow of projects. A visual display of the entire process, composed of an array of columns that represent one part of it, is provided by a Kanban board. Initially, all the tasks are grouped in a backlog column. Each team member will select a task from his or her project backlog to be worked on when the project starts. They select a new item from the backlog as soon as they finish their task and not until all tasks are completed. Kanban’s main selling point is the ability to visualize the progress of each part of the project at any point in time. In addition, columns that are overloaded with tasks are highlighted. So, this method not only provides growth and progress to a project but also eliminates issues. Conclusion You'll be able to navigate situations that seem impossible with ease if you incorporate these straightforward project management tips. You will be able to look at a specific scenario and quickly implement the best solution to the problem at hand with the help of these suggestions. When it comes to completing the project successfully, there is still a long way to go. Everything matters, from selecting the appropriate skill set to selecting an efficient method. Project managers with years of experience can assist you in ensuring a project's success and profitability. Implementing and putting into practice these best project management methodologies can have a significant impact on the process of project execution, enhance overall collaboration, and guarantee project success.

A product can be anything; a product manager's role and responsibilities change across different industries. In this post, I will remove some myths about the Product Manager role and share a bird-eye view of the product development process and some frameworks that may be useful in remembering the overall process. Product Manager Role Product Managers are not managers of anybody except for school interns who aspire to become product managers themselves. The PM acts as a central node in the product development process and is ultimately responsible for the product's success. The role brings all the viewpoints together and is designed with no direct reports so that the engineering/design team can develop an open-communication relationship to express their ideas and concerns. Many often confuse a Project Manager and a Product Manager; the Project Manager is responsible for the successful execution of the project within the agreed timeline and budget constraint, while the Product Manager meets the product goal and metrics. Product Development Process Innovation Process The product development process can be broadly navigated in three stages: Ideation, Feasibility, and Capability. The funnel starts with the discovery of the business situation and organisational context. To begin with, it’s essential to understand the business aim of any product, and it requires big thinking. Six Forces model and the 4-Ps marketing mix benchmark various strategic opportunities and identify business areas that need the most attention. BOSSCARD is a good framework to capture initial thoughts and provide terms of reference for a new project. The description is standard in project initiation documents, and the framework provides all the necessary information to stakeholders without looking at lengthy, detailed initiation documents. The acronym in BOSSCARD stands for Background, Objectives / Opportunities, Scope, Sustainability, Constraints, Assumptions, Resources/Risks (based on project context), and Deliverables. The BOSSCARD is important to have a formal agreement before the kick-off as without it always almost lead to some expectation not being met. Nowadays, there is a trend to use PRFAQ — popularised by Amazon - as the first document. Get I call the first stage in the funnel the Ideation stage. In this stage, we brainstorm and think about problems from the user’s perspective. I want to emphasise the importance of focusing on problems rather than solutions at this stage. Various methods, such as personas and others, can follow a process to learn more about customers and articulate the use cases. The CIRCLES method developed by Lewis helps Product Managers articulate customers’ needs and is an excellent framework for solving complex work problems and cracking PM interviews. We cleared the charter gate between the Ideation and Feasibility Stages. Validate CIRCLES method leads us to the Feasibility stage — the next stage of our product development process. After we have an overview of solutions, it’s important to fine-tune them and make them business-ready. In the feasibility stage, Product managers work closely with customers, designers, and engineers to create and iterate mock-ups. They objectively use each HEART element's Goal-Signal-Metrics to learn whether the product is improving. The HEART framework originated at Google, and the team used it to narrow down their focus on a few key metrics so they could test the progress objectively. I developed a detailed roadmap and business case to take sign-offs and resource commitments from relevant stakeholders. A best practice is to have graphic displays of information reflecting the entire journey of the product from a vision (conceptual) to a technical point of view. In many and now most organisations, the A/B testing result or MVP is the expectation of clearing the contract gate and moving to the next stage. The contract gate document is the most detailed product development document and acts as a single source of truth across various teams in the organisation. Implement Engineers work on the agreed plan, and in this stage- Capability stage- the project manager takes control of the project from the Product Manager and is responsible for ensuring development runs on schedule. Various project management tools such as Agile and SCRUM track the project. Marketing uses the window to create content across blogs, videos, and other promotional platforms. The legal/regulatory team ensures the product complies with the local laws and discusses the implementation with the regional team. The stage ends with a big launch and celebration clearing the Market Ready gate! After the launch, PLE (Post Launch Evaluation) kicks in, and we compare user data against set goals.

Platform teams are an integral part of an IT solution delivery organization. Every IT organization has a way of structuring its platform team based on its context and multiple considerations, including alignment with the Development or Operations of other units, position in the reporting hierarchy, business portfolio alignment – common vs. federated setup, etc. However, one thing that is likely to be common across these structures for platform teams is that it is a common service provider to the Dev and Ops teams. It is most likely a 'horizontal' team providing tooling support, frameworks, platforms, and even standards and benchmarks for the solution delivery and operations teams. This article describes an illustrative model to structure the platform team and outlines the team's responsibilities, metrics, and approach to Governance. Team Structure and Responsibilities The platform team plays a crucial role in servicing requests from the product, application, and operations teams. The team has certain responsibilities that are aimed at providing timely services to meet the IT goals and business priorities. Here are the key aspects of the structure and responsibilities of the platform team in this illustrative model. The platform team will have persistent team members with a combination of skills related to technology architecture, databases, testing, automation tools, security, and so on. The team will be responsible for providing common services to multiple products, application development, and operations teams. There could be multiple platform teams or sub-teams within a platform team – typically one or more for each of the following areas: Architecture runway maintenance DevOps Tooling Support DB Support Security – E.g., vulnerability analysis, pen testing Cloud migration support The team could also own certain environments and provide services such as penetration testing, performance testing, or other non-functional testing. The Kanban approach would be an effective way of working for the team to deliver their services to the internal teams. The following chart depicts this illustrative model. The Enterprise Architecture team helps the platform team with inputs to align with the planned technology roadmap. The Governance group ensures alignment with the goals and priorities of the enterprise and provides strategic direction and support. As illustrated below, the platform team could have multiple sub-teams to provide specialized solutions and services. Product / Work Backlog The platform team's backlog is different from that of an application team. It will have new items for 'development' in the context of the platform and work items related to existing services and solutions. As can be seen, almost all of the backlog items are technical in nature and focus on areas such as migration or a technology upgrade, or tooling support. The backlog of the team could include items such as: Epics for large migration (Cloud, technology, Database). Tech stories for architecture enhancement/maintenance across products. Tech stories for Database Administration and maintenance across products. Tech stories for common DevOps tooling and support across applications. Product/application-specific performance testing requirements. Tech stories for common security analysis and testing. Work items and 'tickets' related to an already provided service. Product Owner The Product Owner (PO) role is special in the context of the platform team. The PO typically would be from the technology organization. While they will focus on tech epics, they will always keep the business needs, epics, and roadmap in consideration while prioritizing the tech stories. The PO role could be played by the Enterprise Architect, Tech Lead or Design Lead, or other identified Tech Subject Matter Expert, depending on the tech stories. There could be a separate PO for each platform team, depending on the scope of their work. E.g., a DBA could be the PO for the DB migration/maintenance team. The PO will periodically sync up with the product, application development, and operations teams to understand their support requirements and consolidate these appropriately to define epics and stories for the platform teams. The PO will also keep a tab on the tech trends and leverage industry data in defining epics and stories for new services or enhancement to existing solutions and services of the platform team. Metrics The platform team in this illustrative model delivers services to the internal teams. Therefore the typical measurements that are relevant to a service delivery team would apply to the platform team as well. The measures would be around the quality of service, speed, service level agreements, and so on. Given the nature of work and the services delivered by the platform teams, there could be a set of metrics that are specific to the platform teams. Here are some examples: Story lead time: average time for a story from backlog to production release. Tech Debt reduction percentage. Average issue resolution time. Number and frequency of security incidents attributable to platforms. Automation/DevOps implementation maturity in the individual product or application teams. Satisfaction index from product teams, application teams, operations, and identified business stakeholders. Sync up With Dev and Other Teams As the platform team plays a pivotal role in delivering technology services to the internal teams, it often assumes an integrator's responsibility – that is, the product team takes a consolidated view of the different tech services requested by the other teams and tries to provide integrated services and optimize resources needed to provide those services. Therefore it Is essential for the platform team to sync up with other teams on a periodic basis to understand their current needs and future challenges. Here are some examples of the sync-up events that a platform team in this illustrative model would consider. Sync up sessions with product and application teams. Sync up sessions with the other platform teams. Tech work prioritization sessions with the other platform teams involving Scrum Masters, Product Owners, and Tech Leads of product teams. Catch up with enterprise architects. Sync up with the enterprise cyber security team. Sessions with identified business stakeholders – e.g., Portfolio Leadership, Line of Business Head. Governance Governance is a key component of the platform team model to provide guidance and make sure that the team delivers to the best of its capabilities. Governance ensures that funds allocated to the platform team are utilized effectively, and the services provided by the team align with business priorities and meet the expectations of the teams consuming their services. Here is a brief outline of the Governance structure of the illustrative platform team model. Who is involved: The following roles are involved in the Governance of the platform team. Identified business stakeholders, Enterprise Architects, Identified Tech Leads, Enterprise DBA, Security Leads, identified Product Owners, and Scrum Masters. What is reviewed: The governance body reviews the key aspects of the services of the platform team on a periodic basis, provides strategic guidance, and suggests course corrections were found necessary. Typically the following aspects are discussed. Progress against planned technical capabilities, enhancement, and delivery milestones. Funds/resource utilization Planned tech upgrades/migration (architecture, platform, cloud) Key observations in Audit reports. Security, observations, and recommendations made by the cyber security team and the resulting action plan. Key feedback and action from team retrospectives. What is measured (Metrics): As part of Governance, the team reviews the key metrics indicating service quality and delivery effectiveness. Here is a sample list of the metrics used in this illustrative model: Compliance metrics DevOps maturity Tech Debt Reduction Automation percentage Mean time to deliver service – across different categories of services provided. Frequency: The Governance review could happen every quarter on a cadence. It could also be conducted on the completion of key milestones. Other Considerations Single point of reference: This illustrative model uses its JIRA Board as the primary source of information for planning, status reporting, and action tracking. Transparency: The team maintains full transparency of its work, challenges, resolutions, and plan of work by making these visible to the identified stakeholders. Empowerment: The organization in this illustrative model fosters a culture of empowerment and innovation. The teams harvest creative ideas from their members by seeking their feedback and suggestions on a regular basis. Learning: Continuous learning is crucial for the platform teams to bring solutions and services aligned with business needs and technology trends. The team promotes continuous learning by providing ample opportunities for its team members through internal learning interventions and external training programs. For the team to keep pace with rapidly changing technology and provide state-of-the-art tools and solutions, the team implements a structured program to scan and understand technology trends, market solutions, and platforms. Using this understanding, the team designs its next set of solutions and services. Conclusion Platform teams play a key role in an enterprise to provide technology services to the IT organization. The structure of the platform team could vary from one organization to the other. The aspects discussed above in this article are relevant to the typical platform team structure.