What's the key to leveraging the power of AI in the workplace?

Effective Communication

One of the most powerful predictors of team performance is Effective Communication.  This is a broad topic considering brevity & conciseness, accuracy & ambiguity, a shared vocabulary and context, high trust, good alignment and many other factors.  Whilst making predictions about the impacts of technology in the future is hard, and history tells us, generally inaccurate, it would make sense to assume (at least for now) that effective communication between intelligent, interacting entities (IIEs) will continue to be a key predictor of overall effectiveness and performance.

With this in mind, how might we future-proof our business and working practices to leverage the power of the rapidly advancing capabilities of Generative-AI?  Well... in short, focus on improving effective communication between IIEs... yes, there was a reason why we referred to "intelligent, interacting entities" earlier, and not simply "people".  If we consider AI-powered tools and systems as IIEs, we think more carefully about how we create knowledge and share information in the workplace.  Precise, unambiguous, concise, accurate (PUCA) language, within a common context, will remain just as important as ever.

We can improve our abilities to communicate with people today, relatively easily.  But it may take a bit longer to be able to do so with AI.  So you need to start now.

"Aren't you just talking about 'Prompt Engineering?"

Prompt Engineering

Prompt engineering is certainly a skill / role related to effective communication between IIEs.  It involves crafting clear and effective instructions or prompts to elicit desired responses from AI language models, a form of Generative-AI. It's definitely a skill to formulate input in a way that guides the AI model toward generating specific and relevant outputs.  But it has it's challenges, it's not very deterministic or repeatable, it's geo-language specific and comes with all the issues that is inherent in human languages.  They're not PUCA.

When people converse, the current context, domain specific terminology, buzz-words and acronyms are a powerful short-hand ...and troublesome.  So how do we maximise their richness whilst minimising their short-comings?  We'll get to that in a moment.

Product & Software Development

What might this mean in the world of Product & Software development?  Well, undoubtedly we will be employing AI systems to do much of the work, we can see this beginning to happen already.  But how do we interact and communicate with them, and most importantly, who communicates with them?  We touched on the 'who' point in a previous article last year, it's a very short read and is worth checking out.

Requirements Models

One approach to communicating in a PUCA manner is to create a model.  Modelling requirements within a specific context and domain, serves as an excellent example (and a proven method) for communicating with PUCA language and powerful short-hand terms. Once a popular technique, requirements modelling has fallen out of favour in recent years. This is often due to it being perceived as time-consuming upfront work, at odds with a more agile way of working.

In reality, these models often still get built.  What frequently happens is that automated test suites effectively create a type of model representing the requirements and their domain. Additionally, some would argue (with merit) that software architecture and software design practices, such as those related to Domain Driven Design (DDD) and Object-Oriented Programming (OOP), also produce models. Whilst generally effective, they are not the most efficient method:

1. The level of experience and expertise one needs, to correctly, effectively, and safely practice these techniques is high.
   
   In the hands of experienced developers and engineers, they are effective techniques for navigating a sea of complications and complexity.  But for most people, it takes a lot of time, effort, and making mistakes, to become proficient.
   
   In short, only a sub-set of your workforce can correctly and unambiguously communicate with IIEs this way.
   
   
2. An iterative approach can hide unnecessary rework and corrections.
   
   These types of requirements models are rarely developed correctly at the first attempt.  They become increasingly valuable as they undergo iterative updates, often as a result of finding and resolving ambiguities or from answering questions that nobody had the answers to at the start. This is sensible.  But it can also be very inefficient.  There are better ways of driving out uncertainties and ambiguities.
   
   Also, this means that the PUCA 'expression of needs' doesn't initially exist in a manner that facilitates communication with a concise, correct and unambiguous language, whether to a person or an AI-powered tool.
   
   We're not suggesting that we try to make a waterfall-like approach work. Rather, we are acknowledging that the reasons for the emergence of agile practices will persist, even within AI-powered software development.  We will still need to iterate, experiment, learn and adapt.  But there are better ways to model requirements such that we can unleash the power of AI in the workplace.
   
   
3. They're not really requirements models.
   
   A Requirements Model goes beyond a simple list of written requirements by offering a comprehensive framework that captures the essence of what's needed. It provides a structured representation that illustrates relationships, dependencies, and interactions among various requirements. This holistic approach, often referred to as "cohesive rules," ensures a more interconnected and nuanced set of guidelines, which can be vital for effective system development and understanding the project's complete scope.
   

What if we could quickly model the requirements, communicating with PUCA language and powerful domain-specific terminology?  What if we could shine a light on the scenarios and situations that mustn't be allowed to exist?

Well, we can, there are numerous techniques that have been used over the years.  They use modelling languages (MLs) and they differ in their innate abilities to drive out uncertainties and shine a light on ambiguities.  Most are valuable for being able to 'zoom out' and to be able to see a summary of a complex scenario.

Examples of modelling techniques range from graphical and notation based approaches such as UML and its various models, The C4 Model, Business Process Modelling such as BPMN, to more strongly typed, semantically rich and self-verifying MLs and finally to formal / mathematical MLs that create provable models.

What if we could do it in such a way that lowered the level of experience and expertise needed to do this accurately?  After all, this both improves the usefulness of some of your workforce and teammates now, and takes you one step closer to being able to effectively and safely adopt AI-powered development tooling in the future.  We can.  Numerous methods have proved that they enable this, maybe not when practiced in isolation but when practiced together.  But they don't get adopted by the mainstream development communities.