Dev Ticket Hierarchy, Disagree and Commit, Manager Schedule
Dev Ticket Hierarchy, Disagree and Commit, Manager Schedule
Edition #30 - Monday Ideas
Hello 👋,
Welcome to the Monday morning ideas newsletter ☕️.
Every Monday morning, receive 3 ideas on how to work more effectively in product and dev teams.
To receive articles like this, please subscribe to The SEO Sprint 👇.
1) Dev Ticket Hierarchy
Keeping track of the progress of a project in ticketing systems can be a nightmare.
It’s easy to lose track of the progress of a project in a dev backlog. There can be hundreds of individual tickets, and it’s easy to become disorganised. Not to mention that at any moment, someone can delete a ticket, and you can’t hit the undo button.
Successful teams have learned to use the ticket hierarchy feature built into most ticketing systems.
In popular ticketing systems like Jira and Azure DevOps, your tickets have a parent-child relationship.
👨 Epic Tickets - Epics represent a large piece of work.
👦 User Story Tickets - User story tickets are the children of epics.
👶 Subtask tickets - Subtasks are the children of user story tickets.
When product and development teams turn ideas into tickets, they create epics to represent a large piece of work. Then group relevant user stories underneath them. And developers create subtasks underneath these user stories.
This nested structure helps teams keep track of project progress.
How can we use this ticket hierarchy to get SEO projects executed?
I’ve used the native ticket hierarchy structure for years to bring order to my SEO Dev tickets. It helps to keep track of your tickets in the chaos of delivery.
Both product and development teams enjoy the structure. It helps them better understand the scope of the SEO projects and what is left on their to-do lists.
Think of the ticket hierarchy as a series of nested to-do lists for your projects:
☑️ Epic tickets are the to-do list for your project.
✅ User story tickets are the to-do list for the epic.
✔️ Subtasks are the to-do list for the user story.
As the team mark these tickets are complete, you can easily track the progress of your project. And you can see if tickets are blocked or still WIP. Then speak to the ticket owner to understand why it has still not been marked as complete.
For more information on ticket hierarchy, check out the quick Atlassian guide.
2) Disagree and Commit
Disagreements are a healthy part of working in tech teams.
Many companies don’t collaborate with the product, development and design teams because they don’t want to face disagreements. Or push back.
This is a huge mistake!
Disagreements are completely normal in product and development teams.
In fact, if the developer and designer don’t disagree with an initial idea, I actually think they are not paying attention. And try to ask questions to make sure there are any unknowns.
Identifying unknown risks that would kill the project is key.
It’s important you are able to de-risk your idea as soon as possible, either by running an experiment or discussing it with the relevant stakeholders in the business.
So how can you improve how you handle disagreements with other team members?
There is a great leadership principle at Amazon called “Have Backbone; Disagree and Commit”.
As a principle, it is all about how to disagree with your boss if you don’t agree with a decision.
The principle is broken down into five steps:
🤷 Why - When disagreeing with someone, you need to make sure you understand why and clearly explain why you don’t agree.
✏️ Facts - When someone disagrees, they need to provide facts or data to back up their position. If there are no facts or data, then agree to disagree and return to the argument when the person disagreeing has gathered new facts or information.
👂 Discuss - When someone disagrees, the team acknowledge they have heard and understand the concerns. And discuss the disagreement as a team.
🗣️ Decide- When your team agrees on the next steps or solution that is communicated to the team and why that decision has been made.
🆗 Commit - When you voice your disagreement and you have been heard, if the team decide to go in a different direction, you need to accept it and commit to the new direction.
I’ve used the “Disagree and Commit” principle and these 5 steps to help me work through disagreements with developers, designers and content specialists.
Be careful when using this technique. Disagreeing with a brand-new stakeholder in an open meeting can have negative downstream consequences.
But it works really well in smaller groups with developers, designers and content teams.
I always state I’m happy for people to disagree as long as they have examples, facts or information to support their disagreement. And are happy to discuss it.
3) Manager Schedule
Product Managers love meetings.
But why?
Because Product managers are on a manager's schedule.
A famous Paul Graham essay Maker’s Schedule vs. Manger’s Schedule, defines the maker schedule as:
The manager's schedule is for bosses. It's embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you're doing every hour.
To a Product Manager, a meeting is the fuel to drive the engine of change.
A manager's schedule is packed with meetings to collaborate and make decisions which help get things done. A Product Manager needs to sync with different teams to ensure everyone is on the same page about strategy and roadmap.
Why is it important to understand a PM's calendar?
Because it can be a nightmare to book a meeting if you want to push through your SEO recommendations.
How can you make sure you take into account the PM's schedule?
When working with product teams, I recommend doing the following to make sure you can get meetings booked:
Meeting cadence - PMs will have a calendar packed full of scheduled meetings. So make sure you book a scheduled meeting each week, fortnight or month.
Communicate schedule - PMs share their calendars with other team members to make it easier to book a meeting. So ask them to share their calendar with you. So you can book an appropriate meeting time (consider time zones - I once booked a meeting at 23:30).
Plan ahead - PMs always think 1-3 months into the future (part of the job), so you must think and plan ahead. Try to book meetings 1-2 weeks ahead. Don’t try to book last minute.
Be prepared - PMs are very busy and don’t have the time or the patience to wait around for you to “open your 100-page audit”. When you book a meeting, be prepared and ensure you know what you want out of the meeting.
Keep focused - PMs can easily be distracted by the latest updates or news, so when you do have meetings, make sure you keep them focused on your priority recommendations.
If you enjoyed reading this article, then consider the following:
📰 Share — Please share the newsletter with your network or colleagues if you think they might find it helpful!
✉️ Subscribe to The SEO Sprint newsletter — if you haven’t already, please consider subscribing.