Our tech team at ComplyAdvantage is, how can I put it, extremely back-end heavy. For business reasons I'm generally not privy to, our hiring efforts thus far have resulted in a tech workforce comprising a handful of front-end engineers (including yours truly) among hundreds of back-end engineers. Now, of course, this is not inherently a bad thing if the greater number of technical problems to be solved are more back-end leaning. In our particular situation though, it was clear that this presents some challenges to the business.
Challenges of a Back-End Heavy Team
I'd say we're a pretty curious bunch at our company and that's definitely a strength. Naturally, many of our business-as-usual tasks involve quite a lot of one side of the stack and a sprinkling of the other. An API endpoint might need refactoring which dictates a small change to the UI to accommodate it, for example. This is all well and good, as it seems most of my illustrious database-loving, python-wielding engineers from the other side have done a bit of UI/React development in their time. But it's now clear to me that we just don't yet have the knowledge sharing in place to make that frictionless. It turns out the same questions would come up again and again: Do I need to build this basic component from scratch? Where's the best place for this new code? What's a good approach to testing?
The Need for Skill Sharing
Well, as it turns out, myself and the rest of ComplyAdvantage's front-end chapter has the answer to these questions, so it sounds like a pretty good idea to do some skill sharing. I've held a couple of these sessions so far and though there will be many more in the future, I feel like now is a good time to share some of the things I've learned from running them. There is also a selfish side-benefit that having these things documented means there's less pressure on my own memory as my Christmas break approaches.
Lessons Learned from Front-End Upskill Sessions
Anyway, I digress, here are some things I've learned from CA's first two Front End Upskill sessions.
Listen
You only know what to teach once you find out what others want to learn about. There are two parts to this - find out what skills people want you to share and discover where their current skill levels are. After all, there's no point teaching a mechanic how to refill wiper fluid. This doesn't have to be anything particularly laborious, a simple Slack survey sufficed for us; multiple choices ranging from "I know some basic HTML/CSS" to "I've worked on React codebases professionally" is all it needs. This way, you can tailor the focus of the material to your audience.
Don't reinvent the wheel
Our teams work in a hybrid model so this means our sessions will always be remotely held, to remain as inclusive as possible. So my first inclination was to ask questions like "How can I teach the basics of state management or UI testing in an hour?" but quickly remembered other people are already doing that, incredibly well. So, how can I deliver something fresh and valuable, here? The answer is to...
Make it relevant
By all means, share your useful learning resources (sometimes finding good courses online is unclear to someone with less experience) but to make it really worth everyone's time, tailor it to your team. In our case, rather than teaching React itself, it was a case of sharing where our component libraries live and how to work with them. Rather than how to manage UI state, it was more useful to share how we manage various types of state in our UI.
Make it realistic
By now, your audience has probably sat through roughly eight million slide-based video presentations (true statistic... probably). So where possible, make the format more interactive. For our first session, we picked up a 'good first issue' from our design system JIRA board, made the changes, updated tests and got it into code review, discussing different approaches along the way. As everyone on the call knew how to write the code, the value wasn't so much in the code itself but in where to make those changes and show what processes we follow.
Make it last
Live sessions with questions and feedback are of course more valuable than one-way streams but I can't stress enough, the importance of documenting and recording your sessions. A simple shareable document will suffice, with links to resources, repositories and recordings. It's very difficult to find a simultaneous free spot in a large group's calendars so inevitably some folks won't be able to make it.
Conclusion
I hope this encourages you to share your skills with your colleagues - it can be as rewarding for you as much as anyone else. I'm learning myself of course, so if you've got an insight into how I can make these skill-sharing sessions even more useful, I'd love to hear about it. My door (to my Slack/email) is always open.