Lessons From Teaching SQL to Non-technical Teams

Lessons from Teaching SQL to Non-Technical Teams

From scaled approaches to more tailored ones — and why I think coaching from a distance is the future

Throughout my career, I ended up in multiple situations where I ran internal SQL trainings. While those training sessions were never a top priority for me — they are among the projects that gave me the most satisfaction. When you start seeing someone getting comfortable with running their queries, finding the information they need by themselves, building dashboards, and more generally getting excited by this newly acquired skill; I don’t know — it just feels good.

Recently, I saw the name of one of my former “students” popping up on a shared group to ask a pretty complex SQL question — and my reaction was the same as the one of Alfred when he nods to Bruce Wayne in “The Dark Knight Rises” (if you don’t have the reference — here it is).

The goal of this article is to walk you through my journey and my learnings on running internal SQL training to teach entire non-technical (or at least not SQL-savvy) teams, so hopefully you can share the gift of knowledge in your organization and get similar joy as I got.

Why I ran these trainings in the first place

Generally speaking, the situations that drove me to run these trainings fell into two broad categories:

1. Upskilling needs: Sometimes people in an organization can hit a ceiling because of their lack of SQL skills. A typical symptom of this is the apparition of convoluted processes that involve using multiple tools and spreadsheets to get to one final report. Granted, the solution is not always on the SQL side, but from experience, if you have one of those time-consuming multi-stage processes, and deep down you think that they’re got to be a better way to do what you are doing — most likely there is.
2. Resources scarcity: In an organization where analytical resources are scarce, I found it very beneficial (for both the organization and the individual) to identify individuals with “adjacent skills” (i.e. people who are used to working with spreadsheets and data) and to offer to upskill them. You end up broadening the horizon of an individual while generating more value for the business.

While there can be plenty of reasons why you’d want to run such a training (the above list is not exhaustive by any means; an argument could be made that this isn’t even mutually exclusive), it is important to be clear on what you want to achieve here. Depending on your goal, the way you’ll go about executing the training can differ greatly.

The early iterations, or how I discovered the limits of the “one size fits all” type of training

In my early iterations (back in 2015… dang, time flies!) I tried scaled approaches. The usual format was a typical classroom format: an X-week long program, with 1h weekly sessions (always at the same time on the same day), open to anyone interested in learning SQL, solely focused on SQL:

• Every week, the group learned something new, starting from the “Hello World” of SQL (SELECT * FROM TABLE LIMIT 1) all the way to how to do window functions with multiple CTEs and optimizing queries.
• Between each class, the group had to do some kind of homework (i.e. some exercises to test and solidify the knowledge they were learning in class)

While some people stuck to it to the end, the success rate (success being defined as when someone keeps using their newly acquired SQL skills post-training) was extremely low. Every session, fewer and fewer people were coming. Only a few people were doing the proposed exercises outside of class. Factually speaking, it wasn’t a success.

But I got a lot of good learnings from it:

• I enjoyed mentoring: It taught me about the joy of mentoring and teaching new skills to others, which ultimately paved the way for this blog and other activities that I found generally rewarding.
• There is a fear of SQL being “too technical”: A lot of people didn’t participate in those free trainings, or gave up at the very first obstacle, just because they considered SQL as something reserved for technical people, and they didn’t consider themselves as technical.
• Having a training without a “retention” mechanism is bound to fail: It made me understand the importance of having some kind of system to keep people retained. Relying on people’s discipline for these kinds of training is wishful thinking — in any given organization, there are too many competing priorities and reasons to not complete this learning. So either you need to find students with strong intrinsic motivations for taking your training (e.g. you have a clear goal for learning SQL) or you need to provide them with strong extrinsic motivations (e.g. their managers expect them to learn SQL to take on some more technical projects).
• Teaching SQL is just one part of the equation: Finally, and more importantly — it made me realize the importance of not teaching just SQL. Nobody uses SQL in a vacuum. The reality of SQL is that:

1. Before writing your SQL code, you need to locate the right datasets in your organization (which can be easy in mature organizations, but complicated in less mature ones, or even non-existent).
2. Once you have located the datasets, you need to locate the right fields for your query and make sure these fields contain the information you want / need (which is an art in itself)
3. From there, you need to request access to the dataset, and once you have access, you need to write the SQL code in a specific tool that has specific guidelines and features.
4. While writing your query, you need to keep an eye on computing cost, and potentially you need to re-factor things before running your query.
5. And so on and so on. If you don’t teach those elements as well, it will be hard for your students to use SQL.

All these learnings paved the way for the improved version of my program — a more tailored approach.

More recently — a shift toward a more tailored approach

After a couple of improved iterations of the above, I reflected on all the learnings I got along the way, and tried a new approach: I forgot about scale and went in the complete opposite direction. Instead of having 1h weekly sessions with a full class, I started having short weekly 1:1s with a few selected individuals.

While the program was still open to everyone, there was now a selection process to be a part of it. People who wanted “in” had to show the following:

• Clear need for learning SQL: Prospective students had to fill in a form explaining why they wanted to learn SQL, and a project for which they needed SQL (e.g. “I want to automate X reporting, I want to build a dashboard on Y). If they were selected, this project would be the one they would work on for the whole duration of the program.
• Pre-existing adjacent skills: Prospective students had to show what I call “adjacent skills”, i.e. skills that are similar to the skills you needed for SQL or data analysis in general.
• Ability (and willingness) to carve enough time on their schedule: As part of their “application” to the program — students had to validate their “learning” project with their manager and be willing to dedicate at least X0% of their time over the next X weeks to learning. X0% might seem like a lot — truthfully it wasn’t really about the X0% — it was about sending a message (insert Joker meme). This program was going to be time-consuming and prospective students needed to make sure they could carve out the necessary time required to be successful.

On the training itself — the focus was shifted from SQL to doing a project. The first session of the training was spent on splitting their project into milestones. The very first milestone was kind of the same for everyone: find a resource (free or paid, online or offline — whatever they preferred) to learn the basics of SQL — and complete it.

I want to acknowledge this might be a bit disappointing — you would expect an article that is about “teaching SQL” not to be so dry on the “learning SQL” part. My general belief is that you can learn the key concepts of SQL in a very short amount of time but it will take you months/years to truly excel at it, and the sooner you start applying it to real-life problems, the faster you’ll get to a solid level. So the bulk of the program is spent on applying it to real-life problems, not on getting a basic understanding of SQL (that you can easily get on the amazing thing that is the internet).

Once the above first step was completed, we would start working toward the next milestones. For instance, for someone who would want to build a dashboard- we would split the project into:

1. Learning about the basics of SQL
2. Finding the right datasets and query logic (with learning how to get that information)
3. If necessary, building a database (with the roles and responsibilities tied to building a database)
4. Connecting this database to the dashboarding tool
5. Designing the dashboard
6. Building the dashboard

And from there, each student was supposed to reach a different milestone every week. They were always able to ping me or email me or have an office hour during the week if they were stuck somewhere, but generally speaking, they had to complete the milestones independently.

With this system, I saw a pretty high success rate (success being defined as when someone keeps using their newly acquired SQL skills post-training). And reflecting on it — I believe there are several reasons for this:

• The selection process added friction: The added selection process made sure only the most motivated people with an actual project were part of the training.
• The milestone system was a great forcing function: Having goals is a great start, but if there is no thought given to the steps needed to achieve the goal, and more generally to the work necessary to achieve the goal, there is little chance for the goal to be ever achieved. Having a milestone system, with clear deliverables under a clear deadline, creates an accountability and feedback loop that greatly helps the student grow.
• Setting the right expectations from the beginning made everything simpler: I believe a big part of success in anything is linked to the mindset and our perception of the work. From the get-go with this program, I tried to set the right expectations: (1) It was going to be time-consuming (2) It was going to be challenging (3) It was going to be long
• (4) But we were going to take the time, we were going to overcome the challenges one by one, and ultimately we were going to be victorious
• Teaching people how to learn SQL by themselves vs actually teaching SQL: Last but not least — this key change made a huge difference in the program. It allowed them to become familiar with finding the key info they need on the web, experiment with it, and learn along the way. It made them way more independent, allowing them to keep growing, even after the program ended.

To date, the approach above is one of the most successful I have ever run. But it is pretty time-consuming, and I still see a lot of room for improvement.

Toward a more hybrid approach

At this point, the main question is: how might we scale the program above? If I reflect on the role I played in this training, it was mostly about giving direction and keeping people honest:

• In the beginning: I helped students structure their projects and break them down into milestones
• Before each milestone: I gave them some tips on the best way to approach each obstacle. If they get stuck, I gave them directions on how to unblock themselves.
• Throughout the program: I celebrated their wins, challenged them, tried to keep them motivated when they were struggling, but also kept them accountable to deliver what they were supposed to deliver under the timeline they set.

I don’t think you can automate the above — or maybe you can with LLMs, who knows nowadays — but either way, you can definitely standardize it and optimize it, and maybe do a lot of that asynchronously, not necessitating a weekly meeting. And that’s what I would want to try for my next iteration — to reduce my time spent per student so that I can train larger cohorts.

Author’s note: I am seeing more and more fitness influencers offering “coaching from a distance”, where you can talk to your coach via email, send them videos about your training, and receive a personalized program. Maybe there is something similar to do for data analytics?

Regarding the program itself, I’d love to integrate some “community” elements. In particular, I am a strong believer in the Feynman technique — which is about (in a very simplified way) teaching what you learn. Concretely speaking, I’d want the students to start documenting their learnings and start sharing it back to new students (a bit like in the movie “Pay it Forward”). I see a couple of benefits here:

• It could help scale the program (think of it as a “train the trainer” kind of approach) and allow more people to benefit from the knowledge
• It would help “students” who are now teachers to internalize the key concepts they learned and identify gaps in their understanding
• It would kickstart a huge knowledge base, that then can be used for more of a self-service approach for highly motivated individuals that might not be able to participate in the program

As always, ideas are cheap — execution is where you understand what works and what doesn’t — I am going to try to experiment with that shortly, and potentially report back in a future article.

In conclusion

Over the past 8 years, I tried different programs to turn colleagues and reports into SQL experts. I have not always been successful, but the pivot I made a couple of years ago from a wide-reaching program to a more tailored mentorship got me a lot of success and some great learnings.

My real challenge now is about the amplification of the method. How can we simplify and remove all the bullshit to focus on generating as much value as possible for the selected individuals, so that they are empowered to 10x the impact they are having in their organization? Maybe fitness influencers are onto something…

Hope you enjoyed reading this piece! Do you have any tips you’d want to share? Let everyone know in the comment section!

And If you want to read more of me, here are a few other articles you might like:

• How to Build a Successful Dashboard
• Building Analytically Mature Organizations (AMO)
• What Sets Great Data Analysts Apart

PS: This article was cross-posted to Analytics Explained, a newsletter where I distill what I learned at various analytical roles (from Singaporean startups to SF big tech), and answer reader questions about analytics, growth, and career.

Lessons From Teaching SQL to Non-technical Teams was originally published in Towards Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.