Our Next Evolution in Deploying UX, CX, and Agile into Digital Consultancy
A few weeks ago Dan Burka moderated a fantastic discussion on the Designer/Developer/Product Manager “chasm.” The conversation was between Amanda Richardson, Arianna Orland, and Anthony Casalena, and provided some insight into how several project-oriented technology companies are addressing team structure in order to ship fast and well.
A good deal of the conversation referenced, either explicitly or implicitly, the tension that exists between occupiers of these various roles. It drove me to consider the significance of that tension and how it might be an actual driver of productivity and collective creativity.
Middle Management Can’t Exist When There is No Middle
At PCR, we just underwent our 8th or 9th or 10th reorganization since I came on 7 months ago. While this likely sounds terrifyingly unstable to managers in traditionally structured businesses, for us it is a sign of growth and maturity. We actively experiment with different team structures as the problems we are facing alongside our clients change. In addition, we are still a small enough team that the addition or subtraction of a single member ripples across all mentorship spheres. We’re adding people, so the organization evolves.
Initially a good deal of my job focused on attempting to build robust processes to make sure that our streams of output were all high quality. However, since we’re working in a fundamentally creative space, that approach was flawed (one of my first insights). Now my focus is on optimizing minimalistic processes as well as dynamic team structures that support autonomy, user-focus, team learning, and ultimately high-quality (but never deterministic) output. These structures look different depending on the deliverable or client, and often times members of one team structure are expected to adapt as they float into the mentorship sphere of another team.
Teams are organized around problems, grouped generally into client-side and org-side. It can be really exciting to watch someone who works on the client side conceptualize a winning solution to a problem with an HR process, and we want to celebrate the development, rather than worry about from where it came.
How Software Dev Can Be a Metaphor for Org Dev
I have talked a good deal about how we are attempting to set up our teams to select for winning solutions instead of arbitrarily celebrating “seniority” or leadership. In a sense, this is a result of my observations (both direct and indirect) of what works in building software solutions. “Agile” or “responsive” or “adaptive” or “emergent” are all terms that get thrown at these ideas, but ultimately, we’re building teams that rally around problems and optimize solutions based on iterative methods. We select solution pathways that we determine to be high-efficacy, and then test and evolve those based on relevant feedback channels. To borrow from Boyd, we are building systems of “intuitive competence.”
.png)
Necessarily, these team structures change often. If you happen to follow my posts, you’ll recall how we were experimenting with pairing a few months ago. We found that pairing is completely appropriate for some types of tasks (short commits, design pieces, or campaign microsolutions) but far less effective when addressing some larger-scale and more strategic problems. We’re now experimenting with triads for many of the reasons discussed in the panel referenced in the opening.
Instead of a linear tension like that that exists between a designer and a developer, having three biases working the same problem set can drive a much more dynamic approach. On the strategic planning level (one at which we operate quite a bit as we have shifted to being more of a digital consultancy than a marketing shop), dynamic frameworks are more important than one-off solutions. The triad can be less efficient at building, especially when we break down the traditional silos of the PM/Dev/Designer, but we intentionally deviate from efficiency in favor of flexibility for planning stage deliverables.
The triadic structure is designed to take advantage of how discrete team components tend to generate solutions that service a specific area. These areas are not necessarily the end user of the product. Accounts personnel’s job is to be the voice of the client within our agency, so they tend to provide solutions that make clients happy (as they should). However, we recognize that the client is only a component of the equation, and many times fundamentally misunderstands the journey of her/his prospective customer.
We‘ve termed these biases and believe that setting several biases to work together, as well as having an overall organizational bias toward the user/customer/prospect has yielded progressively better results. We also find that when the solutions need to be iterated, those driven from triads are more rapidly evolved than those from pairs, likely because we have added half again as much cladistic branching potential in the build process.
How Adaptive Organization Gives Rise to Responsive Products
The beauty of digital is that it is incredibly well-suited to responsiveness. We can, with very little friction or time, develop a solution, test that solution, and reiterate based on what we’re learning. In print marketing or advertising this is happening at a year or 6-month resolution. We are adjusting campaigns weekly, daily, and sometimes even on the hour.
What is really exciting is that we are becoming predictive. We are starting to anticipate opportunities to develop microcampaigns that connect with clients and their customers based on local and regional happenings. We are looking at how people are responding and using clients’ web portals and synthesizing predictions about how we can create value proactively for them. We aren’t super good at this yet, but we’re getting better.
In order to manage those frequencies, we are asking a lot of our teams. Most of them do not come from technology backgrounds, and are not used to being asked to explain to a client how there is a difference between their perception of the problem and the problem. Team members tend to internalize instead of pass off deliverables. They worry about failure when we’ve built systems that are designed to use failure to improve. We’re pushing them into uncomfortable spaces and in some cases literally sitting alongside them to help develop the habit of letting go and resolving on the overarching strategy. But there is great power in watching an email come through with the subject line “URGENT!!” and sending it to the Solve Later folder. The process is to breathe, slow down, recall the goals, and bring in a team to fix. Slow is smooth. Smooth is fast.
What We Found There
The crazy thing is to walk into an accounts team meeting now and hear them talking about the customer journey or to overhear the sales team addressing illogical navigation pathways in a prospect website. Again, this is by and large a team of marketing and advertising people. We’re beginning to see them take seriously the thought patterns of user and customer experience and execute according to iterative methods despite many not knowing the difference between CSS and C++. This has been an interesting experiment, and we’re starting to see really promising results. Non-technology people can learn the lessons we’re bringing from the technology space and port them to products and services that have heretofore been addressed by outmoded approaches. We are seeing the marketing buzzwords turn into actual, meaningful character traits and I’ll tell you, I couldn’t be more stoked.
This article was originally posted on medium.
