Knowing when to go "quick and dirty"
Sometimes there isn’t time or bandwidth or energy to do everything you “should” do. Knowing when, and how, to do something quick and dirty is critical to successfully pulling it off.
We’ve all been in situations where we know the “correct” or “best” way to do something, but not had the time/money/energy to go that route. Instead, we look for something that will still get the job done, but may not be as clean…. The “quick and dirty” method.
While we generally want to avoid going quick and dirty (it is, after all, both quick… and dirty) there is an argument for it being useful. Our standards and best practices certainly exist for a reason; experience (ours or others) tells us the best way to move forward. There are, however, times when we are unable to follow best practice, or when following it would result in negative consequences. These are the times when using a quick and dirty solution can be beneficial.
Making a decision to essentially ignore best practice and go this route shouldn’t be taken lightly. You, and everyone you interact with, needs to understand the tradeoffs. Generally there’s a higher risk of error and the end product may not be as robust as it would be had you followed the proper channels. Getting buy in, or at least ensuring everyone knows what the tradeoffs are, is absolutely critical to this route. You could go it solo, however, eventually others will notice that it wasn’t quite done “right” and will start asking questions.
Generally the quick and dirty approaches also necessitate additional testing or oversight to ensure something critical wasn’t missed. This degree of oversight may not be required with the best practices route, but is here since you’re basically cutting corners (hopefully the right ones!). You’ll need to ensure you’ve got extra bandwidth or support to help minimize the risk of problems showing up.
This approach can definitely help get things done… at least if you keep a close eye on things and know what you’re doing. My best advice when choosing to go this route is to ensure everyone on the team is aware that you’re choosing it. This has a few advantages, including getting more eyes watching out for issues and helping explain any odd side effects.
The biggest takeaway is to ensure you’re making the “quick and dirty” decision for the right reasons and that everyone is aware of your choice. Ideally you’ll never need to use it, but if you do a bit of planning can help save the day.
Domain Expertise
Knowing the system is absolutely necessary to supporting it. Know the domain it exists in, however, vastly improves our ability to manipulate and design the best way to use that system. Take time to learn that domain, meet the experts in it and if you can, become one.
In the tech world we tend to focus on learning the tech. Those of us working on any given system or tool want to drill into how it operates, what features it has and when they should be used. This is true for NetSuite, or AWS, or InfoSec. And there’s nothing wrong with making technical skills a focus of our job; after all we ARE the systems folks!
Learning technical skills, however, shouldn’t (can’t!) be all we focus on. We also need to stretch ourselves to understand the domain our systems exists in. For SalesForce this would involve learning how sales teams operate. What does any given Sales rep need to do or know on a monthly/week/daily/hourly basis? Why do they (dis)like any particular aspect of SalesForce? What policies does the Sales team have to follow?
While certainly not directly related to the system, questions like this help inform WHY and HOW the system can be used. We don’t need to know as much as our customers about their process, but the more we know, the better we’ll be able to support them (personally I became a license health care broker to help accomplish this).
Gaining Domain Experience
There’s many ways to help expand our domain expertise. The simplest is simply through osmosis. As we work on any given system, we’ll naturally learn a bit about the domain it exists in. Working in NetSuite, for example, will expose us to charts of accounts. SalesForce will expose us to a closing process. Workday will expose us to hiring. This is a natural first step for many folks since it’s basically impossible to miss; you can’t learn the system without picking up SOMETHING. That said, this is only the beginning.
Getting to know your customers is another way to improve your domain knowledge. Get them involved in testing, or have them show you how they use any particular screen. Sit in on their team meetings and get a feel for how the team behaves. This first-hand experience has several advantages, including giving you more domain expertise, but also helps build connections and puts a face to everyone. Knowing Jimmy in sales is much more impactful than knowing some random user has problems.
Training like your customer-base takes this a step further. Go and get whatever certification or accreditation they need (like my example of becoming a certified benefits broker). This will not only extend your baseline knowledge of that particular area, it will help you see things the way they do. In the care of a credential or training you’re also rounding out your own experience and possible exposing you to new concepts. This has the added benefit of (generally) getting you some street-cred with your customers.
Going even deeper you could even BECOME your customer. I very rarely see folks taking this path since it is very intense and time consuming… but it does offer the most in-depth way to gain experience. For example a software engineer might choose to implement a live customer, or a Salesforce rep may take some inbound calls. While this does crank up the intensity a bit, it will really help show you what’s important, or annoying, or impactful for your customer base.
While there’s nothing wrong with not taking these steps, I find they help individuals make better informed decisions and allows them to develop better solutions to challenges. Flexing ourselves this way also has the side-effect of helping us build better relationships, and learn something new about our tool.
On Forests
Keeping an eye on details is important, but understanding how it all comes together, and how those details interact with everything else, is equally critical to success.
While it can be incredibly gratifying and satisfying to immerse oneself in details, keeping an eye on the bigger picture is also incredibly important to success. Not only does understanding how your contributions fit into the grand scale help you understand your work, it also helps you identify and correct potential problems. The challenge is remembering to look up every once in a while and seeing what the spread looks like.
Zooming out
One pitfall many folks fall into is assuming that your manager/director/leadership will be the ones to handle the big picture. They do, after all, sit behind a Bigger Desk. In many ways this is not a bad thought or approach; it’s literally their jobs to concern themselves with the big(ger) picture. This, however, doesn’t excuse those of us working on the details from also understanding, at least to a small degree, that larger picture as well. This expectation also goes both ways; those leaders are also expected to understanding, at least to some degree, how the details work.
Ensuring everyone involved is at least aware of the greater picture has a number of benefits -
Seeing how your contribution fits in - Knowing that the really boring and tedious spreadsheet work you do will help drive down cost, or make someone else’s life better makes it MUCH easier to accept that work. Not having this knowledge can result in you internalizing negative feelings around it.
Avoiding potential problems - Knowing where a project should be headed ,or what it is intended to do, can help you sniff out potential problems before they show up. This can take the form of helping you rule out specific approaches, altering leadership to specific things and more.
Broaden skillsets - Most of our time is spent in our specific areas of focus (which is good, it’s why we’re there!). Getting exposure, and awareness, to the greater picture helps us expand our skillsets, understandings and connections. This, in turn, rounds us out and helps us be better at our specific area of focus.
Finding ways to keep an eye on the bigger picture can seem daunting… after all, most of the we’re just focused on our small area of the project. There are some easy ways to see what else is going on at other levels:
Just ask - The simplest way I’ve found to learn about the higher levels is just to ask. Ask around your team and see what you can learn about your project.
Get involved - Similar to asking, get involved with other aspects of your project. If you’re a sales specialist maybe get time with the operations team to see what they’re doing. If you’re on the tech side, talk to Finance. Something as simple as attending one of their status meetings, or asking them to show you their system can give you a great idea of how they operate.
Annnd a bit further
While learning about the greater forest does take some time and energy, the return is more than worth it. Not only will you get to expand your own skillsets and knowledge, you’ll also help keep the project moving in the right direction. So go ahead, take a moment to stop looking at the trees and see the forest.
On trees
Keeping details in mind is incredibly important in life. Without them we can never really be sure what we’re doing… unfortunately many times though, we lose sight of this and suffer for it.
Details are important, it’s where the devil is (citation needed). Details are what allow a plan to come into focus and and idea to have impact. Without them we cannot fully shape what we’re working on, and can never really be sure we’re done with our task. Despite this, we frequently fail to fully understand the details on what we do. We embark on tasks without taking the time to fully examine the minutia that defines our work. Instead, we focus on the higher-level portions - concepts, ideas - that rely on the detailed work to really stand out.
On one hand I can completely understand the desire to avoid really getting into the details… it’s tedious. It can be boring. It takes time… and there’s SO much of it. Even what seems to be a “simple” project contains a ton of details when you zoom in. Asking questions like “who do we talk to about X”, or “what specific steps are needed to complete this task” makes those “simple” projects seem more complex… after all, we started with just installing a new piece of software, why does that have more than one step?
While it is true getting into details can make projects seem to stretch out, the time is more than worth it for a number of reasons.
Understanding the whole picture - Taking time to understand the details helps flesh out the entire picture you’re looking at. It’s similar to looking at a painting and noticing something new… suddenly you understand a new perspective on what the artist wanted to capture.
Avoiding pitfalls - Knowing the trap is there is the first step to avoid it, and investing energy in the detail work will help uncover potential problems that may have otherwise remain hidden. While identifying and planning for these challenges adds more time to your calendar, it will pay off by avoiding the need to fix those problems later.
Improving your skills - Getting into the details also helps you expand your skillset. You’ll find things you didn’t know were there, or connections suddenly become obvious. Like any skill, over time you’ll also get better at defining the detailed work, which will reduce the amount of time it takes to reap the benefits of this exercise.
On the other hand, however, I find it baffling when folks consciously avoid the details. I’m not suggesting that everyone involved in a project needs to be at the most granular level (indeed, executives need to exist at a high level and tend not to have time for detail work), but the project as a whole needs to be aware of details. Even something as simple and double checking settings on an email account should not be taken for granted (unless you want the whole company to see what’s in there…).
You can always take 15 minutes to kick around your projects details with your team. Ask them what’s missing from the plan, and then go find that devil.
No Extra
Not doing extra on a task is hard… we always find something we can add, or something that was “missed”. Doing this, howe ver, distracts us from the actual task. At best it results in a weaker final product… at worst, complete failure.
Extra, in some cases, is good. Extra guac? Please. Extra time to sleep in? Sure. Unfortunately on a project, extra can be bad. At best adding extra to things distorts our view of the request and makes it easy to lose sight of what is actually needed. At worst it totally derails a project and diminishes its value to your customer.
Adding extra into our work does several things… some obvious, others much less so. I find that instead of making things better or providing a better output, these additions detract from my deliverable. Here’s several ways how:
Energy drain
Working on extra stuff that is “better” than our objective distracts us from what we should be doing. We can tell ourselves we’re helping, or that we can make up the time, or that the actual request is easy to do, we’re just making it harder to complete our objective. At best we end up putting less energy into our objective, which results in risk that we missed something important, or that the product isn’t as strong as it could be.
Diffused Focus
Working on extra necessarily pulls our focus away from what we should be doing. Instead of critically examining our request for potential flaws, we’re day-dreaming about something unrelated. This split focus allows us to make mistakes we otherwise would catch. Even worse, this can result in less time to figure out the “extra” we thought was so valuable… so instead of delivering what was asked we deliver one thing that was asked that may or may not work, and another thing that wasn’t asked for of questionable use.
Missed Target
Working isn’t done in a vacuum, and we as individuals (and sometimes teams) can’t know everything. When we make a choice to add extra to a request we’re gambling that we know what’s “best” or “right”. While we might get lucky and deliver something that is, in fact, useful or valuable, what happens if we’re wrong? Suddenly we have to explain why we wasted time NOT working on what someone wanted to build something that’s useless.
I find it fascinating how hard it is to only do what is asked, and nothing more. It should be an incredibly easy thing to do, but the allure of making it “better” is very hard to resist. As funny as is it to say, it takes discipline to stay inside the lines. It is true there will be times when we can push on those lines, and sometimes help redraw them, we need to be very careful not to wander outside them. Doing so distracts us from our objective, and instead of building us up, only tears us down.
Conceptually speaking...
Rote mechanical skills are essential to learning, but at a certain point the underlying concepts become more important. Knowing how a tool works, or why something is done a certain way is an incredibly powerful skill, and one that takes conscious effort to build.
Learning a new thing is always a process. We begin by learning rote skills, the mechanical movements necessary to reproduce a specific result. Then we progress to application of those mechanical skills, and eventually end up learning underlying concepts in whatever it is we are doing. Take writing for example, we first learn how to physically hold a pen or to use a keyboard, then we learn how to make letters appear (so much tracing!), then onto making words appear, then sentences and finally paragraphs. Once we have mastered those basic mechanical skills, we move on towards applying them to novel situations - writing new things.
This general progression appears everywhere. In the martial arts we begin learning how to stand, or how to breathe, or how to focus where we’re looking. These are then built into more complex moves, how to punch or kick, and then strung together into sequences of movements called forms. Once we understand those basic building blocks we can compose any series of movements we like.
Professional skills are the same - we learn what the various buttons do on a machine we operate, then we learn how the machine works, and eventually we’re making widgets. We learn how to perform basic tasks, we teach others those tasks, then we get to define what those tasks are.
Where I find it becoming interesting is after we’ve learned those mechanical skills and what we get to do next. Must we ALWAYS have at least 3 sentences in a paragraph?
What happens if we don’t?
Must we ALWAYS turn to the left after a specific kick in a form? What happens if we turn right… or don’t turn at all?
I find myself wondering what is beyond the rote mechanical skill. It’s important to know the basic standard skills (they’re called standards for a reason - having a shared lexicon is incredibly important), but after you know them how important is it to follow them explicitly, and what happens if you don’t?
So far I’ve found it easiest to identify in martial arts movements. It doesn’t REALLY matter if you right, then left, or left, then right. The underlying concept behind the movement is to teach you how to move. I’m seeing similar patterns in my work - learning how an Excel function works is great, but the concept of an “if” statement can be applied across every system we work in. Zooming out a bit further, the concepts behind many soft skills generally don’t have a specific application, but rather require you to understand them conceptually.
This is certainly a reflection of where I happen to be at in my own growth. Beginners, for example, should be given clear, repeatable directions to follow; before we can play with concepts, we have to understand the mechanics. This also leads to some amusing situations when I’ve taught, and forgotten the “correct” way a movement goes. Inevitably I’ll get the question “But Rob, don’t we turn right after that move?”. After a few seconds of remembering the “correct” way I’ll respond with “Yes, but at the end of the day it doesn’t matter. The intent is to teach you how to move, not how to turn right”.
This approach to looking at the importance of underlying concepts, and not just the mechanical skill is one that shouldn’t be applied at all levels of learning. Beginners especially need the mechanical approach as it reinforces learning and ensures they share a common baseline. For example it’d be incredibly hard to talk about writing if everyone didn’t know what a period was, or if some of us used vowels differently. Similarly it’d be challenging to train up new team members at work if everyone on the team taught them different ways to do the same task.
Once someone is comfortable with those basic thoughts, begin to shift the focus to what’s behind them. Why we choose to take a certain action is more important than the action itself ... knowing the difference is even more important.
Data Analysts - Know Thy System
Understanding both how a system creates/stores data and how it is used is critical to being a good data analyst. Knowing these things makes it easier to interpret information and to tell a good story about any potential results. Failing to Know Thy System at best results in wasted in… and catastrophic decisions at worst.
“Know Thyself” is certainly an important concept to being a human. “Know Thy System” is an equally important concept to being a data analyst.
In addition to knowing data analytics concepts (not making misleading graphics, for example), a good data analyst also understands how data moves through the system(s) they analyze. This knowledge goes beyond basics and extends into how specific metrics are collected, how users behave and how data is stored. This background knowledge not only makes it easier for them to find the numbers they need, it allows them to draw better conclusions on that data.
Some examples I’ve run into include:
Knowing when tickets are assigned - Many reports on ticketing systems relate to who’s been working on tickets. Knowing when/how users are assigned tickets will impact the report. For example, if someone triages a ticket THEN assigns it, we can expect tickets to remain unassigned throughout the triage process.
When data is added to something - Some data fields are populated when a record is created (Employee ID, for example). Other data, however, may remain defaulted or even null. These defaulted values will appear in reporting, and may throw off results.
Where data comes from - End-user reports sometimes contain data from multiple sources/systems/etc. While this makes for easier story telling it can make troubleshooting or updating things more complicated. Being aware of how your reporting system pulls information reduces time to update things and makes it easier to explain how things were determined.
The problem with NOT knowing thy system
Understanding the UI and the users perspective isn’t enough to really know how the system operates. Many systems, for example, combine multiple metrics when displaying values such as Service Level Agreements (SLA), total compensation and others. Looking at the back end database tables can be incredibly confusing if you don’t realize that “SLA” really feeds 5 different dimensions.
As data analysts it is our job to know about these concepts. Failing to understand them will, at best, result in a LOT of wasted time as we dig through tables or configuration settings, and at worst, result in bad decisions being made about the data. Something as simple as not realizing your underlying data doesn’t include any data from January can be catastrophic; your customers will make business decisions on the lack of results from January… which aren’t real.
Helping others to Know Thy System
I’ve run into MANY situations where someone doesn’t have any background on the underlying systems and tries to make determinations on something. At best, this results in confusion as folks come to you, the Data Analyst with more questions. At worst, this results in conclusions being drawn from information that folks don’t truly understand.
In many cases we cannot expect our customers (folks reading our reports) to fully understand all the underlying concepts. This isn’t to say there shouldn’t be SOME expectation that they understand things, just that we cannot expect them to know anything close to what we do. To help bridge that gap, I’ve been following a few guidelines:
Always put comments in reports - Many reporting systems have a comment or text field. I’ve started always putting notes in there that relate to that specific report. These include a brief description of what the report is intended to show, and any call outs to specifics that may not be 100% obvious (e.g. a specific field showing a null/none until a specific time period, etc).
Proper Naming - Definitely another easy win - just name things more accurately. I try to keep a specific convention that briefly describes the report. This both makes it easier for me to organize, but also helps my customers find the right report more quickly.
Basic Documentation - In addition to cranking out reports and dashboards, I’ve found providing basic documentation on where data comes from is incredibly helpful. This doesn’t have to be (nor should it be!) a full data dictionary. This wouldn’t only drown your customer in too much info. Rather it’s a quick guide on what common metrics mean and how they’re pulled. Think of this as proactive defense against common questions.
Attendance Automation
Finding pain points is a big part of my job…. but finding solutions is much more fun.
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.