Message to Som Gollakota

Please Enter All Requested Information Below
Your Name
Email Address
Message
Leave this Blank:
Hyderabad, India
Delivery Excellence - Technology and Strategy Organization
April 05, 2010
F
irst step in creating a Technology and Delivery Organization is to perform a talent assessment of the current workforce and identifying their individual competencies. The competencies could be in terms of their technology skills (primary and secondary) as well as the applications that support the company's business verticals. This enables the organization to understand who would better serve the company in which sub-org/position/place. The focus of this effort is to
  1. Identify the technical subject matter experts (hard technologies)
  2. Identify the application subject matter experts (specific "bread-and-butter" applications)
  3. Align and utilize the workforce in the areas they are most suited and can contribute effectively
The identification process is a bottoms-up approach where it occurs at the lowest levels first. Identify which architects, analysts, developers and testers have expertise in which hard technologies and business applications. Identify which managers are most experienced in managing those technologies and applications (Ops, Arch, Dev, Test). Create new positions if necessary, such as Data Systems Development Manager, Web Applications Development Manager, Data Systems Test Manager etc. Further, this identification occurs per Business Vertical (Portfolio). Depending on the depth and width of the domains (number of applications or database to support, number of people to manage etc.), either one manager can fill multiple roles, or one role can be divided among multiple managers (with clear delineation of responsibilities).
Technology and Strategy Orginaztion Structure
Consider the organizational structure shown in the picture.
In the org structure, developers are aligned under Development Managers who own the applications pertaining to their business vertical (domain). Depending on the size of the organization and complexity of the business domain (number of applications, customers etc.), another layer (a Portfolio Manager) may be introduced right above the Development Managers. The Dev Managers (or Portfolio Managers) report to the Director of Development.
Next up, in the Quality Assurance Organization, Testers and QA Analysts are aligned under QA Managers and QA Process Analysts (defining QA Processes for a Technology Vertical) are aligned under QA Process Lead/Manager. Both Test Managers and QA Process Lead/Managers report into the Director of Quality Assurance.
Finally, the analysts that perform lights-on operations for the company's applications (in production), and the Architects that work on the overall applications/enterprise architecture, are aligned under Operations Managers, who report into the Director of Operations and Strategy. The question here is, why do I want Architects aligned with Operations rather than Development? Operations is the closest that the technology can get to the actual business of the company. They understand not only the technology aspect of the business, but also the actual business usage of the application, what can go wrong, and what the architecture must be for things to work right for the business.
In the given org structure diagram, there is an area that overlaps between Development and Operations.
  1. When serious production outages or issues are identified, Analysts can analyze the problems and Architects can advise on any architectural issues/bottlenecks, but to actually develop a fix, we need developers.
  2. When developing a solution, either to an existing production issue or a new business need, the developers require the expertise of an architect to take a global (bird's eye) view of the enterprise systems architecture and actively contribute towards the development design. Without such a view and help, the solution may not be effective (or worse, may have a severe negative effect on the existing systems in production).
Therefore, you see a red two-way dotted line between Operations Managers and Dev/Portfolio Managers, representing a dotted-line reporting hierarchy between Ops Managers and Developers on one hand, and Dev Managers and Analysts/Architects on the other. It is the criticality of the collaboration between these two individuals (Developers and Architects) that results in a dotted line hierarchy between the two groups. The other areas (such as Test), although just as critical to ensure quality of the solution, are considered quite independent, so that they can focus primarily on quality without external delivery pressures. Operations Group is a key "downstream" stakeholder, and the Development Group is a key "upstream" stakeholder to the QA effort.
----------x----------