Fill in the form to arrange a demo
Written by Ed Long Solutions Architect Manager
« Go back
22 Jan 2019  |  Culture

How to Bridge the Tech Divide Within your Company

5 minute read

I’m Ed and I joined Paddle late in 2017 as the company's first Solutions Architect. At the time, our staff were often dependent on our Product and Engineering teams for technical understanding of our platform and tools. Since then, we’ve supported Paddlers to better understand what our technical teams do. In this blog I’ll be explaining, together with Senior Front End Engineer Hector Lorenzo Pons, how we’ve gone about introducing coding basics to all new starters.

How can you help your non-technical teams understand your product?

Teaching your staff about the technical work that goes into your product is valuable. The more people who understand how your product is set up and how it functions, the better the customer experience. Of course, every tech organization is comprised of teams with very different skills and varying levels of technical knowledge, which can make it difficult to educate your staff on the complexities of your technical work. Here’s how we went about tackling this issue at Paddle.

My role as a Solutions Architect was introduced so that our commercial team could offer great technical support and advice to sellers building their web checkout with Paddle. One of my first challenges was finding ways for Paddlers to be able to be more self-sufficient when dealing with technical enquiries and bridging gaps between our technical and non-technical staff.

Our Sales team at Paddle is much more technical and inquisitive than your typical sales rep but I could see that they were keen to learn more about how our customers use our platform. I started by organizing 1-1 coaching sessions with my colleagues and, soon, several Sales staff were up to the point of being able to build a simple HTML + JavaScript webpage hosting a Paddle checkout that opened on a button click. It was simpler than most of them realized and going through the process themselves gave them a lot more confidence when talking about implementations of our checkout with the customers they spoke to.

We soon added the ‘Build a Checkout’ 1-1 coaching session to the onboarding process for new Sales team members, but also got interest from other existing staff and even engineers who had only worked on back-end features and hadn’t spent much time with the checkout library.

With the increased interest, we decided to offer a group workshop once every few weeks as an optional add-on to the standard Paddle onboarding timetable. This soon evolved into making ‘Build a Checkout’ a standard part of onboarding for all staff. In a group setting like this, you get to see a mix of technical, commercial, marketing and administrative staff all writing code together, asking questions and helping each other out. It’s a great way to bring new starters up to a common level of product understanding while also getting a sense of the range of background knowledge among your hires.

How do you plan a workshop like this?

You want a workshop like this to be as hands-on as possible while still being accessible. For us, this means opening with a 15 minute presentation outlining some basic concepts and terminology in web technologies and then jumping straight into a practical. We start with a very bare bones HTML page structure and walk through how to import the JavaScript library and add elements, as well as how to make some basic changes to the page’s styles and content.

It’s crucial to keep your main goals in mind when planning an introductory workshop such as this, focusing on simple and achievable aims for the sessions. Our three goals were:

  • Participants should be able to follow our documentation to do a basic checkout implementation, starting from a basic page structure without help.
  • Participants understand the concept of importing external CSS and JavaScript libraries.
  • Participants begin to see the options available to sellers to customize the appearance and behaviour of the Paddle checkout.

Why transparency about your product is key

The most important thing to do when explaining your product to all staff is to make sure the whole architecture of the product is as transparent as possible. Everyone assumes some level of magic in any technical process but demystifying how the product works is positive in two ways. Firstly, non-technical people understand the pains and complexities behind an apparently straightforward operation. Secondly, having tech-savvy employees is good for any company: they will be better at selling, better at resolving customer queries and better at designing landing pages for it.

This is why we also like to begin our workshops with a quick detour of the different parts of our system, including backend services, serverless components and frontend applications. How do they communicate? What happens when a user clicks ‘Pay with card’? Why is it so easy to implement Paddle.js on a website? It’s really important to give your staff a picture of what goes on behind the scenes to fully understand the full product picture.

The challenges of teaching all your staff

Technical people often assume some basic technical ability of everyone, but here ‘basic’ is a relative term. Engineers can get exasperated when trying to explain fundamentals of coding to novices and, needless to say, this goes both ways. Someone from Marketing may talk about not having enough MQLs and engineers will roll their eyes and leave the room.

We realised as we began these workshops that it was also a learning opportunity for engineers to re-assess and test their assumptions when working with non-technical people and so Hector and other members of the Front End team started to lead sessions along with the Solutions Architects. For most engineers, working with people who are new to code is kind of an epiphany: they realise that users might not be like them after all and start working on their “technical empathy”.

While we often have a mix of engineers and non-engineers in a workshop for the new staff, the time taken to get through the practical part does vary depending on the balance. One week we had a cohort of nearly all front-end engineers, so we got through the workshop in about 10 minutes and then moved straight on to building more advanced implementations, while on other weeks we’ve felt the time constraints of the session when introducing several people to coding for the first time. The exercise absolutely encourages patience and empathy from both sides; your company’s veterans and the new cohort alike.

Adapting your training as you evolve

When we started working on this ‘Build a Checkout’ workshop, we used MAMP (a nifty application to create a server in your own computer) to run the checkout examples locally. While it’s a useful piece of software, we realised we could save time and focus more on the core workshop outcomes by using online code editors like JSBin or CodePen where you can start coding straight away without worrying about servers.

We’ve made changes based not only on our experience of the sessions but also on feedback from new starters. Of course, no two sessions are the same and some groups are more excited about coding than others, but we’ve found that the workshop is a valuable addition to the onboarding timetable. It’s good to improvise when needed to make sure nobody gets bored or lost along the way and it’s very important to keep refining your workshop as your company grows and changes.

Want to join Paddle? We’re hiring! Check out our career openings here.