The Data Solutions Architect

What an individual contributor career looks like two decades in

I’ve spent my entire professional career in data. All two decades of it. And nearly 99% of it has been as an individual contributor (IC). There was that one time (no, not at band camp) when I tried to get into management. Didn’t like it.

I recently changed jobs internally into a solutions-focused role and had been struggling to come up with a way to describe what I do. Then one day it hit me: Data Solutions Architect! It has just enough latitude to allow me to continue learning even two decades later.

It fits perfectly with what I do and how I think about the impact I want to have. I really like the idea of collaborating across different areas of the organization, finding problems and designing and implementing high-leverage solutions.

But to me, “Data Solutions Architect” is more than just a title; it’s a mindset, a philosophy, a way of thinking if you will. Core to this philosophy is being comfortable in a structureless environment. While I still have a manager who gives me projects, I like to think beyond the projects.

This means becoming more proactive, looking for high-impact problems I can solve, propose solutions, sell them internally and then design and implement solutions for them. Whether you are in this position or not, this mindset shift alone is powerful enough to upgrade your career. And it’s not that hard.

There are only three pillars:

1. Finding high-leverage problems that can unlock massive organizational performance. I covered this briefly in another post

2. Collaborating and getting buy-in from different stakeholders across different business units, with different agendas and incentive structures

3. Architecting, designing and implementing robust, data-based solutions

As you can see the mindset is a combination of business knowledge, people skills and deep technical expertise. I don’t care how advanced AI gets, the person with this mindset is indispensable in any organization.

Since I don’t have the space here to expand on all the implications of adopting this mindset, I’ll just illustrate the ideas with an example. Let’s say you work for a SaaS company and your customer churn (the percent of people canceling their contracts) is higher than you’d like.

In this case the problem has already been identified. There’s just one “small” issue.

You were never invited to the meeting where the problem was discussed and without consulting you, the solution everyone came up with was to create a churn prediction model. Since you’re the “data person” you’re now being brought in to design and implement the solution.

How do you apply the mindset to this problem?

First of all while the problem of churn is definitely real, you should do your own analysis. Don’t assume that “churn prediction” is the right solution. This doesn’t mean you reject their idea. You want to be more tactful than than and you don’t want to butt heads with an executive you might want in your corner later.

So what do you do?

I would start by asking for more context about the problem. It’s the age of LLMs and everyone who has read anything about it understands the importance of context. So it’s perfectly fine to ask with a smile on your face: “Unless you want me to hallucinate like ChatGPT, I would like more context about this problem :D”

Let’s see how this might play out.

Them: “We want to lower customer churn so we can improve profitability and CAC/LTV ratio.”

You: “Ok, and so in order to lower churn and to do that you want to create a predictive model that tells you who is about to churn, right?”

Them: “Yes exactly.”

You: “Suppose you have this churn prediction model and it has identified that customer x is about to churn, what do you do next?”

Them (not having thought it out fully): “We can reach out to them, maybe call them or send them an email with an offer or something like that.”

You: “How do we know they will respond to the offer?” (Notice the use of we vs you)

Them: “Well we can try it and see.”

Let’s pause for a second and comment on the situation so far. As you can see this is an incomplete solution. A churn prediction model might be part of the solution but it doesn’t solve the churn problem directly. We have to consider what will happen with the output of the model.

At this point you have a choice. You can take the discussion into a number of more productive directions:

• Suggest a thorough analysis of churn to find the root cause. Maybe the problem is the original offer? Could it be the pricing? Lack of certain features? The prediction model will not help here.

• Suggest a quick and dirty version of the churn prediction model in order to test out various interventions (email offer, phone call, etc) This could be something you run manually before more time is spent automating it.

• Suggest something more grandiose for example a model that doesn’t just predict who is going to churn but also provides the right intervention (call, email, etc.)

If it was me, I’d choose the first option. But now we need to redirect the conversation towards that choice while making them think it was their idea. This is where the second pillar comes into play. The solutions architect also needs good people skills on top of the technical expertise.

Here’s how I might do it. Let’s pick up where we left off.

You: “Well, we can certainly try and see but wouldn’t it be nice if we knew exactly why they were canceling? That way we can send them the right offer.”

Them: “Can we do that? Can we figure out why people are canceling?”

You: “I think so. What would you suggest? How could we do it?”

Them: “Hmmm…..”

Now you’ve got them right where you want them :D

I’ll leave it there for now. If you like me to continue talking about the Data Solutions Architect mindset let me know by liking, commenting or replying to this email.

Until next time.