Week 3 post by Leslie - Interview with Citrix Systems UX Designer

For this week's application assignment, I interviewed Patrick Kovacich, a lead user experience designer at Citrix Systems. I wanted to investigate his company's organizational structure to determine whether the realities of that structure reflect the expectations established in our readings.

---

LW: Please tell us where you work and what you do. How do you fit in to your company’s organizational structure?

PK: I work for Citrix Systems, Online Services Division (formerly known as Citrix Online) as a user experience designer for our collaboration product offerings. [LW: Many of you are familiar with these products, which include GoToMeeting, GoToMyPC, GoToTraining, and GoToWebinar.] I am a design lead, meaning I bridge communications and planning between our engineering department and our product department, merging product market requirements with engineering realities in order to create the best possible experience for the end user.

Within the organizational structure, I am a production-level team member, but I also work on roadmaps and planning with stakeholders throughout the hierarchy.

LW: How is Citrix structured, generally speaking? Are org charts used to define relationships, or is there a less formal approach?

PK: Org charts do exist for HR reporting, but in practice production teams work in a fairly flat manner and each individual has a large amount of autonomy. As you go up the chain to executives, the hierarchy becomes more rigid.

LW: And how is workflow managed from a structural perspective? What divisions are used to organize people or the tasks they perform?

PK: Most of the labor is distributed to departments according to skill set. Many of those departments are related; for example, the UX [user experience] and QA [quality assurance] departments are part of the blanket engineering group.

There are some ad hoc skunkworks-type teams, but these are usually created to pilot processes or ideas and then hand their work over to a larger team when it proves viable. On the other hand, many multi-disciplinary teams remain together for extended periods, from inception to release and even into legacy support.

LW: What’s your impression of the success (or shortcomings) of the structure you've just described?

PK: Autonomy is great for employee morale and allows for innovation to be nurtured, but can also lead to "pet projects" or conflicts among horizontal roles that drag out projects or waste vast tracts of time.

Learning as much as you can about different tasks and roles can lead to more resilience and flexibility within a team, but also often leads to decreased overall value in my experience. A preference for strong stables of specialized SMEs [subject matter experts] has served us quite well.

LW: Can you provide a specific example of one of the problems you just described?

PK: Sure. We have some people who have been with the GoToTraining team since the product was approved in about 2007. Version 1.0 was released in February 2010. It lacked some key features at release, and customer adoption has been slow-- which in turn makes prioritizing the addition of those features fiscally tough. It's a vicious chicken/egg problem.

Meanwhile, we have a team that sees GoToTraining as their "baby" but is really not providing the most value they could to the company with their time and prodigious talent. Disbanding that team and making a hierarchical decision about whether to support the product or not are two things our current structure has not allowed to happen, at our peril.

LW: Has Citrix's organizational structure always been what it is today, or has it evolved in your time with the company? 

PK: My experience has always been within the product and engineering side of the company. There has been a major shift toward a more horizontal structure that followed our adoption of the Agile software development processes. Horizontal collaboration is a key tenet of scrum/Agile.

In other areas of the company, there are still some well-established hierarchies that have become more rigid rather than less -- marketing, for example. The marketing hierarchy tightening is probably the result of new blood in key areas and an executive-level focus on short-term financial goals versus internal product diversification. Our finance and accounting departments operate roughly as they always have, as there have been no business drivers for them to change. 

LW: What information systems facilitate communication and coordination at Citrix?

PK: We use a tool called Authoria for tracking bonuses/goals and performance evaluations, but it is used maybe four times a year, even by managers. Almost all the rest of our tools are very flat, collaborative project management/progress monitoring tools.

Large blast email is still our common language, but more and more these communications contain links to JIRA tickets, Confluence wiki pages, or in the case of HR or marketing, SharePoint sites.

We used to use a tool called Version 1 which tracked all our projects company-wide and allowed deep visibility into individual team progress and project progress. This functionality has now been shifted over to JIRA, which also replaced our bug tracking system. One less thing to log into. This is a very open and transparent system, though I imagine it is not peered into all that often outside engineering.

[Patrick had to limit our interview to these six questions, which he took while catching a connecting flight at O'Hare.]

---

I've visited Citrix Online's offices in Santa Barbara, which exude an undeniable "West Coast" vibe. Flip flops seem to be the only dress code requirement, folks bring their dogs to work, and a quick foosball tournament between friends can occur at any hour of the day. This laid-back atmosphere, along with the company's penchant for hiring the young, creative, and tech-savvy, had me convinced that Citrix's structure would more closely resemble the horizontal plateau of W. L. Gore & Associates (Townsend, 2000) than the strict, centralized hierarchy of Oracle Corporation (Daft, 2007). It seems the truth is actually somewhere in the middle.

Mr. Kovacich describes a "hybrid structure" that "combines characteristics of various approaches tailored to specific strategic needs" (Daft, 2007, p. 120). For instance, he explains that the production-level engineering associates near the bottom of the organizational structure operate in a fairly horizontal environment with a high level of autonomy. Yet the company's leadership follows a much stricter hierarchical pattern, and other departments -- Mr. Kovacich cites marketing as an example -- are vertically organized from top to bottom. Daft observes that this marriage of functional and horizontal structures is a "hybrid approach that is increasingly used today" (2007, p. 122).

A hybrid structure is subject to the relative weaknesses and advantages of each component structure (Nohria, 1995). For instance, the horizontal structure of Mr. Kovacich's production group engenders high employee morale, nurtures innovation, and increases agility, but it also creates an environment that limits "in-depth skill development" (Daft, 2007, p. 116) because everyone wants to grow and develop across multiple competencies. Kovacich suggests that the introduction of some more vertical decision-making processes might help his colleagues focus on "meeting organizational goals," (Daft, 2007, p. 102) a critical advantage of functional structure.

Citrix employs a number of vertical and horizontal linkages. While Authoria allows line-of-sight performance management, the company's "Wiki" pages and project tracking tools are information systems that facilitate easier horizontal collaboration (Daft, 2007). Mr. Kovacich also describes the ways in which Citrix uses both teams and task forces. Citrix prefers permanent project teams, perhaps because they "provide more horizontal information capacity" than other horizontal linkages (Daft, 2007, p. 99).

My interview with Mr. Kovacich crystallized the overall theme of the week's readings: no single organizational structure is free of flaws; instead, each has inherent advantages and disadvantages.   Even if a structure seems ideal to support a particular company's organizational strategy, this evaluation should be revisited regularly and tested for "systems of structural deficiency" (Daft, 2007, p. 123).

References

Daft, R. (2007). Fundamentals of organizational structure. In Organization Theory and Design (9th Ed., pp. 88-125).

Nohria, N. (1995, June 30). Note on organizational structure [Case no. 9-491-083]. Boston, MA: Harvard Business School Publishing.

Townsend, D. R., & Harder, J. (2000). W. L. Gore & Associates [Case no. UVA-OB-0700]. Charlottesville, VA: Darden Business Publishing.