The Learning Compact We've Broken

When I started working at mFoundry, I had never worked with software engineers before. I had worked at a friend of the family’s software company as a gopher for a summer in high school but that’s as far as I had ever gotten in the software world.

So it wasn’t surprising to me when I met the engineering team that I was going to be working with and finding that three of the six of them were fresh out of college - like this was their first “adult” job ever.

And the three that weren’t straight of out school? They were still younger than me, and I wasn’t exactly old (I hadn’t even hit 30 yet).

Initially, I thought that this was just “how it was” because I didn’t know any better. But then as we continued to grow as a company and build our vision for what our teams looked like, it became more apparent to me that it was very deliberately built!

Subscribe now

The value prop was mutually beneficial so no one felt like they were losing, and both parties felt a little like they were getting away with something.

The company got cheaper labor than market rates from the kids straight out of school, and the kids got a very competitive new grad salary that made the transition to adult life much easier!

Additionally, because we were all expecting these kids out of school to be very green, we could be a little more lenient while ALSO being quick to identify talent. And that talent was identified even MORE quickly because the kids coming in were constantly making mistakes. And instead of us as leaders making snap judgements that the mistakes were indicative of the talent of the individuals, we could step back and instead work on how quickly they learned from their mistakes. How well did they take in the lessons of failure. What adjustments did they make based on their past success or failure.

That feedback loop was invaluable. Because it was lacking in judgement (negative) (I put negative in the parentheses because my fantasy football podcast loves using words then telling you the connotation right after, because sometimes someone can be talented and you mean it positively and sometimes you mean it as “has potential but it’s not manifesting” so it’s negative! Anyway that’s just a fun aside for me because why the hell not lol)! We were creating psychological safety for our team before we were smart enough to know it was a thing let alone why it was important.

So how did people differentiate themselves under this system?

It was all about the cadences of our work creating fast reacting feedback loops. So when we start a sprint, the engineers have to sign up for specific work items, that amount to a certain number of points, and I’d look at a couple of different things to see how someone was progressing.

Speed in picking up storiesThis is much more about confidence than it is about ability. You can’t just look at a new engineer taking on a ton of stories and saying “that person is gonna be a rock star”. But it’s a feedback element for you as a leader. It’s one of many inputs that alone means nothing to me, but when I couple it with the other elements, it becomes impactful

Are they hitting their sprint goals?

Paired with speed in picking up stories now we can start creating a narrative. Is the developer picking up a ton of stories but never finishing everything they picked up? Are they only taking on a few story points, but then always finishing them and picking up additional work off the backlog? Do they know their own abilities and hit the mark perfectly every week (and if they are, is it because they’re grinding and working their ass off to hit the mark or are they knowing they can do more but only picking up some stories so that they can coast a bit)

Code Quality

This is an obvious one, but still important — how good is their code?! Working code is always great, but is it working because it is a hacky mess and they got there but it’s a house of cards ready to topple at the slightest strain? Or is it sustainable code? Or is it a simpler solution than you expected? A more complicated solution than you expected? Do they understand the fundamentals? This is why code reviews and pair programming are critical especially for junior devs, because it’s where they learn the expectations.

Attitude

This one is subjective and team based. Partly this is just a “vibe check”. Some people are incredibly talented, but terrible team mates. Some people are lacking in talent, but are always there to help and step in. Some people are some weirdo combination of the two and you want to slap them because they seem too perfect. And sometimes you just can tell that they might be a great person, but their vibe doesn’t fit with the team dynamic and you need to try them on another team.

This obviously isn’t exhaustive as a list, but it DOES have some commonalities that I find to be obvious that may not be.

Every one of these, requires a human who is knowledgable and curious who is observing and actively mentoring these junior engineers.

This is illustrative of the trade off that we used to have in our industry - yes when you’re a junior engineer you will be underpaid compared to the other engineers in the company. And in return, we will train you. We will put you through the wringer and you’ll come out a professional who can be successful. We will put in the effort to ensure that you have all the tools needed to learn and grow.

But I’m not here to talk about the glorious past right, I’m here to talk about the here and now - and the fact that we’ve explicitly broken that compact.

What we used to have was a clear path to move from a newbie to a seasoned vet who could train the new crop of newbies, creating a feedback loop that rewarded those who provided the most value. It wasn’t perfect, but no system ever is. But it served a useful purpose and did as best we could to support people at different stages of their careers.

But, we’ve been trending further and further from that mutually beneficial value proposition.

First (and yes I realize this isn’t a recent trend, it’s ongoing but it’s just one of the many proof points in my argument), is that we realized we could get significantly cheaper labor outside of the US. That drop off in costs also meant some level of drop off in either skill, or communication, or time zone adaptability, etc.

And so we started finding developers in India who were less costly, but it meant that they needed to stay up all night working US hours, or that we would just have a hand off that then got reviewed each day and created a lot of inefficiency.

Then we tried moving to other parts of the world, whether it’s South America which lines up nicely with a lot of our time zones, but the costs were higher than in India and the outcomes were a little better due to those time zone alignments (there was also additional language gaps that were more onerous to overcome), then we also tried eastern Europe for folks on the east coast of the United States, which works well and they have great skill but again language barriers are more prevalent.

But, this moved the costs of those junior devs who are just learning to other locale’s where you could get a senior dev at 1/3 of the cost! So why invest in talent here when we can get it cheaper somewhere else!

Then we also bought into remote work, but didn’t set up good systems for developers to still learn from one another. We had stack overflow, and we had our “productivity tools” that allowed us to collaborate remotely… but we didn’t set up clear paired programming expectations, or create buddy systems, or do any of the soft skills work that’s needed for young developers right out of school! We essentially threw them to the wolves in their living rooms and shipped them a laptop hoping that’d be enough.

Don’t get me wrong here… I’m not advocating for doing away with remote work. It’s exactly the opposite - I think remote work is the future and present and simply needs more opportunities to show how we can collaborate effectively across space, and the best way to do that is to create systems that your team can take advantage of!

And then finally, we added on top of that every AI assistant we could get our hands on. Making it so that the mundane and annoying became tasks for the AI to handle. Robbing people of the pain that comes from learning something new or solving a problem that you barely understand. Instead, we let AI hold your hand and walk you through it, without earning the knowledge for yourself, making it so that you won’t know how to do it in the future, you’ll just reach out to AI and hope it knows what to do.

And it might! Honestly, it might get to the point where it can do the development as well as a junior dev or even a senior dev. Hell it might already do that today.

But the point isn’t “can it create the code”. We’re not just chasing development solutions here. We’re chasing after knowledge, experience, and a point of view. What good is a developer who simply says “yes sir” whenever you make a request? They are there for their skill, their expertise, and their ability to identify when things will likely go wrong.

Don’t get me wrong, having new tools, having new ways of working, hell creating new social compacts, all of those are potentially very good outcomes! I use AI all the time. I wrote the outline for this article with my good buddy Claude. I use CoPilot to help me to write up a weekly report of what I accomplished and what’s upcoming. I even used AI to build out prototypes and ask it questions about code. I also am a part of a team that explicitly is filled with experienced vets and we have no newbies on the team.

So my point isn’t “we should go back to the old way of doing things” at all. It’s that the old way of doing things was purposeful and thoughtful and had achievable goals and expectations.

Our new way of working is nothing short of “how can I extract the most value I can out of my employees before they can’t stand being here any more”. And that’s a huge problem. We are so focused on people who already have the right skill sets, already have the industry knowledge, already have the hands on keyboard experience, already have blah blah blah.

And we ignore the future we’re creating.

For instance, my kids have no idea how a computer works. At their age, we were playing with floppy drives, learning about water cooling, overclocking our CPUs and doing all sorts of weird shit just to see if we could. But where’s the encouragement being given to try something and fail?

As Yoda told Luke in The Last Jedi (jfc if you all make this a referrendum on that movie I’ll sit down and cry lol — I for one love it, if you don’t whatever, this quote is still a bar) “The greatest teacher failure is”. And it’s true. The best lessons I’ve learned are when I screwed up.

But we’re not giving people the room to do it. We’re not creating psychologically safe work environments because we’re SO focused on the bottom line. When did making the shareholders an extra 13 cents on their share price become more important than teaching our workforce how to learn and adapt and take advantage of all the new and exciting tools that are coming our way?

And the story I’m telling myself in this moment is, bro you sound like an old man yelling at the sea. You gotta take a chill pill, and just let this thing play out, I’m sure that other people thought that the old system was fucked and that we were failing the next generation of developers 15 years ago too.

That story might be right. I dunno. I’m not a fortune teller, and if I could see the future, let’s be real you’d never hear from me again lol. I’d live happily ever after with a dozen animals and my family and just live a quiet life because that sounds amazing right now.

But I can’t see the future.

All I can see is my past and present. And the lessons that I’ve learned are that failure and growth go hand in hand. And without opportunity you can’t fail. And we’re not providing the opportunities to the next generation the way that we were provided them.

My way of trying to change the dynamic is to focus on what I’ve always focused on… teams. We aren’t going to make changes from the top down. We’ve seen over the last decade that the top down dynamic is starting to crumble. So instead we start where we can with the teams that we are a part of. And we need to start bringing in more voices and creating more opportunity.

I know we all get comfortable surrounding ourselves with the people we know and trust already, but the way they BECAME those people is by giving them opportunities and seeing what they did.

My challenge to myself, and challenge to all of you, is to look at the people you put on teams, and question - am I creating this group because I’m afraid of failure, or because I’m trying to create something special in the future.

I’m going to try and lean more into learning, and empower the future of our industry; what are you going to do?