Every engineer, over the years of their career, develops an appreciation for particular design patterns. In general, there are multiple tools that one can pull from for any particular problem, and engineers with different personalities end up with their own customized grab bag of tricks including preferred patterns. My personal favorite pattern was always the Façade pattern.
Perhaps simple things appease simple minds, but the humble elegance of the façade pattern has a particular attraction in how easily it can abstract the underlying complexity of a task from a requesting piece of code.
Over the years as I have moved into more organization and management, I tend to look at real world challenges to be solved in the language of design patterns as well.
In a recent engagement with a partner group, we would have expected to deal with a single person, but in practice, we needed to not only manage the first point of contact, but subsequently also manage each ‘specialist’ to explain our needs and ultimately to reconcile the feedback. In general it was a half baked sub-par experience. We shouldn’t need inundate our simple minds with the complexities of each of the sub domains – we want to be able to go to one person and have that euphoric experience of not having to manage the service provider. It may sound like we simply want to dump work from our team onto another, but it is more nuanced than that. It is having the most capable and efficient person taking on the right tasks. The partner group is the domain experts.
I have seen some companies do this well, and when I view others, I can’t comprehend why some think that providing a disjointed service to customers or partners, is somehow an optimal route to take. There doesn’t seem to be any benefit.
At Yahoo, the numerous times we’ve had to engage with the Legal team, has been a great experience. We have a single point of contact for the Mobile Platform, and as we roll out new features, our liaison abstracts the complexities of dealing with all of the individual specialists such as policy, regions, and sub-domains – conducts the internal reviews, collates the information and then distills it in a manner that we can understand along with the options and thus they need to abstract the complexities. The end result has been that the overall time spent as a company was reduced – Legal focused on legal work, we focused on the actual platform, product, and capabilities.
My recent experience dealing with AT&T however, was a great example of a poorly set up process. I had to speak with one person about voice connectivity, I had to speak to another person about my Internet connection, and I had to speak to yet another person to deal with my bill in general, all the while having to re explain the situation to each on fo them. In today’s world, where switching costs are dropping and alternatives for services constantly coming into the market, those that are able to provide the better experience will command loyalty and customers. Within the workplace, successful organizations will be those that reduce the friction in execution, otherwise the morass of bureaucracy will cripple the ability of the company to compete.
Within each team that I have led, the primary task that I have tried to solve is improve the organizational set up so that execution improves. Using my grab bag of tricks from my engineering days, has been an invaluable resource and the façade pattern has always been the quickest, simplest, and most effective pattern to implement.
I also really like the Observer pattern… but I’m still trying to figure out a consistent way to implement that in large organizations – timely communication seems to be a constant challenge!
What are some of your organizational tips? If you’re a techie – ever leaned on some of your tech tricks to help in real world issues?
The original design book by the Gang of Four and the authors:
UPDATE (Sept 22, 2013):
I came across a couple of relevant articles/posts recently, so adding them here.
- JavaRevisted: Observer Design Pattern
- Amusingly MOSS: Design Patterns That Get Implemented in Real Life (the anti-Facade!)