Flagstaff, AZ — On a hike in the fall of 2018

Unpacking Delegation — Part 1

As a leader, at some point in your journey you have probably been told or have even told someone “you need to delegate more”. Pretty hollow, I know, and at best it is not helpful. I have literally uttered those words, and completely deserved the resulting facial expression of the recipient.

The reason that this is a hollow request, is because it fails to provide important context. Namely, what does it really mean to delegate, what does it not mean and how good delegation (or lack thereof) affects you and your professional sphere.

In this series of articles, I will share a more in-depth view of delegation especially from the perspective of technology leadership. For this first post, I attempt to provide a useful definition of delegation which hopefully sets the tone for getting more in-depth.

“Delegation” undefined

First, let us deal with some of the misconceptions that one may have regarding what delegation means. Here we just state their essence and leave the proper debunking to occur in the future posts.

Myth #1 : Delegation involves assigning tasks and priorities

Assigning tasks, setting priorities or other “obvious” intrinsic assignments do not constitute delegation. For example, if you have a release engineer on your team, the release tasks they are performing do not constitute delegation on your part. They would be performing those tasks and functions regardless of your presence.

Myth #2 : My team is super-busy, mission accomplished

The term “busy” describes the state of being occupied. The word makes no other claims, and certainly none about your success in delegating. The state of being occupied also makes no claim on whether the team is doing important work from which they draw a sense of fulfillment and achievement.

Myth #3: I can only delegate to people in “my team”

This limiting-belief is based on a limited definition of delegation (and of what “my team” is). This myth works hand in hand with Myth #2.

Myth #4: Delegation will erode my “currency” as a technical expert

My favorite myth because it is one that I have held at times. Technology leaders especially, may have an affinity for this limiting-belief.

“Delegation” defined

As an embedded systems architect by trade, I relish in describing things precisely, but with the power and elegance of abstract constructs and behaviors afforded by well-crafted specifications and semantics of programming languages. The abstractions do not take away from the preciseness because the many layers below these constructs are themselves precise and predictable. The goal of defining an architecture, model or specification is to achieve comprehension without interpretation.

This is a leadership anti-pattern however. Delegation is a human behavior and humans are neither precise nor predicable. We must also welcome interpretation and a variety of resulting comprehensions.

At some point, I was introduced to the concept of “user stories” (see Wikipedia for a quick definition). These are usually short and simple blurbs, and yet convey a lot of purpose and motivation. The reason they are so powerful is because of their sufficient vagueness. A user-story is deliberately vague, so it can be re-interpreted and iterated upon.

So here is my user-story based description of what delegation really means:

“I want to entrust someone to own a thing that I am very passionate about, so that innovation and people can thrive

Let us interpret this story:

  • Trust — Real delegation is a resounding expression of trust. Trust is everything. The thing about trust, is that it must be manifested to positively effect the recipient. Delegation is a lot like trust in that it is a set of beliefs and associated behaviors. People cannot observe what you believe, only how you behave.
  • Importance (intensity) — You are not truly delegating unless the “thing” is important to you. Chances are if it is important to you it will be important to the “someone”
  • Purpose — I have written down what I consider my overarching “why”, but there are many more, e.g., “so that our company remains competitive”, “so that I can stay focused on where the team is going”, “so I can delve into a new technology that might be important for us in the future”. The list goes on. It can be iterated-upon and re-interpreted.

We have now established the key elements of what would constitute a qualifying delegation and hopefully you are coming up with more “whys”. Which “whys” matter to you?

Technology Leader | Systems Architect | Programmer | Photographer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store