Case Studies in Apprenticeship Vol. 7 — John Gile, Derek Nelson, and Brent Williams

Time to Read:

We’re back talking about software apprenticeships and the practices that make them successful. This time we’re talking to three leaders from Clique Studios, a design and engineering company in Chicago. They recently completed their first Modern Apprentice Program (MAP) and sat down to discuss what they learned.

We’re back talking about software apprenticeships and the practices that make them successful. This time we’re talking to three leaders from Clique Studios, a design and engineering company in Chicago. They recently completed their first Modern Apprentice Program (MAP) and sat down to discuss what they learned.

Joe: Just to get started, I wanted to say thank you for taking the time to sit down and actually talk to me about the program you have.

Derek: Yeah, of course.

Joe: Could you tell me briefly what got you interested as a company in doing an apprenticeship program?

Derek: Sure. So when we were getting started on the initial site we had a link that said Clique University and it was actually just a blog. But, the idea was that we always wanted a pillar of our business to be about education and training and sharing our learnings, because I’m a believer (or at least a recent convert) to the idea that no designer or engineer is really self-taught.

Everybody is learning something through the community. So when I asked myself “how did I learn development?” Well, I was “self-taught”. What really happened was that I stole some code from some site that already exists by some engineer that was smarter than me. Took it apart, rebuilt it, whatever. That’s not self-taught, that’s learning from somebody. Same thing with design, same thing with really anything. So we wanted to accept that as a part of our business and realized that in technology and design everything is changing every day. And if you’re not really committed to re-learning your job you’re going to get left behind.

So we felt like an agency is a good place to do that, because if you’re working on, say, one software solution you’re building it and updating it all the time. It’s hard to get the varied amount of experiences you need to really be honing your craft. And having all these counter-arguments and other frameworks that might improve what you’re doing. So for us, we thought it was a good match. We just strictly believe in it, but we think an agency is a really good place to surround people with an environment to learn and get better.

So with us I think there’s two missions to our business. One’s what you see on our site; “Build something”. It’s making things. The second one is trying to get better at our jobs everyday. Brent has heard me say this ten times this week, but I want Clique to be the best at getting better. We feel like if we give people a path and an environment to learn and improve their craft every day, it’s going to be good for clients, so we’re going to do better work. It’s going to be better for us internally, because we’re all getting better. And just community-wise, it’s going to be great for Chicago and for engineering in general, if all of us are committed to sharing what we know and giving ourselves paths to get better.

Joe: Fantastic. And so Brent joined just prior to the initial apprenticeship round. Can you tell me a little bit about the structure of the program. How did you decide to lay it out?

Brent: Yeah, I joined the team kind of to do this thing. It was one of the first things. We wanted to try our hand at apprenticeship and really do a good job.

Joe: And you’re the Director of Education?

Brent: Yeah. That’s the title…

Derek: I’m trying to get him to refer to himself as the Dean.

Brent: *laughing* We’ll see if it sticks internally.

But the idea there really was to make it something that could be differentiated and at the same time really high quality. What we came up with was starting with what François, our head of engineering, and John, our CTO saying “Okay look, these are the skills we need for somebody to be highly successful.” And then planning backwards.

And I think that sounds intuitive. And it is. But it’s also for sure the way you would plan generally an educational experience, which is my background and mindset. And so that’s the way I tackled the problem. And then from there, we estimated how long we thought the average person would need to get to that bar, and landed on about twelve weeks. Starting out I always felt we had the advantage of leveraging a lot of shared apprentice program learnings throughout Chicago. So much has been learned and shared from your work on medium, to Dave Hoover’s book, the Apprentice meetup and friends like Blake and Jill at Enova etc.

So there was a mixture of explicit sessions, where you’re going to sit down with an engineer for two hours and really show you how something works, to projects, where you’re going to be on your own working through some stuff. To day long challenges to assess your learning. It became a mixture of things, but the idea that ran underneath it all was a progression from very very supportive one-on-one mentorship towards more and more independence.

Which is ultimately what you’re going to have to exercise to be effective as an engineer at the company. All of our engineers here mentor and pair with them, but eventually they get to a place where they’re a little more independent.

“Having an engineer that was in charge of mentoring all the apprentices through that project was more efficient and effective.”

Joe: So within that program, you said that everybody mentors. Does each apprentice have a set mentor, or is it something you’ve distributed across the team?

Brent: We started with doing one to one mentoring, and that remained a theme. But what became clear was that as we were giving projects to push people forward, having an engineer that was in charge of mentoring all the apprentices through that project was more efficient and effective.

And it’s hard when Bridget — John’s mentee — comes to him and says “this is what I’m working on”, if he hasn’t been involved in that project at all.

John: So we had an assigned mentor for every mentee throughout, but towards the end when we had larger projects, we tried to have a project lead essentially. So I would — as an example — if I were project lead, I wrote the project as it should be implemented, and so on. And then because I’m the one who wrote it, and because I have my own expectations, and because I’m the one who’s going to evaluate it have my own standards on how this project should be done, most questions go to me for that project.

But, that said. If it was just “I need help”, then you’d typically go more to your actual mentor.

Joe: Makes sense. So you mentioned evaluation, which I think is interesting. You guys wrote a blog post about the things you learned. And one of the things you mentioned was expectation setting. How do you set those demonstrable goals for apprentices, and how does that work when you have them reporting to a project where the owner’s criteria might be different.

Brent: That’s something that we realized partway through. That part of the challenge of doing it the first time is — because you don’t know how they’re going to respond to things — it can be hard in advance to say “this is the goal point”. Because they’re on a racetrack that is allowed to move. So it’s hard to figure out where the finish line is.

So what happened for us, is that in week six or seven, John, Ted, Derek and I were chatting. And we realized that we have a lot of qualitative thoughts about them. Y’know, “person A is doing this, person B is good at this.” But not a lot of quantitative “they can’t do this, they can do that.” And so, from that conversation the thing that we came up with to start trying these ideas of mini-challenges. And the way that we viewed that was we tried to segment out three of the biggest areas we need folks to be competent in. And for us, that ended up being really Full Stack PSD to Coded one page site, and a kind of Mini-Blog, and then François gave them a pretty basic Backend Task all in PHP.

And they each get to do each challenge, and they each get to be assessed by a different engineer. And so by the end of those three days, we have an unbiased (at least as unbiased as we can make it) datapoint from each engineer on each apprentice in three different skill areas.

John: I think how we started was that we started in the very beginning with more learning and less evaluation. We wanted to throw people in the deep end without heavy evaluation, and just push them in the right direction. And I think as you get further, you’ve got to start evaluating.

What we were having trouble with — well, I wouldn’t say trouble. When you get to bigger projects, they tend to cover everything, or more of everything.

Joe: They cut across concerns.

John: Yeah. And so the issue then can be that it sometimes becomes hard to evaluate what the actual holdup was in a project. Especially when you’re working with Wordpress as an example. It’s a framework where everything is so intertwined — frontend, backend, PHP, and so on — it’s not a clear set of backend classes and frontend code.

And so it gets hard to figure out where everyone’s strengths are. So what Brent was saying is, we did [the evaluations] and those are great to evaluate where you are as a whole. As in, as a junior level developer, will you be able to do these projects. But what we wanted to do is really isolate where people were strong and weak, so we can target those things for that person moving forward.

And that’s where we broke it up, and started to evaluate on specifically frontend tasks, specifically backend tasks, and then kind of hybrid full-stack tasks. That helped us to evaluate who was strongest in what area, and then what they needed to get better at individually.

Joe: Makes sense. Another thing that you mentioned in the blog post was learning to support people in their mentor roles. I think it’s interesting, because I think we forget that sometimes. That it’s not the same skill as doing engineering. Could you talk a little bit about what kind of support they needed, and what they responded well to?

Derek: Yeah, it’s important to lay foundations and principles for how to support somebody, right? Because engineers haven’t typically done that. For instance, I went to journalism school — a really great journalism school at University of Missouri. And almost everybody that taught me was somebody from the field. Some great award winning journalist.

Half of them were awesome professors because they were smart and had all these great experiences. Half of them weren’t because they weren’t teachers. They weren’t people that could actually convey their knowledge. So, with us it was really the reason and the impetus for bringing Brent in as a really early hire in a thirty person company. Because we realized that doing isn’t always the same as teaching. And education is a really valuable resource, and if you want to double down on it, you can’t just do it by talking. You need to make some smart targeted investments in that area.

So, I have a simple answer to that, which is that’s why Brent is here. That’s why we have a Director of Education, whose life has been devoted to education, so that we can support how to actually convey all this smart stuff that we’re doing and how we bring people up to speed.

Brent: The only thing I would add there would be that the thing we’ve learned was the difference between teaching and mentoring. I think a lot of our engineers, certainly John and François, were pretty well prepared to mentor because they’ve had to already. A lot of our engineers here have been here for a while, and worked together. You see them sitting there asking questions back and forth all day.

But teaching a group of three or more at a time is a different thing. Learning to structure a session. What we can do with a group of folks, versus what we can’t. I think those are the things that over time we’ve had to get better with.

Derek: And we’re still learning that.

John: Yeah, I mean when for several years I was the only engineer here. A long time ago, but I was the only engineer. Every engineer that’s come through here since then, I’ve probably had some role teaching them. Sometimes a lot, sometimes a little, but something. And mentoring.

So, I knew how to mentor and teach in those informal environments easily. But it’s a totally different thing to do a lesson with a group of people, and being able to move forward. And making it easy to consume whenever you can’t go hands on with every person in the group. I think that’s where Brent became super valuable for the mentors specifically. Teaching us how to do that and adjusting how we work. Just tweaking what we thought would be right, and getting it all finely tuned.

Joe: It seems like the experience of teaching makes it possible to take somebody who’s going to be even more junior. But it makes sense that when it’s more junior and a larger group.

John: Exactly, that’s the thing.

Joe: You had three in your original class?

John: Yeah, three.

Brent: But it gets even bigger sometimes. We had a session teaching git to engineers…

John: Yeah, sorry, there’s three apprentices, but oftentimes our classes would have all our engineers in there.

Joe: Oh cool. So, using that opportunity to bring other people up.

John: Yeah, we’d bring other people in, because there are other things where everyone has their own specialty or experience. And so a lot of those classes were valuable for full-timers as well.

Derek: And as you’re talking through the value of programs like this, I think that’s a huge one that we somewhat expected but got even more value out of it than expected. Which is that it causes some self-analysis about best practices. And causes you to get your own stuff together because you’re going to be teaching it. You can’t teach proper usage for internal git if everyone works differently.

Joe: *laughing* If you don’t have a proper process.

Derek: Yeah. So there’s a quality assurance aspect of this. That I think is super important and I think is one of the best values we got out of it. Causing us to do some introspection about the best way to do things.

Joe: Are there other lessons that you learned in the process of running this first class? Things you think you might adjust a little bit in the future when you run another class like this?

Brent: We went through a pretty good process at the end, with the engineers and Ted and Derek, and the apprentices. I’ll tell you one thing; it’ll be great to have someone who was an apprentice already.

In terms of the way we think about it slightly differently in the future. I think we have significantly more clarity on exactly what we need from a candidate coming in and coming out. So I think that’s a huge change for us. And I think the shift to be more event-focused. Those would be two of the biggest changes from my end. I’m sure I’m forgetting one or two of the things we talked about…

John: Yeah, just focus in general. A piece of what we were trying to figure out was that a lot of these junior people come from bootcamp and so on. And we’re trying to figure out those gaps in things they didn’t pick up in their programs.

And we figured out that they’re good at one thing, whatever they were taught. But if you tell them “alright, I need you to go build a site from start to finish and launch it”, they have no idea. Most, typically, they can code the website, but they certainly can’t launch it. They usually have a harder time with frontend code than with backend code. Just little things here and there that you’ll find. So we’re trying to fill those gaps, and where we focus our program I think we’ll tweak slightly just to hit the right point in terms of what they need to learn to get to a point where they’re totally self sufficient.

I think we ended up focusing a little more strongly on backend development this time, and I think next time we’ll focus a little more on the frontend and javascript. Little tweaks like that; without going through it a few times it’s hard to know.

Derek: I think one of the biggest learnings for me is that a graduate from a bootcamp is very different from somebody who’s been tweaking stuff on their own on the side, or somebody who just graduated from a computer science degree but hasn’t built anything.

Joe: *laughing* Very different.

Derek: *laughing* But they’re all very different, and so a typical junior engineer who comes in here before this is somebody who’s done a lot of HTML and CSS, has sort of learned frontend, has built a site for themselves, and is now looking to learn more of the backend. Bootcamp is very interesting because it’s the exact opposite.

They can do some really refined and impressive things with APIs, with custom backend frameworks, with ruby or whatever it is. But they need to be brought up to speed on a lot of the stuff that I did when I was learning. You have to make sure that it’s tailored to somebody’s background, because people aren’t one thing, right? People have very different backgrounds.

John: I always under the assumption that you learned HTML first, and then you learned CSS, and then you dived into all these other things. The backend, the server side languages, but it’s just not true for a lot of people. So we had to…

Joe: I know a lot of bootcamps start on just plain ruby, not even frameworks.

Derek: Isn’t that funny?

Joe: Yeah. I think it makes sense in the context of… “this is an if/else statement, this is a loop”.

John: Kind of universal programming stuff. Very little markup. And most people you’d think they’d learn markup first. That’s just how they did it. In junior high I took markup class.

Joe: I think we may have started in a different era of the internet….

Derek: *laughing* And that’s fine. I think the big gap right now is that there are a lot of people who are interested in the frontend. And there’s a big gap between that aspect and the engineering people. And bootcamps are filling that gap and getting more people to be interested in that part, I think that’s a great thing. It’s just different than what we expected.

Joe: So, last question. What does the future of the program look like?

Brent: I think the thoughts about Clique U come from some of the things we did well in the apprenticeship. And have gone well in Clique U in general. And some of the things we learned we didn’t do well and maybe needed to change. And literally some product-market fit kind of stuff. And when I look at the future and when I talk to you and François about what we need, and the business needs. It seems like two things are clear.

One, having a little bit less structured monolith program is going to be part of the next iteration of the program on the apprenticeship side. What that turns into we don’t know, but I think it’ll be a little bit less structured. And that’s responding to what Derek and John were saying about not knowing what the input is going to be. If you don’t know what the puzzle pieces are, you’re not going to be able to put the puzzle together.

Joe: You’re not sure where you’re starting…

Brett: Exactly! So that’s a thing for us. And the other thing is that we see out in the ecosystem is that there are a lot of people that need. There’s all these people coming out of bootcamps, and there just aren’t enough ways to ladder up to level two. And I think that took us to what I think we’ll try more in next quarter or so, which are more series of trainings. We’re getting ready to do a Node workshop with the Startup Institute. Specific tools that we use, whether it’s a framework we’ve developed (clique.ui) or whatever. But a short burst of things will I think be the next iteration. And depending on how that goes, then I think three six, months down the road when we have the hiring need (which is a thing we didn’t focus on quite enough), then we look at “okay, do we consider the full apprenticeship in the same version again”? Or what does that become?

There’s definitely a step in-between, which is exploring the external ecosystem more. Because in a perfect world, we’d find a way to marry the external ecosystem with apprenticeship, which is great both for them in terms of job preparation, but is also better for us in terms of prepation for them.

Derek: The last thing I would add is that where we are now for at least the next month or two or three, is responding to some thoughts that we had during the apprenticeship program. We had three people in a room learning a frontend framework, or learning git, or learning how to deploy something to a server. And every time I saw that room, I go “there are hundreds or thousands of people in Chicago who could benefit from this. Why are we doing it in this small room?” Right?

And as a company, we’re all very very big believers that the smartest people in a generation should be making stuff. They should be inventors, they should be engineers. They shouldn’t be people who sit in meetings all day. They should be creating stuff. So we’re passionate believers that more people should be joining this ecosystem. And should be joining this evolution, or revolution, or whatever you want to call it in Chicago, of tech becoming a major player.

So to us, we were saying “How can we expand all those learnings, and expand that impact, and try to convince as many smart people that this is the industry for you because you can be creating things.” Because that’s the core driver behind all this.

John: Yeah, that sounds good.

Joe: *laughing* “Ditto”. Awesome, well thanks so much for taking the time to talk.

All: Thanks.