Delegation versus Abdication

I've had several instances where I was being asked about management work at an IT software/services company. They were interesting conversations, and I thought I'd write about it here. Some of the senior developers and project managers I've worked with indicated they wanted to either stay away from management (and remain with coding), or get out of management (and get back to coding).

These discussions usually boiled down to the difference between management by delegation and management by abdication. I've read about this before in E-Myth Revisited and here too.

The dictionary defines delegating as "entrusting (a task or responsibility) to another person, typically one who is less senior than oneself". And defines abdicating as "to renounce or relinquish a throne, right, power, claim, responsibility, or the like, especially in a formal manner".

I'd usually get a chuckle and a reaction that indicates that they're not abdicating, since they are obviously still occupying the position of power. But I believe they are missing the point.

Delegation requires a manager to understand what needs to be done, and then assigns someone to perform or be responsible for that task. A delegating manager designs what they are managing, and then delegates the responsibilities of that management to the people underneath him.

Abdication, on the other hand, involves assigning tasks to others, while not having any understanding of what they are doing.

Are you delegating? Or are you abdicating?

Real-world Example: IT Manager

Abdicator

Hires a team of software developers, analysts, and testers, for a project. Never gives them clear roles and responsibilities, but instead just says "do your job". While the team is busy with the project, the abdicator doesn't monitor and check if the project is progressing the way he wants it to progress (as s/he does not understand how it needs to be done).

When a project team member would ask the manager for suggestions, the abdicating manager would simply say something like "I surround myself with people smarter than me. That's why I hired you. So, what do you think would be best? ... Then go with it." (Sound familiar?)

Then, when something goes wrong with the project (e.g. missed deadlines, etc.), the abdicator gets mad and fires the team because they weren't doing their job.

And worse, this repeats again with another project team, since the abdicator still hasn't learned his/her lesson. S/he still has not designed a way (strategies/tactics/processes) for the team to manage the project, and failed to ensure that the team is following it.

Delegator

Hires a team of software developers, analysts, and testers, for a project. Understands that the following processes need to happen for a successful project: contract, schedule, backlog, sprints, iterations, version control, coding, testing, deployment, etc. Delegates the: backlog to the product owner, user stories to an analyst, design and coding to the programmers, testing to the testers, etc. Understands that each of these tasks happens continuously and then tracks the progress of these. S/he knows before something goes wrong in the project, and understands how to remedy them.

S/he continues to refine the design with structure and forethought. This frees the manager from the crushing load of day-to-day issues, and allows him/her to expand and scale out.

Micro-manage?

Remember our dictionary definition of "delegate" is to entrust someone else a task? Regardless of who has the responsibility for a task or function, the delegating manager is ultimately accountable for the outcome.

If it's such a big risk to delegate (and ensure things are done correctly), then should we micro-manage? Please don't!

Delegate, Do Not Abdicate

There are ways to help ensure that delegated tasks are done correctly (without micro-managing). That's why most IT managers define processes and checklists to help ensure that things are done well (e.g. require a signed contract before starting a project, ensure that work effort is charged to the correct project account, how are margins affected when team members are promoted, consider effects of long-term engagements over short-term, etc), and if things go wrong, managers can readily see it and take action.

In the E-Myth Blog post, it provides some guidelines for effective delegation. These include:

• Document the correct way to perform this task, step by step, including the quality control standards for each step.
• Clearly specify the expected results of the delegated task. Give information on what, why, when, who, where and how.
• When the new system document is ready, provide it to the employee responsible for that task, train them on how to successfully run this "system" and insert a copy of this process document into your company's Operations Manual.

In an organization that provides IT software/development services, these step by step guides to performing (delegated) tasks may mean: using TDD or ATDD, setting up a version-controlled repository for team members, using user stories and story points, having a daily 15-minute stand-up, proper on/off-boarding for new team members, etc.

Note that the processes need to be continuously refined. Or, if the process was defined by someone who does not have a good understanding of the business of software development, then perhaps the process itself is flawed.

If you're joining a company to become part of management (or whatever role), this is effectively being delegated the task of managing (or whatever the role entails). It would be good to determine if the company (and its leaders or managers) is good with delegation, and check if they have processes to bring you up to speed with how to do things correctly. Ask how you'll be evaluated to see if you're doing a good job or not. Otherwise, it might be a sign that the company doesn't really know what it's doing (and is just abdicating to hired people and telling them to "do your job").