Rule Authors come in a lot of different packages, but they can tend to be grouped into three categories:
1. The Casual Rule Author
This person knows exactly what should be in a lookup table or a decision table, yet likely never made it to product training. Here are a few more characteristics:
- They kick-out logic across states, geos, and the like.
- They don’t want to be bothered with testing or heavy process.
- They are happy to do their part and delegate.
This kind of rule author is easier to conscript because the cost on their daily job is low while the business takes advantage of their knowledge.
2. The Everyday Rule Author
Many business decisions cannot be expressed with casual attention and resources. The decisions need to be exercised, pondered and proven to do the job. Moreover, as the business changes, so does the logic. 5,000 to 10,000 rules later, there are multiple people working on aspects of the decision and measuring outcomes. They report readiness, completeness and demonstrate compliance to the business. In general, these people undergo training and help others along the way to scale.
In terms of recruiting for this role, look for people who love Microsoft Excel and live in the middle of calculations and SQL. Look across the hallway for individuals trained in data analytics and statistics, since they can use those same skills to improve the rule application. Examples of this would be known correlations, data patterns, or concrete examples of risk and fraud. In the end, a great decision combines the insight of the organisation and makes it operational. In general, if you’re not sure about a candidate, consider the following:
- Is the person wired to know how and why things work?
- Is it painful for them to miss a detail or have gaps in their understanding of a process?
- Do they spend a lot of time explaining details and process to stakeholders?
- Do others listen when they speak and are they regarded as an expert?
If the answer is yes to most of those questions, then you likely have a good rule author.
3. The Technical Rule Author
It seems every team needs at least one technical rule author. They do the heavy lifting and help with feature selection within the product: service integration, data modeling, user defined functions and vocabulary setup. Often, these people are developers (or architects) and understand underlying APIs for integration. They rely on the repository API reflecting the innards of the rule definitions. They play a critical role in life-cycle management (SDLC) and help socialize to the technical teams how something works. They might have the title “Architect” or “Lead Developer.” This person also cares about performance and efficiency. Once a rule application grows to a certain size, others start caring about response times, refactoring and making sure every rule does its job—or removing it if it doesn’t. If you look in-house for this, search for someone that’s interested in solving a wider range of problems, including people and business process.
It’s not likely that any of your rule authors woke up one morning thinking about a career in decision management. I bet they do wake up thinking about business problems in the form of people, process and data. If you are in the early stages of your project, it might be time to have lunch with some folks and explore the possibilities of them joining your project.
Finally, you should think about scaling your team. The figure below is based on numbers we have seen from small to large projects. It’s intended to be a rough guide. Actual team sizes vary a lot based on dimensions not represented.
|Authoring Team Size||Rule Count||Complexity|
|1-2||50 to 1000||Low to Medium|
|3-5||1000 to 3000||Medium to High|
|6+||3000 to 15,000+||
High with Multiple Decisions
The actual team mix of author types (Casual, Everyday, Technical) is largely driven by the size and complexity of your problem. Factors such as performance, integration and security typically drive up the count of technical rule authors. As the success of the project grows, expect more demands on the team to socialize what’s taking place.
If you are in the early stages of project research, consider working with us. Contact us if you require any further information.