The trust multiplier
“All of this jumping between topics is all very well, Jim. But if there was a button on your website that said “GET HELP NOW!”, what would be the first bit of advice that you dish out?.”
OK, I made up this question. But I have been asked something along these lines a couple of times. More often, it’s something like ‘Where the hell do I start as a front-end lead?’
If you know me personally at all, then you’ll probably know that my disappointing answer to this question is always going to be ‘it depends’.
If we were having a coaching conversation, I would start by asking questions right back at you to determine what the situation is. For example, ‘Tell me why you’re asking that question now’. The first question someone asks is almost never the real question they have.
But, we’re not having a conversation, so I suspect you’re not going to be satisfied with ‘it depends’.
If I was forced to provide some pithy advice for new front-end leads to take into work with them, it would need to be generic enough to apply to everyone, but actionable enough that everyone can do something with it. Not always that easy.
But I think I have something that can address most of the mistakes new leads make, and it’s this:
Above all, work your bum off to build trust between everyone in the team, and with other parts of the product development organisation.
Trust is everything for someone in a new role.
Without it you can’t do anything much, even alone. But with it, you can enable a group of people to make big changes.
Think of everything through this lens early on. Then it will become natural.
For example, if you consult my laundry list of front-end responsibilities, you’ll see that the first item is ‘Develop a browser support policy’. Sounds easy, right? This is something that you can, in theory, sit down and prepare yourself with paper and pencil.
But that’s just making the easy part of the job easier, and ignoring the real, difficult work.
Why are you creating a browser support policy? You might already have an old and dusty one that only the front-end developers know exists in a dark corner of an underused wiki. ‘Develop a browser support policy’ has already been done.
What you probably mean is reach consensus on, adopt and enforce an appropriate browser support policy across the organisation.
To do this successfully requires trust. But you can also use the exercise as a means to build trust. It’s all in the way you do it.
Instead of unilaterally deciding on a browser support policy because you nominally own it as part of your role, do the leg work of consulting representatives from any part of the business that could be affected.
In the case of browser support policies, this includes customer support, testers, product managers, designers, UX researchers, architects, developers and others.
Tell them what you’re planning, and then ask them how this could affect them. Ensure that their needs and concerns are included in your plan for rolling out the support policy.
Do you understand the browser and device constraints inherent in your customer base? Enterprise B2B SaaS is very different to consumer products here. Talk to your product owner, UX researchers, sales and marketing teams to better understand your users, and validate your assumptions with them.
Thinking of stopping support for some older versions of IE? You’ll need to announce it in advance to loyal users who regularly use those browsers. Work out a plan for doing this with the customer support team.
Will your new policy impact existing automated tests? Talk to your test lead about how to handle it, and who should make any necessary changes.
These are just some examples. The same principle applies to every aspect of front-end leadership. Open-minded consultation and consensus-seeking is a great way to build trust.
Front-end engineering sits squarely right in the middle of the business of web product development, so trust-building is a vital tool for a front-end lead.
What is something you have done recently that improved trust in the front-end team?
– Jim
