I’ve been running design organisations for the past nine years. First as the senior-most Individual Contributor in a design immature company where I was trying to establish a design practise, then as it’s head of design, and most recently in that same role in a more design mature company.
Running a design organisation consists mostly of work that no one sees, and that even fewer people understand. To some people, this can make the work seem trivial or easy, to others, superfluous. One has to decide on a daily basis whether to work on advancing an organisation’s understanding of design and design leadership or actually doing the work. One of those choices is better for your career, the other is better for your team.
Design is and will never be a true peer of engineering. We have lost that battle in almost every company I know of and we should stop fighting to be on par - we’re outnumbered and outspent. The better investment of our time lies in getting as close to the product organisation as possible. The relative scale of that team and the overlapping incentives with design make this a much more viable and equitable partnership.
Great design work rarely looks perfect. As designers become more experienced and work on more complex business problems their work has to balance a massive increase in competing objectives, stakeholders and other complexities. Great design work at the strategic level, therefore, is most often comprised of the best set of compromises available, not an idealised and pure design vision. This is one of the most difficult parts of the transition for designers from being a senior IC to reaching principal level
Hiring is half of the job. You can’t outsource it, you can’t delegate it away. Building a team with a strong identity and culture of doing great work requires leadership to fully invest in hiring. Otherwise, you cede control of what the team becomes as new people join it.
Alongside the daily work against quarterly or annual roadmaps, a design team must have an articulation of a longer-term design vision which encompasses both design and product-led ambitions. Done well this becomes a businesses best artefact for its mid-term strategy. This artefact should serve to offer a direction of travel which informs the roadmap, sets a standard for the quality of user experience, and poses important questions to the organisation about where it spends its time, and what is truly important beyond the rhetoric.
A multi-disciplinary team in which there are 15 engineers and one designer is an engineering team with a designer. This is not the ideal place for designers to prosper. A design organisation, therefore, needs to operate horizontally to give designers a team of their own. It’s this structure that in turn allows for investments in things like design program management, design systems, Learning & Development programmes, etc.
Managerial hiring is critically important - a bad hire in a management position can completely break a team. Giving Individual Contributors the opportunity to transition into management is one way to avoid this, but you can’t avoid hiring managers forever. This is where it’s important for ultimate hiring decisions to be unilateral. As a design leader, you have to make these decisions based on input but you can’t hire by committee, especially in important roles such as these.
Hiring should ideally happen cross-org, rather than with individual teams running their own hiring efforts. The latter creates a situation whereby it’s impossible to have common standards and requirements, and in turn creates an inflexible and disjointed design team. This is rarely popular because it’s slower and harder than devolving hiring responsibilities - but, it means as a leader you retain some control over what the design discipline is and what it can be held accountable for.
It’s okay to occasionally have to ship half a feature or a stripped-back version of it. The constraint is rarely enough design capacity and so it can be frustrating when work gets chopped up, but if you’re going to die on each one of these hills you’re going to be miserable. Designing the ideal version and helping Product & Engineering work out how to get there iteratively is good design work. Designing something that’s impossible or impractical to build but beautiful is not.