The Setup
I worked at a company that had a great L&D team setup. They developed a lot of internal training on their Learning Management System (LMS), which was augmented by a large number of instructor led training (ILT). There was a wide range of training, from regulation mandated compliance, to new hire onboarding, to skills development. Luckily we were well supported by an engaged group of trainers with backgrounds ranging from training consultants to formally trained teachers.
Tracking was mainly done through the LMS, and was easy enough since that system was setup to track things like log ins, who watched what, and what quiz scores we got. A number of built in reports provided basic output we could share with the business. The ILT, whoever, proved to be more of a challenge. While we could get an idea of knowledge retention by sending out quizzes or follow ups, keeping track of who actually showed up was more of a challenge.
Generally paper attendance was taken, which works…. To an extent. This was compounded as we had multiple locations that had to report back, forcing us to rely on folks outside the team to scan and email us attendance sheets. Cheating was also a concern, as you could write down anyone else’s name and then claim they were there. Given the highly regulated area we were in, this could result in significant consequences if we were caught.
The Eureka Moment
While thinking over this problem I had a “no-duh” moment that led to an eventual solution - every employee has a security badge, why can’t we just use those to log into class? I knew our security system could record badges when someone opened a door, including who it was, when it happened and which door. I didn’t see any reason we couldn’t do this for in-person trainings, now I just had to figure out how it could be done.
I knew other companies had dedicated training rooms (lucky), which would have made this easy. All we would have do was get folks to badge into that training room and they knew who was there. While we did have a number of rooms large enough to hold dozens of people (frequently needed for mandatory training), we were not lucky enough to have dedicated training spaces. This was further compounded by having multiple locations.
My general idea was to have some kind of website setup that folks could swipe their badge into and record their attendance. This would remove the need for paper (messy and easy to make a mistake), as well as the risk someone would write in someone else’s name (one individual did try to badge in their entire team at once, which we quickly shut down). The only challenge was I didn’t have was the hardware to scan the badge or the software to process the information.
The Challenges
There were three challenges to overcome, two technical and one cultural. On the technical front I had to figure out how to allow someone to badge into a class, and then how handle and process their scan-in. The first required a hardware approach (some kind of badge reader), and the second a software approach (some system to take that persons scan-in and put it somewhere). On the cultural front we had to get buy-in from leaders to socialize this amazing new product, and from individuals to properly use it (e.g. not send one person to scan in their entire team).
The Hardware
The Security team owned our badging system, so I started my quest there. Their first recommendation was to have the Learning team pay to put a badge reader on EVERY conference room. Now this would solve our challenge, since it would collect badging information when someone badged in… and it would also cost a LOT of money that we didn’t have (our budget was basically $0). This approach would also only tell us that someone badged in at a certain time, not information about WHY. For example, without additional work we wouldn’t know what class they were attending, or who was teaching it, both data points we were interested in.
Their next suggestion was to use a USB badge reader. This sounded like a great idea, but unfortunately they didn’t know exactly which one we should get. After a few failed Amazon purchases we reached out to the contractor who setup our system originally. Without nerding out TOO much, the badges were made by a company called HID and go by the “Prox Card” brand name. These cards can be programmed with any one of 137 billion unique codes, which is great if you have 137 billion employees, and slightly more of a challenge if you’re looking to read them. We eventually figured out there are multiple ways to encode the card, for example, you can include a building number, as well as a unique ID for an employee, in the code. The card readers have to be setup to read the number properly, if not, they’ll grab the information incorrectly (something I ran into during my initial testing).
In this sample card number the first three digits (110) could mean building #110, while the last 5 (72956) could be the unique ID for that individual.
11072956
Unfortunately the USB card readers don’t know this out of the box… resulting in them reading the entire number as the employee’s ID. The cards do have the number printed on the outside, so I was able to verify the number the reader was picking up was the correct one. This, however, did not help me figure out what the numbers actually meant.
Fortunately our contractor was able to help us untangle this and gave us a configuration file that we could write to the card readers. This ensured they properly read our badges, and meant we could quickly update new card readers ourselves. We ordered a few readers for each location, and made sure the local L&D folks knew where they were (they aren’t cheap!). This took care of how to get an employees badge ID off their badge.
The Softer Side
Oddly writing the software for this turned out be easier than wrangling the badge readers. I discovered that Google Suite (gMail, Slides, Sheets, etc.) has a scripting language called Google Apps Script (GAS), which is based off of JavaScript. Not only was there more documentation available online, but there are massive communities online to reach out to for help (unlike our badge readers, which required a consultant to come in and help out).
GAS allows you to perform virtually anything a human can do via a script. Need a Form to update a spreadsheet, perform some calculations, then email someone and wait for a response? GAS can do that. Need a button you can push to reformat an entire Slides presentation? GAS has you covered. Need a Sheet to open a webpage and collect badging information? GAS serves up HTML and CSS.
Unfortunately while I had some basic coding classes back in the day, I knew nothing of coding (well, I knew it was a thing, in the same way I know quantum mechanics is a thing). Fortunately I had two advantages - a manager who wholly supported this project and the firm belief that I wasn’t trying to do anything groundbreaking. Having my manager’s support was essential as it legitimized any time or energy I put towards this project. Since this was a prioritized project, this also allowed me to push back against other demands on my time and gave my some great backup in the form of my manager getting folks off my back.
Understanding that this project didn’t present truly novel problems to humanity helped me keep my focus and feel from being overwhelmed. At the end of the day all I was doing was taking a number, looking up a name and displaying something on a website. Sure, the number came from an ID card, but everything about this was what I called a “solved problem”; everything I was trying to do had already been solved by someone, somewhere. This understanding gave me a great “out” any time I got stuck - just look it up online.
The challenge with looking things up is knowing what to actually type into Google/your library/whatever to find what you want. Since my background isn’t computer programming my biggest challenge was not having the correct words to describe problems. This resulted in a lot of wasted time at the beginning, but helped expose me to a wide range of ideas as I tripped over things and generally beat me head against the keyboard until something worked.
Culture Wars
Getting buy in to use the tool was the easiest part. No one likes doing paper attendance (citation needed), and this is doubly true at tech companies. After all, if we’re surrounded by really smart people who can code new apps and discover new solutions, why are we stuck using technology invented in the first century?
The cultural challenge we ran into was enforcing some simple rules, like “You can only badge in yourself”. This came around after several teams sent one person “ahead of everyone else” to badge in the entire team. We avoided most of these challenges by getting managers and directors buy-in to help enforce behavior. We also told our front-line trainers to push back on anyone trying to break the rules, and, more importantly, they we had their backs if anyone complained.
Deployment
Eventually I got to a place where I had a working prototype which I felt comfortable showing my team. Getting feedback was an important part of this tools life, mainly because I wouldn’t be the one using it on a daily basis, but also because my background wasn’t in running corporate training. I got several great suggestions, such as having the tool accept an email address in case folks didn’t have a badge, or also recording the instructor and name of the course that someone badged into. These reviews did take time, but at the end of the day they made a much stronger tool.
We had a large (400+ employee) compliance training coming up and saw it as a great opportunity to field test the tool. We decided not to say anything to the trainees or their managers, and instead just setup a table with a computer, badge reader and someone to check folks in. Everyone up until now had been conditioned to sign in on paper, something they really didn’t like since it was one, slow, and two, annoying. We weren’t sure what the response to the tool would be, but figured it couldn’t be worse than signing in on paper.
We were amazed at the response.
Several folks who badged in wanted to get their hands on the tool for other events their team ran. Several Directors immediately wanted to know how they could blend this information with other learning systems to see how their teams are performing (e.g. if Sally shows up to training, do her sales numbers improve?). Many of them asked where we had bought the tool from, and were quite surprised when they learned it was home grown.
Overall, the tool was a hit. We got some great feedback on how to improve it, and after a few modifications and testing, we deployed it to all our locations to track attendance. Not only did we entirely remove the annoyance and inaccuracy of paper based records, we drastically improved our reporting capabilities and built great relationships with internal teams.
Lessons Learned
Find pain points - Everyone has something that bugs them about how they do their job. A screen loads slowly. They have to get 15 approvals to go to lunch. Bob in accounting refuses to sign off on something with a $.01 difference. When folks are first exposed to these pain points, they tend to either complain a little bit and then stop, or just assume that’s part of reality and accept it. Over time, we learn to deal with them and they don’t seem so bad… but they are. Take the time to talk to your coworkers about what could go better, and then go do it.
Get buy in - Once you’ve IDed some pain points, talk with your team/manager and get their feedback and buy in to tackle one or two. Notice it’s one or two, not ALL of them… you really want to sell the lowest hanging fruit, something you can knock out of the park with a bit of work. Getting buy in makes it much easier to get help from others, and makes your goal much more legitimate to others.
Jump in - Once you’ve got buy in, jump in! The solution may not be a straight line… but those are boring anyways. Going into it I wouldn’t have been able to tell you I’d end up learning how to write JavaScript, but also learned how our ID badges work. Take the time to understand the challenge, and give yourself space to explore the options.