Hold Up. What problem are we trying to solve here?
We’ve just gotten through a lot.
In step 1, we talked about introducing training to your organization. We talked about getting training from external vendors and where your own internal training assets need to be in place.
In step 2, we talked about technical mentorship: sharing lessons from folks with more experience with folks with less; mentoring such that everyone gets something out of the relationship.
In step 3, we talked about coaching: people managers' role in a learning organization. We talked about how to be a good coach, the differences between coaching and mentoring, and how coaching keeps people growing even when you’re in terra incognita.
In step 4, we talked about delegating. We reviewed how your Learning Organization needs to be tied to your strategy and how all teaching is about spreading learning. All learning is about building skills to leverage in your strategy. Your learning organization should mimic - if not be - your organization. We talked about delegation patterns and common failure points and how to avoid them.
Lastly, we talked about thought leadership in step 5. That’s the one (or two) ways that you will excel and compete in the marketplace. You need to grow beyond mere experts and be the ones discovering facts about the world with your tech, marketing, and operations.
This may all seem incredibly complicated; and it may seem like you can never do all of this. That’s probably true. Let’s face it, you’ll never get anything perfect in your organization; but even if you admit that, you still may not know where to prioritize.
Do you need training or mentoring? Are your managers scaring people away? Maybe you should work on your coaching skillset?
There’s a way to organize a lot of this. Just as Google has argued that SRE implements DevOps, there is a system that “implements” a Learning Organization. And it may work as an excellent blueprint for your organization.
Enter: Badges and Guilds
Badges and Guilds are a way to organize a Learning Organization. They can build independently but get some nice set-completion-bonuses if you eventually make both.
If you build Badges first, you’re eventually going to run into the problem of “How do I hand this Badge system off and to whom?”
If you build Guilds first, you’re eventually going to run into the problem of “How do I ensure these groups are transparent and meritocratic?”
What’s a Badge?
A Badge is a written document (in GitHub, Confluence, or wherever) that shows a transparent and concrete path to learning a single subject.
Badges are helpful as a reference point for questions like, “How do I learn data science?”
They should make up the core written element of your Learning Organization. If you had nothing but a Badge system describing all the core skills you thought you needed to succeed in the marketplace - and how to get those skills - you’d be doing pretty good.
You can apply the Dreyfus Learning model and Situational Leadership to the Badges themselves. All five steps of this blog are good guideposts. You might break up Badges into “levels,” for instance.
Level 1
Here’s your basic training and other rote rules-based content. You’d be trying to get people from Novice to Advanced Beginner.
You might have links to blogs, videos, tutorials, or classes that your team found useful. You might require basic certifications and provide the budget to do so. In addition, you might introduce people to the basic rules that your company follows - a coding standard, a peer review process, and so on.
You may want to produce quizzes for these both to help with retention and as a means for compliance.
People aren’t masters at the end of Level 1; but they at least have been introduced to the way things work.
Finally, maybe you have a capstone “challenge” like a code challenge.
Level 2
Here you’d begin to introduce specific experiences and look at the sheer time of experience using the craft. You’d introduce mentoring. Where do you get the mentors? Stay tuned...
You can still mix in traditional tutorials and training. However, this would cover more practitioner’s concepts - tips and tricks rather than the basics.
Graduation here might look like time-in-level plus the mentor’s approval and completion of required training.
Level 3
Here you’re introducing mentees. You’re also branching out from “basic developer” experience to “expertise” kinds of experience. Any training at this level may be self-paced. It might include a menu of advanced options, such as conference attendance and unstructured training (basically self-paced hours of videos) and writing quizzes or challenges for others.
Graduation from level 3 may consist of the usual - time-in-level, mentor’s approval, and introduce things like people manager’s approval based on whether or not the candidate has been responsive to coaching. This could be in addition to peer-level support through 360s and other methods.
Level 4
Here’s where Badge holders might partake in “running” the Badge (assuming you have level 4s). These folks have become a select few who are actively advising the company on using the skillset the Badge pursues.
Stretch projects that introduce new concepts to the company are seen as the experience to be pursued here. Additionally, one might expect to grow broader and wider through Badge dependencies. To get a level 4 in this Badge, maybe you need a level 3 in two others.
Level 5
In the one or two Badges where you even recognize a level 5, these folks need to be recognized as site-wide leaders in the company by other experts. They need to be seen as upholding and pursuing company values and strategy by the people management chain.
This is where the goal is to begin to be seen as industry-wide experts, by your clients, competitors, and partners, in the fundamental skillset. This is where competitive advantage is located when it comes to human capital.
Obviously, level 4s may be “running” the Badge in many badges. If level 5s exist, naturally, they’d take precedence. Otherwise, they’re spending their time training, mentoring, and researching the skillset in the direction they think is most aligned with the company’s strategy.
Example: C++ Badge
As stated in earlier posts, you probably don’t need a deep programming language Badge. However, C++ is something the author knows and has the confidence to give at least a bad example rather than an outright terrible one.
Level 1 Advanced Beginner
Read Accelerated C++, do exercises, and have them checked by your mentor
Review our C++ Coding Standard and take the quiz
Finish the C++ Code Challenge used for hiring candidates, respond to feedback
Those who finish these things can play the role of “C++ Developer” on a project team
Level 2 Competent
Have played the role of C++ developer in one project successfully
Have made at least twenty contributions to a C++ codebase that at least two peer reviewers (your mentor, the code owner) approve of after feedback
Read Modern C++, do exercises, have them checked by a mentor
Read some tutorials on Boost and do the Boost Code Challenge
Have at least twenty pieces of feedback accepted during a peer review of other’s C++ code
To graduate, in addition to the above: mentor’s approval, one year of experience at level 1
Those who finish these things can play the role of “C++ Specialist” on a project team
Level 3 Proficient
Mentor at least two other C++ developers from Level 1 to Level 2
Read one of: Something on high-performance C++, Something on distributed C++
Play the role of code owner for at least two years on a C++ repo of at least 5ksloc
Have attended at least 3 C++ conferences
Have done at least 3 C++ related internal tech talks
Reviewed and added a tutorial to this Badge, added a quiz to this Badge
To graduate, in addition to the above: mentor’s approval, peers (other Badge holders for C++)'s general approval, people manager’s approval (based on embodying values), two years experience at level 2
Level 4 Expert
Mentor at least two other C++ developers from Level 2 to Level 3
Mentor at least four (total) C++ developers from Level 1 to Level 2
Whole “owned” code over 10ksloc
Presented at one C++ conference
Given 6 internal tech talks
To graduate, in addition to the above: peers (other Badge holders) general approval, VP level people manager approval, two years experience at level 3
Note: Why are we going up the people chain to VPs here? Because the number of slots for experts and above may be limited.
Level 5 Thought Leader
Expectations:
Present regularly at C++ conferences
Advocate for the company to have a seat on the guiding committee
Be writing a book
Lead advanced training
Consult with C-level leaders on strategy leveraging C++
Actively mentor experts
Like what you see here but are having trouble of applying the above sample to your own problem? We can help you design your own Badge system!
External Certifications
External certs are valuable and usually are a Level 1 or Level 2 sort of target, as are most books. External education is exceedingly cheap where you can get it.
Still, most companies seem to eschew external education. Why?
I’d say they break down into two large groups.
The first group of companies doesn’t think training is their job. They attempt to find people in the hiring process with the training they already need. This seems like a wrong long-term solution for a few reasons:
You’re never going to find anyone “trained” in “your” company. If you don’t provide that, no one else will.
By trying to find people who already have the skills, you’re focusing on a segment of folks who obviously prefer gathering skills. But then you turn around and offer them an environment that will not support them in getting more skills. This makes attracting and retaining them hard.
Already skilled people will be more expensive than hiring less skilled people and training them.
The second group of companies thinks only about cost instead of ROI. This is terrible accounting. So they see a price tag for the training of $5k. That “sounds” expensive, so they send one person, then bring that person back and have them re-give the same training internally. This is the train-the-trainer model. This has flaws as well:
The trainer you’re getting won’t be as good as their trainer. You're playing a game of telephone. So all the folks taking this internal training will get less value out of it than had they attended the real thing.
If you think in terms of ROI, you’re sending an employee who can do a host of things no one else can do - fix your internal systems, lead internal projects, advocate for internal change - and flipping them into something anyone can do. Train on curricula that are out there in the industry. It’s a colossal waste of resources. You focused on dollar cost rather than opportunity cost.
Many entry-level trainings are pretty cheap. If cost is prohibitive, you can reserve a certain number of slots per year and give them to higher levels.
A Roadmap for Coaching
The Badge system becomes a handy tool for coaching because it helps coaches - who otherwise are not domain experts - see the broader landscape of skills and growth.
One-on-one conversations with people managers can quickly become just check-in on “Badgework” rather than a brainstorming session on how to best find goals and tactics to achieve those goals.
Talking about Badges also helps with human capital planning. What skill sets are needed? These are questions individual contributors might ask their people managers when thinking about what to target next.
Badges also serve as a tool for mentors since they provide set curricula, answer keys, and rubrics. They don’t have to think of in-depth exercises but have a ready set and standardized group of activities. This also helps with quality control, as there’s less worry about getting the “bad mentor.”
You Don’t Have to Have 5 Levels
You can break things up into more than five levels, splitting concrete goals and milestones even further to provide more growth. The more you break things down, the more “momentum” effects you’ll enjoy from folks cruising through your Badge system, aware that yet another milestone is nearly complete.
This may all sound complicated - indeed, you may be wondering how you can plan out and operate anything but the most straightforward Badge system. The answer to this is…
Guilds
In the paragraph above, we referred to “Badge holders” as a group of people. People may have the Level 1 Java Badge, and another group of people may have the Level 2 People Manager Badge.
If you don’t have a Guild system, that may be as far as you go in denominating these groups. However, it becomes a bit easier as soon as you introduce Guilds. Anyone with a C++ Badge is a member of the C++ Guild, anyone with a People Manager Badge is a member of the People Manager Guild.
I am Known by Many Names
Whether it’s “communities of practice” or “enabling teams,” the idea of Guilds shows up across many companies. So instead of seeing Guilds as a strict definition that does a specific thing, look at your company and figure out what’s “most similar to” the Guild idea at your company and just try to iterate there.
Who Watches the Watcher?
Mature Guilds may be led by someone in a Level 4 or Level 5 role. These people will help set what work is and is not in the Badge and lead other efforts contributed by the Guilds.
Depending on the actual level of work the Guild needs, this may be a full-time role or a part-time role. Indeed, there may be a handful of full-time roles for crucial Guilds who act as consultants in the Guild’s skillset (the “enabling team” from Team Topologies). Various kinds of “Guild topologies” allow you to tailor-fit each Guild to the level of effort you want to fulfill your strategy.
Some Guilds may comprise just a Level 1 Badge and a single person administering Guild meetings part-time. On the other hand, Guilds that provide skills you leverage as a competitive advantage may have many full-time members and a very deep and elaborate Badge.
The person who runs a Guild is called, ahem, a Guildmaster.
Guildwork
We mentioned Guilds “running” and owning the Badge. What else might they do?
First, we noted earlier that very mature Guilds may act as enabling teams, providing consultants to various other groups. This is different than the “C++ Developer” role described above.
For instance, perhaps your people managers have decided that each cross-functional team should have one C++ Developer and one C++ Specialist. These terms are defined as having the Level 1 Badge and Level 2 Badges, respectively.
These cross-functional teams (called “value stream” teams in team topologies) have people assigned to them full-time, and those folks report through that cross-functional team. They just go to the Guilds for their training and mentoring.
Let’s say our C++ Specialist runs into a particularly hairy problem and needs help. They may reach out to the Guild and get a few part-time consultants to review the situation and advise. This is the “enabling team” pattern.
Second, Guilds are going to own a lot of skillset-related artifacts. Let’s go over some examples.
Definitions of Done
The software engineering Guild may decide that all code to be merged must have unit test coverage of 50%, run a linter, and be peer-reviewed by at least one person. This is part of their definition of done.
People management determines that each cross-functional team should have at least 3 software engineers of various levels assigned. To have a level 1 or higher in the Software Engineering Guild, these members agree to abide by that Guild’s definition of done. Hence, to stay a member in good standing, they will bring their definition of done with them. All projects using those Guild members will have unit tests covering 50%, etc.
Code Standards
Similar to definitions of done, particular code formatting and other rules particular to one company may be owned, amended, and updated by the Guild. These can serve as peer review guidelines or a set of tools the Guild requires to be run on all code.
Code standards may be debated or amended through a democratic process, or the Guild may be set up such that the Guildmaster alone can push for code standards. Generally, democratic processes will get you better results in the long run but take longer to spin up.
Code Challenges / Hiring Guidelines
The challenges you use to hire folks can and should be owned and operated by the Guild. For instance, let’s say you’re looking for Python developers.
The Python developer opening is in a particular cross-functional team; that team may have certain things it likes to add to its hiring process. But it must also abide by the requirements of the Python Guild and use that coding challenge.
Peer reviewers for candidates' code challenges can also come from the Guild.
Guilds Operate the List of Mentors
When a person needs a mentor - or wants to switch mentors - the Guild is where they’re going to go to get that list. This helps administer the Guild and mentoring system by ensuring each Guild maintains a list of who has what Badge. As a result, it’s easy to identify who can serve as a mentor.
Guilds May Have Reporting Relationships
Guilds replace functional departments in matrix organizations. Thus, just like functional departments, they may have other Guilds report to them and, in turn, report to other Guilds.
Rather than the HR department reporting to the Finance department, you may have the HR Guild that reports to the Finance Guild. In turn, the Compensation Guild may report to the HR Guild.
This becomes very useful when Guilds more or less represent the skillsets of other Guilds - or when Badges require other Badges to advance. For instance, the Software Engineering Guild may have the C++, Python, and Ruby Guilds report into it. And to grow as a Software Engineer, you may need to have certain levels in one or more of the reporting Guilds.
Guilds are not departments, however. This is crucial. What do I mean?
Guilds are interface inheritance; departments are concrete inheritance.
Inheritance
In Java, you inherit as many interfaces as you like, but only one concrete class.
Departments are like concrete classes. You are a member of a department. In many matrix organizations, you are a member of only one department, must ask permission to get transferred, and the department is your primary reporting structure. You’re loaned out to projects. The functional hierarchy is the solid line, while the project teams are a dotted line.
Guilds work differently. You can be a member of as many Guilds as you like so long as you can keep up with the commitments and do the Badgework required. You do not need to ask permission to work in a Guild - though some restrictions may apply at the higher levels. Your project team is your central solid line relationship, while all your Guild responsibilities are your dotted line relationships.
Liskov Substitutability and Constitutions
How can you abide by many Guilds? And how do Guilds interact when they have their own hierarchy? For instance, if your Software Engineering Guild requires a test coverage of 50% to be in good standing, and your C++ Guild needs 60% to be in good standing, which rule applies?
In this case, the more strict rule applies since that would satisfy both.
Child Guilds (like C++ to Software Engineering) can get more strict; but they cannot get looser in their requirements. This is similar to the design principle of Liskov substitutability.
Similarly, the C++ Guild and the Software Engineering Guild may require applicants for a C++-heavy position. These need to be combined. Care should be taken that they don’t contradict - with the Software Engineering Guild getting the right of way when they do.
Many sets of artifacts, how Guilds work, and so on can be defined in Guild Constitutions. Storing these in Github is nice because amendments to the constitution become a PR process.
Ultimately, these constitutions themselves must stack, not unlike the US State and Federal constitutions.
Guilds are Not Roles
If you are a member of the C++ Guild, you are not necessarily the “C++ programmer.” Your cross-functional team may not need more C++ skillset at this time. Though, of course, no one will stop you from doing peer review or sprucing up the code when you’re not busy.
For example, you may be a Python and C++ Guilds member. But on your cross-functional team, you play the role of a Python developer. This is another way you can be in as many Guilds as you'd like. Guilds make you eligible for roles, but they do not guarantee them.
Value Stream Teams
I’ve used the terms cross-functional, project, and value stream team interchangeably. And we gave an example above of how roles on a team would be “qualified” for using the Guild and Badge system; but ultimately, they’d report to that cross-functional team.
In a very mature system, you may see your value stream teams of folks with levels 1-3 (often in many domains) doing the execution work for the value stream. Meanwhile, your Guilds and enabling teams are doing consulting work and are populated with levels 4-5 (in their particular Badges).
Common Guilds
We’ve used a lot of technical examples like the C++ Guild or the Python Guild. But any skillset can and should have a Guild and Badge.
That includes, but is not limited to:
Product management/ownership
People management
Project management/agile coaching
SRE
DevOps
Software Engineering
Data Science
Data Engineering
How do Guilds and Career Ladders Interact?
You probably want to find a few core Guilds; as an “artifact” they own, they’re allowed to create titles.
For example, your C++ Guild probably doesn’t need any titles. But your Software Engineer Guild may need some titles.
These titles can correspond to certain levels in the Guild. So a level 3 software engineer may be considered a Staff position, and Level 4 is regarded as a Principal position.
Similarly, in your people management Guild, Level 1 may be manager, level 2 may be director, etc.
More people may have the Level 3 Badge than you have staff engineering positions.
How Do You Reconcile Badges and Titles?
This is true of all roles, such as Guildmasters or full-time Guilds positions, and titles that may be limited due to budget.
Guilds and Badges should be where the bulk of your qualification goes in. The goal is to remove politics and make promotions as transparent as possible.
But, you may still find yourself in a position where you have five people with the level 3 Software Engineer Badge and only two staff engineer positions. There are a few ways you can handle this.
Seniority
The easiest, and maybe the first you’d like to roll out, would be simple seniority. Who’s been a Level 3 the longest should get the staff positions. This is a first-come, first-served sort of situation. It’s not always super fair and can be easy to game; but it’s predictable and transparent.
Points
A step beyond this might be for the Badge to have a point system. Certain activities are still required to get a level. Say, completing a training. But other actions are tracked and earn you experience points. Maybe you get one XP for every ten revisions in accepted PRs or one XP for every tech talk you do. Then you’d give roles to whoever had the right Badge level and had the most points.
You can combine this with the seniority solution above by saying each additional year in the level is worth some points. That will allow high performers to quickly outpace folks who are just “waiting their turn” without ignoring years of experience altogether.
Lotteries
You can also simply do a random assignment of all the qualified people. This, ironically, can often seem the fairest. People won’t be hurt if they weren’t selected because they know it’s not a reflection of their abilities or skills. Just a bad break.
You can combine lotteries with point systems to get the best of both. Perhaps you take the top three point-getters in our example above, then randomly assign them.
This can help people not focus too much on points but instead just try and be in the top-performing group. This limits the benefits of gaming the point system.
What NOT to do
The last thing you want is to allow the Guildmaster to give out titles as they see fit or allow people to vote for (or campaign for) the position. There needs to be a fair, transparent way to divvy out titles agreed on well before there are titles to give out so that people know the rules of the game.
“No, I mean, you know, how do Guilds interact with CAREER LADDERS??”
Okay, let’s talk about pay.
There are a few ways your Guild system can impact your compensation system. You’ll want to make the Badges particularly hard to game before considering this. There are some excellent benefits if you get it right.
First, let’s talk about incentives - paying people for having Badges will feel like an incentive system. But that’s not the reason you should do it. You’re not trying to incentivize getting Badges. You’re trying to keep the system fair by paying people with more skills proportional to what they bring to the party.
Be careful and recognize that the Badge and Guild system should only play one part in a more comprehensive compensation scheme.
Pay for Titles
The first obvious implementation would be what was implied above. Guilds have a certain number of title positions; those title positions may come with higher pay brackets.
This can make up part of the compensation scheme, and it’s honestly what most people expect. However, this will cause titles to become competitive (not that they aren’t already).
Pay for Badges
Another approach is to just pay for the Badges themselves. Badges are easier to earn; you don’t have to wait for titles.
A possible way to decouple the budget from this problem is implementing an “ideal salary” system. Your ideal salary is set by the number of Badges you have (plus several other things, like a 360 rating, etc.). Then, your raise is given in proportion to how wildly off your actual salary is from your ideal salary.
This would ensure people with more Badges earn more over time but don’t run into the “you can’t earn this Badge yet because we don’t have the money.”
Badge Bounties
An iteration on the above is to say different Badges are worth more than others. Perhaps all Badges at a certain level are worth the same. Yet strategically, you can add to the pot key Badges that the company thinks it needs.
This will get you those Badges filled in time, for sure. Though people need to understand when there’s no longer a bounty on a Badge, their raises may slow.
Another way to look at this is just being transparent - it’s not about incentives; instead, it’s about getting the skills you need. You would have to pay outside talent a higher rate to get them in the door for the Data Engineering skill. It’s naturally only fair to let everyone in the organization know that Data Engineering is paying better, and you need the skill. Badge bounties provide a way to convey that information.
Combo systems
Naturally, I always like a combination of many things, but it takes time to build a complex system. Start with something simple first - the simplest thing to do is not pay based on Guild/Badgework.
Once it’s mature and more challenging to game, you can start introducing title positions. Then, if that goes well, a general incentive for Badges overall.
Having different ways to win helps reduce gaming because there are fewer “competitors” using any particular strategy. An engineer who’s going to shoot for titles and another one happy just getting level 1 Badges will not get into a fistfight because they’re not competing for the same slice of pie.
Outside the Guilds
You don’t want your Badges and Guilds to be the only means to get ahead. 360 reviews on how much a person fulfills the company’s values and results-oriented checks on actual work output and quality should matter too.
How Do You Even Begin to Roll This Out?
I promised you at the top of this that we’d have a system that simplified all 5 steps to a learning organization, and now your head is probably spinning at the complexity of what I just described.
However, Badges and Guilds can be rolled out iteratively and incrementally.
Incremental here means only one Badge at a time. Iteratively means that the Badge may suck at first and get better over time.
Think about a core skill set you need more of and focus there. Then, focus on that first level. Get something that looks reasonable, and then get people to try it out. Learn from experience, and improve the Badge as you go forward.
Over time, you’ll need more levels in that Badge or more Badges overall. Make each of the decisions based on the latest available information.
Insofar as actual administration, your current managers/people managers can run the initial Badges until someone is ready to run it themselves. So start with the Badge system first. Keep a lot of the authority in your current management chain. This reduces the amount of change going on at once. Then, as you get qualified individuals, start delegating (as we described in Step 4) the administration of the Badges to them.
This rollout will help ensure you have the resources focused on the highest priority item at any one time and that you’ll be investing in growing it out as well.
Strategy Will Determine Where To Start
Your overall strategy will point you to what Badge to start with and how deep it needs to be at the end. But start with the simplest thing that can possibly work at first.
Over time, you’ll add Badges that help you achieve your strategy and add levels as you need them - again, based on your strategy. The topology that develops - which Guilds report to other Guilds - should also reflect your strategy.
But the strategy can and should change over time - this means that levels needed will change, Badges required will change, and who reports to who will change. Again, these changes should be applied iteratively and incrementally, not unlike refactors of code.
Conclusion
It’s been a long journey, and we’ve covered a lot of ground.
We’ve talked about training, mentoring, coaching, and delegating. We’ve talked about how to be a thought leader in the industry.
All of these things fit into your learning organization. How does your company learn about the market it sells into, learn about the technology it uses, and learn about itself in the process?
The holistic view of this can be daunting.
However, Badges and Guilds provide an out-of-the-box approach to implementing an organizational structure that will learn and teach.
Badges and Guilds are capable of a lot of complexity. And just like all complex systems, it’s easiest to start with a simple system and get it working, then iterate.
Think about your strategy. What are your priorities? Then, what’s the most minor iteration of the smallest increment you can do based on that? Focus all your efforts on that. Don’t build too broad, as too much cultural change is confusing.
This can be rolled out in companies of 4 people large up to 4000. It just may take time.
We may not operate a Guild inside your company, but we are trying to be the Guildmaster of your heart! Want to know how we can help you roll out Badges or Guilds? Contact us!
Or…
Click “Subscribe to the Soapbox” below for more!
.png)