1
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.
.avif)
So, the first step’s done - deciding. After that, comes an unexpected hurdle: keeping everyone in the loop.
This is an underrated aspect of developing a top-of-the-line ML solution. This job usually falls squarely on the shoulders of technical leaders - tech leads, PMs, or anyone hands-off on the development work. They’re best poised to understand the project, while not taking development cycles away to deliver updates.
It’s also critical. Not everyone has the same background as the technical team working deep in the weeds.
But the finance team still needs updates, the HR team is invested in the outcome, and legal needs to make a pass. How will you balance their backgrounds, needs, interests, and questions?
Here’s a framework for presenting these ideas.
To run an effective project, the main communication methods can’t just be a scrum board or email summary. We’ve found assigning a main point-of-contact is incredibly helpful.
The question of who that is comes down to who the most effective communicator is on your team. We often hand that off to the product manager. Not all ML engineers have the necessary communication skills to relay all the information we’re going over. And adding communicating responsibilities to engineers adds another opportunity for the ultimate productivity destroyer: context switching.
We prep our product managers on a call, where we go over:
As you might have guessed, whoever you pick should be decently technical. They’ll be directly translating technical content from the ML Engineers into non-technical updates for stakeholders.
And, you guessed it, you need to tailor the content for each stakeholder to what resonates with them.
Let’s not get ahead of ourselves. How you present concepts completely hinges on the audience. “Non-technical stakeholders” could mean any number of vocations - finance, legal, HR, the list goes on.
“It’s crucial to find the balance between saying a lot of technical words, and speaking in common terms. Using technical words can help you explain more deeply and show you are building something state-of-the-art. But balancing that with relevant, digestible explanations is important.” says Vitalijus Cernej, a Machine Learning Engineer at NineTwoThree.
Finance, for example, deals with similar concepts to data science, like regressions and data pipelines. They will understand and take interest in some specific technical parts of your project. On the other hand, legal might have a vested interest in the data integrity and security side.
“Common knowledge can help explain concepts.” says Jurgis. “For example, if they know how trend lines work and what forecasting is. If they know forecasting, then you can say that LLMs are just forecasting the next word. Start simple, and build on that.”
Think intentionally about this. Anticipate their questions, and try to find a good balance in your slides or doc.
On that note, it’s important to understand the way the team typically delivers project updates. Is it via Slack? Email? PPT? Live presentation? This will keep them engaged and speak to them in a language they can understand.
Once you have the medium ready, and understand their questions, you can start to decide how to present the content.
In ML projects, there are a few project and progress updates you can expect to make.
“Updates can vary. Initially, it can be as simple as letting everyone know the environment is set up. Then, when you have a working demo, it might shift to demonstrating the solution answering a basic question. And at the end, there’s real evaluation.” says Jurgis Samaitis, an MLOps engineer at NineTwoThree.
These can be anything from:
The content for each of these differs, but the questions below are what you’ll want to ask yourself before you start working on these updates.
If you can answer these questions, you’re ready to start strategizing on the content.
What’s going to be the audience’s main KPI?
Are you going to be explaining a broad overview of your project, or asking for an extra $1,000 to provision GPUs to train one model?
“It’s important to identify what the audience’s angle is. If they don’t care about costs, focus on explaining the results. If they are interested in accuracy, then don't spend as much time explaining efficiency.” says Jurgis.
Linking your explanation to their KPI is a great way to speak their language. But you have to go deeper - their incentive and investment in the project is key to your messaging.
If you speak their language, the discussion becomes exactly that - a discussion. That part is often overlooked.
It’s important to treat this as a conversation rather than a presentation.
After you’ve zeroed in on the angle to approach for your stakeholder, give them options. Get their opinion on the options, weighing priorities and business values for each alternative. Rarely do ML projects have one path with one outcome, and leveraging the expertise of stakeholders can help steer the project in the right direction.
This helps keep the conversation business-focused instead of engineering-focused. You can frame the discussion around end users and answer questions like:
It’s tough to answer these questions if you aren’t having a back-and-forth conversation with stakeholders.
Back-and-forth doesn’t just mean within one meeting, either. As the project grows, you’ll continuously communicate with them. Updates will, as you’d expect, look different at each stage.
Once the project is off and running, you’ll want to have internal calls where you’re communicating project updates frequently.
Use this cheat sheet to lead the discussion
Your point-of-contact should facilitate this discussion. Use this template to guide each week’s topics.
There’s a big difference between presenting a project that’s going to happen, versus one that’s almost done.
“For example, if a new product manager is joining the project, and you already have architecture diagrams (or better yet, a demo), that’s a better way to show what you’ve been building. These types of updates make it easier to understand the project, the goals, and the progress.” says Vitalijus.
At the beginning, you’ll be speaking in a lot of abstracts - what will happen, what you’re hoping to accomplish. And there’s tribal knowledge, concentrated in individual experts. That’s harder to approach and explain, especially for someone non-technical. At that point, it’s a good idea to be visual and focus on diagrams and concepts.
At the end, you’ll hopefully have working demos, presentations, and charts. Those are all extremely helpful, and easier to approach for someone trying to get up to speed.
Be careful, though - especially early on, there are expectations to manage.
ML projects are a trap these days - expectations are high. Keep in mind that stakeholders might come in thinking the solution will work perfectly, with no flaws. That’s an unreasonable expectation for an ML project, and something that’s important to communicate early.
Our advice? Be reasonable with expectations, add buffer for potential risks, and overdeliver.
“Some companies like to brag about their top-of-the-line accuracy, but that only happens after years of fine-tuning models and tweaking prompts. Start low - for example, 70% accuracy on responses - and then communicate improvements. Statistics can be tricky, and it’s important to calibrate expectations.” says Jurgis.
Remember that internet benchmarks are usually based on ultra-clean datasets, and can be hard to replicate.
Another pitfall is to just show numbers without any more information. Make sure to include context. A 2ms latency improvement can be impressive or negligible, depending on the context of the improvement. Is it at 20% decrease? 0.5%?
Another pitfall is assuming technical knowledge. We mentioned that your coworkers in finance might understand regressions, but that varies by function, team, and even employee. Making that assumption without double checking can lead to an awkward explanation.
This can be mitigated through asking for continuous feedback - keep checking in and asking if the material makes sense, what’s missing, and what’s confusing.
This is a nuanced part of any successful machine learning project, but an important one. Timely and relevant updates can give confidence to your stakeholders that their concerns are met and they understand the project.
Our team at NineTwoThree has partnered with dozens of successful companies to deliver world-class AI projects. We have this process down: a streamlined, transparent way to ensure everyone is in the loop.
If you’re interested in partnering with us to get your AI ideas off the ground, we’re ready to listen.
Contact us to learn more about our machine learning services today!
