Data Science and Analytics Strategy: An Emergent Design Approach

It's a It's a really common challenge, isn't it. You know your organization needs to leverage data, I mean properly leverage it, but just figuring out where to start. How do you even build that capability? It can feel well, completely paralyzing sometimes.

Yeah, like staring at this huge ocean. You know there's something valuable out there, but the map seems missing.

Exactly that feeling of being overwhelmed. The potential is massive, we all see that, but the actual path yeah, not always clear.

It's understandable. There's so much noise, so many options, it's easy to get, you know, bogged down.

And that's exactly what we're diving deep into today. We actually had a request from one of you asking for a practical guide. Ah yeah, someone looking to strategically build data science and analytics functions, but crucially without needing this like huge upfront investment or getting lost in planning forever.

Right, makes sense.

So we're going to unpack the key insights from data science and analytics strategy an emergent design approach. It's by Kayla Shawadi.

And Alex good Choice. It offers a really useful perspective. Our goal here is basically to pull out the actionable advice from the book give you a clearer, maybe step by step feel for how you can develop these capabilities. And the key thing to remember really is that this isn't about reaching some perfect end state overnight.

No, definitely not.

It's much more of a journey, you know, learning, adapting, growing as you go.

Okay, so let's get into it. The book kicks off by looking at why those traditional, very rigid data strategies often just don't work out.

Yeah, they often fail to deliver.

It even points to that Harvard Business Review article is data scientists still the sexiest job of the twenty first century? Remember that one?

Oh? Yeah, that highlights some of the let's say, traps for the unwary when setting up these functions.

So what are those main traps? What goes wrong with the old school approach?

Well, one big one is rushing in hiring data scientists, buying the flashy tech before really nailing down the business problems they're supposed to solve.

This sexy java lure takes.

Over exactly, it distracts from the groundwork. And then there's this great concept the book introduces, the corporate immune system.

The corporate immune system tell meymore.

It's that, you know, inherent organizational resistance to big changes, like your body fighting off a cold.

Okay, I can picture that.

These big, top down, prescriptive strategies, they often trigger that resistance because they feel disruptive, maybe even threatening, imposed from above.

Right. Yeah, we've probably all felt that pushback at some point. So if that traditional, heavily planned way hits this wall, what's the alternative? What does emergent design offer.

Emergent design is well, it's much more flexible, more responsive, instead of these huge detailed plans that are probably outdated the minute you print them. Sure, it focuses on setting a clear direction and then learning and adapting as you go.

Iteratively, Well, that's about mapping every single step, more about setting a course and then adjusting based on what you find.

Precisely, it's how much more evolutionary.

The book uses this really interesting analogy. It talks about the strategist being more like a midwife rather than an expert. What does that actually mean in practice?

It means, especially early on, your role is more about facilitation, less about coming in saying I'm the expert, here are the answers, and more about helping the business give birth to its own solutions if you like. It's about engaging with different departments, facilitating conversations to really understand their core challenges.

So it puts a big emphasis on problem finding.

Huge emphasis really digging deep to uncover what keeps people up at night, and.

It actually suggests asking that specific question, right, what keeps you up at night? Go ask sales operations HR yes, get.

Them to articulate their main pain points. Sandra Hogan, who's quoted in the book, even suggests starting right at the top, ask the.

CEO, I understand the being picture first.

Exactly, get the CEO's vision the main organizational challenges, and then you can tailor those conversations with other leaders to make sure everything aligns so.

You ensure the data stuff you do actually tackles the most critical business needs.

Right and crucially, the book stresses showing value early tangible results through what they call proofs of value, not just proofs of concept, not just technical feasibility no Criicknapier makes this point well in the book. You need to demonstrate actual business benefit quick wins that show this approach works.

Okay, that makes a lot of sense. So you found some key problems using this collaborative method. Now you need the tools, the infrastructure, the team. The book talks about building the data analytics stack. Can you break that down? What are the basic pieces?

Sure, at a high level, you've got a few key stages. First is data ingestion getting the data in from all the different source systems okay. Then data storage keeping it safe and accessible. Then data processing that's the cleaning transforming, getting it ready for analysis.

A messy part, often often the messiest.

Then the analysis itself, finding the insights, answering the questions, and finally data consumption how those insights get to the people who need them, reports, dashboards, apps, whatever it is.

And the book really hammers home the incrementally part of building this right. Start with what you've got.

Absolutely, leverage existing tools, existing infrastructure as much as you can. Initially, don't feel you need the shiniest new thing right away, so resist.

The urge to buy everything immediately.

Definitely, And a key principle is matching your data ingestion frequency how often you pull data in with what you actually need for analysis.

Meaning if you only report weekly, maybe you don't need real time data streams for everything exactly.

Batch processing might be fine, but there's an important caveat. The book mentions operational alerts think manufacturing IoT sensors.

Ah, right, where you need to know now if something's wrong.

Yes, for those critical operational systems, real time data is obviously essential.

Got it. And then there's the team structure. Sure, the book mentions BI developers, analysts, data scientists, data engineers, architects. Sometimes those lines feel a bit fuzzy.

They really can be, especially in smaller teams or organizations just starting out. But broadly, think of BI folks as focused on the what.

Happened reporting dashboards right looking back.

Data scientists are more about the why and what might happen next. They dig deeper, build predictive.

Models, forecasting, understanding drivers exactly.

And data engineers or architects they're the builders. They create and maintain the underlying infrastructure, the data pipelines, making sure everything is reliable and performs well.

The foundation, the foundation.

But yeah, the book acknowledges it's often blurry. People wear multiple hats.

That clarification helps. And you mentioned predictive models. The book touches on supervised versus unsupervised machine learning. Quick explanation for US Dragon free.

If possible, Okay, let's try. Supervised learning is like like learning with a teacher or flash cards. You have data that's already labeled with the right.

Answer, like emails marked spam or not spam.

Perfect example. The algorithm learns from those labels to classify new emails or regression. Another supervised type predicting a continuous number like a house price or sales figures based on labeled historical data.

So you know what you're aiming for.

Yes, you have a target. Unsupervised learning is more like exploring. You don't have labels. The algorithm's job is to find hidden patterns or structures in the data itself.

Like grouping customers together based on behavior exactly.

Customer segmentation is a classic example, finding groups you didn't even know existed. The book also gives a nod to deep learning, especially for unstructured stuff like text and images, right, the complex stuff, but it also wisely points out it's not always the magic bullet, especially for standard you know, tabular data. Sometimes simpler models work better.

Okay, useful distinction. So you're building the tech, assembling the team, but the book is very clear technology isn't the whole story. You need to cultivate a data driven culture. What does that actually look like?

It means creating an environment where using data to make decisions isn't just like a special project, It's just how things are done everywhere, ingrained in the day to day exactly. Technology is just the tool. The real shift is in people's mindset and behavior, and the book suggests several ways to nurture this. One is finding and growing talent.

Internally, not just hiring externally.

Right, maybe offer introductory courses, say in Python, across different departments. You might uncover hidden talent, people who are really keen on data but never have the chance upscill your existing folks.

I like that, democratizing it a bit. The book also talks about internal hackathons like it Lassians ship it days, but maybe smaller scale to start.

Yeah, even mini hackathons can be fantastic, great for learning, trying new things, getting different teams, collaborating on data problems. Plus they can be fun, create some buzz definitely. And then there are things things like communities of practice, do heat a catapo shares experiences on this, or data champions networks. Kyl Ash mentions this ways to connect people interested in data across the organization, spreading the knowledge and enthusiasm precisely.

And not just for the data team right. Ian Jackman and zanvan Wick emphasize.

This, No, absolutely not. Data literacy is for everyone. It's about understanding data, being able to interpret it, question it, think critically about its quality and how it's being used. Sandra Hogan calls it empowering the business community.

And there's that key phrase. Data doesn't make decisions.

People do crucial point data informs, but humans decide, which brings in the need for critical thinking skills across the board. Tim van Gelder's definition is great the art of being right, partly by considering how you might.

Be wrong, thinking critically about the data itself. Okay, makes sense now, shifting gears slightly, actually choosing the technology. That landscape can feel incredibly complex. Any practical guidance from the book.

Yeah, it offers some solid advice. First, maybe start with cloud providers. Your organization is already.

Familiar with less friction that way usually. Yeah.

It mentions the Big three AWS, AZURE, GCP and notes that since many orgs use Microsoft Tools. Azure often feels like a natural starting point for the bi side of things, but a really important theme is interoperability. Design things to be modular, API driven avoid getting locked into one vendor. Ian Jackman really stresses this.

Future proofing essentially exactly needs change.

De Weeeda Katapou gives an example of her org moving from Redshift to Snowflake because Redshift struggled with their Jason data needs at the time. You need that flexibility, good example. What else, usability for the team is key. Heima Prosade makes this point. If the tools are clunky or hard for your data folks to use, adoption just won't happen.

Makes sense, Keep the users happy.

And don't forget the ongoing effort to keep the lights on or ktlo work needed to maintain any data product or platform that needs factoring in.

Right, it's not just build and forget and the process for choosing, it's just.

The structured way brainstorm your decision criteria collectively, get input from everyone affected. Then maybe use something like pair wise comparison, comparing options side by side on each specific criterion to help make a rational choice.

Okay, methodical approach. So we've got tech team culture selection. What about governance and ethics that feels increasingly important, hugely important.

The book frames data, governance and ethics not as nice to have as anymore, but absolute, must have, non negotiable pretty much. Governance provides the rules of the road. The processes rolls responsibilities for managing data well, ensuring quality, security compliance. Think DAMA definitions, managing availability, usability, integrity. Security sounds potentially massive that it can be, But the advice, echoing fvirus Hamden's experience is start small. Build governance based on the

Bias can creep in easily.

Very easily. The book uses a great phrase data does not speak for itself. It depends on perspective, how it was collected, how it's interpreted. The example given is how different Sydney suburbs might look depending on which data points you choose to highlight right.

Context matters hugely.

Plus, you have regulations like GDPR, data privacy rights, the right to be informed, access erasure and so on. These have to be built in.

So responsible AI needs thinking about from the start.

Absolutely. Doctor Lean's point in the book is about building in diversity from the beginning to encourage ethical discussions. Frame it using the language your organization understands. Maybe it's risk management, maybe it's core company values, maybe it's sustainable development goals. Find the hook to embed ethical thinking.

Okay, that brings a lot together. So wrapping this up, what's the single biggest takeaway from this whole emergent design approach to building data capabilities?

I think the core message is it's a process. It's not a project with a neat finish line. It's this ongoing emergent journey of learning, adapting, and constantly collaborating between the tech side and the business side.

A continuous evolution exactly. And for someone listening feeling maybe inspired, but still a bit unsure where to start, what's one concrete next step you'd suggest based.

On this, Start with the conversations, use the what keeps you up at night. Question Talk to different teams, Find one specific nagging business problem that data might.

Help with just one to start just one.

Then focus on delivering a small, targeted proof of value for that problem. Show a tangible win, however small, that builds momentum.

Great advice, and finally, a last thought for our listener to maybe chew on after this deep dive.

Maybe reflect on that idea of the ever changing reality borrowing from Claudiosubora. Things will change the market, the business, the tech. An emergent approach accepts that.

It embraces the flux right.

So think about how you can foster that ongoing dialogue, that iterative adaptation in your organization to make sure your data efforts stay aligned and keep delivering value as things inevitably shift.

A really powerful way to think about it, Fantastic Insights, Thanks so much for unpacking all of that with us today, My pleasure. We really hope this deep dive gives you, our listener, a clearer path forward on your own data journey. Thanks for joining us