Thoughts

Supporting the strengths and struggles of a diverse team part 2

Building authentic relationships

Design teams are not a hive mind or Borg collective. Like any team, each person in a design team is there for their own reasons, some of which have nothing to do with the success of the organisation that pays them. In return, an organisation hires people because it has its own needs, not because it wants to support the career and life of that individual.

A good employee wants their organisation to succeed, and a good organisation wants its employees to succeed, but that’s not often the reason either of them have entered into the relationship. As long as we recognise that, I think that’s fine — that’s the basis for an honest relationship. But in my experience, this relationship only works if we intentionally acknowledge this transactional nature in an authentic and structured way. This concept is particularly important at the team level, because this is where those frustrations are most keenly felt.

It’s easy, when you are running a team, to hyper-focus on the goals you are under pressure to deliver: a good delivery, happy stakeholders, high chargeable hours — whatever goals you are charged with achieving. When we think of our design team as just resources to achieve those goals and forget that our team members have their own individual goals, it leads to frustration and hurt feelings all round. When we forget the transactional nature of our relationship, we tend to fall into assuming shared goals. And because of this, both parties become surprised and frustrated when one party doesn’t seem to support the other.


Leaders get frustrated when designers complain about the type of work they are doing, or don’t seem to care about the success of the overall organisation. Why are they complaining about doing the job they were hired for? Why don’t they care about our success?

Designers get frustrated that they aren't progressing in their skills or careers, and that they are expected to work like they own the company without any of the rewards of actually doing so.Why are they blocking my development? Why am I being asked to do that after hours for no reward?

To build a high-functioning team, it’s really important right at the start of the relationship to learn what the goals of each designer are, and to make serious and visible efforts to support them at the team level. Likewise, it’s really important to be transparent about organisational goals, why they were hired to support those goals, and what we need from them to succeed. This stuff is obvious, I know. Many high-functioning design teams work on this principle, but I’ve experienced enough that don’t that it’s worth talking about here.

In my experience, the key is to be intentional and structured about it. It takes real engagement from both parties. In my case, I’ve made progress with it by sitting down with my team, plotting out what their goals are, what they need to progress them, and creating a structured plan with a high level of accountability attached to it. Often the bulk of what designers need aren’t things you can provide for them — they are things they can only do themselves — but there are always opportunities for us to support them as an organisation and as a team. In the future, I'm going to make more of an effort to do the same in reverse, and help them understand more explicitly what I need from them, and why.

This creates an environment where designers understand why they are doing the work they are doing, even if it isn't exactly what they want to do at that moment — and where they take it seriously anyway, because they understand why you need them to do it, and know that in return you are taking them seriously. And in return, I do take them seriously, and make a real effort to get them the opportunities they need to move towards their goals.It’s as simple as recognising that you both have your own goals, that they might not be the same, and that that’s ok. But for that acknowledgement to have a positive impact and create motivated, high-performing, and happy designers, it needs to be followed up by real, structured actions. More on that in the next two posts.