Softwire’s Key Responsibilities, #3 – Be fully responsible for all your tasks and actions
30 April 2014, by Chris Harris
This is the third in a series looking in depth at the five “Key Responsibilities” that Softwire asks of its employees, as outlined in this post.
Who is responsible for the successful delivery of a project? In Softwire, the answer is quite illuminating.
Each project is assigned a Project Manager (PM), who is the most obviously responsible for its successful delivery (incorporating commercial success and customer satisfaction).
The PM’s manager is called the “Super Project Manager” (SPM). In Softwire we currently have 4 SPMs, each of whom manages a number of PMs. Here’s what our internal literature says about the SPM’s duties:
The SPM is fully responsible for ensuring that the PM delivers the project successfully by providing oversight and advice as required…
Note that the involvement of the SPM does not in any way diminish the PM’s responsibility to deliver the project successfully. The PM remains fully responsible for successful delivery. The SPM is also fully responsible for ensuring the PM succeeds. I.e. both roles are fully responsible!
A similar principle applies to the portion of a project assigned to each developer. So The developer is fully responsible for both the quality and timeliness of their delivery, but so is the PM and the SPM. And the QA is just as responsible for the quality of the output as the PM or the SPM. You may consider this to be logically inconsistent garbage – or worse, some kind of Orwellian brainwash along the lines of “War is Peace”. The flippant response is “You can never have too much responsibility!” However we need to prove that this overlapping responsibility is meaningful in practice.
It’s worth considering two aspects of “taking responsibility” for something:
- Doing everything possible to make sure it goes well
- Being held accountable if it doesn’t go well.
The only problem with having multiple people fulfilling the first aspect is the potential for duplication of work. In practice, within the structure defined above, this doesn’t happen too often. It’s true that a QA and a developer might both independently be considering the same risks associated with a task, or the SPM might tread on the PM’s toes in double-checking that the project is going to be delivered on time, but this almost always turns out to be a virtue – these are important things to be thinking about, and we’re more than happy for two people to be doing so.
As for the second aspect, mutual accountability also turns out to be a virtue. Say a task goes wrong, and in hindsight it’s clear that the developer did not have the necessary experience. Then we should ask the PM why they didn’t give the developer more support. But we should also ask the developer why they didn’t request more support. And we should ask the SPM why they didn’t check with the PM that all the developers were able to perform their duties competently.
We generally delegate responsibility to people early on in their career, and the apparent logical paradox of mutual responsibility ensures that if you do something wrong, you are not hung out to dry, but neither are you let off the hook completely. And more importantly, when things are going well, everyone can take the credit!