Team & Project Management

Restructuring A Product Team

This article discusses the challenge of structuring a team to work on an umbrella product with 20 sub-products. The author's solution was to slice the umbrella product into sub-products based on user intent and to keep teams as small as possible. To keep all teams on the same page, biweekly all team meetings were held. The author also found that it was better to give product manager duties to a designer or engineer until a new PM could be hired and onboarded.

From Chaos to Structure on the Operations Team

At my previous job, I was assigned a team that was not functioning well and had a poor reputation. I took a number of actions to improve their operations, such as using a single ticketing system, providing training and cross-functional competencies, setting up rotations for the support team, creating runbooks, and setting up standard SLAs. I also established healthy hours for operations and communicated to external stakeholders. Through this process, I learned to take time to assess the situation, spend time with each team member, communicate change to the outside world, and align team celebrations with meaningful milestone deliveries.

Standing up for an Employee in Trouble

A conflict arose between two teams when one team wanted to contribute code to an application owned by the other team. One of the junior engineers made some optimization suggestions which were not taken well by the other team, leading to bullying. The manager of the first team intervened by getting the full story and speaking to the manager of the other team. The engineers apologized for their inappropriate language and the incident was used as an example of how not to behave. The manager learned the importance of conflict resolution and protecting their team.

Securing Buy-In for New Metrics

After introducing metrics to measure the times from pull requests being open and interacted with to being completed and merged, the team cohesion strengthened and the team started to operate more like a team. Initially, the team was skeptical of the metrics, but they soon realized that the metrics provided them with more ammunition when it came to performance assessment and salary reviews. Communication was key to securing buy-in and enforcing a data-driven culture. Metrics around reviews, pull requests, bug meantime to resolution, and the amount of time spent on a story combined with its estimate were all found to be successful.

Head or Tail: What PMs Should Be After

This article discusses the importance of considering both head and tail customers when developing enterprise software products. It suggests that the head customers are solution-driven and the tail customers are problem-driven. The article also emphasizes the need to focus on core use cases and create delightful experiences rather than blindly building features for the biggest customers. Finally, it suggests that it takes determination from a PM to create an intentional tension between the needs and wants of the head and tail customers.

How to Lead your Leaders

When expectations are not met, people can become frustrated and complacent, leading to a lack of collaboration and progress. To prevent this, it is important to be aware of the possibility to lead your leaders, recognize that everyone is on the same team, and communicate your needs to your superiors. It is also important to remove the hurdles that cause people to wait around and explain the why to both the team and leadership.