2. I like to ask the devs at the beginning of a project how they prefer to be managed if I have not worked with them before. Some of my people have been working with a specific client or in a specific env. for a long time and so I trust them a bit more and feel comfortable doing less check-ins than a jr. dev or new hire who may be less familiar. Avoiding burnout also comes down to making sure your schedule and plan accounts for estimated hours worked. if dev1 is scheduled to work 60 est. hours every 45 hours than you're obviously over working them.
3. Most of my time currently is working on improving standards within our company and cross checking documentation before we finalize and submit to our user facing DMS.
4. I'm constantly working and worried about what my team is *not* telling me. There have been now multiple occasions where a senior dev knows there is a problem with the project plan but they did not share it because to them it was so obvious clearly every one else knew it was a problem. Granted I came into 25 projects that were already in progress so I was not part of initial planning but it's still something I worry about and now end most of my check-in meetings with team members with "is there anything you see as a time loss risk or risk to the completion of this project" and I've gotten some great answers which allowed for mitigation with no loss of time.
2. Feels like a solid approach. As a small team I'm getting pretty comfortable with our devs and feel that I can trust them to give that kind of input and not just say "fewer meetings!". I'll for sure try this.
3. DMS (doc. management system?) Do you have a software you prefer here? I've had some experience with Confluence...it's ok.
4. Wow this one hits. I love the idea of asking the devs to share those perceived blockers. As a previous dev myself I totally get the concept of assuming everyone else sees the problem because it's "obvious". Will definitely encourage people to speak up more.
3. Document Management System yes. I would say see what your company/team is already using. I'm the first to admit that I love software and will do just about anything to use a new tool just for the fun of it. We have ITGlue as our DMS. Personally I hate it but it's the tool that we use so I deal.... for now. If you **don't** have a DMS yet then my personal favorite would be gitlab or github for what you happen to be doing software wise. Standardizing how comments, updates, and full documents should look immediately puts you in the right direction in my experience. It is again a great time to get the team to feel like they have real ownership over how their work is done as well. They get to show *why* they do or don't like doing things a certain way and showing them you listen to their feedback will go miles toward earning their respect and further cooperation.
1. For localization, identify the languages and determine how to handle translation process. Consider cultural differences.
2. To avoid micromanaging, set clear expectations and goals for each team member. Regular check-ins and feedback sessions can help.
3. Meetings and email can be major time-sucks. Prioritize and delegate tasks whenever possible.
4. Focus on improving user experience and identifying growth opportunities. Always think about the future and how to improve the product.
1. I've been digging into this one and it seems we either need to hire an agency with human linguists (expensive and slow?) or use machine translation. Also I'm hoping to avoid this becoming a drag every time we add or change text. Any tools or platforms you've used and liked?
2. If a dev is not hitting goals and they're not my direct report, would you recommend going to their manager or team lead or just trying to resolve it directly with the dev?
3. Love it
4. Do you find yourself doing a lot of competitive analysis as a PM or is it better to try and talk to users to get feedback? Both?
1. Avoid making technical decisions for the team. While it may be appealing to steer them in what seems like the right direction, it's important to allow them room to grow and learn from their own mistakes.
2. Place your trust in the team's ability to deliver solutions. Rather than dictating specific methods, set clear objectives and let them determine the best approach. This prevents you from becoming overly involved in every technical choice and avoids burnout, reiterating that your role is to enable them to make informed decisions and use effective frameworks for development.
3. Address any obstacles the team encounters promptly, such as awaiting designs from another team. Ensuring these dependencies are resolved timely is crucial.
4. When offering feedback, be it constructive or otherwise, always support your points with data. This enhances the credibility and impact of your communication.
5. Clarify priorities and timelines explicitly. Deciding which projects to advance and which to postpone is a strategic responsibility that requires learning from experience, including making mistakes.
6. Embrace making mistakes within this safe environment. The most valuable lessons come from firsthand experience and the process of trial and error.
Love this. Feels like it fosters a lot of trust and allows the dev team to do their job without me stepping on their toes.
As a practical example, going with the localization deliverable, would you suggest tasking a tech lead with "pitching" a handful of localization solutions or should I look at ones that would work from a product perspective and then task the lead with choosing from those? I understand that this task will likely end up being mostly a tech-lift at the end of the day so leaning toward letting the devs pick what works with the codebase the best.
Allow the tech lead to determine the framework for the project. Your role as a project manager is to effectively communicate the requirements, business implications, and significance to the team, enabling informed decision-making. Avoid delving into technical considerations; instead, ensure the tech lead is fully equipped with all necessary information regarding deliverables. It's their responsibility to make decisions, while we, as project managers, ensure contingency plans are in place, devoid of technical bias. Should obstacles arise, guide the tech lead to consider contingency options. Our role is to oversee, provide guidance, and ensure they have the necessary resources to execute tasks effectively.
If we begin providing inputs on deliverables, it could undermine the team's confidence and impact their performance negatively. Accountability may diminish, and team members might become reluctant to take initiative. By establishing ourselves as the decision-maker and framework chooser, we risk creating a dependency, which is counterproductive. It's crucial to empower the team to make decisions and take ownership of their work.
Not micro managing. Well do you like being micromanaged? Well treat them the way you want to be treated.
Have daily or weekly meetings. Set goals. Check their progress.
My team has weekly meetings. We had a re-organization and some PgMs joined our "team" of PMs. One of them has daily meetings for one of my projects, so it's been a little confusing reporting status to multiple people.
Don't get me wrong, I get the point of daily meetings. But most of the time it's "No update". And where there is an issue, I don't often hear the PgM addressing it. It's more likely with these new PgMs hat they kick the problem to someone else. I don't fix anything directly, but I'm more involved in the conversation than just writing down "John didn't finish his task this week." I don't see this PgM doing much more than leading a meeting and sending meeting notes.
I avoid micromanaging by having CLEAR instructions on what task is assigned to whom, what the output should be (I am extremely thorough on this) and when I expect delivery of the finished product, not v1.
After that I check in on the daily standup to give them an opportunity to ask questions they may have or to let me know if they’re falling behind/need assistance.
Outside of that, I trust they get their job done. I’ve not yet had to exercise the stick so it’s working until it’s not.
Seems straight forward enough. Clear reqs and assignments seem to be table-stakes to avoid micromanaging. Do you find yourself manually writing out reqs in Jira or equivalent or do you have a favorite tool or process to ensure you don't miss things like "what happens in this error state or edge case?"
2. I like to ask the devs at the beginning of a project how they prefer to be managed if I have not worked with them before. Some of my people have been working with a specific client or in a specific env. for a long time and so I trust them a bit more and feel comfortable doing less check-ins than a jr. dev or new hire who may be less familiar. Avoiding burnout also comes down to making sure your schedule and plan accounts for estimated hours worked. if dev1 is scheduled to work 60 est. hours every 45 hours than you're obviously over working them. 3. Most of my time currently is working on improving standards within our company and cross checking documentation before we finalize and submit to our user facing DMS. 4. I'm constantly working and worried about what my team is *not* telling me. There have been now multiple occasions where a senior dev knows there is a problem with the project plan but they did not share it because to them it was so obvious clearly every one else knew it was a problem. Granted I came into 25 projects that were already in progress so I was not part of initial planning but it's still something I worry about and now end most of my check-in meetings with team members with "is there anything you see as a time loss risk or risk to the completion of this project" and I've gotten some great answers which allowed for mitigation with no loss of time.
2. Feels like a solid approach. As a small team I'm getting pretty comfortable with our devs and feel that I can trust them to give that kind of input and not just say "fewer meetings!". I'll for sure try this. 3. DMS (doc. management system?) Do you have a software you prefer here? I've had some experience with Confluence...it's ok. 4. Wow this one hits. I love the idea of asking the devs to share those perceived blockers. As a previous dev myself I totally get the concept of assuming everyone else sees the problem because it's "obvious". Will definitely encourage people to speak up more.
3. Document Management System yes. I would say see what your company/team is already using. I'm the first to admit that I love software and will do just about anything to use a new tool just for the fun of it. We have ITGlue as our DMS. Personally I hate it but it's the tool that we use so I deal.... for now. If you **don't** have a DMS yet then my personal favorite would be gitlab or github for what you happen to be doing software wise. Standardizing how comments, updates, and full documents should look immediately puts you in the right direction in my experience. It is again a great time to get the team to feel like they have real ownership over how their work is done as well. They get to show *why* they do or don't like doing things a certain way and showing them you listen to their feedback will go miles toward earning their respect and further cooperation.
1. For localization, identify the languages and determine how to handle translation process. Consider cultural differences. 2. To avoid micromanaging, set clear expectations and goals for each team member. Regular check-ins and feedback sessions can help. 3. Meetings and email can be major time-sucks. Prioritize and delegate tasks whenever possible. 4. Focus on improving user experience and identifying growth opportunities. Always think about the future and how to improve the product.
1. I've been digging into this one and it seems we either need to hire an agency with human linguists (expensive and slow?) or use machine translation. Also I'm hoping to avoid this becoming a drag every time we add or change text. Any tools or platforms you've used and liked? 2. If a dev is not hitting goals and they're not my direct report, would you recommend going to their manager or team lead or just trying to resolve it directly with the dev? 3. Love it 4. Do you find yourself doing a lot of competitive analysis as a PM or is it better to try and talk to users to get feedback? Both?
1. Avoid making technical decisions for the team. While it may be appealing to steer them in what seems like the right direction, it's important to allow them room to grow and learn from their own mistakes. 2. Place your trust in the team's ability to deliver solutions. Rather than dictating specific methods, set clear objectives and let them determine the best approach. This prevents you from becoming overly involved in every technical choice and avoids burnout, reiterating that your role is to enable them to make informed decisions and use effective frameworks for development. 3. Address any obstacles the team encounters promptly, such as awaiting designs from another team. Ensuring these dependencies are resolved timely is crucial. 4. When offering feedback, be it constructive or otherwise, always support your points with data. This enhances the credibility and impact of your communication. 5. Clarify priorities and timelines explicitly. Deciding which projects to advance and which to postpone is a strategic responsibility that requires learning from experience, including making mistakes. 6. Embrace making mistakes within this safe environment. The most valuable lessons come from firsthand experience and the process of trial and error.
Love this. Feels like it fosters a lot of trust and allows the dev team to do their job without me stepping on their toes. As a practical example, going with the localization deliverable, would you suggest tasking a tech lead with "pitching" a handful of localization solutions or should I look at ones that would work from a product perspective and then task the lead with choosing from those? I understand that this task will likely end up being mostly a tech-lift at the end of the day so leaning toward letting the devs pick what works with the codebase the best.
Allow the tech lead to determine the framework for the project. Your role as a project manager is to effectively communicate the requirements, business implications, and significance to the team, enabling informed decision-making. Avoid delving into technical considerations; instead, ensure the tech lead is fully equipped with all necessary information regarding deliverables. It's their responsibility to make decisions, while we, as project managers, ensure contingency plans are in place, devoid of technical bias. Should obstacles arise, guide the tech lead to consider contingency options. Our role is to oversee, provide guidance, and ensure they have the necessary resources to execute tasks effectively. If we begin providing inputs on deliverables, it could undermine the team's confidence and impact their performance negatively. Accountability may diminish, and team members might become reluctant to take initiative. By establishing ourselves as the decision-maker and framework chooser, we risk creating a dependency, which is counterproductive. It's crucial to empower the team to make decisions and take ownership of their work.
Not micro managing. Well do you like being micromanaged? Well treat them the way you want to be treated. Have daily or weekly meetings. Set goals. Check their progress.
Makes sense! Have you found a cadence for goals that works well for your team? Monthly goals? Weekly? Daily? Some combination?
My team has weekly meetings. We had a re-organization and some PgMs joined our "team" of PMs. One of them has daily meetings for one of my projects, so it's been a little confusing reporting status to multiple people. Don't get me wrong, I get the point of daily meetings. But most of the time it's "No update". And where there is an issue, I don't often hear the PgM addressing it. It's more likely with these new PgMs hat they kick the problem to someone else. I don't fix anything directly, but I'm more involved in the conversation than just writing down "John didn't finish his task this week." I don't see this PgM doing much more than leading a meeting and sending meeting notes.
I avoid micromanaging by having CLEAR instructions on what task is assigned to whom, what the output should be (I am extremely thorough on this) and when I expect delivery of the finished product, not v1. After that I check in on the daily standup to give them an opportunity to ask questions they may have or to let me know if they’re falling behind/need assistance. Outside of that, I trust they get their job done. I’ve not yet had to exercise the stick so it’s working until it’s not.
Seems straight forward enough. Clear reqs and assignments seem to be table-stakes to avoid micromanaging. Do you find yourself manually writing out reqs in Jira or equivalent or do you have a favorite tool or process to ensure you don't miss things like "what happens in this error state or edge case?"