Knowledge shared by our community

Leveraging Roadmap Planning for Engagement and Alignment

This article discusses how a product leader can drive productive cross-functional engagement to create a plan that is leveraged for accountability and learning. It suggests an iterative mindset, early interaction with the organization, finding an expression that is authentic to the organization, and creating artifacts that are tailored to the audience. It also suggests a process for keeping artifacts in sync and checking in on progress to plan along the way.

Building a Product Team: Identifying Desired Attributes and Activities

This article outlines a process for building a strong product team by first documenting the desired attributes and activities of the ideal candidate, then sharing it with the organization for feedback and revisions. This document is then used to define the interview activities and post-interview conversations to ensure the right fit for the organization's needs. Separating cultural aspirations from key responsibilities has helped the organization better understand what it needs in a product partner.

Creating Space on Your Roadmap for Innovation and Improvements

This article discusses how to ensure proper alignment on work projects by using three distinct work types (Discover, Build, Strengthen) and a 4-quarter rolling roadmap cadence. It also explains how investing time to review and ratify with cross-functional partners helps to feed learning into the plan, sharpen thinking, and reduce surprises.

Building a Platform Team

As a company grows, it is natural for teams to specialize and the first distinction is between product and platform engineering. It is important to identify the right time to do the split, which is usually when the value of spending engineering cycles to optimize what is being done becomes more apparent. Platform teams are built differently in different companies and should be structured according to the company's North Star and specific initiatives. Platform teams typically work on a longer time horizon than product engineering teams and should use DORA metrics to track progress. It is important to not split the team too soon or too late.

How to Drive Operational Excellence

Product technology leadership face various challenges such as balancing velocity and quality, product features and tune-ups, and staffing investment. The largest determinant of success is the ”speed of innovation”, which consists of two categories: innovation (product features) and tune-up items driving the speed of innovation. Prioritization should be based on customer impact, business impact, and operational efficiency. Alignment and prioritization with the Product and Engineering teams is crucial, and metrics should be captured to inform data-driven decision making. Lastly, transparency and clear communication on decisions and tradeoffs should be maintained, with follow-through on execution and delivery.

Leading an Organization Through a Colossal Change

As a tech leader, the author has taken a variety of actions to mature the team and processes to meet the next phase of the company's growth and needs. This includes restructuring the organization, assessing and putting the right people in the right roles, introducing performance assessment and a 9-box matrix, organizing show-and-tells, tech reviews, tech talks, and roundtable discussions, and introducing external trainers and post-mortems. The outcomes of these actions have been increased engagement, attendance, and frequency of forums/meetings, influencing outside of engineering, and improved engagement scores. The author has also learned the importance of having patience and giving time for the process to mature, holding cross-groups accountable, and training as early as possible.

Adapting Scrum to Continuous Deployment

A development organization was operating on a very inefficient one-month sprint cycle and manual deployment process. The existing leadership team was risk-averse and did not want change. The individual gathered data to support the changes and developed a roadmap to enable fully automated deploys at least once per day. This demonstrated value allowed them to elevate the automation project to an officially sponsored initiative. After achieving the goal of daily fully automated deployments, the heavy sprint cycle development process was the next bottleneck. The individual experimented with process tweaks on a single team, rolling out each successful change to all the other teams. This allowed teams to deliver a predictable flow of work while retaining the ability to quickly react to production incidents and changes in project scope.

Tech Debt Bankruptcy

After realizing that their fixed 20% tech debt budget was not working, a team took action to quantify the amount of time spent on unplanned work, created a three-level priority system for work, and established service ownership to ensure that critical issues were addressed. This resulted in unplanned work dropping in half, production incidents virtually disappearing, and developer happiness doubling. The team learned that service ownership works at small scales and that there is more to "production" than customer-facing components.

A Lack of Clear Vision and the Team Morale

A team had built an in-house product that was launched globally, but had insufficient global coverage and quality issues. An external company released a third-party solution that could replace the in-house product, and the team feared they would be downsized or disbanded. The manager had to balance between what was best for the team and the company, and ultimately decided on a hybrid solution that combined the best of both worlds. The team was encouraged to think from a customer perspective, and transparency and trust were key to motivating the team to work on improvements.

Restructuring a Team: How to Enhance Accountability and Ownership

When the author joined their current company, they found that the team was not structured to execute and scale well due to its size and project-based nature. To address this, the author and their team restructured the team into six smaller subteams with vertical ownership and tech leads to drive a charter and provide a long-term vision. This improved the team's engagement, on-call rotation, and overall reliability. The restructuring also allowed leadership to have more visibility into areas that needed more investment. However, the author also learned that forming a research team too early can be problematic if the underlying platform is not mature enough.

Learning to Sell

A product development lead was given the opportunity to become a product manager and had to learn how to sell the product without any prior experience or training. They read books, blog posts, and ebooks, followed sales influencers on social media, and worked with salespeople. Through tracking data, they improved their social media outreach success rate and started publishing engineering topics on social media. They learned that sales is still helping people and that their engineering background made them a more authentic helper.

Integrating a Junior Engineer Into a New Team

A junior engineer was integrated into a product development team, but the team was not welcoming and the engineer was unfamiliar with the culture and procedures. The engineer was passionate about a technology solution, but the team did not feel the presentation was well-researched enough. The engineer was mentored and the technical leader of the product development worked with them, but the engineer eventually left the company. Lessons learned included creating a better, welcoming culture and pairing the junior engineer with a mentor.

Balancing Your Team and Product Sponsor’s Requirements

As a team lead, I was tasked with managing a team of engineers building a product according to the sponsor's wishes, despite the team's skepticism. To keep the team motivated, I asked the sponsor to set clear objectives, answered all questions, and encouraged the team to document their work. I also took the blame for delays to protect the team from disciplinary action. Ultimately, I learned that it is important to set objectives, explain the value of the work, and not overload the team.

(Not) Finding the Right Job

After joining a company without being intentional about the role, the narrator quickly realized the role was not a good fit and caused a strained relationship with a peer. The narrator took time off and was more intentional when looking for the next role, asking critical questions to ensure it was the right fit. The narrator learned lessons about loyalty, knowing oneself, expectations, and recognizing when one is in the wrong place.

Bringing a New Product to Market

A startup hired a new employee to launch a new product, but the strategy they used to bring it to market was not successful. They eventually had to pivot to target enterprises instead, but they underestimated the effort it would take to create a new market. Ultimately, the business was shut down due to the greater investment needed for success. The lesson learned is to be careful of assumptions, pick advisors wisely, and not let enthusiasm cloud judgment.

Dropping the Ball Explicitly

This story is about a program manager who was given significant responsibility in a large corporation. He accepted the responsibility halfheartedly and ended up not delivering on it, leading to a fire drill. He learned the lesson that it is okay to drop the ball as long as it is done explicitly, and to always ask for help when needed. He now makes sure to communicate clearly if he is unable to deliver on a project.

Building a Startup Within a Large Corporation

This article discusses the steps taken by a large corporation to set up a startup within its organization. The corporation identified two main sets of activities to set up for success: defining a business model and attracting the top talent. The business model was based on the company's strengths and weaknesses, and the talent was sourced from universities and a high school teacher's network. The company sought risk-takers who were willing to experiment with new technologies and embrace a fast-fail startup mentality.

Evaluating Engineers: A Three-Step Guide

The author was tasked with deciding who would stay on the team and created a three-step guide for evaluation: performance assessment, career path conversations, and productivity measurement. Performance assessment involves understanding the company needs and evaluating technical competence and interaction with team members and the business. Career path conversations involve discussing plans for the upcoming quarter or year and providing support for professional development. Productivity is measured by tracking work closely but without obsessing over metrics. The author learned that without time pressure, people are empowered to choose tasks that can unlock their potential, document performance-related activities, and have regular one-on-ones.

When an Engineer Has to Make Product Decisions

In transitioning from an IC to an architect in a startup, the author had to take on many responsibilities and learn new skills. They read avidly, connected with peers, and had a mentor to help them adjust to their new role. They also improved their technical skills, introduced new processes, and learned to manage up. The author learned that many people before them had similar challenges, and that it is important to stay technical, keep a consistent pace, and learn to say no.

Understand the History of Agile, or Be Doomed To Repeat It

Agile processes, specifically Scrum, are often seen as the only way to do software, but this view is too restrictive and prescriptive. Agile is the best default answer we have, but it is not perfect and should be treated as an imperfect tool. It is important to understand the historical context of Agile and to be familiar with multiple Agile techniques, as Agile is not a culmination but the most recent iteration in a long line of process improvements.

Leveraging Roadmap Planning for Engagement and Alignment

This article discusses how a product leader can drive productive cross-functional engagement to create a plan that is leveraged for accountability and learning. It suggests an iterative mindset, early interaction with the organization, finding an expression that is authentic to the organization, and creating artifacts that are tailored to the audience. It also suggests a process for keeping artifacts in sync and checking in on progress to plan along the way.

Building a Product Team: Identifying Desired Attributes and Activities

This article outlines a process for building a strong product team by first documenting the desired attributes and activities of the ideal candidate, then sharing it with the organization for feedback and revisions. This document is then used to define the interview activities and post-interview conversations to ensure the right fit for the organization's needs. Separating cultural aspirations from key responsibilities has helped the organization better understand what it needs in a product partner.

Creating Space on Your Roadmap for Innovation and Improvements

This article discusses how to ensure proper alignment on work projects by using three distinct work types (Discover, Build, Strengthen) and a 4-quarter rolling roadmap cadence. It also explains how investing time to review and ratify with cross-functional partners helps to feed learning into the plan, sharpen thinking, and reduce surprises.

Building a Platform Team

As a company grows, it is natural for teams to specialize and the first distinction is between product and platform engineering. It is important to identify the right time to do the split, which is usually when the value of spending engineering cycles to optimize what is being done becomes more apparent. Platform teams are built differently in different companies and should be structured according to the company's North Star and specific initiatives. Platform teams typically work on a longer time horizon than product engineering teams and should use DORA metrics to track progress. It is important to not split the team too soon or too late.

How to Drive Operational Excellence

Product technology leadership face various challenges such as balancing velocity and quality, product features and tune-ups, and staffing investment. The largest determinant of success is the ”speed of innovation”, which consists of two categories: innovation (product features) and tune-up items driving the speed of innovation. Prioritization should be based on customer impact, business impact, and operational efficiency. Alignment and prioritization with the Product and Engineering teams is crucial, and metrics should be captured to inform data-driven decision making. Lastly, transparency and clear communication on decisions and tradeoffs should be maintained, with follow-through on execution and delivery.

Leading an Organization Through a Colossal Change

As a tech leader, the author has taken a variety of actions to mature the team and processes to meet the next phase of the company's growth and needs. This includes restructuring the organization, assessing and putting the right people in the right roles, introducing performance assessment and a 9-box matrix, organizing show-and-tells, tech reviews, tech talks, and roundtable discussions, and introducing external trainers and post-mortems. The outcomes of these actions have been increased engagement, attendance, and frequency of forums/meetings, influencing outside of engineering, and improved engagement scores. The author has also learned the importance of having patience and giving time for the process to mature, holding cross-groups accountable, and training as early as possible.

Adapting Scrum to Continuous Deployment

A development organization was operating on a very inefficient one-month sprint cycle and manual deployment process. The existing leadership team was risk-averse and did not want change. The individual gathered data to support the changes and developed a roadmap to enable fully automated deploys at least once per day. This demonstrated value allowed them to elevate the automation project to an officially sponsored initiative. After achieving the goal of daily fully automated deployments, the heavy sprint cycle development process was the next bottleneck. The individual experimented with process tweaks on a single team, rolling out each successful change to all the other teams. This allowed teams to deliver a predictable flow of work while retaining the ability to quickly react to production incidents and changes in project scope.

Tech Debt Bankruptcy

After realizing that their fixed 20% tech debt budget was not working, a team took action to quantify the amount of time spent on unplanned work, created a three-level priority system for work, and established service ownership to ensure that critical issues were addressed. This resulted in unplanned work dropping in half, production incidents virtually disappearing, and developer happiness doubling. The team learned that service ownership works at small scales and that there is more to "production" than customer-facing components.

A Lack of Clear Vision and the Team Morale

A team had built an in-house product that was launched globally, but had insufficient global coverage and quality issues. An external company released a third-party solution that could replace the in-house product, and the team feared they would be downsized or disbanded. The manager had to balance between what was best for the team and the company, and ultimately decided on a hybrid solution that combined the best of both worlds. The team was encouraged to think from a customer perspective, and transparency and trust were key to motivating the team to work on improvements.

Restructuring a Team: How to Enhance Accountability and Ownership

When the author joined their current company, they found that the team was not structured to execute and scale well due to its size and project-based nature. To address this, the author and their team restructured the team into six smaller subteams with vertical ownership and tech leads to drive a charter and provide a long-term vision. This improved the team's engagement, on-call rotation, and overall reliability. The restructuring also allowed leadership to have more visibility into areas that needed more investment. However, the author also learned that forming a research team too early can be problematic if the underlying platform is not mature enough.

Learning to Sell

A product development lead was given the opportunity to become a product manager and had to learn how to sell the product without any prior experience or training. They read books, blog posts, and ebooks, followed sales influencers on social media, and worked with salespeople. Through tracking data, they improved their social media outreach success rate and started publishing engineering topics on social media. They learned that sales is still helping people and that their engineering background made them a more authentic helper.

Integrating a Junior Engineer Into a New Team

A junior engineer was integrated into a product development team, but the team was not welcoming and the engineer was unfamiliar with the culture and procedures. The engineer was passionate about a technology solution, but the team did not feel the presentation was well-researched enough. The engineer was mentored and the technical leader of the product development worked with them, but the engineer eventually left the company. Lessons learned included creating a better, welcoming culture and pairing the junior engineer with a mentor.

Balancing Your Team and Product Sponsor’s Requirements

As a team lead, I was tasked with managing a team of engineers building a product according to the sponsor's wishes, despite the team's skepticism. To keep the team motivated, I asked the sponsor to set clear objectives, answered all questions, and encouraged the team to document their work. I also took the blame for delays to protect the team from disciplinary action. Ultimately, I learned that it is important to set objectives, explain the value of the work, and not overload the team.

(Not) Finding the Right Job

After joining a company without being intentional about the role, the narrator quickly realized the role was not a good fit and caused a strained relationship with a peer. The narrator took time off and was more intentional when looking for the next role, asking critical questions to ensure it was the right fit. The narrator learned lessons about loyalty, knowing oneself, expectations, and recognizing when one is in the wrong place.

Bringing a New Product to Market

A startup hired a new employee to launch a new product, but the strategy they used to bring it to market was not successful. They eventually had to pivot to target enterprises instead, but they underestimated the effort it would take to create a new market. Ultimately, the business was shut down due to the greater investment needed for success. The lesson learned is to be careful of assumptions, pick advisors wisely, and not let enthusiasm cloud judgment.

Dropping the Ball Explicitly

This story is about a program manager who was given significant responsibility in a large corporation. He accepted the responsibility halfheartedly and ended up not delivering on it, leading to a fire drill. He learned the lesson that it is okay to drop the ball as long as it is done explicitly, and to always ask for help when needed. He now makes sure to communicate clearly if he is unable to deliver on a project.

Building a Startup Within a Large Corporation

This article discusses the steps taken by a large corporation to set up a startup within its organization. The corporation identified two main sets of activities to set up for success: defining a business model and attracting the top talent. The business model was based on the company's strengths and weaknesses, and the talent was sourced from universities and a high school teacher's network. The company sought risk-takers who were willing to experiment with new technologies and embrace a fast-fail startup mentality.

Evaluating Engineers: A Three-Step Guide

The author was tasked with deciding who would stay on the team and created a three-step guide for evaluation: performance assessment, career path conversations, and productivity measurement. Performance assessment involves understanding the company needs and evaluating technical competence and interaction with team members and the business. Career path conversations involve discussing plans for the upcoming quarter or year and providing support for professional development. Productivity is measured by tracking work closely but without obsessing over metrics. The author learned that without time pressure, people are empowered to choose tasks that can unlock their potential, document performance-related activities, and have regular one-on-ones.

When an Engineer Has to Make Product Decisions

In transitioning from an IC to an architect in a startup, the author had to take on many responsibilities and learn new skills. They read avidly, connected with peers, and had a mentor to help them adjust to their new role. They also improved their technical skills, introduced new processes, and learned to manage up. The author learned that many people before them had similar challenges, and that it is important to stay technical, keep a consistent pace, and learn to say no.

Understand the History of Agile, or Be Doomed To Repeat It

Agile processes, specifically Scrum, are often seen as the only way to do software, but this view is too restrictive and prescriptive. Agile is the best default answer we have, but it is not perfect and should be treated as an imperfect tool. It is important to understand the historical context of Agile and to be familiar with multiple Agile techniques, as Agile is not a culmination but the most recent iteration in a long line of process improvements.

Leveraging Roadmap Planning for Engagement and Alignment

This article discusses how a product leader can drive productive cross-functional engagement to create a plan that is leveraged for accountability and learning. It suggests an iterative mindset, early interaction with the organization, finding an expression that is authentic to the organization, and creating artifacts that are tailored to the audience. It also suggests a process for keeping artifacts in sync and checking in on progress to plan along the way.

Building a Product Team: Identifying Desired Attributes and Activities

This article outlines a process for building a strong product team by first documenting the desired attributes and activities of the ideal candidate, then sharing it with the organization for feedback and revisions. This document is then used to define the interview activities and post-interview conversations to ensure the right fit for the organization's needs. Separating cultural aspirations from key responsibilities has helped the organization better understand what it needs in a product partner.

Creating Space on Your Roadmap for Innovation and Improvements

This article discusses how to ensure proper alignment on work projects by using three distinct work types (Discover, Build, Strengthen) and a 4-quarter rolling roadmap cadence. It also explains how investing time to review and ratify with cross-functional partners helps to feed learning into the plan, sharpen thinking, and reduce surprises.

Building a Platform Team

As a company grows, it is natural for teams to specialize and the first distinction is between product and platform engineering. It is important to identify the right time to do the split, which is usually when the value of spending engineering cycles to optimize what is being done becomes more apparent. Platform teams are built differently in different companies and should be structured according to the company's North Star and specific initiatives. Platform teams typically work on a longer time horizon than product engineering teams and should use DORA metrics to track progress. It is important to not split the team too soon or too late.

How to Drive Operational Excellence

Product technology leadership face various challenges such as balancing velocity and quality, product features and tune-ups, and staffing investment. The largest determinant of success is the ”speed of innovation”, which consists of two categories: innovation (product features) and tune-up items driving the speed of innovation. Prioritization should be based on customer impact, business impact, and operational efficiency. Alignment and prioritization with the Product and Engineering teams is crucial, and metrics should be captured to inform data-driven decision making. Lastly, transparency and clear communication on decisions and tradeoffs should be maintained, with follow-through on execution and delivery.

Leading an Organization Through a Colossal Change

As a tech leader, the author has taken a variety of actions to mature the team and processes to meet the next phase of the company's growth and needs. This includes restructuring the organization, assessing and putting the right people in the right roles, introducing performance assessment and a 9-box matrix, organizing show-and-tells, tech reviews, tech talks, and roundtable discussions, and introducing external trainers and post-mortems. The outcomes of these actions have been increased engagement, attendance, and frequency of forums/meetings, influencing outside of engineering, and improved engagement scores. The author has also learned the importance of having patience and giving time for the process to mature, holding cross-groups accountable, and training as early as possible.

Adapting Scrum to Continuous Deployment

A development organization was operating on a very inefficient one-month sprint cycle and manual deployment process. The existing leadership team was risk-averse and did not want change. The individual gathered data to support the changes and developed a roadmap to enable fully automated deploys at least once per day. This demonstrated value allowed them to elevate the automation project to an officially sponsored initiative. After achieving the goal of daily fully automated deployments, the heavy sprint cycle development process was the next bottleneck. The individual experimented with process tweaks on a single team, rolling out each successful change to all the other teams. This allowed teams to deliver a predictable flow of work while retaining the ability to quickly react to production incidents and changes in project scope.

Tech Debt Bankruptcy

After realizing that their fixed 20% tech debt budget was not working, a team took action to quantify the amount of time spent on unplanned work, created a three-level priority system for work, and established service ownership to ensure that critical issues were addressed. This resulted in unplanned work dropping in half, production incidents virtually disappearing, and developer happiness doubling. The team learned that service ownership works at small scales and that there is more to "production" than customer-facing components.

A Lack of Clear Vision and the Team Morale

A team had built an in-house product that was launched globally, but had insufficient global coverage and quality issues. An external company released a third-party solution that could replace the in-house product, and the team feared they would be downsized or disbanded. The manager had to balance between what was best for the team and the company, and ultimately decided on a hybrid solution that combined the best of both worlds. The team was encouraged to think from a customer perspective, and transparency and trust were key to motivating the team to work on improvements.

Restructuring a Team: How to Enhance Accountability and Ownership

When the author joined their current company, they found that the team was not structured to execute and scale well due to its size and project-based nature. To address this, the author and their team restructured the team into six smaller subteams with vertical ownership and tech leads to drive a charter and provide a long-term vision. This improved the team's engagement, on-call rotation, and overall reliability. The restructuring also allowed leadership to have more visibility into areas that needed more investment. However, the author also learned that forming a research team too early can be problematic if the underlying platform is not mature enough.

Learning to Sell

A product development lead was given the opportunity to become a product manager and had to learn how to sell the product without any prior experience or training. They read books, blog posts, and ebooks, followed sales influencers on social media, and worked with salespeople. Through tracking data, they improved their social media outreach success rate and started publishing engineering topics on social media. They learned that sales is still helping people and that their engineering background made them a more authentic helper.

Integrating a Junior Engineer Into a New Team

A junior engineer was integrated into a product development team, but the team was not welcoming and the engineer was unfamiliar with the culture and procedures. The engineer was passionate about a technology solution, but the team did not feel the presentation was well-researched enough. The engineer was mentored and the technical leader of the product development worked with them, but the engineer eventually left the company. Lessons learned included creating a better, welcoming culture and pairing the junior engineer with a mentor.

Balancing Your Team and Product Sponsor’s Requirements

As a team lead, I was tasked with managing a team of engineers building a product according to the sponsor's wishes, despite the team's skepticism. To keep the team motivated, I asked the sponsor to set clear objectives, answered all questions, and encouraged the team to document their work. I also took the blame for delays to protect the team from disciplinary action. Ultimately, I learned that it is important to set objectives, explain the value of the work, and not overload the team.

(Not) Finding the Right Job

After joining a company without being intentional about the role, the narrator quickly realized the role was not a good fit and caused a strained relationship with a peer. The narrator took time off and was more intentional when looking for the next role, asking critical questions to ensure it was the right fit. The narrator learned lessons about loyalty, knowing oneself, expectations, and recognizing when one is in the wrong place.

Bringing a New Product to Market

A startup hired a new employee to launch a new product, but the strategy they used to bring it to market was not successful. They eventually had to pivot to target enterprises instead, but they underestimated the effort it would take to create a new market. Ultimately, the business was shut down due to the greater investment needed for success. The lesson learned is to be careful of assumptions, pick advisors wisely, and not let enthusiasm cloud judgment.

Dropping the Ball Explicitly

This story is about a program manager who was given significant responsibility in a large corporation. He accepted the responsibility halfheartedly and ended up not delivering on it, leading to a fire drill. He learned the lesson that it is okay to drop the ball as long as it is done explicitly, and to always ask for help when needed. He now makes sure to communicate clearly if he is unable to deliver on a project.

Building a Startup Within a Large Corporation

This article discusses the steps taken by a large corporation to set up a startup within its organization. The corporation identified two main sets of activities to set up for success: defining a business model and attracting the top talent. The business model was based on the company's strengths and weaknesses, and the talent was sourced from universities and a high school teacher's network. The company sought risk-takers who were willing to experiment with new technologies and embrace a fast-fail startup mentality.

Evaluating Engineers: A Three-Step Guide

The author was tasked with deciding who would stay on the team and created a three-step guide for evaluation: performance assessment, career path conversations, and productivity measurement. Performance assessment involves understanding the company needs and evaluating technical competence and interaction with team members and the business. Career path conversations involve discussing plans for the upcoming quarter or year and providing support for professional development. Productivity is measured by tracking work closely but without obsessing over metrics. The author learned that without time pressure, people are empowered to choose tasks that can unlock their potential, document performance-related activities, and have regular one-on-ones.

When an Engineer Has to Make Product Decisions

In transitioning from an IC to an architect in a startup, the author had to take on many responsibilities and learn new skills. They read avidly, connected with peers, and had a mentor to help them adjust to their new role. They also improved their technical skills, introduced new processes, and learned to manage up. The author learned that many people before them had similar challenges, and that it is important to stay technical, keep a consistent pace, and learn to say no.

Understand the History of Agile, or Be Doomed To Repeat It

Agile processes, specifically Scrum, are often seen as the only way to do software, but this view is too restrictive and prescriptive. Agile is the best default answer we have, but it is not perfect and should be treated as an imperfect tool. It is important to understand the historical context of Agile and to be familiar with multiple Agile techniques, as Agile is not a culmination but the most recent iteration in a long line of process improvements.

Leveraging Roadmap Planning for Engagement and Alignment

This article discusses how a product leader can drive productive cross-functional engagement to create a plan that is leveraged for accountability and learning. It suggests an iterative mindset, early interaction with the organization, finding an expression that is authentic to the organization, and creating artifacts that are tailored to the audience. It also suggests a process for keeping artifacts in sync and checking in on progress to plan along the way.

Building a Product Team: Identifying Desired Attributes and Activities

This article outlines a process for building a strong product team by first documenting the desired attributes and activities of the ideal candidate, then sharing it with the organization for feedback and revisions. This document is then used to define the interview activities and post-interview conversations to ensure the right fit for the organization's needs. Separating cultural aspirations from key responsibilities has helped the organization better understand what it needs in a product partner.

Creating Space on Your Roadmap for Innovation and Improvements

This article discusses how to ensure proper alignment on work projects by using three distinct work types (Discover, Build, Strengthen) and a 4-quarter rolling roadmap cadence. It also explains how investing time to review and ratify with cross-functional partners helps to feed learning into the plan, sharpen thinking, and reduce surprises.

Building a Platform Team

As a company grows, it is natural for teams to specialize and the first distinction is between product and platform engineering. It is important to identify the right time to do the split, which is usually when the value of spending engineering cycles to optimize what is being done becomes more apparent. Platform teams are built differently in different companies and should be structured according to the company's North Star and specific initiatives. Platform teams typically work on a longer time horizon than product engineering teams and should use DORA metrics to track progress. It is important to not split the team too soon or too late.

How to Drive Operational Excellence

Product technology leadership face various challenges such as balancing velocity and quality, product features and tune-ups, and staffing investment. The largest determinant of success is the ”speed of innovation”, which consists of two categories: innovation (product features) and tune-up items driving the speed of innovation. Prioritization should be based on customer impact, business impact, and operational efficiency. Alignment and prioritization with the Product and Engineering teams is crucial, and metrics should be captured to inform data-driven decision making. Lastly, transparency and clear communication on decisions and tradeoffs should be maintained, with follow-through on execution and delivery.

Leading an Organization Through a Colossal Change

As a tech leader, the author has taken a variety of actions to mature the team and processes to meet the next phase of the company's growth and needs. This includes restructuring the organization, assessing and putting the right people in the right roles, introducing performance assessment and a 9-box matrix, organizing show-and-tells, tech reviews, tech talks, and roundtable discussions, and introducing external trainers and post-mortems. The outcomes of these actions have been increased engagement, attendance, and frequency of forums/meetings, influencing outside of engineering, and improved engagement scores. The author has also learned the importance of having patience and giving time for the process to mature, holding cross-groups accountable, and training as early as possible.

Adapting Scrum to Continuous Deployment

A development organization was operating on a very inefficient one-month sprint cycle and manual deployment process. The existing leadership team was risk-averse and did not want change. The individual gathered data to support the changes and developed a roadmap to enable fully automated deploys at least once per day. This demonstrated value allowed them to elevate the automation project to an officially sponsored initiative. After achieving the goal of daily fully automated deployments, the heavy sprint cycle development process was the next bottleneck. The individual experimented with process tweaks on a single team, rolling out each successful change to all the other teams. This allowed teams to deliver a predictable flow of work while retaining the ability to quickly react to production incidents and changes in project scope.

Tech Debt Bankruptcy

After realizing that their fixed 20% tech debt budget was not working, a team took action to quantify the amount of time spent on unplanned work, created a three-level priority system for work, and established service ownership to ensure that critical issues were addressed. This resulted in unplanned work dropping in half, production incidents virtually disappearing, and developer happiness doubling. The team learned that service ownership works at small scales and that there is more to "production" than customer-facing components.

A Lack of Clear Vision and the Team Morale

A team had built an in-house product that was launched globally, but had insufficient global coverage and quality issues. An external company released a third-party solution that could replace the in-house product, and the team feared they would be downsized or disbanded. The manager had to balance between what was best for the team and the company, and ultimately decided on a hybrid solution that combined the best of both worlds. The team was encouraged to think from a customer perspective, and transparency and trust were key to motivating the team to work on improvements.

Restructuring a Team: How to Enhance Accountability and Ownership

When the author joined their current company, they found that the team was not structured to execute and scale well due to its size and project-based nature. To address this, the author and their team restructured the team into six smaller subteams with vertical ownership and tech leads to drive a charter and provide a long-term vision. This improved the team's engagement, on-call rotation, and overall reliability. The restructuring also allowed leadership to have more visibility into areas that needed more investment. However, the author also learned that forming a research team too early can be problematic if the underlying platform is not mature enough.

Learning to Sell

A product development lead was given the opportunity to become a product manager and had to learn how to sell the product without any prior experience or training. They read books, blog posts, and ebooks, followed sales influencers on social media, and worked with salespeople. Through tracking data, they improved their social media outreach success rate and started publishing engineering topics on social media. They learned that sales is still helping people and that their engineering background made them a more authentic helper.

Integrating a Junior Engineer Into a New Team

A junior engineer was integrated into a product development team, but the team was not welcoming and the engineer was unfamiliar with the culture and procedures. The engineer was passionate about a technology solution, but the team did not feel the presentation was well-researched enough. The engineer was mentored and the technical leader of the product development worked with them, but the engineer eventually left the company. Lessons learned included creating a better, welcoming culture and pairing the junior engineer with a mentor.

Balancing Your Team and Product Sponsor’s Requirements

As a team lead, I was tasked with managing a team of engineers building a product according to the sponsor's wishes, despite the team's skepticism. To keep the team motivated, I asked the sponsor to set clear objectives, answered all questions, and encouraged the team to document their work. I also took the blame for delays to protect the team from disciplinary action. Ultimately, I learned that it is important to set objectives, explain the value of the work, and not overload the team.

(Not) Finding the Right Job

After joining a company without being intentional about the role, the narrator quickly realized the role was not a good fit and caused a strained relationship with a peer. The narrator took time off and was more intentional when looking for the next role, asking critical questions to ensure it was the right fit. The narrator learned lessons about loyalty, knowing oneself, expectations, and recognizing when one is in the wrong place.

Bringing a New Product to Market

A startup hired a new employee to launch a new product, but the strategy they used to bring it to market was not successful. They eventually had to pivot to target enterprises instead, but they underestimated the effort it would take to create a new market. Ultimately, the business was shut down due to the greater investment needed for success. The lesson learned is to be careful of assumptions, pick advisors wisely, and not let enthusiasm cloud judgment.

Dropping the Ball Explicitly

This story is about a program manager who was given significant responsibility in a large corporation. He accepted the responsibility halfheartedly and ended up not delivering on it, leading to a fire drill. He learned the lesson that it is okay to drop the ball as long as it is done explicitly, and to always ask for help when needed. He now makes sure to communicate clearly if he is unable to deliver on a project.

Building a Startup Within a Large Corporation

This article discusses the steps taken by a large corporation to set up a startup within its organization. The corporation identified two main sets of activities to set up for success: defining a business model and attracting the top talent. The business model was based on the company's strengths and weaknesses, and the talent was sourced from universities and a high school teacher's network. The company sought risk-takers who were willing to experiment with new technologies and embrace a fast-fail startup mentality.

Evaluating Engineers: A Three-Step Guide

The author was tasked with deciding who would stay on the team and created a three-step guide for evaluation: performance assessment, career path conversations, and productivity measurement. Performance assessment involves understanding the company needs and evaluating technical competence and interaction with team members and the business. Career path conversations involve discussing plans for the upcoming quarter or year and providing support for professional development. Productivity is measured by tracking work closely but without obsessing over metrics. The author learned that without time pressure, people are empowered to choose tasks that can unlock their potential, document performance-related activities, and have regular one-on-ones.

When an Engineer Has to Make Product Decisions

In transitioning from an IC to an architect in a startup, the author had to take on many responsibilities and learn new skills. They read avidly, connected with peers, and had a mentor to help them adjust to their new role. They also improved their technical skills, introduced new processes, and learned to manage up. The author learned that many people before them had similar challenges, and that it is important to stay technical, keep a consistent pace, and learn to say no.

Understand the History of Agile, or Be Doomed To Repeat It

Agile processes, specifically Scrum, are often seen as the only way to do software, but this view is too restrictive and prescriptive. Agile is the best default answer we have, but it is not perfect and should be treated as an imperfect tool. It is important to understand the historical context of Agile and to be familiar with multiple Agile techniques, as Agile is not a culmination but the most recent iteration in a long line of process improvements.

Leveraging Roadmap Planning for Engagement and Alignment

This article discusses how a product leader can drive productive cross-functional engagement to create a plan that is leveraged for accountability and learning. It suggests an iterative mindset, early interaction with the organization, finding an expression that is authentic to the organization, and creating artifacts that are tailored to the audience. It also suggests a process for keeping artifacts in sync and checking in on progress to plan along the way.

Building a Product Team: Identifying Desired Attributes and Activities

This article outlines a process for building a strong product team by first documenting the desired attributes and activities of the ideal candidate, then sharing it with the organization for feedback and revisions. This document is then used to define the interview activities and post-interview conversations to ensure the right fit for the organization's needs. Separating cultural aspirations from key responsibilities has helped the organization better understand what it needs in a product partner.

Creating Space on Your Roadmap for Innovation and Improvements

This article discusses how to ensure proper alignment on work projects by using three distinct work types (Discover, Build, Strengthen) and a 4-quarter rolling roadmap cadence. It also explains how investing time to review and ratify with cross-functional partners helps to feed learning into the plan, sharpen thinking, and reduce surprises.

Building a Platform Team

As a company grows, it is natural for teams to specialize and the first distinction is between product and platform engineering. It is important to identify the right time to do the split, which is usually when the value of spending engineering cycles to optimize what is being done becomes more apparent. Platform teams are built differently in different companies and should be structured according to the company's North Star and specific initiatives. Platform teams typically work on a longer time horizon than product engineering teams and should use DORA metrics to track progress. It is important to not split the team too soon or too late.

How to Drive Operational Excellence

Product technology leadership face various challenges such as balancing velocity and quality, product features and tune-ups, and staffing investment. The largest determinant of success is the ”speed of innovation”, which consists of two categories: innovation (product features) and tune-up items driving the speed of innovation. Prioritization should be based on customer impact, business impact, and operational efficiency. Alignment and prioritization with the Product and Engineering teams is crucial, and metrics should be captured to inform data-driven decision making. Lastly, transparency and clear communication on decisions and tradeoffs should be maintained, with follow-through on execution and delivery.

Leading an Organization Through a Colossal Change

As a tech leader, the author has taken a variety of actions to mature the team and processes to meet the next phase of the company's growth and needs. This includes restructuring the organization, assessing and putting the right people in the right roles, introducing performance assessment and a 9-box matrix, organizing show-and-tells, tech reviews, tech talks, and roundtable discussions, and introducing external trainers and post-mortems. The outcomes of these actions have been increased engagement, attendance, and frequency of forums/meetings, influencing outside of engineering, and improved engagement scores. The author has also learned the importance of having patience and giving time for the process to mature, holding cross-groups accountable, and training as early as possible.

Adapting Scrum to Continuous Deployment

A development organization was operating on a very inefficient one-month sprint cycle and manual deployment process. The existing leadership team was risk-averse and did not want change. The individual gathered data to support the changes and developed a roadmap to enable fully automated deploys at least once per day. This demonstrated value allowed them to elevate the automation project to an officially sponsored initiative. After achieving the goal of daily fully automated deployments, the heavy sprint cycle development process was the next bottleneck. The individual experimented with process tweaks on a single team, rolling out each successful change to all the other teams. This allowed teams to deliver a predictable flow of work while retaining the ability to quickly react to production incidents and changes in project scope.

Tech Debt Bankruptcy

After realizing that their fixed 20% tech debt budget was not working, a team took action to quantify the amount of time spent on unplanned work, created a three-level priority system for work, and established service ownership to ensure that critical issues were addressed. This resulted in unplanned work dropping in half, production incidents virtually disappearing, and developer happiness doubling. The team learned that service ownership works at small scales and that there is more to "production" than customer-facing components.

A Lack of Clear Vision and the Team Morale

A team had built an in-house product that was launched globally, but had insufficient global coverage and quality issues. An external company released a third-party solution that could replace the in-house product, and the team feared they would be downsized or disbanded. The manager had to balance between what was best for the team and the company, and ultimately decided on a hybrid solution that combined the best of both worlds. The team was encouraged to think from a customer perspective, and transparency and trust were key to motivating the team to work on improvements.

Restructuring a Team: How to Enhance Accountability and Ownership

When the author joined their current company, they found that the team was not structured to execute and scale well due to its size and project-based nature. To address this, the author and their team restructured the team into six smaller subteams with vertical ownership and tech leads to drive a charter and provide a long-term vision. This improved the team's engagement, on-call rotation, and overall reliability. The restructuring also allowed leadership to have more visibility into areas that needed more investment. However, the author also learned that forming a research team too early can be problematic if the underlying platform is not mature enough.

Learning to Sell

A product development lead was given the opportunity to become a product manager and had to learn how to sell the product without any prior experience or training. They read books, blog posts, and ebooks, followed sales influencers on social media, and worked with salespeople. Through tracking data, they improved their social media outreach success rate and started publishing engineering topics on social media. They learned that sales is still helping people and that their engineering background made them a more authentic helper.

Integrating a Junior Engineer Into a New Team

A junior engineer was integrated into a product development team, but the team was not welcoming and the engineer was unfamiliar with the culture and procedures. The engineer was passionate about a technology solution, but the team did not feel the presentation was well-researched enough. The engineer was mentored and the technical leader of the product development worked with them, but the engineer eventually left the company. Lessons learned included creating a better, welcoming culture and pairing the junior engineer with a mentor.

Balancing Your Team and Product Sponsor’s Requirements

As a team lead, I was tasked with managing a team of engineers building a product according to the sponsor's wishes, despite the team's skepticism. To keep the team motivated, I asked the sponsor to set clear objectives, answered all questions, and encouraged the team to document their work. I also took the blame for delays to protect the team from disciplinary action. Ultimately, I learned that it is important to set objectives, explain the value of the work, and not overload the team.

(Not) Finding the Right Job

After joining a company without being intentional about the role, the narrator quickly realized the role was not a good fit and caused a strained relationship with a peer. The narrator took time off and was more intentional when looking for the next role, asking critical questions to ensure it was the right fit. The narrator learned lessons about loyalty, knowing oneself, expectations, and recognizing when one is in the wrong place.

Bringing a New Product to Market

A startup hired a new employee to launch a new product, but the strategy they used to bring it to market was not successful. They eventually had to pivot to target enterprises instead, but they underestimated the effort it would take to create a new market. Ultimately, the business was shut down due to the greater investment needed for success. The lesson learned is to be careful of assumptions, pick advisors wisely, and not let enthusiasm cloud judgment.

Dropping the Ball Explicitly

This story is about a program manager who was given significant responsibility in a large corporation. He accepted the responsibility halfheartedly and ended up not delivering on it, leading to a fire drill. He learned the lesson that it is okay to drop the ball as long as it is done explicitly, and to always ask for help when needed. He now makes sure to communicate clearly if he is unable to deliver on a project.

Building a Startup Within a Large Corporation

This article discusses the steps taken by a large corporation to set up a startup within its organization. The corporation identified two main sets of activities to set up for success: defining a business model and attracting the top talent. The business model was based on the company's strengths and weaknesses, and the talent was sourced from universities and a high school teacher's network. The company sought risk-takers who were willing to experiment with new technologies and embrace a fast-fail startup mentality.

Evaluating Engineers: A Three-Step Guide

The author was tasked with deciding who would stay on the team and created a three-step guide for evaluation: performance assessment, career path conversations, and productivity measurement. Performance assessment involves understanding the company needs and evaluating technical competence and interaction with team members and the business. Career path conversations involve discussing plans for the upcoming quarter or year and providing support for professional development. Productivity is measured by tracking work closely but without obsessing over metrics. The author learned that without time pressure, people are empowered to choose tasks that can unlock their potential, document performance-related activities, and have regular one-on-ones.

When an Engineer Has to Make Product Decisions

In transitioning from an IC to an architect in a startup, the author had to take on many responsibilities and learn new skills. They read avidly, connected with peers, and had a mentor to help them adjust to their new role. They also improved their technical skills, introduced new processes, and learned to manage up. The author learned that many people before them had similar challenges, and that it is important to stay technical, keep a consistent pace, and learn to say no.

Understand the History of Agile, or Be Doomed To Repeat It

Agile processes, specifically Scrum, are often seen as the only way to do software, but this view is too restrictive and prescriptive. Agile is the best default answer we have, but it is not perfect and should be treated as an imperfect tool. It is important to understand the historical context of Agile and to be familiar with multiple Agile techniques, as Agile is not a culmination but the most recent iteration in a long line of process improvements.

Leveraging Roadmap Planning for Engagement and Alignment

This article discusses how a product leader can drive productive cross-functional engagement to create a plan that is leveraged for accountability and learning. It suggests an iterative mindset, early interaction with the organization, finding an expression that is authentic to the organization, and creating artifacts that are tailored to the audience. It also suggests a process for keeping artifacts in sync and checking in on progress to plan along the way.

Building a Product Team: Identifying Desired Attributes and Activities

This article outlines a process for building a strong product team by first documenting the desired attributes and activities of the ideal candidate, then sharing it with the organization for feedback and revisions. This document is then used to define the interview activities and post-interview conversations to ensure the right fit for the organization's needs. Separating cultural aspirations from key responsibilities has helped the organization better understand what it needs in a product partner.

Creating Space on Your Roadmap for Innovation and Improvements

This article discusses how to ensure proper alignment on work projects by using three distinct work types (Discover, Build, Strengthen) and a 4-quarter rolling roadmap cadence. It also explains how investing time to review and ratify with cross-functional partners helps to feed learning into the plan, sharpen thinking, and reduce surprises.

Building a Platform Team

As a company grows, it is natural for teams to specialize and the first distinction is between product and platform engineering. It is important to identify the right time to do the split, which is usually when the value of spending engineering cycles to optimize what is being done becomes more apparent. Platform teams are built differently in different companies and should be structured according to the company's North Star and specific initiatives. Platform teams typically work on a longer time horizon than product engineering teams and should use DORA metrics to track progress. It is important to not split the team too soon or too late.

How to Drive Operational Excellence

Product technology leadership face various challenges such as balancing velocity and quality, product features and tune-ups, and staffing investment. The largest determinant of success is the ”speed of innovation”, which consists of two categories: innovation (product features) and tune-up items driving the speed of innovation. Prioritization should be based on customer impact, business impact, and operational efficiency. Alignment and prioritization with the Product and Engineering teams is crucial, and metrics should be captured to inform data-driven decision making. Lastly, transparency and clear communication on decisions and tradeoffs should be maintained, with follow-through on execution and delivery.

Leading an Organization Through a Colossal Change

As a tech leader, the author has taken a variety of actions to mature the team and processes to meet the next phase of the company's growth and needs. This includes restructuring the organization, assessing and putting the right people in the right roles, introducing performance assessment and a 9-box matrix, organizing show-and-tells, tech reviews, tech talks, and roundtable discussions, and introducing external trainers and post-mortems. The outcomes of these actions have been increased engagement, attendance, and frequency of forums/meetings, influencing outside of engineering, and improved engagement scores. The author has also learned the importance of having patience and giving time for the process to mature, holding cross-groups accountable, and training as early as possible.

Adapting Scrum to Continuous Deployment

A development organization was operating on a very inefficient one-month sprint cycle and manual deployment process. The existing leadership team was risk-averse and did not want change. The individual gathered data to support the changes and developed a roadmap to enable fully automated deploys at least once per day. This demonstrated value allowed them to elevate the automation project to an officially sponsored initiative. After achieving the goal of daily fully automated deployments, the heavy sprint cycle development process was the next bottleneck. The individual experimented with process tweaks on a single team, rolling out each successful change to all the other teams. This allowed teams to deliver a predictable flow of work while retaining the ability to quickly react to production incidents and changes in project scope.

Tech Debt Bankruptcy

After realizing that their fixed 20% tech debt budget was not working, a team took action to quantify the amount of time spent on unplanned work, created a three-level priority system for work, and established service ownership to ensure that critical issues were addressed. This resulted in unplanned work dropping in half, production incidents virtually disappearing, and developer happiness doubling. The team learned that service ownership works at small scales and that there is more to "production" than customer-facing components.

A Lack of Clear Vision and the Team Morale

A team had built an in-house product that was launched globally, but had insufficient global coverage and quality issues. An external company released a third-party solution that could replace the in-house product, and the team feared they would be downsized or disbanded. The manager had to balance between what was best for the team and the company, and ultimately decided on a hybrid solution that combined the best of both worlds. The team was encouraged to think from a customer perspective, and transparency and trust were key to motivating the team to work on improvements.

Restructuring a Team: How to Enhance Accountability and Ownership

When the author joined their current company, they found that the team was not structured to execute and scale well due to its size and project-based nature. To address this, the author and their team restructured the team into six smaller subteams with vertical ownership and tech leads to drive a charter and provide a long-term vision. This improved the team's engagement, on-call rotation, and overall reliability. The restructuring also allowed leadership to have more visibility into areas that needed more investment. However, the author also learned that forming a research team too early can be problematic if the underlying platform is not mature enough.

Learning to Sell

A product development lead was given the opportunity to become a product manager and had to learn how to sell the product without any prior experience or training. They read books, blog posts, and ebooks, followed sales influencers on social media, and worked with salespeople. Through tracking data, they improved their social media outreach success rate and started publishing engineering topics on social media. They learned that sales is still helping people and that their engineering background made them a more authentic helper.

Integrating a Junior Engineer Into a New Team

A junior engineer was integrated into a product development team, but the team was not welcoming and the engineer was unfamiliar with the culture and procedures. The engineer was passionate about a technology solution, but the team did not feel the presentation was well-researched enough. The engineer was mentored and the technical leader of the product development worked with them, but the engineer eventually left the company. Lessons learned included creating a better, welcoming culture and pairing the junior engineer with a mentor.

Balancing Your Team and Product Sponsor’s Requirements

As a team lead, I was tasked with managing a team of engineers building a product according to the sponsor's wishes, despite the team's skepticism. To keep the team motivated, I asked the sponsor to set clear objectives, answered all questions, and encouraged the team to document their work. I also took the blame for delays to protect the team from disciplinary action. Ultimately, I learned that it is important to set objectives, explain the value of the work, and not overload the team.

(Not) Finding the Right Job

After joining a company without being intentional about the role, the narrator quickly realized the role was not a good fit and caused a strained relationship with a peer. The narrator took time off and was more intentional when looking for the next role, asking critical questions to ensure it was the right fit. The narrator learned lessons about loyalty, knowing oneself, expectations, and recognizing when one is in the wrong place.

Bringing a New Product to Market

A startup hired a new employee to launch a new product, but the strategy they used to bring it to market was not successful. They eventually had to pivot to target enterprises instead, but they underestimated the effort it would take to create a new market. Ultimately, the business was shut down due to the greater investment needed for success. The lesson learned is to be careful of assumptions, pick advisors wisely, and not let enthusiasm cloud judgment.

Dropping the Ball Explicitly

This story is about a program manager who was given significant responsibility in a large corporation. He accepted the responsibility halfheartedly and ended up not delivering on it, leading to a fire drill. He learned the lesson that it is okay to drop the ball as long as it is done explicitly, and to always ask for help when needed. He now makes sure to communicate clearly if he is unable to deliver on a project.

Building a Startup Within a Large Corporation

This article discusses the steps taken by a large corporation to set up a startup within its organization. The corporation identified two main sets of activities to set up for success: defining a business model and attracting the top talent. The business model was based on the company's strengths and weaknesses, and the talent was sourced from universities and a high school teacher's network. The company sought risk-takers who were willing to experiment with new technologies and embrace a fast-fail startup mentality.

Evaluating Engineers: A Three-Step Guide

The author was tasked with deciding who would stay on the team and created a three-step guide for evaluation: performance assessment, career path conversations, and productivity measurement. Performance assessment involves understanding the company needs and evaluating technical competence and interaction with team members and the business. Career path conversations involve discussing plans for the upcoming quarter or year and providing support for professional development. Productivity is measured by tracking work closely but without obsessing over metrics. The author learned that without time pressure, people are empowered to choose tasks that can unlock their potential, document performance-related activities, and have regular one-on-ones.

When an Engineer Has to Make Product Decisions

In transitioning from an IC to an architect in a startup, the author had to take on many responsibilities and learn new skills. They read avidly, connected with peers, and had a mentor to help them adjust to their new role. They also improved their technical skills, introduced new processes, and learned to manage up. The author learned that many people before them had similar challenges, and that it is important to stay technical, keep a consistent pace, and learn to say no.

Understand the History of Agile, or Be Doomed To Repeat It

Agile processes, specifically Scrum, are often seen as the only way to do software, but this view is too restrictive and prescriptive. Agile is the best default answer we have, but it is not perfect and should be treated as an imperfect tool. It is important to understand the historical context of Agile and to be familiar with multiple Agile techniques, as Agile is not a culmination but the most recent iteration in a long line of process improvements.