The focused BA: why I still believe in specialized roles in software projects

Featured
24171 Views
4 Comments
9 Likes

The idea that excellence at performing a complex task requires a critical minimum level of practice surfaces again and again in studies of expertise. In fact, researchers have settled on what they believe is the magic number for true expertise: ten thousand hours.

Malcom Gladwell, in Outliers

As an IT professional who was born and grew up in Brazil, the country that invented “jeitinho” (a word that comes from the expression dar um jeito, literally “find a way”), I’m no stranger to the need to be resourceful and wear multiple hats in work initiatives.

Once in my native country I was hired as a business analyst for a subscription-based software project in which I also became responsible for defining the marketing strategy and the subscription tiers. I even did some coding, when we needed to quickly get a registration page ready for a demo, and the developers were busy trying to fix an issue with the database that was threatening to cause serious schedule slippage.

Yes, we managed to deliver a successful product with very limited resources. I remember one day the project manager calling my husband to ask for help fixing the database issue, after a consultant from the large database provider had spent 2 days on site unsuccessfully trying to find a solution. It was a typical case of “jeitinho”: using the resources at hand(the project manager’s personal connection with my husband, who shared his alma matter, and creativity) to fix a problem. How did my husband manage to fix the database issue? Ele deu um jeitinho [1].

The focused BA: why I still believe in specialized roles in software projectsHowever, having had a chance to compare the results of projects with generalists vs. projects involving specialists in different areas: discovery, UI and technical design, development, testing, I’ve come to the conclusion that most projects produce better results when they have specialized people playing the various roles, rather than trying to be resourceful and wear multiple hats.

See, I’ve had great success in the past creating clickable prototypes and even designing web interfaces. Recently, in a visit to London, I was told by a small business owner that he liked so much the design I created for their website that the only change made in 4 years was the addition of an image-rotating feature to the homepage. I’ve also managed to design data models that stood the test of time; still, if someone asks me if I want to do UI or data modeling for a complex software project, I always say no. If it’s possible to have a specialist perform the task, I don’t want to be doing it.

Let’s take as an example UX design. Technology is constantly changing, and now with a wide range of new devices hitting the market, including heads-up displays such as Google Glass, the challenges associated with designing a winning user interface have grown exponentially. The need for fast interfaces is also a bigger concern now: while a decade ago it may have been acceptable to go grab a cup of coffee while the computer was loading, today users expect software to load fast and respond quickly to keyboard, touch and voice inputs. Someone working on the user interaction space will have time that I don’t have to keep up with new developments in UI techniques. Such person has a much better chance of avoiding the many pitfalls of UI design for an increasingly ecosystem of devices with varying screen sizes, pixel densities, and input types.

Likewise, the designers and developers I work with love the fact that they can count on a business analysis specialist to work on the discovery process. Talented designers and developers often don’t have the right skills, time or inclination to devote hours to reading and analyzing large amounts of information, or ask probing questions until the real need is surfaced and understood. In over a decade in BA consulting, I’ve developed an ability to quickly separate relevant information from unnecessary facts, and see gaps in a solution that others gloss over. But getting good at the discovery process meant, for me, leaving behind an opportunity to truly master my coding, designing, or project management skills.

The 10,000-hour rule, well-known to performance scientists, was popularized by Malcolm Gladwell in his 2008 book Outliers. We all need a critical minimum level of practice to achieve excellence in performing complex tasks. “Jeitinho brasileiro” is still a part of my toolkit, but instead of using it to do things on my own, I apply it the same way the project manager who called my husband did: to build and maintain a “knowledge business yellow pages” of experts who can fill the inevitable knowledge gaps that any knowledge worker will face from time to time. Becoming a top performer requires approaching work with a craftsman mindset, and making deliberate practice a regular part of our work routine. While it’s useful to be curious and willing to learn new things, and step off the expected path, it’s also true that we can’t spend 10,000 hours stretching our abilities in all fields.

Specialization helps us master the skills that matter most for the work we do, and develop the rare and valuable traits needed to excel at our roles. I still attempt some small coding projects from time to time: it’s a fun hobby that helps me understand the development world better. But I don’t have any illusion that I’ll become a skilled programmer during my life span, and the bulk of my “professional development time”is spent on mastering skills related to discovery and analysis that I can use to produce a positive impact in my projects.

Some agile proponents argue that specialization create skill silos of people who barely understand or appreciate the other side, preferring to work in an environment of“collective ownership” and “frequent role rotation” instead. I don’t see specialization as an enemy of collaboration, though, and like to think of my specialized role as an opportunity to constantly improve in what I do best while still collaborating with the team in adjacent areas such as defect troubleshooting and test case creation.

After all, we Brazilians are also the inventors of Frescoball – a game similar to beach tennis in which instead of trying to defeat the opponent, players help each other keep the ball in play for as long as possible. Choosing to specialize doesn’t mean leaving behind the idea of a collaborative and creative process: it just means recognizing that time is a valuable and scarce resource, and that achieving excellence in something often requires a willingness to ignore other interesting pursuits that may pop up along the way.


Author: Adriana Beal has 13 years of experience working on increasingly complex software development initiatives. During this period she has helped a diverse client base that includes IT, telecom, health care, and major U.S. financial institutions understand the real business problem and make better decisions about their internal and customer-facing applications. Adriana’s work currently focuses on executive-level consulting in ecommerce, mobile and web-based applications, as well as implementing performance measurement systems for business analysts via Beal Projects.


1.The “jeitinho” in this case was to tell the project manager that if he switched operational systems from Windows to Linux, my husband would be able to troubleshoot and fix the issue. That’s what the project manager did, saving the project days of delay waiting for the database provider to send another specialist to identify the root cause of the issue in the Windows environment.

Like this article:
  9 members liked this article
Featured
24171 Views
4 Comments
9 Likes

COMMENTS

[email protected] posted on Wednesday, April 16, 2014 8:17 PM
Some specialists DO operate in silos, and think there expertise alone makes for a good outcome. This gives specialists a bad name. They forget that there is a synergy in collaboration. Fortunately, not all skilled specialists operate in silos. Some collaborate, and share responsibility. Those are the ones I like working with. As you suggest, having such collaborative specialists gives us the best of both worlds.
adrianab posted on Wednesday, April 16, 2014 10:12 PM
Yes, David -- I like your distinction. There's a big difference between specializing to the point you refuse to collaborate, and knowing your specialty but also wearing other hats when it makes sense to do so to assist the team.

I've been in situations where I was the person with the best eye for color and space on the entire team, so I gladly took the job of creating the CSS styles for an app. However, I'd definitely try to convince my boss to give the task to a colleague if there was one on the team with more design expertise, who could do the job better while I focused on another area in which I have my "ten thousand hours of experience".

For collaborative specialization, it's important to understand our strengths and weaknesses, and to be willing to step forward at key points to meet a need or solve a problem.

Thanks for leaving your comment!
Dtbanks posted on Thursday, April 17, 2014 1:53 PM
Hi Adriana (and David), 

Though specialists do tend to work in silos, I wonder if specialization actually enhances collaboration?

Specialization requires more 'handoffs" than generalization, and thus more opportunities for collaboration.

To clarify...

I don't regard 'collaboration' and 'silo' as opposites.  As I often work in domains I know little about, I initially 'silo' myself (via research and investigation) so that I can later facilitate collaborative sessions. Though it is often said, "There is no I in team,"  I'm suggesting that there should be (I once said that in a conversation with Steve Blais, and he replied, "if you look closely, there is a me" :)).

So, silos are essential 'parts' of collaboration, so long as specialists don't "think there expertise alone makes for a good outcome," as David said.
adrianab posted on Thursday, April 17, 2014 8:07 PM
Hi, Dtbanks,

I believe you are using the word "silo" in a different context here. The "Silo Mentality", as defined by the Business Dictionary, is a mindset present when certain departments or sectors do not wish to share information with others in the same company. In that context, "silo" and "collaboration" are indeed opposites.

I can't say I agree with the notion that specialization offers more opportunities for collaboration than generalization (e.g., a self-organizing agile team may have little specialization but will still require a great deal of collaboration to be successful).

Still, I think we all agree that a collaborative environment is much more effective for organizations, and better for generalists and specialists alike. Thanks for sharing your view!
Only registered users may post comments.

 



 




Copyright 2006-2021 by Modern Analyst Media LLC