My friend Argenis Fernandez (blog | @DBArgenis) is the host of this TSQL Tuesday and he’s chosen the topic of Jack of All Trades, Master of None. This is one of my favourite discussions about the IT industry. My interest stems from the Agile Manifesto that says:
The best architectures, requirements, and designs emerge from self-organizing teams.
This one statement, which sounds wonderful to me, is often interpreted to mean:
Agile teams must be made up of generalists: no specialists allowed.
Another interpretation is that anyone on the team must be able to do any job on the project. Most rational agile teams don’t take that extreme interpretation. Or at least they never repeat that mistake more than a couple of times. They learn that having people who understand things at more than a surface level will make work go faster and with less rework.
Specialists vs. Generalists…or is is Specialists vs. Speed?
This is a very strong belief of one prominent Agilisto who is extremely vocal about this principle. His articles and post are full scathing attacks on people who specialize. Sure, he allows people to have a couple of specializations just for fun, but he’s clear that specialists impede the speed of a project, hold back production and generally lead to diva princesses, his name for me when I appear in debates with him. There’s also a prominent consultancy that tells clients that no one with the words "analyst, audit, architect, administrator" will be allowed to speak to anyone on the project –teams must be just business users and team members (developers). This consultancy is also adamant that only a developer and a clerk be able to decide on requirements and implementation issues.
I’ve been on those projects. We ended up with the clerk and the generalist designing and implementing a brand new way of doing accounting, with a brand new chart of accounts. Just for one project. They couldn’t get into QA testing because their solution was not going to pass audit, integration, security or generally accepted accounting practices reviews. But dang, they sure did it fast. And their new way of doing accounting led to inaccurate accounts, but that didn’t matter. They were fast. However, they were sent back to do it all over again. It was painful for everyone.
These are the types of things an architect, auditor, administrator and analyst would have slowed them down with by pointing out gaps in their solution. But dang, they sure did it fast.
Over Specialization and Over Generalization
I do recognize that people can be over-specialized. You see those people all over…if you ask a question, their answer always involves the same solution or tool. They can’t see any other way of doing something than what they know. I also know people who are fabulous at many, many things on my projects. But in my opinion, the all generalist meme really translates to:
Our team needs to be staffed with people who are specialists in everything.
Think about that for a few seconds. What would that mean, just on your current project? Someone who knows these topics at a professional level: database, network, security, design, data, storage, development, coding, planning, estimation, capacity planning, estimation, UX, reporting, analytics, scalability, reliability, availability, quality, testing, compliance, legislation, localization, globalization, privacy, accessibility for people with disabilities, reporting, methodology, development environments.
Now insert the words for all the technologies used on an enterprise system. All of them. We need professional level people to work with all of them. Note that professional doesn’t mean expert; it means someone who can get something done with minimal supervision.
Then insert all the words for all the activities your entire enterprise does. Do you have a few hundred words? A few thousand? Imagine trying to hire someone who meets all those criteria at the professional level? Even if you could find that person, which I don’t believe you can, how much are you going to have to pay her? Does your company have enough spare zeros hanging around to do that? [tweet quote] What are they going to do when they need 100 more people, just like that?
Why I Hire Specialists who Make Great Generalists
So what does this mean? I want to hire people who have a broad understanding of IT development. I want them to have a good literacy-level understand of most the things we do and use. If they don’t have that knowledge, then they need to be able to pick it up as we go. But I need specialists. I don’t have time on my projects to train and mentor someone one who is going to build the database on the difference between foreign keys, alternate keys, surrogate keys, primary keys and Florida Keys. Now if someone else on the team wants to know that, I’m happy to point to resources where they can find that out. However, my database designer needs to be able to work under minimal supervision to be able to do that. In fact, I’d prefer that they know how implement in it in our specific technology. They should be able to rely on external resources, but they shouldn’t have to sit at their desks with a (virtual) book open before them showing them how to do every step. That’s a recipe for disaster. It will take longer and be more error prone.
Be Both a Specialist and a Generalist
How can you do that? By ensuring that your professional development plan (you have one, don’t you?) includes activities that strengthen both your specializations and your overall technical and non-technical skills. That means you read about things outside your specialization. You actually sit through a DAMA meeting or a SQLSaturday session that isn’t part of your "today job". You expand the depth and breadth of your knowledge. Heck you even attend a session on professional development. Then you make sure you plan gets executed, even if it means paying for your own training or getting up early on a Saturday to attend free training at a SQLSaturday. Maybe it means starting up a series of brown bag lunches at your company, where every group takes turn presenting 20 minutes on their favourite topic for other groups.
If you are a data architect, it means learning more about process modeling, database implementations and development tools in your shop. If you are a DBA, it means learning more about data modeling and data compliance. If you are a developer, it means you learn more about all of the above. It’s up to you. You need to take care of both your inner generalist and inner specialists.
Generalists are great…in general. You can’t master everything, no matter what people tell you. But your specialization won’t be much value if you can’t apply that knowledge within the context of the overall project. You need to be both.
I blogged over on Dataversity about Hiring Data Professionals: Mason Dixon Lines and Zombies in Your Job Postings . In that rant, I talk about organizations that want to hire people who can do everything in the data column of the Zachman Framework.
I call these people "wonder candidates" and write about how they don’t exist in sufficient numbers to supply all the organizations in the world:
It would seem to make sense that if you were hiring a data professional you’d design a position that fills in the Data column, right? No? It turns out, though, that most people don’t think and work along a column. In my experience, people aren’t passionate about tasks that span columns from top to bottom. They normally aren’t skilled along the whole column, either. Referring to the Zachman Framework, what sorts of skills and passions would this candidate need: planning, architecting, designing, building systems, building parts, keeping the systems up and running.
I thought about my rant in this area while reading a job posting on Dataversity for a Data Architect. I’m sure the people at Miami Children’s Hospital do amazing things, probably with very limited budgets. That’s why these hiring organizations tell me they have to fill their positions with Architect Designer Developer Implementer Operational Support Wonder Candidates. I’m going to pick on this posting, so apologies to the hospital for using them as an anti-pattern for finding good data architects. I’m sure they are nice people there and really want to get to successful database and data warehouse solutions. You might even want to apply for that job.
“Designs and constructs very large relational databases for data warehousing. Develops data models and is responsible for data acquisition, access analysis and design, and archive/recovery/load design and implementation. Integrates new data with existing data data warehouses in design and planning.”
Right there we have the keywords design, constructs, develops, implementation. These activities are done in different rows in the data column of the Zachman Framework. There’s also this:
performance tuning, data retention policies, data classification, data security, and data acquisition….Data modeling experience. Database and application object management, including DDL, table constraints and triggers, clusters, object storage allocation and tuning, indexing options and tradeoffs, partitioning, etc., experience.”
Those activities are clearly down in the lower half of the Framework. Yet data modeling, which exists along the entire data column, is not typically a strong skill set for people who work so far down in the Framework. So my guess is that professional data architects and modelers will not be qualified to do the clustering/partitioning/indexing/performance tuning part of the job and that implementers who can won’t be qualified to prepare and maintain the data models they also want out of this role.
If I were interviewing for this type of position, I’d focus on why this organization wants data models but doesn’t seem to want to fund a data architect. It’s sounds crazy, but I recommend that organizations not incur the costs of preparing and maintaining data models when they don’t want to work with professional data modelers. They won’t see many of the benefits of having an active data model but will incur all the costs and the risks associated with preparing incorrect ones.
I realize that there are many successful IT professionals who can work along many rows and columns. I’ve worked with these amazing people. But staffing a team of these amazing people is costly: they are difficult to find, expensive to hire, and tough to keep around because:
There may be people who can do a lot of those things, but in my experience they aren’t passionate about all of them. New hires won’t be happy and the organization will not realize the economies that they think they will.
I recommend that if organizations want to combine responsibilities that they do so across the columns in the same range of rows. Combining positions where thought processes are similar (business and data analysts, DBAs and developers, etc.). Analysts in general make for good analysts in other columns. Operational people tend to think operationally, builders tend to think mostly of building, not planning well. Let’s not drag people up or down the rows.
Go now and check your job postings. Do they reflect the true nature of the job? Or are they actually full of zombies ready to drag someone to an assignment that they don’t really want?
Do you work with any of these Zombies? People who have been hired to fill several jobs, but don’t have the passion or skills to do all of them? How is that working?
Two of my posts are now up over on Dataversity.net, a portal of all things data for data professionals.
The first, now with images working correctly, is Hiring Data Professionals: Mason Dixon Lines and Zombies in Your Job Postings. In that post I reflect on some of the craziness in job postings I’ve seen over the last few months.
In my most recent post, Normalization Myths that Really Make Me Crazy – Introduction to a Rant, I start a series on normalization myths. I expect this series to provide hours of new content for my Contentious Issues presentation. In the introduction I talk about why a series and the emotions people feel about normalization. Please stop by and leave your thoughts there.
I’ll be writing more than a dozen posts for Dataversity this year and I appreciate your reading my posts there as well as those here at InfoAdvisors.
Subscribe via E-mail
- September 2016
- August 2016
- June 2016
- May 2016
- April 2016
- March 2016
- February 2016
- January 2016
- December 2015
- November 2015
- September 2015
- July 2015
- June 2015
- May 2015
- April 2015
- March 2015
- February 2015
- January 2015
- December 2014
- November 2014
- October 2014
- August 2014
- July 2014
- June 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- December 2013
- November 2013
- October 2013
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- September 2010
- August 2010
- July 2010
- February 2009