Learning-focused engineering

So Brittany, you’re the Director of Platform Engineering at Articulate, but you haven’t always been. Do you want to tell us how you got here?

Yeah, sure. So I started at Articulate about two years ago at this point… But prior to joining Articulate, I was an instructor at a coding bootcamp, Turing School, in Denver. And I did that for about four years. So I spent a lot of time there teaching brand new software engineers how to code, how to build applications, all the ins and outs of debugging, and getting things up and running, so that they could eventually get into software engineering themselves and make a change in their career paths.

So that part of my career was super enlightening, and has actually guided a lot of what my goals at Articulate are in my current role. After I switched from teaching into management over at Articulate, trying to translate and transfer some of these educational strategies that I’ve learned into a company that – we’re a SaaS company, we sell e-learning software and we have a typical range of engineers that work for us, so trying to translate all of these educational strategies that are really classroom-based and formal into our day-to-day work processes, to help level up our engineers is something that I’ve been working really hard towards in my role.

And in platform engineering, we are working with every single engineering team. So I’m working internally with all of our product developers, our QA developers, our infrastructure developers, and I see a lot of the strains that organizations have on creating really good learning opportunities for their engineers, and being able to support engineers just of all levels and all different backgrounds and technical skill sets.

So share some of those insights; you’re at Turing School, you’re teaching people day in and day out, and you’re learning very quickly about that process. What did you find?

[04:18] That we’re really bad at it. So I don’t think anybody recognizes how hard teaching is until you fail at that miserably. And our industry puts senior engineers in a position where we say like, “Okay, mentorship is part of your job description now. This is one of your responsibilities”, but we don’t do anything to teach our senior engineers how to be good instructors, how to be good mentors to other engineers.

So when I first started teaching - I think anyone that first starts teaching, it’s almost like a rite of passage, where your first lesson will go terrible, and everyone just knows it’s going to go terrible if you’ve taught before… I had a lesson that I taught years ago on JavaScript; Intro to JavaScript, like JavaScript 101, for (I think) a startup institute in New York. I thought it went pretty well, and at the end of the lesson, the lecture, I asked for a little bit of feedback, and I remember one of the women in that class was like, “I think this will be really helpful once we’re in it a little bit more, once we have our footing a little bit better.” And I was like, “Okay, that’s good feedback.” Like, “Great. I think it went pretty well.” And then years later, I found my slide deck, and I looked back at it, and by the fourth slide in, I was talking about prototypal inheritance. And that is not an Intro to JavaScript topic. That was the indicator to me. I laughed when I saw it; like, that did not go as well as I thought it did. So our blissful ignorance at how bad we are at teaching is something that’s super-obvious to me that I don’t know if the rest of the industry is as aware of.

Yeah. Well, you forget the things you learned and how challenging they were to learn. And even on-ramping anybody from zero coding ever to coding something, even a Hello World, there’s such a margin in there. So many parts, like the terminal, and just different things we take for granted, because we touch them and live them and eat them and breathe them every single day. It’s just like, “Well, that’s just common… You know, you’re supposed to not breathe underwater. Did you know that?” Do you know what I mean? Like, if you go swimming for the first time as a kid, you’re like, “I should breathe underwater, because I breathe. I’m a human.”

Yeah, exactly. And even if you’re at an organization where you’re not mentoring people who are brand new to software engineering, like maybe you’re bringing on engineers that have a couple of years of experience, mid-level engineers, maybe some more junior engineers, that stuff still applies all the way through different skill levels. As you grow into some more experienced roles, you develop all of these instincts and all of this intuition, and then it becomes very difficult to know how to teach intuition, how to teach instincts to someone. And it’s not a question that we commonly ask ourselves, like “How did I know this? Why did I know to go looking here for this type of information?” unless someone else’s pointing that out to you and forcing you to answer those types of questions.

Yeah. How much does humanity come into play? Like shame, or the fact that like “I just don’t know”? Because there’s a large majority of that’s self-taught to some degree, there’s a large majority that have gone to school, and it’s a big handbag of all those variances. At what level am I, how much skill do I actually have in comparison to my other seniors or juniors? How much does humanity come into play whenever it’s pushing back on that ability to instruct or that ability to teach and lead?

[08:01] Are you trying to bring up a little bit of like the imposter syndrome and empathy aspect of becoming a good instructor, or…?

Kind of. I mean, let’s say I think I’m really good at my job, right? I have this belief I’m really good, and you come to me and you say, “Well, Adam, you could improve in these ways to help lead or instruct those around you in these ways.” I might take shame, because you’ve now attacked my abilities, what I think of very personally, my skill set that I’ve cultivated. So you kind of get into this gray area of like, “Well, I’m not just trying to help you improve.” Well, now it’s like, I take that personally, that I don’t meet the level of whatever it might be, and somehow I’m not enough.

Sure. What I would ask them is have you cultivated that skillset, and has your manager supported you in cultivating that skillset? Have they provided you resources to actually cultivate that mentorship skill set that they’re saying you need to have?

There is a blog post recently by Camille Fournier, who listed out a bunch of essential skills that senior engineers need, and non-exhaustive obviously, but one of them was, “knowing how to mentor other engineers”, but then also being able to take feedback. That’s like, “We need to improve on this skill set”, and be able to act on it. And I think the problem there is that I don’t think many organizations or companies give their senior engineers the support that they need in order to cultivate that skill set. So it isn’t fair to a lot of seniors, I think, to expect them to be really good at this thing that we’re not teaching people how to do.

Yeah. I draw an analogy over to board games, because there’s lots of complicated, fascinating, deep board games now, and everybody has, in their friend group, I think, that one person who’s really good at explaining the game to somebody who’s new. And the rest of us can play the game and understand it intimately, and have strategies, very advanced knowledge, and the person who’s coming to the new board game, it’s not like they’re unfamiliar with the way board games work, right? They have experience, but they do not understand this particular game. And some people are just really good naturally at teaching, and understanding how I’m going to explain this board game, so that you grok it quickly and can start strategizing with us and start playing and having fun. And then the rest of us are actually like – even if we’re really good at the game, if it’s our turn to explain it, it’s like “This is not – I can’t.”

“I don’t know how do it.” Yeah.

“This is hard.” Because teaching is a completely different skill set than doing, right? And so, like you said, Brittany, like, have you cultivated it? Have you been supported it? How many times have you explained this board game to other people? Because it gets easier with time. So there shouldn’t be shame, I don’t think, for any of us who struggle to teach, because teaching is really hard, and some people - there’s like a scale of how you have naturally inclined to do it. And just because we’re good developers or good engineers, it doesn’t mean we’re going to be able to impart that without instruction, without learning and experience.

Yeah. Normally, I hesitate to say that like certain people are naturally good at something and others aren’t. I feel like sometimes that perception is a little bit unclear. But in this particular context, someone who’s naturally good at instruction or explaining a board game or something, I would say that it’s not necessarily just in their nature to be good at that type of communication, or have that skillset. I think those types of people are still very, very in tune with their beginner perspective, which is something that we lose sight of very easily as senior engineers or as we get further in our experience, and get comfortable in our expert roles. And the more time we spend there, the less we stay in touch with what it feels like to be learning something brand new, what it feels like to not have a comprehensive view of the tools and the systems that we’re relying on; you lose a little bit of that empathy and you lose sight of where that starting point is for certain people.

[12:12] So is it safe to say that it’s smart to keep in touch with your beginner mindset, or your beginner place? And that beginner slides, because beginner might be actually beginner at a high-level thing, not a low level; like an entry point. So beginner is not necessarily like brand new, it could be brand new at something very advanced.

Absolutely.

How do you keep in touch with the beginner mindset?

So I think always be pushing yourself to learn something brand new. And I wouldn’t necessarily say always be learning something brand new in tech or in related directly to your job, because you already have some significant level of expertise there that you recognize like on paper, it’s your resume, it’s maybe your job title, it’s your years of tenure at your company and how much historical knowledge you’ve gained. Go try to learn how to knit if you’ve never knit a sweater before. That is something that’s completely outside your comfort zone maybe, and that’s what’s going to really give you a lot of that beginner perspective empathy that you need in order to recognize like, “Wow, this is what it feels like to be a beginner here, in this space.” You’re not going to feel like a total beginner when you’re learning something new in an industry that you’ve been working in for years, because you still have a leg up on how to go about learning that new thing, and where to go do your research, and what bits to pay attention to and what bits to not pay attention to. So you already have a leg up, where you’re not going to get that true beginner mindset if it’s in something that you’ve been working with for a while.

I think another part of keeping in tune with your beginner mindset too is, like I mentioned before, always asking yourself “How and why did I know how to do this?” Which I don’t – I mean, it was never a part of my development process when I was in an IC role to be asking myself those questions when I was just coding along all day… But if someone else asked me that, it was like “Oh, I have no idea. Let me think about that. Let me get back to you on that.” And that’s a lot of the stuff that you need to be consistently asking yourself, because a lot of the things that we think are instinctual are not. There can be teachable rules and patterns to those. I think that comes into play a lot with debugging, in engineering. Like, think about, Jerod or Adam, how do you go about googling an error message? What do you do?

Ooh. This could be a precursor to a future show we do.

Oh yeah.

This is actually a deep subject, how do you google, essentially? We want to do a deep dive, we aspire to do a deep dive on all the multi-facets you can do to google a problem set.

Yes. I’ll tell you, having been experienced in specific errors, that the first thing you do is copy and paste the exact text –

Precisely.

…into Google to see if somebody has actually put the text into a blog post and you find an exact match. That’s a great way to start.

Yeah.

From there, you’ve got other things… But for sure, if you can get the exact error – now, you may have to scrub like the unique parts out and just normalize it, and get rid of the parts that are unique to you and keep the parts that are general. Otherwise, you’re not going to get a hit.

How do you know what parts are unique to you? Give me an example of a part that would be unique to you in an error message.

A timestamp, or if it’s like a web request, specific parameters that are put into the thing or, stuff like that.

The first line of your terminal; not usually somebody else’s, I mean –

Your prompt… My prompt says Jerod in it.

Yeah, exactly. Jerod@macbook, whatever, you know…

Right.

Yeah. And then what do you do if you scrub all that information out, you have an error message, you copy and paste it, and you don’t really get a ton of results, or you get some results that might be related, but kind of vague…

[16:04] Right. Then I will often generalize the search query even more. And instead of putting like an entire message in, I’ll find like what kind of error it is, and I’ll put that in, along with my circumstance, like Alexa 1.12 or something, and then this particular error.

Oh yeah.

You know, so you’re just kind of tweaking it. You’re just trying to give Google exactly what it needs to find that.

Yeah. And that’s something that our engineers, some of our new engineers when I was still in my instructional role - they did exactly that first step, just copy and paste the error message and throw it into Google, but didn’t know to take out the file names or parameters or function names that were specific to them, or didn’t know to add keywords about what library they’re using, or what framework they were using.

So teaching those types of things is super insightful, but most people’s first step in teaching that, and where a lot of people stop short, which you didn’t, is just copy and paste the error message into Google. Like, go google it, and that’s about it. But there’s a lot more teachable things in that.

Right. Yeah, it’s kind of the individual steps. I’m thinking about TDD a lot, because you know, in test-driven development you want that first test to fail. And as a person who practices it over time, it’s so silly making it fail first, right? It’s red/green refactor, and a lot of times we know what the green looks like, because we’ve just done it a hundred times. And it’s like, “Am I really going to make this test fail again, for the thousandth time?” Similar, like “Am I going to put everything right into Google, or am I going to generalize it, because I know it’s not going to match perfectly?”

So the intuitive part is actually just iterations of experience where I’ve realized I can skip the red part – sorry, TDD purists, but a lot of times I’ll just skip the red, and I’ll go straight to the green. And everything’s fine. You know, the world doesn’t end, the program continues to run… And other times I’ll do the red, because I think I need it. And those are the things I think are intuitive, but they’re actually just iteration and experience. But when I go to teach that, it’s like, “This is the way I do it.” It’s hard to actually go back to those individual steps, like you’re mentioning, and teach it that way.

Yeah. And it might seem silly to teach it that way when it’s something that – you know, 99% of the time it’s going to be fine if I just skip to the green part and head that way… But I think one thing that you’re touching on with this is the efficiency of being able to teach that type of stuff and get someone from the point of always wanting to rely on that red, to feeling comfortable and confident with just relying on starting with that green step. So just teach the basics and the foundations of kind of where you started, but as long as that’s exposed to them and they understand the why and the how, the earlier they get that type of instruction, the faster they’re going to be able to skip through however many layers of iteration you had to do to get to that point.

You might’ve had to iterate and get 100 times of experience going through that process, and maybe they only need to do it 20 times before they get to that same level, because they have that insight, and you’ve explained that intuition and instinct to them that they needed.

It seems like a lot of responsibility on a senior engineer… Not only do you have to be able to do all the things that your job entails, what would be listed on your job, but then also, you have to become a really good teacher and mentor, and help sponsor people… And these are all things that we agree we should be doing, but - holy cow, isn’t this like a lot of responsibility on seniors, to say it’s not good enough to achieve it, what’s written on your job priorities, but also you’ve got to learn how to do this better…?

Absolutely. I think this is why it does seem to fall to the wayside at a lot of organizations where mentorship kind of takes a back seat to the other high-priority, like, either feature work, or bug fixes, or on-call rotations - everything else that senior engineers have on their plate; mentorship is pretty much always listed as a responsibility, but then very much deprioritized. And I understand why, because those bandwidth concerns are universal; everyone’s got bandwidth concerns. It’s really hard to do that.

[20:18] But the more efficient we get at our instruction and our mentorship, the less of a burden it is on senior engineers, and the more senior engineers you develop, you create, you make that talent with the efforts that you put into your instruction and your intentional mentorship.

Is the struggle organizational support of this mentality? This mentality of instructing and cultivating and teaching; not just product feature, go, go, go. Because you have to continuously learn. Software by nature has extreme entropy; it’s changing every single day. This very moment, a brand new – a thousand repos were just created in this moment. You know what I mean? There’s something new that just happened just now that we’re not going to catch up to until months, weeks, years from now, potentially. It just moves so fast.

How do organizations take this and run with it? Is it a commonality for organizations to embrace this idea for internal education, internal mentorship and sponsorship and supporting it? Because this, to me, takes the margin in an organization to enable that outside of feature set, outside of product.

Yeah. So I think organizations kind of have a lot of different types of goals in this space. There’s organizations that might be really ambitious about stuff like this, where they want education first. That’s one of their core values. They are trying to prioritize always leveling up their engineers. Maybe they have goals around being an organization that’s known for creating really amazing engineering talent, more so than just attracting it, simply attracting it… And really supporting a lot of people’s professional development goals and educational growth in this space. I think that’s the most ambitious end of the spectrum for organizations, and I don’t think many organizations are there. Articulate is an education-based company, so we try to kind of live and breathe it in and out, and we’re still not even there. That’s something that we’re going to be still working towards for sure, for years to come, I’m sure. But those really ambitious goals would kind of put organizations in line with what you might think of with teaching hospitals, where those hospitals are known for still doing surgeries, procedures, providing medical care, but at the same time, they have education ingrained into their everyday processes, everyday policies. That is just how their business model is built from the ground up.

There are other organizations that might have way simpler goals, smaller goals that are simply just “Maybe we want to ramp up our engineers faster. Maybe we want to be able to hire engineers that maybe don’t have every single checkbox of technical skills that we’re looking for, but we know we can trust that we’re going to level them up just fine on the job”, and maybe they just want to make it easier for engineers to get the answers to their questions and promote good cross-team collaboration.

But even those really tiny goals can seem insurmountable for organizations because of how inefficient we are with our instruction and our mentorship right now, because we don’t provide any sort of formal training on those types of things. I think a lot of organizations right now lean on providing stipends, like professional development budgets, education budgets, maybe 20% time to go learn something new or hack on a side project… I think those are great, organizations should continue to support these types of growth efforts in those ways, but that’s like the easiest thing to do, is “Here’s some money, here’s some time. Use it as you please.” But formal training in this space is something that would make a lot of those tiny goals a lot more feasible to achieve, a lot more achievable for folks.

Break: [24:26]

So we’re at a place right now then - we’re having to teach people how to teach, essentially. If you say that’s the place that lacks, is “How do you– “ Sure, I wanna teach. Sure, I believe in education. I don’t want to just give you a thousand dollars stipend or whatever the number is to do courses or whatever. I want to enable that, to do free rein “Go learn something new.” So maybe that’s in addition to, but how do I teach you how to – how do I know how to teach, if that’s the trouble? That seems to be the core issue. How do we do that?

Yeah, we don’t have a lot of experts in this space right now, which is the main blocker. My number one recommendation for organizations would be go seek out engineers who have taught before, have taught at coding bootcamps or do open source education efforts and training courses, and embed them into your organization, embed them into your engineering teams to start learning how they teach, and what works well and what doesn’t, in courses that they’ve done and lessons or materials that they’ve provided online.

There’s a lot of education-based strategies, classroom-based strategies that you might learn if you had gone to college to be an educator, to be a public school teacher or any other sort of professor, that are pretty unknown to people in the engineering field, because we’ve never had to learn those types of things.

[28:13] So I think the first step for organizations is a) just being able to identify and leverage any potential learning opportunity that you can create for folks. And those happen at the organization level, they happen at the team level, and they can happen in these more one-on-one intimate levels as well.

Organizationally, I think – at Articulate, we’ve done a couple of things. We’ve recently partnered with jeli.io. They do incident analysis work. I’m not sure if either of you have worked with them or heard of them in the past… Super-talented people over there, and they helped us facilitate a lot of incident review calls, which are open to all of engineering for anyone to attend. And those types of opportunities are really great for creating a lot of consistency and predictability in a learning environment where you’re going to review an incident – and not only what happened and how did we fix it, but how did the people who were involved know what to do? Let’s suss out their instincts and how they got this to resolution. What can we learn from this? What can we learn that was interesting about the systems that were involved and the tools that were involved? And those types of opportunities don’t require a ton of in-depth –

Preparation.

Yeah, preparation from certain folks, but they allow for a really wide audience and are very focused on like exposure, which is sometimes half the battle. Exposure is 50% of the battle in terms of knowing where to get your answers to your question, knowing that something exists, knowing where to go find something, even if you don’t actually know the answer to your question. Those types of learning opportunities - minimal effort, super-wide audience, and really focused on creating a lot of links, mental links, for people across the organization.

I think other organizations probably do lots of things, like lunch-and-learns… We also do depth discussions, which are hour-long technical topics that someone wants to present. Things like that are very consistent learning opportunities that you can be creating at the org level.

And then at the team level - this is where a lot of these classroom-based and educational strategies come into play, I think. Things that we’ve done on our team, that – some have worked some, I think, haven’t worked, are things like backwards planning; that happens a lot in classroom-based education, where you start with that end goal or big picture of what are we trying to accomplish here, and then slowly spec out details in more specific detail from there.

And what we’ll do to emphasize that on our team is actually create, like some of our tickets are our cards with that type of information spec-ed out up top before we get into the nitty-gritty of what actually needs to be done. So anything that lends itself to a good learning opportunity, we want to make sure that we’re working from the end goal into where the nuts and bolts are that this person’s going to have to go dig into to get to that final space of resolution.

Other areas that we’ve done on our team - scaffolding is another really common classroom-based strategy, where you’re providing a lot of meat and bones and rails and bumpers for someone, and then having them fill in the gaps by really isolating their learning opportunity there. So in engineering, this might look like creating a pull request, a draft pull request that has a ton of the prep work already done and flushed out, and telling another engineer, “Okay, you take this on from here. Don’t worry about all the stuff that I’ve already put in place, but fill in these tiny gaps… And here’s the learning opportunity for you, so that you can really focus just on that very narrow aspect of that learning opportunity instead of having to get overwhelmed by every other thing that needs to fall into place.” If that’s not what you want that person to focus on, do it for them and then hand it off when you have that focus really clearly defined for them.

[32:34] There’s a few terms that come to mind - yak shaving, reverse engineering… I think these all kind of play into some of that work backwards aspect. There’s even a really well-known book out there now called Working Backwards, about a lot of Amazon’s practices, and how they accomplished Prime and AWS, and other things… And I read the Prime chapter, it’s phenomenal, if you want to read that chapter alone, how they came to Prime. They essentially did similar pull request driven development or teaching. In this case, it was press release. Like what did we release into the world? What product was it and how did we get there essentially? That’s an interesting way to get there, because it’s like, that’s common, to say “Reverse engineer how this came to be, reverse engineer how this would come into play, and fill in the gaps.” Because you need those constraints and the possibility, but you kind of have to rewind to see what you’ve got do to get there.

So they wrote the press release first. Is that what I’m hearing?

Yeah, I’m paraphrasing some of it. I’m not giving you the – it’s like a very compressed TLDR. It’s press release, like “What do we want to actually have in the world?” There’s a lot more in it, but they have a practice of, “What does the press release for the announcement of Prime?” for example. Okay, so that’s the press release; that lets us know what we want to deliver. How do we do that? Because they had a very specific customer obsession.

It’s kind of like Readme Driven Development where you write the readme first.

Right. Exactly. Write the readme first, write the PR first, in this case, that Brittany had mentioned… It’s an interesting thing to say, what do we want in the world? And then how do you get there?

And to pass off an opportunity like that to a new engineer or maybe a new hire that you want to create that learning opportunity out of - I think you can provide them with that end goal, and that’s what they’re going to really be working towards. But as they get into the nuts and bolts, it’s so important to be having consistent checkpoints with them, because in light of any type of new information they come across along the way, they might not know if something is relevant or irrelevant. They might not know they shouldn’t bother going down this rabbit hole that they’re about to go down, or they might work really hard to get to that end goal, and when you see the work that gets delivered at the end realize, “Oh, this was way harder than any of us thought it was supposed to be. We’re so sorry. We didn’t intend for you to have to do all of this. We thought it would have been a two-line code change.” And then all of a sudden you realize, “Oh, actually it was a 20,000 line code change for this person”, but they didn’t know that. Yep, at this point, this is the delineation of like, “This would not be worth it anymore. This end goal should change now”, in light of these new hurdles that you’ve come across.

So you have to make these checkpoints in a sense, where the instructor is going to do that or the leader’s going to do that with the mentee in this case, potentially, if that’s the terminology; they’re going to have certain checkpoints to basically do that?

Yeah, and that can look different for everybody. It could be async checkpoints, just, “Hey, how’s it going?” Or it could be something way more formal, where you’re doing pairing sessions and looking through the work as it goes along. But keeping in mind your beginner perspective, it can be really hard to ask for questions or to know whether or not something is still worth it or if this is still the end goal that I should be striving for, or am I allowed to switch gears? Should I switch gears and tackle something different instead?

[35:56] I think that’s happened to all of us too, where like, maybe it’s our Friday afternoon and we pick up a ticket that looks pretty easy and simple, and then it turns into a beast, and we’re like, “Man, didn’t want to spend my Friday afternoon doing this.” And now it’s going to be a week, and maybe we’ll just drop it and put it at the bottom of the backlog again and pretend we didn’t pick it up to the first place, but –

Or dread the weekend and come back to it on Monday.

Yeah, exactly.

Or get stuck on it and you can’t even sleep because you’re solving the problem in your brain over the weekend. You’re like, “I’m trying to disconnect…”

Yeah.

That’d be me. I’d be like working all weekend because I couldn’t let it go.

I love this incident analysis idea as a teaching mechanism, and just institutionalizing knowledge… Because so many times like how you go about solving that particular problem is the domain of a senior’s expertise. It does only live in their brain. I have a good friend who works at a Fortune 500 that does credit card transactions; they are still on mainframes, and these things are incredibly esoteric, and there’s a few people that work at that company that’s like, “If Fred dies, we are in serious trouble.” Fred’s not the actual name; the names have been changed to protect the innocent.

But you know, his knowledge is not institutionalized. That is bus factor in a huge organization. You have like a bus factor of three with thousands of employees. And here you have with these incidents, this analysis in this teaching through the incident, institutionalizing that knowledge, making it mineable, making it searchable, making it go backable, and be like, even for Fred, “How did I do this the last time? Because I can save myself two hours trying to remember how I did it the last time if I just read this.” That’s really cool.

That’s what a lot of our review calls have started to suss out, is what are these instincts that people are unaware that they have, that we want to be able to teach to others?

There was a talk by Katrina Owens on – I think it was called Cultivating Instinct, and she talks all about how novices will have an extreme amount of information that they need to process, and it’s very hard to know what to pay attention to and what not to pay attention to. And experts simply know; they recognize the patterns, they recognize what they need to pay attention to and what’s relevant.

And when we get into that expert phase, we transition from like, “Oh, this was my step-by-step process” to “Oh, well, how did you not see this? How did you not know this? Because it seemed so obvious to me.” We don’t recognize why things are obvious, and we’re really not very good at training or instructing those more autopilot parts of our brain and our thinking. So you really have to be asking people consistently, how and why did you know how to do these things, and where did you find this information to lean on, and who did you know to reach out to? Why did you know to reach out to that person?

Have y’all ever seen that experiment? …there’s was a video years ago about like a gorilla that was like walking through a basketball court where people were passing a basketball back and forth to each other.

No.

Okay. So it was all about selective attention. And there’s – you both will see it, now that I’ve told you about it, so it won’t work on you if you’ve got to look it up… But you’re on a basketball court and there’s a bunch of people passing a basketball. And the prompt at the beginning of the video is like, “Count how many passes are made on this basketball court.” And people are so focused on counting the passes that they don’t realize that a man in a gorilla suit walks through the court halfway through the video. Then you watch it again after someone tells you, and it’s like, “How did I not notice that?” And that’s very similar to that transition of being a novice versus being an expert; an expert has that laser focus of what they need to pay attention to already, so they’re not going to be bothered by that gorilla. It’s not going to distract them at all. But a novice is going to probably see that gorilla and be like, “Maybe we need to stop the game. Like, there’s a gorilla here!” It’s like, “Should we be panicking? How come no one else is panicking?” You know, it’s just a very different perception of what people are paying attention to at different levels.

[40:14] Now that you’ve mentioned that, I do recall seeing that.

I did, too. It seems like there’s so many winds of just teaming an experienced expert with a novice, and just having that be a team at all times. Because the novice, just like you said, the perspective is there, but also just the questioning of the why, the things that you don’t even know why anymore, like “Ah, I don’t really even know why I do it this way.”

You start to question yourself, and that can improve yourself as an expert as well… Because some of the things we do are just habitual, they aren’t the best way, and we just don’t – they get the job done, but that doesn’t mean that you couldn’t improve that process… So you’ll see those things through new eyes that you don’t see yourself.

Absolutely.

Yeah. The novice tends to question almost everything, because they need to question it, because they’re trying to hone down why they do what they do, why they do it, when they do it. And the expert is like, “I just know, because it’s been a thousand times, and I haven’t questioned again why that habit’s a habit… But it is, and it pays off every single time, because I get the job done every single day” etc.

Yeah.

But the novice is going to question. That’s a good idea, to pair those two together, because you always have that both sides of the better coin.

They both benefit.

Yeah. I always would tell my students or any new engineering hires, like, the most valuable thing you bring to the table in that first week or that first job is going to be your questions. Like, your time to impact where you’re delivering a big feature or fixing a major bug or whatever - that might be a little bit slow to start at any new job, and that’s fine. In the meantime, ask all those questions that you can, because people who have been here for a while, forget to ask, or they don’t know.

I remember starting one engineering job I had years ago, and the first project that I got put on, the guy behind me, Albert - he just stood up behind my cubicle and was like, “Hey, if you see anything weird in this codebase, it probably is weird.” And I was like, “Okay.” He’s like, “Let me know.” And I was like, that was so nice, and it helped me so much, because you don’t know if it’s supposed to be weird, or it’s intentionally weird, or it’s weird because of some reason that isn’t relevant anymore, or if it’s weird because you don’t know what you’re doing and you don’t have the skills for the job. There’s so many reasons why something would be unfamiliar to you. And for someone to explicitly say, “Hey, if you see something weird, tell me, because it probably is weird” is very reassuring. That’s a really good way for people to build trust in these mentee-mentor relationships as well.

It’s funny, we’ve just had that conversation on Ship It, which is our show all about putting the code into the world with Gerhard Lazu, and we turn the lens on ourselves every 10th episode. Adam and I join the show, and we talk about the development of changelog.com and our podcasting platform and stuff.

And Gerhard does a lot of the infrastructure config, our CDN configs… And I hop in there and try to help out, but he’s the expert in that domain and I’m very much the neophyte. And I was trying to fix some problems the other day, and I’m just assuming he must have known what he was doing when he did this. It looked wrong, but I just didn’t feel like I had the expertise to say, “Actually, this is incorrect.” Because I just figured it’s Gerhard, he knows – he did it. He had a good reason. And when I talk to him about it, he was very flattered that I would think that. He’s like, “No, I just totally screwed up. I had no idea what I was doing”, you know, in that particular context. But I gave him the benefit of the doubt, because I was the novice and he was the expert. And if I had had that permission, if he had said, “I got the Fastly thing working, but I have no idea how I did it”, then I would have had more critical eyes. So it’s interesting, that communication can change the way you approach problems.

[43:58] Yeah. I absolutely love when our more senior engineers can be really vulnerable with other engineers and kind of demonstrate and show off the mistakes that they’ve made, or the things that they didn’t understand. I think that’s a really good dynamic to create, especially when you’re in these one-on-one scenarios. There’s so many learning opportunities one-on-one, with like pairing sessions, and PR reviews, stuff like that. But there’s always going to be a bit of a power dynamic there, which can hamper some of these feelings of safety that someone might have. Someone’s more tenured, someone’s more senior, someone’s more experienced than someone else. And being able to create and maintain that level of safety and vulnerability within that relationship is going to be super important for learning from each other, and trusting each other with what it is that you’re teaching and what is that you’re learning.

I think inviting people to ask you questions is super, super important. Not just like, “Here’s all the information that I have in my head, go ahead and get started with this and see where you get.” That’s okay, but like, “See where you get, and then come to me as soon as you have a question. Come to me when you have questions at the end of the day” or “Let’s schedule something for two days from now to go over any questions that you have.” Assuming that they will have questions, letting them know it’s expected that they will have questions, and inviting them to come to you with those is super important for fostering that healthy type of relationship.

So Brittany, you rattled off quite a few different strategies or techniques - backward thinking, scaffolding, incident analysis, different ways you can do these things as an organization. Is there a playbook somewhere where it’s like, “Okay, we want to do this well inside of our team or inside of org”? Can I just go find the playbook somewhere and say, “Here’s six techniques for leveling up your engineers on the go” or something snappy like that?

Yeah, we don’t have any formal playbooks on it yet, but it’ll be something that we develop over time, and hopefully can create resources for people around.

Okay. So with any playbook, a lot of the value is what’s not in the playbook, because you can waste a lot of time spinning your tires and trying things that aren’t effective… And a playbook is like, “Here’s six things that work, and we left out the 45 things that don’t work.” Surely, you’ve come across both in your years doing this, things that are effective ways of teaching and things that aren’t very effective. Can you help us avoid common pitfalls?

Yeah. So there have been a lot of things that we’ve tried to translate over in practice that I kind of don’t want to give up on yet, but I just think I have to… One of those is like spiraling concepts. This is something that is super common in classroom-based education, where you are really revisiting concepts over some interval. And in between those intervals, you’re working on different stuff or you’re learning different stuff, and then you revisit something that you learned maybe six weeks ago, and you start building on top of that.

[48:03] That works really well in the classroom or maybe in other industries, but in engineering, I think it falls short, because people get so overwhelmed with context switching; and you put them on one project or one learning opportunity where they’re going to learn X, Y, and Z, but then they move off of that for maybe a couple months, depending on the workload of your dev team. And then when they come back to that, there’s a lot of time spent having to refamiliarize yourself with what you worked on a month ago. And it’s so quick and easy for those types of things to fall out of our heads, because we do spend so much time focusing so strongly on our current task at hand, that if we don’t need information that we needed two weeks ago, we’re going to prune that out of our minds. In some educational research, they’ll call that cognitive offloading. Whatever you don’t need to remember, that goes away, especially when you have other focuses that you need to be paying attention to at any given time.

So I’ve tried spiraling a little bit, and it’s been met with resistance… And just not necessarily the best results, but not the worst results either, where people actively say, like, “I’m going to forget all of this if you move me off of it now and put me on different dev work, and then I don’t come back to it for a long time.” And I’m like, “Okay, let me clarify then what would I hope that you do remember about this experience six weeks, two months from now.” And it might only be the tiniest thing.

We have like a Ruby on Rails application that my team works on, and I remember talking with one of our engineers, I was like, “Okay, if you don’t work on this again for two months and then you come back to it, all I would hope that you remember from your previous experience is that the Rails console is your friend, and you have that great debugging tool to work with, and you can go Google how to like write these different queries to get information from the database. Knowing that you had that exposure and you can find that information - that’s great. That’s all you need to remember.”

And usually, that is a small enough detail that it does stick, as long as you’re explicit about it and as long as it’s not too much. And then it makes them feel okay about not remembering everything that they worked on two months ago. They’re like, “Okay, if this is just my goal to remember this, even if I have to refamiliarize myself with other information about what I worked on, I have some sort of backbone to lean on, some sort of memory that I can rely on to move a little bit faster this time.”

And I think for managers, it’s all about making that okay, and letting people know, “I expect that you will need to spend some extra time ramping back up on this, because it has been a long time since you’ve touched it”, and not expecting them to be able to dive right back in the second time they look at a particular tool or system.

It’s about repetition, right?

Mm-hm.

Repeating, learning the same thing kind of over and over, one additional layer at a time, or kind of a little further into it… Right?

Mm-hm.

That’s how I learned, is repetition, personally, so I can empathize with that process. Because if I hit the same thing or – if I’m reading a book, for example, if they kind of recap… I like recaps in learning, it helps me. So that’s similar to that nature, then… It’s kind of recapping; you can come to the problem again, or you start a new chapter, “Hey, by the way, in the last chapter we read this part, and here’s how it kind of goes into this part here.” That’s similar, and that style of teaching works for me.

[51:44] Yeah. And I think how painful things are for you is also like a huge motivator for engineers, where “This problem I keep running into drives me bananas, and I can’t stand it. I’m going to commit the solution to this, to memory so that I never have to run into it again”, and that becomes a big motivator for future learning and future reference that people can be relying on.

But one thing about how painful it is to learn or to run into problems - I think a lot of newer engineers won’t know if the pain that they’re feeling is worthwhile, or going to be valuable for them or not. We had a phrase when I was teaching at Turing School, and bullet points, around effective struggle strategies. Like, how do you know when you’re struggling in a way that is effective and worthwhile, and worth your time, versus spinning your wheels and going down a rabbit hole that you don’t want to go down? And that’s something that is also a little bit difficult to teach, but there are strategies around it. Teaching someone – having those close connections with someone who’s working on something brand new and those checkpoints is super important for helping them time box… Like, “Hey, I ran into this side bug that I don’t know if I should pay attention to or not. Can you confirm for me if I should pay attention to this?” And this other engineer that they’re pairing with can be like, “Spend one hour trying to debug that” or “Completely ignore that” or “Come back to me after a day of looking into that”, because the person who knows those tools and systems will know if it’s worthwhile to struggle on something, and someone who doesn’t have that full picture of the system will have no idea if that’s important or not, or if that’s worth their time or not. So being really effective with your struggle is super important.

That was one of the things that I did often. So I did teach web development for a couple of years in classrooms, and as an instructor, I would be able to pick and choose if I was going to remove a roadblock for somebody and get them along their way, or if I was just going to let them sit in that one. And it’s like, “No, you’re going to figure that one out on your own”, because I knew that was an effective – what do you call it? Effective struggling?

Mm-hm.

At that point, it was like, “This is actually making you stronger, if you get through this.” Other times, it’s like, “You just can’t figure out this database connection string, like this is not knowledge that you need to have. This is just ridiculous. Let me just fix it for you real quick, and you can move along your merry way.”

Exactly.

Yeah.

For senior engineers that are in these mentorship roles, there are definitely signs of effective struggle and ineffective struggle. Sometimes for the engineer, this might come out in emotions; they might be getting really frustrated or really short with some of their questions, or how they’re feeling about the particular work that they’re on at that time… Sometimes, it’s a little bit more tangible than that, where when they’re saying they’re stuck, maybe they don’t have the right words to express what their question actually is, or what they’ve already tried at this point, and what didn’t work or what did work, and where their problem actually lies.

One thing that we would see a lot with people who are struggling and spinning their wheels was like - especially for new engineers - tons of commented-out code. It was like they wanted to hold on to all of these things that they tried. And it’s like, “I can tell you tried ten things and you’re afraid to get rid of them because you don’t know if they worked or not.” And if you’re at that point, that’s not effective struggle anymore. You should always be able to clearly articulate, like, “What is my question? What is not working about my solution? Why did I think my solution would work? And what did I try and why didn’t that work?” Always have that clear timeline of your struggle, and as soon as it starts to get difficult to explain that to someone else, that’s how you know you’re getting into these ineffective struggle scenarios where you’re probably spinning your wheels.

The weeds.

Yeah, you’re in the weeds.

[55:54] So before my professional days, I was a server at a restaurant, and we would call that “in the weeds” essentially - when you have too many tables and you can’t keep up and you just cannot focus, we call that “in the weeds.” And that’s where I learned that terminology. It applies to many of the places, not just there, of course, but I learned what it meant to be in the weeds, because I’m like – I see my other people that were with me and I’m like, “They’re not struggling. I’m totally lost here. I don’t know what I’m supposed to do right now. My table’s going to have drinks. I can’t get an order in. The food’s not there. Everyone’s upset and I’m getting no tips tonight.” That’s deeply in the weeds, and you just can’t get your focus back.

Yeah.

Step away to get unstuck.

Yeah. And it’s also okay to be in a position where you don’t even know what question to ask, because you’re so stuck and you’ve tried nothing, or you don’t understand the problem space. That’s another area of coaching that a lot of senior engineers have to run into, is helping them rephrase what the problem space is, or present it in a different way for their engineers so that they can start to come up with those questions… Because it’s very possible to be so lost that you’re either not sure where to even start, or not sure what to ask. You’re not even sure what you’re not sure about, what you’re confused about.

So this is another aspect of like, you really need to build a close relationship and understanding of the background of the person that you’re working with and the person that you’re mentoring, to see what kind of pre-existing knowledge they do have, what is their foundation, where is their area of expertise, so that you can start building these connections and mental models for them.

We had a newer engineer join our team who had worked a lot with Git, and this was their first infrastructure position. So connecting Git for version control to Terraform was a really good link for them to be like, “Okay, version control for your infrastructure versus version control for your code.” There’s a lot of similarities there, and that helps them build these mental models on their own, and use what they already know to transfer it over to what they’re currently doing. But without having that experience - it is probably a pretty obvious one that you can build off for any type of engineer. But if you don’t know what their previous knowledge and foundation is, you can’t help them build those mental models. So you’ve really got to do a lot of research and have a lot of conversations with your mentee about what is your bread and butter, and what things make sense to you and what things don’t. “Tell me about times that you’ve struggled. Tell me about times that things came really easy to you”, and build that relationship.

Those kinds of exchanges though - it does require some vulnerability. Because that person that’s the mentee is going to have to potentially share, like, “You know what? I – ” They’ve got to show the side of them that doesn’t know, and that’s challenging.

Yeah.

Absolutely. And I think that comes with the safety aspect of that, comes with, as a senior, demonstrating, “Here are the things that I don’t know anything about. These are the things that I struggle with. And these are the things that I get really confused by, and I always have to lean on this person to help me out with this, because they’re my expert over here.” And showing that no matter where you are at in your career, you’re always going to have those areas that you do and don’t understand, and you’re never going to have a completely full picture of everything. So… Demonstrating.

Essentially, that provides some safety, right? Because in vulnerability, you’re like, “Can I be safe to share what I don’t know?” And that’s a version of saying, “Hey, it’s safe. Because I’m vulnerable in these ways. I don’t know everything here in these ways. So you can reciprocate and be vulnerable, too.”

Absolutely.

[59:44] At Articulate, do you have an explicit budget for education? Do you have that at your disposal? Because I’m looking at some of these things like lunch-and-learns, and bringing in outside teachers, and a lot of these things actually require capital expenditure, right?

Yeah. So we don’t have like a dedicated internal team on education right now focused on those efforts. But we have the personal professional development budgets for all of our engineers, and anyone in the org really, for a benefit to go expand their learning and their education. We’ve done hackathons and some free time for autonomous work that you can kind of focus on things that you want to level up in a little bit.

So we do a lot of the standard things right now that I think a lot of orgs do in terms of benefits that way, and then these education efforts are all just getting rolling, because we’ve been a pretty small company so far - I think about 250 employees - and we’re starting to grow, and absolutely feeling a lot of those pain points of becoming a way larger organization already… And that’s how we’re starting to recognize the need for all of these processes and touchpoints, learning opportunities, leveraging all of these types of things that we can use to really level up our engineers and make it easy for them to do their jobs and learn our systems, learn our tools.

I’m just thinking about somebody who wants to instill these values and then execute on these values inside of their orgs, what are the kinds of things that they would need. That’s why I asked about a playbook. It seems like you need some sort of budget or the ability to spend some money, especially some time, right? Because a lot of this is slow-down-to-go-faster kinds of things, the way you’re working with some of your new hires and having them – I mean, even the scaffolding idea… It’s like, it’s probably just faster in a short-term sense to just let the senior do the thing, right? Versus like scaffolding now and handing it off to somebody else. So these things, I think, require buy-in at, maybe not the highest levels, but high up levels, including time and budget constraints.

Yeah, absolutely. So I definitely think budget is a concern, and knowing to prioritize that upfront time cost for future gains and efficiency later is super-important. And I think as managers and directors at Articulate, we have the autonomy to do that, and it is absolutely up to our discretion. If we think handing this work off to this person to help them level up here and learn this particular piece of our tech stack is going to be really beneficial down the road, nobody’s going to stop you from doing that.

So I think it’s really important to have that buy-in from up above and that trust from up above to make those calls and make those decisions, because you don’t have to have a dedicated team or person that is solely focused on implementing these educational efforts all across the org on every team in one-on-ones. You can integrate all of that stuff directly into the organization from a manager role, from a mentorship role, from a director role. That’s very possible to work that into all of the day-to-day, as long as you have the autonomy and the trust to do so.

So you don’t have the actual education team; it’s sort of baked in. What is that called, and if you don’t have that - so speaking to listeners that don’t have this and want to instill it, what would you call it if it doesn’t have a name yet? And how do you pitch that as an idea? How do you forecast the possibility of instilling these kinds of things, baking these kinds of things into your org levels and managers?

Great question. I think you really want to define that as a core value and core priority, either for a relationship, when you define the relationship between a senior engineer and someone who they’re going to be mentoring… They can define that as a core value in their relationship. They can say, “Okay, we’re always going to prioritize your growth and education and learning, and this is how we’re going to do it.” We define the relationship there.

As a manager or a director of a small team, you might be saying, “Okay, within our team, this is how we operate. We put these types of processes in place, because we’re going to prioritize these types of learning efforts”, and you work that into the policies for your particular team.

[01:04:11.16] This works really well at Articulate, because we do have that autonomy to run our teams, and that trust to run our teams the way that we see fit; maybe at other organizations they’re a bit more strict with that type of stuff, but at the team level you can define that as a core value. And then at the org level maybe it’s not defined as a core value yet, but I would say that is something that organizations that want to achieve this should put in place as one of their core values, if that’s going to be something that they want to be focusing on and are bought into dedicating that upfront time and effort to focusing on it.

Yeah, I like that. It’s incremental. You start at the smaller area where you can see the surface area and control it better, and then you see this success, and you use that success to layer it up. It’s iteration. It’s iterative, essentially. Iterative education, I don’t know what to call it, but you know… It’s like, how do you take it out there? It’s like, you iterate that, because you want to put it in the –

I think - ongoing, right? Ongoing education.

Yeah.

Is that what they call it?

Yeah. Why I say iterative is because you started in the smaller two-person sense or small team sense, you were able to put some sort of framework and it made sense for your coding style, team, or operational, organizational, whatever it might be, and then you said, “Hey, everybody else, this is how we’re doing it here. It would make sense if we upgraded our engineering departments in these ways by adopting what this team did very well. What can we take there and extrapolate it across these teams? And what would the benefits be if we solved that?” And then that’s how you get buy-in from the higher-ups who are disconnected from that. Not that they don’t care, they just literally are disconnected from different – just delegation of natural organizational properties. So I think if you start small, you’re able to prove how it works, show success there, and maybe even iterate a few times to get it better or right, and then present your case to the wider org.

Yeah. And once you have that proof, it’s so contagious, especially at these smaller organizations… Stealing ideas from each other is our favorite thing to do at Articulate. We’re always creeping on each other’s meetings and popping into different team meetings, and we’re like, “Ooh, I like this idea. I see how they’re doing this. Let’s do this, too.” And it’s just kind of unspoken. You’ll see things that are working elsewhere and you’ll just start bringing that into –

We do it here, too.

Yeah. Into your team.

In different ways. I steal Jerod’s words. He steals my words.

For sure.

Yeah.

What does the proof look like? Is it happy engineers? Is it you end up moving faster eventually? What does that quantify? It seems like it’s hard to quantify.

Yeah, I think it’s both of those things. I focus a lot on efficiency, and really seamless resolutions to issues. So on our team, in particular, our platform team, we’re supporting lots of engineering teams internally, and we have a lot of really good data points that we can work off of. So we’ll get a lot of questions from a bunch of engineering teams about how certain things work, or something about our infrastructure or platform, and we can literally see the number of requests that come into our team, and the types of requests that come into our team, and we’re like, “Okay, let’s figure out how to do better education for product engineers around this topic”, because this is something that keeps coming back to us as like a point of confusion or a pain point for our engineers. And after we implement either – this is either more documentation, this is lunch-and-learn discussion, like whatever the format is that we choose to try to tackle it… Maybe it’s improving the system; maybe there’s bugs in the system that need to be improved. All of those types of strategies we implement that, and then we have data to look back on to say, “No one has reached out to us about this problem since we did X, Y, and Z.” And we see that enablement that we’re able to provide for our product engineers using actual, hard data. So things like that is something that the platform team specifically looks at quite frequently, just the amount of questions and pain points that we can see engineers running into.

[01:08:16.05] But I think also just being able to move really efficiently and fast on a lot of our projects is another indicator, and being able to have anyone jump into anything pretty seamlessly is huge. So our team is responsible for - I think it was like a hundred repos out at one point. It’s less than that now, but there are so many things that we needed to know about on this team, and for a while, we had one person who is an expert on this tool. One person who’s an expert on this tool. “Oh, if this person’s out, you’re going to have to wait until tomorrow to get an answer to your question on it, because they’re our expert”, and with these educational efforts that we do within the team, it’s slowly becoming a scenario where anyone can hop into this and get the answer to this or bring this to a resolution, because we’ve either put really good documentation in place, or we’ve done a really good job sharing context at our stand-ups, or leaving each other the training and learning opportunities that we need with scaffolded PRs in order to get other people involved in an easy and safe way with these other projects. So things like that.

Anything on closing, Brittany? I know we’ve got some resources mentioned that we’ll put in the show notes. But I’m curious if there’s anything you want to call out, that’s like, “Okay, you made it this far… You must want to dig further or dig deeper.” Any particular resources you care to call out or want to call out?

I would definitely read up and watch the two talks that I mentioned, Camille Fournier’s blog post and Katrina Owen’s –

Cultivating Instinct, yeah

…video on Cultivating Instinct. And then there’s a lot of education research that I would encourage people to look into, just literally about how our brains work and what the different learning styles are that exist. And I have tons of links to these that I can send over that we can include. This will really help us understand why we prioritize certain things in our minds and we prune out others. Why it’s important for us to know what it is about our instincts, what made those things instinctual for us, and how we can get back to that beginner perspective. And then it might help you come up with more creative strategies for how to implement some of these classroom-based learning opportunities that we’ve talked about today. So lots of educational academic research I would definitely be digging into.

Yeah, I’d be curious for sure. We’ll get those links from you and put them into our show notes. So listeners, you know they’re there; head back to the notes, you’ll find them, a link away. Dig deep, be curious.

Brittany, thank you so much for walking us through this process and sharing a lot of your wisdom. I know it’s just like – wow… I mean, to lead and be led is a challenging thing, and to learn how to learn or even teach how to teach, it’s a challenging thing, and we appreciate your time today. Thank you so much.

Yeah. Thank you both so much.