Spoiler Alert – They’re Not That Hard to Find
A common complaint I’ve heard in the business intelligence industry is how hard it is to find good people. I personally don’t think it’s that true, but from a consulting company’s perspective, the problem is twofold. First, your customers want to know how many years of experience your people have with a particular tool, and having those experience years with a piece of software that isn’t easily available to the public means it can be a seller’s market.
These days, when someone in the industry tells me how hard it is to find good people, it usually means one of two things: “I’m too cheap to spend the money on someone with the resume I need” or “I’m too focused on finding the people with the name brand skills (i.e., Cognos, Microstrategy) than people who have the equivalent skills”.
It’s Not Rocket Science, People
I don’t want to sound like I’m dismissing the number of years of experience a person has with a particular tool, but honestly, business intelligence is not rocket science. It’s mostly about moving data, querying data, and presenting data. In most cases, the data I speak of lives in relational databases. And here’s the thing, while there are a ton of flavors of relational databases, they’re fundamentally the same. They all pretty much speak the same language (SQL), and do the same core things (create, read, update, delete — aka CRUD). Sure, there are nuances and details a good business intelligence consultant needs to know, but if you are pretty good at SQL and know how a relational database works, you’ve got pretty strong fundamentals to start with.
A lot (but not all) of the business intelligence people I’ve come across didn’t start off as business intelligence people. In most cases (like Vince), fell into it when an employer bought the software and needed an internal resource to learn it. In rarer cases (like me), an employer hires a person with the right background to fast-track them into a position. When Vince first hired me over a decade ago, he saw that while I had a little direct business intelligence experience, but I also had a lot of enterprise software and web development experience to fill in the gaps.
When it comes to “home-grown” business intelligence people, I find there are two types. People who go through the motions, and people who really get into it (I’ll let you guess where Vince and I fall into that grouping). Too many people, in my opinion, just go through the motions. They know that access to the software is generally scarce, and don’t really bother expanding or deepening their skill sets too much. Vince is one of the most knowledgeable Cognos/Data Warehouse guys I know. That’s because he loves the problems he’s solving and he’s a pit bull when it comes to attacking those problems. He also loves learning new methods and techniques. Unlike Vince, my love for business intelligence is a little different. I love systems and visualizations. I was a huge fan of Edward Tufte’s information design principles before I even did anything called “business intelligence”. I love coding and doing root cause analysis. Because we come from different backgrounds, when Vince and I work together on business intelligence problems, we end up being greater than the sum of our parts.
Before we started Assign It To Us, I worked at a Cognos shop that Vince co-owned. To maintain our “partner” status with our software vendor, we had to have a certain number of “certified” consultants. Certification meant that you memorized parts of the training guide and were able to pick them out in a multiple choice exam. Neither Vince or myself bothered writing those exams (and speaking for myself only, I’m pretty sure I would have trouble passing them, as I’m not a great test-taker), but we were always the go-to people to solve the problems our certified people could not figure out themselves. How could this be? Vince generally knows how to use the tools better than me, and because of my background in enterprise software development, I generally have a better understanding of how the tools work under the hood. Because of that difference, we attack problems from two different directions, and more often than not, we figured out problems faster than we could get Cognos resolve an open ticket for us.
While we still do Cognos today, we’ve been able to take our past experience and offer our customers the option of considering free or low-cost alternatives to business intelligence. Software costs used to be a barrier to deployment and skill acquisition, but they don’t have to be today. Pick the right approach, and you can have business intelligence solution at a fraction of the cost a decade ago. After all, it’s not rocket science, people.
So You Think You Can Be A Business Intelligence Expert
In my opinion, there are plenty of people out there who have what it takes to be great business intelligence people, they just don’t appear to be on paper. It’s really hard to be a Cognos expert if you don’t work at a Cognos shop or have tens of thousands of dollars to buy a license.
On the other hand, there are plenty of open source relational (and non-relational) databases, ETL tools and libraries, and reporting tools. It’s easy to get your feet wet with those, provided you have a core set of skills. I tend to think that a good full-stack web developer (someone familiar with LAMP – Linux, Apache, MySQL, PHP or similar) usually has a good set of fundamentals to make a fantastic business intelligence consultant.
To me, the most critical skill in business intelligence is a solid knowledge of SQL. Yes, I get that most major enterprise business intelligence software is designed so you don’t need to know SQL, but I have found that skill to be invaluable during my time working with Cognos. To me, SQL represents the one true way to know if your data source is right. Debugging the data in an abstraction layer like Cognos Framework Manager first is wasted time since you need to know if it’s a garbage-in-garbage-out situation before investigating any of the software between the database and the end user. I can’t tell you how many times my knowledge of SQL has saved significant time during the root cause analysis process.
Of course, not everything was smooth sailing at the beginning. The technical stuff was always fairly straightforward, but the hard part was learning how to map business intelligence terminology to the terminology I already knew. Every domain has its own language, so I had to quickly learn about facts and dimensions and map them to the types of data structures I was already familiar with in my life before business intelligence. Once that was done, things were pretty easy. The main frustration after that was the feeling that things weren’t in your control. When you’re a full stack developer, you generally have very low-level access to all sorts of things. Something broken? I’ll just fix my code. This was no longer the case. A lot of enterprise business intelligence tools are designed to be turn-key systems. Instead of developing your own reporting system with access control, etc., they give you a portal out of the box. Instead of designing your own reports in raw HTML, they give you a WYSIWYG report designer that has drag and drop. In other words, you’re given a black box GUI to do a lot of work. That sense of control you get when you have when you’re a coder is gone at this point. Even without that control, however, you’re still getting the satisfaction of solving customer problems and building stuff. To me, it’s just as rewarding, only different.
How To Find People
I’ve always had the (somewhat controversial) opinion that a business intelligence expert isn’t about how good they are at [insert enterprise brand name tool here], but at knowing what to do when the software misbehaves. It doesn’t take a genius to do a web search and find hundreds of articles on why “enterprise software sucks” to know that enterprise software will not always behave the way it’s supposed to. Knowing all the pitfalls of a brand of software comes with years of experience. The absence of this knowledge, however, doesn’t prevent a relatively skilled person from doing the day-to-day development work though.
Because Vince and I are a two-man shop right now, we haven’t had to hire any new people, but we do generally agree on the approach.
It’s more important to hire a person with the right attitude and core technical skills than it is to have them with certain brands of software on their resume. I will grant that sometimes it’s unavoidable on a project-by-project basis, but if you’re building a team for the long term, I think the better approach is to focus on general competency than niche competency. I am personally biased, but I tend to think that full-stack web developers are a great resource to tap into when it comes to hiring newbies for business intelligence. They have the raw skills, and you can fill in the knowledge gaps quite easily. Because full-stack web developers are plentiful, you can find more affordable team members, while bearing in mind that you do get what you pay for.
Of course, when you’re specifically hiring for senior level people, that strategy may not work. The difficulty in hiring senior level resources is where the complaint of not being able to find good people comes from. But I said earlier, that you get what you pay for. The best experienced people are usually already working somewhere. Getting them to work for you isn’t as simple as saying “hey join us, we’re cool!” You need to give them a reason to leave an otherwise highly paid, comfortable position. You have to have something to offer that the person’s current employer does not. And if you’re being truly honest with yourself, you’ll probably realize that all other things being equal, the only thing you have to offer is more money. If you’re not willing to pony up the cash it takes to get a top prospect, your problem may not be much that “good people are hard to find” than it is “my company doesn’t have what it takes to attract good people”.