It's not a deadline, it's a commitment
Achieving aligned autonomy in projects as a people-centred leader
Imagine a collaborative project scenario with business-focused goals, high trust and team autonomy. The team begins chasing their goals with pace and motivation. However, 2 months in, the team realises they actually need 4-6 months in total to reach their goals. They drop scope, discard half-finished work, and are generally stressed as once-ambitious plans are laid waste by real-world velocity. 3 months in, they share their need for 1 more month to deliver minimal scope.
The Manager starts the next project by imposing a clear, non-negotiable, end date. “A deadline will help them focus. A little pressure is a good thing!” the Manager thinks. The team forms a detailed plan and pursues “the deadline”. At an update meeting, the Manager asks for some additional scope. Wanting to be flexible, the team accepts. At a later meeting, the same thing happens. The team is frustrated at the divergence from the plan, and demotivated as they continue to work overtime to meet “the deadline”.
What was the difference between the teams in these two projects? The first was autonomous, highly motivated but ineffective. The second had low autonomy, was demotivated, but had some degree of effectiveness through management alignment.
“Aligned autonomy” seeks positive effectiveness using a balance between leadership alignment and autonomy. How could a people-centred leader achieve this with project delivery? What was so wrong with the deadline anyway?
Are deadlines good or bad?
It depends.
In the earlier contrived story, and often in real life, a deadline increases focus. The team probably avoided throwaway work in the second project. Perhaps the problem being solved didn’t require a lot of adaptability. Perhaps the project was “better done than perfect.” Finally, the shared journey in the crucible of an urgent deadline forges strong social bonds.
“Remember <mega project>?”… “Yeah, still have the T-shirt!” - anonymous
However, as Richard Boyatzis, a professor studying organisational behaviour and cognitive science at Case Western Reserve University, said:
The research shows us that the more stressful a deadline is, the less open you are to other ways of approaching the problem. - Richard Boyatzis, WSJ article.
So adaptability can be stifled, leading to a "stick to the plan" mentality in the team like we saw in the second team earlier, instead of maximising outcomes for the project.
Further, “deadline” just isn’t a positive concept. Consider the actual definitions of the term:
The latest time or date by which something should be completed.
A line drawn around a prison beyond which prisoners were liable to be shot.
Sure we can just stick to #1, but, if you have a principle such as “Positive Urgency”, as we do in our Qwilr ways of working, it’s clearly conflicting.
From deadline to commitment
Teams and leaders can use dates more positively. With an understanding of scope and quality, a team can reason about a date and commit to delivering the project. Because “it’s not a deadline, it’s a commitment”, the team naturally feels more motivated to achieve an outcome they set forward rather than one imposed on them.
It can initially feel disempowering for leaders to allow teams to nominate dates in this way. It’s important that while it starts here, where it leads to is a broader social contract between the team and leaders.
Commitment needs confidence
A team may be reluctant to provide a date to commit to. In this scenario acknowledge the cone of uncertainty or the inverse which I call “build confidence”.
It is easier for a team to say “2 months with low confidence” reasonably quickly. This starts a productive conversation within teams and between teams and leaders. It also poses the most important next question: What is the most important next step to increase “build confidence”?
Therefore, a team can commit to giving an estimate in a much wider range of scenarios. A rule of thumb like “explore until medium confidence” may help. If a project starts with low build confidence, for example, expect a reset partway through the project. If the project is highly agile, considering focusing early work on increasing confidence to avoid the scenario this blog started with.
Commitment to scope
Teams don’t just commit to “when”, but also to “what” they are building. That can be daunting for a team not used to defining the scope in a lean way. For a team starting out, avoid fancy techniques and simply list the independent "things to be built". Think of groups of work that:
Deliver a single feature/story for the user.
Are self-contained in building and deploying.
Serve dependencies for other work or projects.
Are likely to be included/excluded together.
I like the MoSCoW method, and MUST/SHOULD in particular, as a shared language of commitment between teams and leaders. For example:
MUST Scope:
Is critical to the success of the project. The project will fail without it.
The team is committing to shipping these by the scheduled date, or the project will be off track.
SHOULD Scope:
Adds significant value but is not critical to the success of the project.
The team will implement these if time permits, however, they can be deferred to a later project/release without impacting the current one.
Further, teams that explicitly state what is OUT OF SCOPE (or WONT in MoSCoW), are doing their best to avoid the nastier "assumed" scope sometimes mentioned in late check-ins.
These practices are critical in achieving the "alignment" in aligned autonomy.
Commitment to quality
My preference is for a minimal standard of quality, enough for it to not trigger debate from project to project, though it remains critically important. At Qwilr and in previous teams we have defined a Definition of Done, which is this minimal standard. That story SHOULD be told, but isn’t in scope for this blog :)
Commitment to outcomes
Teams commit to a project until they are done. This requires iteration (e.g. sprints) so the team can reflect, re-calibrate confidence in the project and adapt as needed to maximise outcomes for the project.
As stated earlier, adaptability is the very thing that is hindered by deadlines, so if a team is taking a commitment approach it is critical to also pay attention to adaptability. Early validation, through prototypes, demos or some other approach is a great way to achieve this and doesn’t just increase build confidence, but also the confidence of the overall outcomes of the project that live long after the end date.
Commitment to communicate
Both teams and leaders know how ongoing communication will take place via systems, updates, demos and/or other rituals. They also know which scenarios will lead to:
Passive communication (e.g. a mention in a system update), such as a project at risk.
Active engagement (e.g. a meeting request), such as when a project is off track and a scope trade-off is being made, or a significant blocker is hit.
The latter is an example of a “tripwire” which by definition is a scenario when active leadership engagement is expected.
In either case, an effective autonomous team is proactively responding to risks and offering solutions/recommendations for trade-offs.
Commitment to predictability and velocity
Teams that commit will want to model risk. They may then use a buffer (time without planned work) to absorb some delays and reduce the chance of a trade-off conversation. This increases predictability but can reduce velocity due to Parkinson’s law (“work expands to fill the time available for its completion”). That week of buffer could have been spent on the next project, reducing tech debt, or some other valuable exercise.
One approach is “stretch scope”, SHOULD work that is ideally motivating and fits in the buffer. Tread warily though as I have both seen this succeed and fail.
Think of what creates positive urgency for your team, the desire for predictability by leadership and necessary process simplicity. Experiment and go with what works for your team, and be open with the approach you are taking.
The leadership and team commitment
As leaders, and yes, I flipped from “Manager” to “Leader” intentionally in this blog, running projects this way requires a commitment to empower teams to be autonomous, and to be clear on alignment and communication upfront. No people-centred leader likes to course-correct a team. When this does happen, treat it as a learning for the broader team rather than a failure of either the team or leaders. Commit to finding a balance rather than wild swings towards either leadership control or unfettered autonomy, both are which are damaging in ways illustrated in our earlier project stories. Aligned autonomy is hard, and the biggest commitment of all is the commitment needed by teams and leaders alike to make it work.
Credit: To Paul Slade, a former manager and mentor, who I once heard declaring in the hallways of Atlassian "it's not a deadline, it's a commitment!"