The Motivation
As a stakeholder are you suffering from zero notification communication infrastructure and wondering what does it take to get started? Or are you flooded by a deluge of notifications from different channels that pains you so much that you ignore them altogether, wondering what does it take to cleanse your notifications to make if more meaningful to your work-life?
The Context
There are startups that live by word of mouth or email communication for anything and everything without any automated notifications of any kind, even today. And then there are many companies that has got annoyingly big and loud notifications, making its team mute it altogether, thus resorting to acting on event based on word of mouth (command from leadership). The later though jazzy, only increased overhead cost of tools than any productivity on ground.
If you can relate to this and are looking for a systematic approach to lean and manageable notification practices that enhances transparency, and accountability, do read further.
The Approach
Step 1: Know your immediate needs
Don't fall prey to "Overnight, Zero to Hero" stories. Do not frame the needs based on assumptions or forecasts for distant future. And do not blindly take somebody's best practice as solution to your needs.
Know your immediate needs and let the immediate needs grow organically with the evolution of business and product suite. Stay lean and be agile.
Step 2: Prioritize your needs
Not all notifications are same. Some are critical, some important and mostly it is informational.
All informational notifications are known as simply "Notifications". A CICD pipeline is expected to pass or go Green every time, and when that happens the stakeholders are Notified of it as acknowledgement.
All important notifications should be know as "Alerts" only. A CICD pipeline is expected to pass or go Green every time, but if it does fail in any quality stage-gate, the respective stakeholders should be Alerted of this bad event gearing them up to do the course correction as soon as possible.
All critical notifications should be known as "Alarms" only. The same CICD pipeline, if it were to fail in successful deployment of a new release in production, all required stakeholders should be Alarmed of this critical event to go on a war-footing to fix it immediately, in order to minimize the damages.
Step 3: Classify your needs
Classify your notification on the basis of needs of the group - Business team, Product team, App/Service Engineering team, SysOps team.
Once this classification is clear, you can then group your notifications based on this classification as respective channels. For example, if a sales conversion funnel don't reach the timely threshold for the day, the respective business and the product would want to learn about it to diagnose if it is an operational, or product issue before double clicking onto technical side of things. Storage drive breaching set threshold, would warrant the Ops team be alerted about it without troubling the rest of the organization. A unit-test failure in CICD pipeline for local to its engineering team to act on, than anybody else.
Step 4: Solve your needs
Solve your needs by setting up notifications in appropriate tools configuring it to publish to right channel(s). Every time you add or modify existing notification, take it as an opportunity to cleanse the ecosystem with dated ones. If you don't do timely cleansing, you are letting the ecosystem rot.
There are companies whereby some Sysadmin manages the individual's subscription to different notification channels. The next level maturity is to democratize it with open subscription for individuals to subscribe to or unsubscribe from any channel on demand, desire and need basis.