Tag: Open Badges (page 2 of 9)

Why do we hire based on ‘experience’? HR, Automattic, and Open Badges

It’s 2016. Nobody can reasonably expect to have a ‘job for life’, or even work within the same organisation for more than a few years. As a result, you’re likely to dip into the jobs marketplace more often than your parents and grandparents did. That means it’s increasingly important to be able to prove:

  • who you are
  • what you know
  • who you know
  • what you can do

Unfortunately, hiring is still largely based on submitting a statement of skills and experience we call a ‘Curriculum Vitae’ (or résumé) along with a covering letter. This may lead to an interview and, if you like each other, the job is yours. We have safeguards in place at every step to ensure people don’t discriminate on age, gender, or postcode. Despite this, almost every part of the current process is woefully out-of-date. I’ve plenty to say about all of this, but will save most of it for another time.

In this post I’m particularly interested in why we include ‘job history’ or ‘experience’ when applying for new positions. Given that we have so little time and space to highlight everything we stand for, why do we bother including it? Academic credentials are bona fides, but job history is a bit more nebulous. Why is it still such a prominent feature of our LinkedIn profiles? Why do we email people CVs listing our ‘experience’?

Whether you think that looking at someone’s job history allows for a good ‘cultural fit’, or allows you to make assumptions about the network they bring with them, the reality is that we use job histories as a filter. They’re a useful shorthand. After all, if someone has been hired by Google or another big-name organisation, that’s a bit like saying they went to an elite university. We tend to believe in the judgments made by these kinds of organisations and institutions. We trust the filters. If the person was good enough for those organisations, we think, then they must be good enough for ours.

We like to tell ourselves that we live in a meritocratic world. If someone is good enough, so the story goes, then they can achieve the qualifications and experience necessary to get the job they want. Unfortunately, because of a combination of unconscious bias, innovation immune systems, and the new nepotism, some groups of people are effectively excluded from consideration. Don’t know the right people? Not good at interviews? Have skills too advanced or too new for qualifications to have been developed yet? Bad luck, buddy.

Another problem is that we tend to use what I call ‘chunky black box qualifications’ as proxies of the thing we’re trying to hire for. As an example, take jobs that require a degree ‘in any discipline’. What does that actually mean in practice? They want somebody who can think at a certain level, someone who is likely to come across as ‘professional’, someone who can submit work on time. However, we’re not directly looking at the assessment of the particular quality in this situation, we’re merely using an imperfect proxy.

There are many ways round the current status quo. For example, Automattic (the company behind WordPress which powers a lot of websites) does hiring very differently to the standard model. As outlined in this post, when hiring developers they test candidates in real-world situations through paid trials. In fact, as Automattic is a globally-distributed company, communication happens mainly through text. Most candidates don’t have voice conversation with anyone at the organisation until they’re hired! Obviously this wouldn’t necessarily work in every sector, but it is a good example of thinking differently: focus on what the candidate can do, not what they claim to be able to do.

Another way to approach things differently in hiring is to seek wherever possible to break down those ‘chunky black box qualifications’ into more transparent, granular, and fluid credentials.

For example, when I say I worked for Mozilla it usually piques people’s interest. I then have to go on and explain what I did during my time there. This isn’t easy given the amount of different things you do and learn in an organisation that you were with for three years. Yes, I had two different job titles, but I learned a whole load of things that would take time to tease out: working across timezones on a daily basis? Check. Learning how to use GitHub for development? Check. Consensus-based decision-making? Check.

Not every organisation is in a position to offer a trial period like Auttomatic. Nor would every individual be able to take up their offer. However, much as some people start off as consultants for organisations and then end up employed by them, there is value in getting to know people in a better way than the traditional CV and interview process allows. If we need better filters then we need smaller sieves.

For the past five years I’ve been working on Open Badges, a web-native way to issue trusted, portable, digital credentials. In the situation under consideration, I think there there are a few ways in which badges can be used to unlock those chunky black box qualifications.

  1. Granularity – instead of looking at qualifications that act as proxies, we can evidence knowledge, skills, and behaviours directly.
  2. Evidence – whereas LinkedIn profiles and CVs are a bunch of claims, Open Badges can include a bunch of evidence. Proof that someone has done something is just a click away.
  3. Portability – instead of credentials being on separate pieces of paper or in various digital silos, Open Badges can be displayed together, in context, on the web. They are controlled and displayed at the earner’s discretion.

I’m excited by the resurgence in apprenticeships and vocational education. I’m delighted to see more and more alternative ways organisations are finding to hire people. What I’m optimistic about most of all, though, is the ability for organisations to find exactly the right fit based on new forms of credentialing. It’s going to take a cultural shift in hiring, but the benefits for those who take the leap will be profound.

Image via Nomad Pictures

Calling out Pearson on Open Badges

Open Badges is a web-native credentialing system. It was incubated by Mozilla and I served on the founding badges team. Since then, stewardship of the project has been given to a spin-out non-profit called the Badge Alliance. I’m currently consulting on areas including Open Badges, meaning that, all told, I’ve been involved in the community for nearly five years.


You can find out more about Open Badges and how they differ from other digital credentials via the OB101 course.


There are some big players in the Open Badges space. One of them is Pearson, which you may find surprising. After all, why would an organisation best known for its rapacious business practices (and who some see as standing for everything currently wrong in education) get into the open credentials game?

The answer, of course, is to commodify it. They’ve taken a leaf from Microsoft’s old playbook: Embrace, Extend, and Extinguish. Pearson even have a page on their site explaining how they’re using different terminology just to spread FUD.

Pearson’s badging platform is called Acclaim. They have some big-name partners such as IBM and Citrix. Today, I noticed via the #openbadges hashtag on Twitter that they were singing the praises of the Open Badges ecosystem while pimping their own platform.

There’s nothing particularly wrong with that. Acclaim is technically compatible with the Open Badges Infrastructure (OBI). However, it’s entirely pointless that the badges they issue are Open Badges as users cannot export them from the system elsewhere. Given that Open Badges are portable digital credentials this kind of misses the point.

It’s true that Pearson have engaged with the community on this issue, but their justification seems spurious:

Real-time verification is essential for the clients we work with who are invested in building trust networks with their badge earners and other issuers. We fully expect the market to mature such that services like Mozilla will address this, but until then, we are not offering export / integration.

This is exactly the kind of response you would have found Microsoft giving 15 years ago when attempting to embrace, extend, and extinguish open document formats.

Growing sick of seeing Pearson’s disingenuous tweeting on the #openbadges hashtag, I challenged them today:

They held the line:

https://twitter.com/YourAcclaim/status/697785850273206273

Note that they don’t care about the spirit of the community or the ethos behind Open Badges, just the cold, hard code. As far as they’re concerned, they’re technically compatible with the OBI, therefore they’re part of the Open Badges community. This logic doesn’t wash with me.

I’m calling for Pearson to get their act together and allow badges issued via their Acclaim platform to be portable. Credly have the exact same business model as Acclaim, yet their ‘credit’ can be exported to the Mozilla backpack and elsewhere.

If Pearson aren’t willing to allow their badges to be portable, then they should have the guts to stop pretending that they’re interested in the success and sustainability of Open Badges. Muddying the waters doesn’t help anyone except Pearson’s profits.

Parody of Acclaim website thanks to the wonderful X-Ray Goggles

The Possibilities of Badges and Blockchain [DML Central]

My latest post for DML Central has just been published. Entitled The Possibilities of Badges and Blockchain it’s a follow-up to a post I wrote for them last year, which stated that this kind of thing was ‘deep in the future’. Perhaps not!

Read the post

This kind of stuff fascinates me, which is why I’m delighted that a few ex-Mozilla colleagues and interested parties have come together to form Badge Chain. You can sign up on the site for (low-traffic) email updates, and/or subscribe to our Medium publication.

What a post-Persona landscape means for Open Badges

Note: I don’t work for Mozilla any more, so (like Adele) these are my thoughts ‘from the outside’…


Introduction

Open Badges is no longer a Mozilla project. In fact, it hasn’t been for a while — the Badge Alliance was set up a couple of years ago to promote the specification on a both a technical and community basis. As I stated in a recent post, this is a good thing and means that the future is bright for Open Badges.

However, Mozilla is still involved with the Open Badges project: Mark Surman, Executive Director of the Mozilla Foundation, sits on the board of the Badge Alliance. Mozilla also pays for contractors to work on the Open Badges backpack and there were badges earned at the Mozilla Festival a few months ago.

Although it may seem strange for those used to corporates interested purely in profit, Mozilla creates what the open web needs at any given time. Like any organisation, sometimes it gets these wrong, either because the concept was flawed, or because the execution was poor. Other times, I’d argue, Mozilla doesn’t give ideas and concepts enough time to gain traction.

The end of Persona at Mozilla

Open Badges, at its very essence, is a technical specification. It allows credentials with metadata hard-coded into them to be issued, exchanged, and displayed. This is done in a secure, standardised manner.

OBI diagram

For users to be able to access their ‘backpack’ (i.e. the place they store badges) they needed a secure login system.Back in 2011 at the start of the Open Badges project it made sense to make use of Mozilla’s nascent Persona project. This aimed to provide a way for users to easily sign into sites around the web without using their Facebook/Google logins. These ‘social’ sign-in methods mean that users are tracked around the web — something that Mozilla was obviously against.

By 2014, Persona wasn’t seen to be having the kind of ‘growth trajectory’ that Mozilla wanted. The project was transferred to community ownership and most of the team left Mozilla in 2015. It was announced that Persona would be shutting down as a Mozilla service in November 2016. While Persona will exist as an open source project, it won’t be hosted by Mozilla.

What this means for Open Badges

Although I’m not aware of an official announcement from the Badge Alliance, I think it’s worth making three points here.

1. You can still use Persona

If you’re a developer, you can still use Persona. It’s open source. It works.

2. Persona is not central to the Open Badges Infrastructure

The Open Badges backpack is one place where users can store their badges. There are others, including the Open Badge Passport and Open Badge Academy. MacArthur, who seed-funded the Open Badges ecosystem, have a new platform launching through LRNG.

It is up to the organisations behind these various solutions as to how they allow users to authenticate. They may choose to allow social logins. They may force users to create logins based on their email address. They may decide to use an open source version of Persona. It’s entirely up to them.

3. A post-Persona badges system has its advantages

The Persona authentication system runs off email addresses. This means that transitioning from Persona to another system is relatively straightforward. It has, however, meant that for the past few years we’ve had a recurrent problem: what do you do with people being issued badges to multiple email addresses?

Tying badges to emails seemed like the easiest and fastest way to get to a critical mass in terms of Open Badge adoption. Now that’s worked, we need to think in a more nuanced way about allowing users to tie multiple identities to a single badge.

Conclusion

Persona was always a slightly awkward fit for Open Badges. Although, for a time, it made sense to use Persona for authentication to the Open Badges backpack, we’re now in a post-Persona landscape. This brings with it certain advantages.

As Nate Otto wrote in his post Open Badges in 2016: A Look Ahead, the project is growing up. It’s time to move beyond what was expedient at the dawn of Open Badges and look to the future. I’m sad to see the decline of Persona, but I’m excited what the future holds!

Header image CC BY-NC-SA Barbara

3 reasons open source needs Open Badges [opensource.com]

opensource.com

A few months ago, my friend and former colleague Laura Hilliger encouraged me to write something for opensource.com. She’d had a few posts published about the benefits of working openly.

Today, Bryan Mathers and I have had published an article that goes into why Open Badges are such a good fit for open communities.

The web is the perfect medium for a new credentialing system. Just like the web, Open Badges are democratic, open, and distributed. The OBI is itself open source, as are many badge issuing solutions found on GitHub and other code repositories. Open Badges help move forward the open web.

Read the post in full: 3 reasons open source needs Open Badges

I’m closing comments here to encourage you to add your thoughts on the original post.

The New Nepotism

Nepotism in action

Nepotism in action

Nepotism is a word which is ordinarily used pejoratively. That is to say, nobody wants to be accused of it.

nepotism, n. unfair preferment of or favouritism shown to friends, protégés, or others within a person’s sphere of influence.

The old version of nepotism was guilty of saying, “You’re my friend from the tennis club so I’m going to give you this unrelated opportunity”.

People were given jobs independent of aptitude or talent. It was all about connections and relationships within a very small network. It’s the reason sinecures were so common until the mid-20th century.

Nowadays we like to think we live in a meritocracy. Despite the modern origin of the word being satirical, we equate being meritocractic with ‘fairness’. We’re probably correct in that assumption.

However, the hiring practices this has led to are sub-optimal. I’m not sure there’s a single person who would design the system we’ve got if they were doing so from scratch.

Yes, it’s illegal in many jurisdictions to even ask on an application form about someone’s age, gender, race, or sexual orientation. This is a step forward for equality. Great! The really sad thing is that it often leads to bland mass of undifferentiated application instead of truly embracing diversity.

As a result, for better or worse, people have found ways to bypass stifiling recruitment practices. The New Nepotism says, “You’re my friend / former colleague from a previous project/organisation. We successfully created something awesome together, so I’m going to give you this related opportunity.”

I’m guilty of having received opportunities through New Nepotism. I’m also guilty of giving them. My point with this post is to say that we’ve got a twin-track system where one track is the direct result of the other. We look for colour and diversity through relationships that we’ve already established because CVs and application forms are so limp and lifeless.

Perhaps we could move beyond New Nepotism through a system like Open Badges? No two human beings are truly alike, so why should their credentials? As soon as we have a system that truly captures the value of people’s experiences, then we can hire based on talent and experience rather than who you’ve already happened to work with and know.

Image CC BY-NC Andy B

Why the future remains bright for Open Badges

Some context

I first stumbled across Open Badges in mid-2011. I immediately thought the idea had revolutionary potential, and began evangelising it to anyone who would listen. Happily, this led to me being asked to fly to San Francisco to judge the DML Competition that initially seed-funded the ecosystem. There, I met Erin Knight in person, and subsequently accepted a position on the badges team at Mozilla.

It’s hard enough building a start-up. So you can imagine what happens behind the scenes when you’re trying to build a brand new global ecosystem. It wasn’t all rainbows and unicorns. From what I understand, things got even tougher after I moved teams at Mozilla to focus on web literacy work in late 2013. My former colleagues formed the Badge Alliance, initially funded by the MacArthur Foundation.

While I was aware of some of what went down at the end of 2014, it’s only been later in small group conversations that I’ve been able to fill in the gaps. All was not what it seemed in badge land. Politics and personalities threatened to shipwreck the nascent badges community. It was a delicate balance: people deserved to know some of what was going on, but negative press could have unduly ‘scared the horses’.

Thankfully, I didn’t have to be the one to write the post that Kerri Lemoie published this week to coincide with this weekend’s Mozilla Festival:

Mozilla is Doing a Hack Job on Open Badges

In the couple of days since Kerri’s post I’ve seen some chatter on social networks. Some people seem to be worried about the long-term viability of Open Badges. Not me. For two reasons.

1. Open Badges is a open source project

The first is that Open Badges is, as the name suggests, an open source project. The great thing about this development model and approach is that, ultimately, it belongs to everyone and no-one. There are occasions when a person, group, or company might assume leadership. However,  but that can (and does) change over time. If there’s ever a time when a significant enough group within an open source project disagree with the direction it’s heading, they can fork the project.

2. The Hype Cycle predicts what’s happening

The second reason comes courtesy of Gartner Hype Cycle. It’s a way of understanding the “maturity, adoption and social application of specific technologies”:

Gartner Hype Cycle

According to Gartner’s 2015 education report (paywalled, but there’s a summary here), Open Badges is right at the top of the Peak of Inflated Expectations. As tends to happen as technologies mature, Open Badges is likely to slide into the Trough of Disillusionment in 2016. This is to be expected. In fact, according to Gartner, it’s necessary in order to reach the Plateau of Productivity.

Now look again at the hype cycle diagram. At the start of the Slope of Enlightenment it reads ‘Second-generation products, some services’. Over the last few months there’s been some discussion about pairing Open Badges with the blockchain technology underpinning Bitcoin. Back in March I wrote a post to that effect, there have been some noises in the Google Group, and (excitingly) and MIT have just launched a similar-sounding project.

Conclusion

So I’d say the future remains bright for Open Badges. It has experienced the growing pains as any truly innovative technology will suffer. 2016 might be rough for the community.

However, we should bear in mind that the hype cycle can describe a full 10 years from conception to mainstream. If that’s true of Open Badges then we can expect full adoption to happen around 2021. So, between then and now, there’s a bunch of us who need to roll up our sleeves, and do the work.

This stuff is too important to be a mere ‘bridging technology’. For some of us it could be some of the most significant work we do in our careers. Open Badges is what we make it. Let’s get on with building the future!


Double rainbow photograph CC BY-SA Eric Rolph. Added badge image presumed fair use from badgerank.org.

Open Badges location extension

I’m delighted that, thanks to some help from Kerri Lemoie, the Open Badges extension for geolocation that I proposed is now available for use. It was simple enough to do the initial coding following the following the example using JSON-LD but Kerri (and Nate Otto)

Details of how Open Badges extensions work can be found in this post I wrote for DMLcentral. It explains how version 1.1 of the specification allows for great things through extensions.

At the time of writing, the following extensions are now available:

  • Apply Link — provides a URL allowing potential badge earners to apply for an opportunity specified by a badge issuer.
  • Endorsement — allows a third party to publicly acknowledge the value of a badge designed, assessed, and issued by a particular issuer.
  • Location — allows for the addition of the geographic coordinates associated with a badge.
  • Accessibility — allows for the addition of content for people with disabilities.
  • Original Creator — provides a way to track the origin of a badge when one organisation creates it for another.

I’m really pleased with all of this and delighted that the Open Badges ecosystem has a bright future!

Image CC BY-ND Bryan Mathers


If you’re interested in designing badge systems and think I might be able to help, please do get in touch via my consultancy, Dynamic Skillset. I have reduced rates for third sector organisations such as charities, non-profits and educational institutions.

Taking Another Look at the Digital Credentials Landscape [DMLcentral]

Taking Another Look at the Digital Credentials Landscape [DMLcentral]

My latest post for DMLcentral is up. Entitled Taking Another Look at the Digital Credentials Landscape, I attempt to clear up some confusion in the Open Badges landscape about various terms.

Here’s an excerpt:

In the early days of talking about Open Badges, I feel that we conflated several important points: the ability to issue micro credentials, bypassing traditional gatekeepers to learning, and the Open Badges standard itself. What I’ve tried to do in this post is, to some degree, begin to tease these apart. The important innovation is the interoperability and standards-based approach.

I’ve closed comments here to encourage you to leave them on the original post.

Click here to read in full on DMLcentral

 

Towards a visual hierarchy of Open Badges

This week I’ve been working with a client on the first stages of a visual hierarchy for Open Badges. This is more complex than it sounds and there are a couple of things that you should have a look at before reading further. The first is Carla Casilli‘s post A foundational badge system design, and the second is the Badge Studio* created by Andrew Hayward during his time at Mozilla.

Badge Studio

* This is an Open Source project and can be found on GitHub here.

What I like about the Badge Studio approach is that it:

  • is easy to use
  • has a visual hierarchy baked-in
  • makes it very difficult not to follow a style guide
  • removes the bottleneck of visual badge design

Variables

As with everything, the simpler and more intuitive something looks, the more work has gone into it in the first place. Here’s some variables we identified for badges across the group of companies of which my client is part:

  1. Organisation
  2. Badge name
  3. Badge yype
  4. Icon/glyph
  5. Level
  6. Logos/brand
  7. Pips (as on military insignias)
  8. Expiry
  9. Meta status (i.e. whether it’s part of, or is a meta-level badge of badges)

Differentiators

I’m sure there are others to consider, too. From there we looked at the most obvious differentiators, deciding upon shape and colour. Happily, there’s already a defined colour palette in place for each organisation that’s part of the group. They’ve also just launched a new group identity that includes five different shapes! Perfect.

Text

We agreed in the preliminary meeting that we’d try and reduce the amount of text on the badge itself. This was for two reasons: (i) users should only ever be a click away from the metadata contained in the badge, and (ii) text is likely to be difficult to read if the badge is displayed at a small pixel size.

Complexity

Theoretically, every badge issued could be both a ‘meta-level’ badge made up of smaller badges and itself part of a larger ‘even-more-meta-level’ badge. It’s potentially turtles all the way down. To prevent this potential/perceived complexity, I’ve proposed we limit the number of layers to three. This chimes well with Carla’s work mentioned above. In practice, this leads to very simple and straightforward badge pathways – which, if you want, get way more complex.

Conclusion

Creating an ecosystem of value is an extremely difficult thing to do. Essentially, you have to have to create enough productive ambiguity for it to be flexible and adapt to different contexts, while simultaneously giving people enough structure to get started. The way I’m proposing we approach that in this example is to:

  • Nail down badge colour (organisation) and badge shape (type)
  • Place a limit on the number of badges that can count towards a meta-level badge (perhaps six, using Trivial Pursuit as a metaphor?)
  • Keep iterating on the taxonomy we’ve started.
  • Look into what makes a good icon for an iOS/Android app (they rarely include text)
  • Consider where/how to show both my client’s brand and the brand of any organisation they partner with.
  • Create/keep a list of badge display requirements that are separate to the badge itself (e.g. how ‘expired’ badges look within a profile)
  • Look into forking Badge Studio to create a version for my client’s group of companies.

If you’ve got examples of a good hierarchy of visual design for Open Badges, I’d love to see it! 🙂


PS You’ve completed my 2015 reader survey, right?

css.php