Design orgs and the centralized, consultancy model
Design leaders that structure and operate their teams as if they are a centralized, internal consultancy within an agile product organization will rarely make an impact.
From my experience, this doesn't work for several reasons, one of them being that it makes it difficult to consistently build the necessary long-term relationships with the other cross-functional teams. Building trust with the working teams is difficult when designers are frequently parachuting into projects and then leaving to move on to the next thing.
Another thing that tends to happen is the designers may also take a consultancy approach (big reveals and artifacts upon artifacts!) to their projects with a highly stringent "design project" plan that almost never holds up in an agile environment. This could be due to factors like not including engineering at any point early in the process or designers needing to go down that checklist of artifacts because that's what the project plan laid out, quite often making them a bottleneck.
It goes without saying but designers need to be adaptive in order to thrive in the very inconsistent environment of software development. The centralized, consultancy approach works in only a few cases, but when it comes to designing for outcomes and seeing things through, design orgs need to stop isolating themselves from the rest of the organization. We rely heavily on product, engineering and the rest of the org to be truly effective.
Comments ()