This will start a series of posts on a topic dear to my heart – honing your communication skills to amplify your impact.

More than anything else, how you communicate will be the dominant factor in your success as a data professional (especially in management and leadership roles). Hear why and what you can do to turn communication into a strength.

The wrong question

I get asked a lot by aspiring data professionals about how to and what they should be focusing on to improve.

Things like:

• What framework should I learn next?
• What models should I be using?
• Should I learn Julia or Spark?

While these are all good things to consider (in the proper context) for most people, they’re not where you should be focusing. Being that rare data scientist who knows Julia over their peers is only going to assist in some niche roles or industries — it’s one of those skills that might be used to differentiate between two strong candidates.

Wouldn’t it be better if you built the foundations to be a robust and standout candidate across all roles and industries?

Once you’re beyond a certain threshold of technical understanding, it is tough to keep advancing and make meaningful improvements to your technical ability. This usually comes with niching down and mastering some specifics in the field.

There are, however, general skills that are always useful and sorely scarce across all data roles. Things like:

• Project management
• Research methods
• Teamworking (yes this is a skill you and you can get better at it!)
• Timekeeping (this too!!)

In my opinion, however, one skill beats them all. You guessed it, communication.

This is a no-brainer, right? Communicating effectively is vital for any profession and for life, but I want to highlight its importance in business.

I’ve worked with several super-talented people that struggled to have the impact you’d expect because they were held back by their communication. Worse, many talented people think they’re above this, and the work should speak for itself — it won’t.

Simplification

It’s your job to translate your ideas into the clearest, easiest-to-digest form possible without compromising on the content of the message. In many situations, you’ll be the expert in what you’re discussing — you’ll have been hired for your technical expertise and are required to translate that to non-technical stakeholders, or you’ll be in a technical team. You’re relaying the outcomes of your project to the broader group. Either way, it’s about context.

It reminds me a lot of the famous experiment by Elizabeth Newton at Stanford — study participants were made to tap out a tune to others and guess the likelihood it would be guessed correctly; those tapping the tune massively overestimated the ease with which it would be guessed. This is dubbed “The Curse of Knowledge” and is well-studied.

Curse of knowledge

Essentially, it’s hard for anyone to discount what they already know when explaining something to someone else. Data professionals are especially bad for this. We often assume a level of understanding (or even interest!) that isn’t there and communicate at completely the wrong level.

Although I have a technical background, I tell my teams to write their presentations, demos, and documentation as though they’re communicating with an idiot. You’ll hear me band around the term “idiot-proof” a lot.

Assume I know nothing, and you need to communicate so that I get your main points. The algorithm or mathematics might be interesting to you, but for many non-technical stakeholders, it isn’t. Worse, high-level leaders within many businesses may consider this intellectual snobbery or time-wasting.

How do you improve at this? Practice.

Run lunch and learn sessions for non-techies or people with little experience in your field. Ask your family or friends that don’t work in tech if you can quiz them on it. Getting this right will work wonders and save time getting bogged down in technical detail when it isn’t needed.

Written communication

This skill should come with time as you document your work and collaborate with a team. Try to keep concise and avoid the use of complicated words or language.

I’ve kept a written journal of my working day for my entire career. I learned early on in my doctorate that I needed to write things as explicitly as possible and keep track of references like my life depended on it. If you’re ever on a call with me, you’ll be fully aware of just how much I write down.

We work in a broad field with many deep technical areas; it’s easy to forget something you knew six months ago. Getting into the habit of good note-taking should improve your writing.

Don’t be afraid of the review and editing process; a harsh editor is a blessing. I went through a lot of this pain writing my thesis, and my writing is much better for it. Having someone else objectively review your writing is gold. If you’re finding it hard to read what you write, start a blog; plenty of people online are eager to help. If you start a blog after reading this and want it reviewed, reach out, and I’ll tell you what I think.

Finally, I’d recommend using a tool like Grammarly – it’ll stop you from second-guessing your grammar and help with consistency.

Verbal communication

Most data professionals I’ve known have struggled more with verbal communication than written. There are a load of tricks and tips for getting better at speaking. The top three I tell people when coaching this stuff are:

• Slow down (a lot) — one thing many techies tend to do is talk too fast, especially when they’re excited. Try to avoid this. Try to actively slow down, and think of the kind of pace a politician or actor uses when giving a rehearsed speech or monologue.
• Pause more, for longer — this seems counterintuitive, but add longer pauses to your speech. Leaving gaps can be powerful and punctuate what you’re saying. It exudes confidence. It also gives others a clear signal that they can cut in with questions or another point if they need to, and won’t have to talk over you or wait too long. It also gives you an excellent opportunity to review the body language cues you’re getting from the room and tweak your message accordingly.
• Get to the point — too often, I’ll hear excellent points get ruined or missed because the speaker goes off on a tangent or down a rabbit hole. You’ve probably witnessed someone get lost and forget what they’re saying. In a work context, this can be a damaging reputation to have and can lead to people switching off every time you start speaking. Try to be concise and keep on track, and expand on your points only if asked to or absolutely necessary.

Visual presentation

This probably hurts my soul more than anything else mentioned in this list. Please take some time to learn to use visuals effectively. Please.

Too often, I see folks present brilliant work with results plotted on the wrong chart type, with bad axes, and unclear, ugly, squinty visuals. Whether you’re writing for journals, giving presentations, blogging, or just documenting your results in your Jupyter notebook — your charts are what most people will gravitate towards. Make them hit home.

I’m a big believer that if I can’t immediately (within a few seconds) understand what’s going on in a chart, it’s probably a bad visual. If someone has to walk me through or explain a chart, there’s a good chance it could have been simplified or presented better.

There are a lot of resources out there to draw from. Sometimes a mixed bag, but r/dataisbeautiful is an excellent place to see what others are doing (just be wary, beautiful charts aren’t necessarily good).

I recommend you familiarise yourself with the Financial Times Visual Vocabulary — this is an excellent standard to strive for. There are some implementations for things like Tableau and Power BI out there too.

Sometimes complex figures are necessary, in which case, try your hardest to apply some of the points from the fantastic Visual Display of Quantitative Information by Edward Tufte.

Final thoughts

With anything, targeted practice will lead to significant improvement across the board. Some of these things might come naturally to you, while others won’t. Don’t be afraid to reach out to mentors, colleagues, or even the wider community — there’s nothing like starting a blog or attending a local meetup to hone your skills. You might enjoy it.

Hopefully, you found this helpful. Please let me know if there are any tips you think I may have missed — I’m still learning too!

All the best,

Adam

This week’s newsletter was kindly sponsored by CoRise – one of my favourite expert-led online learning platforms.

CoRise is running free SQL Crash Course (signup link) and Python for Data Science (signup link) courses; sign up now!

A data team’s work is never done

Many data teams do a great job of serving the requests of their stakeholders. They get the job done in a timely manner, build robust, scalable solutions, even get some time to do knowledge sharing and education across the organisation.

But it’s easy to get a bit stuck in a rut.

Data and analytics isn’t easy. It takes time. These solutions are complex and complicated, often taking many iterations to develop from an idea to something that serves the business-as-usual need. Furthermore, your skills are in demand and you can add value to almost any other role or team in the organisation.

That can lead to overload – lots of different people competing for your time and attention to sprinkle some of your data and analytics magic on their workload.

You can end up on the treadmill, stuck in that “order-taker” role. Working away at whatever crosses your Kanban backlog and, if you’re lucky, getting through it at about the same rate it’s growing. Some of the great ideas you’ve had sit on the “one day” shelf, gathering ever more dust while you build yet another ETL pipeline to replace some fractal VBA nightmare.

At least someone cares

What’s worse than many people looking for your support?

No one looking for it.

Maybe you’re capable, available, keen, and ready to go but the one area of the organisation you think you could make the most impact in just aren’t interested. They don’t get it. They’re not data people. They don’t care. Or they just don’t see how things might be improved with a little help from their local friendly data team.

How do you break free if you’re in either of the above situations?

How do you get stakeholders engaged?

How do you take some control over what gets built – being proactive instead of reactive?

The Art of the Possible Workshop

I think this might be my favourite tool developed over the last few years of leading and consulting for data engagements. The Art of the Possible Workshop aims to get stakeholders excited about what they can do with data and analytics. It helps them spot opportunities across their organisation, and most importantly it gets them to prioritise a big shopping list of potential workstreams so you can take them on to the next step.

The Art of the Possible Workshop was built using the Perfect Workshop Blueprint, discussed in BD #9. If you aren’t familiar with it, this is my go-to approach to turning meetings into gold. Read it here:

The goal of this workshop is threefold:

• get stakeholders excited about the possible impact data and analytics can have
• gather a curated list of pain points and potential opportunities to drive positive change in the organisation
• get collective commitment and prioritisation on what to do next

This starts the whole co-design process. People often love the sound of an idea if they think it was theirs (even if they were coached to it). This workshop allows you to guide the group to have a bunch of great ideas for your team to start implementing.

The participants

I typically want to deliver this to between 4-8 people (too few and you don’t get a wide enough picture, too many and people don’t get enough share of the time/space). If you need more people, consider splitting it up into sub groups or categorising by role. This should be somewhat additive, so don’t be afraid to run it with a similar group at a later date once some changes have been made.

Who should be in the room depends on the remit of the data team or those you’re trying to engage. If I’m running one of these for a small company with only a handful of heads of and directors, I’ll probably try and do it as a company-wide exercise using them as spokespeople for each department. If the company is large or you’re looking to engage just one function/team (say finance), then you might want to get really specific and try to invite at least one of each job role and seniority level in that function.

The Format

I like to do these in a single day-long, in-person workshop with a whiteboard and post-its. I’ve done it remotely with online collaboration tools and I’ve broken it into lots of smaller stages, delivered over weeks. This is always the rough flow of events.

• Case study showcase
• Opportunity discovery
• Discussion
• Themes
• Ideation
• Prioritisation
• Commitment

Case study showcase – 60 minutes

This part takes the most time to prepare. You want to prepare a number of case studies that are relevant to the people you have in the room. The objective here is to get people excited and discussing blue sky, no limits things that are possible.

Draw these case studies from four places, in order of preference:

• direct competitors and similar organisations in other markets that do almost exactly what your audience do (or want to do)
• industry adjacent organisations that serve similar customers / markets but in different ways (suppliers or B2B customers in the same domain, that speak the same language)
• organisations, functions, or teams equivalent to the one you’re talking to (finance team in another industry for example)
• generally applicable case studies that will impress (think good data catalogues, ChatGPT etc.)

Nothing gets the room talking more than showing them what their fiercest competitor is doing and they aren’t. The point here is be as specific to their context and language as possible. The closer the better.

I always try to include some interesting general stuff that they might not be aware of – data discoverability tools, RPA, self-serve reporting, data quality tools etc.

Aim for roughly 10 examples, use short GIFs and video demos over pictures where possible. You don’t need to go into details. If you can link to hard, citable numbers that’s even better. Case studies by big vendors and consulting firms is where I usually start my search.

Once you’ve done this, your audience should be primed for some participation.

Next week we’ll get the post-it notes and whiteboard pens out and talk about how to turn this energy into something you can plan against.

All the best,
Adam

I lied!

Last week I promised to land the second part of the AotP Workshop write-up. I’m currently working through one with a customer and realise it needed updating a little. Once I’ve worked that through I’ll get that sent out.

Instead, this week we’re talking about

Interview Pitfalls

Now that we’re well and truly past the peak of the data and AI hype cycle, I can tell you hiring data scientists can be a painful and challenging process for both sides. Whether you’re a candidate trying to find the perfect role or an organisation seeking the right fit — there are plenty of pitfalls to watch out for.

For those getting into the role, there’s confusion about where to start. Trying to become the ‘Full-Stack Unicorn Data Scientist’ can feel like a task of mythical proportions. There’s just so much to learn. What’s worse, finding the right fit of skills for the role your going into is like playing Tetris set to invisible.

For organisations trying to find the right person, it can be just as overwhelming — especially if they’re going to be the first data scientist your organisation adds to the team.

While there are myriad paths to failing any hiring process, I’ve outlined some of the most common themes from my experience below.

Beyond understanding machine learning, statistics, programming, etc., there is a specialist skillset to be learned throughout your career as a data scientist.

You’re more than just a bag of technical tricks — knowing how to communicate and collaborate is paramount to your success.

The tech job market is more competitive than ever, and it should be no surprise for aspiring data scientists that even getting past the first hurdle can be challenging. It can be even more challenging if you don’t set yourself up for success. The advice below should help you avoid common pitfalls if you’re looking for a new job or a promotion at your current place.

If you’re looking to hire data scientists, you might find some of the points below useful to look out for.

So, what are the most common routes to failing the data science interview?

Machine Learning Buzzword Bingo

It’s all too tempting to tweak your resume to stand out. You read the job advert and see a few technologies you’re only tangentially familiar with. You think, No harm, I’ll brush up before the interview. This is a great way to pass the automated hiring filters used by recruiters and organisations, so you might think it’s a good step.

You need to remember, however, that many experienced data scientists will know how long these skills take to learn. Furthermore, they’ll want to know specifics and details.

It’s becoming ever more common to seek out specialists when building data science teams. I often speak about being T-shaped — have a broad knowledge of many tools and technologies but pick a topic or two and go really deep. This allows you to steer the interview towards your true strength.

It can become apparent quickly if you don’t honestly know your stuff. I’ve been in interviews where I’ve asked the candidate to draw up and talk through a high-level diagram of how CNNs work on the whiteboard, only to be met with shaky loose descriptions of the basics of neural networks.

You’ve wasted precious time you could have used to show your strengths and prove you can’t entirely be trusted.

Library Calls != Model Building

I’ve seen this so many times — a bright, talented candidate starts talking about all of their experience, and it seems reasonable at first, but as we start to dig a little deeper, answers to simple questions like:

• What’s the difference between XGBoost and a Random Forest?
• Can you explain the steps in building a decision tree?
• How do you select the number of clusters when using K-Means Clustering?

Don’t seem to come quickly. Asking more profound questions about why to use one tool over another might even go unanswered.

The thing is, it’s so easy to load up the library or copy the notebook from Kaggle and get going that the aspiring data scientist can see some results without ever developing a proper understanding of what’s going on.

Now you don’t have to be able to derive the equations from scratch for every model you use.

As a rule of thumb, be able to draw up a diagram of the fundamental processes for the tools you use and talk your way through them confidently when asked.

Understanding how these models work will allow you to better spot when they’re suitable and when they’re not.

Model Building != Data Science

Machine learning is a big topic, so it might seem wise to spend much of your time and focus there. For many organisations, however, this can leave you without the broader skills required to make an impact.

It’s no secret that the vast majority of time in data science projects is spent on tasks other than machine learning. So it would help if you spent time building other technical skills, such as data wrangling, cloud computing, statistics, and analysis.

Designing suitable experiments and knowing how to test a hypothesis is more important than knowing which tools will get you the highest accuracy.

It’s worth your time to look outside the machine learning literature to some fundamentals.

Relating Technical Skills To Business Problems

This is often the most frustrating experience to encounter when hiring. A capable and talented individual who knows the ins and outs of technical skills gets stumped when talking about the commercial aspect of the role.

Like it or not, you’re there to add value to the business. Simply solving technical problems is often the first step. In a larger team, this can be compensated for by other members with more commercial understanding — but it’s still a red flag in many cases.

I’ve heard horror stories of companies having to let go of great data scientists on paper because their ego stopped them from even trying to engage with the business — staying lost in the clouds of the technical. There’s a certain intellectual snobbery that you see in many early-career data scientists that is always more harmful than good.

Take the time to understand how these tools and ideas can translate to real value.

Try to communicate everything in terms that matter to your business — cost savings and profits instead of accuracy and precision.

Specific Knowledge About the Organisation

I always find this one a shock as it’s so easy to get around. You get through the early stages of the interview, and it’s going well, but when asked about what a candidate knows, it becomes clear they’ve made a short skim of the website — and that’s it.

Many people in the tech sector (especially data) love talking about what they’ve done. So, if you’re going into an interview, try hard to find all the information you can on specific projects they’ve done. This will give you great insight into the skills and domains that are important to them.

Read through recent marketing material. Look for blog posts on the company site. Try to connect with the people that will be interviewing you.

I always recommend trying to find individuals on LinkedIn — to see if they have personal blogs or have recently done industry talks. This will make you stand out as having done your homework.

Final thoughts

Although this list isn’t exhaustive, these common themes often go unspotted. So keep in mind the following before your following interview:

• Develop your fundamental skills outside of machine learning and understand the why.
• Don’t inflate your application with tools you don’t have experience with.
• Be able to confidently talk through the tools you use and focus on displaying a single strength over trying to cover as many areas of data science as possible.
• Make an effort to understand the business context; read through materials outside the technical about companies that have seen great success from machine learning.
• Seek specific information about what the company or individuals doing the interviews have done — it’s often more straightforward than you think.

Best of luck if you are searching — it can be tough out there!

All the best,
Adam

This week we will continue our walkthrough of the best tool I’ve developed for driving end-user engagement and codesigning solutions with business users. If you missed it, the Art of the Possible Workshop was introduced here.

To recap, this workshop is designed to take a group of stakeholders from any area of the business, arm them with ideas about what data and analytics can achieve, and then get them to agree on a list of opportunities for further investigation.

Where we left off

The previous article finished just after we’d presented some relevant case studies to get the group thinking about what data and analytics could do for them.

BTW I got a great response from a reader regarding good sources of use cases for larger organisations:

There’s plenty more to do – the remainder of this workshop gets the attendees collaborating, prioritising, and loosely committing to a list of potential projects. The sections are as follows.

• Opportunity discovery
• Discussion
• Themes
• Ideation
• Prioritisation
• Commitment

Opportunity discovery – 30 minutes

Now that folks have seen what’s possible in similar spaces, it’s time to start getting thoughts together. At this stage, we want to keep things problem-focused. Tell the attendees there’s plenty of time to solutionise later.

Give everyone some post-it notes and markers (avoid permanent ones as you’ll inevitably get someone writing on the whiteboard with it at some point). Ask them to write down as many issues, risks, and opportunities as possible.

It can be difficult for some people to frame great ideas as challenges and not jump straight to the solution (especially if they’re techies). Introduce them to “How Might We” statements – a great tool to ideate the right way.

Encourage free open thought here – nothing is off limits, and there are no bad ideas. Quantity and breadth is the goal at this stage.

If people start grouping their thoughts and expanding on others, then great. Let whatever comes naturally to the group happen.

Now, you can do this stage asynchronously with a bigger group that can’t make the meeting. Just send out some leading questions in something like Forms and collate them before the event. If you’re doing this, I will seed the whiteboard (either digital or physical) with as many of the summarised form responses as makes sense. If the team has already done this, I’d shorten this part of the live workshop to 10-15 minutes and introduce it as a “Warm Up” to get them used to the tools (essential if you’re using a digital whiteboard).

Start moving similar post-its into clumps and keep notes on what the group focuses on.

Discussion – 45 minutes

Don’t be too worried about this section bleeding into the first. This will happen naturally. In this stage, start by going through the items on the board and getting the group to talk openly about them.

We’ll want to get some loose categorisation going. I like to draw three horizontal lines on the board, creating the following sections:

• Affects one role – capture the challenges that are only specific to a particular role here
• Affects the team – things that are specific to one team or function
• Affects the broader company – challenges that cut across teams
• Strategic enabler or blocker – large items that could affect the whole company enabling or blocking significant projects

Don’t worry too much about this; it’s a guide for later prioritisation. The value is in getting the team to discuss their challenges openly. Have them refine, update, or remove post-its as they see fit. We are honing in on consensus.

Themes – 30 minutes

Now we want to take a step back. At this point, you should have plenty of challenges, hopefully, some loose groupings of post-its, and breadth categorisation. This section aims to surface any themes that may tie challenges together.

The objective is to create a hierarchy of concerns that tie to how you plan and manage work. I’m a big fan of the Theme > Epic > User Story > Task breakdown – although I rarely use SCRUM, this is a great model for breaking up work items.

Most post-its so far translate roughly to the User Story level (with some cross-over into the others). This section of the workshop aims to get some Epics and Themes out of the group, allowing us to better prioritise and communicate activities.

To actually do this, I would get a larger size of post-it notes, like these, use them like column headings, and then move all the related post-its underneath them.

Ideation – 45 minutes

Now we’re at the point of talking about solutions. Work through your groups of challenges and capture some of the attendee’s thoughts about how they might be solved.

The objective shouldn’t be to think of the most complex, fanciest ML solution for every challenge. Quite the opposite, in fact.

Schedule a break before this section and line up the post-its so far into a column to the left of the whiteboard. Then draw two lines and add these three headers to the new columns:

• Manual solution by the team
• Off-the-shelf solution or service
• Bespoke solution

This will encourage the team to think of ways to solve their challenges using unscalable manual solutions, existing products and services, or new approaches that haven’t yet been developed. You don’t want to reinvent the wheel or build fancy data products that solve a problem some off-the-shelf product can do for little effort.

Let this stage be collaborative and open – don’t let budgets, skills, reality, or common sense get in the way. The next stage will filter out what’s most important.

Prioritisation – 45 minutes

The final (and often most fun) part of the workshop. If you haven’t used dot voting, read this and buy some of these. Most online whiteboard tools have this as a built-in feature, or you can just use shapes and overlay them onto your post-its if needed.

We’ll do this in two stages.

First, give everyone X number of votes. X doesn’t matter too much; 3-5 usually works best. You want votes to be scarce and important to people.

Then allow the users to add their precious dots to any challenge post-it in the leftmost column they wish. They can add them all to the same one or spread them out; it doesn’t matter. They can vote on their own notes or other people’s. Anything is game.

All votes are equal, and the number of votes will determine priority when we start planning development.

Once that’s done, feel free to discuss the outcomes and which items were voted for the most.

Then repeat the process for the solutions the team created.

Once all is done, take some time to discuss things and write down the top five from each side of the board in order of priority. Don’t move things about at this stage; we’ll need to capture everything into some documentation later – at that point, you can create nice-looking lists etc.

Commitment – 30 minutes

Thank everyone, and discuss why you’ve done everything so far.

Then go around the room and ask for feedback.

Finally, capture actions on how to proceed. As a development team, it’s your responsibility to turn the post-it frenzy into a backlog. The current prioritisation is important but not final. Use it to inform the sponsor and allow them to sequence things properly.

Ensure you put in an action to replay the findings to the group and set up your cadence of meetings to progress these ideas into solutions – however that may be for your organisation.

Congratulations, you’ve empowered a team to codesign a prioritised list of challenges and potential solutions that should easily translate into a work management system. Now get building

One final note

If this sounds like it would be valuable to you, but you’re not confident you could run the workshop, well, it’d be remiss of me not to say I know a consultancy that might be able to help 😉. If you’d like to chat about me and my team running this for you, please grab me at the email below.

All the best,
Adam

It’s been a busy couple of weeks, and things are really starting to motor at Hypercube Consulting – we’re in the early testing stages of our new MLOps-managed service and working with our first customers to iron out some wrinkles. If you’re an energy company seeking support with MLOps and data platforms, we should talk.

The wrong ladder

I presented at the MLOps Community Scotland meetup this week and had a great conversation with a senior techie asking about potentially becoming a manager. Like many capable people, after a few years of high achievement, this person found themselves at a crossroads:

• Do they continue to try and advance their career as an individual contributor?
• Or do they make the switch to the management track?

Not an easy question.

In many cases, the management track can be a faster route to more responsibility, compensation, opportunities, and the most senior leadership roles in an organisation. Be careful though, many climb “the ladder” much faster only to realise the view isn’t what they expected, and it was the wrong ladder all along.

For anyone looking at management solely to progress up the org chart as quickly as possible, I’d advise reaching out to as many sane managers as they can (rare in some organisations) to get the best view they can on what it is really like.

If you have other motivations or just aren’t sure, let me share some of the primary considerations from my experience and the second-hand experience I’ve learned from colleagues and customers over the years.

Why would you want to be a manager anyway?

First, the good bits.

For me, the most compelling reason to get into management is the impact you can drive. Even the best individual contributors have their limits and often need the right environment and support to reach their potential. Getting multiple talented people to collaborate effectively on the right work at the right time is no mean feat. Building and supporting that environment for success can be incredibly rewarding.

The personal relationships you develop have the potential to be some of the most rewarding for both you and the reports you serve. You have the opportunity to make someone’s working week more meaningful and more enjoyable for them. This is not always the case, many people don’t want to be best pals with their manager, and that’s fine. But it does happen – I’ve helped more than one person struggling with their mental health find more enjoyment and fulfilment from their work, and we’ve become great friends as well as colleagues.

There are other great things about management: getting the wider picture, seeing more of the business, shaping the direction of things, and collaborating with bright people, to name a few.

There’s plenty of rough stuff, though.

Some of those higher-level meetings can be the worst hours of your life. And I’m not just talking about the seemingly endless soul-draining carousel of weekly and monthly roundtables that should be emails. I mean the really tough meetings – layoffs, performance reviews, budget cuts, or the ones where cross-functional politics and animosity reach boiling point and it the tension is unbearable. As a manager, this is some of the worst stuff you’ll encounter and depending on the organisation, it can be more common than you think.

If you’re not comfortable having uncomfortable conversations – management isn’t for you. You absolutely can’t let people get away with poor behaviour because you’re not able to have the conversation.

What if that offensive “joke” did actually alienate someone? Or is it just a small sign of far worse behaviour that’s hidden from you as the manager?

What if the poor performance gets worse or spreads to other members of the team that see there’s no real recompense for slacking off?

As data professionals, we often get into our roles for the technology, but management really is a people game. We love looking at the numbers and the trends, but this can be hard when it’s down to individuals. You’re dealing with people’s careers and lives, their emotions and ideas, and even their self-worth for some career-focused individuals.

I’ve had to make people redundant due to budget cuts. I’ve had to call people out for sexist comments. I’ve had to chastise team members, leading to whole teams no longer treating me as a friend.

If you’re not ready for this, management can be a bumpy ride.

Final thoughts

I love being in management. But it’s hard. Don’t get into it for the wrong reasons.

All the best,
Adam

This week’s issue is sponsored by DesignRush.com, a leading B2B Marketplace connecting businesses with verified agencies – and it’s free to post your projects on.

If you are looking for proposals for a digital project – anything from AI and software to app development and more, DesignRush will help you match with the right agency that fits your budget, timeline, and other requirements.

Want to get started? Submit your request for proposals here.

Whose budget is this anyway?

One of the biggest challenges of being a manager in a tech-driven organisation is getting the approvals and sign-off to go after something you and the team know will have a positive impact. Maybe you’ve run through the Art of the Possible Workshop (here and here) or even have a full data strategy – your stakeholders are aligned, enthused, and understand what data can do for them. But how do you take that positive energy and turn it into action?

This week’s issue is sponsored by DesignRush.com, a leading B2B Marketplace connecting businesses with verified agencies – and it’s free to post your projects on.

If you are looking for proposals for a digital project – anything from AI and software to app development and more, DesignRush will help you match with the right agency that fits your budget, timeline, and other requirements.

Want to get started? Submit your request for proposals here.

The answer to this question in many organisations is the Business Case.

Essentially, a business case captures the reasoning for initiating a project or task. It is often presented in a well-structured written document, but may also sometimes come in the form of a short verbal argument or presentation. The logic of the business case is that, whenever resources such as money or effort are consumed, they should be in support of a specific business need.

An example could be that:

• a software upgrade may be costly in terms of time and monetary investment
• but the business case is that better performance would improve customer satisfaction, require less task processing time, or reduce system maintenance costs.

Why use a template?

Business cases give your organisation a standard document to capture all the commitment and decision making inputs for projects. But let’s face it, creating a business case from scratch can be time-consuming and overwhelming.

That’s where business case templates come in. They provide a proven structure for developing, evaluating, and writing your business case and recommendations.

With templates, you’ll have a valuable resource that you can use for all your projects, no matter their size or type (some organisations go so far as to have specific templates for different project sizes and types). By using a template, you can communicate your recommendations and strategic rationale effectively and ensure that you include all the information necessary for decision-making.

Good business case templates contain all the critical information required to get approval for the project; including:

• The strategic reasons for doing the project
• The business options evaluated, including the base business options of do nothing, so something, or do something else
• Project and operational costs
• Project and operational timescales
• Benefits, expressed in quantifiable terms
• Investment appraisal (or cost-benefit analysis); and
• Major risks and their mitigation plans.

If this all seems like a bit much, I’ll share the template I most commonly use below.

The Template

This template has evolved over the years working across various teams and industries to arrive at something that captures the core of a good business case. It may need tweaking to your specific organisation, or certain parts might need more emphasis (I’d stress timelines, safety, and security elements more if I was working with a nuclear power station than with an ice cream shop).

I advise using a whiteboard to work through this, either physical or digital and running this as a workshop (some inspiration for building that workshop can be found here).

Simply work through the sections in order and capture answers for each.

1. Opportunity

• What’s the problem/challenge/opportunity?
• Who are the main stakeholders and end-users?
• Why should the organisation care?

2. Solution

• What are the proposed solutions?
• How do they relate to the opportunity?
• What else has been considered and rejected?

3. Benefits

• Why should we do this?
• What are the intended outcomes?
• Clearly state the the financial and non-financial benefits.
• Can we calculate the ROI?
• Can we quantify any reductions in current risks this brings?

4. Scope

• What investment does the solution involve?
• What is defined as in scope?
• What’s marked as out of scope?
• How much time, resource, and technology is required?
• How does this align to the data/tech/business strategy objectives?

5. Stakeholders

• Who are the stakeholders? (Can we write a RACI Matrix?)
• Who owns the data? The analysis?
• What are their key interests, issues, and driving factors?
• How engaged are they and how much will they need to be involved in the delivery?

6. Resources

• What data sources are required? Do we have access to them?
• Do we have the necessary infrastructure/data platform?
• Do we have the skills to build this solution?
• Who from the company is needed?
• Do we need support from third-parties? Vendors?

7. Risks

• Score the risks by likelihood and impact.
• From this scoring, what are the highest concerns?
• How can they be mitigated and reported on?
• Have we considered regulatory concerns (e.g. GDPR)?

8. Costs

• What are the cost estimates?
• Can we split this by CAPEX and OPEX?
• How much does this cost to support and maintain going forward?
• Does this need to be reinvested again in the future?

9. Metrics

• How can we quantify success?
• What are the artefacts and deliverables?
• How do these metrics feed into higher-level reports?

Take each of these sections and line them up as columns on your whiteboard. Write the questions equally spaced as subheadings for each column, then let your participants use post-it notes to submit and collaborate on their answers.

Once you have worked through this on a whiteboard you should have plenty of material to produce a document. Use the same section headers but talk through each of the answers in a concise and objective manner. Attach any figures or graphs generated in support of the business case.

Include an executive summary section that lists the top level costs, timelines, and impact as well as a one-paragraph overview of the proposal.

The objective here is to capture all the relevant information so that any decision maker can see what has been considered and refer back to this document once a decision is made. These can also act as living documents for larger projects or things that need more analysis before a decision is made.

Final thoughts

There are plenty of ways to build a business case – some can get really complicated. If your organisation doesn’t have a process or it’s something you’re new to, using a template can help you quickly get most of the way there quickly. Feel free to adapt and alter this to your specific context – and good luck with your project!

All the best,
Adam

In today’s digital age, most organisations understand that data is the lifeblood essential to stay ahead of the competition. However, convincing decision-makers to invest in data and analytics can often be challenging. This guide will discuss how to build a strong business case to help your organisation see the value of data and analytics.

I wrote about the discovery process for a business case here:

In this post, we’ll talk more about the need for one and outline a template for the document structure.

Establishing the Need for Data and Analytics

The first step towards building a convincing business case is establishing the need for data and analytics. This can be done by evaluating the current state of data management and analysis within the organisation.

• Are there gaps or inefficiencies in current data processes?
• Does data quality need improvement?

Once you acknowledge the shortcomings, it is easier to highlight areas that can be improved with data and analytics.

Modern businesses that invest in data and analytics have a competitive edge over those that don’t. With data analytics, businesses can gain customer insights, track buying habits, and make informed decisions.

Establishing the need for data and analytics is crucial for any business looking to stay competitive and improve its operations. By analysing your current data management processes, industry trends, and competition, you can identify areas for improvement and make informed decisions that drive growth and success.

Evaluating the Risk of Data and Analytics

Every investment comes with some level of risk, and data and analytics are no exception. Therefore, assessing and mitigating these risks is an essential part of building a business case. Risks can include things like technological challenges, lack of employee training, or inadequate data security.

You really need to convince the decision-makers that the pain of change is worth it and that you’ve considered everything before making the recommendation.

It is crucial to address risks upfront and establish a clear roadmap for data and analytics initiatives. Begin by evaluating current data security protocols and identifying any loopholes that threaten the safety and confidentiality of sensitive data. Ensure your organisation has the right technology, infrastructure, and personnel to support data analysis efforts.

In addition to evaluating technological risks, it is also essential to consider the potential impact of data and analytics on your organisation’s culture and operations. For example, introducing new data-driven processes may require significant changes to existing workflows and employee roles. Therefore, it is essential to communicate these changes clearly and provide adequate training and support to ensure a smooth transition.

Another potential risk to consider is the accuracy and reliability of the data itself. Inaccurate or incomplete data can lead to flawed insights and poor decision-making. It is important to establish data quality standards and invest in data cleansing and validation processes to ensure that your analysis is based on reliable and accurate data.

Finally, it is important to consider the potential legal and regulatory risks associated with data and analytics. Depending on your industry and the type of data you collect and analyse, you may be subject to various data privacy and security regulations. Understanding and complying with these regulations is critical to avoid legal and financial penalties.

By taking a comprehensive approach to risk assessment and mitigation, organisations can build a strong business case for data and analytics initiatives and ensure they are positioned for success.

Assessing the Return on Investment of Data and Analytics

Once you have established the need and addressed the risks, it’s essential to assess the ROI of data and analytics initiatives. The ROI of data and analytics includes both financial benefits and non-financial benefits like reduced operational costs, customer satisfaction, and improved decision-making.

Calculating exact ROI can be tough for many tech initiatives. Don’t make the mistake of telling the CEO about your model evaluation metrics either. I try to keep things to these categories when communicating to stakeholders:

• additional revenue generated
• additional costs saved
• time saved
• new achievable scale (e.g. a document classification model can now process 1000s of documents in the time it takes an expert to do one)
• risks mitigated (either likelihood or impact reduced)

Anything outside of these tends to be less generally understandable and more difficult to immediately understand.

It’s essential to identify specific goals and KPIs that you want to achieve through data and analytics to evaluate ROI accurately. These goals should be specific, measurable, attainable, relevant, and time-based. Use these goals as a benchmark to measure success throughout the project’s lifecycle.

Measuring the Success of Data and Analytics Initiatives

Measuring success is integral to understanding whether your data and analytics initiatives are successful. Initially, set out clear performance benchmarks and monitor progress against these benchmarks. With the right data tools, it’s possible to gain insights into the impact of the initiatives in real time.

Investing in data training for staff is also essential to interpreting data analytics and unlocking insights. This builds data literacy within the organisation and helps to ensure that decisions are data-driven.

A Template Business Case Structure

Executive Summary:

• Briefly outline the proposed project and its objectives.
• Provide a high-level overview of the potential benefits and estimated costs.
• Emphasise the potential impact on the organisation’s data and analytics capabilities.

Business Objectives:

• Clearly articulate how the proposed project aligns with the organisation’s data and analytics strategy.
• Describe how the project will contribute to specific business goals, such as improving customer engagement, increasing revenue, or reducing costs.
• Explain how the project supports the organisation’s overall mission and vision.

Problem Statement:

• Describe the current data and analytics challenges faced by the organisation, such as data silos, poor data quality, or a lack of actionable insights.
• Explain how these challenges are impacting the organisation’s operations or performance and why they need to be addressed.
• Use data and analytics metrics to illustrate the scope of the problem and the potential benefits of a solution.

Proposed Solution:

• Outline the specific data and analytics activities, resources, and deliverables required to achieve the project objectives.
• Explain how the proposed solution addresses the identified data and analytics challenges.
• Describe any new technologies, tools, or methodologies that will be implemented as part of the project.

Benefits and ROI:

• Identify the potential benefits of the proposed project in terms of data and analytics outcomes, such as improved data quality, faster time-to-insights, or increased data-driven decision-making.
• Use data and analytics metrics to quantify the project’s potential impact, such as increased revenue, reduced costs, or improved customer satisfaction.
• Calculate the expected return on investment (ROI) for the project, taking into account both financial and non-financial benefits.

Cost Estimate:

• Provide a detailed breakdown of the costs associated with the proposed project, including any hardware, software, or personnel costs.
• Explain how the costs were estimated and justify the investment based on the potential benefits and ROI
• Consider the long-term costs of maintaining and scaling the solution, and include these in the cost estimate.

Risks and Mitigation Strategies:

• Identify potential risks or obstacles to the successful implementation of the project, such as data privacy concerns, technical limitations, or stakeholder resistance.
• Develop strategies to mitigate these risks, such as developing a data governance framework, conducting user training, or piloting the solution before full-scale implementation.
• Consider the impact of external factors, such as changes in regulations or emerging technologies, on the success of the project.

Implementation Plan:

• Develop a detailed timeline for the implementation of the project, including key milestones, deliverables, and dependencies.
• Identify the roles and responsibilities of each team member involved in the project.
• Consider the resources required for implementation, such as personnel, hardware, and software, and ensure that they are available and allocated appropriately.

Conclusion and Recommendation:

• Summarise the key points of the business case, including the benefits, costs, risks, and implementation plan.
• Provide a clear recommendation for whether or not the proposed project should be approved and implemented based on the potential impact on the organisation’s data and analytics capabilities and the expected ROI.

Final Thoughts

In conclusion, it can be difficult to get buy-in for a data and analytics initiative if you don’t know how to make the argument. Several factors go into building a strong business case for data and analytics, from recognising the need for it to assessing the ROI and mitigating potential risks. By following a well-defined roadmap and setting clear goals, you can work with your organisation to unlock the benefits of data and analytics and gain a competitive edge in the market.

All the best,
Adam

Wallaroo – the purpose-built platform for last mile ML – is the sponsor for this week’s issue.

Wallaroo is a great end-to-end MLOps tool with some amazing features for complex deployments (I wrote more about this here).

Download the free Community Edition here, and there are a load of excellent tutorials here.

I will continue through the four-question framework I use to build actionable data strategies this week (introduced here). We’ve covered getting an understanding of an organisation’s current data landscape in this article. Now we’re going to talk about goals and ambitions – what does good look like in this context, and is it achievable?

The TL;DR for this stage is:

• ask the end-users and business stakeholders what pain points and opportunities they spot with data across their daily workflows
• filter out the ideas that don’t align with the larger business strategy (and be wary of whole application/software replacements – that’s not just a data thing)
• identify what key metric or value-driver these initiatives are going to impact and how.

But let’s start with a pitfall.

Setting expectations

One of the biggest challenges many organisations have comes from the nature of best practices and industry news. It’s easy to get caught in a bit of a trap about taking state-of-the-art solutions or processes seen at the latest keynote and trying to copy-paste the ideas directly into their own context.

The trap is that many of those ideas aren’t written by organisations like yours. They’re often written by industry leaders and big-tech companies with very high data and analytics maturity, with data and machine learning at the core of their value drivers. Jumping straight to these solutions, copied straight from a blog post without all the organisational learning and understanding that went with developing them can be dangerous and wasteful.

We need to take inspiration from the business users in the organisation at hand. And that’s fine. It’s not a lack of ideas that usually holds them back (although if it is, I’ll cover that in another post soon).

A wealth of great ideas

People are smart. Most people working with data will understand that there are things that can be done. They’ve read the blog posts, tinkered with the tools, and spoken to former colleagues and industry peers. When you ask them what they want to do with data, don’t be surprised if you’re quickly swamped with ideas.

This can be great.

By listening to the stakeholders (over the techies), you’ll be grounded in the real pain points and opportunities that drive the day-to-day of the business. Not just aligning with the latest technology trends or cult-like communities.

The technologists will get their time to shine in enlightening the end-users with the “Art of the Possible” or tempering their enthusiasm in reality.

But if you don’t know the organisation or context as well as they do – how do you know where to start?

We need to find the balance between:

• what is going to deliver the most impact
• what activities carry an acceptable level of risk
• what is going to drive success and adoption across the organisation
• and what is actually achievable.

We’ll do this in parts.

It’s strategies all the way down

Now “strategy” is a devalued word and gets thrown about by consultants a little too much (sorry!). But I’m a strong believer in being explicit and giving simple definitions so here’s mine:

A set of plans to achieve long-term goals and ambitions with measurable deliverables, designed within the limits of the practices, guidelines, and resources available to an organisation.

Each business should then have an overarching strategy to achieve its longer-term goals, and data strategies should directly feed into and align with that. In some cases, the data strategy will be aligned to some larger strategy of the organisation (most commonly, the data strategy feeds into the technology strategy, much like the sales and marketing strategies should feed the commercial strategy).

This gives you the golden filter through which all “great ideas” should pass.

How does this initiative drive a positive impact to the higher-level strategy?

If something isn’t clearly aligned with the wider business strategy or its value can’t be articulated well, then it needs more thought.

What’s this metric for anyway?

You should now have a long list of ambitions, goals, and project ideas linked to real pain points and opportunities. These ideas should span the business (or at least the subsection of the business you’re working with) and should be loosely aligned to the overarching strategies the business is pursuing.

But loosely aligned isn’t good enough.

Essential for the last phase of building our data strategy, prioritisation, we’ll want to get a clear understanding of how to quantify the impact of these ideas. How does implementing the above move the needle?

For this, get your stakeholders to link the deliverables from these projects to metrics. If your business has existing key metrics, results, and performance indicators (OKRs, KPIs, etc.) it uses then these are great first candidates.

Sometimes, a function or team will want something that isn’t clearly linked to existing indicators. That’s fine – part of writing a new strategy should involve challenging the existing ways of working. Have the team come up with something measurable and quantifiable for these cases. If they can link it to either money, time, or risk measures you’re in a really good spot.

You might be tempted to get into estimating impact at this stage, but I’ve found it’s better to do that later. Go through the next phase of the data strategy framework (“How do we get there?”) and come back to impact at the last phase (“Where do we start?”). The added calendar time between ideation and impact assessment lets stakeholders review, update, and edit their ideas with a fresh set of eyes (spoiler alert, they’ll want to change things).

Results

You now have a great long list of things the business wants to achieve to improve the day-to-day workings of the teams with their data. You’ll have everything from data lineage and catalogues to better BI reporting to fully-fledged automated machine-learning solutions churning through streaming datasets.

The point at this stage is to get people excited and engaged, but also to understand what good looks like in their eyes – and align that vision with the actual business strategy.

There is a lot of information gathering and collaboration in this process stage. I use a mix of workshops (typically following the perfect workshop blueprint), surveys, and interviews to do this. I’ll try and get some templates together and posted here for easy replication in the future if that’s something readers are interested in.

We’ll start to create a roadmap on what it would take to achieve this next. Then finally we’ll look at what’s possible and where to start.

Bit of a long one, but hope it was worth it. As always, any feedback on the issues or what you might want to read in the future is greatly appreciated.

All the best,

Adam