I'm working on a system for positive behavioral recognition and metrics using Firebase and React. This is a hobby/side project that I work on usually on nights and weekends.
This weekend I had an issue with Firestore (the newer of the two data solutions inside the Firebase product). I was querying on multiple data attributes in a collection. This is not allowed in Firestore, unless you have created an index that includes those two attributes.
I had no such index, so I got this error:
Yes, the short answer is that that link says, "You can create it here." And you can click on it and it takes you to the page where you can build the index.
And it has pre-populated the index for you with the two fields that you need so that you can click, "OK". And the index builds, just like you need it:
This is really pretty amazing and I have never seen an error like this.
Often, errors are very generic and it takes time to search through forums trying to find someone with the same error who is actually having the same problem as you.
I have seen a number of errors in React that offer suggestions as to where your bug is and they are often correct. This is very helpful and a huge improvement.
The Firestore error takes that level of customer service to a new level: here's your problem, here's how to fix it, and here's a link that will basically fix it for you.
I would very much like to see more of this.
What has happened here is that someone at Google (Firebase is a Google product) has applied the ideas of user experience to the error handling in their product. Developers are the users of the error system, so thank you for that!
Firebase is a web-based product, so there is no reason why it can't know enough to point you in the right direction.
If you are in software development, though, you can appreciate that this is a high bar to jump over:
Someone had to think of this early on, so that it could be woven into the product.
Leadership had to include time and budget to implement it.
Their UX had to be consistent enough to allow it.
The error system handling system had to be built smart enough to make it all work.
All of this to say - a lot had to happen technically, organizationally, and culturally to make this happen.
When you think about the amount of time that often goes into error handling and management, it makes this all the more amazing.
Developers ARE the users of your error system, your API, your toolkits, and your documentation. Doing things like this makes your tool attractive to developers, managers, and business decision makers.
Why managers and business decision makers? Because it makes good developers better and faster, and it makes new developers far more productive than they would be if you didn't have it.
New developers spend a lot of time searching for answers online and asking more senior team members for help. Imagine a world where the platform itself can answer your questions and guide you through solving the problem.
Kudos to Firebase/Google on an amazing innovation.
In my last post I jumped right into the fray of describing a whole system for data-driven software development that includes normal stuff (Business KPIs, OKRs, Software metrics) but also some weird stuff - what I call Positive Behavioral Metrics. I didn't describe what I meant, so I am going to do that now.
I also didn't describe what to do with the other half of that coin - negative feelings and behavior - but I am going to do that separately, in a future post.
Positive Behavioral Metrics is keeping track and counting all the good stuff that people do. A system to do this (could be software-based or not) should have the following characteristics:
A means to create and track 'wins' or instances of people doing good stuff. This could be someone who gave a great presentation, won significant new business, or contributed to the positive roll-out of a new initiative. Really anything that is good (for individuals, teams, or the organization in general) - large or small does not matter. Concrete behavioral information is preferred - a specific good thing is better than a vague good thing. But honestly, even starting with vague is better than nothing.
Notification - the person should always be notified when someone recognizes them.
Notification of Others - the person's boss and their boss's boss (if applicable) should be notified about the good thing that was done.
Reports - a person should be able to go in and see all the good things that they did in a time period (last month, this year, a certain year) so that it can be used in reviews.
Track positive behavior to company values: any time that someone does something good and it is tracked, they person entering should have the ability to track this to some part of the company's values.
Provide a report on people who consistently recognize other people. These are your energy fountains - the people producing energy in your organization. This is another key number, in addition to the people who get recognized the most.
Organization-level Reports: should include reports on doers - those doing the good stuff and recognizers those doing the recognizing. For both you want to know how much of it is happening, where it is happening, and to be able to drill down and see who is doing it and who they work for.
This is really pretty straightforward - honestly this can be built for very little $$ and you could get away with 1,2, and 3 to get started. You don't need more than that.
Outside of the system, you need a program around the raw numbers and reports to really drive maximum effect. And I don't mean prizes or gift cards. I honestly think that tying it to rewards or awards isn't terribly interesting or effective.
I'm really talking about how this applies to people's growth, to their careers, and to their happiness. This is what will make it the most powerful. This should generally include:
Personal recognition - by which I mean, if you're in charge and you get the emails about people doing awesome stuff, then walk around or visit the people and talk to them and show them that you are aware of what they do. You can take them to lunch if you want, or have a dinner or something, but do some form of recognition where their peers see you talking to them about what they did.
Thank you notes - I'm personally terrible at this, but many people swear by it. Sending handwritten thank you notes to people (or their spouses) is something that can be very effective.
Use of reports - encourage people to review their data, especially at review time to be sure that they use this data when filling in their reviews or 360 evaluations.
Encourage managers to recognize - use the recognizer score to ensure that recognition is happening and that you have even consistent coverage in your organization.
There are many other things you can do. These are simple examplesthat you can start with that don't cost much but do build a lot of energy in your organization.