top of page
Post: Blog2_Post
  • Writer's pictureJohn Graham

How to Build a Learning Organization: Step 4 - Delegating

Where Are We


We're talking about a learning organization and how to build one. Specifically, we're talking about a teaching organization and the tools you need to have in place. The goal is to have others learn as fast as possible and turn those learnings into lessons for others.


We're near the last step. This is what our skill-will matrix would call "Delegating." From the Dreyfus Model, which we're also using as a roadmap, the question here is: how do we begin to grow our proficient individuals into experts.


But first, we need to talk about what expertise means here and why we might need it.


I want to explain:

  • What you're going to delegate

  • Delegation pitfalls

  • How Delegation builds experts



Not Everyone is Going to be an Expert


It's costly to build an expert, but they're expensive to hire. Experts are rare.


We may have made the process seem inevitable - everyone marches from novice through advanced beginner and beyond, eventually reaching expertise. But that's just not the case.


First, we need to point out that actual knowledge domains are incredibly nuanced. For instance, you may have an expert in JIRA or Trello; that alone will be rare. But they won't necessarily be an expert in Project Management as a whole.


As another example, let's talk about high school subjects. Expertise isn't developed in "Math" or "History." Instead, people have expertise in "The Quadratic Equation" or "The Teapot Dome Scandal."


Expertise is narrow in most cases. Broad expertise is astonishingly rare.


The other thing to note is that you don't need expertise in everything. I mentioned JIRA earlier. Do you need an expert in JIRA? Or do you just need someone proficient - competent even?


Most companies today - even successful ones - have large teams of advanced beginners, a handful of Competents, and just one or two Proficients for entire vital functions. You don't need expertise in everything; it's too expensive to get anyway.


To build these narrow experts takes a lot of time and money. Given how the marketplace works, there will be experts you can get advice from (consultants) and experts you want in-house. What experts do you need to have in-house?


What Experts You Have Depends on your Strategy


Where you decide to spend your resources ultimately comes down to your strategy. Your strategy should answer that question - what is our area of focus. When you determine your area of focus, you're deciding where you need to build expertise.


We have proficients; we want to build expertise. Strategy is at the core of the learning organization.


Strategy is roughly the goal your company has identified and a set of tactics it has decided to use to pursue that goal.


Those tactics will influence all aspects of the company. In particular, the tactics a company uses to pursue a goal will affect the Org Chart. This isn't just how deep or wide it is, but how many skill sets are needed and what job descriptions are required.


When an Org Chart grows, people need to backfill those slots. The best way to backfill those slots is to train, mentor, coach, and eventually delegate authority to those people.


So your strategy more or less is embodied in how your learning organization works. Not just in the day-to-day enforcement of values but also in:

  • The disciplines that your learning organization supports

  • The level at which each is supported

That's because we're reaching the end for most domains.


Many disciplines in your company will cap out at Competent becoming Proficient.


There aren't enough resources in the company to make everyone an expert in everything.


Indeed, your strategy will define your core competencies (or what you think they should be). And your learning organization is going to help you get there.


You only need Experts in your core competency.


If your company's strategy isn't "use our crazy good Java skills to outcompete our rivals," you don't actually need experts in Java. Like, where expert means: you present at conferences, write white papers, and write books.


You need the Java skillset, and you need people proficient in it. But you're not going to invest in growing people to the point of expertise because, as you've seen, it is starting to get expensive.


Delegation in Practice


This may sound a bit theoretical, so let's give a more concrete example. You need to decide what your organization will look like for a senior leader. The way you choose that will depend on the goal you have for the organization and the pros and cons of various organization types in achieving that goal.


Is marketing a C-level function, or will a Vice President do it? Do you need to have a Chief Engineer in addition to a CTO?


Many people answer this question with "who" - who's in charge of what. This is backward. You need to decide the organization first, then assign those roles to people. You aren't a jobs program. You do not exist to ensure the CEO's buddy is employed. You exist to make a profit and keep your customers happy. Your org design needs to reflect that.


From these top-level positions on down, you need to think of roles that need to exist to make the org function efficiently. In the end, you will have an organization that has implied levels of expertise built-in.


Experts are Experts in Your Thing


This finished Org Chart that pursues your strategy must build experts in-house because none should exist anywhere else. If you have a top-level role that ultimately could be filled by a consultant, you are more or less saying you're competing with that consultant. You're in the same industry.


If you decide you need high-level experts in Java, you need to realize that you're making the implicit assumption that you will compete in the marketplace based on your Java skills. This may be the case, but it's probably incorrect unless you're selling a Java library.


Will a healthcare firm need to be a healthcare expert? Kind of. But not really. Because "healthcare firms" don't exist.


Instead, you are a firm in the healthcare industry with a specific client niche using a specific product category powered by a specific methodology and technology to compete.


Your experts need to be experts in those things. They need to be experts in your company. Now, you can see why you're going to have to build them. You're not going to find many people who already know all those things out in the labor market because why would they?


Sure, you can hire from your competitors, and that's not a terrible idea as part of a larger strategy. But you need experts who also know your internal politics and have social capital. Again, this means your top-level people - to be experts - will have to be built internally.


How to Build Experts


Let's talk about broad and narrow again. Someone might only need to be "Proficient" in project management overall and be knowledgeable in how your company works, who your target client is, what your technology is, etc... to be an "expert" in your company.


In other words, each specialty is narrow, but the thing you want - an expert in your company - is going to consist of a family of information that may be disparate. As much as our schools and functional breakdowns of our companies imply that you just need to be the best accountant to be the head of accounting, we know that's not the case. You have to have a broader and broader skillset to understand more of the business, see the industry's future, and have ideas on what moves to make.


These tactics break down into 3 steps:

  1. Broad rotations

  2. Delegation

  3. Succession Planning


1. Building Broad Experts


So, by and large, you can repeatedly use the previous Learning Organization steps to continue building broader and broader expertise in people. Here we aren't talking about rotations as a way to better understand a specific field.


Rotating through various teams working on C++ projects is a great way to build more knowledge in C++. But only by rotating through marketing-focused efforts or sales-focused efforts is someone going to make that broad expertise in your company.


People may be novices at many things, advanced beginners in a few things, and competent in one or two at any one time. Your future broad experts - the ones you are building to run your organization - will be going through the learning organization repeatedly, learning broader and broader skillsets.


2. Delegation


Training, Mentoring, and Coaching Is Not Over


Training will get more self-paced, as we said in our blog on building a learning organization and coaching. We need to continue to use other means at our disposal to the extent that we can continue to grow our staff.


Coaching needs very little modification - other than some antacid for the coach who needs to get used to their protege making bigger and bigger mistakes. You could also consider outside coaching at this point since, as you go higher up the hierarchy, the number of People Managers who can effectively coach and hold people accountable to their goals is going to get fewer and fewer.


Do you need external coaching for your managers or technical leaders? Let us save you time so you can focus on strategy. Contact Us!

Mentoring can also continue, though you may need to put people of similar skillsets together to "mentor each other" - divide and conquer complex material, or specialize in slightly different aspects of the domain. Or, just have a conversation partner with a deeper level of domain knowledge than coaching.


These things continue as we add in Delegation.


When to Delegate


You have a role - this role developed from your strategy. Perhaps it's your own role (we'll talk succession planning in a moment), or it's a new role to pursue a change in strategy since you were promoted.


You have a person who's done all the required training, mentoring, and coaching to build their skillsets to fulfill your designed role.


Now you are ready to delegate.


And not a moment sooner.


"Wait, what?"


If you give someone authority - delegate to them - tasks and responsibilities that you have not trained, mentored, and coached them for, you are setting them up for failure.


This is because Delegation is not delegating execution or delegating busy work. It's delegating the responsibility.


If you are pulling smaller parts of your job out and delegating them to people, but you need them done in a specific way, you're not actually delegating. You're directing. You're telling.


This is fine, but it belongs in an earlier part of their skill-will journey. You tell novices how to do things. You don't tell experts - that's micromanaging and refusing to delegate.


One horn of the Delegation dilemma is precisely this: people refuse to let go of their current responsibilities, giving them to staff prepared to take them.


You must be willing to let the delegate make mistakes. The primary time for correction is over. Delegation means you're letting someone take the wheel, and you will back what they decide. You are not ready to delegate until you're prepared to do that.


The other horn of this dilemma is delegating too early. If you haven't gone through this system's training (directing), mentoring, and coaching parts, you have people whose skill or will is not up to the task you're about to delegate to them.


Allowing them to make mistakes is cruel at that point.


You escape the dilemma by explicitly setting out the learning expectations for the role, and when someone's met them, you let go.


"But We've Got To Grow!"


Okay, so let's get back to the real world. We've got to grow, and we haven't had the time to set up an entire learning organization yet.


How do we bootstrap? You absolutely 100% needed help yesterday.


The solution is to delegate and grow the person simultaneously, using the job as the domain they're developing their expertise in.


This is skill-will / situational leadership 101 and your only option if you don't have training, mentoring, or coaching in place.

It's not complicated - but you have to meet people where they are. To delegate to people who aren't ready, you've got to basically micromanage them.


Woe be unto you if you misjudge who is ready and micromanage someone who can do your job better than you.

This means that you've got to lean more on the directing and telling side, similar to our failure case above. You've got to pull off the tiniest responsibilities and tell people exactly how to do them and why.


When they're successful in replicating you, you've got to shift to mentorship intuitively. Shift from prescriptive instructions to after-the-fact feedback. Again, if you stay too long in "telling/directing," you will be micromanaging.


As they need less and less feedback but need more and more thought partnership, you're shifting to coaching. You have not delegated the responsibility yet! If they make a mistake, you need to save the day; though they're more able to learn from experience rather than guided instruction.


Finally, as they seem competent and engaged in this new task, you can turn it over to them.


This can take a long time. There is no shortcut. If you decide to just turn things over to people before they're ready, you'll be doing little more than fixing everyone's mistakes in the short run. In the long run, hiring to cover the higher turnover you caused will get you stuck in the mud anyway.


The Low Performing High Performer


If you've ever had someone Peter Principle themselves, you can see this in action. They seem to do well at many tasks required for a higher role, but once in that role, they struggle and struggle.


Have they hit their peak performance? Not likely. Instead, they are no longer getting the support they need to continue to build their skill and, more importantly, their will. They get stuck, and no one's available to help them.


All of their direct reports suffer because of this.


If you're their manager, you need to step in.


The skill-will model works forward and backward. If you realize someone may be Proficient in "Managing 6 people" but only a Novice in "Managing 16 people," you have to meet them where they are. Get back to telling/directing/training until they have the skills to be more confident.


Letting them flounder is unfair to them, and you can't expect people to just sink or swim.


What To Delegate?


Okay, so you've either got:

  • a learning organization set up (even a tiny small one)

  • you're bootstrapping one

What should you hand over?


What about the learning organization itself?


Let's talk about that Java expert that keeps coming up. Let's assume you need a Java expert.


So your future Java expert has done all the training you recommended. They have been mentored in-house and by consultants. They have been coached by you. They've gathered lots of experience and did rotations even in things adjacent to Java. They've mentored others and led in-house training.


Aren't they the most qualified at this point to administer the training and mentoring programs? Aren't they the most suitable to determine who's Competent, Proficient, and merely an Advanced Beginner when it comes to Java?


Just as teaching helps us learn, designing a teaching program helps someone remain holistic in a very challenging way. The first thing your expert may do with any future knowledge, any product of R&D, any new technology in their field is to figure out how to fit it into the learning organization. By controlling the path that got them to their level, they're always aware of what it might take to get to the next level.


Watch for Gatekeeping


One caveat of delegating authority over training and mentoring itself is the tendency to gatekeep. This happens to the best of us - we think because we faced hardships, others should too. Or we overvalue experiences because they were brutal.


Training and awareness of gatekeeping can help, as can policies and guidelines that will resist it. For instance, making training harder should have a concrete reason for doing so, and there should be a way for trainees to lodge complaints about difficulty.


You can also turn over parts of the learning organization in phases and double-check changes for a year before fully turning things over. Beware of using this lever to micromanage, though. Try your best to trust changes and only roll things back if you have evidence things are getting worse.


People Delegation and Inheritance


So in the prior section, we talked about delegating functions. It works with delegating teams, too, though people are usually more familiar with that. I wanted to ensure it was included so readers didn't think functions and skillsets are the only things that can be delegated.


However, a good model of how teams might grow can be found in Object-Oriented programming and the Liskov Substitutability principle.


Let's say the company is growing. You have a team of 6 folks, but ultimately you need a team of 6 managers who manage teams of 6 engineers. That's a lot of growth.


You can delegate the responsibility of managing those folks - similar to the skillset/functional Delegation of technical experts. You need to really hand off the subteams to them.


But how do you ensure that teams are similar enough to still work together if need be, or people can rotate through them? And what needs to be shared at the departmental level? What do teams do because you're their director, and what do teams do because someone else is their manager?


Using Liskov Substitutability means there should be some foundation of culture and process department-wide. Individual teams can build on top of this. They can do more, but they can't do less.


For instance, your departmental "Definition of Done" may require 50% code coverage of unit tests before a commit can be merged. This means individual teams can go beyond this - 60%, 70%, 80%... but not below it.


Delegating the How


Another way to delegate people authority is to still set the goals but not determine the how.


This can be done at the product level by setting feature priorities in a backlog. But it can work with other aspects of teams as well.


For instance, your departmental process doc - which I will call a departmental constitution - may require "Teams meet regularly to discover problems early."


One team may want to use a Scrum Standup to accomplish that goal, while another group may just write status in slack.


In this way, you're setting up an interface - what does it mean to be a team in this department - but allowing implementation details to differ.


This allows for autonomy, which is what Delegation is ultimately about.


3. Succession Planning


The first project a person should be assigned is how to delegate their position.


That doesn't mean they're going to delegate what they just got; but the way an organization keeps growing is that each person builds growth into their job from day one.


It's also prime time to do succession planning. The delegate goes through parts that weren't captured in any training, mentoring, or coaching. They will be catching these things themselves so that they can train, mentor, and coach others on them.


You will not get another chance to see all the dust for the first time. If you don't take the opportunity to reflect on how the Delegation could have gone better, you may miss your chance to OODA loop this process. It takes a long time to prioritize improvement to Delegation; what better way to do that than to prepare to delegate again.


This also sets up a good precedent for Delegation. It's all about genuinely handing something off. And the best way to let someone know they are in charge of a thing is to tell them - after handing it off - "I'm sure I made a lot of mistakes in handing this off to you. Write them down and fix them, so you don't make the same mistakes when you hand it off."


It lets the delegate know they are now responsible and have the authority.


How Does Delegation Build Expertise?


All this may have made sense, but ultimately, it may not have been clear how this builds expertise. How does taking someone Proficient in enough things and giving them power and authority turn them into an Expert?


It doesn't. Not automatically. And not very soon.


However, if you do not delegate, you will absolutely never have experts.


Ultimately, you're pushing the boundaries of what the company knows. You build expertise by learning - and your Proficient people have to learn.


We've helped your future Experts learn by training and mentoring. We've helped them get as much out of new experiences as possible by coaching them as they start to reach beyond our own expertise.


Ultimately, they will have to make bigger and bigger mistakes to keep growing. We'll have to be there to help them analyze what went wrong and what went well. That's you're only option at this point. You've exhausted every other means of learning outside of trial and error.


Delegation also shifts people's mindsets. Being responsible and accountable for a thing tends to make people think a bit more clearly. If you're a parent, it may be a constant struggle to convince your kids that, no, ice cream is not dinner.


They know that if they can convince you that ice cream is dinner, they can be confident you've thought about the long-term health risks, and it's okay, just this once.


But once people are off to college or young adulthood, they realize that no one will check their bad decisions. They become more responsible because there's no one to keep them safe if they screw up. At least some of them do.


Did your child grow up to be an adult that insists on eating Ice Cream for dinner and is now paying the price? Please don't contact us because that's not our expertise.

This responsibility is what Delegation will get your staff. They're going to see all the tech debt their proposed rewrite may bring on or deal with all the political fallout of trying to discipline someone. It's on them, and they have to learn how to navigate that.


Similarly, gatekeeping can be somewhat hindered by ensuring delegates know that you're expecting a specific rate of recruits making it. The balanced responsibility to ensure quality and quantity can help people understand that they aren't meant to close the door behind them.


You Are Not Necessarily an Expert


A final note on this subject... We've talked about building experts and Delegation. One can work the delegation process in reverse and conclude that because we're delegating, it makes us experts.


No.


Experts are grown by going through the Dreyfus Skill Acquisition model. If you haven't done that, you aren't an expert.


One of the most significant advantages of handing the learning organization to people who've gone through it is that they'll know what you got wrong because they'll be closer to an expert than you were.


The people they train, mentor, and coach will be better still. Moreover, the learning organization will get more efficient. Over time, the company can sustain higher rates of growth. There will be deeper and broader expertise. This is a good thing. Don't try and hire the best - learn from Delegation. Make the best people and get out of their way.


If you want help developing your own ideas for a Learning Organization or need help delegating, reach out to us or...

40 views0 comments

Recent Posts

See All

Will AI Phase Out Software Developement Roles?

John recently sat down with Daniel Litwin at MarketScale to talk about AI. AI won't change programming in the way you think... Check it out here. Key Takeaways: Junior devs need to treat AI as a doubl

Soapbox Logo (Transparent).png
bottom of page