Knowledge shared by our community

Without a Solid Team You Can’t Build a Good Product

A senior developer was brought in to a team of six developers who were inexperienced and lacked a work-ethos. The developer identified two groups of problems: team and their processes, and decided to first focus on team-related problems. Through one-on-ones and leading by example, the developer was able to increase the team's speed and productivity, reclaim ownership, and demonstrate their values. The developer also learned to be cognizant of how human-nature plays in the team and to manage their leadership capital.

Prioritizing Technical Matters Within Scrum

After introducing the Agile process Scrum to a company, it was discovered that all technical matters were left out of engineering's priority list. To solve this problem, tech items were included in the regular release cycle and became part of the process of prioritization. This allowed the team to plan their work ahead of time, work more effectively, and improve delivering on an amount of promised features in the delegated time frame. The lesson learned was that backlogs, tech items, and tech debt should not be left out of Sprint cycles or off the priority list, but instead included early on and within each cycle.

When Your Team Isn’t Acting Like a Team

When the author joined their last company, the team that reported to them didn't feel like a team. To address this, the author set expectations and brought the team together, creating an open and relaxed atmosphere for them to share and talk about their individual work. They also started going out biweekly for breakfast to get to know each other outside of the workplace. As a result, the team was able to trust each other and solve problems together. The author learned that setting expectations and bringing people together are the best ways to have a team start to feel like a team again, and that it's important to encourage teams to get to know each other outside of the workplace.

Restructuring to Feature-Based Teams

This case study outlines the problem of having a single team responsible for the base layer of a software product, resulting in communication, priority, and delivery issues. To solve this, the team was dissolved and responsibilities were dispersed to the remaining teams. This structural change allowed for faster delivery, as teams were able to refer to the same backlog and have the same priorities. The lesson learned is that if there is a problem with the team structure, one must weigh their options and make the necessary changes.

Pivot to Transform Failures into Opportunities

A friend with expertise in a certain technology had an idea to make it do the seemingly impossible. Initial experiments were promising and they were able to obtain a one-million-dollar purchase order. However, when they tried to scale the technology, it started behaving in an unanticipated way. They tried to make it work the way they originally envisioned it, but eventually decided to step back and ask what problem it was a solution to. This shift of perspective allowed them to reframe the product concept and prototypes they had developed and explore new applications. This pivot generated new opportunities and partnerships and reinvigorated the venture. The lesson learned is that it takes courage to stop and re-evaluate everything, and to embrace different unanticipated perspectives and re-define goals.

Managing Different Personality Types: No “Golden Rule”!

This article discusses the importance of understanding individual personalities when managing a team. It uses the example of an engineering manager who initially managed a team of peers using the Golden Rule, but found it more challenging when managing a diverse team. After introducing the Myers-Briggs Type Indicator (MBTI) framework, the article explains how the manager was able to refactor the role of an individual on the team to better suit their personality type. The article concludes by emphasizing the importance of understanding individual personalities, using MBTI as a tool, and seeking feedback from others to gain a more complete picture of the people being managed.

Getting Promoted: How Can KPIs Help

When considering an employee's promotion, assessing their personal motivation is key. A senior engineer approached the company to step up to the next level, and the company identified areas in which the engineer needed to improve. The engineer had difficulty with social skills, so the company proposed action items and encouraged him to think them through. The company also identified two main challenges: finding clear and precise KPIs and finding the balance between hard and soft skills. The engineer was eventually promoted after meeting the requirements of the career ladder. The company learned that personal motivation is important, the balance between hard and soft skills is challenging, and action items should be discussed and not imposed.

Developing High Performing Teams: How To Transform a Software Developer Into a Product Engineer

This article discusses a problem that many companies face: making detailed plans for product roadmaps and building products without talking to clients first. This often leads to unexpected frictions and a lack of autonomy for product teams. The solution proposed is to explain the context behind decisions, set clear objectives, and measure outcomes instead of outputs. This will allow engineers to become more involved in product decisions and be proactive in front of stakeholders.

Leveraging Diverse Peer Groups for Tighter Feedback

In order to break the isolation of small teams of senior people working on advanced technology projects, a manager had them stage review sessions with each other. This allowed them to communicate with peers who had a shared culture of pushing the envelope, encouraging skill-transfer and creating unexpected collaborations. Unexpected network effects were also observed.

Leveraging the Team to Salvage a Frustrated High-Performer

A manager was faced with a talented team member who was exhibiting signs of disaffection and was on the verge of leaving the team. The manager reframed the issue from an individual to an organizational perspective and developed a plan to help the team member share his ideas with the team and upper management. This plan helped to improve the team's trust and comfort level, and the team member was able to successfully present his insights to management. As a result, the team member was happier, the team was more effective, and the organization benefited from his talent.

Going Low-Tech to Uplevel Agile Practices

In order to improve the agile practices of an inexperienced team, an agile consultant and the author decided to take a radical approach and go low-tech. They bought physical poster boards and post-it notes for the team to track tasks from start to finish. This approach was surprisingly successful, as the teams became attached to their boards and even used them to communicate with stakeholders. The author has since found other opportunities to use low-tech solutions, such as passing around a gold trophy to track who was on-call. Low-tech solutions can still be valuable, even in the world of COVID-19.

Remote Work in Times of the Coronavirus Pandemic

This article provides best-practice instructions for managing remote teams during the coronavirus pandemic, when many organizations are experiencing a sudden shift to remote work. The instructions include overcommunicating, maintaining visual interaction, being proactive, reiterating flexibility, giving more attention, maintaining a work-life balance, maintaining momentum, watching out for new and junior employees, writing things down, keeping company culture, and managing oneself. These instructions should help optimize remote work processes and make the experience more efficient and productive.

Aligning an Ineffective Team to Realize Product Potential

When inheriting a technology product with an ineffective team, the author implemented processes to ensure business continuity and hold the team accountable to their Development Plans. This process involved creating a “Contributions” document to capture the knowledge held by developers, and a “Development Plan” to encourage proactivity and self-evaluation. The author learned that it is essential to establish processes to differentiate effective team members, and that accountability and communication are key to achieving personal and company goals.

Resolving Remote Communication Issues

The Chief Architect of a fully remote team of 20 developers faced communication issues both internally and with customers. To resolve these issues, the Chief Architect created a Google doc to track time zones, split the team into smaller groups, and created Slack channels and dashboards for each project. Additionally, they began recording conversations with customers and created War-Room channels in Slack for urgent issues. These solutions improved communication and response time, and the Chief Architect learned the importance of recording conversations and splitting up large teams.

Infrastructure: On-Site, Colocation, or the Cloud

The CTO of a company was faced with the challenge of transitioning their system into production. Initially, they chose to use bare-metal servers, but soon realized that this was not the best solution for their needs. After moving to colocation servers, the CTO realized that the cloud was the best solution for their needs. The cloud provided better security, cost savings, and storage options. The CTO's leadership and the business both benefited from the switch to the cloud, as they were able to focus on their business logic and the future of the company.

How To Identify the Right Product To Build

Startups need to focus on finding the right product to build before building it. This involves reducing risk by testing assumptions and being customer-driven. A collaborative approach with the product manager, product designer, engineering manager, and other stakeholders should be taken to identify risks, dig into why the project exists, and evaluate the solution. A go-to-market strategy should be created to focus on delivery and OKRs should be set to align people. A lean approach and continuous discovery and delivery is the best way to guarantee business impact and reduce the risk of failure.

Leveling Up Without Direct Support From Your Manager

This article is about a software engineer who was stuck in a career plateau and wanted to expand their skillset. In order to do this, they took three steps: leveling up by learning new languages and frameworks, leading a new project, and teaching. Through these steps, the engineer was able to level up their career and gain new opportunities. The article also emphasizes the importance of having a self-determined game plan and seeking mentors outside of the organization.

Building Customer Driven Backlog Across Several Component Teams

In software development, it can be difficult to enforce a product team to operate in a full-stack way. To solve this problem, a team restructured their engineering teams to have product managers responsible for value streams across different areas and tech leads responsible for components. This setup requires a lot of buy-in from teams in terms of communication and alignment, but it allows everyone to understand the user needs and values and how the product they build will change the user's life.

How to Bring Business Context to the Development Team

This problem was solved by creating a dedicated KPI for the product team that connected strategic business goals and features. This KPI was used to measure the 'share of wallet' and a KPI tree was created to map out features that could help increase revenue. Additionally, it was important to distinguish between leading and lagging indicators and to focus on measurements that can be easily affected and changed over time.

Organizing Stakeholder Requests

The team was having difficulty managing content personalization, on-site visibility, and traffic distribution for stakeholders creating content related to clothing and fashion. The developers were responding to requests with shortcuts and fixes, leading to a difficult-to-maintain solution and a complicated user experience. To address this, the product manager enforced bureaucracy and used user story maps to collect requirements and do requirement engineering. This process helped to create a database of user stories, lower the number of requests, and shift the focus from the solution to the problem. The lesson learned was the importance of understanding the current workflow and desired goals before brainstorming a solution.

Without a Solid Team You Can’t Build a Good Product

A senior developer was brought in to a team of six developers who were inexperienced and lacked a work-ethos. The developer identified two groups of problems: team and their processes, and decided to first focus on team-related problems. Through one-on-ones and leading by example, the developer was able to increase the team's speed and productivity, reclaim ownership, and demonstrate their values. The developer also learned to be cognizant of how human-nature plays in the team and to manage their leadership capital.

Prioritizing Technical Matters Within Scrum

After introducing the Agile process Scrum to a company, it was discovered that all technical matters were left out of engineering's priority list. To solve this problem, tech items were included in the regular release cycle and became part of the process of prioritization. This allowed the team to plan their work ahead of time, work more effectively, and improve delivering on an amount of promised features in the delegated time frame. The lesson learned was that backlogs, tech items, and tech debt should not be left out of Sprint cycles or off the priority list, but instead included early on and within each cycle.

When Your Team Isn’t Acting Like a Team

When the author joined their last company, the team that reported to them didn't feel like a team. To address this, the author set expectations and brought the team together, creating an open and relaxed atmosphere for them to share and talk about their individual work. They also started going out biweekly for breakfast to get to know each other outside of the workplace. As a result, the team was able to trust each other and solve problems together. The author learned that setting expectations and bringing people together are the best ways to have a team start to feel like a team again, and that it's important to encourage teams to get to know each other outside of the workplace.

Restructuring to Feature-Based Teams

This case study outlines the problem of having a single team responsible for the base layer of a software product, resulting in communication, priority, and delivery issues. To solve this, the team was dissolved and responsibilities were dispersed to the remaining teams. This structural change allowed for faster delivery, as teams were able to refer to the same backlog and have the same priorities. The lesson learned is that if there is a problem with the team structure, one must weigh their options and make the necessary changes.

Pivot to Transform Failures into Opportunities

A friend with expertise in a certain technology had an idea to make it do the seemingly impossible. Initial experiments were promising and they were able to obtain a one-million-dollar purchase order. However, when they tried to scale the technology, it started behaving in an unanticipated way. They tried to make it work the way they originally envisioned it, but eventually decided to step back and ask what problem it was a solution to. This shift of perspective allowed them to reframe the product concept and prototypes they had developed and explore new applications. This pivot generated new opportunities and partnerships and reinvigorated the venture. The lesson learned is that it takes courage to stop and re-evaluate everything, and to embrace different unanticipated perspectives and re-define goals.

Managing Different Personality Types: No “Golden Rule”!

This article discusses the importance of understanding individual personalities when managing a team. It uses the example of an engineering manager who initially managed a team of peers using the Golden Rule, but found it more challenging when managing a diverse team. After introducing the Myers-Briggs Type Indicator (MBTI) framework, the article explains how the manager was able to refactor the role of an individual on the team to better suit their personality type. The article concludes by emphasizing the importance of understanding individual personalities, using MBTI as a tool, and seeking feedback from others to gain a more complete picture of the people being managed.

Getting Promoted: How Can KPIs Help

When considering an employee's promotion, assessing their personal motivation is key. A senior engineer approached the company to step up to the next level, and the company identified areas in which the engineer needed to improve. The engineer had difficulty with social skills, so the company proposed action items and encouraged him to think them through. The company also identified two main challenges: finding clear and precise KPIs and finding the balance between hard and soft skills. The engineer was eventually promoted after meeting the requirements of the career ladder. The company learned that personal motivation is important, the balance between hard and soft skills is challenging, and action items should be discussed and not imposed.

Developing High Performing Teams: How To Transform a Software Developer Into a Product Engineer

This article discusses a problem that many companies face: making detailed plans for product roadmaps and building products without talking to clients first. This often leads to unexpected frictions and a lack of autonomy for product teams. The solution proposed is to explain the context behind decisions, set clear objectives, and measure outcomes instead of outputs. This will allow engineers to become more involved in product decisions and be proactive in front of stakeholders.

Leveraging Diverse Peer Groups for Tighter Feedback

In order to break the isolation of small teams of senior people working on advanced technology projects, a manager had them stage review sessions with each other. This allowed them to communicate with peers who had a shared culture of pushing the envelope, encouraging skill-transfer and creating unexpected collaborations. Unexpected network effects were also observed.

Leveraging the Team to Salvage a Frustrated High-Performer

A manager was faced with a talented team member who was exhibiting signs of disaffection and was on the verge of leaving the team. The manager reframed the issue from an individual to an organizational perspective and developed a plan to help the team member share his ideas with the team and upper management. This plan helped to improve the team's trust and comfort level, and the team member was able to successfully present his insights to management. As a result, the team member was happier, the team was more effective, and the organization benefited from his talent.

Going Low-Tech to Uplevel Agile Practices

In order to improve the agile practices of an inexperienced team, an agile consultant and the author decided to take a radical approach and go low-tech. They bought physical poster boards and post-it notes for the team to track tasks from start to finish. This approach was surprisingly successful, as the teams became attached to their boards and even used them to communicate with stakeholders. The author has since found other opportunities to use low-tech solutions, such as passing around a gold trophy to track who was on-call. Low-tech solutions can still be valuable, even in the world of COVID-19.

Remote Work in Times of the Coronavirus Pandemic

This article provides best-practice instructions for managing remote teams during the coronavirus pandemic, when many organizations are experiencing a sudden shift to remote work. The instructions include overcommunicating, maintaining visual interaction, being proactive, reiterating flexibility, giving more attention, maintaining a work-life balance, maintaining momentum, watching out for new and junior employees, writing things down, keeping company culture, and managing oneself. These instructions should help optimize remote work processes and make the experience more efficient and productive.

Aligning an Ineffective Team to Realize Product Potential

When inheriting a technology product with an ineffective team, the author implemented processes to ensure business continuity and hold the team accountable to their Development Plans. This process involved creating a “Contributions” document to capture the knowledge held by developers, and a “Development Plan” to encourage proactivity and self-evaluation. The author learned that it is essential to establish processes to differentiate effective team members, and that accountability and communication are key to achieving personal and company goals.

Resolving Remote Communication Issues

The Chief Architect of a fully remote team of 20 developers faced communication issues both internally and with customers. To resolve these issues, the Chief Architect created a Google doc to track time zones, split the team into smaller groups, and created Slack channels and dashboards for each project. Additionally, they began recording conversations with customers and created War-Room channels in Slack for urgent issues. These solutions improved communication and response time, and the Chief Architect learned the importance of recording conversations and splitting up large teams.

Infrastructure: On-Site, Colocation, or the Cloud

The CTO of a company was faced with the challenge of transitioning their system into production. Initially, they chose to use bare-metal servers, but soon realized that this was not the best solution for their needs. After moving to colocation servers, the CTO realized that the cloud was the best solution for their needs. The cloud provided better security, cost savings, and storage options. The CTO's leadership and the business both benefited from the switch to the cloud, as they were able to focus on their business logic and the future of the company.

How To Identify the Right Product To Build

Startups need to focus on finding the right product to build before building it. This involves reducing risk by testing assumptions and being customer-driven. A collaborative approach with the product manager, product designer, engineering manager, and other stakeholders should be taken to identify risks, dig into why the project exists, and evaluate the solution. A go-to-market strategy should be created to focus on delivery and OKRs should be set to align people. A lean approach and continuous discovery and delivery is the best way to guarantee business impact and reduce the risk of failure.

Leveling Up Without Direct Support From Your Manager

This article is about a software engineer who was stuck in a career plateau and wanted to expand their skillset. In order to do this, they took three steps: leveling up by learning new languages and frameworks, leading a new project, and teaching. Through these steps, the engineer was able to level up their career and gain new opportunities. The article also emphasizes the importance of having a self-determined game plan and seeking mentors outside of the organization.

Building Customer Driven Backlog Across Several Component Teams

In software development, it can be difficult to enforce a product team to operate in a full-stack way. To solve this problem, a team restructured their engineering teams to have product managers responsible for value streams across different areas and tech leads responsible for components. This setup requires a lot of buy-in from teams in terms of communication and alignment, but it allows everyone to understand the user needs and values and how the product they build will change the user's life.

How to Bring Business Context to the Development Team

This problem was solved by creating a dedicated KPI for the product team that connected strategic business goals and features. This KPI was used to measure the 'share of wallet' and a KPI tree was created to map out features that could help increase revenue. Additionally, it was important to distinguish between leading and lagging indicators and to focus on measurements that can be easily affected and changed over time.

Organizing Stakeholder Requests

The team was having difficulty managing content personalization, on-site visibility, and traffic distribution for stakeholders creating content related to clothing and fashion. The developers were responding to requests with shortcuts and fixes, leading to a difficult-to-maintain solution and a complicated user experience. To address this, the product manager enforced bureaucracy and used user story maps to collect requirements and do requirement engineering. This process helped to create a database of user stories, lower the number of requests, and shift the focus from the solution to the problem. The lesson learned was the importance of understanding the current workflow and desired goals before brainstorming a solution.

Without a Solid Team You Can’t Build a Good Product

A senior developer was brought in to a team of six developers who were inexperienced and lacked a work-ethos. The developer identified two groups of problems: team and their processes, and decided to first focus on team-related problems. Through one-on-ones and leading by example, the developer was able to increase the team's speed and productivity, reclaim ownership, and demonstrate their values. The developer also learned to be cognizant of how human-nature plays in the team and to manage their leadership capital.

Prioritizing Technical Matters Within Scrum

After introducing the Agile process Scrum to a company, it was discovered that all technical matters were left out of engineering's priority list. To solve this problem, tech items were included in the regular release cycle and became part of the process of prioritization. This allowed the team to plan their work ahead of time, work more effectively, and improve delivering on an amount of promised features in the delegated time frame. The lesson learned was that backlogs, tech items, and tech debt should not be left out of Sprint cycles or off the priority list, but instead included early on and within each cycle.

When Your Team Isn’t Acting Like a Team

When the author joined their last company, the team that reported to them didn't feel like a team. To address this, the author set expectations and brought the team together, creating an open and relaxed atmosphere for them to share and talk about their individual work. They also started going out biweekly for breakfast to get to know each other outside of the workplace. As a result, the team was able to trust each other and solve problems together. The author learned that setting expectations and bringing people together are the best ways to have a team start to feel like a team again, and that it's important to encourage teams to get to know each other outside of the workplace.

Restructuring to Feature-Based Teams

This case study outlines the problem of having a single team responsible for the base layer of a software product, resulting in communication, priority, and delivery issues. To solve this, the team was dissolved and responsibilities were dispersed to the remaining teams. This structural change allowed for faster delivery, as teams were able to refer to the same backlog and have the same priorities. The lesson learned is that if there is a problem with the team structure, one must weigh their options and make the necessary changes.

Pivot to Transform Failures into Opportunities

A friend with expertise in a certain technology had an idea to make it do the seemingly impossible. Initial experiments were promising and they were able to obtain a one-million-dollar purchase order. However, when they tried to scale the technology, it started behaving in an unanticipated way. They tried to make it work the way they originally envisioned it, but eventually decided to step back and ask what problem it was a solution to. This shift of perspective allowed them to reframe the product concept and prototypes they had developed and explore new applications. This pivot generated new opportunities and partnerships and reinvigorated the venture. The lesson learned is that it takes courage to stop and re-evaluate everything, and to embrace different unanticipated perspectives and re-define goals.

Managing Different Personality Types: No “Golden Rule”!

This article discusses the importance of understanding individual personalities when managing a team. It uses the example of an engineering manager who initially managed a team of peers using the Golden Rule, but found it more challenging when managing a diverse team. After introducing the Myers-Briggs Type Indicator (MBTI) framework, the article explains how the manager was able to refactor the role of an individual on the team to better suit their personality type. The article concludes by emphasizing the importance of understanding individual personalities, using MBTI as a tool, and seeking feedback from others to gain a more complete picture of the people being managed.

Getting Promoted: How Can KPIs Help

When considering an employee's promotion, assessing their personal motivation is key. A senior engineer approached the company to step up to the next level, and the company identified areas in which the engineer needed to improve. The engineer had difficulty with social skills, so the company proposed action items and encouraged him to think them through. The company also identified two main challenges: finding clear and precise KPIs and finding the balance between hard and soft skills. The engineer was eventually promoted after meeting the requirements of the career ladder. The company learned that personal motivation is important, the balance between hard and soft skills is challenging, and action items should be discussed and not imposed.

Developing High Performing Teams: How To Transform a Software Developer Into a Product Engineer

This article discusses a problem that many companies face: making detailed plans for product roadmaps and building products without talking to clients first. This often leads to unexpected frictions and a lack of autonomy for product teams. The solution proposed is to explain the context behind decisions, set clear objectives, and measure outcomes instead of outputs. This will allow engineers to become more involved in product decisions and be proactive in front of stakeholders.

Leveraging Diverse Peer Groups for Tighter Feedback

In order to break the isolation of small teams of senior people working on advanced technology projects, a manager had them stage review sessions with each other. This allowed them to communicate with peers who had a shared culture of pushing the envelope, encouraging skill-transfer and creating unexpected collaborations. Unexpected network effects were also observed.

Leveraging the Team to Salvage a Frustrated High-Performer

A manager was faced with a talented team member who was exhibiting signs of disaffection and was on the verge of leaving the team. The manager reframed the issue from an individual to an organizational perspective and developed a plan to help the team member share his ideas with the team and upper management. This plan helped to improve the team's trust and comfort level, and the team member was able to successfully present his insights to management. As a result, the team member was happier, the team was more effective, and the organization benefited from his talent.

Going Low-Tech to Uplevel Agile Practices

In order to improve the agile practices of an inexperienced team, an agile consultant and the author decided to take a radical approach and go low-tech. They bought physical poster boards and post-it notes for the team to track tasks from start to finish. This approach was surprisingly successful, as the teams became attached to their boards and even used them to communicate with stakeholders. The author has since found other opportunities to use low-tech solutions, such as passing around a gold trophy to track who was on-call. Low-tech solutions can still be valuable, even in the world of COVID-19.

Remote Work in Times of the Coronavirus Pandemic

This article provides best-practice instructions for managing remote teams during the coronavirus pandemic, when many organizations are experiencing a sudden shift to remote work. The instructions include overcommunicating, maintaining visual interaction, being proactive, reiterating flexibility, giving more attention, maintaining a work-life balance, maintaining momentum, watching out for new and junior employees, writing things down, keeping company culture, and managing oneself. These instructions should help optimize remote work processes and make the experience more efficient and productive.

Aligning an Ineffective Team to Realize Product Potential

When inheriting a technology product with an ineffective team, the author implemented processes to ensure business continuity and hold the team accountable to their Development Plans. This process involved creating a “Contributions” document to capture the knowledge held by developers, and a “Development Plan” to encourage proactivity and self-evaluation. The author learned that it is essential to establish processes to differentiate effective team members, and that accountability and communication are key to achieving personal and company goals.

Resolving Remote Communication Issues

The Chief Architect of a fully remote team of 20 developers faced communication issues both internally and with customers. To resolve these issues, the Chief Architect created a Google doc to track time zones, split the team into smaller groups, and created Slack channels and dashboards for each project. Additionally, they began recording conversations with customers and created War-Room channels in Slack for urgent issues. These solutions improved communication and response time, and the Chief Architect learned the importance of recording conversations and splitting up large teams.

Infrastructure: On-Site, Colocation, or the Cloud

The CTO of a company was faced with the challenge of transitioning their system into production. Initially, they chose to use bare-metal servers, but soon realized that this was not the best solution for their needs. After moving to colocation servers, the CTO realized that the cloud was the best solution for their needs. The cloud provided better security, cost savings, and storage options. The CTO's leadership and the business both benefited from the switch to the cloud, as they were able to focus on their business logic and the future of the company.

How To Identify the Right Product To Build

Startups need to focus on finding the right product to build before building it. This involves reducing risk by testing assumptions and being customer-driven. A collaborative approach with the product manager, product designer, engineering manager, and other stakeholders should be taken to identify risks, dig into why the project exists, and evaluate the solution. A go-to-market strategy should be created to focus on delivery and OKRs should be set to align people. A lean approach and continuous discovery and delivery is the best way to guarantee business impact and reduce the risk of failure.

Leveling Up Without Direct Support From Your Manager

This article is about a software engineer who was stuck in a career plateau and wanted to expand their skillset. In order to do this, they took three steps: leveling up by learning new languages and frameworks, leading a new project, and teaching. Through these steps, the engineer was able to level up their career and gain new opportunities. The article also emphasizes the importance of having a self-determined game plan and seeking mentors outside of the organization.

Building Customer Driven Backlog Across Several Component Teams

In software development, it can be difficult to enforce a product team to operate in a full-stack way. To solve this problem, a team restructured their engineering teams to have product managers responsible for value streams across different areas and tech leads responsible for components. This setup requires a lot of buy-in from teams in terms of communication and alignment, but it allows everyone to understand the user needs and values and how the product they build will change the user's life.

How to Bring Business Context to the Development Team

This problem was solved by creating a dedicated KPI for the product team that connected strategic business goals and features. This KPI was used to measure the 'share of wallet' and a KPI tree was created to map out features that could help increase revenue. Additionally, it was important to distinguish between leading and lagging indicators and to focus on measurements that can be easily affected and changed over time.

Organizing Stakeholder Requests

The team was having difficulty managing content personalization, on-site visibility, and traffic distribution for stakeholders creating content related to clothing and fashion. The developers were responding to requests with shortcuts and fixes, leading to a difficult-to-maintain solution and a complicated user experience. To address this, the product manager enforced bureaucracy and used user story maps to collect requirements and do requirement engineering. This process helped to create a database of user stories, lower the number of requests, and shift the focus from the solution to the problem. The lesson learned was the importance of understanding the current workflow and desired goals before brainstorming a solution.

Without a Solid Team You Can’t Build a Good Product

A senior developer was brought in to a team of six developers who were inexperienced and lacked a work-ethos. The developer identified two groups of problems: team and their processes, and decided to first focus on team-related problems. Through one-on-ones and leading by example, the developer was able to increase the team's speed and productivity, reclaim ownership, and demonstrate their values. The developer also learned to be cognizant of how human-nature plays in the team and to manage their leadership capital.

Prioritizing Technical Matters Within Scrum

After introducing the Agile process Scrum to a company, it was discovered that all technical matters were left out of engineering's priority list. To solve this problem, tech items were included in the regular release cycle and became part of the process of prioritization. This allowed the team to plan their work ahead of time, work more effectively, and improve delivering on an amount of promised features in the delegated time frame. The lesson learned was that backlogs, tech items, and tech debt should not be left out of Sprint cycles or off the priority list, but instead included early on and within each cycle.

When Your Team Isn’t Acting Like a Team

When the author joined their last company, the team that reported to them didn't feel like a team. To address this, the author set expectations and brought the team together, creating an open and relaxed atmosphere for them to share and talk about their individual work. They also started going out biweekly for breakfast to get to know each other outside of the workplace. As a result, the team was able to trust each other and solve problems together. The author learned that setting expectations and bringing people together are the best ways to have a team start to feel like a team again, and that it's important to encourage teams to get to know each other outside of the workplace.

Restructuring to Feature-Based Teams

This case study outlines the problem of having a single team responsible for the base layer of a software product, resulting in communication, priority, and delivery issues. To solve this, the team was dissolved and responsibilities were dispersed to the remaining teams. This structural change allowed for faster delivery, as teams were able to refer to the same backlog and have the same priorities. The lesson learned is that if there is a problem with the team structure, one must weigh their options and make the necessary changes.

Pivot to Transform Failures into Opportunities

A friend with expertise in a certain technology had an idea to make it do the seemingly impossible. Initial experiments were promising and they were able to obtain a one-million-dollar purchase order. However, when they tried to scale the technology, it started behaving in an unanticipated way. They tried to make it work the way they originally envisioned it, but eventually decided to step back and ask what problem it was a solution to. This shift of perspective allowed them to reframe the product concept and prototypes they had developed and explore new applications. This pivot generated new opportunities and partnerships and reinvigorated the venture. The lesson learned is that it takes courage to stop and re-evaluate everything, and to embrace different unanticipated perspectives and re-define goals.

Managing Different Personality Types: No “Golden Rule”!

This article discusses the importance of understanding individual personalities when managing a team. It uses the example of an engineering manager who initially managed a team of peers using the Golden Rule, but found it more challenging when managing a diverse team. After introducing the Myers-Briggs Type Indicator (MBTI) framework, the article explains how the manager was able to refactor the role of an individual on the team to better suit their personality type. The article concludes by emphasizing the importance of understanding individual personalities, using MBTI as a tool, and seeking feedback from others to gain a more complete picture of the people being managed.

Getting Promoted: How Can KPIs Help

When considering an employee's promotion, assessing their personal motivation is key. A senior engineer approached the company to step up to the next level, and the company identified areas in which the engineer needed to improve. The engineer had difficulty with social skills, so the company proposed action items and encouraged him to think them through. The company also identified two main challenges: finding clear and precise KPIs and finding the balance between hard and soft skills. The engineer was eventually promoted after meeting the requirements of the career ladder. The company learned that personal motivation is important, the balance between hard and soft skills is challenging, and action items should be discussed and not imposed.

Developing High Performing Teams: How To Transform a Software Developer Into a Product Engineer

This article discusses a problem that many companies face: making detailed plans for product roadmaps and building products without talking to clients first. This often leads to unexpected frictions and a lack of autonomy for product teams. The solution proposed is to explain the context behind decisions, set clear objectives, and measure outcomes instead of outputs. This will allow engineers to become more involved in product decisions and be proactive in front of stakeholders.

Leveraging Diverse Peer Groups for Tighter Feedback

In order to break the isolation of small teams of senior people working on advanced technology projects, a manager had them stage review sessions with each other. This allowed them to communicate with peers who had a shared culture of pushing the envelope, encouraging skill-transfer and creating unexpected collaborations. Unexpected network effects were also observed.

Leveraging the Team to Salvage a Frustrated High-Performer

A manager was faced with a talented team member who was exhibiting signs of disaffection and was on the verge of leaving the team. The manager reframed the issue from an individual to an organizational perspective and developed a plan to help the team member share his ideas with the team and upper management. This plan helped to improve the team's trust and comfort level, and the team member was able to successfully present his insights to management. As a result, the team member was happier, the team was more effective, and the organization benefited from his talent.

Going Low-Tech to Uplevel Agile Practices

In order to improve the agile practices of an inexperienced team, an agile consultant and the author decided to take a radical approach and go low-tech. They bought physical poster boards and post-it notes for the team to track tasks from start to finish. This approach was surprisingly successful, as the teams became attached to their boards and even used them to communicate with stakeholders. The author has since found other opportunities to use low-tech solutions, such as passing around a gold trophy to track who was on-call. Low-tech solutions can still be valuable, even in the world of COVID-19.

Remote Work in Times of the Coronavirus Pandemic

This article provides best-practice instructions for managing remote teams during the coronavirus pandemic, when many organizations are experiencing a sudden shift to remote work. The instructions include overcommunicating, maintaining visual interaction, being proactive, reiterating flexibility, giving more attention, maintaining a work-life balance, maintaining momentum, watching out for new and junior employees, writing things down, keeping company culture, and managing oneself. These instructions should help optimize remote work processes and make the experience more efficient and productive.

Aligning an Ineffective Team to Realize Product Potential

When inheriting a technology product with an ineffective team, the author implemented processes to ensure business continuity and hold the team accountable to their Development Plans. This process involved creating a “Contributions” document to capture the knowledge held by developers, and a “Development Plan” to encourage proactivity and self-evaluation. The author learned that it is essential to establish processes to differentiate effective team members, and that accountability and communication are key to achieving personal and company goals.

Resolving Remote Communication Issues

The Chief Architect of a fully remote team of 20 developers faced communication issues both internally and with customers. To resolve these issues, the Chief Architect created a Google doc to track time zones, split the team into smaller groups, and created Slack channels and dashboards for each project. Additionally, they began recording conversations with customers and created War-Room channels in Slack for urgent issues. These solutions improved communication and response time, and the Chief Architect learned the importance of recording conversations and splitting up large teams.

Infrastructure: On-Site, Colocation, or the Cloud

The CTO of a company was faced with the challenge of transitioning their system into production. Initially, they chose to use bare-metal servers, but soon realized that this was not the best solution for their needs. After moving to colocation servers, the CTO realized that the cloud was the best solution for their needs. The cloud provided better security, cost savings, and storage options. The CTO's leadership and the business both benefited from the switch to the cloud, as they were able to focus on their business logic and the future of the company.

How To Identify the Right Product To Build

Startups need to focus on finding the right product to build before building it. This involves reducing risk by testing assumptions and being customer-driven. A collaborative approach with the product manager, product designer, engineering manager, and other stakeholders should be taken to identify risks, dig into why the project exists, and evaluate the solution. A go-to-market strategy should be created to focus on delivery and OKRs should be set to align people. A lean approach and continuous discovery and delivery is the best way to guarantee business impact and reduce the risk of failure.

Leveling Up Without Direct Support From Your Manager

This article is about a software engineer who was stuck in a career plateau and wanted to expand their skillset. In order to do this, they took three steps: leveling up by learning new languages and frameworks, leading a new project, and teaching. Through these steps, the engineer was able to level up their career and gain new opportunities. The article also emphasizes the importance of having a self-determined game plan and seeking mentors outside of the organization.

Building Customer Driven Backlog Across Several Component Teams

In software development, it can be difficult to enforce a product team to operate in a full-stack way. To solve this problem, a team restructured their engineering teams to have product managers responsible for value streams across different areas and tech leads responsible for components. This setup requires a lot of buy-in from teams in terms of communication and alignment, but it allows everyone to understand the user needs and values and how the product they build will change the user's life.

How to Bring Business Context to the Development Team

This problem was solved by creating a dedicated KPI for the product team that connected strategic business goals and features. This KPI was used to measure the 'share of wallet' and a KPI tree was created to map out features that could help increase revenue. Additionally, it was important to distinguish between leading and lagging indicators and to focus on measurements that can be easily affected and changed over time.

Organizing Stakeholder Requests

The team was having difficulty managing content personalization, on-site visibility, and traffic distribution for stakeholders creating content related to clothing and fashion. The developers were responding to requests with shortcuts and fixes, leading to a difficult-to-maintain solution and a complicated user experience. To address this, the product manager enforced bureaucracy and used user story maps to collect requirements and do requirement engineering. This process helped to create a database of user stories, lower the number of requests, and shift the focus from the solution to the problem. The lesson learned was the importance of understanding the current workflow and desired goals before brainstorming a solution.

Without a Solid Team You Can’t Build a Good Product

A senior developer was brought in to a team of six developers who were inexperienced and lacked a work-ethos. The developer identified two groups of problems: team and their processes, and decided to first focus on team-related problems. Through one-on-ones and leading by example, the developer was able to increase the team's speed and productivity, reclaim ownership, and demonstrate their values. The developer also learned to be cognizant of how human-nature plays in the team and to manage their leadership capital.

Prioritizing Technical Matters Within Scrum

After introducing the Agile process Scrum to a company, it was discovered that all technical matters were left out of engineering's priority list. To solve this problem, tech items were included in the regular release cycle and became part of the process of prioritization. This allowed the team to plan their work ahead of time, work more effectively, and improve delivering on an amount of promised features in the delegated time frame. The lesson learned was that backlogs, tech items, and tech debt should not be left out of Sprint cycles or off the priority list, but instead included early on and within each cycle.

When Your Team Isn’t Acting Like a Team

When the author joined their last company, the team that reported to them didn't feel like a team. To address this, the author set expectations and brought the team together, creating an open and relaxed atmosphere for them to share and talk about their individual work. They also started going out biweekly for breakfast to get to know each other outside of the workplace. As a result, the team was able to trust each other and solve problems together. The author learned that setting expectations and bringing people together are the best ways to have a team start to feel like a team again, and that it's important to encourage teams to get to know each other outside of the workplace.

Restructuring to Feature-Based Teams

This case study outlines the problem of having a single team responsible for the base layer of a software product, resulting in communication, priority, and delivery issues. To solve this, the team was dissolved and responsibilities were dispersed to the remaining teams. This structural change allowed for faster delivery, as teams were able to refer to the same backlog and have the same priorities. The lesson learned is that if there is a problem with the team structure, one must weigh their options and make the necessary changes.

Pivot to Transform Failures into Opportunities

A friend with expertise in a certain technology had an idea to make it do the seemingly impossible. Initial experiments were promising and they were able to obtain a one-million-dollar purchase order. However, when they tried to scale the technology, it started behaving in an unanticipated way. They tried to make it work the way they originally envisioned it, but eventually decided to step back and ask what problem it was a solution to. This shift of perspective allowed them to reframe the product concept and prototypes they had developed and explore new applications. This pivot generated new opportunities and partnerships and reinvigorated the venture. The lesson learned is that it takes courage to stop and re-evaluate everything, and to embrace different unanticipated perspectives and re-define goals.

Managing Different Personality Types: No “Golden Rule”!

This article discusses the importance of understanding individual personalities when managing a team. It uses the example of an engineering manager who initially managed a team of peers using the Golden Rule, but found it more challenging when managing a diverse team. After introducing the Myers-Briggs Type Indicator (MBTI) framework, the article explains how the manager was able to refactor the role of an individual on the team to better suit their personality type. The article concludes by emphasizing the importance of understanding individual personalities, using MBTI as a tool, and seeking feedback from others to gain a more complete picture of the people being managed.

Getting Promoted: How Can KPIs Help

When considering an employee's promotion, assessing their personal motivation is key. A senior engineer approached the company to step up to the next level, and the company identified areas in which the engineer needed to improve. The engineer had difficulty with social skills, so the company proposed action items and encouraged him to think them through. The company also identified two main challenges: finding clear and precise KPIs and finding the balance between hard and soft skills. The engineer was eventually promoted after meeting the requirements of the career ladder. The company learned that personal motivation is important, the balance between hard and soft skills is challenging, and action items should be discussed and not imposed.

Developing High Performing Teams: How To Transform a Software Developer Into a Product Engineer

This article discusses a problem that many companies face: making detailed plans for product roadmaps and building products without talking to clients first. This often leads to unexpected frictions and a lack of autonomy for product teams. The solution proposed is to explain the context behind decisions, set clear objectives, and measure outcomes instead of outputs. This will allow engineers to become more involved in product decisions and be proactive in front of stakeholders.

Leveraging Diverse Peer Groups for Tighter Feedback

In order to break the isolation of small teams of senior people working on advanced technology projects, a manager had them stage review sessions with each other. This allowed them to communicate with peers who had a shared culture of pushing the envelope, encouraging skill-transfer and creating unexpected collaborations. Unexpected network effects were also observed.

Leveraging the Team to Salvage a Frustrated High-Performer

A manager was faced with a talented team member who was exhibiting signs of disaffection and was on the verge of leaving the team. The manager reframed the issue from an individual to an organizational perspective and developed a plan to help the team member share his ideas with the team and upper management. This plan helped to improve the team's trust and comfort level, and the team member was able to successfully present his insights to management. As a result, the team member was happier, the team was more effective, and the organization benefited from his talent.

Going Low-Tech to Uplevel Agile Practices

In order to improve the agile practices of an inexperienced team, an agile consultant and the author decided to take a radical approach and go low-tech. They bought physical poster boards and post-it notes for the team to track tasks from start to finish. This approach was surprisingly successful, as the teams became attached to their boards and even used them to communicate with stakeholders. The author has since found other opportunities to use low-tech solutions, such as passing around a gold trophy to track who was on-call. Low-tech solutions can still be valuable, even in the world of COVID-19.

Remote Work in Times of the Coronavirus Pandemic

This article provides best-practice instructions for managing remote teams during the coronavirus pandemic, when many organizations are experiencing a sudden shift to remote work. The instructions include overcommunicating, maintaining visual interaction, being proactive, reiterating flexibility, giving more attention, maintaining a work-life balance, maintaining momentum, watching out for new and junior employees, writing things down, keeping company culture, and managing oneself. These instructions should help optimize remote work processes and make the experience more efficient and productive.

Aligning an Ineffective Team to Realize Product Potential

When inheriting a technology product with an ineffective team, the author implemented processes to ensure business continuity and hold the team accountable to their Development Plans. This process involved creating a “Contributions” document to capture the knowledge held by developers, and a “Development Plan” to encourage proactivity and self-evaluation. The author learned that it is essential to establish processes to differentiate effective team members, and that accountability and communication are key to achieving personal and company goals.

Resolving Remote Communication Issues

The Chief Architect of a fully remote team of 20 developers faced communication issues both internally and with customers. To resolve these issues, the Chief Architect created a Google doc to track time zones, split the team into smaller groups, and created Slack channels and dashboards for each project. Additionally, they began recording conversations with customers and created War-Room channels in Slack for urgent issues. These solutions improved communication and response time, and the Chief Architect learned the importance of recording conversations and splitting up large teams.

Infrastructure: On-Site, Colocation, or the Cloud

The CTO of a company was faced with the challenge of transitioning their system into production. Initially, they chose to use bare-metal servers, but soon realized that this was not the best solution for their needs. After moving to colocation servers, the CTO realized that the cloud was the best solution for their needs. The cloud provided better security, cost savings, and storage options. The CTO's leadership and the business both benefited from the switch to the cloud, as they were able to focus on their business logic and the future of the company.

How To Identify the Right Product To Build

Startups need to focus on finding the right product to build before building it. This involves reducing risk by testing assumptions and being customer-driven. A collaborative approach with the product manager, product designer, engineering manager, and other stakeholders should be taken to identify risks, dig into why the project exists, and evaluate the solution. A go-to-market strategy should be created to focus on delivery and OKRs should be set to align people. A lean approach and continuous discovery and delivery is the best way to guarantee business impact and reduce the risk of failure.

Leveling Up Without Direct Support From Your Manager

This article is about a software engineer who was stuck in a career plateau and wanted to expand their skillset. In order to do this, they took three steps: leveling up by learning new languages and frameworks, leading a new project, and teaching. Through these steps, the engineer was able to level up their career and gain new opportunities. The article also emphasizes the importance of having a self-determined game plan and seeking mentors outside of the organization.

Building Customer Driven Backlog Across Several Component Teams

In software development, it can be difficult to enforce a product team to operate in a full-stack way. To solve this problem, a team restructured their engineering teams to have product managers responsible for value streams across different areas and tech leads responsible for components. This setup requires a lot of buy-in from teams in terms of communication and alignment, but it allows everyone to understand the user needs and values and how the product they build will change the user's life.

How to Bring Business Context to the Development Team

This problem was solved by creating a dedicated KPI for the product team that connected strategic business goals and features. This KPI was used to measure the 'share of wallet' and a KPI tree was created to map out features that could help increase revenue. Additionally, it was important to distinguish between leading and lagging indicators and to focus on measurements that can be easily affected and changed over time.

Organizing Stakeholder Requests

The team was having difficulty managing content personalization, on-site visibility, and traffic distribution for stakeholders creating content related to clothing and fashion. The developers were responding to requests with shortcuts and fixes, leading to a difficult-to-maintain solution and a complicated user experience. To address this, the product manager enforced bureaucracy and used user story maps to collect requirements and do requirement engineering. This process helped to create a database of user stories, lower the number of requests, and shift the focus from the solution to the problem. The lesson learned was the importance of understanding the current workflow and desired goals before brainstorming a solution.

Without a Solid Team You Can’t Build a Good Product

A senior developer was brought in to a team of six developers who were inexperienced and lacked a work-ethos. The developer identified two groups of problems: team and their processes, and decided to first focus on team-related problems. Through one-on-ones and leading by example, the developer was able to increase the team's speed and productivity, reclaim ownership, and demonstrate their values. The developer also learned to be cognizant of how human-nature plays in the team and to manage their leadership capital.

Prioritizing Technical Matters Within Scrum

After introducing the Agile process Scrum to a company, it was discovered that all technical matters were left out of engineering's priority list. To solve this problem, tech items were included in the regular release cycle and became part of the process of prioritization. This allowed the team to plan their work ahead of time, work more effectively, and improve delivering on an amount of promised features in the delegated time frame. The lesson learned was that backlogs, tech items, and tech debt should not be left out of Sprint cycles or off the priority list, but instead included early on and within each cycle.

When Your Team Isn’t Acting Like a Team

When the author joined their last company, the team that reported to them didn't feel like a team. To address this, the author set expectations and brought the team together, creating an open and relaxed atmosphere for them to share and talk about their individual work. They also started going out biweekly for breakfast to get to know each other outside of the workplace. As a result, the team was able to trust each other and solve problems together. The author learned that setting expectations and bringing people together are the best ways to have a team start to feel like a team again, and that it's important to encourage teams to get to know each other outside of the workplace.

Restructuring to Feature-Based Teams

This case study outlines the problem of having a single team responsible for the base layer of a software product, resulting in communication, priority, and delivery issues. To solve this, the team was dissolved and responsibilities were dispersed to the remaining teams. This structural change allowed for faster delivery, as teams were able to refer to the same backlog and have the same priorities. The lesson learned is that if there is a problem with the team structure, one must weigh their options and make the necessary changes.

Pivot to Transform Failures into Opportunities

A friend with expertise in a certain technology had an idea to make it do the seemingly impossible. Initial experiments were promising and they were able to obtain a one-million-dollar purchase order. However, when they tried to scale the technology, it started behaving in an unanticipated way. They tried to make it work the way they originally envisioned it, but eventually decided to step back and ask what problem it was a solution to. This shift of perspective allowed them to reframe the product concept and prototypes they had developed and explore new applications. This pivot generated new opportunities and partnerships and reinvigorated the venture. The lesson learned is that it takes courage to stop and re-evaluate everything, and to embrace different unanticipated perspectives and re-define goals.

Managing Different Personality Types: No “Golden Rule”!

This article discusses the importance of understanding individual personalities when managing a team. It uses the example of an engineering manager who initially managed a team of peers using the Golden Rule, but found it more challenging when managing a diverse team. After introducing the Myers-Briggs Type Indicator (MBTI) framework, the article explains how the manager was able to refactor the role of an individual on the team to better suit their personality type. The article concludes by emphasizing the importance of understanding individual personalities, using MBTI as a tool, and seeking feedback from others to gain a more complete picture of the people being managed.

Getting Promoted: How Can KPIs Help

When considering an employee's promotion, assessing their personal motivation is key. A senior engineer approached the company to step up to the next level, and the company identified areas in which the engineer needed to improve. The engineer had difficulty with social skills, so the company proposed action items and encouraged him to think them through. The company also identified two main challenges: finding clear and precise KPIs and finding the balance between hard and soft skills. The engineer was eventually promoted after meeting the requirements of the career ladder. The company learned that personal motivation is important, the balance between hard and soft skills is challenging, and action items should be discussed and not imposed.

Developing High Performing Teams: How To Transform a Software Developer Into a Product Engineer

This article discusses a problem that many companies face: making detailed plans for product roadmaps and building products without talking to clients first. This often leads to unexpected frictions and a lack of autonomy for product teams. The solution proposed is to explain the context behind decisions, set clear objectives, and measure outcomes instead of outputs. This will allow engineers to become more involved in product decisions and be proactive in front of stakeholders.

Leveraging Diverse Peer Groups for Tighter Feedback

In order to break the isolation of small teams of senior people working on advanced technology projects, a manager had them stage review sessions with each other. This allowed them to communicate with peers who had a shared culture of pushing the envelope, encouraging skill-transfer and creating unexpected collaborations. Unexpected network effects were also observed.

Leveraging the Team to Salvage a Frustrated High-Performer

A manager was faced with a talented team member who was exhibiting signs of disaffection and was on the verge of leaving the team. The manager reframed the issue from an individual to an organizational perspective and developed a plan to help the team member share his ideas with the team and upper management. This plan helped to improve the team's trust and comfort level, and the team member was able to successfully present his insights to management. As a result, the team member was happier, the team was more effective, and the organization benefited from his talent.

Going Low-Tech to Uplevel Agile Practices

In order to improve the agile practices of an inexperienced team, an agile consultant and the author decided to take a radical approach and go low-tech. They bought physical poster boards and post-it notes for the team to track tasks from start to finish. This approach was surprisingly successful, as the teams became attached to their boards and even used them to communicate with stakeholders. The author has since found other opportunities to use low-tech solutions, such as passing around a gold trophy to track who was on-call. Low-tech solutions can still be valuable, even in the world of COVID-19.

Remote Work in Times of the Coronavirus Pandemic

This article provides best-practice instructions for managing remote teams during the coronavirus pandemic, when many organizations are experiencing a sudden shift to remote work. The instructions include overcommunicating, maintaining visual interaction, being proactive, reiterating flexibility, giving more attention, maintaining a work-life balance, maintaining momentum, watching out for new and junior employees, writing things down, keeping company culture, and managing oneself. These instructions should help optimize remote work processes and make the experience more efficient and productive.

Aligning an Ineffective Team to Realize Product Potential

When inheriting a technology product with an ineffective team, the author implemented processes to ensure business continuity and hold the team accountable to their Development Plans. This process involved creating a “Contributions” document to capture the knowledge held by developers, and a “Development Plan” to encourage proactivity and self-evaluation. The author learned that it is essential to establish processes to differentiate effective team members, and that accountability and communication are key to achieving personal and company goals.

Resolving Remote Communication Issues

The Chief Architect of a fully remote team of 20 developers faced communication issues both internally and with customers. To resolve these issues, the Chief Architect created a Google doc to track time zones, split the team into smaller groups, and created Slack channels and dashboards for each project. Additionally, they began recording conversations with customers and created War-Room channels in Slack for urgent issues. These solutions improved communication and response time, and the Chief Architect learned the importance of recording conversations and splitting up large teams.

Infrastructure: On-Site, Colocation, or the Cloud

The CTO of a company was faced with the challenge of transitioning their system into production. Initially, they chose to use bare-metal servers, but soon realized that this was not the best solution for their needs. After moving to colocation servers, the CTO realized that the cloud was the best solution for their needs. The cloud provided better security, cost savings, and storage options. The CTO's leadership and the business both benefited from the switch to the cloud, as they were able to focus on their business logic and the future of the company.

How To Identify the Right Product To Build

Startups need to focus on finding the right product to build before building it. This involves reducing risk by testing assumptions and being customer-driven. A collaborative approach with the product manager, product designer, engineering manager, and other stakeholders should be taken to identify risks, dig into why the project exists, and evaluate the solution. A go-to-market strategy should be created to focus on delivery and OKRs should be set to align people. A lean approach and continuous discovery and delivery is the best way to guarantee business impact and reduce the risk of failure.

Leveling Up Without Direct Support From Your Manager

This article is about a software engineer who was stuck in a career plateau and wanted to expand their skillset. In order to do this, they took three steps: leveling up by learning new languages and frameworks, leading a new project, and teaching. Through these steps, the engineer was able to level up their career and gain new opportunities. The article also emphasizes the importance of having a self-determined game plan and seeking mentors outside of the organization.

Building Customer Driven Backlog Across Several Component Teams

In software development, it can be difficult to enforce a product team to operate in a full-stack way. To solve this problem, a team restructured their engineering teams to have product managers responsible for value streams across different areas and tech leads responsible for components. This setup requires a lot of buy-in from teams in terms of communication and alignment, but it allows everyone to understand the user needs and values and how the product they build will change the user's life.

How to Bring Business Context to the Development Team

This problem was solved by creating a dedicated KPI for the product team that connected strategic business goals and features. This KPI was used to measure the 'share of wallet' and a KPI tree was created to map out features that could help increase revenue. Additionally, it was important to distinguish between leading and lagging indicators and to focus on measurements that can be easily affected and changed over time.

Organizing Stakeholder Requests

The team was having difficulty managing content personalization, on-site visibility, and traffic distribution for stakeholders creating content related to clothing and fashion. The developers were responding to requests with shortcuts and fixes, leading to a difficult-to-maintain solution and a complicated user experience. To address this, the product manager enforced bureaucracy and used user story maps to collect requirements and do requirement engineering. This process helped to create a database of user stories, lower the number of requests, and shift the focus from the solution to the problem. The lesson learned was the importance of understanding the current workflow and desired goals before brainstorming a solution.