With authority follows accountability. The other way around is also true. Anyone who’s held accountable has to have authority. Unfortunately it is far too common that developers are held accountable for a project, even though they don’t have any real authority. They typically are responsible for the delivery, but the authority stays on management level and that’s where the accountability belongs.
A bad manager will take all the credits for the success, while any failures are blamed on the developers. A good manager of course does it the other way around, but let’s ignore that for now. This post is about bad managers that do not accept the accountability that comes with authority.
There are two different cases where the developers are held accountable without having authority.
- The developers should really be accountable and have the corresponding authority, but management won’t delegate the authority.
- Management has the authority and they should, but they refuse to accept the accountability that comes with authority.
Developers Should have Authority
The first example I can think of where developers should have the authority is time estimation.
I’ve always been amazed when an initial estimate is given on a project and a non-engineer comes back and says that it’s too long. […] how can a non-engineer know how long something will take to be built?
– Nicholas C. Zakas
I’ve experienced this several times myself. The developers give an estimate that’s way past the budget the manager has to follow. The manager adjusts the estimates until it fits the budget and then blames the developers when it takes longer time. Often the actual time is close to the estimate given by the developers.
The estimate given by the developers is the only one that has a chance to being realistic. The developers should have the full authority to give estimates – and be held accountable for any deviations. If the estimate is larger than the manager’s budget, the manager has to adjust the scope.
Management Should be Held Accountable
While the developers should be trusted with doing time estimations on single tasks, it’s managements responsibility to keep the overall budget of the project. The authority to decide the scope of the project lies on the management. The managers have to balance budget against scope and quality.
If the project in total overruns it is always a management fault and management should be held accountable, not the developers. There might of course be several reasons that a project overruns, that sometimes are easy to blame on the developers. From a project management perspective it all loks the same:
The developers’ time estimates of the tasks were too low.
But looking closer on why the estimates were too low shows that it really is management that has failed in their responsibilities…
- Were the developers given the full authority of time estimates, or were they adjusted by management? In the latter case it’s not the developers’ estimates. It’s the management’s estimates.
- Were there enough time estimation and architectural skill and experience in the team doing the estimates? If not, it’s the management’s fault because it’s management that is responsible for putting together the right team.
- Were the project manned with more junior resources than the team doing the time estimates were informed of? Still management’s fault. It’s a huge difference in productivity between different developers and management must know the level of productivity of the resources assigned to the project. That information must also be passed on to the team doing the time estimates.
The only one that can possibly be responsible for the project budget and meeting the deadline is the product owner (or product manager) because that’s the one who defines the scope of the project.
The Authority to Reject Bad Specifications
When the product owner hands over the specifications of the project to the developers there’s one single authority that I’ve found crucial. The developers must have authority to reject bad specifications.
In some recent projects I’ve been using a workflow for product backlog items where there is an explicit “requirements approved” state. The workflow for an item is made of 5 steps (well, there are 5 QA and deployment steps too, but they’re not important here).
- New. Someone had an idea – not sure if it will ever be done.
- To Do. The product owner has decided that this will be included in the project.
- Requirements Approved. The architect (that’s me) has looked through the item and approved the description as detailed enough to be able to work with.
- Included in Sprint. The item has been included in the sprint to be worked on.
- Done. The item is done.
The important steps are number 2 and 3. This workflow ensures that both the product owner and the development team (through the architect) has approved the item before being eligible for inclusion in a sprint. At the sprint planning meeting we only consider those tasks that have state “requirements approved”.
As a developer it is a huge relief to have the authority to reject the specifications. Whenever something is unclear I simple refuse promotion to “requirements approved” and puts the item back as “to do” together with a list questions on details.
With authority of course follows accountability. Once I have approved the requirements of an item, I’m held accountable for the item being possible to implement within the given time estimates. That’s perfectly fine because I always have the option to hand back a product backlog item that’s not possible to work with. I have the authority to accept the accountability. It’s not something that’s just pushed on me.
Let Accountability follow Authority
When accountability follows authority everyone has the tools available for doing a great job. People thrive when they are given responsibility – but only if they also gets the tools necessary to accomplish the task.
This post was heavily inspired by Nicolas C. Zakas’ excellent post The care and feeding of software engineers (or, why engineers are grumpy). I think that most of the things he describes in there are a result of accountability being pushed onto developers, or developers trying to compensate for bad management decisions. With a accountability and authority being placed on the right roles engineers will stop being grumpy.