Learn a lot about one thing or a little about a lot of things?

Should Custom Software Developers be Generalists or Specialists? 

Spoiler alert: " I think the answer is that I need to be both. There are a few things that I need to know deeply. Deep enough that I am prepared to solve complicated problems that my teams encounter in that technology. There are many things that I know broadly. I need to know enough about them that I can leverage those technologies to solve a wide array of problems my team might encounter throughout the life cycle of a project," Eric Potter writes.
 
True for testers as well.  I want to know enough about everything that I can point junior colleagues in the right direction when they have questions.  But I also want to be an expert of at least a few things, so that I can be useful in solving particularly arcane, tricky problems.

Testers: Get Out of the Quality Assurance Business

I was doing some late Friday afternoon cleaning of my to-read list and finally read this post of Michael Bolton's that I had bookmarked within the past few months.  

We give information.  We explore.  We look at the product from the perspective of "maybe this doesn't work?" instead of trying to prove that it does.  We add value that we sometimes only know is there if we *don't* add it.  

The article spoke a lot about our relationship to development, project management, and management.  I want the developers to think of me as an ally who saves them time in the long run and not someone to hide from. I want management to see me as an ally who does their best to make sure we aren't embarrassed in the marketplace.  I want project managers to see me as an ally providing information about risk and gut feelings and diplomatic assessments of project stumbling blocks.  I try to be honest in all of my dealings internal and external to my department and positive/affirming at every opportunity I'm able, so that when I suddenly sound the alarm, it's perceived as important.  I want to, as Michael Bolton states, "Be a service to the project, not an obstacle."