Full Circle: From Generalist to Specialist and Back

29 June 2012

Lee Thomas
IAG NZ

I started in the IT industry back in the early 1990s, working for Ford Company in the U.K. Since then I've observed with interest the trends in the skill set required to be successful in our industry.

Looking back, I realize I was extremely fortunate to work for such a progressive company when IT was merely a fledgling career path. My first job was in marketing systems with a James Martins CASE (Computer Aided Systems Engineering) tool called IEF (or Information Engineering Facility, now CA Gen), building management information systems for monitoring and reporting vehicle production and dealer stock levels in our European markets.

Some of the practices we followed back then were similar to the Agile approaches we know today, such as Scrum and XP. We used the early Agile methodology Rapid Applicant Development (RAD) approach, working closely with a business representative who was the business expert. We didn't have formal iterations back then, but we conducted weekly workshops during which we could prototype screens and data objects that we would then build and demo in the following session. We were very light on documentation (sometimes there was none) and focused on producing working software.

We did it all. As systems analysts, we were truly-cross functional and would cover the full systems development life cycle. We data-modeled, performed analysis (and yes, we actually spoke to our customer), wrote the code, designed the screens, tested each other's code, and implemented and supported the applications we produced. I recollect that there was not a business analyst, project manager, or tester in sight!

As my career as a consultant progressed, I moved to other companies and was exposed to different methods and techniques. The roles I just listed began to emerge, with distinct separations among them. Developers stopped talking to customers, as this was considered wasteful and unproductive. Project plans began to appear, as did weighty tomes of detailed requirements.

So much for the trip down memory lane. What's the point? My point is that we have gone through a natural maturity process in our profession. We started as generalists (at least I did), doing what was needed. We later moved to specialization as technology and tools became more complex. Now, as part of the Agile movement, I see us returning to that generalist approach — with improved tools and a need for lower cost and overhead.

I also see a further trend in the younger generation joining the work force, a trend of more technical analysts and testers, and of developers with better communication skills. All of them are accepting Agile as the way to work. In my view, there is no place in the modern Agile environment for analysts who just want to talk to the customer and write down requirements, nor is there a place for the developer who wants to just sit and write code, or for testers who just want to push buttons. It isn't a case of being a jack of all trades and master of none, but simply a shift in the skills required to do our jobs efficiently. There is now a need for what I have heard called "T-shaped" individuals, those having a depth of skill in one area but the capacity to perform other functions as required.

I'm sure these trends will continue to change as we constantly inspect and adapt what and how we do, but for now the return of the generalist is a fact. As the Agile movement gains momentum (after several false dawns in the past decade), I believe we are finally coming of age and joining the mainstream.

Article Rating

Current rating: 5 (1 ratings)

Comments

Zoran Vujkov, CSM, 7/5/2012 4:05:13 PM
Good Article
Problem with specialist as well is an apperance of functional teams with functional managers, who usually have different agenda than Agile teams. To be able to get rid of the functional teams, by my experience you should start with building cross-functional teams first. Next phase is to make these teams to be multilearning (For example tester to learn more about writting requirements, how to talk to customers; BA to learn how to test; developer to learn how to test, talk to customers etc...). Use Communities of Practices and overlay them on the top of cross-functional teams, create multi-learning teams. As you said the goal is to move away from specialist to generalising specialist. Ones we have team of generalising specialist we will be able to fully utilise Agile. After that we can get rid of functional teams, functional managers and Project Managers
Lee Thomas, CSM,CSPO, 7/9/2012 5:53:36 PM
Hi Zoran,
Thanks for reading my article and I totally agree with your comments. Moving away from a matrix style organisation and into "Product Teams" is surely the way to go. This removes the silos that exist in many organisations and gives teams the platform to develop the skills they need to build and support actual products.
Regards,
Lee.
Dele Oluwole, CSM, 7/17/2012 4:14:43 PM
Good article and a good reminder of the past. While I acknowledge the drift from Specialist to Generalist I want to also point out that selling Agile to all stakeholders, that is the management and the supposedly scrum team is the herculean task today.

The trust in Agile has to be firmly established and bought into by the management and ultimately driven down from the top on to the ΓÇÿspecialistsΓÇÖ at the bottom for it to be successful in any organisation, only them can the curing of the specialists syndrome begin.
Srinivas Chillara, CSP,CSM, 7/20/2012 4:14:40 AM
I agree, and indeed it high time we stopped encouraging tunnel visioned specialists. However thing are far more complex than during the 90's, and I wonder if we should also be mindful of having a primary skill (specialist) while taking up all other sorts of tasks.
Along with a "generalising specialist" at some stage we'd also need "specialising generalists"
Gareth Davies, CSP,CSM, 9/10/2013 4:36:56 AM
Great article thanks Lee -- I was reminded of it just this week when a team was asking about the extremes of specialist versus generalist. Being able to draw a picture on the whiteboard showing the combination of both together in ‘T-shaped’ individuals really helped to get the message across for the whole team.

You must Login or Signup to comment.