Industry Experience
01/12/2011 14 Comments
I don’t get it. Why do so many jobs and contracts seem to insist upon having experience in a particular industry when, in the overwhelming majority of cases, the specific industry in which we work has no bearing upon the nature of our work.
I have worked across many industries, but each time I talk to a recruitment agent I get similar questions: “Have you worked in X industry?”, “I won’t put you forward for Y unless you have worked for Z”.
It’s the wrong question. Have I worked in Media? Investment Banking? Accountancy? Property? Logistics? It doesn’t matter. No, really. It doesn’t. I have worked in all of those industries and a few more besides, and the nature of the industry was largely irrelevant. A friend recently suggested that you need Investment Banking experience so you understand the inordinate bureaucracy and dreadful boredom that come with working for an Investment Bank. A little unkind, but I know where he’s coming from.
What is relevant is the type and nature of systems with which you are working. Are they mission critical? Zero downtime? Very High Transaction rate? Enormous Data Warehouses? Hundreds or Thousands of databases? These questions have relevance. A high transaction rate OLTP in a Bank is very similar to a high transaction rate OLTP Web Retailer. The challenge with these systems is a different to that of an enormous data warehouse, but it’s still fundamentally an RDBMS. Data is data is data. We don’t need industry experience – it doesn’t help us in the same way as it helps Business Analysts or Project Managers or even Developers.
The recruitment problem for DBA’s is that recruiters don’t know the difference between OLTP and Data Warehousing; a large proportion simply keyword match (the great ones don’t! – and there are genuinely great recruiters out there, in small numbers) so you need to ensure you have all of the relevant keywords on your CV – I have even been asked to amend my CV to put Word and Excel on there! WTF? Unfortunately you also need to be careful, otherwise you’re probably getting job adverts sent through for Cobol Programmers, Websphere Guru’s and all manner of support and helpdesk staff. I removed IBM Assembler Programmer from my CV about 10 years ago, although I suspect there are not too many jobs left for that skill set now.
Neil Chandler's DB Blog 
hi
neil your article was very good mate. i was follwoeing ur blog u post were really intresting.hope u continue with good articles.
best of luck
k.goutham
LikeLike
Ahh, keyword searches. Last week I got sent a job spec by an agent for a ‘C’ programmer. I’ve never programmed ‘C’, I have not got the letter ‘C’ as a single character on my CV and I did not have any of the other specific skills that were asked for either.
I can’t help but think they got their keyword matching wrong and sent everyone on their books with the letter ‘C’ somewhere on their C.V {little clue there) the job.
Agents. Never has an occupation been so blighted with incompetents as that one. You almost cry with relief when you find a decent one.
LikeLike
You’ve hit the nail on the head there Martin. The only truely great agents are the ones who research properly, and read the blog posts of their potential clients 😀
Neil.
LikeLike
Hello,
You mean there are actually some decent agents out there? They must be gold dust.
The other thing, is SC clearance, lots of jobs out there requiring that, but you can’t just apply, you need your employer sponsor to apply, but you can’t get one the fekin’ jobs until you have the clearance!?!
jason.
LikeLike
The problem being, SC takes 6 weeks to get and consultants are always wanted ‘yesterday’ 😦 Catch-22
LikeLike
The SC thing is annoying, the guidelines clearly state the process is supposed to be find the right candidate then security clear them. As no one can wait the 6 weeks everyone simply ignores DV is even worse and is supposed to be role specific anyway.
Personally I think the reason for requiring industry experience in banking is so people are not shocked when they find out how badly managed and secured some banking and financial systems are.
LikeLike
Surely agree with the headhunter comments, but not so much with the industry experience ones. The difference lies in the analysis – sure, many places have analysts who write specs for programmers to program to, many programmer/analysts are (hopefully) trained to extract needs from customers who (hopefully) know the real requirements, business process re-engineering (or whatever the hot process is) can redefine it – but still, many places expect a certain amount of knowledge of their vertical market to be able to communicate.
Obviously, the mapping of those expectations gets distorted through HR departments and thence to headhunters. Perhaps not so obviously, most hires are based on current skills required, which is a short-term mindset to a medium or long term issue. Someone leaves, someone else needs to replace what they were doing. Then new things come along.
Some things cross industries – I had some deja vu when I wrote some analysis programs for a pharmaceutical manufacturer, almost exactly as I had done for an electronics manufacturer using much different technology 20 years before. Others don’t – some things in process manufacturing have no translation to nuts-n-bolts manufacturing. And are completely non sequitur in search engine optimization or web development or kernel development or aircraft GPS control systems. People have disagreements about whether it is easier to train a programmer in a business or a knowledgeable industry person in programming – or neither.
In addition, in general careers have a path, so you follow that path upwards until hopefully you hit CEO. Computer career paths don’t necessarily follow that. And aren’t we all just a bunch of nerds and geeks anyways? 🙂 I knew (friends parents) software engineers in the ’60s, but many computer related jobs are too new to have settled into a path.
LikeLike
I don’t agree – from a DBA/Admin perspective (this is a DBA blog!)
Whilst I know what a head of stand is, a dunning letter, a dead spread or how to calculate net present value, I have never needed to understand any of those business terms to make a database run and get it working for the business. It’s about understanding the uptime, response and recovery requirements, not how you pull data to directly market to your customers. That’s for analysts and developers, not DBA’s. If you are a development DBA, then you have a foot in the vertical knowledge camp, but true Development DBA’s are rare (I know, I have been one.)
The main difference for me is understanding how to negotiate the levels of red tape in each individual organisation, and that varies considerably more between organisations rather than in the same vertical sector.
A career isn’t just about getting as high as you can. There will be an awful lot of disappointed people if it is. I am considerably happier as a technical consultant with no staff instead of being a senior manager, managing managers, and/or running global teams. I have checked out all of those (and more) options in my career. I know what I want and it’s not being a CEO or a CIO. I want to be happy (and I am, btw :-D).
Neil
LikeLike
It’s entirely possible we agree and I just have an odd view from odd experience. If any good dba doesn’t need to understand the business requirements to run the database, why not just use cheap offshoring? Many places have tried, and why have they run away from it? Because something needs to be communicated, and it’s not just dealing with red tape. I might be working the definition of DBA backwards, because so often I’ve seen more value in people who are DBA+, whether it’s plus vertical business knowledge, plus knowledge of tools, plus accounting or what-all. Even in large sites with expensive Oracle corp dba’s, I’ve seen times where I come in and do better than they do because I wouldn’t try to force DBA “correctness” on dumb vendor packages, but work with the db and the packages. Some places call that a vendor-specific app DBA, but they are DBA’s too :p . So for headhunters, there may be an implicit requirement that someone in an industry is familiar with the packages common to that industry, and they may correctly or incorrectly think that applies to DBA’s. For app DBA’s, Fusion consultants/architects, it may very well be correct or the step up from regular ol’ DBA.
LikeLike
Pingback: Friday Philosophy – The Worst Thing About Contracting « Martin Widlake's Yet Another Oracle Blog
Prior to joining the Bank where I work, I was an operations DBA at a Manufacturing organisation — handling ERP (Financials and Supply Chain) and Manufacturing (Process, SPC etc) databases. Fortunately, my hiring managers *and* the head-hunter were both cognisant of the role requirements — they wanted a database specialist not necessarily focussing on industry domain but being able to use a database in a variety of implementations.
However, it does seem that too many job adverts ask for domain expertise. This very well could stem from lack of knowledge about what the DBA (if we are speaking of a DBA position specifically) will be doing in the hiring organisation *OR* that domain knowledge might, in a small minority of cases, be really a requirement. When we apply for a position we cannot distinguish between the two — nor does the head-hunter bother to identify which of the two categories the DBA is required for.
With respect to Joels comments about (a) Outsourcing and (b) Vendor-specific apps : Outsourcing DBAs may not put in effort to “understand” the database they manage. You don’t need domain knowledge but you DO need the right attitude. That seems to be lacking amongst very many DBAs. Applying “dumb” best practices seems to be a favourite — either implemented as standards or as recommendations from “Senior” DBAs. Neither do DBAs try to understand the “right fit” nor do their managers get them to make an effort. Finally, the DBA is “just a DBA” — rather a DBO.
……….. hopefully, soon, I might be publishing some thoughts on this topic.
LikeLike
DBA attitude is comething completely different, and comes back to the old 80%/20% rule. 80% of the work in any organization is done by 20% of the people (this is true for all job roles). I have worked at several places with many DBA’s, and only a few actually do anything interesting, creative or add value to the business. The others come in, push the buttons and go home (tablespace filling up – click – add space – click). Where outsourcing falls down is you should only outsource the 80% button pushers, not the 20% of staff with value-add. However, the baby is frequently thrown out with the bathwater.
LikeLike
Should DBA’s be creative and interesting? I think that is one of the paradoxes of the job – you have to be able to rapidly switch roles, from being a stubborn mule about backups and upgrades to creatively solving performance problems (and I’m sure we could all add examples to such categories). This becomes a problem in staffing, managers usually want to replicate themselves, when they really should be trying to wind up with a staff with a range of abilities. We can’t all be Tom Kyte, there is a place for the 80%ers, even in our job category. How really creative do you want banking admins to be? Or the Jr. doing a restore?
LikeLike
I agree that you need a mix. Teams outperform when you have creatives along side button pushers and completer/finishers. You need problem solvers, and gatekeepers dealing with procedure.
Try getting a great problem solver to check the alert log every morning when they come into the office. It’s hard to achieve, in the same way it’s hard to give a complex problem to a button pusher.
“Bad” techie managers keep doing the work that their team should be doing – “Because I’ll get it done!” This leads to overworked techie managers trying to do 2 roles, and underutilised staff never learning. It can be hard for managers to let team members with less skills in a specific discipline go away and produce an “inferior” result in a longer timeframe, but good managers will do it.
And you don’t have to be creative to add value. You do need to add value. You do need to think. I’m eternally surprised at the amount of staff who add very little value, and don’t bother to think – at all levels within an organisation.
LikeLike