In my post on Framing the Technical Growth Conversation, I shared a skill ladder I use to discuss technical competence at work. If you haven’t already read that post, I recommend reading it before continuing here. I hope that article makes clear why having the language of a ladder is useful – but it is reasonable to wonder how to actually climb the ladder.

Here’s the ladder itself, for reference.

0	know nothing
1	have a few unconnected bits of knowledge about some components of the system
2	have some knowledge of a few components of the system; can see how some components come together; know how to ask questions about the system
3	understand most components of the system and how they fit together; know where/how to find more details independently; can independently make or review changes within a component
4	could clearly explain most components and how they fit together; can review and approve major or cross-component changes confidently
5	could structure and teach detailed a workshop; can design major changes; understand all pieces of the system, how they fit together, and why

Not every strategy is available for every person or every type of thing to learn, so take from this post what is useful. I would love to hear arguments about details and alternative suggestions in the comments.

0 to 1

0	know nothing
1	have a few unconnected bits of knowledge about some components of the system

In some ways, this rung is the easiest: you just need to start filing away a bit of knowledge, without bothering to connect it up or actually understand it fully. However, a 1 is almost never going to be your final goal – you won’t be able to actually do much with level 1 understanding. So your focus in this stage shouldn’t be getting to a 1, but instead should be getting to a 1 in a way that sets you up for success in future rungs.

• Take notes. Your notes should be specific and useful to you, so that you have a reason to reference them often. For example, the first time you access a new database, write down the specific steps you needed to take. When someone brings up a term you didn’t know, write down the term and the definition. Don’t worry about formatting your notes nicely – you can fix them later when you have a better understanding of how they should be arranged.
• Ask for early explanations. Ask others to give you overviews of the system. You won’t absorb everything (or even most things) during this process. As you listen to these explanations, you should:
  • Notice whose teaching styles best line up with your learning style
  • Start to hear terms that come up often and write down their definitions
  • See what everyone brings up, since those might be the best things to focus on first
• Focus on the purpose. Understanding why a system was built (who built it, and what problems were they trying to solve) usually makes the system more approachable. Understanding this story will help you better absorb and remember information later on.

1 to 2

1	have a few unconnected bits of knowledge about some components of the system
2	have some knowledge of a few components of the system; can see how some components come together; know how to ask questions about the system

You have a few pieces of information, but you don’t yet really know how anything is connected. My best analogy for this stage of learning is that people have started to hand you books and so far they’re all in a pile on the floor. The next step of the learning is to actually build a bookshelf so that you can absorb information about more components and see how they relate to each other.

• Look for analogies. Are there systems you already understand that work similarly under the hood? Or other tools that perform some of the same functions? How is this system different and what does it have in common?
• Structure information. Here is where you really make use of what you did in rung 1. You have some pieces of information; how do you structure that information?
  • Get someone to give you a diagram or picture of the system. Looking over the terms you know, where does each one fit? Does it describe a specific component, a way that they relate, a goal, a theme?
  • Organize your notes. What is operational, what is explanatory? What do you expect to need often and what will you just reference occasionally? Is there anything you wrote down that might not be right or is contradictory?
• Ask questions. One of the criteria for rung 2 is to know how to ask questions. So naturally, when you’re trying to get to that rung, you don’t know how to ask questions yet. Accept that your questions might not make sense and may be repetitive, and ask them anyway.
  • If you are nervous about wasting others’ time with these questions, schedule an hour with someone whose teaching style you like and let them know in advance that you want to practice asking questions about the system.
• Take intro courses. A good introductory course will help you structure information, ask better questions, and build an overall strong foundation for future learning. Taking a course already primed with bits and pieces of information (that is, you’ve already gotten to level 1) will allow you to absorb more of the details and connections. With online courses, I recommend skimming, jumping around, and repeating sections as you need!

2 to 3

2	have some knowledge of a few components of the system; can see how some components come together; know how to ask questions about the system
3	understand most components of the system and how they fit together; know where/how to find more details independently; can independently make or review small changes within a component

You’ve started to understand how things come together, but you know you have a lot of gaps. This might be the part of the learning process that feels the worst: you’re most able to see how much you’re missing. The biggest challenge here is to take things one step at a time and set realistic expectations for your own growth. Your goal here is to be able to find information fairly independently and get to a point where you can competently make well-scoped changes. Your goal is not to suddenly and magically become the leading expert in the world on this system.

• Solidify your bookshelf. Going from 1 to 2, you started to build a bookshelf for the information about the system. That bookshelf was probably built a bit badly, and now is the time to make some improvements to the shape and soundness of how you’re structuring information.
  • Build a system diagram from scratch. You’ll probably need a few iterations  with feedback to get it right, and you’ll likely learn a lot in the process.
• Take on well-scoped work. It may not be immediately obvious what work actually is well-scoped, so you may need someone with more expertise to give you some guidance here. Can you take on work limited to a specific component of the system? Are there changes you can make that have a clear testing path? Are there example work products very similar to what you are trying to produce?
• Schedule help. When you are trying to accomplish a task and get stuck, schedule support between around 1 and 4 working hours in the future. Once your meeting with a coworker is on the calendar, write down the questions you plan to ask. Pick one question and see if you can take any steps towards answering that question yourself. You don’t need to get all the way to an answer – you have help scheduled! – but you’re practicing the skill of independently gathering information.
• Read documentation. Before this stage, reading documentation will probably feel overwhelming and you will retain very little. But once you have structured your knowledge (built that bookshelf), you’ll be better able to slot what you read into your existing understanding.

3 to 4

3	understand most components of the system and how they fit together; know where/how to find more details independently; can independently make or review small changes within a component
4	could clearly explain most components and how they fit together; can review and approve major or cross-component changes confidently

Before you embark on a journey from a 3 to a 4, it’s worth asking why. Are you taking on a leadership role in this area and need to be able to teach others? Are there major changes coming up in the system that you will need to help design and review? Do you get more satisfaction out of working with a system you understand deeply?

• Chase down bugs. Bug-hunting often requires a deeper knowledge of the system than new features. You may need to cross multiple components in order to find a root cause. You’ll also need to have a sense of what is normal behavior and what is odd; once you start to notice those differences, be sure to ask yourself why.
• Teach others. Try explaining the system to someone at a 2 or 3. After you attempt the explanation, ask for feedback. Did your description make sense? Was it in a sensible order they could follow? What still feels like a mystery?
• Review changes deeply. As you build up your understanding, your reviews will be more and more valuable to your teammates. Get in the weeds on code and design reviews and ask yourself and others about possible alternative paths, future risks, etc.
• Design changes. Try to design changes that impact several components. When you ask for review, tell your peers which parts of your design you are least confident about so they know where to focus and you get more directed feedback.
• Take advanced courses if available. Now that you have a strong foundation, you can pick out courses that get you into the right kinds of weeds. As you take these courses, try to identify areas of active disagreement among experts. You’re working to become an expert yourself –– what do you disagree with?

4 to 5

4	could clearly explain most components and how they fit together; can review and approve major or cross-component changes confidently
5	could structure and teach detailed workshop; can design major changes; understand all pieces of system, how they fit together, and why

This is the hardest part of the ladder for me to comment on. There are relatively few technical areas where I rate myself at a 5 and it’s hard to generalize about this level of expertise. I’ll give a few ideas and would love to hear more.

• Run a workshop and get feedback. If possible, dry-run your workshop a few times to iterate on your structure and content. Someone at a 3 or a 4 could help give you constructive feedback, while someone at a 2 could tell you whether your content was sufficiently approachable.
• Design major changes and reflect on the outcome. Often, the system you’re learning about won’t need major changes that challenge your understanding at this point. However, if you are lucky enough to get to lead some big restructure or overhaul, make sure to set aside time to reflect afterwards. What risks did you need to take, and were you able to mitigate them? What would you have done differently if you went through the whole process again?
• Debate and disagree with other experts. The goal of these conversations is not to convince others of what you believe about the still-controversial parts of the system. Instead, your goal is to walk out with mutual understanding of each others’ perspectives. Why might reasonable people with deep knowledge of the system disagree? What do these disagreements mean for the future of the system?

Wrapping it Up

All of these ladder rungs are written with technical, professional use cases in mind. However, there are plenty that you could take and adapt into other areas of your life where you care about skill and growth. I’d love to hear about people using this in work, yes, but also in their sports teams, video gaming, or artistic endeavors.