Dave Paola: Agency of Learning

• Visit the Agency of Learning to learn more about Dave's innovative approach to junior engineer hiring and management.
• For a more in-depth understanding of teaching for mastery, check out Sal Khan's illuminating TED Talk.
• Get involved with open-source contributions and support social good with Ruby for Good.
• Discover Casa, a case management open-source app that supports volunteer work for children in foster care.
• Dive deeper into the tech industry's professional growth and career progression with Engineering Ladders.
• Check out "Engineering Management for the Rest of Us" by Sarah Drasner for relatable and pragmatic advice on engineering management.
• Read David Marquet's transformative leadership book, "Turn the Ship Around" for a novel perspective on leadership and management.
• Connect with our guest on Twitter @dpaola2 for more enriching content and discussions.

Welcome to Build and Learn.    My name is cj.    And I'm Colin, and today we are talking with Dave Paola    about the Agency of Learning.    Dave, welcome.    Hello?    Yeah, hi.    How's it going?    Good to be here.    Appreciate you.    It's going great.    Yeah, life is good.    Work is good.    we're in the beginnings of spring, or I guess beginnings of summer here.    I'm calling in, calling from rural Ohio today.    so there's a lot of green, things are good.    Life is good.    Are you on starlink or what's your internet out there?    funny enough, good question.    I investigated starlink and, I haven't pulled the trigger yet.    Basically, I'm living in a family cabin right now, that has been in my    family since I was born, basically.    and I was able to finally get internet access here in, I think in late February.    For the first time in, it's 30 years of existing, and the internet    is faster here than it is at my parents' house, in northeast Ohio.    It's faster than the internet I had in San Francisco in the Mission, and    it's faster than the internet I had in Tahoe and it's half the price.    it's fiber internet.    Yeah, it's great.    Kinda surprising.    I'm excited to try out starlink, but I don't know, I'm not very optimistic    that it would work well for a Zoom call or like a remote podcast recording    like this, just given the latency.    But, yeah.    I had to ask, given you're out in some rural spots, I do    know that it's available here.    There's like a small lake here and somebody acrossed the lake told    me that they had, star, Lincoln had only recently gotten it, and    that they were raving fans of it.    So who knows?    Maybe it's in my future.    Nice.    Yeah, it's, it's big in the van life community already, especially for nomads    and being able to still be connected.    Cause I think the joke has always been that like, digital nomads    are probably gonna be like the least dependable contractors.    You got a lot of like software developers to try to travel and then you're just    like, they're never able to follow up on, they're like, oh yeah, my internet's bad.    I'll sync up later.    And.    Push up your code when I'm do surfing.    Yeah.    Yes.    Let my people go surfing.    I got some friends who are, who are van lifers and, it's interesting,    as part of that appeals to me, I've heard their stories about, going    to Thailand for a year or whatever and saving cash and surfing.    But I also remember hearing a story of, I, I don't remember if it was them    or if it was somebody else about, they would basically pull up to the beach.    They would work, off of a charged car battery, and as soon as the car    battery died, they would go surfing while the car battery charged.    And so the thing that would dictate their hours, the flex,    the flexibility of their hours was actually the car battery capacity.    Not, time zones or, their mental, load or how much sleep they got    that day or anything like that.    I always thought that was a, it was a funny story.    It's a forced break.    I think that's good.    But, yeah.    Yeah.    Yeah.    So I think today we're gonna be talking a little bit about, helping early career    developers grow into more mid-level senior level developers one day.    And, before we jump into that, we'd love to hear a little bit about    your background, Dave, and just how we got to where we're at today.    Sure.    I'll try to be brief.    Let's see.    So right now I'm founder of the Agency of Learning, as you mentioned.    the Agency of Learning is basically a community of early career    developers who, are either bootcamp grads or self-taught, or otherwise.    I've described it in a variety of ways.    And the way that is most resonant with developers is that it's a community to    help you get job ready for that first job.    being a junior developer is pretty lonely.    You're often working on.    Your own solo side projects, and you've selected those side projects so that you    can potentially learn a new technology because you think that's gonna make    you more attractive to employers.    the employer pitch is a little bit different.    the employer pitches, we're essentially a finishing school for bootcamp grads,    and I find that most employers nod their heads at that description with    very little other detail required.    Right now we're pretty focused on Ruby, on Rails.    I'm growing it very slowly and exclusively so like I interview every single person    that joins before they're, before they receive their link to Discord.    we run it like, like a real team.    It is a real team.    we contribute to open source projects.    We have daily standups.    We have a couple folks who are more senior that help with all the code review    and, we do design documents for all of our high level technical decisions.    We follow a pretty, structured agile process.    And so forth.    My background comes from the bootcamp industry.    I won't go into too much detail, but, basically a buddy of mine back    in 2012, co-founded block with B L O C, which was, to my knowledge,    the first online developer bootcamp.    I.    We were involved with Dev Bootcamp extremely early on    during their first cohort or two.    and we worked with, the founder there, for a short time and decided, Hey,    we should try to do this online.    It eventually evolved away from the online classroom model, towards one    of a, towards more of a one-on-one model where we would pair bootcamp,    attendees with experienced practitioners.    We pioneered a lot of the, a lot of what you see now in the online    developer communities where you have a developer boot camps where you have    the income sharing agreement and, we have lots of thoughts and opinions    based on the experience there.    And eventually what we landed on was, I was the C T O.    And so I was responsible towards the end of my tenure there.    I was there for six years, responsible for the longest and    most intense product, which was the software engineering program.    Went to hiring managers and basically heard from hiring    managers, Hey, 12 weeks isn't enough.    you have all these gaps in all these students.    And so we put together a longer, more intense program, to get them job ready.    and eventually we had this thing called the tuition reimbursement guarantee, which    was basically like, you know, uh, get, get a job where you get your money back.    a lot of my experience since then, and certainly what I'm doing now is based    on my, my experience at Block and.    It was a really wonderful place and we had some really great people working    there throughout the organization.    and I think we were like one of the last programs that was based on Ruby    on Rails and I, can talk a lot about that, when you're, when you're    talking about like this finishing school for bootcamp grads, like what    are the main gaps that you're seeing?    is it how to work?    In an engineering organization instead of independently?    Or is it more like computer science fundamentals?    what is going into sort of the finishing pieces?    Yeah, that's a great question.    the, it's, I am still iterating and honing the way I describe this.    Probably every time I talk about it, I talk about it a little bit differently    because we're learning so much, so fast.    But, Most, it's probably 50% technical and 50% non-technical.    the technical stuff is, it's really just like when you come out of a bootcamp.    you've learned the fundamentals, in theory, and you've maybe worked    on some, some greenfield projects, but here's what you have not done.    You have not been assigned a, a small task and an existing code base that is running,    Ruby two seven and Rails, five oh that has nine GitHub actions associated with it.    Two of them are flaky and, you have to get this up and running on your machine,    and you have to do so in your first week.    And you have to manage the expectations of your employer along the way.    You wanna be able to communicate effectively.    So it's basically like a whole big mess of okay, technical skills.    How do you get your environment set up?    How do you get unstuck when you inevitably get stuck setting up    your environment like we all do.    how do you do so without overburdening your employer?    How do you do so without being overcome with imposter syndrome?    How do you, communicate?    What you need and when to your colleagues, if you have colleagues    and a whole bunch of stuff.    it's hard to articulate like line by line what it is, but what we've found    is that basically doing a simulated team environment with open source,    like ticks most of the boxes, uh, it's very obvious, you know, for example,    do you wait to be asked for an update before you give an update on your work?    Or do you proactively provide the update at a, a, a.    Same time every week to your employer.    how do you.    Infer tone from pull request feedback.    what does a nitpick mean?    Is a nitpick a nice to have or is it a need to have, like all these things    that, that we know about as developers every day, if you've never worked    on a real team, like you have to learn all of this in your first job.    And so by providing what is essentially a volunteer job experience upfront and    by, honestly like selecting the best people I can find, like the idea is    that, the agency of learning becomes a place where employers can go to find the    very best junior de developer talent.    Yeah, it's really interesting.    We, we, we did this at the collective, so at the, our co-working space, we    worked with the university to hire a software developer kind of intern.    So it was, this is really cool program that the students voted on    where they're, they're, I forgot what they're called, but they pay into    their tuition to create this program.    So the program then pays the students so that we didn't have to pay them,    but it ended up being a really cool program where we get the grant to    pay the student to work with us.    And we were building, you'll love this, but we're building a co-working    software, management system.    Oh.    And the funny thing was like, you could see as they were, this was    someone coming outta computer science and they were, very good technically.    but there was that piece that you're talking about, like working with a team.    In the real world.    And there were all these, very senior Ruby on Rails developers who    just were too busy to be honest.    Like we were like, okay, we want, they're gonna be here to help you.    And so when we started working on the project with these    developers and our intern.    And at the beginning it was a lot of them, you could tell they were looking    for permission to do a lot of stuff.    am I allowed to give feedback?    Can I ask for this?    To, by the end of their semester, they were in GitHub being    like, Hey, where's your pr?    Hey, can we close this?    What's going on?    Like it was, I.    I, I don't care how many lines of code were written.    I was like, you have reached the next stage.    Like you have to get stuff done sometimes.    And it was just like, that is the one thing I took away from that was so like,    I don't know, just filled up my cup kind of thing, where it was like, I think we    succeeded here and I can, I reproduce that with every individual person.    I don't know.    There's a little bit of, personality and like you said, imposter syndrome    and all these different things, but I didn't intend to teach that, but    she was like, my semester's ending.    We have to get this project done.    Where's your code?    Why is this still open?    I was like, you might have a future in product and project management.    That's awesome.    you say it fills your cup like it does.    It does with mine too, and I dunno if you remember this or if you    ever watched this talk, but what you've just described reminds me    of way, way back, like maybe 2011.    Or so, Sal Khan, when he launched the Khan Academy gave a talk, I think    it was a TED Talk where he talked, I think it was about mastery learning,    and it was a TED talk about mastery learning, where you don't let each    student proceed until they've mastered the topic at hand, which is, I dunno    about either of you, but very different than my public, school education.    and he talked, he had a graph that he showed of each individual student.    It was like a scatter plot with a vector attached to each point.    And you could visualize each line was a student, and you could see as    time went on, So the x axis is time, and the Y axis is like competency.    And most students were roughly in the middle.    It was like this linear progression in the middle somewhere, not perfectly linear.    but then there was this one at the very bottom that for long, took a    long time, whatever the topic was, algebra or something took a long time.    But as soon as they hit it, they spiked and outperformed everybody else.    And his point was, in the traditional education system, that person would've    been labeled learning disabled and.    Their whole life trajectory would've been different.    And so that was, that's the whole Khan Academy Mastery Learning thing.    And I find that very, fulfilling, fascinating, intellectually interesting.    especially because education is so important in society.    But, in a more micro level, maybe like watching the less experienced developers.    If you give them a chance and you give them the right environment, like    they can do amazing things, way better things than at least 50% of the senior    people I've ever worked with, which is uncomfortable to talk about sometimes    when you're talking to senior people.    But, but man, it's awesome.    I can give you three people right now that come to mind, like very similar stories.    It's really cool.    So could you help explain a little bit about the model?    Like how does the agency of learning make money?    Are the junior devs paid?    Are they unpaid?    Is it all open source?    Is it like, are you taking projects for clients?    Are you building your own stuff?    what does that look like?    it's been changing a lot.    In the recent past, and it will probably change a lot, in the    immediate future as we learn more.    I'm definitely taking like the lean startup approach to this, where I'm    like, try trying every different model and seeing which one is a good fit.    And honestly, I'm not sure we found the right model yet.    So I can tell you what we're doing now.    I have a very small for-profit agency that is becoming more of a    side agency to be honest with you.    And the agency is like, the naming is very confusing here.    My actual for-profit agency is called Sierra Rails.    It's been around for a year and a half or so.    the Agency of Learning is, as you mentioned, it's totally volunteer based    right now, or I should say it is a freak.    It's free to join.    there's no compensation involved today for, I, for myself or for the,    For the members and the way that one business model I've been investigating    with, I would say it's very early.    the results seem promising, but I don't know if it's where we'll land,    basically like I become a little bit of like a staffing model where, on the    strength of the technical assessments and the experience and the candidates,    we place these folks on a contract a higher basis inside companies.    I have.    Three candidates right now.    they're not candidates anymore.    They've been placed.    So I have three eight junior devs right now that are on that model.    And, it's I don't know the jargon cuz I'm new to the staffing industry,    but, I have some friends that have basically contracted through an    agency like this where the agency takes a cut for placing them.    So that's one early experiment that I would say is like modestly successful.    it could be that we evolve more towards a model where employers pay to get    access to a profile system or something.    I think we're a long way off from that.    although who knows?    But basically like the model is, Dave identifies like the best    people that apply, makes sure they are good, and then gives 'em a    bunch of volunteer experience for.    Three months, six months.    And it's not just, it's not just Dave.    It's like I have a team of people working with me, so I don't wanna    take all the credit, but essentially it's, building a brand for employers    that employers can trust us to give them really good candidates.    and trusting that at some point we'll be able to make money off that.    I don't know when that will happen.    so I still have a day job, but, yeah, that's how it works.    It'll be exciting to see.    I think we're seeing this in the rails world with the Rails Foundation and    things too, where they're wanting to focus on education, and how does    Rails show up to that conversation?    And you mentioned like having a curriculum, in the boot camps that    you've worked with in the past.    And there's the gaps and there's no replacement for real world experience.    Either.    So getting a blend of that, and it'll be interesting to see how Agency of    Learning fits in with things that exist, boot camps that exist, go Rails, rails,    foundation, whatever comes from that.    and yeah, I was going somewhere with that, but We'll, I'll turn it over to cj.    Yeah, no, I was just reflecting on.    my experience too, teaching at a bootcamp and then at the end having a group of    students that all knew the same stuff.    They all knew the same stack.    They all knew the same at the time.    We were using like rails in the back end and backbone on the front end.    And so it was fun to see okay, they did their final project and now like maybe    they're working on some extracurricular stuff to polish up their resume    and get ready to go look for jobs.    But at that time, like right after they came out, it was cool to see    many of, the students work together because they could pair and build    stuff really quickly because they all had this common language about.    Okay.    I know exactly what, my model's gonna look like, my controller's    gonna look like, and you know what?    My front end is probably like the conventions that I will likely follow.    so that was really exciting to see.    And then, I remember.    watching a lot of those students go on to work at, at agencies and for    companies like Thoughtbot and Pivotal Labs and, in those environments where they    continued the pair programming like, like really immersive and like intentional.    Learning process, and many of those engineers are now like the best    engineers that I know in industry.    And I think the pattern totally works and, yeah, I'm, interested to watch    as you figure out the business model.    But I definitely have seen and experienced, some juniors.    Being really effective.    And also the pair programming model working really well.    is pairing something that's part of your process or is it mostly solo,    you're gonna get a task and we expect you to go execute on that or, yeah.    What is the, like the day-to-day for one of the juniors look like?    Yeah.    so first off, I couldn't agree with you more.    my, the experience I had lines up.    Perfectly with what you just described, to the point where I now have, one    of the, one of the challenges we'll say that I face an obstacle going    forward is in communicating to employers the story that you just told.    This is a story that I tell all the time, nearly verbatim to what you    just said, so I won't rehash it.    But the idea that you can hire two developers instead of one.    It feels like educating the market kind of a challenge, because over and over    again, the opposite story happens, right?    It's oh, yeah, I don't have the budget to hire two juniors, so    I'm only gonna hire one junior.    it'll be fine, right?    And no, it's not fine.    it's so significantly different and we all know how that goes too.    Like we know when you hire a junior and you don't set expectations properly, you    don't communicate with them effectively.    They get imposter syndrome.    They feel guilty for asking their colleagues for help.    I had a candidate recently who, was told that they were not allowed to    ask their senior colleagues for help.    And if there's not a faster way to destroy, the potential in a junior    engineer, I don't know what it is, that's gotta be the one that does it the fastest.    you're not allowed to ask for help from your, so nonetheless,    th that mindset is still pervasive in the, in the market right now.    And I don't know how to fix it, beyond just keep talking about it,    keep evangelizing and so forth.    but yeah, basically to answer your question, Yes, pairing is a    significant part of the experience.    Basically, we follow what, used to be a pretty normal agile process of you    go, get acquainted with a feature.    Either you pull it off of the work board or you talk to your manager about it or    your product manager and, you spike on it.    Say, okay, let's go take a couple hours and write some throwaway code.    And you write the throwaway code, and then you come back and you talk about it.    You have a conversation.    You use the code as an artifact.    In that conversation, you say, this is the part that's gonna be really easy and fast.    In fact, it's already done.    This is the part over here that.    We tried it this way and this is not the right way.    We're gonna have to try a different way.    Or you say this way worked, but we have to change 30% of it, or whatever.    And then you go on and build it again.    And when you build it again, it goes four or five times faster because you've    already done the majority of the research.    And I don't know why maybe someone more experienced can fill me in, but    this is way more effective at avoiding the gigantic PR problem where you    have this huge PR at the very end and people are just like throwing feedback    into that PR willy-nilly, senior people, junior people, nice to have,    need to have nitpicks, style, choice, who it is impossible as we know to    get like an architectural overview.    How does this thing work when you have a 4,000 line pull request?    You have to review.    But we've all been on teams like that I'm sure.    yeah.    Repairing is a big part of it.    Pair we pair on the spike aspect, and sometimes they pair the whole time.    Sometimes they stop halfway through and it becomes very obvious that the    seams, the seams are obvious and clear and they can just, come together.    But it's very rare that there's no pairing happening at all.    You didn't specifically mention it, but , having two juniors, instead    of one, allows those two to pair with each other as well, right?    So that they don't, they're working.    Someone might have a slightly different background, they might be a little bit    ahead, a little bit behind, technically and They hopefully will still get to talk    to their senior engineers, but having the two means that it's not this lonely,    existence on the team where they're like, okay, we were brought on, I've    been on many teams where they'll hire a junior, but then they don't set the    expectations with the senior people that.    Or even giving the senior people the right training.    I would say mentoring is not a given, like most people have not been    taught how to teach or how to mentor.    And it's a chicken and egg there too, where you do have to develop it.    Like in my roles, I do see, helping my team as part of my job.    It's not just to produce my own artifacts, to produce my own code.    I've also been a senior engineer who's guilty of making the too big of a PR    that's got way too much stuff in it too.    Because we've just been jamming on one idea or one concept, but    that makes it harder for juniors to learn from as well because now    they, are they gonna emulate that?    Are they thinking this is what being a senior engineer looks like,    that you have to have these huge, massive, like too big to fail prs?    No, it's not.    So there's a little bit of modeling that has to happen.    Role models.    a little bit of training.    I don't think, I don't know Sure.    If you've heard of anything.    Is there any formal programs for teaching seniors on how to do    mentorship and things like that?    I'm sure there are, the only one I am aware of that's top of    mind is one from Engineer Kit.    And I think it's pretty new.    I talked to Gavin, at Engineer Kit a little while ago about this    that's the only one I'm familiar with off the top of my head.    I do think you're right though.    And I think one of the, one of the things that I've stumbled upon here is    that if you're already on an engineering team, That has a great culture in    terms of, egoless leadership and people are able to give candid feedback and    revisit decisions along the way and you have a culture of helpfulness and    openness and, no such thing as a stupid question, those kinds of cultures.    Then you can add juniors to that environment and they'll do fine    even if you hire them one at a time.    It's the other cultures that you need to send these squads of juniors    into to, in a sense, be a version of it's like you're implanting a seed    of a new environment into a team and you do it with these two juniors and    it can work really well actually.    It's very, it's harder, but I think it can work well.    but I do think, basically I agree with you like the.    The idea of being a good role model is like half the battle, if not more.    Sandy Metz, I'm sure we all love and admire Sandy Metz.    I certainly do.    she had a gr, I forget which talk it was in, but she, hammered the point    home somewhere that when you have, especially newer engineers, but all    engineers I think are guilty of this, you go into a new code base and.    You're tasked with writing some code or building a feature    or changing something, right?    Most code is not written new.    It's changed.    And when you need to make a change, you try to adhere to    the patterns you see already.    And if the patterns that you see already are, subpar, if you add juniors to them,    they're gonna copy subpar patterns.    It's not necessarily cause of stupid, it's because that's what we all do.    And so I find a lot of my work at the agency now has become, Try to    make sure the guardrails are good.    Try to make sure the patterns that are there.    it's actually more, it's actually a little bit like an architect role, but    it's not about the architect of the code.    It's about architect the code that people are going to live in and habit.    So that like when you add more people to them, they don't just duplicate bad    patterns, they duplicate good patterns or arrange things in such a way that.    The patterns emerge or there are no patterns.    Like you, you organize the mess first and then you separate the messes first and    then it's kinda refactoring a little bit.    But anyway, yeah, being a good role model and like making good technical    decisions, I find is half the battle.    and to your point about new engineers joining a team and having those 2000    line PO requests, like everybody is guilty of this, myself included.    And one of the meta lessons that I've watched some of these folks    learn is, oh yeah, okay, this is far messier than I expected.    Like we have a big project and it's not this perfect harmony of beautiful code.    And the process rained perfectly.    It's like there's some stuff that went in at the last    moment that is not good, right?    And we just have to suck it up and deal with it.    And that's gonna be a reality too.    I think that's an important lesson to learn, that you're not gonna learn on    your own, on your solo side projects.    you gotta learn that in a real team.    What I like about this too is most times when someone comes from a bootcamp, they    have, a set of kind of personal portfolio projects that they've worked on, but    they're solving a problem for themselves.    It might be a portfolio website.    It might be.    a to-do app, Pinterest clone, things like that.    But they're not necessarily, they've nev never talked to a customer.    They, and in some cases, I don't think that's necessarily an    expectation of a junior either.    But like you, you're just coming up with a thing on your own to do it.    And it's greenfield like you mentioned, but you don't get    that world real world experience.    And I would actually say like open source.    Feels like jumping into the deep end.    what sorts of projects are we talking about when we talk about open source    that folks are contributing to?    that's an excellent point.    we even had at Block, we had, as part of our longer track, We had something    called the open source apprenticeship.    It was like that last after the capstone project.    You would go, ostensibly work on real code.    It didn't work very well.    it didn't work very well because it wasn't real.    It, even though it was open source, it wasn't a real simulated team.    It was like, go hunt and find issues that, people need help with out on your favorite    library and try to contribute to them.    And it did a good job of instilling the experience of getting acquainted with a    new code base, cloning the app, getting it running, and like trying to understand    what's what and how it all works.    But that still wasn't real.    and so that's part of the, reason we're doing it this way at the agency, but,    right now we have two projects and we're about to have a third that I'm very    excited about that I can't talk about yet.    and maybe we'll have announced it by the time this airs, but the two that we work    on right now and I'm very grateful for the ability to contribute to Ruby for good.    so Ruby for Good.    If you're not, I'm sure the two of you are, but for the listeners that aren't    familiar, it's it's this great group of people that donates their time,    and energy to work, to basically build out open source rails applications    for charitable organizations.    So the first one that we're working on is called casa, which is Core    appointed Special Advocates.    It's a system that, nonprofit, pasa organizations use to manage their.    Foster youth.    Not just the foster youth, but the volunteers, the cases, they go to    court, they have to go report to courts and give updates and so forth.    They have to keep track of their volunteers and whether or not    their volunteers are commuting to meet with their CASA youth or not.    And different organizations have reimbursement schedules and it's a    real product in use by real people.    It just happens to be an open source.    It has all the warts and skeletons and cobwebs that a real app    has because they've had to make trade-offs over the years.    And so far that's the one that, I would say has been the most realistic and given    people, I think, the best approximation of what it's like to work on a real team.    in fact, I feel comfortable enough with that fact that I encourage our    folks to add to LinkedIn the fact that they have worked in a volunteer    capacity on this real product.    Because that's what it is.    Talk.    There's a stakeholder meeting every Friday that we go talk to the users who use it    and hear the bug reports and that's the kind of thing as another representative    example is if you're an engineer working on this app, you get to go every Friday    to hear about this repeated bug report.    You have a disgruntled user sometimes that says, Hey, this bug still isn't fixed.    Why isn't this bug fixed?    And if there isn't a more representative example of what    it's like to be an engineer on a real team, like that's it, right?    yep.    Now we're working on it, right?    so the second one is an app that we're building for ourselves.    Actually, it's an open source as well.    It's the app that we're gonna be using to basically manage    the experience of the agency.    Know, profiles, login, wait list, onboarding, FAQ Pattern Library.    we have a lot, we have big plans for it.    We're starting very small with a feature called pair requests where if you are    open to working and you want to pair with somebody, then you send up a little    pair request and it'll notify people.    And a little bit like Calendly actually, but specific for    developers who want a pair program.    so that's another project we're working on.    And as I mentioned, we have more on the way.    If anybody has ideas, if any, if either of you or you, your listeners have    an open source project that you would like some help on, that you think    would be a good fit, please email me or text me or DM me or whatever    and I'll try to make it happen.    Cuz right now that is actually the bottleneck is, getting ahead of the work,    making sure it's scoped, making sure it's prioritized, just like a real organization    that's actually now the bottleneck.    We have plenty of developers trying to get in, Thank you in advance.    Yeah.    How do you balance the demand?    Like how are you balancing supply and demand, like the projects you're    working on versus how many devs want to participate in the program    and I assume that once someone has volunteered for six months or so,    they like spin off and go get a job.    and so you're constantly trying through people or Yeah.    how does that look?    Yeah, I think one thing that's very important to me is that once    you get a job, you don't leave.    I remember back in the bootcamp days, there, there were some    call them optical challenges.    there was one big bootcamp that we've all heard of that would    hire their own grads to teach.    And this got a very bad reputation.    And I, there's other things as bootcamp did that were, not great.    but I do think there is a lot of merit, and I think lots of educators would tell    you that there is a lot of merit to the best person to explain something to you    as someone who just learned it themselves.    Because when you're really experienced and I remember mentoring the first,    some of the first block students back in 2012, and we made a mistake together,    pair programming, and they said, oh, don't worry, but just get checkout.    And they're like, what's get oh my God, we need to add version    control to our curriculum.    I.    And so those experiences of forgetting you forget what you know already.    And I think it's very powerful to have, somebody who, anyway, so to feed    this back in to the question is, we care very much that the people who    get work through us, stick around and help their fellow community members.    It's so at that point it kind of transitions from, become job ready to    like, Newly employed mastermind group or mastermind community where, you know, next    Wednesday, we're having a roll call, we call it, where if you're on a contract,    then we just get together on Zoom and talk about the challenges we face and, whether    or not it's like, how do I communicate this tricky situation to my employer?    they said, I'm only allowed to have X hours a week.    I wanna work more than that.    Do I build them?    How do I think about that?    Is it okay to go over some of these questions?    you don't really encounter until you get your first job.    so yeah, it becomes a little more like a mastermind group in that regard.    I.    I imagine that some of those folks are also then able to be more like    the quote unquote senior engineers for the new juniors, right?    For pairing partners, stuff like that.    So they, I.    Their alumni of a sort that can contribute in other ways, help, agency of learning    become a little bit more sustainable.    So it's not just Dave and a few other people who are    keeping the lights on there.    Does that play into it at all?    Yeah, you nailed it.    it's like the value of the community.    It's one of the reasons when, you try to pitch a, this is not a venture backed    thing, and I'm, I have no intention of making it that, but if you pitch to a    vc, you go on Andrews and Horowitz's website and read about the kind of    pitches that they fund, it's okay.    Network effects.    network effects.    There's a reason.    It's every time you add a new great person to a network, it    increases the value of the network.    And that's true here.    That's true in every community I've ever been a part of, is like the value    of the community is the other people.    And so if you have people that you know, they come in, they work for    a little while, and open source, they get some great experience.    They get their first job, they get their second job, they come back and they    share that wealth with the community.    It makes everything better.    It makes everything more valuable.    It makes the community more valuable.    It gives them that experience of coaching the juniors, which we just talked about    is really valuable, for their career.    Yeah.    I wouldn't call them senior right away, but I would definitely say like we want    them around because more experience.    Imagine you're a bright isle, bushy tail, bright eyed, bushy tail junior    developer looking for your first job.    If you're in a member of a community where someone just like you, like just    got that first job and they're coming back, you get to listen to all the    challenges that they're facing and the challenges that you never would've.    Thought of.    It's just a really cool experience, you know?    I think the brand that you're talking about there is important.    Cause there's definitely some boot camps where when we would get applications    from that bootcamp, we would take it.    They would go to the top, like we're like, okay, of all the candidates,    like we really enjoy talking to and know, we know the level of curriculum    and everything that comes outta that.    We've had people on the team who've come from that bootcamp.    and then there's definitely been other ones where, okay, we're gonna have    to go really like in the take home tests or whatever, figure out what    might be missing, things like that.    And so having a strong brand with agency of learning and keeping, I would say    Keeping that high is important there so that when I see Agency of Learning, I    get excited that someone from Agency of Learning is hoping to work at my company.    And I think you've talked about this on other podcasts that kind of became similar    with Pivotal Labs was very much like this.    It's like someone would go from a bootcamp, go work at Pivotal,    and suddenly everyone's oh.    I want a Pivotal alum on my team.    When they move on to their next thing, usually they would    go on from agency to product.    And you end up with all these people at Airbnb and all these companies    that came from Pivotal, which I don't think is pivotal, still around.    I don't think it is.    Yeah.    So we've got today it's probably more like the Planet Argon, the evil Martians,    sorry for all my agency friends.    Sierra Rails.    Not Bot.    Not bot.    There we go.    Not bot.    Yeah, you're right.    it is brand building.    There's a lot about this that's not only is it not new or    innovative, it's actually very old.    we used to talk a lot about this.    At Block we had this problem where, The whole industry decided on the    placement rate as a metric that prospective students should use when    deciding which boot camp to attend.    And like on its face, if you're looking at applying to in-person    boot camps, it makes sense.    It's not a crazy concept.    It's yeah.    How many people, went through the program as the denominator, and how    many people got jobs as the numerator?    And when you're dealing in, 10, 20, 30 people in a cohort and you only have four    co, four cohorts a year, yeah, that's less than 200 people, less than 300 people.    that's not crazy.    What it means is, first of all, geolocation, depending on where    you're at, San Francisco, la, New York, Houston, Dallas, whatever.    That bootcamp.    it's the same thing as college admissions.    It's literally the same thing.    you're identifying the best people and you're bringing them in, and you're doing    it so you can get a good placement rate.    so that you can build that brand.    Block.    Block was different.    Man block was much harder.    we had an admissions process, but it wasn't that competitive.    and the whole point of doing it online was the scale.    We wanted the scale of impact to be much larger.    And that's one of the reasons it ended up looking very different    than an online classroom.    when I left we had 3,500 concurrently enrolled students and.    If all you're looking at is a placement rate with numbers at that scale, you    have to have five asterisks after your placement rate because you know a lot.    What about dropouts?    What about people that don't want a job?    We wanted to accommodate all of those people, but in order to meet    the market, the optical market needs anyway, it, it was a big challenge.    and I think, this model is simpler.    I remember.    hack Reactor.    I am, I'm unplugged in the boot camp world now, but I remember Hack Reactor used to    call themselves the Harvard of boot camps.    I don't know if they still call themselves that, but for a while    at least that was their brand and I think they did a really good job.    I think that, I think they nailed that branding because that's what this is.    it's about branding, it's about building a brand that people trust and you    need to invest in that reputation.    And I'll say right away, I don't think we did a great job of that at Block.    we did not appreciate how important that was.    And then we also did not appreciate how old of a problem this is.    anyway, so I agree with you.    When people are considering hiring junior engineers, one thing that    often comes up is who is gonna manage them or mentor them or lead them?    And I think.    In one of the posts on the Agency of Learning site, you talk about like    wiggle room in management practices and having a little bit more margin    to make mistakes in turn of management when you hire a senior person.    And I'm curious what your take is on maybe minimum level of experience for an    engineering manager or the other engineers on the team to successfully integrate.    Junior or two to their team?    I think it's like there's more than one dimension to mentorship, right?    there's like technical coaching, hey, You shouldn't use loops, you should use map,    or you shouldn't use polymorphism here, you should use composition or whatever.    this approach doesn't follow solid principles.    Duplication is better than the wrong abstraction, those types of things.    But then there's also hey, There's also like pulling the, there's like    the managerial duties of pulling aside the engineer and saying,    Hey, I get what you're going for in that meeting, this kind of a thing.    Got in your way there.    Next time, maybe try this approach.    Or, Hey, uh, you know, I, I have a really high bar for you and you didn't meet that.    Here.    Is everything okay?    so I think technically obviously you need to have.    Significant experience to be able to coach a junior from a technical    perspective, you want to definitely avoid the blind leading the blind.    and I honestly, again, an unpopular thing, like I see that a lot, I    see a lot of the blind leading the blind and it doesn't keep me up at    night, but it makes me concerned for specific organizations and teams.    I don't think you need a lot of technical experience to do the other stuff at all.    in fact, I think very junior, technically junior engineers can be significantly    superior managers and leaders.    I.    Because of their background, because of their, maybe their communication    skills or their interpersonal skills.    Sometimes they're just like the diamond in the rough and they turn    out to be really good leaders.    That's one person in particular at the agency right now that I know of that's    like that, that I feel very fortunate.    Basically like Pluto and Saturn lined up and beamed a good luck Ray into    us and we got this awesome person.    they're very junior technically.    So would they make a good mentor?    Like they make a good engineering leader?    they probably need some help making technical decisions.    But, yeah, I don't know.    That's a very good question.    I don't have a totally solid answer for Colin.    what is your sort of like experience to being maybe like being managed or    managing other people or whatever?    Cuz I think, yeah, I've got, My own takes about managing    people or like mentoring people.    And it's tough.    It's super tough to do it right and bring them along and, yeah, I think, yeah.    I'm curious your experience too.    The wiggle room really resonates with me is that you do have to have the    space for it, and you have to give yourself, if you're the one mentoring    and helping, that is part of the job.    It may not feel like, oh, I'm a software engineer.    My job is to write code.    as you get more senior, and I think we haven't done an episode on this, but    we'll share a link to the engineering ladders as you get more senior, your.    locus of control, if you will, gets more from, goes from    more internal to externally.    You start working more on how as a junior I have my tickets and I'm working    on my things and I'm learning myself.    You're not so much worried about what other people are working on.    you might start to think about how your ticket fits into the greater scope of    things, and then you get to the next level and you start to work with other people.    I like the idea of pulling, pairing down so that you are working with other    people on more earlier in your career.    But starting, you're not having to worry about the business goals    as a junior engineer, Versus as you get more and more senior and    you're getting towards that senior.    Level engineer, you're actually more concerned about what the whole department    is working on or what your team is working on and how it fits into the    greater goal and things like that.    And so I would say like all of that is part of the work and I really enjoy for    developing like your own, whether or not you're an IC or aspire to be a manager.    There's a really good podcast called Developing Leadership    from Jason Warner and ISO Kent.    and then there's also a really good book called Engineering Management    for the Rest of Us from Sarah Dresner.    And both of those are really good at just if you don't want to be an    engineering manager, they're useful to listen to, to learn how to work    with your managers to learn like what is even engineering management.    sometimes that person was an engineer.    Sometimes they're not.    It really depends on the organization.    and.    It's also a very big decision people have to make is a lot of people will stick to    the IC track and some people will choose to go to the people management side.    and so I think if you're out there and you're thinking about bringing    on a junior, like you gotta give yourself the space and time to make    sure that you can do the mentorship and that remember it's part of the job.    You might not feel like you did the same amount of work as you did yesterday    because you had to do some work with your.    You're Junior and it's great, that's part of the job.    that's going to, you're gonna see that payoff in spade.    Like you could have done the work yourself, but now they're gonna    learn how to do that work and they're gonna be able to develop themselves,    which is, goes a lot farther.    Totally.    On one of the teams that I was on, we.    Worked really well as a small engineering team.    And we had some, I would say like we were pretty functional, like high functioning    in terms of using Jira really well.    We had our velocity was like really locked in.    We could estimate really well, and one of the things I remember.    When we brought on a junior to that team was like, okay, everyone, we all    expect velocity to plummet for the next six to nine months because we all    wanna bring this junior along with us.    And so like it is a fully understood thing going into this that we're    gonna lose a little bit of speed.    And that's intentional because we want to yeah, eventually get that back in spades.    I think, one interesting experience I had was managing a couple of interns.    and that's when I started to recognize there's so many different behaviors    as an engineering manager, that can make it so that the junior is    more successful or less successful.    It's like you gotta, you do have to be explicit about those communication    touchpoints and about holding certain bars and being really clear about    the expectations and making sure that they understand how to achieve    those and all the steps in between.    And the more and more that you build that trust, the more you can    let go of the reins a little bit.    But I think, yeah, in my experience holding those, I.    Controls really tightly with a junior actually makes you move faster    because you can get to know what's expected sooner and then the junior    kinda picks up and runs with it.    but yeah, I think, I don't know.    Engineering management is very hard.    So anyone who's out there who's doing engineering management, I, yeah.    Kudos to you cuz it's, it is, it's tricky to be both technical.    And be able to work with people.    And, yeah, bringing juniors along is tough.    preach, that's all.    I'll, that's not all I will say to that, cj, but I'll say preach.    I think the best environments that I've ever seen or been a part of to    learn the craft of, of engineering management have been, a weird mix of    both supportive and warm, but also, The higher up you get, the more brutal    the consequences are when you fail.    and for me, just looking out my own eyes, the experience of block for me was    fascinating and it, I feel very lucky to have been a part of it because it    was, it's four of us at the beginning.    And then we started hiring engineers and hiring a designer.    And then we had hired a second designer and we hired an office manager.    We hired a director of marketing, then we hired a SA salesperson,    then second salesperson and support.    Before you know it, I used to joke my job changed every four to six    months and what I learned real fast was that like, you gotta get your    ego out of the way because if the ego's in your way, you're gonna fail.    And basic basically, cuz it's, for me it was this like, Crazy recursive,    meta hyperdimensional experience of like e every four months you'd have    a new mirror held up to you that showed you all your flaws, right?    Yeah.    Because the team be beneath you began to manifest those flaws.    It's okay, the next team, they better be better at receiving    feedback than I was, installing that.    And the last thing, it's it's a very humbling experience.    I couldn't agree with you more.    That goes both ways.    you don't want this culture of your company to be that people who are new    to the team, whether they're junior or not, to have this experience of    having to go visit the wizard on the mountain to go ask a question, right?    It's like you gotta check the ego at the door.    No matter what level you're at, you're on the same team, you're on the same side.    Like the goal is not that I know more, this is a very much a scarcity    mindset that sometimes happens.    And I'd be curious to end this, this episode on this topic of    right now in the market, there are.    Quite a few engineering jobs.    There's also quite a few engineering layoffs happening, but almost    all the jobs are senior and staff engineers right now that I'm seeing.    And I'd be curious to get your take on why that is.    Why when we see these little ripples in the economy, do we see a retraction in.    Early career jobs, and we don't have to solve this problem if we    don't know the answer to it, but I'd just be curious to get your    take on why do we think we see that?    Like why wouldn't this be an opportunity to invest in early career devs?    When you know, senior staff engineers, they come with ego, they come    with really expensive salaries.    Why is that still being hired for when we have other options?    I'm not gonna pretend to like.    be the oracle that knows why.    Cause I don't, my experience is not at big companies.    I don't, I've, we did do a layoff at Block in 2016, which was very tough.    so but I am of the opinion that it is an opportunity.    I find myself in this weird.    This weird spot personally, where it's I know, I feel like I now know,    especially after the last few months, I know how to hire pairs of junior    devs with the right amount of senior coaching, the right product management,    the right types of projects, and they produce superior results to a team    of, three senior engineers and it's cheaper and they have better retention    and they have better job satisfaction.    So what am I missing?    Like I do think that, And, I'm doing my best to educate the market and manifest    it, but I think at the end of the day, every team and culture is different.    to your point, CJ earlier about like the balance of like holding that control    very tightly produces better results.    I'm a big fan of, David Marque, who wrote this great book, turned the ship around.    I am not an affiliate or anything.    I've never met the guy, just, I'm big fan of his work.    and he, there's this idea of in the spirit of not ha not building a cult of    personality into your organization, he has a line about every organization knows,    e everybody knows of an organization where people will just follow the leader    off of the cliff, Instead, if you push the authority down to the information    rather than the information up to some decision making authority, then you    just get a healthier organization.    And if you think at it from a systems perspective like that, tuning    the control that you give to the competency level, and so you can    ratchet it up, is the key, right?    And so in this world of layoffs where it seems like nobody's hiring    juniors like Zig, when everybody else is zagging, turn everybody else's    deadly risk into your superpower.    that's what I would say.    find the playbook, execute the playbook.    It is not that hard.    What's hard is you, it's, it you, it will feel unnatural to you.    it's the engineering management problem that we've just been talking about is    it's much easier to hire the egotistical, expensive senior engineer and deal    with their baggage, sorry to say.    Than it is to hire a pair of juniors and go through that discomfort and    incur the management overhead and try to figure out how to run an effective    organization when you've really been just leaning on really experienced people.    Nothing wrong with that.    That's the kinda organization being it's fine, but, I perceive this as a potential    superpower and I see it in my team.    I've seen it on other teams and I can't figure out why more people don't do it.    So if you can crack that code, you'd be in the top 1%.    All right.    I think that's a great place to end, this episode.    Thank you so much for joining us, Dave.    And yeah, this is something, it's giving me a lot of things to think about too.    In terms of like, how best I can think of this in my own roles and how to    empower early career devs, and if you're interested in getting involved, where can    people find all the things about agency of learning, all things Dave Sierra Rails.    Where can, where should we send people?    Yeah, I should send people to agency of learning.com or follow me on Twitter,    which I'm too, still trying to figure out like the branding between myself and    the Agency of Learning Twitter account.    it's a weird hybrid, but yeah.    I appreciate you guys bringing me on and it was fun chatting and,    yeah, let's catch up again soon.    Thanks a ton.    as always, you can head over to build and learn.dev to check out all the    links and resources in the show notes.    That's all for this episode, and we will, see you next time.    Bye folks.    Thanks again, Dave.    See ya.