blog. |
|
|
It should have been a simple request.
The VP has asked the division director of the We-Innovate Analytics team over and over to provide an operationally-useful organizational chart. He complains bitterly to the CFO, "How hard is it to draw a few boxes, say what the people do, who does what, and what is their rate? She's slowing down progress. I like her, but she is a terrible communicator. I told her--no more of this matrix-y, collaborative stuff. I have no clue what they're doing." This scenario seems like it might be something from the 1990s, but it's back and far uglier. Sure, it's not "new"--the gap between business operations and software engineering has always been difficult to traverse. Engineering managers long ago mastered the art of translating the realities of the engineering pit to the C-suite by explaining "agile" and (other) mild forms of deceit. Now, today's executives want to "leverage" big data analytics. But don't look down--the gap between the business side and data science operations is a yawning sinkhole. I know I sound snarky, but I do understand the dilemma. Many operations are of sufficient scale and complexity, that each division must be organized in a consistent and recognizable manner for efficient, fair, and defensible decision-making processes with regard to budgeting and high-level employee decision-making. Not only that, but your organizational model has always been hierarchical, and everyone gets it, including the CFO. This model requires that employees are grouped together with one clear supervisor, and running up a chain of command. This grouping is conceived as a service or product model, and your employees are classified and compensated based on the functional value they provide in completing a service to the company. After all, you can't run a business without metrics.For example, IT might have a service called the Help Desk. The Help Desk has many employees and each of this individuals function to provide that unified service. Each of these employees gets put in a box on the org chart and pinned to a salary range. At the end of the day, just punch the numbers into the spreadsheet and it should be close to the service-line budget for "human capital." Heck, you don't even have to put a name in the box to manage this thing. In this blessed scenario, an IT employee in the help desk service group can even have goals based that can be measured (metrics), such as time-to-respond. Unfortunately, data scientists (like their long-suffering software engineering brethren and sistren) are ignorant to their need to be boxed. Because these teams are often made up of hybrids of mathematicians, software engineers, domain experts, trend-spotters, and the odd dilettante, the most high-performing data analytics teams cannot operate hierarchically. Their work is remarkably collaborative, and while they may provide "services" to the organization and despite the advanced skills required to perform their work, the delivery of the services is very often relationship-based. Data scientists succeed when open communication--both internal and external--is reliable. For example, your company is a top retailer of specialty organic asparagus; but all of a sudden you realize that the Amazon is talking about spring vegetables. You ask your data science team to help you understand Amazon as a retail competitor; you require a deep analysis to try to predict their next move--and yours. Stipulating that the team understands the question, they are going to need to do three general (this is embarrassingly general) things:
What just happened here?The ability to provision the appropriate service to answer your question, actually invoked an entire cluster of skills that drew on many in the data science team, as well as outside data and sources of expertise. In this example, there were myriad questions and implications that needed to be balanced and resolved. Did your org chart have boxes labeled "dilettante," "wrangler," and "just found something arcane, but super-useful which you should totally check out!" Only you can answer that, but I can tell you that while data science groups may often appear to be operationally-decentralized free-floating entities, they are far from that. High-performing groups are most-often formed in team-based structures comprised of skilled individuals, designed to enhance operational flexibility. This enables efficient control and bottom-flow of decision-making. Or, in your comfy hierarchical model, data scientists are going to have to explicitly ask for permission to perform certain tasks not in their box (they won't do this actually), which would require calling-up the line until an authority is reached who can pass down a decision after a significant delay. An easy way to choke the process and slow down the entire enterprise of answering your questions: VPs cell phone glows at 2 AM with a text. Unfortunately, he's just dozed after working on his org chart well past dinner-- "Oh hi VP dude, is it okay if we use this kick ass model I found on Edwin Chen's blog? I'm going to have to code it up a little differently, so I'll have to stop wrangling and do some engineering. Is that okay, boss? I need to know pretty soon >:P" Beep Boop. Honestly, there are major disadvantages to team-based organizations, primarily that they are complex and hard to understand from the outside. They really are hard to work with from a budgetary and planning perspective. Yet still, they offer significant advantage in their efficiency, recognized through the ability to rapidly communicate between people in and beyond the division. Because data science operations demand highly relational and diffuse partner management, collapsing it into a hierarchical model fails to convey existing “life-on-the-ground” roles, processes, accountability, and information flows, and ultimately creates structural gaps. ("Oh shoot, our wrangler quit and we haven't hired another one yet...Someone call VP dude and tell him"). One other small thing; Apart from having a poorly functioning team of data scientists who won't deliver your magic unicorns, higher-level executives are required in hierarchical scenarios to take on more tactical responsibilities. Not only will this result in poor overall results, but will minimize their (your?) leadership value to the organization. So, how badly do you want your boxes?
0 Comments
|
RSS Feed