Navigating the PM Framework: Part 3
Impact
This is part 3 of a 3 part series breaking down the PM Career Framework. If you missed part 1 or 2 check them out here.
Vision and Strategy
Deciding and aligning on what we should do AND what we should NOT do
Leadership
It’s all about developing, keeping, and leveraging trust
Impact
Get Shit Done
Once we have established the strategic direction to work towards and we have a healthy and inspired org to work with, the final piece of the impact puzzle is to execute. As a PM we will not be solely responsible for delivering on promises ourselves, but there are ways to make a difference on how effectively a team and collaboration partners deliver on goals and get shit done.
Structure
Minimal Viable Process
Put simply, our team will need to take a coherent action from our strategy, and break it down into manageable chunks of work that build towards achieving the goal of that action. Then they need to take those chunks of work and get them done. The process our team(s) work with needs to satisfy these two conditions:
It solves for our team’s execution needs
It solves for our need, as the accountable PM, for reasonable predictability.
There are lots of options and a wide variety of needs here. A senior team with individuals who are good at structuring their work might mostly self-manage. A newer team may require a stricter process. Regardless, our team(s) should feel ownership of their process, and we should ensure to give them what they need within that process to empower them. Then keep a dialogue open with the team and help them solve for our predictability needs with the process too. Retros can serve this purpose, but there are other ways too.
Are we set up for Success?
The process might indicate that our team(s) risk not being able to deliver on the expectations of them. This can show up in several ways, such as if ambitions seem unrealistic, or delivery suffers from significant unpredictability. There are many ways to set our team up for success which our Engineering Manager partner will generally be responsible for. Where we as the PM can really contribute is articulating the impact these issues have in terms of the ambitions and expectations on the teams. This is needed input to the Engineering Manager and our leadership structure, who will need to weigh various options to help (or choose not to). Here are a couple of examples of where a team is not set up for success:
A team has a high load of customer support which consumes the time of two engineers full time, that will greatly reduce the baseline of execution time that a team has. If the team is thin as a result, it is not set up for success.
The tech a team maintains is in bad shape, and as a result they are vulnerable to stop-the-line incidents a couple times a quarter. This makes delivery predictability challenging, and the team is not set up for success.
There could also be challenges with respect to seniority, coverage of different disciplines of engineering, retention, etc.
When our team(s) are not set up for success, we and our Engineering Manager partner must escalate this and help leadership understand the impact of these challenges so they can make a call on how to address them, or explicitly accept the consequences of not doing so.
Org Rhythm
Lastly, in a large company like Spotify, teams are generally part of a larger initiative to deliver on higher level goals. We don’t need to follow or copy exactly the process that Project Management for that higher level goal has, but we need to arrange our processes so they fit together. As a leader of a team and department, we are responsible for abiding by these higher level processes, and therefore must be able to get the input from the team at the right time to do so.
Team Delivery
Empowered Accountability
As part of scaling ourselves we should strive to not be needed consistently in the teams day-to-day. Instead, we can empower engineers so they understand how a particular chunk of work fits into the big picture and WHY it matters. Then the engineers should be able to make decisions themselves. With trust established, we can expect the engineers to raise issues if things are not going according to plan. And as soon as we know it’s not, we can make a call on how to address that. Of course this does not come for free, and we may need to spend time in the team’s day-to-day to achieve this, but it should be seen as a means to an end. We can also help this by making themself available for 1:1 meetings with the goal of inspiring and empowering engineers in the team.
Goals and Focus
I commonly hear that Engineers feel they are not productive enough if they have not spent the bulk of their time writing code and delivering things. But the team is evaluated on if it delivers on the RIGHT things, the things which have the most impact. Where I personally find I can be most impactful in the day-to-day within a team is by helping them choose a goal to be laser focused on, and consequently protecting them from everything else. I’d much rather my team swarm/pair on achieving an explicit goal than picking up a new ticket from the backlog. This may unintentionally open up a new workstream which may cause delay on the critical path. Too many workstreams implies less focus on the goals on the critical path. The second order consequences are less collaboration, less knowledge sharing, and divergence of understanding and expertise within the team. This is especially challenging in a remote setting, as pair programming or working together on tasks is less natural.
Lastly, in my opinion the four worst words a PM can hear are “That is basically done”. This could mean that it just needs to be deployed, needs documentation, needs user verification, or something else which is necessary to achieve the explicit goal of a task. Set goals explicitly, and help the team recognise that “basically done” is not Done, because probably the impact hasn’t been achieved yet and focus will suffer as a result.
Adoption
The impact a Platform Product brings to the company comes from solving a common problem for the users and teams that depend on it. This means that when we have delivered a product we haven’t achieved impact until teams are using it AND verify that we have indeed solved this common problem (for them). So achieving adoption is the final piece of delivery. We can empower others to do this and delegate, or they can do it themselves. But as the PM, we can leverage stakeholder relationships to find reasonable options for adoption and set the team up in the right conversations, if needed.
Collaborative Impact
Often the problems we are trying to solve are bigger than one reasonably sized team can tackle. Therefore, we need to facilitate collaboration across teams in order to achieve impact.
Empowered Collaboration
When facilitating collaboration across teams to deliver on a greater goal, in my opinion it does NOT work to throw requirements in the form of “asks” at teams and hope for explicit commitment. This sort of collaboration is ripe for misunderstanding and leaving deliveries in the dreaded “basically done” state. It also has limited options to mitigate if the answer is “NO”. I believe this approach is only effective when we ask another team to do something small, like upgrade a library. If we need significant collaboration between teams, we need teams to put their own respective priorities aside and buy into the impact that this greater goal will have. Then the teams learn, work, and iterate together to make it happen. The key is to set a shared goal between the teams, and keep eyes on the prize to achieve it. If the shared goal is not achieved, both teams fail. It doesn’t matter who didn’t finish their part. Help each other, and have collaborative impact.
Do the Right Things
The flip side of this is that sometimes another PM or team will approach us and try to influence us to contribute to some greater objective that they are trying to achieve. If the objective the other team is pitching is more impactful than the goals that we have in mind for our team, then the right thing to do is to set our team up to collaborate on this other objective.
We are not necessarily evaluated on the impact we have within our own problem space. We will be evaluated on the impact we have, period. The more trusted we are, the more likely it is that we are put in the most impactful problem spaces. Contributing to these greater goals builds that trust when it is the most important thing we can contribute to. We just can’t forget to be transparent about the tradeoffs this implies by neglecting or down-prioritising our own problem space.
Predictability
The more collaboration is needed to solve a problem, the more difficult it is to be predictable. A Project Manager will manage this by being explicit about expectations and asking for commitment, but solving engineering problems is always unpredictable, so this is hard. The trick is to break things down and try to be as reliable as possible with short term commitments, and always being transparent as early as possible about possible risk to the timeline. My strategy here is to be “realistic” in the short term (1 quarter) and optimistic in the long term 2-4 quarters. But “being optimistic” in the long term doesn’t mean “wishful thinking”. It means clearly presenting the best case scenario, both in terms of outcome and the team set up required for this to be possible. Then, the second half of that optimism is about being clear about the consequences of NOT setting the teams up for success would have, so that leadership can evaluate the tradeoffs that might be included in that setup.
All aspects I’ve dissected here from the PM career framework are leading towards helping a PM maximise the impact that they have on behalf of their organisation. We need to learn and discover what the right problems or opportunities are that should be solved. We need to inspire and lead an organisation that is well set up to solve them, and then leverage the trust in our organisation to get shit done and have impact. In my opinion, the TL;DR of navigating the PM career framework is to have impact and then recognition will follow. The career development framework is just that, a framework. It is intended to help us develop different skills in our roles in order to to maximise their impact. But those skills are a means to an end. A means to being an impactful PM.
New to PM? Check out this post with some learnings from the early days, or this Podcast episode about building and marketing internal products for impact.