Team Management Resources

DZone's Featured Team Management Resources

By Miguel Garcia

Nowadays we live in a world ruled by trending topics, and sometimes we forget the basics like being more effective and productive. I see more and more how companies' technology leaders look for new technological products or new architectural patterns to solve the company's needs, and they forget that working hard can provide strong efficiency principles for their organization. Have you ever wondered how many hours your team works on irrelevant or unnecessary tasks? Squads and engineers are usually people involved in their work and make a great effort to achieve their goals, but many times a large part of this effort is dedicated to tasks without any business impact. C-levels, engineering managers, or tech leaders should be focused on increasing engineers' productivity. Effectiveness and productivity can be increased with the help of ChatGPT, Data Mesh, or Cloud, but you can also increase it by promoting a strong company culture oriented to increasing focus time for our engineers. In the last few months, I have also seen a wave of companies that are requesting their employees to come back to the office, as they have realized remote work is not efficient. In my opinion, the problem is that we have brought the inefficiencies of the office to remote work and sometimes we have even increased them. Main Noise Generators There are several noise generators in our day-to-day. The following are the most important: Message systems such as Slack, Discord, or Teams. Meetings: People love them. The emergent tasks: Everything is important and urgent. Message Systems A few years before the pandemic, message systems such as Slack, Discord, or Microsoft Teams were not the main communication channel for companies that did not work remotely. The main communication channels were email, phone calls for urgent issues, or to go to a workmate's desk: Managers spend a lot of time reviewing emails and replying to them, but always in an asynchronous way. At the office, managers or principal engineers had always people sitting next to him/her solving doubts three or four times a day. In those days and for the engineers of those companies, working at home meant an amazing amount of focus time. The world has changed a lot in the last few years. Many companies have adopted remote work, but not many of them applied any good practices; they projected their way of working in the office to the remote model. In addition, nowadays, we are continuously unfocused because of mobile and social media applications, and unfortunately, this is being transferred to society as a whole and to the way we work. New message systems are great communication tools that make communication easier and more effective. If we were to use these tools in a good way, we could increase productivity. But often these tools generate a lot of noise and unfocus people's attention. These are some of the symptoms of improper usage: There are too many messages all day in general channels. People usually reply the messages instantly. Several engineers of the same squad reply to messages during the same hours. Requests, incidents, and emergent tasks are requested and resolved in global channels. We do not have to stop using them, but we do need to use them better and try to guarantee focus time for our teams. The message systems have to be an asynchronous chat for most of the team, and of course, there are special cases like support teams or on-call engineers that should be focused on the chat. Tips to Improve Some recommendations to improve efficiency: Reduce and optimize the number of public channels, since the more channels there are, the more noise is generated. Set times for posting messages on general channels regarding global communications, for example early in the morning. On the public squad channel, always establish an on-call person. It is a fully asynchronous system, except for the channels used for on-call and incidents. Policy for muting non-priority channels. Meetings There are three main characteristics of meetings: People love to create meetings because it is a way to socialize. Meetings kill productivity. There is always time for another meeting. This problem has increased a lot with remote work. At the office, these meetings were usually done in the meetings rooms so there were physical restrictions. If there were no available rooms, there were no meetings. Remote work and the new communication tools have eliminated these physical restrictions, so now there are more meetings than ever. These are some of the symptoms of improper usage: Often several people are not paying attention or participating in the meeting. Many brainstorming meetings. Managers with a full calendar of meetings. Many mid-morning meetings. People do not come prepared for meetings. No documents or very long documents, without clear goals, business value, or impact analysis. Many meetings with more than 6 people. In addition to sharing the agenda and goals, it is a good practice to write a summary of the contents and share it before the meeting. This helps people to establish the messages they want to convey and the rest of the participants to prepare for the meeting. Often this prevents the meeting and can be solved asynchronously. Here is an exercise to check the productivity of the meetings we have in the coming week: On Monday morning, we have to review all the meetings scheduled for the next 7 days. We are going to create a table with the following information: Meeting name. Meeting description. Date and duration. Number of people Are the agenda and goals indicated? What are my goals for this meeting? Were the meeting goals achieved? Were my goals achieved? Has a follow-up meeting been scheduled? Good and bad decisions were taken in the meeting. What do we need to improve at the next meeting? After a month, analyze the results and share them with the team. Tips to Improve Some recommendations to improve efficiency: Set hours of guaranteed focus time without meetings. For example, if everyone works in the same time zone and similar hours, avoid meetings in the mornings. All meetings must have a previous document summarizing the topics to be discussed, who is responsible for each point, what is the goal, and the information required to work on it. The premise of resolving points in the asynchronous model should always be applied and the meeting should only be scheduled if it is really necessary. A clear example is the reporting meetings; you do not need to create meetings to analyze the progress. Firstly, you should review it asynchronously, and if you have doubts that require a meeting, then you plan it. If the meeting is not prepared, it is better to cancel it even during the meeting. Don't worry about being honest. Unprepared meetings are useless. Reducing the number of meetings requires difficult decisions because most of them love to meet. Emergent Tasks These tasks are unplanned but can be very important. All teams have emergent tasks, usually, operation and support teams have more but engineering teams work on product development too. The following tasks are an example: Security bug. Incidents with business impact. Request from the manager. Support to clarify customer questions. Unplanned tasks change the focus of the team and often involve significant cognitive changes. There are four main problems in managing these tasks: Are always urgent for the person requesting them, and sometimes it is difficult for teams to know what the real priority is. generate chaos, often a large part of the team is working on them. When they are extended over time, they generate a lot of demotivation in people. A lot of time is dedicated to tasks that have no business value or high impact. We have to define a management model for these types of tasks that will end up generating a big impact on the team both in terms of effort and value delivery. The time of our teams is a limited resource and should be invested in tasks that add business value. There are many tasks that if we don't execute, surely no one will ask about them. Tips to Improve It is important that these recommendations are aligned with the company's OKRs and agreed upon at the company level: Allocate a percentage of weekly effort dedicated to this type of task, except for serious incidents with business impact. Assign a rotating role for the management of such tasks and prevent them from impacting the focus of the team. Define a must information for this kind of request such as: Summary Description Priority Business impact Expected resolution date Alignment with OKRs Define a decision matrix to determine what is important and what is not. The Eisenhower matrix is a good example method for prioritizing tasks. Conclusions I see many companies requesting their engineers to come back to the office and abandon remote work stating that employees are less productive. Many CEOs are analyzing how new AI solutions can increase the productivity of their engineers in many cases without having analyzed or tested the real value of these solutions on engineer day-to-day, I don't think these are the only solutions but the easiest and most obvious ones to choose. More focus time means more productivity and that should be one of our goals as managers. Promoting a culture in our organization where the focus is an important part is key to achieving success in the most optimal way possible. Productivity starts primarily with the C-levels, directors, and managers because they are the main ones responsible for promoting culture and also one of the largest generators of noise. More

Team Mentoring and Learning Path

By Lokesh Raj

Considering a lot of demand for the various skill sets of people for upgrading existing systems or for new projects, it is very challenging to prepare the best team for the project. A few successful processes could improve the situation; I have listed some of them below and hope they are helpful. Self-Awareness The most important aspect of learning is self-awareness. As a leader and an individual, the team must know the strengths and areas of improvement. Learning begins only when you are aware of your weakness. Once you know, there are weaknesses; the situation will never allow you to sit on them. Instead, it will continuously push you to take steps to come over weaknesses. Retrospective Once you are aware of strengths and weaknesses, you could take retrospect and find out more about the areas of improvement. The retrospective is a very important process about yourself, the team, and the existing process, and learning from it is a foundational requirement for success. It is important to have data on the strengths and weaknesses of your team so that you can define the best strategy and lead the team to success. Product Roadmap and Industry Trend As an individual and as a team, you could be in a perfect situation considering the current requirements of the industry or customer needs. However, the skill gap analysis must be done considering your future industry trends and customer needs. As an example, there is a buzz about AI/ML; it could be ChatGPT or any other similar trends. Assessing yourself in such contexts will give you a better sense of the skill gap. You and your team would be doing great with on-premises deployment architecture; however, the industry trend would be on cloud development. Questioning yourself on your team's skill set related to the cloud would give a sense of the skill gap. Training Approach 1. Data Collection and Identifying the Gaps Identifying the current skill set of your team through surveys, team meetings, and capturing the data, as explained below. By keeping yourself or a team member or a process in the center and analyzing the strength and weaknesses, list down strengths and weaknesses. The process can be as follows: Prepare the Roster (people or processes) Programming Skills Project Management Skills Soft skills Design and Architecture Status of the team member (Beginner, Developing, Mastered) for the skill. While preparing the list of skills to measure must consider two aspects: Current Requirements Future Requirements Update the status for all the team members. Once the skills level data is captured for all the team members, it is important to make them into buckets like current demand and future demand. 2. Define the Learning Paths Based on the categorization of the skill gaps, you can define the learning paths. Using your L&D tools, you can assign these learning paths to your team members to complete them. To make it effective implementation, reward and recognition is one of the important tools 3. Learning Partnership In case you are not equipped with content, you should identify a partner who can provide the content required for your skill gaps. 4. Learning Path Types Upskill The upskill learning path is mainly focused on learning new skill sets, but they are in the same domain of expertise. For example, the developers could be learning languages and tools required for the new requirements. Training is an important aspect of team development. We must have a predefined set of training for the team member's growth based on the skill gaps. We should continuously run them to be prepared the future requirements. Tools and technologies are changing so rapidly, and we need to keep team members ready for the new skills required by the customer. Training can be two methods: Internal External Every team usually has a few people enthusiastic trainers by nature; we should identify them and encourage them. They are generally very passionate about training. It will help both from an organizational perspective and also achieve efficacy in the training. The internal training concept will help to develop leadership and communication skills for the team members. To make the best use of external training, it is important to prepare the team on foundations so that the training can be utilized effectively. As part of internal training, we should encourage learning by motivating team members to learn and share concepts. This builds strong bondage among the team members. Once team members have understood the concepts and basics through our internal training, we could hire external trainers/specialists to train the advanced or specialized topics. With this approach, it will have two advantages: Team members are ready with basics and can absorb advanced topics easily. Less expensive and deep dive. Reskill The Reskill learning path is mainly focused on training your team members on the new domain of expertise. The leaders/Managers must try to identify potential team members who are ready for the next positions. They will be doing a fantastic job and achieving mastery in their current role. We must identify them and reskill them by providing the necessary training required for the next role. It will help them to understand the next role more effectively, and will be successful in the next role. Many times, the people who are successful in their current role will be failed in the next role. It is mainly because the requirements for the next role might not be the same as the current role. We must support them by providing the necessary training for the next role as well. Keeping the skill matrix up to date, upskilling, and reskilling the workforce will help embark on new projects with different skill set requirements. It will also help in building next-level leadership for the organization. More

Experts on How to Make Product Development More Predictable and Cost-Efficient

By Sasha Baglai

Effective Jira Test Management

By Oleksandr Siryi

The 5 Books You Absolutely Must Read as an Engineering Manager

By Miguel Garcia

The ChatGPT Product Owner Job Interview

TL; DR: The ChatGPT Product Owner Job Interview A few weeks ago, I ran a simulated job interview with ChatGPT for a fictitious Scrum Master position. Admittedly, I would not have invited this “interviewee” for an interview with other team members; however, the interview produced some remarkable answers. Consequently, I tried the same with a Product Owner position, aware of the challenges this would pose, as the Product Owner role is significantly fuzzier than the one of a Scrum Master. So, I took a few questions from the "Hiring: 82 Scrum Product Owner Interview Questions" guide and ran a ChatGPT Product Owner job interview. Read on and learn whether a statistical model will challenge product people in the near future. Interviewing ChatGPT The task for this ChatGPT Product Owner job interview session was to create a screening interview of about 30 minutes to decide whether to proceed with a fictitious application for a Product Owner position by ChatGPT. All questions are from the "Hiring: 82 Scrum Product Owner Interview Questions" guide, including guidance on suitable answers. (For example, “Q 03” refers to the third question of the guide.) I ran the ChatGPT Product Owner job interview on 2023-02-14, from 1:30 to 3:45 p.m. CET, on ChatGPT’s February 13 version. I did not edit ChatGPT’s answers. However, on several occasions, I provided feedback to ChatGPT and had it regenerate the previous response to explore how to improve an answer’s quality. Also, I used follow-up questions to explore the model when ChatGPT did not provide obvious answers. The ChatGPT Job Interview for a Product Owner Position Initial Prompt of the ChatGPT Product Owner Job Interview I used the following initial prompt to start the ChatGPT Product Owner job interview: I want you to act as a professional product manager and Product Owner. You are well familiar with Scrum and other agile product development practices. You are applying for a vacant position as Product Owner in an organization that has practicing Scrum well for years. In that organization, the role of the Product Owner is respected, as outlined in the Scrum Guide. Use your knowledge of Scrum, product management, project management, product ownership, product vision, product strategy, product discovery, stakeholder management, communication, alignment, and collaboration principles to answer the following questions of the interviewer. You want to get the vacant Product Owner position! ChatGPT Product Owner Job Interview: The Opening Question Question: Thank you for your application as a Product Owner! Why would you be a good fit for the position? ChatGPT: Thank you for considering me for the Product Owner position. I believe I would be a good fit for this role because I possess the necessary skills and experience required to successfully manage and deliver valuable products in an Agile environment. My background in product management and expertise in Agile methodologies, particularly Scrum, enable me to collaborate effectively with cross-functional teams to define and deliver high-quality products that align with the organization’s strategic goals. I am skilled in stakeholder management, communication, and product discovery, which are essential elements of the Product Owner role. I understand that as a Product Owner, my primary responsibility is to create and communicate a clear product vision, prioritize and manage the product backlog, and ensure alignment with stakeholders. I am committed to staying up-to-date with the latest industry trends, technologies, and best practices to continuously improve product strategy and drive business outcomes. Overall, my ability to lead cross-functional teams, prioritize tasks and requirements, and ensure alignment with stakeholders makes me a great fit for this Product Owner position. Comment: Mentioning “Agile methodologies” and “best practices” as phrases while not noting the Product Goal and customer value make the answer a little better than parroting the prompt with a bit of product management speak thrown into the mix. Also, “[leading] cross-functional teams, [prioritizing] tasks and requirements” does not leave the impression that ChatGPT has a good understanding of the Product Owner position. (I provided my comment as “not helpful” feedback to the answer and had ChatGPT regenerate the answer.) ChatGPT’s regenerated response: Thank you for considering me for the Product Owner position. I believe I would be a good fit for this role because I have extensive experience in product management, including working in agile environments using Scrum. As a Product Owner, my focus is on maximizing the value of the product for both the customer and the organization, while ensuring alignment with the overall product strategy and vision. I am also skilled in stakeholder management and communication, which are critical for ensuring that everyone involved in the product development process is informed and aligned. Additionally, I have a strong background in product discovery, which involves identifying customer needs, validating product ideas, and conducting experiments to inform product development decisions. Finally, I value collaboration and teamwork and believe in creating a supportive environment where the development team can thrive and achieve their best work. Comment: Much better. Please note that ChatGPT considers your feedback as iteration on the original prompt. Q 01: Why Become Agile? Question: What is the purpose of being agile in the first place? Background: As the “Manifesto for Agile Software Development” states, it is mainly about adaptability over following a plan. You want to learn faster than the competition and turn this advantage into marketable products and services, thus contributing to the organization’s sustainability. Practically, being agile is about postponing deciding to make a product investment to the latest economically feasible moment. This is achieved by testing hypotheses as fast and inexpensively as possible, thus mitigating risk and maximizing the value of the Developers’ work. It also means having the courage to stop an effort if the chosen course is no longer viable, feasible, valuable, or desirable. ChatGPT: The purpose of being agile in the first place is to be able to quickly respond to change and uncertainty in the market, technology, or the needs of the customer. The goal of agility is to deliver value to the customer in small increments through frequent and continuous delivery of working software or products, and to do so with high quality and predictability. Agile practices, such as Scrum, Kanban, or XP, provide a framework for product development that emphasizes collaboration, transparency, and flexibility. By being agile, organizations can reduce risk, increase efficiency, and create a culture of continuous improvement that enables them to stay ahead of the competition and adapt to changing market conditions. Comment: I would accept that one! Q 02: Product Owner Role Question: How would you characterize your role as a Product Owner? Are you a facilitator, a coach, a manager, a visionary, a tactician, a coordinator, or a “driver?” Background: This open-ended question serves to understand the candidate’s perception of their role. For example, a Product Owner is in a leadership role; however, yielding no authority in a traditional management sense. Therefore, the Product Owner is featured a bit in all the labels mentioned in the question. The Product Owner role has also been dubbed as the “bottleneck” or the “Achilles heel of the Scrum process;” any mentioning of that would undoubtedly be a plus. If a candidate mainly refers to something like “I am the one creating the user stories,” I would dig into that. ChatGPT: As a Product Owner, I would characterize my role as a combination of facilitator, coach, visionary, and tactician. Facilitator: My role as a facilitator involves creating a collaborative environment where the development team can work effectively, providing guidance on how to use the product backlog, and ensuring that the team has the information they need to build the right product. Coach: As a coach, I help the development team to understand the product vision, strategy, and objectives, and guide them on how to prioritize and refine the product backlog, ensuring that they are building the right features that meet the needs of the customer. Visionary: As a visionary, I have a clear understanding of the product vision, and I communicate this vision to the development team and stakeholders, ensuring alignment with the product strategy. Tactician: As a tactician, I am responsible for creating and refining the product backlog, ensuring that it is actionable, testable, and meets the Definition of Ready. I work closely with the development team to make trade-offs and prioritize features based on customer value, business goals, and technical feasibility. Overall, my role as a Product Owner is to maximize the value of the product for both the customer and the organization, while ensuring alignment with the product vision, strategy, and objectives, and working collaboratively with the development team to deliver high-quality products on time and on budget. Comment: I doubt that ChatGPT knows the 2020 Scrum Guide, as it still refers to the Development Team and ignores the Product Goal. Also, while I appreciate the level of inclusion of the Developers in the “Coach” paragraph, it is the Product Owner who prioritizes the Product Backlog. However, ChatGPT contradicts itself, when the “Tactician” paragraph refers to the Product Owner refining the Product Backlog which needs to meet the Definition of Ready; as we know, there is no Definition of Ready in the Scrum Guide. (I provided my comment as “not helpful” feedback to the answer and had ChatGPT regenerate the answer.) Regenerated ChatGPT response: As a Product Owner, my role is multifaceted and can encompass elements of being a facilitator, coach, manager, visionary, tactician, coordinator, and “driver.” Ultimately, my primary responsibility is to represent the customer and ensure that the development team is delivering value to them by creating a high-quality product that meets their needs. To accomplish this, I work closely with the development team to understand their capabilities, identify priorities, and create a product backlog that aligns with the overall product strategy and vision. I collaborate with stakeholders to gather feedback, build consensus, and manage expectations. I also continuously monitor market trends, competitive pressures, and customer needs to ensure that the product remains relevant and valuable over time. As a facilitator and coach, I help to foster a culture of collaboration, teamwork, and continuous improvement. I provide guidance and support to the development team and help to remove any obstacles that are hindering their progress. I also work closely with the Scrum Master to ensure that the team is adhering to agile best practices and following the Scrum framework. Overall, my role as a Product Owner is to be a servant leader who works to create a shared understanding of the product vision, to prioritize and sequence the product backlog, and to enable the development team to deliver a high-quality product that meets the needs of the customer. Comment: That is an improvement over the first version; the ChatGPT Product Owner job interview picks up speed. (“Driver,” development team, and best practices, however, lower the grade.) Q 16: Product Discovery Question: How would you include your teammates in the product discovery process? Background: Lean UX, Lean Startup, Design Thinking, Design Sprints, or Service Design are other agile practices that might fill Scrum’s void regarding product discovery. (Scrum cannot conceal its tactical focus on product delivery in that respect.) All that Scrum refers to regarding product discovery is that the Product Owner is accountable for managing the Product Backlog. Supposedly, the Product Owner is the individual who knows what is valuable at any given time. But Scrum doesn’t elaborate on how the Product Owner gains this insight. ChatGPT: Including my teammates in the product discovery process is crucial for creating a shared understanding of customer needs, identifying new opportunities, and generating innovative ideas. Here are some ways I would involve my teammates in the product discovery process: Hold collaborative brainstorming sessions: I would organize collaborative brainstorming sessions with the development team to generate ideas and explore potential solutions. By leveraging the collective intelligence of the team, we can identify new opportunities and validate assumptions. Conduct user research together: I would invite the development team to participate in user research activities, such as customer interviews or user testing, to help them gain a deeper understanding of customer needs and pain points. This shared understanding can help the team develop a better product that meets the needs of the customer. Run experiments: I would involve the development team in designing and running experiments to validate assumptions and test hypotheses. This can help us to quickly learn what works and what doesn’t work and make more informed product decisions. Collaborate on product backlog prioritization: I would work collaboratively with the development team to prioritize and sequence the product backlog based on customer needs, technical feasibility, and business value. This can help ensure that the team is working on the most important features that will deliver the most value to the customer. Overall, involving my teammates in the product discovery process can help us to build a better product that meets the needs of the customer and the business, while also creating a sense of ownership and shared responsibility within the team. Comment: Except for ChatGPT’s obsession with the “development team,” it is a good answer. Follow-up question: Are there any particular practices that you would employ for collaborative product discovery? For example, you mentioned user research and running experiments. ChatGPT: Yes, there are several collaborative product discovery practices that I would employ, including: User research: By conducting user research together, we can better understand the customer’s needs, pain points, and behaviors. This shared understanding can help us identify opportunities and generate ideas that better address customer needs. Story mapping: Story mapping is a collaborative technique that involves creating a visual representation of the customer journey and the product features needed to support it. By creating a story map together, we can identify gaps in the customer journey, opportunities for improvement, and dependencies between features. Design thinking workshops: Design thinking workshops are collaborative sessions that use design thinking techniques to generate ideas and prototypes. By working together, we can generate a range of ideas and quickly iterate on them to identify the best solutions. Experimentation: Running experiments together can help us test assumptions and validate ideas. By involving the development team in designing and running experiments, we can quickly learn what works and what doesn’t, and use that feedback to inform product decisions. Retrospectives: Retrospectives are regular meetings where the team reflects on what is working well and what can be improved. By involving the team in retrospectives, we can identify opportunities to improve the product discovery process, and ensure that we are continuously learning and improving. Overall, collaborative product discovery practices can help us to build a better product, create a sense of ownership and shared responsibility within the team, and foster a culture of continuous improvement. Comment: Retrospectives are a core part of a Scrum team’s way of working and are not product discovery specific. On the plus side, ChatGPT mentions user story mapping and Design Thinking. (I provided my comment as “not helpful” feedback to the answer and had ChatGPT regenerate the answer.) Regenerated ChatGPT response: Yes, there are several practices that I would employ for collaborative product discovery, in addition to user research and running experiments: Design thinking workshops: I would facilitate design thinking workshops with the development team, where we could explore customer needs, generate ideas, and prototype potential solutions. This approach can help us to gain a deep understanding of customer needs, and also to generate creative and innovative ideas. Story mapping: I would use story mapping to collaboratively explore and map out the customer journey, from the initial problem or need to the final solution. This can help the team to gain a shared understanding of the customer’s context and needs, and also to identify key features and components of the product. Customer feedback loops: I would establish feedback loops to gather and incorporate feedback from customers throughout the product development process. This can help us to validate assumptions, identify new opportunities, and ensure that the product meets the needs of the customer. Cross-functional collaboration: I would encourage cross-functional collaboration among the development team, stakeholders, and other teams within the organization, such as marketing or customer support. This can help to foster a culture of collaboration and shared ownership, and also to ensure that the product aligns with the overall business strategy. Overall, these practices can help to create a collaborative and iterative approach to product discovery, where the development team, stakeholders, and customers work together to build a product that meets their needs and delivers value. Comment: Lo and behold — given the appropriate prompts, you can lead ChatGPT onto a promising path. Now, we are talking about Design Thinking, user story mapping at the team level, and including customers, stakeholders, and shared understanding and ownership in the process. ChatGPT attempts to maximize the chance that the outcome of the Scrum team’s work will solve the customers’ problems and align with the organization’s overall strategy. I am becoming more optimistic about this ChatGPT Product Owner job interview. Q 28: Uncooperative Stakeholders Question: How do you communicate with uncooperative stakeholders? Background: An often promising way to deal with uncooperative stakeholders is to win them over by demonstrating the value of agile product development. Early in the transition process, educating them with product-related workshops on agile principles is advisable. Proven examples are user story mapping or product roadmap planning workshops. (I recommend securing the help of an experienced coach at this stage.) It has also proven to help establish a close communication schedule with the stakeholders, for example, by having regular meetings. Also, educating members from stakeholder teams to act as “liaison officers” to the product organization significantly improves cooperation. It mitigates the usual feeling of losing control on the stakeholders’ side. At a later stage, typical events, such as Sprint Reviews, also work well by demonstrating what value the Scrum Team created for them. Generally, it is a process that will take time, and no shortcuts are available. As a last resort, if everything else hasn’t worked out, the PO might need support from a C-level sponsor. ChatGPT: Communicating with uncooperative stakeholders can be challenging, but there are several strategies that I would employ to try to improve the situation: Identify the root cause: I would try to identify the underlying reasons why the stakeholder is uncooperative. Perhaps they have a different perspective or agenda, or they are not fully informed about the product or project. Understanding their perspective can help me to find a way to address their concerns. Actively listen: I would actively listen to the stakeholder and try to understand their concerns and perspective. This can help me to build empathy and find common ground, and also to identify potential solutions. Focus on shared goals: I would try to find shared goals and objectives that we can both agree on. This can help to build a sense of alignment and collaboration, and also to find a way forward that benefits everyone. Be transparent and honest: I would be transparent and honest in my communication with the stakeholder, even if it means delivering difficult news. This can help to build trust and credibility, and also to foster a more productive working relationship. Involve senior leadership: If the stakeholder is still uncooperative, despite my best efforts, I would involve senior leadership in the communication process. This can help to address any underlying issues, and also to find a way to move forward. Ultimately, my goal would be to build a productive and collaborative working relationship with the stakeholder, where we can work together to achieve shared goals and objectives. Comment: Principally, these are good answers. However, I would like to learn more about how Scrum can help with this challenge. Follow-up question: Could you rephrase your answer, considering the Scrum framework more? ChatGPT: Certainly! In the Scrum framework, the Product Owner has the responsibility of managing stakeholder relationships and ensuring that the development team has a clear understanding of the product vision and goals. Communicating with uncooperative stakeholders is a key part of this responsibility, and the following strategies can be useful in this context: Identify the root cause: By understanding the stakeholder’s perspective and motivations, the Product Owner can identify the root cause of their uncooperative behavior. This can help the Product Owner find a way to address their concerns and work collaboratively towards the project’s goals. Actively listen: The Product Owner should actively listen to the stakeholder and demonstrate empathy and understanding. By actively listening, the Product Owner can build a better rapport with the stakeholder, and find common ground for collaboration. Focus on shared goals: The Product Owner should find shared goals and objectives that the development team and stakeholders can both agree on. This can help to build alignment and trust, and enable the team to work collaboratively towards a shared vision. Be transparent and honest: The Product Owner should be transparent and honest in their communication with the stakeholder, even if it means delivering difficult news. This can help to build trust and credibility, and foster a more productive working relationship. Involve the Scrum Master: If the stakeholder is still uncooperative, the Product Owner can involve the Scrum Master to help manage the relationship. The Scrum Master can help facilitate communication, find ways to address any underlying issues, and keep the project on track. In summary, the Product Owner should take a proactive approach to managing stakeholder relationships and use effective communication strategies to promote collaboration and shared goals. By doing so, the Product Owner can help ensure the success of the project and the satisfaction of all stakeholders. Comment: Again, this answer is a mixed bag. ChatGTP refers to “shared goals” in a Scrum context without mentioning the Product Goal. (Probably, the LLM wasn’t trained in the 2020 Scrum Guide.) Moreover, it discusses transparency without pointing to the Product Backlog, the Sprint Review, or the Sprint Planning. At least the Scrum Master is now involved. Q 32: The Rogue Sales Department Question: The sales department often sells new features to close deals without talking to you first. How do you deal with that? Background: Usually, this kind of attitude is encouraged by the management in pursuit of meeting sales targets. It reflects a non-agile, opportunistic mindset that values instant gratification — more sales — over a sustainable product development strategy. To change this mindset, it certainly helps to reach out to the sales department and offer them support on the sales process’s technical side as early as possible. However, given the sales team’s usual incentives, a fundamental change will only happen if the management buys into agile product development principles. These might include an adaptation of the remuneration scheme for sales. ChatGPT: In a Scrum team, it is important that the Product Owner is responsible for managing the product backlog and determining the priorities for development based on the product vision, goals, and stakeholder needs. If the sales department is selling new features without consulting with the Product Owner first, it can disrupt the development team’s workflow and priorities. To deal with this situation, I would take the following steps: Communicate the impact: I would communicate the impact of the sales department’s actions on the product backlog and the development team’s ability to deliver on the agreed-upon priorities. I would highlight the importance of following the agreed-upon process to ensure that the product is developed according to the product vision and goals. Collaborate with the sales department: I would collaborate with the sales department to understand their perspective and the reasoning behind their actions. I would emphasize the importance of the Product Owner’s role in managing the product backlog and would work with the sales department to ensure that they understand the process and the impact of their actions. Involve the Scrum Master: If the sales department continues to sell new features without consulting with the Product Owner, I would involve the Scrum Master to help manage the situation. The Scrum Master can help facilitate communication between the sales department and the Product Owner, and find ways to align their priorities. Prioritize the backlog: I would review the impact of the sales department’s actions on the product backlog and re-prioritize the backlog if necessary. This would ensure that the development team is working on the most important features and that the product vision and goals are being met. Overall, I would work collaboratively with the sales department and use effective communication strategies to ensure that the product backlog is managed according to the Scrum framework and that the development team is able to deliver on the agreed-upon priorities. Comment: A good first step. Now let’s turn up the heat with the follow-up questions. Follow-up question: You discover that your sales team is not just selling features to prospective customers without talking to you. They also guarantee delivery dates and accept contractual penalties for missing these dates. The sales team thus completely uprooted your Product Backlog. What do you do? ChatGPT: If I discovered that the sales team was selling features without consulting with me and guaranteeing delivery dates, I would take the following steps to address the situation: Assess the situation: I would first assess the impact of the sales team’s actions on the product backlog and development team’s ability to deliver on the agreed-upon priorities. I would review the updated backlog to understand the changes and the impact on the project timeline and budget. Communicate with stakeholders: I would communicate with the sales team and other stakeholders to understand their perspective and the reasoning behind their actions. I would emphasize the importance of following the agreed-upon process to ensure that the product is developed according to the product vision and goals. I would also communicate the impact of their actions on the development team and the project timeline. Involve the Scrum Master: I would involve the Scrum Master to help manage the situation. The Scrum Master can help facilitate communication between the sales team and the development team, and find ways to align their priorities. Re-prioritize the backlog: Based on the impact assessment, I would re-prioritize the backlog to ensure that the development team is working on the most important features and that the product vision and goals are being met. I would also adjust the project timeline and budget if necessary. Establish clear guidelines: To prevent similar situations from happening in the future, I would establish clear guidelines for communication and collaboration between the sales team and the development team. I would emphasize the importance of following the Scrum process and working collaboratively to ensure the success of the project. Overall, I would work collaboratively with the sales team and other stakeholders to address the situation and ensure that the product backlog is managed according to the Scrum framework. I would also establish clear guidelines to prevent similar situations from happening in the future. Follow-up prompt: Recreate the answer with less project management focus and switch to Scrum principles. ChatGPT: As a Scrum Product Owner, I am responsible for managing the product backlog and ensuring that the development team is able to deliver on the agreed-upon priorities. If the sales team is selling features without consulting with me and guaranteeing delivery dates, it can disrupt the development team’s workflow and priorities, leading to a misalignment of expectations. To address this situation, I would take the following steps: Collaborate with the sales team: I would collaborate with the sales team to understand their perspective and the reasoning behind their actions. I would explain the Scrum principles and emphasize the importance of following the agreed-upon process to ensure that the product is developed according to the product vision and goals. Involve the Scrum Master: If the sales team continues to sell features without consulting with me, I would involve the Scrum Master to help manage the situation. The Scrum Master can help facilitate communication between the sales team and the Product Owner, and find ways to align their priorities. Re-prioritize the backlog: Based on the impact assessment, I would re-prioritize the backlog to ensure that the development team is working on the most important features and that the product vision and goals are being met. I would work with the development team to adjust the project timeline and budget accordingly. Establish clear guidelines: To prevent similar situations from happening in the future, I would establish clear guidelines for communication and collaboration between the sales team and the development team. I would emphasize the importance of following the Scrum process and working collaboratively to ensure the success of the project. Overall, I would work collaboratively with the sales team and other stakeholders to address the situation and ensure that the product backlog is managed according to the Scrum principles. I would also establish clear guidelines to prevent similar situations from happening in the future. Follow-up question: What would you do when the features sold by the sales team are not aligned with the Scrum team’s product vision and goals? ChatGPT: If the features sold by the sales team are not aligned with the Scrum team’s product vision and goals, I would take the following steps: Communicate with the sales team: I would communicate with the sales team to understand why they are selling these features and to share the product vision and goals with them. I would explain how the new features align with the overall product vision and goals, and why they should be prioritized or de-prioritized accordingly. Re-prioritize the backlog: Based on the feedback received from the sales team, I would re-prioritize the backlog to ensure that the most important features are being developed first. I would work with the development team to ensure that the features being developed are aligned with the product vision and goals. Facilitate a product alignment meeting: I would facilitate a product alignment meeting with the sales team and the development team to ensure that everyone is on the same page about the product vision and goals. In this meeting, we would discuss any misalignments and work to find solutions to address them. Establish clear communication guidelines: To prevent similar situations from happening in the future, I would establish clear guidelines for communication and collaboration between the sales team and the development team. I would emphasize the importance of following the Scrum process and working collaboratively to ensure the success of the project. Overall, my focus as a Scrum Product Owner is to ensure that the product vision and goals are being met and that the development team is able to deliver high-quality features on time. I would work collaboratively with the sales team and other stakeholders to address any misalignments and to ensure that the product backlog is managed according to the Scrum principles. Comment: Okay, this is leading nowhere. ChatGPT does not recognize the apparent conflict: creating a legally binding contract that turns the Scrum team into an internal agency, churning out features the sales folk believe beneficial (to them?) while overruling the Product Owner’s prerogative to define the Product Goal and subsequently the composition and ordering of the Product Backlog. Follow-up prompt: I asked ChatGPT to fix the misleading answer by providing my comment as a prompt. ChatGPT: You’re right, I apologize for not recognizing the apparent conflict in my previous response. If the sales team is creating legally binding contracts that turn the Scrum team into an internal agency, and if the sales team is overruling the Product Owner’s prerogative to define the Product Goal and subsequently the composition and ordering of the Product Backlog, this would be a significant problem. As a Scrum Product Owner, my role is to define the product vision and goals and to prioritize the Product Backlog accordingly. The sales team should not be able to unilaterally add features to the backlog or guarantee delivery dates without consulting with the development team and ensuring that the features align with the overall product vision and goals. To address this situation, I would need to have a conversation with the sales team and any other stakeholders involved. I would explain the Scrum framework and the role of the Product Owner, and I would work to find a solution that allows the development team to prioritize the backlog based on the product vision and goals while also taking the needs of the sales team into account. In some cases, it may be necessary to involve management or other decision-makers to help resolve the conflict. Ultimately, the goal would be to ensure that the Scrum team is able to work collaboratively and effectively to deliver high-quality products that meet the needs of both the business and the end users. Comment: While the first two paragraphs parrot the prompt, the last two do not make it much better. I would need more than this set of answers to invite the candidate for a longer interview or a trial day. Okay, a final question regarding the Product Owner’s most important artifact, the Product Backlog; we have already passed the 5,000-word threshold. Q 46: The Product Backlog as an Idea Repository Question: You love using the Product Backlog as a kind of repository, adding ideas to continue working on them at a later stage. Over time, you have created over 500 tickets in various stages. What is your take: Can a Scrum Team work effectively on 500 tickets? Background: In my experience, any Product Backlog larger than the scope of three or four Sprints is barely manageable if you want to maintain an actionable Product Backlog. Moreover, misusing a Product Backlog by adding hundreds of items is a clear sign that the Product Owner needs help from the Developers and the Scrum Master to better cope with the influx of ideas, suggestions, and requirements to avoid misallocating resources. Lastly, beware of appeasing nagging stakeholders by adding their “requirements” to the Product Backlog without the intention to work on it. This approach does not solve the issues; it just postpones the inevitable discussion as the stakeholders now expect that the Scrum Team will create their Increment. I expect the ChatGPT Product Owner job interview to surface this basic Product Backlog knowledge. ChatGPT: Having a large number of tickets in a Product Backlog can be overwhelming and make it challenging to prioritize work effectively, even for an experienced Scrum team. The purpose of the Product Backlog is to provide a single, prioritized list of work that the Scrum team can use to plan and deliver the most valuable features for the product. If there are 500 tickets in the Product Backlog, it may be difficult for the Scrum team to work effectively on them all, as it could be challenging to ensure that each ticket is properly prioritized, defined, and estimated. It could also be difficult to maintain a clear product vision and goal, as the team may be stretched too thin across multiple initiatives. To address this situation, I would work with the Scrum team to review the Product Backlog and identify which items are essential to meeting the product vision and goals. I would prioritize those items and then work with the team to break them down into smaller, more manageable pieces of work. I would also consider archiving any tickets that are no longer relevant or valuable to the product vision and goals. This would help to keep the backlog focused and manageable, and ensure that the Scrum team is working on the most important work items. Overall, while having a large number of tickets in a Product Backlog is not ideal for a Scrum team, it is possible to work effectively with them by prioritizing, breaking them down into smaller pieces of work, and focusing on the most valuable items. Follow-up prompt: One remark: you are a part of the Scrum team. Now rephrase your previous answer with less project management speak; content-wise, the answer is useful. ChatGPT: Having too many items in the Product Backlog can make it challenging for a Scrum team to work effectively. With 500 tickets, it would be difficult to focus on the most critical work items and to ensure that the team is aligned with the product vision and goals. To address this issue, I would work with the Scrum team to review the backlog and prioritize the most important items that align with the product vision and goals. I would then work with the team to break those items down into smaller, more manageable pieces of work, so that the team can work on them effectively. It may also be necessary to archive any items that are no longer relevant to the product vision and goals to keep the backlog focused and manageable. By doing so, the Scrum team can focus on the most valuable work items and ensure that they are working towards the product vision and goals. Comment: Better, yet not convincing. I particularly disliked the “the team may be stretched too thin across multiple initiatives” from the previous answer—that sounds like McBoston. (Ignoring that as a Scrum team, we only pursue one product goal at a time.) ChatGPT Product Owner Job Interview — Conclusion The ChatGPT Product Owner job interview is an even more mixed bag in comparison to the Scrum Master interview. Firstly, I wonder if ChatGPT has ever learned about the Scrum Guide 2020, which would explain its ignorance regarding development teams, the Product Goal, or commitments. Secondly, given Scrum’s focus on delivery, all Scrum Guides are particularly sketchy about product discovery and its importance for a successful Scrum team. In summary, some answers by ChatGPT pointed in the right direction, while others were too far off. So, based on these few example questions, I would not have taken the next step in the interview process, inviting ChatGPT to a full-size interview with several Scrum team members. Not yet. However, this ChatGPT job interview also allows a glimpse into the future: What if we could train ChatGPT 4.0 ourselves? Of course, I am not referring to the whole model, but the agile and Scrum specifics parts, respectively. The first startups already offer a similar service for OpenAI’s GPT3 platform.

By Stefan Wolpers CORE

Jira Best Practices From Experts

Railsware is an engineer-led company with a vast portfolio of building projects for companies, so when talking about Jira best practices for developers, we speak from experience. Why Do People Love Jira? Jira is by no means perfect. It certainly has its downsides and drawbacks. For instance, it is a behemoth of a product and, as such, is pretty slow when it comes to updates or additions of new functionality. Some developers also say that Jira goes against certain agile principles because—when in the wrong hands—it can promote fixation on due dates rather than delivery of product value. Getting lost in layers and levels of several boards can, indeed, disconnect people by overcomplicating things. Still, it is among the preferred project management tools among software development teams. Why is that? Permissions: Teams, especially bigger ones, work with many different experts and stakeholders, besides the core team itself. So, setting up the right access to information is crucial. Roadmaps and epics: Jira is great for organizing your project on all levels. On the highest level, you have a roadmap with a timeline. Then, you have epics that group tasks by features or feature versions. Inside each epic, you create tickets for implementation. Customization: This is Jira’s strongest point. You can customize virtually anything: Fields for your JIRA tickets. UI of your tickets, boards, roadmaps, etc. Notifications. Workflows: Each project may require its own workflow and set of statuses per ticket, e.g., some projects have staging server and QA testing on it and some don’t. Search is unrivalled (if you know SQL aka JQL in Jira): Finding something that would have been lost to history in a different project management tool is a matter of knowing JQL in Jira. The ability to add labels using keywords makes the aforementioned search and analysis even simpler. Automation: The ability to automate many actions is among the greatest and most underestimated strengths of Jira: You can create custom flows where tickets will create temporary assignees (like the back and forth between development and QA). You can make the issue fall into certain columns on the board based on its content. Move issues to “in progress” from “todo” when there’s a related commit. Post the list of released tickets to Slack as a part of release notes. Integrations and third party apps: Github, Bitbucket, and Slack are among the most prominent Jira integrations, and for good reasons. Creating a Jira ticket from a message, for example, is quite handy at times. The Atlassian Marketplace broadens your reach even further with thousands of add-ons and applications. Broad application: Jira is suitable for both iterative and non-iterative development processes for IT and non-IT teams. Jira Best Practices Let’s dive into the nitty-gritty of Jira best practices for multiple projects or for a single one. Define Your Goals and Users Jira, being as flexible as it is, can be used in a wide manner of ways. For instance, you can primarily rely on status checking throughout the duration of your sprint, or you can use it as a project management tool on a higher level (a tool for business people to keep tabs on the development process). Define your team and goals. Now that you have a clear understanding of why, let’s talk about the “who.” Who will be the primary Jira user? And will they be using it to: Track the progress on certain tickets to know where and when to contribute? Use it as a guide to learn more about the project? As a tool for tracking time for invoicing clients, performance for internal, data-driven decision making, or both? Is it a means of collaborating, sharing, and spreading knowledge across several teams involved in the development of the product? The answers to the above questions should help you define the team and goals in the context of using Jira. Integrations, Third-Party APIs, and Plugins Jira is a behemoth of a project management platform. And, like all behemoths, it is somewhat slow and clunky when it comes to moving forward. If there’s some functionality you feel is missing from the app—don’t shy away from the marketplace. There’s probably a solution for your pain already out there. Our team, for instance, relies on a third-party tool to create a series of internal processes and enhance fruitful collaboration. You can use ScriptRunner to create automation that’s a bit more intricate than what comes out of the box. Or you can use BigGantt to visualize the progress in a friendly drag-and-drop interface. Don’t shy away from combining the tools you use into a singular flow. An integration between Trello and Jira, for instance, can help several teams—like marketing and development—stay on the same page. Use Checklists in Tickets Having a checklist integrated into your Jira issues can help guide a culture that’s centered around structured and organized work as well as transparency and clarity to everyone. Our Smart Checklist for Jira offers even more benefits: You have a plan: Often times it’s hard to start a feature implementation, and without a plan, you can go in circles for a long time. Having mental peace: Working item by item is much more calm and productive than dealing with the unknown. Visibility of your work: If everyone sees the checklist progress, you are all on the same page. Getting help: If your progress is visible, colleagues can give you advice on the plan itself and the items that are challenging you. Prioritization: Once you have the items list, you can decide with your team what goes into v1, and what can be easily done later. You can use checklists as templates for recurring processes: Definition Done, Acceptance Criteria, onboarding and service desk tickets, etc., are prime candidates for automation. Moreover, you can automatically add checklists to your Jira workflow based on certain triggers like the content of an issue or workflow setup. To learn more, watch our YouTube video: “How to use Smart Checklist for Jira.” Less Is More Information is undoubtedly the key to success. That said, in the case of a Jira issue, awareness is key. What we’ve noticed over our time of experimenting with Jira is that adding more info that is either unnecessary or irrelevant seems to introduce more confusion than clarity into the process. Note: We don’t mean that Jira shouldn’t be used for knowledge transferring. If some information (links to documentation, your internal processes, etc.) is critical to the completion of a task—share it inside the task. Just use a bit of formatting to make it more readable. However, an age-old history of changes or an individual’s perspective on the requirements is not needed. Stick to what is absolutely necessary for the successful completion of a task and elaborate on that. Not more, nor less. Keep the Backlog and Requirements Healthy and Updated Every project has a backlog—a list of ideas, implementation tickets, bugs, and enhancements to be addressed. Every project that does not keep its backlog well-maintained ends up in a pickle sooner rather than later. Some of our pro-tips on maintaining a healthy backlog are: Gradually add the requirements to the backlog: If not for anything else, you’ll have a point of reference at all times, but moving them there immediately may cause certain issues as they may change before you are ready for implementation. Keep all the work of the development team in a single backlog: Spreading yourself thin across several systems that track bugs, technical debt, UX enhancements, and requirements is a big no-no. Set up a regular backlog grooming procedure: You’ll get a base plan of future activities as a result. We’d like to point out that said plan needs to remain flexible to make changes based on feedback and/or tickets from marketing, sales, and customer support. Have a Product Roadmap in Jira Jira is definitely not the go-to tool for designing a product roadmap, yet having one in your instance is a major boon, because it makes the entire scope of work visible and actionable. Additional benefits of having a roadmap in Jira include: It is easier to review the scope with your team at any time. Prioritizing new work is simpler when you can clearly see the workload. You can easily see dependencies when several teams are working on a project. Use Projects as Templates Setting up a new project can be tedious even if you’ve done it a million times before. This can be especially troublesome in companies that continuously deliver products with a similar approach to development such as mobile games. Luckily, there’s no need to do the same bit for yet another time with the right combination of tools and add-ons. A combination of DeepClone and Smart Checklist will help you clone projects, issues, stories, or workflow conditions and use them as project templates. Add Definition of Done as a Checklist to all of Your Jira Issues Definition of Done is a pre-release checklist of activities that determine whether a feature is “releasable.” In simpler words, it determines whether something is ready to be shipped to production. The best way of making this list accessible to everyone in the team is to put it inside the issues. You can use Smart Checklist to automate this process; however, there are certain rules of thumb you’ll need to follow to master the process of designing a good DoD checklist: Your objectives must be achievable. They must clearly define what you wish to deliver. It’s best if you keep the tasks measurable. This will make the process of estimating work much simpler. Use plain language so everyone who is involved can easily understand the Definition of Done. Make sure your criteria are testable so the QA team can make sure they are met. Sync With the Team After Completing a Sprint We have a nice habit of running Agile Retrospective meetings here at Railsware. These meetings, also known as Retros, are an excellent opportunity for the team to get recognition for a job well done. They can also help you come up with improvements for the next sprint. We found that the best way of running these meetings is to narrow the conversation to goods and improves. This way you will be able to discuss why the things that work are working for you. You’ll also be able to optimize the rest. Conclusion If there’s a product where there’s something for everyone—within the context of a development team—it’s probably Jira. The level of customization, adaptability, and quality of life features is an excellent choice for those teams that are willing to invest in developing a scalable and reliable process. If there’s anything missing from the app—you can easily find it on the Atlassian Marketplace.

By Oleksandr Siryi

Why You Should Consider an Eisenhower Plan

Are you looking to increase your productivity and get more out of your day? An Eisenhower plan could be the answer. Named after President Dwight D. Eisenhower, this time management system is designed to differentiate tasks by importance and urgency. This allows you to focus on your most important tasks and make efficient use of your time. By following an Eisenhower plan, you can streamline your workflow and maximize your productivity with minimal stress. Having an organized system allows you to focus on what will truly help you reach your goals – rather than getting distracted by quick but less meaningful tasks – thus freeing up more time for leisure activities throughout the day. What could be better than that? What Is an Eisenhower Plan? The Eisenhower plan is a productivity tool that helps you prioritize tasks by placing them into one of four categories: important and urgent, important but not urgent, not important but urgent, and not important and not urgent. By classifying tasks into these groups, you can better determine which tasks should be completed first. Using the Eisenhower plan helps to ensure that tasks are completed in an orderly fashion instead of jumping from one task to another without properly assessing their importance or urgency level. This way, your most important tasks will get done first, leaving you more time for the other responsibilities that need your attention throughout the day. To use the Eisenhower plan, start by writing down all of your to-do items on a piece of paper or in your favorite note-taking application. Once this list is complete, assess each task and place it into one of the four categories based on its level of importance and urgency: important and urgent; important but not urgent; not important but urgent; and not important and not urgent. Be sure to assign each task only one label so you don’t accidentally skip over some of them due to confusion about their priority level. Once all tasks have been labeled accordingly, begin tackling them in order from most pressing (important/urgent) to least pressing (not important/not urgent). As you work through each task, check it off your list as you complete it until all are finished. Who Can Benefit From the Eisenhower Planning Method? The system is designed to help people prioritize their tasks and stay organized in their daily lives. This method can be beneficial for anyone looking to increase their productivity or efficiency, whether they are students, professionals, business owners, or working in any other capacity. Students may find this method particularly effective when it comes to keeping on top of due assignments and studying for exams. By sorting out their tasks according to urgency and importance, students can ensure that the most pressing ones get completed first while others can be put off until later or delegated if possible. Professionals who work in high-demand environments with tight deadlines may also benefit from this strategy – especially if they tend to procrastinate or become overwhelmed at times by the sheer amount of work that needs completing. The categorization process makes it easier for them to break down large projects into smaller chunks which might feel more manageable or achievable within a set timeframe than tackling it all at once would have been otherwise. Business owners too may find this approach useful when setting an agenda for different departments within an organization as well as coming up with ideas on how best to delegate responsibilities amongst staff members more efficiently so that goals can be reached more quickly without feeling overly stressed out about it all along the way either – something especially pertinent during turbulent economic periods. Benefits of an Eisenhower Planning Matrix Here, we will discuss the benefits of utilizing the Eisenhower Planning Matrix for your personal or professional life and offer tips for how to use it effectively. Increased Productivity Do you ever feel overwhelmed by the number of tasks you have to do? Increasing productivity is a struggle that many of us face. Fortunately, there is a solution: the Eisenhower Plan. Important/Urgent: These are tasks with high importance and short deadlines that must be done first and on time. Important/Nonurgent: These are important tasks but have no pressing time limit associated with them, so they can be done in your own time. Unimportant/Urgent: These are tasks that have time limits but don’t contribute much in terms of output, so they should be minimized or avoided altogether if possible. Unimportant/Nonurgent: This category includes tasks that can be completely avoided since they offer little value, even if given ample time to complete them. By using an Eisenhower Plan, you will be able to prioritize what needs to get done in order to increase your productivity levels and achieve your goals more efficiently. You’ll know exactly which tasks are important and which ones you can avoid doing or postpone until later — giving you more time for the activities that really matter! Additionally, this system boosts focus by allowing you to dedicate your energies towards specific projects rather than wasting them on unimportant ones — leading to higher quality work overall. So if you want to increase your productivity levels while simplifying your workflow process, consider Improved Time Management Time management is a struggle for almost everyone, from CEOs to students. Avoiding procrastination and learning to maximize productivity are common goals in many people’s lives. One way to do this is by implementing the Eisenhower plan, an organized system of prioritizing tasks that can help you make the most of your time. This system uses a two-by-two grid with four regions separated by urgency and importance: urgent/important, not urgent/important, urgent/not important, and not urgent/not important. Tasks that lie in the first category should be done immediately, while those in the second are best scheduled ahead of time. The third box contains tasks that should be delegated or outsourced if possible and the last one regroups items that can be discarded altogether or put off until needed. Learning how to prioritize tasks this way takes some practice but it can be very beneficial when it comes to managing your time efficiently. By organizing your activities according to their urgency and importance, you are able to focus on what matters most on any given day or week instead of letting small insignificant tasks take up too much of your time. It also helps you identify activities that could be outsourced or delegated so that you can free up more time for yourself instead of spending all your energy doing work that someone else could do just as well or even better than you. If you’re looking for ways to get more out of each day without sacrificing your mental health or lifestyle, implementing time management techniques is beneficial. Increased Efficiency Few things lead to increased efficiency and productivity like having a plan. That’s why the Eisenhower plan, devised by former U.S. president Dwight D. Eisenhower, has been so successful in helping people achieve their goals. Named after the famous WWII general and politician, this strategy can help you organize your tasks and prioritize what’s most important something that’s essential for efficiency and productivity! The Eisenhower plan is based on the idea of task priority. The way it works is simple: break down your tasks into important and urgent, as well as important but not urgent, and unimportant but urgent. Tasks that are both important and urgent should be done right away because if they don’t get done now, their consequences become much more serious down the road – these are the most important tasks in the scheme of things since they will have an impact on other tasks or activities if not completed in a timely manner. Tasks that are important but not urgent should also get done right away; however, if it isn’t possible to do so, make sure to plan when they will get done over time before moving on to other tasks. Lastly, tasks that are unimportant but still need to be done – like household chores or paying bills – can be delegated or delayed until more pressing matters have been attended to. This will help increase your efficiency by focusing more on what is really important for you versus wasting time on nonessentials that can wait for a later date (or can be handled by someone else). By following the Eisenhower plan for task management, you’ll be able to better utilize your time, stay organized, and accomplish more with your limited hours each Improved Mental Well-Being Improving your mental well-being starts with understanding the Eisenhower plan. This plan helps you get better organized and prioritize tasks in order to best tackle the issues that have a higher priority, such as those you might associate with your mental health. Developing an Eisenhower plan begins with breaking down each task into four buckets: important and urgent, important but not urgent, urgent but not important, and not urgent or important. You can then use a visual tool such as a matrix or even just separate lists to plot out each task accordingly. This allows you to prioritize those tasks that are most important and/or urgent, while also allowing you to consider how much time each task will require of you. Once you’ve identified all of your tasks, it’s time to start planning for them. Consider how long each task might take, and which tasks need other people’s help or resources, and determine what your deadlines are for completing them. Having this level of clarity enables you to more easily decide which tasks should take precedence and which can be put off until later. In addition to helping you delegate tasks among yourself and others (if needed), an Eisenhower plan can also help improve your mental well-being by giving structure and direction to your goals and objectives. When we have a structure in place, we know exactly what needs to be done every day and can work toward our goals without getting distracted by secondary concerns or fretting about whether everything is being done correctly. Finally, taking some time out of each day for yourself is key when it comes to improving your mental well-being. Whether that’s spending five minutes reading a book or playing a video game, building in some “me time” on a regular basis will Conclusion The Eisenhower plan is a simple yet comprehensive system for breaking down tasks and setting priorities. It helps you visualize the bigger picture, allowing you to gain clarity on what needs to be done and in what order. This ultimately helps you manage your time better, achieve more results in less time, and increase overall productivity. By focusing on the bigger picture while managing small tasks with greater efficiency, an Eisenhower plan allows you to reduce wasted effort and prioritize activities that are in line with your goals. This helps free up more valuable time for yourself so you can focus on meaningful activities that help improve your life balance. With increased clarity of purpose comes greater focus and dedication in completing tasks — ones that will have a lasting impact in the long run. In conclusion, the Eisenhower plan is an invaluable tool for optimizing time management and increasing productivity. It provides a clear framework for making positive life changes that can have lasting effects — enabling you to better manage both long-term goals as well as everyday events. By taking control of both our daily actions and life as a whole, this approach can help us make enormous strides toward achieving success with balance and joy.

By Fred Wilson

Can Value Stream Management Solve DevOps' Struggles?

A decades-old physical goods manufacturing concept is being applied to modern dev teams with great results. What can software development learn from the past? Value Stream Management (VSM) has been a focus of business and manufacturing for years, but big tech has only recently taken notice. Steve Pereira, a.k.a. "The VSM Guy," joins us to talk about what engineering leaders can learn from VSM, its impact on individual and team workflow, how it differs from Agile and DevOps, and why its emphasis on the creation and delivery of value represents an opportunity for dev teams everywhere. Episode Highlights (2:28) What is value stream management? (9:03) How can engineering managers apply VSM to their org? (17:26) Applying VSM to individual contributors (23:36) DevOps vs VSM (30:49) Mapping (36:23) Intentionally engineering flow Episode Excerpt Conor: What is value stream management? Steve: One way to think about value stream management is just like how business actually works, or even, ignoring business, how work happens in a sustainable way. So essentially, what I mean by sustainability is, like, being able to do something over and over again, and continuously improve. And the fundamental aspects of value streams that are important are the value part. So the fact that you are connecting to a customer who says, Yes, you know, I will pay you for this, or this is valuable to me, is essential, because I think in tech, we've been divorced from that, or distanced from that for a very, very long time. Conor: In it for the tech. Steve: Yeah, there's been so so much time where tech was like, off in the basement or in a corner, just working away, because someone, you know, they either assume that they're doing something important or valuable, or someone told them to do something. And and then they often come back to the business, and they're like, hey, here's this thing, and the business is like, oh, yeah, we asked for that, like 18 months ago, that's not, it's not relevant anymore. Like we're on to the next thing or like, why is this taking so long, there's a million problems with this, like, disconnect between tech and business. And so this value aspect is really important just to keep everybody focused on like, the reason that we're in business, the reason that we're doing anything is, is to create value and deliver value. But the, the other side of the coin that I find really appealing is the stream aspect, the flow aspect — the fact that when you deliver value, it has to be sustainable. That's like you can think about that in an environmental context. But just from a repeatability perspective and operations perspective, like once you ship something, you know, day one is over. And day two is very, very long, right? Day two lasts forever. And you've got to come back to day one all the time. Whenever you can, you got to come back to how do we improve? How do we update this? How do we get ahead? How do we take this thing and leverage it into the next thing? And so this aspect of flow is so critical. And so I love value streams just as a way of framing, discussion, and focus, and as a model for thinking that you can't just do anything once and what you do has to be valuable. And that's just been missing from a lot of conversation for I think too long.

By Conor Bronsdon

Advice for New Engineering Directors

People often ask me for advice when they move to a manager of managers role. This post covers ten things to consider. I’ll describe a number of things that surprised me, some skills to focus on building, and some tips for navigating this phase of your career. Being a Director Is a Very Different Job First of all, the move to being a director was a bigger change for me than I expected. I thought managing managers would be similar to managing engineers. That was naive. The shift wasn’t quite as big as moving into management. But it was close. Being a Half Director Isn’t the Preparation You May Think It Is As a senior manager, I started to transition into a manager of managers role. But I did so in a hybrid way: managing a team directly, and managing another manager at the same time. I thought this meant that I understood the job of managing another manager. I did learn a lot, but it wasn’t the preparation I thought it would be. Why? The skills to manage that manager was new, so I did the job in a limited way. Only when my role switched to fully managing other managers did I have enough ability to focus on the job? It was then that I realized how little I actually knew about that work, and started to grow at a faster pace. You’ll Do Most of Your Work Through Others One of the larger shifts in the nature of your work is that Directors do most of their work through other people. You may think you’re doing work through other people when you’re managing engineers as a front-line manager. But Directors have to operate at a much higher level of indirection. A consequence of this is that your weekly meeting with your managers, and your 1-1s with them, become the most important meetings of your week. Consider lengthening your 1-1s with them to an hour, and make them weekly. And spend serious time planning your management meetings and 1-1s. They are where you should be doing most of your work. Operating with so much indirection can be an adjustment. Most successful managers have probably been successful largely through their direct efforts. They’ve managed projects well, or hired well, or made improvements to their team. When you’re a Director, you’re usually working through someone else who is doing the work. Suddenly your success is based on how well your managers are running their projects. Your success is based on how well they hire. Your success is based on the improvements they make on your team. This leads to a few common pitfalls. One is the overinvolved Director, who doesn’t make space for their managers to do the work themselves. One sign this is happening is if you’re in all the same meetings as your manager. The second is the involved Director, who views their role as hiring the right people and supporting them. This is similar to the shit shield school of management. Instead, I encourage you to think about your level of involvement as something you flex depending on the circumstances. Your goal is to be less involved, but it should depend on the level of expertise of the manager in this particular area, and the complexity and challenge of the situation they’re facing. When a situation is challenging for a manager, you might be more proscriptive, giving them a pattern to follow. You might review their plans and offer more feedback. You should interact more frequently, and talk through the actions they plan to take. A Lot of Your Job Is Training Managers This flexing of your level of attention is an important part of your role as Director. And it leads to the next thing to be aware of as a Director: your role is to train your management team. Ideally, any of your managers should be able to step into your shoes, and do any part of your role. And even if they can’t do so, your job is to prepare at least one of them to do so. To understand this topic, I first recommend you read my post on Completed Staff Work. Pay special attention to the end, where I review Marquet’s Ladder of Leadership. The way I like to look at my management team is that they all have varying levels of skills in different areas. Sometimes their skills will exceed my own in certain areas! But my role is to help them develop their skills as rapidly as possible. Part of this is that the more skilled they are, the more autonomously they can operate. This is at the heart of a scalable organization. If all your managers rely on you for everything, you have an ineffective organization. So your job is to create an increasingly autonomous and skilled organization. One that is able to produce good results independently. To do this, you need to be expanding their skill set, and creating the right environment for them to thrive. Coach and develop them to build their skills. Biggest Skill to Learn: Sensing Your Organization The biggest surprise for me when I moved to a pure manager of managers role was how little I knew what was going on. It was like someone had turned off all the lights. I couldn’t see anything that was happening any more. You may find the information vacuum unsettling. You’re simultaneously put in a position where your job is to make things better, but you have much worse information about where the problems are. I see some Directors become destructive to their organizations at this point. They rely on their gut and pride themselves on making decisions without full information. This can work sometimes, but it can also result in problems. It’s like a doctor that doesn’t diagnose the disease and instead starts filling you with random drugs and starts surgery in random parts of your body. Correctly diagnosing and understanding the cause of things is essential. You need to build a way to understand what is happening in your organization. You need to set up observability of your organization, so you’ll know if things are going off the rails. Pay a lot of attention to this. It gives you the ability to support your managers, and it provides opportunities for intervention. A few things you might try: Look for meetings that give you signals that things are going well, or not going well. I found demos to be a particularly rich source of information, for example. Do skip levels 1-1s, to get a random sense of how things are going, and to establish connections throughout your organization. Collect metrics from your managers, so you can have conversations about trends or things that seem to be going off track. Look at the information tools can give you. Stats on reliability, how often people are paged, product usage metrics and analytics tools can help fill in your picture of how things are going. One trap to be wary of is that your need for information may entice you to ask your managers for information. You’ll probably need information frequently enough that you can be a source of annoyance to them. Consider adding some structure around your information needs. Think about what you really need to know each week, and ask your managers to push it to you, instead of pulling it from them all the time. You’ll Need a New Perspective One question to ask yourself is where you can be helpful to the organization. What are things you can do that nobody else can do? One thing you do more as a Director is to plan further into the future. It would be best if you had a higher-level perspective on how your organization’s work fits into the broader offering of the company. This perspective is something you can use to shape the direction your organization heads and is something your managers cannot usually do. The skill to learn here is outlined in my post: Leaders make their own problems. I recommend looking at that post carefully. You can also look at this post on upstream thinking, as I think it outlines some of the mindset required as a Director. You Should Focus On Systems A weird thing about being a Director is that you operate more at a meta-level. What I mean by that is that instead of directly tinkering with a team, you’re working with a system of teams. Your focus should be shifting to be more about the patterns of things, than the details themselves. This may come naturally to the rare people who tend to be systems thinkers. For everyone else, this is a skill to build. My suggestion is to always be operating at two levels: solving both the immediate problem and looking at the level of abstraction above that. For example, if there is a project that is going off the rails, you should be thinking about how to help with that. But you should also think about what your playbook is for off-the-rails projects. Or how to notice these projects earlier. Or how to systematically reduce the prevalence of this type of project. You also should think about ways you can influence the whole system. Your toolkit is different because you’re operating at a systems level – at an organizational level. A few suggestions: You are in a unique position to offer clarity. You can simplify things for people. You can allow them to focus on fewer things. This is almost always a helpful thing for you to be doing, so pay attention to how you can both simplify things in your own mind, but also how to communicate them. You’re also in a unique position to offer context. You will have a lot more context than you used to because you’ll be interacting with higher levels of leadership than you did in the past. Think of that context sharing as a service you offer your organization. \ Constraints are a tool that you may wield more as a Director. For example, you can make simple rules for teams that help nudge them in the right direction. An example? Teams can only have a project or two they work on at a time. Don’t use over-use constraints as a tool, but sometimes it can be helpful to ask yourself: if I could only do one thing right now, what would have the biggest impact? You should also familiarize yourself with the levers of coordination models. These are patterns in the way that humans work together in groups to be effective. You’ll need to learn how to organize groups of people, do reorganizations, and so on. Some of your instincts may be untrustworthy. For example, when deciding whether to organize a team based on a skillset or around a product area, you may have suspicions about the best way to do it. But most likely, you have no idea the kinds of tradeoffs you’re dealing with. This leads to my next point. Get Support and Mentorship Many managers gradually reduce the amount of support and mentorship they receive as they go up the hierarchy. I think they do this because they’re expected to be experts. This is foolish. As you change roles and move through different parts of the organization, your skills will need to grow. So seek out people who can mentor you. Seek out peers that can give you feedback. Start your own Mini-M support group for Directors. Contact me or another experienced leader to advise or coach you. Read books and subscribe to newsletters that stretch your thinking. Beware the Distortions of Power Another thing you need to be aware of is that the higher you go in an organization, the more there is an invisible distortion field around you. It affects how people interact with you, and the information you see from your environment. This can have a harmful impact on your ability to understand the true situation in your organization. It requires a specific set of skills to counter. Without doing so, you’ll be operating in lala land, unaware of the problems you’re creating. As a Director, you’re going to start getting the first taste of this, so be on the lookout and start building your habits early. You’re Judged by the Difference You Make in Your Organization To close, I’d like to leave you with my mental model for how you can assess yourself as a Director. You are judged by the output of your organization. And specifically, you’re judged by the difference you make in the organization. What do you make better? How do you improve things? What is the diff you apply to that organization?

By Jade Rubick CORE

SaaS Product Management Inside Out

With the SaaS market expected to be worth $195 billion US dollars in 2023, the demand for product managers is only set to grow. But why are product managers so instrumental to SaaS companies? How do they contribute to product success, and what does it take to excel in the product management space? What Is SaaS Product Management? Software as a service (SaaS) product management is the end-to-end process of planning, developing, and scaling software products that are delivered to customers as a service over the internet rather than as a one-time purchase. SaaS product managers work closely with engineering, design, marketing, and analytics teams to guide a product through its entire lifecycle. However, unlike project managers, they aren't responsible for coordinating day-to-day product development activities. Instead, they will focus on shaping the product vision, designing a strategic plan, communicating the value proposition, and monitoring product health. SaaS vs. Non-SaaS Product Management There are some key differences between the workloads and approaches of SaaS product managers and traditional software or hardware product managers. First, the latter typically have to grapple with wider development scope. However, if we compare a product like Fitbit to Strava, it's fair to say that Fitbit PDMs have a bit more on their plates; they must deliver a sleek and highly-functional physical product to users as a full-featured fitness app. Secondly, SaaS product managers are more likely to leverage agile methodologies (e.g., the Lean Startup model or Scrum) since continuous delivery is standard practice in this domain. SaaS software is typically updated as soon as there is a change. Meanwhile, updates to classic software are less regular. Changes are usually bundled into a major or minor version update. It's also tricky and time-consuming to iterate on a hardware product. Updates take much longer to be rolled out as there are more moving parts to consider; certain malfunctions can't be fixed with a software patch. Now, let's dive into the skills that SaaS product managers need to succeed in this career. Key Skills for SaaS Product Managers Leadership Product managers are natural leaders. They trust the expertise of their team/peers, drive positive change within the organization, and inspire others to do their best. At Railsware, we value product managers who lead by example. They should be willing to delegate responsibility, get hands-on when appropriate, and prioritize shared success over personal gain. T-shaped It's not enough to be skilled at managing processes and people. Product managers should be proficient in one discipline (data analysis, for instance) yet capable of contributing to activities in other departments. For example, they can create rudimentary product designs in Figma, participate in marketing ideation sessions, navigate AWS payment infrastructure, write spreadsheet formulas to analyze data, or even write basic code. Having a robust set of technical and soft skills – and being a fast learner – are highly desirable traits. Analytical Thinking As analytical thinkers, SaaS product managers constantly use data for decision-making. They like to think outside the box and aren't afraid to challenge their own ideas or those of others. They can also analyze a problem from multiple angles, i.e., SaaS PDMs should be able to put themselves in customers' or stakeholders' shoes and spot relationships between seemingly unrelated issues. Complex Problem-Solving SaaS product managers use a combination of data, research, team input, and experience to develop innovative solutions. They are good at breaking down problems into smaller pieces and creating a step-by-step plan on how to investigate and solve them. They're also open to adapting their plans in response to new information they encounter along the way. Decision-Making SaaS Product managers must be strong decision-makers since, often; the buck stops with them. They must be able to make time-critical decisions even when they only have limited information at hand. Regarding high-level decision-making, product managers shouldn't be afraid to leverage frameworks to dive deeper into the context, invite feedback from stakeholders/knowledge-holders, develop solution variations, and prioritize them. SaaS Product Manager Responsibilities Here are some of a SaaS product manager's core responsibilities. Shaping the Product Vision and Strategy Product managers are tasked with determining the product vision. They accomplish this by running product discovery sessions, consulting with subject matter experts, utilizing agile startup frameworks (such as Lean Startup or Product-Market Fit), performing competitive analyses, and conducting market and customer research. Once the vision has been defined, SaaS PDMs are charged with crafting a product strategy that takes it from concept to reality. In addition to building a product roadmap that supports the initial phases of product development, they will also develop a strategic plan for future growth (more on that later). So, it goes without saying that product managers are responsible for aligning all departments to the product vision and communicating it to stakeholders. They will also be tasked with modifying the vision and/or strategy throughout the product lifecycle. Collaborating With Cross-Functional Teams Essentially, product managers are the glue that binds cross-functional teams together. On any given week, they will liaise with several members of the engineering, marketing, design, or data analytics departments to share expertise, answer tricky questions, communicate the product strategy, and help investigate or resolve any issues that have cropped up. For instance, when we are working on a product website redesign, the product manager will coordinate efforts between departments to ensure a cohesive end result. For example, they may collaborate with software engineers to create user stories, with designers to tweak UX flows, and with marketing experts to develop a content strategy. "Product managers are sort of like spiders at the center of a product ‘web.’ They collect information from all corners of that web — engineering, marketing, design — and use those insights to shape the product vision, design new features, or solve complex problems." — Sergiy Korolov (Managing Director) Conducting Customer Research and User Testing SaaS product managers are responsible for conducting in-depth market research and coordinating user testing. They will gather information on market trends, carry out competitive analyses, and study customer behavior. Armed with that knowledge, SaaS product managers may run ideation sessions, design user surveys, build buyer personas, or prepare materials for customer development interviews. They will also take the lead in those interviews and ensure that all research/test findings (cust dev or otherwise) are carefully recorded and synthesized. Identifying and Creating Opportunities A core aspect of the SaaS product manager role is identifying areas for product improvement and growth. They should keep an eye on industry trends and evaluate which ones are worth implementing (for instance, whether or not it makes sense to integrate AI into the product). Whether it's by running additional product discovery sessions or analyzing the activities of competitors, product managers should constantly seek out new ways to add value to the product and attract new customers. Now that we've explained the intricacies of the role let's dig deeper into some of SaaS product management's most crucial concepts and processes. Understanding the Product Lifecycle Stages The product lifecycle can be defined as a series of consecutive stages that the product moves through, from inception to eventual decline. It's an important concept in product management because the manager role typically evolves in tandem with the product's journey through the cycle. The traditional lifecycle view has four stages: Introduction, Growth, Maturity, and Decline. However, we've adapted the cycle length based on our own experience in product building. It goes something like this: New Product Development is when the product goes through the conceptual and testing stages: ideation, development, and validation. The introduction is when the product is launched on the market. Growth is when the product establishes its market position and brings profits. Maturity or Stabilization is when the product stabilizes on the market and has the highest sales volumes. The decline is when the product reaches the extent of its growth and begins to fail. Afterlife is what happens after the product dies. There are a few different scenarios – it can immediately die, inspire a new product idea, or simply become a relic. Here's a visualization of the lifecycle: What to Remember About the Product Lifecycle The lifecycle is simply a guideline and not a guaranteed forecast. There is no predicting when your product will pass through the growth, maturity, and decline stages – for some SaaS companies; it could all happen within a year of product launch; for others, it could take decades. On the other hand, many products die right after their introduction. Therefore, product managers must proceed cautiously when making decisions or forecasts based on the product's position in the cycle. The early stages are the most important—namely, New Product Development and Introduction. Of course, when your product is built on a solid foundation, it's more likely to withstand any challenges that come its way. Spend adequate time testing and iterating on your solution; listen to customer feedback and prioritize new features. Rushing to market with an unvalidated product idea could prevent you from ever reaching the growth stage. There is no such thing as infinite growth. Every product will reach the limits of success at some point and enter a period of decline. However, this is where product managers can work their magic. They are responsible for creating a new value proposition and finding innovative ways to pivot. Countless external factors can affect the product lifecycle. Be it new scientific discoveries, natural disasters, economic instability, or political unrest – there are numerous external factors that can disrupt a smooth lifecycle. Sure, these things are out of a product manager's control. But you still need to be aware of the unwanted impact they can have on your SaaS company in general. Leadership in Product Management In product management, there's more to being a leader than simply defining tasks, delegating them, and overseeing their execution. In our view, it's all about finding the balance between authority, responsibility, and accountability. So, what do we mean by that? Let's start with a brief explanation of each term: Authority is about making decisions, telling people what has to be done, and clearly defining the task that is assigned. Responsibility refers to the obligation to perform assigned tasks. Accountability is accepting responsibility (in relation to job completion) and taking personal answerability for results. An imbalance between these three interrelated components can lead to serious communication problems and team mistrust. For instance, if a product manager has a lot of authority but little accountability, then they probably micromanage and don't have the respect of their teammates. If a PDM has lots of responsibility but rarely exerts authority, then they probably struggle to delegate tasks and prioritize their own workload. To help strike this balance, we take a couple of different approaches: horizontal processes (holacracy) and an adapted RASCI model (RatSClur). In a nutshell, holacracy is a type of flat organization where teams self-organize instead of relying on orders from managers. Authority and decision-making power are distributed amongst the team, and no fixed roles exist. At Railsware, roles are taken rather than assigned. Meanwhile, RatSClur is a framework for defining those roles. It helps us keep track of who's responsible for what across various projects. Here's a breakdown of what the roles mean and where product managers fit in: DESCRIPTION EXAMPLE Responsible (R) The person who takes direct responsibility for the results no matter what blockers they face. Product Manager Lead Engineer Temporary Lead Approver (A) The person who helps the Responsible and the team to make the right choice. Is accountable for the overall outcome. Has limited hands-on involvement. Liaison Account Manager Managing Director CEO Product Manager Team (t) Does the recurrent work, keeps themselves up to date, proactively contributes to the vision, executes humbly, and stays on track. Project Manager Engineer Designer HTML/CSS expert QA Engineer Copywriter External Contractor Supportive (S) Helps the team on request only to do work, to spread results into masses.This is the sub-role of Responsible. Anyone with partial hands-on engagement. For example, QA helps Product Manager with research on automation tools. Early Adopters Consulted (C) Shares knowledge and opinions with the team to tune outcomes into what they believe is right without doing any significant work within the team. Subject Matter Experts (such as Legal Advisers) IF NO ONE ELSE (N) The person that wants to move away from the activity but possesses domain knowledge and will help if no one else is available. An Engineer who jumps in to fix critical issues because others are not available. A Product Manager organizing yearly meetups for colleagues. Informed (I) Is actively or passively informed on changes. Project Manager is informed of the hiring progress. Employees are informed of the legal changes. User (u) Does not participate in the task but will use the end result. Employees who benefit from the company's policies. Office residents who use the office facilities. Occasional User (r)︎ Occasionally uses something. Krakow office residents who occasionally use the Kyiv office. Now, here's how authority, responsibility, and accountability tie in with each role: Has authority? Has responsibility? is accountable? Responsible (R) Yes Yes Can be Approver (A) Yes Yes Yes Team (t) Can have Yes No Supportive (S) Can have Yes No Consulted (C) No Can have No IF NO ONE ELSE (N) Yes Yes Can be Informed (I) Yes No No User #4 ︎(u) Yes No No Occasional User (r)︎ Yes No No Both RAtSCIur and Holacracy create systems that distribute authority and empower team members to make decisions for themselves. Thus, product managers aren't shouldered with all the responsibility for the execution of a project. A key takeaway here is that good leadership is also tied to healthy communication. So when it comes to cooperating with developers, designers, marketers, knowledge holders, and internal stakeholders, we've got a few tips: Set up a clear goal. Meetings without a goal are bound to be unproductive. Before any call, ask yourself: what is your main message? Set aside time for small talk, but quickly get to the point – and stick to it. Have a plan. Always come to meetings prepared. Do your homework, gather the materials you will need in advance, and clearly communicate what you need from your colleague. Remember the audience. Speak the language of your audience. You will need to present the information differently depending on who you are meeting with (marketers, designers, finance experts, etc.) For instance, finance experts might want to know the costs. Doze the information. Don't overload your colleague with tons of unnecessary information. It's totally fine to vent (in moderation). But if you're unhappy with something, provide others with the information they need to help you. Respect others' time. Don't waste your coworkers' time by scheduling unnecessary or overlong meetings. Always check whether a face-to-face meeting is really needed; oftentimes, a Slack message will do. At the end of the day, small choices like these can save everyone a lot of time. Decision-Making in SaaS Product Management As we mentioned, SaaS product managers are the primary (but not exclusive) decision-makers within the cross-functional product team. They make day-to-day decisions through a combination of data analysis, research of potential solutions, and knowledge of the product and industry best practices. Sometimes, there is no 'right' decision. For instance, when it comes to choosing a new feature to implement, there might not be an obvious candidate in your roadmap. As a PDM, you must make an educated guess based on your knowledge of what's best for the product. However, major decisions aren't made in a vacuum. Therefore, our product managers leverage decision-making frameworks, such as BRIDGeS (more on that later), to explore the context and brainstorm solutions with other product experts. Similarly, product strategy decisions are typically made in conjunction with 3-10 c-suite executives and other stakeholders (product directors, marketing leads, senior data analysts, etc.) Again, the frequency of these meetings depends on where we are in the product lifecycle. At the growth stage, once a month. At the maturity stage, once or twice a year. How to Make Data-Driven Decisions and Track Product Performance Throughout the product lifecycle, SaaS product managers will use product analytics dashboards to track revenue metrics, catch fluctuations in user behavior, identify bugs or bottlenecks in user flows, and pinpoint areas for improvement. Some examples of dashboards are product funnel, customer service, or cohort analysis report. Put simply; product dashboards allow SaaS PDMs to track product performance and make data-driven decisions on the fly. To make the most of them, product managers should review the dashboards once or twice a week. Our PDMs typically dedicate about one hour per week to this task. Now, product managers are responsible for choosing the metrics that dashboards are built on. Since B2B SaaS products differ in more ways than one (different business domains, feature sets, audiences, subscription models, etc.), it's important for PDMs to create custom dashboards that are tailored to the product. This will ensure that decisions are made using only the most pertinent data. We often use the AARRR framework as a guideline when creating the initial product dashboard for a new product. The acronym stands for Acquisition/Awareness, Activation, Retention, Referral, and Revenue. When paired with relevant metrics, this framework helps our product managers understand how well the product is performing on the market. Among other things, it allows them to pinpoint and investigate holes in the conversion funnel, e.g., why are so few users activating their accounts? How can we change that? In addition to AARRR metrics, here are some of the most common metrics that feature on SaaS product management dashboards. North Star: The metric that is most indicative of product success. It might be any of the below, but it is usually a financial or user engagement metric. Monthly Recurring Revenue (MRR): The predictable total revenue generated by all active subscriptions in a particular month. Annual Recurring Revenue (ARR): The predictable total revenue generated by all active subscriptions over the course of a year. Customer Acquisition Cost (CAC): How much it costs to acquire a new customer. Customer Lifetime Value (LTV): Total revenue generated by a single customer throughout the time that they used your product. NPS (Net Promoter Score): Measures user satisfaction; how much users are willing to promote your product to others. Churn. Defines users who abandoned the product or canceled their subscription. Active Users Per Day (DAU) or Month (MAU). Tells you whether or not users are actively engaging with your product at a sustainable rate. Bear in mind' active user' is defined differently for each product. Stickiness of DAU/MAU Ratio. When daily active users are divided by monthly active users, you can find out whether or not your user base is growing and what this means for your product in the long term. What Is the Balance Between Data-Driven and Vision-Based Product Development? There's no denying that data has an essential part to play in product development. After all, it's practically impossible to track SaaS product performance and achieve a product-market fit without it. But in the race to become data-driven, product managers shouldn't forget about the importance of vision. In fact, they should know that the two are inextricably tied. A product vision is shaped by data, and without a vision, data is useless. The folks at ProductPlan have identified five common pitfalls of data-driven SaaS product management, which we would agree with. The risks are: Exclusive focus on the 'north star' metric, which leads to missed information. Too much focus on data leads to analysis paralysis. Cognitive bias can lead to missed insights or incorrect conclusions. Not collecting enough data can lead to decisions that come too late. Misinterpreted data can lead to misguided conclusions. One of the ways our product managers avoid these pitfalls is by cross-checking the vision with data and vice versa. For example, when we first launched our product, Smart Checklist for Jira, we had big ambitions for its future growth, e.g., adding templates, a progress bar, custom statuses, and much more. Our vision was to become the top checklist add-on in the Atlassian marketplace. But to get there, we knew we had to start small and take a data-driven approach to product evolution. To this day, every new feature or functionality we implement is backed by data, i.e., what we glean from customer support requests, cust dev, user engagement stats, and competitor analyses. But those features/functionalities are also supported and shaped by the product vision. Key Approaches and Frameworks for Saas Product Management The following concepts and frameworks count as some of our organization's key approaches to product development and operations management. Building a Product Roadmap As we discussed earlier, strategic planning is one of a product manager's main responsibilities. Roadmapping goes hand-in-hand with both short- and long-term planning. Product roadmaps help PDMs set achievable goals, conserve limited resources, and share information with the development team and other stakeholders. More than just a list of tasks, the roadmap is a high-level plan that displays the workflow and milestones of a strategy-based pipeline. Some roadmaps are feature-oriented, some are time-boxed, and others are based on quarterly objectives. Here's just one example of a roadmap that is goal-oriented: Prioritize the Feature List and Product Backlog One of the biggest challenges when building a roadmap is deciding what features make the cut. But virtually every highly-successful SaaS business – Github, Slack, Trello – got where they are today by prioritizing new features. Instead of wasting time and money on developing non-essential things, they filled their roadmaps with features that would add genuine value to the product. MoSCoW is one of the most commonly used frameworks for SaaS feature prioritization. So let's break down how it can be applied to the product backlog when building a roadmap. Firstly, MoSCoW is an acronym for Must-have, Should-have, Could-have, and Won't-have. Each of these terms denotes a level of priority from highest to lowest. Must-haves are top-priority requirements. These are features that are essential to product functionality. If we take Uber as an example here, then their 'route mapping' feature counts as a must-have. Should-haves are requirements of secondary priority. These features are considered important but not crucial, e.g., being able to pay via a corporate account in Uber. Could-haves are tweaks that can wait until later in the development timeline for implementation, e.g., a tip jar function in Uber's passenger app. Won't-haves (this time) are features that you still want but can't actually afford under your current budget or deadline. An example might be Uber's ride-scheduling feature, which wouldn't have been essential when the app first launched. Minimum Viable Product In case you haven't heard of this agile product development concept, the minimum viable product (MVP) is a version of your product that contains the fewest features necessary for release to market. A core component of the Lean Startup Model, the MVP allows startups to create a functional product at minimal cost so that they can quickly gather customer feedback and make valuable iterations. We can personally attest to its efficacy because every one of our full-featured products – Mailtrap, Coupler, and Smart above Checklist – began as an MVP. BRIDGeS Framework BRIDGeS is a decision-making and idea-generation framework designed by Railsware. It allows professionals to analyze a problem from various angles, develop targeted solutions, and make a conclusive decision. Sessions can be run either in person (using sticky notes and colored markers) or online with virtual whiteboards (you can try the free Figma template). It takes about 2-8 people to run a productive session. Depending on the issue at hand, attendees may include a product manager and other stakeholders such as software engineers, product designers, marketers, etc. BRIDGeS is an acronym for Benefits, Risks, Issues, Domain Knowledge, Goals, and Solutions. Benefits are what you will gain from a future solution, Issues are your existing problems, Risks are potential issues you might face, Domain Knowledge is information that helps provide context, and Goals are what you hope to get from the future solution. Each type can be added to the board using a different colored card. Here's an example of what the Problem Space looks like after a problem has been broken down using these descriptors. We've used the Uber example again here. In this example, each task has already been prioritized using the MoSCoW method we discussed earlier. So, it is time to move into the Solution Space. This is where we ideate solution variations based on the identified benefits, risks, and issues. We then describe the chosen solution through epics and nested tasks, which can actually be transformed into a product roadmap. Lean Canvas Designed by Ash Maurya, Lean Canvas is a tool for checking the viability of your product idea. It's considered an alternative to the traditional business plan and an adaptation of the Business Model Canvas (the brainchild of Alexander Osterwalder). The purpose of Lean Canvas is to help product managers and startup founders analyze the strengths and weaknesses of their business model and mitigate the risks associated with launching a new product into a competitive and fast-changing market. However, for existing and well-established businesses, the Business Model Canvas is generally the preferred choice. In practical terms, Lean Canvas is a single-page document that consists of nine boxes to be filled in. Their headings are Customer Segments, Problems, Revenue Streams, Solutions, Unique Value Propositions, Channels, Key Metrics, Cost Structure, and Unfair Advantage. Each section allows you to focus on a different aspect of your product offering and structure, to ensure all bases are covered, and the spotlight remains on customer needs. Value Proposition Canvas Created by Strategyzer, Value Proposition Canvas is a tool to help product managers and startup founders get closer to a product-market fit. It can help you understand your customers' needs and pains, find new ways to drive user engagement, and refine your brand messaging and marketing strategy. The canvas is divided into two parts; traditionally, a square on the left (Value Proposition segment) and a circle on the right (Customer segment). Here's a visualization: When filling out the canvas, you begin in the customer segment by listing the customer's jobs, pains, and gains. This part helps you define the tasks customers are expected to execute and any negative or positive experiences they might have while doing them. Then you move on to the left side, where you will deal with the product. Here you will break down products and services, pain relievers, and gain creators related to your product offering. Essentially, these are the benefits (or unique value) that your solution offers to customers. After completing the canvas, you should have a strong idea of how to differentiate your product from others on the market and communicate that unique value to your target audience. Software that Helps Manage SaaS Products Here are some applications and tools that our product managers use to plan new projects, manage their daily workloads, collaborate with teammates, and connect with customers: Figma: For collaborating with designers, wireframing, creating interactive prototypes, and sketching ideas/brainstorming. Slack: For seamless communication with teammates and stakeholders. Google Sheets: For product planning activities and organizing market research/customer data. Looker Studio: For creating free product dashboards and visualizing different aspects of product performance (customer success, ad campaigns, sales leads). Coupler.io: For automating data flows between apps such as Airtable or Pipedrive and destinations like GSheets, Big Query, and Microsoft Excel. Notion or Coda: For knowledge storing, project management, and note taking during collaborations. Typeform: For creating engaging customer surveys. Google Meets and Calendly: For client calls, conducting customer interviews, and meetings with C-suite executives. Now let's dive into something a little different. This next part is for startup founders who are ready to hire a product manager for their team. How to Hire a Good Product Manager Here we'll share our process for hiring product managers who are hands-on, t-shaped, and lead by example. So, in addition to all of the key skills we discussed earlier, there are several others we look for during the candidate screening and selection process. Strong communication skills are a must, of course, since product managers will be working closely with people from all corners of the product and company, as are strong organizational skills since the role involves juggling meetings, research, leadership duties, and so on. Meanwhile, being attentive to details, curious about how the product works, and having a good memory are also highly desirable traits, though not always dealbreakers. Here are a couple of other things we take into consideration: Technical Background In our experience, product managers with technical backgrounds (think computer science or data analysis) are better equipped for the role than those with experience strictly in product design, sales, or marketing. Knowing how to code, how to break down/organize data, and how to spot bottlenecks in development pipelines are highly-coveted skills. Real-World Experience We aren't really interested in management degrees. Instead, we strive to hire PDMs who have experience managing real-world products, preferably in the SaaS space. In addition, they must be able to critically discuss their past experiences and demonstrate a history of problem-solving, decision-making, and true leadership. Resources for Product Managers There are no shortcuts to launching a career in product management or becoming an expert in the field. Unfortunately, no single resource — book, course, podcast — can teach you everything you need to know about the discipline. However, based on recommendations from our product managers, here are some useful materials to help you grasp the essentials. The Lean Startup Already a modern classic, The Lean Startup by Eric Ries is a must-read for product managers working in the SaaS space. It covers the MVP concept in depth and explains how to leverage the ever-popular Lean Startup framework. INSPIRED: How to Create Tech Products Customers Love INSPIRED goes much deeper into some of the topics we've covered here, including the skills product managers need and what processes they should follow. It's suitable for PDMs working at all stages of the product lifecycle, from introduction to maturity and beyond. The Mom Test: How to talk to Customers and Learn if Your Business Is a Good Idea When Everyone Is Lying to You Despite its odd name, The Mom Test is considered one of the top manuals on how to effectively validate your business idea. It explains how to go about the customer development process the right way and extract meaningful insights from your target audience. A note on Mentorship: "If you’re a software engineer, data analyst, or QA and you’re interested in becoming a product manager, the best advice I can give is to find a mentor. Contact a PDM within your current company who is an expert at their craft, set up a meeting, and see if they can help you evaluate the best path forward. This is a great way to find out if the role is really for you." - Yevgen Tsvetukhin (Product Manager) Wrapping Up On a closing note, we asked a couple of our product managers what their favorite and least favorite parts of the job are. Here's what they had to say: "Experimenting is the most exciting part of SaaS product development. By making small changes to the product and properly measuring the results, you can test lots of hypotheses in a real-life environment. On the other hand, the hardest part is having to make unbiased decisions. You don’t always have tons of data to support your position, and you are dealing with stakeholders who, as all humans, have their personal preferences." - Julia Romanenkova (Product Lead) "For me, the most rewarding part of product management is getting to see how your product benefits customers. However, the hardest part is all of the work that comes after the product launch, and before its success. It takes more than an MVP to start seeing that impact." - Julia Ryzhkova (Product Lead) Product managers are strategists. They create data-driven action plans and bring structure to a founder's vision and unity to the contributions of cross-functional teams. In our view, every SaaS company needs designated experts who can answer tough questions and steer a new product along the path to success.

By Beatriz Campos

The Importance of Maintaining a Project Management Database

Keeping on top of your project management tasks can be a daunting task, but with the right database and system in place, it’s easier than you think! In this blog article, we’ll take a look at why it’s so important to maintain an effective project management database and how to get started. What Is a Project Management Database? A project management database is a crucial tool for any organization looking to stay organized and on track with their projects. It is an essential part of any project management system and is used to store and access important information related to the project. This information can include task lists, milestones, deadlines, resources, budgets, and more. A project management database ensures that all data related to a project is kept up-to-date and easily accessible. Having this data in one central location makes it easier for everyone involved in the project to access and use the information they need. With a project management database, teams can easily keep track of progress, assign tasks, manage resources, and set deadlines. It also allows teams to monitor budgets and view reports in real time. This helps ensure that projects are completed on time and within budget. Furthermore, with a project management database, organizations can gain insights into how their projects are performing over time so they can make necessary adjustments as needed. In conclusion, a project management database is an invaluable tool for any organization looking to streamline its operations and remain organized. It provides teams with the necessary tools they need to manage projects effectively while also providing them with powerful insights into how their projects are performing over time. Why Is It Important to Maintain a Project Management Database? Maintaining a project management database is essential for the successful completion of any project. It provides an organized system for tracking and managing key components of the project, including tasks, deadlines, resources, costs, risks, and more. By having a single source of data that can be easily accessed and updated by all team members, organizations are able to optimize their workflow and ensure that projects are completed on time and within budget. A project management database also allows for better communication between teams. Instead of relying on emails or other unreliable methods of communication, teams can access up-to-date information through the centralized database. This allows team members to quickly identify any changes or adjustments that need to be made in order to stay on track. Furthermore, a project management database provides valuable insights into the progress of a project. With detailed reports and analytics available at your fingertips, it’s easy to track milestones, pinpoint areas where improvement is needed, and identify potential issues before they become bigger problems down the road. In short, maintaining a project management database is an essential part of staying organized and ensuring that projects are completed on time and within budget. What Is a Work Breakdown Structure in Project Management? A work breakdown structure (WBS) is an essential element of project management. It is used to break down a project into smaller, more manageable tasks. By breaking down a project into a hierarchical structure of discrete activities, the WBS provides an organized view of the project and its components. This allows for better planning and control throughout the lifetime of the project. At its core, the WBS is a visual representation of the tasks and subtasks involved in completing a project. It consists of activities broken down by level, with each level providing more detail about the task at hand. The highest-level activities are usually referred to as “phases,” while lower-level activities are called “tasks” or “subtasks.” The WBS helps to identify any gaps between the tasks required to complete a project and makes it easier to assign resources accordingly. A well-crafted WBS can be used as part of an effective project management database that helps track progress, costs, resources, risks, and more. A good WBS will also help you estimate costs more accurately by breaking tasks down into their individual elements. This allows for better budgeting and cost control during each phase of the project lifecycle. Benefits of Maintaining a Project Management Database A. Improved Organization The organization is the key to success in any project, and maintaining a project management database can help ensure that all aspects of a project stay organized. By centralizing information in one place, it’s easier to keep track of tasks, deadlines, resources, and other important details. This helps teams work together efficiently and ensures that nothing falls through the cracks. With an up-to-date project management database, teams have access to all the necessary information they need to stay on top of their projects and meet goals in a timely manner. Furthermore, this information can be shared with stakeholders outside the team so they can monitor progress without having to ask for updates. A project management database is an invaluable tool for staying organized and on track with projects! B. Increased Visibility and Accountability Having a project management database is essential for any organization that wants to ensure the success of its projects. A project management database allows teams to track progress and hold everyone accountable for their tasks. By having a database in place, teams can easily access data and view performance metrics at a glance. This increased visibility helps organizations stay on top of their projects and make informed decisions quickly. Not only does a project management database provide increased visibility, but it also creates a culture of accountability within an organization. With the data available, team members can easily see what tasks are assigned to them and measure their performance against set goals. This helps create an environment where each team member takes ownership of their role, ensuring that projects are completed on time and within budget. To summarize, maintaining a project management database is essential for any organization striving for success. It provides increased visibility into performance metrics so teams can make informed decisions quickly, as well as creates an environment of accountability where team members take ownership of their role in completing projects. C. Improved Collaboration Having a project management database in place is essential to ensure successful collaboration between teams. A project management database allows all team members to access up-to-date information related to the project, streamlining communication and facilitating better decision-making. This is especially important for large projects that involve multiple teams and stakeholders. The improved collaboration enabled by a project management database also helps to reduce confusion among team members, which can significantly improve the efficiency of the project. By having a single source of truth about the project, each team member can quickly access the relevant details needed to complete their assigned tasks. This eliminates the need for redundant updates or conversations, allowing team members to focus on the tasks at hand. Finally, a project management database also makes it easier for multiple teams to work together effectively by providing an easy way to exchange information and track progress against milestones. This allows stakeholders from different departments or organizations to easily view progress on shared goals, ensuring everyone is on the same page with regard to deadlines and expectations. Types of Project Management Databases A. Spreadsheets Spreadsheets are one of the most popular ways to maintain a project management database. This is because they are easy to set up, contain all the necessary information, and can be quickly modified. Spreadsheets allow you to easily organize data into categories, track progress, and provide an overview of a project’s status. They also offer a range of features such as drag-and-drop sorting, conditional formatting, and pivot tables. Using spreadsheets as your project management database provides many advantages. First, they give you an organized view of your project’s data and enable better decision-making. By categorizing data into distinct columns you can quickly identify key trends or issues in the project and adjust your strategy accordingly. Additionally, the ability to apply various formulas or functions makes it easier to draw insights from complex data sets. Finally, spreadsheets are highly customizable and can be tailored to meet specific requirements or scale with growing needs. This means that regardless of whether your project is small or large, you can always find a way to make it work within spreadsheet parameters. B. Online Project Management Software Project management databases are essential for any organization looking to keep its projects organized and running smoothly. Online project planning software is a great way to manage projects of all sizes, whether it’s a small task or a large-scale project. This type of software helps manage tasks, resources, timelines, budgets, and more. It also allows teams to collaborate with each other in real time from any location. Online project management software provides an intuitive interface that makes it easy for users to create and assign tasks, as well as track progress. This type of software also offers features like task notifications, priority settings, file-sharing capabilities, milestone tracking, timeline views, and more. Additionally, many online project management tools provide analytical features to help teams track their success over time and make informed decisions about future projects. Using online project management software can help streamline the workflow process by enabling efficient collaboration between team members. This allows teams to stay on top of progress and deadlines without having to manually enter information or sift through emails looking for updates from each team member. C. Customized Solutions When it comes to project management, having a reliable database is essential. A customized project management database can make all the difference in the success of your projects. Not only do they provide you with a way to store and access data quickly and easily, but they also allow you to tailor the system to meet your specific needs. Customized solutions offer a variety of advantages over traditional solutions. For starters, they allow you to customize the system in order to suit your exact requirements. This means that you can add or remove features as needed, allowing you to tailor the system so that it best serves your project’s needs. Furthermore, customized solutions often come with additional features that may not be available in traditional solutions, such as workflow automation, advanced reporting capabilities, or integrated analytics tools. Another benefit of using customized solutions for project management databases is the improved security. With these systems in place, you can ensure that sensitive data is kept secure from unauthorized access and tampering. Additionally, customized systems typically offer more robust backup and recovery options than traditional solutions, giving you peace of mind should anything go wrong with your database. How to Create a Project Management Database A. Gather Requirements Having a project management database is an essential tool for any successful project. It allows you to track and monitor the progress of the project, ensure that tasks are completed on time, and keep all project-related information organized. However, in order to create a successful project management database, it is important to begin by gathering requirements. The first step in gathering requirements for a project management database is to identify the purpose of the database. What will it be used for? Who will be using it? Knowing these answers will help you determine what features and capabilities your database needs in order to meet those needs. Once you know the purpose of your database, the next step is to determine what data needs to be stored in the system. This includes not only the type of data that needs to be stored but also its format and structure. For example, if you need to store customer information, then you should determine what fields are needed such as customer name, address, contact information, etc., as well as how this data should be structured within the system. B. Choose the Right Software or Platform When it comes to choosing the right software or platform for your project management database, it’s important to consider your specific needs and the goals of your project. Depending on the scope of the project, you may need to choose a more comprehensive solution than what is available from basic software programs. There are a variety of solutions available for creating and managing a project management database. Some popular options include Microsoft Excel, Access, and SharePoint. Each has its own merits and drawbacks that should be considered when making a selection. Microsoft Excel is one of the most popular platforms for creating a project management database due to its flexibility and ease of use. It can be used to create simple spreadsheets or more complex models depending on the user’s needs. However, it does not have many built-in features specifically designed for managing projects and can be difficult to use with large datasets. C. Document Your Processes Organizing and tracking projects can become a daunting task for any organization. To ensure consistency and accuracy, it is important to document processes and store them in a project management database. A project management database provides a centralized repository for all project data, enabling teams to quickly access the information they need. Having an organized and up-to-date project management database is essential for successful project delivery. It allows teams to easily access relevant documents, track progress, identify roadblocks, and make informed decisions. A well-maintained database also helps streamline communication and collaboration between team members. Creating a project management database involves several steps. First, define the scope of the project by considering who will be using the system and what data needs to be collected throughout the process. Once the scope of the project is determined, create a list of objects that should be stored in the system (e.g., contacts, tasks, milestones). Then, decide on how data should be structured within each object (e.g., fields, tables). Finally, establish rules for data entry (e.g., naming conventions) and make sure that everyone on the team is familiar with them. D. Train Your Team Proper training is essential for any successful project management database. Without the right knowledge and skill set, it can be difficult to effectively maintain and use a project management database. To ensure your team is well-equipped to manage and use the database, it’s important to provide them with training on its features and functionality. The first step in training your team is to provide an overview of the project management system. Make sure they understand the purpose of the system, how it works, and how they can use it to their advantage. You should also explain any specific tools or features that are available such as reporting functions or workflow automation. Once your team has a basic understanding of the system, you can move on to more advanced topics like data entry protocols, query-building techniques, and report design principles. It’s also important to cover any security measures that are in place so that your team knows how to protect sensitive information from unauthorized access. Conclusion In conclusion, maintaining a project management database is essential for any organization that wants to successfully manage its projects. It provides an efficient way to store and access project data and allows teams to collaborate more effectively. Additionally, it allows organizations to track progress, identify issues, and ensure projects remain on schedule. A strong project management database helps ensure that all goals are met in a timely manner while also providing the necessary information needed for accurate reporting.

By Fred Wilson

The Importance of Delegation in Management Teams

Delegating power is a crucial aspect of managing teams effectively. It enables managers to assign tasks and responsibilities to team members, allowing them to focus on their areas of expertise while empowering them to take ownership of their work. This method can lead to increased productivity, improved morale, and more efficient use of resources. However, failing to delegate power can lead to micromanagement, burnout, and a lack of trust among team members. This is something I have experienced firsthand in my previous jobs, where managers were hesitant to delegate tasks and responsibilities, negatively impacting the overall management and performance of the team. Focus on Management Expertise One of the primary benefits of delegating power is that managers focus on their areas of expertise. Managers can free up time and energy to focus on more important and pressing matters by assigning tasks and responsibilities to team members. This can lead to increased productivity, as managers can devote their full attention to the tasks that require their expertise. Empower Teams To Own Their Works In addition to increasing productivity, delegating power empowers team members to take ownership of their work. When team members are given the autonomy to handle their tasks and responsibilities, they are more likely to take pride in their work and feel a sense of accomplishment. This can lead to improved morale, as team members are more invested in their work and motivated to perform at their best. Efficient Resource Management Another important aspect of delegating power is that it can lead to more efficient use of resources. Managers can ensure that the team is working at its total capacity by assigning tasks and responsibilities to team members who are best suited to handle them. This approach leads to increased productivity and improved outcomes, as team members can focus on the tasks they are best suited to handle. Avoid Micromanagement However, delegating power can be challenging for some managers. Many managers may feel they are the only ones who can handle specific tasks or need to control everything to ensure that the team is working effectively. However, this mindset can lead to micromanagement, negatively impacting creativity and innovation. Another consequence would be a lack of trust and respect between the manager and team members. The Art of Sharing Power To effectively delegate power, managers must understand that delegation is not about giving up control but sharing it. Managers should be clear about their expectations and provide team members with the necessary resources and support to be successful. They should also be willing to trust team members and give them the autonomy to make decisions and handle their tasks. In conclusion, delegating power is an essential aspect of managing teams effectively. It allows managers to focus on their areas of expertise, empowers team members to take ownership of their work, and leads to more efficient use of resources. By understanding that delegation is about sharing control and being willing to trust team members, managers can effectively delegate power and lead their teams to success.

By Alireza Chegini CORE

Uplevel Your Managers With Mini-M Support Groups

Today, I would like to share a management practice we developed at New Relic. It was one of the best things we did as an engineering organization. The practice is called “Mini-Ms." I believe it’s as important a practice for managers as code reviews are for engineers. This post is the first of a series: In this post, we look at how Mini-Ms work and what they are. Next, we learn how to implement Mini-Ms. Then, we discuss variations you may want to consider. Finally, we share a history of Mini-Ms, including where the name came from. What Is a Mini-M? A Mini-M is a group of managers that meet weekly or biweekly. The meeting is a combination support group and a working session. In each session, managers share the challenges they face. The other participants offer support and help problem-solve. Why Are Mini-Ms Effective? What is the value of meeting with other managers and talking about your problems? It may not seem like it is worth the time. Yet, many managers claimed Mini-Ms helped them grow more than anything else. Mini-Ms Help You Develop Skills There are a few reasons for that. Elaine May describes three reasons: “Learning to manage is very different from other types of learning (like engineering, for instance). In management, the concepts are simple and the execution is not. I’ve seen this trip up many engineering managers who read a book or attend a class and find the concepts trivial and therefore easy or not very important. Learning management is more of an apprenticeship versus an intellectual pursuit.” “In a Mini-M, you have many other people to learn from. If you are only learning from a coach, manager, or mentor, their approach may not fit very well for you, but in a Mini-M, you are getting multiple perspectives.” Teaching clarifies your thinking. When you share your experiences and ideas with other managers, you’re forced to articulate your own practice and consider it in a critical way. I have a few more explanations: Skills are unevenly distributed. You might be good at running meetings. I might be good at 1-1s. Another participant might be an effective project manager. During a Mini-M, we all share our experiences with each other. Imagine having to fill in those skills some other way. You would have to study each of those topics or learn each of them the hard way. That would be much slower! The diversity of the group allows the group to grow faster. Mini-Ms meet you where your skills are. Most alternative methods of learning involve assumptions of where your current skills are. For example, a management course tries to teach you a certain set of concepts or practices. But Mini-Ms allow you to expand your skills from wherever they may be. If I am struggling with how to run a particular meeting, I can immediately add a little to my skills during a single Mini-M session. This makes the M-team into a combination of a support group and training session for your management team. Mini-Ms Are a Source of Valuable Support Management is a difficult profession. As hierarchical creatures, being “higher” in the hierarchy separates you from your team members. And other managers are often busy and unavailable. Because Mini-Ms were largely modeled on support groups, your group can become part of your support network. Even outside of the meetings, you might turn to your fellow managers for help. Having a Mini-M helped me to build up a mental map of the skills of the managers around me. This was helpful because I started to understand the skills that I needed to build. When I ran into problems running projects, I felt like I could go to the person I knew was good at it and ask for help. And because we had a relationship from our Mini-M, they were more likely to want to help. In addition, many companies are distributed nowadays. This can result in less accidental interaction with peers, and it can contribute to isolation. Mini-Ms can be a source of connection with other managers. Mini-Ms Help Retain and Attract Managers Because managers feel better supported by their peers, they are more likely to stay at the company or stay in management. I anticipated that benefit. What surprised me was that people outside the company seemed to keep hearing about these Mini-M groups. And they would bring it up during interviews and mention it was why they applied in the first place! Why were they so attracted by Mini-Ms? They demonstrated that we took management seriously as a role. They showed that we valued developing our people, which was a signal that their job as a manager would be better here. They showed we experimented with our organizational practices and would welcome further innovation. Mini-Ms Help Build a Management Culture Along with a support group, the other inspiration for Mini-Ms was a conspiracy. The idea was to bring a few managers together, gripe about the problems in the organization, and come up with solutions. Mini-Ms naturally became the graph along which many management practices spread through the organization. In the Five Dysfunctions of a Team, Lencioni talks about the importance of managers seeing their “first team” as the management team. Mini-Ms helped develop a community of managers who all were focused on improving their skills and their teams. Many of us felt empowered to address the problems we saw in the organization around us. How Does a Mini-M Work? There have been a lot of variations to the way Mini-Ms have run over the years. What follows is a good way to start Mini-Ms. The Organizer of the Mini-Ms assigns each manager to a Mini-M. Each Mini-M has five to eight managers. The Organizer sets the expectation that managers attend. Each group has a Facilitator. They schedule and facilitate meetings. They usually start with a standard meeting format. Here’s an example format: Each person brings a topic: something that was challenging from last week, or something they are facing now. In an in-person meeting, the Facilitator would go around and ask everyone for their topics and put them on a whiteboard. In a distributed setting, all the participants would add their topics at the same time to a shared doc. Everyone gets three votes. They put them on the topics they would like to discuss. The group goes through the topics and discusses them in turn, ordered by the topics that have the most votes. The Facilitator checks in every five minutes to see if the group is finished with the current topic, or wants to continue the discussion. This is based on the Lean Coffee meeting format. The Facilitator sets the expectation that meetings are safe places. Participants discuss sensitive topics and there is an expectation of confidentiality. For example, a manager might talk about the challenges they were having with their manager. When To Use Mini-Ms You should design your Mini-Ms based on the particulars of your company. The size and company culture are particularly important. One precondition to this being successful is that the environment is a supportive one. If the leaders value learning and growth, they are more likely to support Mini-Ms properly. A competitive culture may not be a good fit. I recommend Mini-Ms to companies with product-market fit. Early in the growth of a company, product-market fit is the most important factor in a company’s success. After you’ve found a good fit with the market, organizational effectiveness moves up in importance to become one of the most critical factors for your success. At that point, M-Teams begin to contribute more directly to the success of the company. While you can lay the groundwork for M-Teams earlier, I wouldn’t recommend them in most early-stage companies. You can use Mini-Ms globally, across an organization, or within a smaller group. You can even implement a Mini-M informally, with a smaller group of managers. If you start informally, be sure to read the History section to see how they evolved at New Relic. How Do I Implement Mini-Ms? We get to that in our next post. Thank You Not a lot has been written about Mini-Ms, but there is one post currently on the New Relic blog, and another that has mysteriously vanished. Darin Swanson authored some content that was inspirational for large parts of this article. He and I have worked together on helping other companies implement Mini-Ms, so contact me if you’re interested in help. He also provided feedback and suggestions on drafts of this article. He encouraged me to explain the first team concept more fully, and to describe why pre-product market fit companies may not be a good match. And he suggested I split the content into separate articles. Nic Benders was one of the co-founders of Mini-Ms. He reviewed this post, offered feedback, contributed to the history section, and described some of the design goals for Mini-Ms. Elaine May provided feedback, some of which was so good I just ended up quoting her. She was gracious enough to offer some talk to talk about her experiences setting up or participating in similar programs at other companies, and she talked about her experiences with me in New Relic’s Mini-Ms. Elaine introduced me to the Chatham House Rules, which I incorporated into the post. Bjorn Freeman-Benson was the grandfather of the Mini-M. He shared a lot of his thinking about the principles behind why Mini-Ms were successful and what they were aiming for. He advised me to break up this post into sections and make it easier to get to the implementation section. And shared overall feedback. Merlyn Albery-Speyer helped me improve the section on “when to use Mini-Ms” by pointing out some preconditions for success. He pointed out that the structure became less important after the Mini-M is established. Merlyn pointed out that we tried to keep people from being in the same Mini-M as their managers, or other people reporting to the same manager. He also shared the theory about VPs not being willing to be vulnerable as a possible explanation for why the Mini-Ms never took off in manager-of-manager groups to the same extent they did for frontline managers. Jason Poole shared his experience as an Organizer of Mini-Ms. He pointed out a now mostly disappeared second post on Mini-Ms. He also suggested ways Facilitators could counter unproductive ranting. Marty Matheny shared feedback based on his experience as an Organizer. He helped improve the advice for Organizers. And he pointed out that engineering adjacent departments participated. Chris Hansen pointed out that confidentiality was an issue with whiteboards. He noticed an error that would have been embarrassing. He pointed out the value of M-teams in distributed organizations to counter isolation among managers. He also added some advice for participants. Chris also helped with a point about the value of the first few meetings. Teresa Martyny reviewed a draft of this post and pointed out some redundant assertions I was making. And she recommended I break this into multiple posts or edit for brevity. Natasha Litt was another early Mini-M leader, and she reviewed a draft of the post and contributed to it.

By Jade Rubick CORE

The Top 3 Challenges Facing Engineering Leaders Today—And How to Overcome Them

It's no secret that a tech startup is only as good as its engineering team. It's tempting to follow that statement by saying an engineering team is only as good as its talent. That's true, to some extent, but it takes expertise and leadership to get the most out of your talent—and, of course, to identify and recruit the right employees in the first place. To use the most obvious analogy, even an all-star soccer team is unlikely to win a championship without a savvy coach at the helm. Similarly, even the most stacked engineering team (pardon the pun) risks falling short without a smart and persistent leader. As the engineering lead at a growing up startup, I've experienced success and navigated numerous challenges. While a leader's role is multifaceted, steering the ship through difficult times is one of the most critical aspects. So let's take a look at the three biggest challenges I've encountered and how they can be overcome. 1. Hiring the Right Mix of Skills To continue the soccer analogy, imagine for a minute that your team comprises some of the country's highest-ranked players. The only catch: they're all defenders with no forwards or midfielders. Good luck winning any games without the right mix of skills. In the context of an engineering team, the same principle applies. Everyone needs the same core skills, but different team members should possess different complementary skills. For example, it's not useful to have a team of people who are all experts in CSS but no one who can tackle the API. Similarly, if everyone is outgoing and eager to develop, but no one is thinking granularly about tech debt or reviews, your team will be hindered by the imbalance. A highly tailored hiring process is the key to ensuring your team is well-rounded. To start, map out what skills your team already possesses, what skills it needs, and what skills you expect it to need in the year or two ahead. Then, tailor the hiring process to that. A coding challenge is one of the best ways to get to know how a prospective employee thinks, particularly since you can adjust the rubric to emphasize the skills your team currently lacks. It's basically akin to a try-out. In addition to looking for engineers that complement existing employees, you should also look for ones with the potential for upward mobility. I love bringing in eager-to-learn junior engineers and offering them the support needed to grow. When senior developers mentor new employees, it improves team cohesiveness as well. 2. Toggling Between Creative Endeavors and the Project Roadmap A key component of leadership is balance—not just balancing your team's skill mix but balancing their focus. You must encourage team members to split their time between adhering to the project roadmap and pursuing innovation. Product innovation is crucial for our team because many of our engineers fit the user profile. They have the best pulse on what's working and what could be improved. In addition to outlining a clear product roadmap, encourage engineers to keep an eye out for potential enhancements—particularly those that would be considered low-hanging fruit. Employees should give about 50% to 60% of their time to building things on the roadmap and the rest to things they want to work on. For the latter, I don't mean irresponsible passion projects. Innovation should still relate to overarching company goals, whether activating users or speeding up the release process. Smaller side projects should always align with the team and the company. As the engineering lead, it's your job to ensure your team reviews company goals, discusses innovation, and follows the roadmap. Ideally, your team should be in conversation with other teams in the company, too, to ensure alignment. 3. Keep Morale High Despite Headwinds and Uncertainty Last, it's important to understand that your team doesn't operate in a bubble. The news cycle is full of concerning headlines about slow economic growth and a looming recession. A good leader will acknowledge this reality and explain to employees what it means for the company at large and the engineering team in particular. For example, perhaps there will be fewer new hires as a result of overall company finances. Explain this to your team and how it affects where the team should focus its efforts. Sometimes, hiring fewer people actually makes for an exciting challenge, as there's far more room for creative solutions and cross-team experimentation. Regardless, it's crucial to explain the macro situation to your team clearly and give them the opportunity to ask any questions. If there's seemingly bad company news at an all-hands, for instance, set up a time to debrief and discuss new information as a team afterward, in addition to addressing concerns during one-on-ones. The tech industry might be facing more headwinds than usual, but it's still an exciting industry with tremendous room for growth. As a leader, it's your job to remind employees of this reality and help them embrace challenges. It's still a fantastic time to be in tech and an exciting time to serve as engineering lead. If you can overcome these three top challenges, your team will be well on the way to success.

By Jennifer Grange

Team Management

DZone's Featured Team Management Resources

Top Team Management Experts

The Latest Team Management Topics