Think of Tech Learning As an Apprenticeship Model
I think it’s helpful to think of entering tech as an apprenticeship model. I’m frequently trying to explain how tech is not like traditional school. You don’t need to know anything before you begin. You just begin. It’s smart to have a more senior person who has experience to walk you through the steps, but this can come in a lot of forms; books, courses, bootcamps. What matters more is that you actually do the work.
Think of a doctor during her residency. What is a residency? It’s really just the doctor practicing skills again and again. That’s the whole point. Apprenticeship. Watch. Learn. Do. In tech, when you are starting down a path, the first thing you should do is creating a learning plan. High-level for 3-month and then as much detail as you can for the week. If you have no idea where to begin, make an investment in someone who knows more than you so you can get started right away. Now, produce something. On day one. Have an output, a deliverable, a portfolio asset. Many of you might say, but my first go will not be portfolio ready. That’s okay. It’s a first draft. Now solicit feedback for her. Iterate on it. Do that again and by the third iteration it likely is portfolio ready.
Why is it helpful to think of learning Tech an an apprenticeship model?
It’s helpful to think about learning tech as an apprenticeship model because if we use our learning references from the past, we’ll think about school. I know school is imperfect and there are many changes that can be made, but I’m not bashing on traditional school here. I’m simply saying that if you bring school as your learning frame of reference, you’ll be frustrated and confused about how to get into tech. If you can think about it more from the apprenticeship model, you’ll have an easier time understanding how you can learn tech.
In an apprenticeship model, you are responsible for your own learning. You are not the expert, you have access to someone more experienced than you, but you are required to bring all the questions. You don’t need to have all the answers, but you do need to have the questions. Through this lens is how I’ve come to recommend the project-based learning model. You pick a self-selected project, you begin to work through that project with your chosen tech path (UX, Digital Marketing, Dev, etc.), building portfolio assets as you go. Many beginners will not feel ready to produce a portfolio asset on day one. I recommend you do it anyway. Why?
Why you should start before you are ready
Because what you need to get hired in tech with no prior experience is — a portfolio. Why? If you demonstrate the work, you’ll become a candidate that offers value. Don’t know how to do the work? Don’t let that stop you. Just start doing it. But you don’t know how or what to do? Try something. The faster you are willing to be wrong and learn the better your progress will be.
Students who offer their first take on an asset in their UX portfolio, or a deliverable in the UX process (they are the same thing) and didn’t do it right, are still significantly further ahead than someone who doesn’t start. Once you start, we can now talk about something very specific. I can say, look here, you mentioned a solution here, but we are still talking about pain points here. What would be a pain point for your (insert problem you are working on)? Define your users’ pain more. So they’ll try to do that. Then I’ll say, okay you’re getting there, but look for intensity, examples and why that matter.
Keep in mind that all of my feedback is in a VERY specific context. That makes all the difference. If you are talking about the pain a parent feels when they try to sign their kids up for a sports team and they have to jump through 3 thousand hoops so they are frustrated, even angry and defeated, that has a very specific application. I don’t have to know very much about the problem you are solving to give you feedback on that. So you get really specific feedback on your problem which helps you learn faster. You go through that process once and you have an understanding. Now you go through it a second time and you’re not perfect, but you have more context around what a pain point is and how to find it. You find it in a different context and know you are really getting the hang of the process. You even have multiple things to talk about in your interview. That’s when you start being able to add value to an organization, when you can apply the same process in different contexts. That’s what you’re doing with your portfolio. You’re demonstrating the experience you’ve gained. So be wrong. Fail. The faster you are willing to do that, the faster you will see the whole process through and grow in your understanding of UX or whatever tech path you are following.