Midwest IT Survival

In the throws of performance reviews and feedback activities, I’ve started to form in my mind the concept of opinion boundaries as it pertains to work team interactions.  As you know from this blog, the significant bulk of my professional work experience has been in IT.  Thus, this concept of opinion boundary has been birthed from IT but very well could apply in other professional disciplines where disparate teams with specific service outputs come together to provide a combined product or service.  I would be curious to hear from folks outside of IT that experience this concept in their work places and under what circumstances does it manifest itself.

Keep your opinions within your realm

First, let me paint a picture of what is creating this opinion boundary concept in my mind:

Hypothetical meeting between a Software Development Team tasked with building a new application and a Database Team that is tasked with providing Database services to applications for the whole company.

Software Development Team: “Ok, we have been asked to build a new application called X that will take in manually entered information from paper request forms and allow each form to be assigned a unique identifier so the five steps to complete the request can be tracked by the new application.  We have a database design we can provide.  What else do we need to do in order to get a database available to us in order for us to start developing?”

Database Team A: “Hey, are you writing this application in Ruby on Signposts?  If you are, you should consider using at least version 2.5 because we’ve heard of performance problems in earlier versions.  Also, have you considered how your data layer should talk back to the UI?  We’ve heard of a group that had problems with the standard PC build, you should talk to the platform guys on that.  Hey, we know that in general, development shouldn’t start until all the requirements are finalized … do you know if the business signed off on the spec yet?  Oh, and we think …”

Compared to a response such as:

Database Team B: “Ok, we just need to know some initial pieces of information from you in order to ensure we can configure a database that will work for your needs and that we can support.  What development language are you using?  Do you have any disaster recovery requirements beyond the default ones for the company?  Do you have any specific needs beyond the core database services of X, Y, Z…”

Note: This is by no means a reflection of database teams in general.  The example attempts to portray one group that needs services from another group in order to deliver their work product.  I chose the example of a software application team needing a database from a database team as a representation of a common use of centralized IT services, in this case databases, being provided out to distributed groups that all need to leverage that common service in order to ultimately provide their service.

The different responses are striking in that the first exhibits seemingly no boundaries to the opinions this hypothetical Database Team A has outside of their core service offering compared to the second from Database Team B.  Team B recognizes the boundaries of their service compared to the requesting team’s needs and has derived an interaction strategy that focuses on determining the most logical touch points and associated technical considerations between their service and the requestors.  Team B does not cross that touch point boundary and encroach on the subject matter aligned with the software development team.

Over the years, I found the most successful cross team partnerships consistently involve a clear opinion boundary.  Opinion boundary being a respect for the needs of the other team and structuring a service interaction model that defines the service touch points in terms of what the requestor needs from the provider as well as clearly explained constraints the provider has to exhort on the requestor in order to ensure the provider’s service can meet their service expectations across all requestors.  And finally, refrain from offering any opinions that break the touch point barrier.

What I have struggled to assemble is what drives an individual or a team to have such a strong need to offer opinions on subject matter outside of their role or service within the organization to such an extreme?  In the utmost extreme case, the only logical conclusion I could draw was that the team was extremely weak skill set wise in what they were tasked to do and used such a tactic to misdirect requestors.  In the process of misdirecting, they seemed to be hoping one of two things occurred:

1. The requestor would find another service provider and thus never return (seemingly odd, but in a very large IT organization it is likely to have multiple teams providing similar enough services that one can meet their business objectives via multiple options)
2. The requestor was hoping the misdirection would require more people to get involved to ultimately map out exact what the provider needed to do at a detailed level that ultimately filled in for their skill set gap.  “Oh, you actually wanted us to provide that?  Oh, that … sure, we can do that.  It wasn’t clear to us initially that you really wanted that.”  Using such backtracking to agree to perform the granular tasks outlined to them from a more senior resource outside their team.

Another is shear ego whilst the provider wants to talk to hear themselves talk and feed their sense of importance for the duration of time the requestor needs to confirm the use of their services.  In other words, for the requestor, suffer through the chest beating and technical pontifications in order to ultimately get the service required in the end.

Anyone have a different definition on option boundary as I have described it or knows of alternative motivations for someone or for a team to interact in these manners?  Anyone find this applies outside of IT?