The State of Technology development within the Organization
Posted: July 3rd, 2010 | Author: Julio Hernandez-Miyares | Filed under: New York City Startup, Technology |
I have been wanting to write my observations about the state of Technology Development in the Organization for some time now. What is that ? You ask! Well, nothing to do with actual bits and bytes. That would be too droll and in the end development groups have been writing code and growing old together with their favorite languages since the advent of the computer and will do so until we figure out how engineer a button that produces code that magically fleshes out the requirements that a customer wants,thinks he wants or is what he needs but doesn’t know it. If the scent of Pizza permeated the hallways leading to the room where the meeting was held the voluntary on-time attendance increased markedly. In other words, it is worth the cost to buy pizza to attract the team.
Of course having an open door policy so that your staff can pop into your office without the administrative hassle of calendar events is a good policy in any context. What I did in partnership with the Business Owners was institute the same policy cross functionality with business owners themselves. Open Door is a cliche and it was a mindset that included going to someone’s office as well as email communications. The point was to create an environment with as few walls as possible , the optimum being no walls between the Business people and the Technologists.
In many instances, the root problem in most instances of Technology and Business relationships is about trust , mostly lack thereof. Trust is hard to build , work to maintain and easy to destroy so the practices to have it permeate the relationships between groups is an never ending process. Technology development has the additional difficulty that we practice a craft that sometimes appears like Black Magic to the lay person. Though I always made it a point to vociferously make the point we are not “car mechanics”, there is a certain resonance to the Car mechanic analogy. For most folks that are not familiar with the inner workings of your typical automobile, the rite of car maintenance especially when some expensive repair has to occur always has behind it the doubt one is being taken advantage of because of their ignorance.
By the way, the photo is out of context of what I am writing about but it does mirror my state of mind at the moment. It is a sweeping view of Key Biscayne Beach down in Key Biscayne, Florida of course. They call it “Island Paradise” at least in the entrance to the Village of Key Biscayne.
No, this post will attempt to be more sociological. It’s something I have experienced directly and indirectly and though I have not dedicated myself to doing thorough research on it, based on my experience I believe it is prevalent. What it is , is the difficulty organizations have setting and managing expectations .
The direct part of my experiences are of course both as a developer and over time as a manager and executive managing larger and larger teams. The teams have been in various disciplines such as Search , Publishing , Integration Services, Video etc but in the end it doesn’t matter or change the expectation challenge one iota.
The indirect I would categorize as more then anecdotal but which I have not experienced directly. It represents those where meeting with a company , say a recruitment exercise , the depiction of the challenge for the candidate is explained.
It generally goes something like this – Our development team doesn’t engage with us like a full fledged member of one team. They rest too much on process and though they may execute on what is asked, they don’t take an proactive interest in contributing ideas or to summarize, they are not innovative.
Though this is not a good organizational state to be in and I will go into how I have solved these problems in the past, let me first say there is a glimmer of goodness in it at least for the optimist like myself. I believe strongly it directly hints at the perception which is also true that Technologists are inherently innovative and that any deviation from that behavior is viewed as a problem to be solved. Even though all human activity and roles have plenty of room for innovation, there are some roles that have a greater perceived expectation and where the mantra “just do your job exactly like I asked” is not enough.
Though there are probably as many ways to successfully solve the predicament as there are people tasked to solve the predicament I will lay out the steps I have taken in terms of consistent and simple communications to the Technical Team I recently led while at AOL. To provide a little context, at a high level , I was tasked with leading a Technology Development team supporting two business units. The teams had previously been broken apart through different management chains that we inane to say the least. Now at least the structure made sense with all the roles needed for success under one accountable executive (myself).
As I lay this out I am not sure if they will be in order of importance but here goes anyway.
- Though we are technologists with our own lingo, we need to become conversant with speaking as business people.
- We are Business People first or at least as much as our Business Partners
- The Customer is always right but our business/product partners are not customers in the conventional sense.
- Regular formal forums with the business owners
- Open Door policy
- It’s all about Trust
No, that does not mean becoming BS artists or such which most business people are not but instead concentrate on the clear, non acronym and technology laden prose. We are here to solve business problems using technology as our craft and most business problems can be clearly stated without delving into the innards of some esoteric algorithm or programming language construct.
Related to the above or actually perhaps supercedes it and should be first but anyway the point is, we have the ability and the obligation to think in business terms, like what consumer value or utility is being addressed by what we are doing? Are we doing it in a way that aligns with the time constraints of the marketplace? Yes as Technologists some of the answers to basic business questions will devolve into technical choices but that doesn’t mean we can’t think through them at a more concrete business level and one that connects us in mindset with non-Technologists.
Back in my high school and college days I made ends meet by being a New York Deli Man. Cutting deli meats for the most demanding and fickle customers known to mankind or at least to me based on my life experiences. If you wanted Baloney cut paper thin or in quarter inch chunks or put through a grinder, well that is what you got though sometimes with a snicker; try to slice 1 pound of paper thin pepperoni and see what I mean. The point is the customer got what they wanted regardless of whether that was the optimum cut and whether they enjoyed it or gave it to their pets was immaterial. The customer is always right in the Deli scenario because there is no inherent interest in the use of the product once is has been procured by the customer. That is a valid mindset for most transactions (I am stretching the point, there are many instances where the use of the product is controlled of course but I hope I made my point).
The required relationship a technology development team must possess with the rest of the organization that consumes it services is a partnership relationship , not a standard customer relationship. The technology team has to feel a vested interest in the absolute utility of what they are being asked be a part of. It’s as though I was cutting the baloney not for some anonymous customer but for myself or a Monday Night Football party I have having at my place.
Though I am not a fan of meetings for their own sake and God knows, neither are people who make their living writing code, bi-weekly or monthly formal open forums with the key business owner was something I instituted especially while at AOL. Admittedly if we were in a crunch I would either give a pass to the group that was under some deadline pressure or I would push the meeting to another week. These forums though allowed a discourse centered on business metrics tying it directly to the largely technical activities of the Development team. If the scent of Pizza permeated the hallways leading to the room where the meeting was held the voluntary on-time attendance increased markedly. In other words, it is worth the cost to buy pizza to attract the team.
Of course having an open door policy so that your staff can pop into your office without the administrative hassle of calendar events is a good policy in any context. What I did in partnership with the Business Owners was institute the same policy cross functionality with business owners themselves. Open Door is a cliche and it was a mindset that included going to someone’s office as well as email communications. The point was to create an environment with as few walls as possible , the optimum being no walls between the Business people and the Technologists.
In many instances, the root problem in most instances of Technology and Business relationships is about trust , mostly lack thereof. Trust is hard to build , work to maintain and easy to destroy so the practices to have it permeate the relationships between groups is an never ending process. Technology development has the additional difficulty that we practice a craft that sometimes appears like Black Magic to the lay person. Though I always made it a point to vociferously make the point we are not “car mechanics”, there is a certain resonance to the Car mechanic analogy. For most folks that are not familiar with the inner workings of your typical automobile, the rite of car maintenance especially when some expensive repair has to occur always has behind it the doubt one is being taken advantage of because of their ignorance.
View from the roof of the “new” New York Times Building in New York City looking towards the Bank of America NY Headquarters in the background.



Leave a Reply