Like 1 in 10 men, I am colorblind. I’m a “strong protan,” according to this free online test. I detect too much green light, which prevents me from seeing the full spectrum of reds. Many reds look more like greens to me or less bright than they do to you.

I can still see colors though. I see approximately 150,000 of them, including many reds. That may sound like a lot, but the average person sees 1.5 million colors. So I see an abysmal 10% of the shades that you probably see.

It’s hard to overstate the importance of training - especially within BI and data science. There’s an overwhelming amount of data tools on the market. An experienced employee moving from one company to the next seldom knows the full tech stack going in.

That almost guarantees that every company needs to train their data team on something. But that need isn’t always met.

When I decided to write my first book, Data Work: A Jargon-Free Guide to Managing Successful Data Teams, I wanted to create something that didn't read like most business books. Ideally, readers would find it both easy-to-read and practical.

The practical part is hard though. It's easy for business theories to sound great on paper, but fail in the real world. But there are some foundational concepts in data work that determines whether companies succeed or fail with their BI solutions.

I've worked with dozens of data teams, as both a consultant and as an employee. The best teams didn't necessarily have the best talent, the best technologies, or even the most innovative projects – they simply had good habits.

Since the book's release, I've learned that many readers agree with me. Here's what they said about the book's message and concepts:

I read an  article in the Harvard Business Review lately and saw this interesting quote:

It’s this same problem that Pucciarelli described that inspired me to write my book, Data Work: A Jargon-Free Guide to Managing Successful Data Teams.

Originally, I was going to call this book How to Identify and Fix Data Quality Issues. I had worked for a company and discovered that its data was a complete mess. Every solution implemented and every technology adopted failed to produce accurate data on an on-going basis.

Our stakeholders had noticed this too. Many stopped using the reporting we delivered. While they passively contributed their inputs to the data solutions, they also made use of other data reporting tools that they trusted for their own work.

Basically, we had produced a zombie solution. One that had little real life in it, but kept walking along nonetheless.

While I felt I had found cool and novel ways to identify the data quality issues, it never seemed to improve things. And as I researched the root cause of these problems, I learned a harsh truth – it wasn’t one person’s fault. 

The two data teams, and the many other individual contributors, were not set up to scale the way we did. I, as the report developer, didn’t have the ability to ensure the accuracy of the data engineers. The data engineer didn’t have the ability to ensure the accuracy of the various subject matter experts whose UTM parameters we depended upon. And those subject matter experts had little training or incentive to maintain consistency with their inputs.

In other words, it was an operations issue. And if we could tackle those operations issues, there was almost no need to identify data quality issues. They'd simply dissipate.

There’s a popular phrase tossed around nowadays called data-storytelling.

I have a love-hate relationship with this topic. For one, I think it’s a bit of a corny term. It’s often said that a good analyst “tells a story” with the data, even though much of our work doesn’t have a narrative to it. I think the more accurate phrasing would be that good analysts “answer a question” with the data. Then again, “data-answering” doesn’t have the same ring to it.

The term data work covers the various fields of data science, business intelligence, digital analytics, etc. If your profession touches data in any way, it’s considered data work.

Data worker covers any professional that works in data work. Whether you’re a data scientist who optimizes machine learning algorithms, a PowerBI developer building dashboards, or a marketing analyst who adds tracking to websites – you’re a data worker.

One of the annoying things about data science, analytics, and business intelligence is that all the terms used to describe our industry mean different things to different people.

When I interviewed people for my book, one of my favorite questions was to ask people “What does the title Data Scientist mean to you?”

I got a different answer almost every time.

This becomes a problem for people who write about data work-related topics, like myself. When I wrote my book, Data Work: A Jargon-Free Guide to Managing Successful Data Teams. I mostly had reporting teams in mind while writing it, but the advice is applicable to most other teams in the data profession.

Whenever I referred to someone that worked in data, I would call them business intelligence developer on one page, analyst on the next, and data professional later.

Same thing with the actual industry name. Business intelligence implies reporting. Data science implies machine learning. Analytics implies… well, whatever the person you’re talking to thinks it implies.

Adopting the terms “data work” and “data worker” solves these problems for those who write about data.

I’m happy to share that my long time book project, Data Work: A Jargon-Free Guide to Managing Successful Data Teams, is now for sale.

Read more about the book below.

It's easy to do well in data and analytics. It's one of the few job markets that favors employees more than employers. It comes with good pay, interesting work, and an abundance of remote work opportunities.

It also offers a wide range of industries to work in. Here is just a sample of the work people in data have accomplished:

• Optimizing the messaging used in advertising
• Predicting box office revenue for new movies
• Identifying police officers at risk of using excessive force
• Predicting hospital patients at risk of sepsis – a life threatening condition

All of these outcomes wouldn’t be possible if it weren’t for the armies of data engineers, data analysts, data scientists, and many others who build programs to track, transform, and analyze the world’s data.

Whether you love programming, analysis, or storytelling, there's a place for you in data analytics.

On December 21st, 2020, I started my dream job. I had finally made it into the most prestigious role in data and analytics – I was a bonafide data scientist.

It’s funny because one year and two months earlier, I thought about leaving analytics for good. I found myself stuck in the reporting trap – where it seemed like the only thing I could ever produce was another Tableau dashboard – despite my best efforts to move towards analysis work.

I didn’t feel like I had control over my career. It seemed like other people made those decisions for me. Every time I did something outside dashboard work, I’d hear the most horrific words you could ever hear at work: “that’s not really your job to worry about.”

And so I drew a line in the sand. I said no more. I got in this field to use statistics and programming to find cool insights and make real world predictions. That’s what I’m going to do.

I left my job – one that paid well for easy work – without another lined up – a move that concerned family and friends alike.

I devoted myself to finding the data scientist role I always wanted and managed to finally do it one year later.

It’s hard not to feel like one of the lucky ones. Many other people aspire to become data scientists. It’s not uncommon to see openings for data scientists to have hundreds of applicants.

That’s understandable. On average, data scientists make about $120k a year. The work-life balance is generally pretty good and the work is intellectually rewarding.

After landing my dream job, it didn’t take long for other aspiring data scientists to contact me on LinkedIn to ask me – ”how can I land this sweet gig?”

Well… it depends on who you ask. I knew many other data scientists and I had asked them all the same thing. There were some overlaps in their answers, but there was also a lot of variation.

Some created project after project with Kaggle datasets. Others offered to work for free for existing data science teams. Others simply started doing the work of a data scientist at their current job and got promoted. And others just applied and got hired right out of the gate! Without a graduate degree no less!

And that’s the harsh truth about data science. Every data scientist has a different story for how they landed their dream job. As much as I wanted to find the silver bullet – the one true path guaranteed to get me a data scientist job – there really wasn’t one.

I had to find my own path and develop my own strategies. And it’s my hope that you learn from my journey with your own job search.

In the year between my last job and my new job, I had three broad strategies:

1. Demonstrating aptitude to potential employers through graduate school and side projects
2. Using my best medium (writing) to develop a reputation among the data science community
3. Good ol' fashioned networking
   
   

Just because the steps are simple and straightforward doesn’t mean they’re easy. I had to apply myself academically – for the better part of a year – and take significant financial risks – all on the chance that my plan would work.

Let’s go into more detail about how I used these strategies.

It’s easy to find work in data science and analytics – provided you have the right skills. While the pandemic certainly slowed things down, the demand for data skills remains strong. People with professional experience in SQL, Python, and R will likely find themselves hearing from recruiters more and more – much like they did before the pandemic.

When work naturally finds its way towards you, you might find yourself asking – does networking really matter in data science?

Yes. 100% yes. There's two big reasons why.