X

Innovative ideas for every utility

Technical or Functional... Maybe it is both - Making sure you don't drop the ball

Anthony Shorten
Senior Principal Product Manager

One of the most enduring principles I have learnt as a former implementer of products, is the line between technical work and functional work is dotted and very grey. In more traditional implementation methodologies, the delineation between technical work, managing the technical aspects of a product, and the functional work, working with the business, has been encouraged to be separated with little flexibility. It was not uncommon to see functional people throw technical aspects of a solution to the more technical people in an implementation. In most cases, the method used for throwing across the fence, as it was commonly called, was not communicative leading to incomplete or incompatible solutions.

Let me give you a concrete example. I was working with a customer as a technical consultant quite a few years back. One day while working at my desk, two functional architects were discussing the different possibilities they could configure to satisfy a requirement. They were bouncing ideas. I joined in on the conversation and suggested functionality that was already in the product which could be used to satisfy the requirement if configured in a certain way. Without hesitation, they suggested to me, perhaps, I restrict my ideas to my technical skills. They effectively discounted my suggestion as it came from a technical person rather than looking at the idea on its merits.

Perhaps that example is extreme. Let me look at it from another perspective with another example. As a product developer, we are always attempting to marry technology directly to satisfy business goals. it is a common principle of any product to exploit technology for business benefit. We introduced Information Lifecycle Management capabilities into the Oracle Utilities products several years ago. The idea is that transaction data, the bulk of the storage usage in any implementation, has a lifecycle that can be exploited to optimize the storage footprint. We determined the best approach was to marry the extensive Information Lifecycle Management capabilities in the database with some inbuilt capabilities for the business to set their goals. Thus the Information Lifecycle Management capability was born. It had a business aspect and a technical aspect, but to truly implement the capability to its fullest extent the two aspects have to work together. In theory, the idea was to marry the two approaches to implement a more satisfying outcome overall.

There was one problem we did not anticipate. In most of our customers the technical people rarely talked to the business in their terms, so there was a disconnect in planning your Information Lifecycle Management and actually implemented it. For example, the first step in the process is the agreeing the retention periods for transaction data. When we launched the Information Lifecycle Management capability, I literally had a number of technical people swamp me after the session, asking how they could get their business to make that decision or maybe Oracle should make that decision for them. They wanted to avoid the discussion altogether. I suggested some techniques for them to start the discussion with their customers. Their comments confirmed my suspicions about this technical and functional divide.

Now I am hoping you are not thinking I am highlighting the divide and leaving it at that. There are ways of addressing this and being successful. Here are some of my suggestions:

  • Appreciate both sides. Don't not put artificial barriers between functional and technical work. Involve both sides is designing and implementing solutions. Consider feedback and possible solutions from everyone in the team. I have found the most innovative solutions come from the most unlikely sources. A useful technique is to see the problem from each side.
  • Learn Each Others Language. It is easy to dismiss something due to jargon as something I don't want to understand. Technical people should phrase their solutions in business terms and functional people should at least appreciate the technical side of the solution. Remember the best solutions marry both approaches. I remember my success with the business is discussing the technical recommendations for a solution in business terms. This is not an easy task but over time you can appreciate both sides of a solution.
  • Be patient. All this won't happen overnight so a degree of patience is important with all parties. You will stumble a lot before you can walk and then run.
  • Don't Drop the Ball. In sports like baseball or even cricket, if the batter/batsmen hits a high ball in between two fielders, the worst thing to happen is if both fielders assume the other is getting the ball. Then the ball falls dead in between them, both looking disappointed. This is true in the context between technical and functional resources, both can assume the other is doing something and in fact nothing gets done. In this case, both take the responsibility and then eventually work out who is the best resource for the task (even that is both).

Over time the divide will reduce to the point that both sides of a solution are considered and you would breed success.

Oracle Utilities, including Opower, partners with the world's hardest working electric, water and natural gas companies to empower, enhance and enable your every single day. From cloud-native products and better grid management tools to support for every single step of your customer's journey, we have the answer. Learn more at oracle.com/utilities. Get specific product information as quick as clicking right here.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.