So what is Frontend Practice Leadership?

BASARAT
5 min readOct 13, 2019

Having been at this role for a few years now, its a question I have had to tackle on occasion, so its worth jotting down my thoughts for my fellow leaders.

If you ask a room full of people (as I have on occasion) what is “Practice Leadership”, one word that resonates commonly is “Thought Leadership”. This is no coincidence, the description of a practice lead in my current enterprise begins with “A thought leader who …”. So practice leadership really boils down to “thought leadership in a particular practice”. In the particular case we are discussing, the practice is frontend. Now thought leadership in itself is something that warrants discussion.

Thought Leadership 🧠

The term “thought leader” is generally well understood even by people that are not in the lingo of software development. In fact it has its own wikipedia page with the term being a century old.

A thought leader is an individual or firm that is recognized as an authority in a specialized field and whose expertise is sought and often rewarded. Thought leaders are commonly asked to speak at public events, conferences or webinars to share their insight with a relevant audience.

So being a thought leader itself is pretty easy to summarise as “as expert in the field”. Being an expert at something is easy to observe in our industry with metrics like conference talks, meetups, blog posts (like this one), open source contributions, books, tech awards (Microsoft MVP, Google Developer Expert) etc.

Observing practice leadership internally in an enterprise is less obvious. The best advice I have in this area is to strive for thought leadership externally, and internally will follow naturally.

So thought leadership is well understood, the question now is, what value does a thought leader provide in an organisation.

Value of a Practice Lead 💸

Certain roles in our industry only make sense at scale. And the best way to observe the value they provide is by noticing the issues that are caused in their absence.

There are plenty of teams that operate without roles that you might consider fundamental to how you work in your workplace. Examples can vary widely and include UX Designer, Digital Designer, Iteration Manager, Business Analyst, Quality Assurance Engineer, Security Assurance or even a dedicated Frontend Developer. However I am sure you have experienced the kind of issues that these roles exist to remove or tackle headfirst. Practice leadership is no different. There are a few luxuries that being a thought leader and having plentiful interactions both internally and externally gets you.

Whats Hot 🔥

Many engineers often don’t get enough time to keep an eye on the pattern and practices the industry is adapting. Frontend is fast moving. Yesterday morning it was JQuery, afternoon was AngularJS, evening was React and who knows what it will be tomorrow morning. Even within the particular sub communities (e.g. React) there is plenty to keep up to date with e.g. which router is the one to use today.

Interacting with the community at large allows a practice lead to make an informed opinion that they can then share with anyone who’s interested.

A good way to measure the value is:

  • teams having a general knowledge of where the community is going.

Fluid interactions 🤝

One of the big objectives of having someone representing a practice in the organisation is being aware of the various bodies of work that is being carried by multiple individuals and teams. Good information sharing internally is just as important as good knowledge sharing and one of the most critical things that are missed in the absence of a practice lead.

One of the best tools of the trade in this arena is a regular community of practice (CoP) session. As a practice lead you get some sway in determining the culture in the CoP, my personal suggestion is to bring the same inclusive and encouraging culture that is common in many of Frontend conferences.

A good way to measure the value is:

  • how aware are the frontend developers of what the different teams are doing, and what experience different teams can leverage from each other.

Comparisons to other practices 🌾

Frontend is almost at the forefront of the kind of open source culture that is slowly being adapted by other practices as well. Because of the amount of open knowledge sharing and free tool development that has been embraced by frontend engineering, it is hard to put an upfront monetary value on different tech choices.

The best metric that I have found to work for me is developer happiness commonly viewed as developer experience / DX.

Happiness leads to multiple benefits, the key ones being increased productivity (perhaps not shorter delivery, but a definite increase in reliability), better employee retention (an increasing concern in tech) and even talent acquisition.

Comparison to other tech leadership roles ≇

There is an excellent conference talk by the Kevin Yank (director of frontend at culture amp - an organisation that knows a lot about engineering culture):

The transcript is openly accessible on conffab and the video is hosted on vimeo.

Kevin Yank’s bread and butter is practice leadership. In this talk he associates different kinds of leadership with accountability and disassociates leadership titles from kinds of leadership. Here is a comparison of the different kinds of leadership and the common titles associated with them:

Team Lead

Responsible for Team Performance.

The team lead — leads people to a timely delivery. I find this role commonly shared by iteration manager in Aussie enterprises or by tech leads in the absence of dedicated release train management common in startups.

Mentor

Responsible for development of individuals.

There is a leadership concept: separation of line (who you report to for performance evaluation) and function (who you report to for day to day tasks). In the absence of explicit mentor role, it is quite commonly your line-manager that takes on this activity. Big enterprises (or enterprises big on culture) will have a dedicated mentor for individuals.

Tech Lead

Responsible for technical outcomes.

Takes on a tech task, breaks it down into its components, designs a solution to achieve the tasks, delegates and gets it done. Common titles for this role are team lead and even tech lead. I personally prefer solution lead (the term we use at my enterprise) as they are really delivering solutions to technical problems.

Practice Lead

Responsible for the strategic vision.

Provides insights to the community and the organisation. Has a finger on the industry pulse, evaluates and shares what’s working and what’s not. Common titles are Chapter Lead, in Kevin’s case Director of Frontend Engineering and even (as your’s truly holds) Practice Lead.

So even though there might not be a person around you with the same title, hopefully now you can answer “So what is a Frontend Practice Lead?” 🌹

--

--