Empowering Our Teams With The Right Tools, With Amjad Masad

Welcome to Scaling Software Teams.

‍

Today, our guest is Amjad Masad, founder and engineer at Repl.it – a programming platform designed to give developers the tools they need to improve their skills, and create even better products.

‍

Amjad’s engineering career began all the way back in the early 1990s, when he built his first application to help teach math to his siblings. In the many years since those first applications, he’s worked for some of America’s most recognizable technology companies – from Yahoo! to Codeacademy to Facebook.

‍

But while that background could have given Amjad a perspective on engineering that prioritizes pedigree and experience… he’s ended up taking the opposite approach when it comes to hiring at Repl.it, valuing talent” “discovery” over “acquisition.”

‍

We explored this concept along with many others in our interview with Amjad – including how he’s overcome the nagging need for “perfection” in software shipping, what he believes makes a great manager, and where he sees the future of engineering work going in the years to come.

‍

[Listen to the full interview here]

Wes: So what got you into building software originally?

Amjad: “I was lucky to get into it really early on. The first time I interacted with the computer, I was six years old. That was 1993. My father brought in a computer (I don’t actually remember the exact model but I feel like it might’ve been an IBM) and it had DOS on it. I sort of started peeking behind his back as he was trying to learn it… and kind of struggling with it.

‍

I remember every night he was fascinated by it, but he really didn’t have the skills to know how to operate it. I’d go in after he’d leave and I’d start tinkering. At first I learned a little bit of kind of DOS commands and how to create directories and delete directories and things like that, along with how to launch games. Later on, I got my start in BASIC.

‍

Before BASIC, there was a visual programming environment. We went to this computer show where I’m from in Jordan. There was this yearly computer show where you go and people are showing the latest computer technology. CDs had just came out and we had a CD driver, and my father and I were just walking around and I saw this collection of CDs in a box and it had a number of different softwares. I don’t know what attracted me to it. It had an accounting software and a few other boring things on it.

‍

Like what all 10 year olds love right?

Right! But one thing that was really cool about it was it had this visual programming environment. I remember booting it up and I immediately got it. I understood that there’s these logic operators – these different blocks that execute code on different events.

‍

I sat down and the first thing I built was a game to teach math to my younger brother (who by the way currently works with me at Repl.it). So I made a program where it gave you an equation, but it just had one part of the equation – it could be X plus 10 equals 19. And he had to guess that “X was nine” and then [if he got it right] it would clap – it would make some sound of clapping for you. And that was really when it clicked… this is like an insanely powerful medium and I can make a lot of things on it.

‍

And then, fast forward to when I really built my first large software that had users, it was when I was 15 years old and I built an application on visual BASIC.

‍

The first program I built was a gas calculation program. Similar story for me. It was for my parents. I didn’t even have a car. It was just like nothing. I think it was in a Kerning and Ritchie C book. The idea was that we would have multiple people, we got a distance, and we figured out how to split the trip cost.

Did you have users? Anyone who used it?

‍

It was command line so I had a friend of mine go in and enter stuff – so one user but that was it.

That’s the most exciting and frightening thing is like when you get to your first user ever. You might be scarred for life because you might have had an input that that accepts numbers and then someone puts a character and you’re like… what? What the hell?! What is this?! What are you doing? It’s like you’re not supposed to do that! And that’s how software engineers become paranoid. [Laughs]

‍

I think that’s that’s a very useful paranoia. I’ll do a lot of user testing, where as you’re building new releases you bring in users to to try out Repl.it and see the new changes.  

We’ve taken a little bit of a different approach and tried to have users as part of our design process.

‍

We have a large beta group that tests our programs and we have we have different chat rooms with different groups of users. So we have a chat room with our developers and we have a chat room with our teachers…. There’s like a wide array of users and use cases, and so for every one of those we get feedback early on.

‍

Sometimes I’ll post a mock-up and chat room and see what they think about it. Sometimes I’ll hop on a Multiplayer session with them – so for example Multiplayer is our collaborative coding feature, so you can turn it on for any environment [that] their output supports. And so that’s been like sort of a boon for user testing because I can jump in and and test some new feature rebuilding live with the users. Sometimes I see our developers pace a live session on Discord, and I’ll just kind of lurk and see how they’re using it – how they’re collaborating. And we don’t have a process per se – it’s part of the DNA of the company; users are part of the process. You know we couldn’t have gotten this far without this sort of participatory design.

‍

Can you think of an example where you came with a design that you thought was great and then the users came in and now your design is much better?

We’ve had a few design decisions at first that weren’t that obvious… for example, we weren’t convinced that chat was needed [in Multiplayer]; people use Discord and Slack. And then when we saw users use it, they were chatting in the comments that they had a big common block up on the file and they were chatting about it. So that’s obviously the best feedback you’d get is when people hack your product to do something it wasn’t intended to do.

‍

Because, you know, it’s kind of a cliche now in tech that users don’t know what they want. There’s that famous [Henry] Ford quote, “If I had asked people what they wanted they would say faster horses – they wouldn’t have suggested a car.” And it’s a cliche because there’s some truth to it, right? If you look at the literature and economics there’s this idea of “revealed preference” versus “professed preference” – people say one thing, but generally do a different thing under the circumstances. So people are bad at predicting their own behavior, so what you want to do is you want to see their behavior. In our case, we saw that behavior and that was a very sort of in your face… like…  yes we need to we need to fix this. We need to add this…

‍

The thing about that Henry Ford quote that always gets me is… they told you they wanted speed! They wanted to go faster! I’m glad I talk to my users. [Laughs]

So I think some people – especially in Silicon Valley –  take that quote to the extreme. You need to look to users for your data – you’re not looking for suggestions. You’re looking for data.

‍

I’m a leader and I feel like I’m failing constantly at lots of things so that I can kind of not fail at one or two things. Sometimes I don’t ship and I think it’s a lot of what you write about on perfectionism. How do you fight that urge?

I think perfectionism is masking a lot of different emotions underneath it. It’s rare that someone is truly a perfectionist. I think most of the time it’s masking some negative emotions.

‍

I think most prominently is fear – the fear of being criticized. You don’t want to ship and you hide under that perfectionism because you’re afraid of getting negative feedback. Another one is embarrassment. You don’t want to ship something because you’re a little bit embarrassed by it, right? Then there’s that famous Reid Hoffman quote where if you ship something that you’re not embarrassed by, you’ve shipped too late. There’s a lot of truth to that.

‍

And so you want to fix those underlying emotions, and I haven’t looked at my post in a while, but I think I talk about exposure therapy. I think the larger point here is being a creator, being a founder, or being an entrepreneur – the biggest bottleneck tends to be your own sort of emotions, your own mental state, or your own psychology. And I use my blog as an outlet to do self-debugging in that sense. When I wanted to debug perfectionism I tried to break it down to its underlying components, and one of them I detected – and the biggest one I think – is fear, and the way I would treat that is by shipping a bunch of things. There’s been this trend where people have this “100 Days of Coding” and every day they ship a website. I’m not sure if you’ve seen that?

‍

Yeah! I’ve seen people post about their websites.

Yeah! They’ve built a hundred sites in a hundred days. And at the end you’ve just kind annihilated that fear that you might have from shipping or embarrassment.

‍

So I would treat perfectionism that way. Now, in some cases you might actually want to go to full way, right? [At Repl.it] we have this 80/20 rule; you can get 80% of the benefit with 20% of the work – but sometimes you actually have to get to 100%. Sometimes like if you’re entering a market where it’s already very advanced and you’re building a product in that market, you might want to try as much as possible to perfect it, because people will have a certain set expectations [around that product].

‍

But most of the time, maybe 80-90% of the time, you’re creating something new and people are gonna be fine if it’s like a little bit janky and not polished.

‍

What’s something recently that you shipped that you were just a little bit embarrassed about?  You saw the hundred percent and you weren’t there, but you knew the right move was it shipped 80 percent.

Yeah I mean that there’s so many. [Laughs] I would say by the time this podcast is out we’re gonna have shipped [one example of our 80/20 rule].

‍

We’ve been working on a way to do graphics. Not just like web graphics – any type of graphics. Like you can write a pi game application, you can write an array tracer in Haskell and it will render in the browser; it’s a pretty ambitious project. And we’ve been doing research and development on it for three or four months – if not more. We’ve had three different approaches to the technology and all three sort of worked, and that’s the worst place you want to be… because you want to have some redundancy, and then one of them works, and it’s great! But for us all three had some suboptimal parts to them. We picked the one that we thought we could polish as soon as possible and just ship it.

‍

I told my team that we just have to ship, and in the beta it’s a little bit janky – but I think once we get feedback and address the “needs” that exist out there, I think people will be happy with it.

‍

It’s sort of already leaked that we’re working on this and I’m getting emails from people, like, “Hey I want to be able to try it.” I’ll give them the link to the Alpha and they will still like put hours in to make it work even though it’s very buggy. So a lot of times in your mind you’re like, “No I don’t want to release this because it’s buggy.” But one of our recent hires mentioned this to me the other day – we need to think about the delta and utility that we’re providing people.

‍

The perfect product feature will, let’s say, bring about an 80% increase in utility for whatever you measure. But if the sort of janky, slightly embarrassing feature is still going to add 50% then you should ship it, right? And there’s also the law of diminishing returns; the more you try to perfect it, the less utility you’re adding to your user. Ultimately you want to go back and fix and polish things – I think the graphics that will go out in a week or two is probably going to be a little bit janky at first  – but I think we’re going to have to deal with it. If you want I can give an example of a thing that we sort of fretted and tried to get as as perfect as possible?

‍

Yeah! Was that because of the delta? He felt like it needed more perfection- versus zero for something else?

Yes. So in this case we’re working on our creation flow.

‍

When you create a new Repl we dump you into this big languages page and you have to kind of look at all the languages and pick one. We are coming up with a better creation flow where you have the option after you import from GitHub, you can name your Repl – you can do all this upfront work. It’s kind of like creating a repo in GitHub. And this is going to be in the critical path for everyone using the product. This will have 100% exposure on our users. This is going to be in the path where people have the most muscle memory, so you can’t iterate on that too much because people are going to be annoyed all the time.

‍

Like I remember once [Twitter] added moments instead of search and I kept clicking on “Moments” by mistake and I was so annoyed. So anything that has to do with muscle memory, or that people have been used to it for a long time, you really want to be as careful as possible when you’re changing it. You contrast that with something you’re creating that’s new, because when it’s new, then people will tolerate change because they understand it’s new and it’s going to go through some iterations.

‍

If my alternative is figure out how to install pi again locally and get it to work with everything to be able to do any graphics, I’m probably more likely to put up with some bugs in the version. That makes perfect sense!

I think developers tooling mostly still sucks. What’s going to change about our industry as that gets better?

‍

It’s an interesting question to ponder. We’re in one of the highest leveraged, most expensive jobs on the planet, but we’re seeing underinvestment in tooling within it. Maybe an economist could do a study on why it is companies haven’t invested in and developed tooling? Like for most companies, a hiring manager will get a new engineer and they have a choice between assigning them to build tools for other engineers in the company, or putting them on a product or a feature. They usually go with the latter. They tend to put them on a product or feature. Why is that?

‍

I think one of the reasons is the measurement problem. This has been discussed since the early days of software engineering, most famously in Man Month where they talk about what the optimal measure for engineering productivity?

‍

They look at lines of code and they see really bad measures, but don’t really have a good measure. Therefore, it’s something that’s really hard to optimize – so that’s why I think the state of software engineering kind of sucks in terms of tools. So, how does it get better? I think people are starting to wake up to the idea that investing in tools has an outsized effect. If you have a company with 10000 engineers and you have an engineer that could increase productivity by 0.1%, they’ve already created outsized returns on your investment. So there is some evidence and I think we’re going to see more investment in this space.

‍

So if I’m an engineering manager and I have some ability to allocate this focus towards tooling versus features, what are some heuristics that I might use to make that right decision? Because I’ve got a product manager, I’ve got someone looking for new features, I’ve got revenue goals – how I can thread that needle?

It’s going to be more art than science. So I’ll just say that upfront there’s gonna be some trial and error. I would say the first thing is sort of perk up your ears and listen to your engineers. Let’s say you’re building a web app – are your engineers having to fiddle with web pack, are they testing tools all the time? Are they having to dive in and upgrade the versions, and losing a week of productivity? Are they complaining about the compile cycle? You want to hear those [complaints] out, don’t disregard them as just “engineers doing their usual complaining.”

‍

But then you need to also think about the fact that not everyone will be a good developer tools engineer, just like not everyone can be a good product engineer. Product engineers have good product sensibilities and they know what users want – so they can sort of think through that.

‍

Same thing with developer tools engineer; they’re usually very passionate about tools, and they’re usually filled with ideas about how things could get better. So don’t pre-allocate that.

‍

At Facebook we had this group called Product Infrastructure. I think there’s been a lot of re-orging at Facebook so I don’t know if it’s still there, but when I was there that team was kind of small, and they had this rule that you can’t join the team unless you spend at least a year on product.

‍

And so that was a very good rule because you can go interview with them, and say “I know what it’s like to build applications at Facebook and I think I can make it much better – here are my ideas.” So you’re gonna have these developer tool people already filled with ideas.

‍

You want to pay attention not to hire “architecture astronauts” – people that add complexity for no reason – and there’s a lot of people like that in the dev tools space. They just want to toy with things, but that’s not the right way to go at it. So I’d say hire or allocate from within, and look for someone who’s already vocal, already doing the job, other people rely on them for that. And then maybe just give them more time to do that.

‍

And if you’re seeing returns on investment, other engineers are being productive, then maybe you put it more into that. So I would say approach it empirically, organically, and with time.

‍

What’s a belief about leading software teams that younger Amjad would probably disagree with?

That managers are a good thing [Laughs]. So, like every like every hacker I had this sort of anarchist view of management – that managers are a waste of oxygen in organizations. I think a lot of engineers think that way. And you’ve had sort of colossal failures where companies try to adopt that mindset on a massive level.

‍

So what changed your mind about the value of managers? What teams what changed your mind?

Being at startups with no managers, being unhappy without anyone to talk to, and not being able to influence decisions. I’ve seen the chaos and the clique behavior that emerges with no managers; people start gossiping and all the bad things about groups of people start to emerge.

‍

But really what really convinced me was having a good manager at Facebook: Tom Aquino, who managed the react team.

‍

I felt much more productive talking to him and I felt [my view of] the relationship changed. Instead of this authoritarian view of management it was more like, “This is a person that’s helping me be productive, that’s helping me solve problems, that’s helping me communicate better, that’s coaching me through rough periods – and this view of management made it less about authority and less about “being the boss” and more about efficiency and productivity increasing communication flow. You’re breaking down silos, and leaders need to make sure they have a good sense of the “heartbeat” of the organization.

‍

What are some things you’ve borrowed from Tom?

Being non compromising with performance, but at the same time, being kind. You want to push people to do the best job that they can do. But don’t lose the kindness and don’t lose that human connection and understanding. I think this was probably one of my biggest takeaways.

‍

If you had a magic wand and you could spread one idea out there that would improve hiring – get one idea out into the Zeitgeist that developer managers could know would make hiring better for everyone… what would be that idea?

I think people should pay more attention to talent discovery, rather than talent acquisition.

‍

Start-ups, especially – and I think that’s where most of my experience is but it also applies to bigger companies – I think we tend to get stuck in our own bubble, and we look at people’s resume, and we want to see all these big names and big universities. Talent is everywhere, but opportunity is not. I would say the upside of discovering talent is huge.

‍

At Repl.it, our first hire was 19 years old. He had dropped out of college and he wanted to break into the San Francisco tech scene. He went to Hack Reactor, which was was one of our users, and we found him through them. We hired him and he is now indispensable – he’s one of the biggest drivers of invention at the company, and is creating a lot of the new products and ideas.

‍

I did that multiple times, and when you discover talent usually you can also coach them in a way that allows them to have the most impact on your company, and on the world. I’ve done that before at Facebook, as well; I discovered talent from different parts of the world, and recruited them to our team. And Facebook being a little bit more forgiving, not requiring a lot of credentials and being more merit-based helped.

‍

So I’ve had good luck with this before and I think it’s not only good for the companies, it’s also good for economic growth – it’s good for giving more people a chance. I had a Tweet this morning about how the startup scene in Silicon Valley is one of the most open to outsiders, and a big part of what makes it open is that a lot of startups know that they’re in the business of talent discovery. So let’s try to grow people. Believe me: it’s gonna be worth your time.

‍

I want to get better at discovering people, as well. I don’t know how we do it – maybe Repl.it is a good vehicle for that, as well. But I feel like there’s so much that we could do in terms of making hiring better and faster if we just didn’t focus on the creme de la creme at the top of the top.

‍

So if I find an engineering manager and I believe that talent is evenly distributed, but that opportunity is not, what are some steps I could take to help my organization get better at discovering talent rather than just looking for credentials on resumes?

You’re going to see a lot of resume is that you might disregard, and it just takes a moment to not disregard it [and give it a chance]. If you don’t see any of the big names on the resume still give them a chance!

‍

Look at their GitHub look at their creations, if they’re an engineer they’re probably on different places – increasingly Repl.it. Look at what they’ve made, don’t immediately jump to the “prestige” because prestige doesn’t matter anymore. The big schools don’t matter anymore, and I think we’re seeing a big change now. Lambda School has been in the news a lot. Are you familiar with it?

‍

I am a big fan of Lambda School.

Yeah. So Lambda School – nine months, coding bootcamp, no fees, just an income sharing agreement. You kind of kick back after you get your first first job. And the stories that are coming out of that of people kind of changing their lives – going from working as bodyguards in some cases to making $200,000 dollars a year as software engineers. So that’s that’s one way you can partner with these organizations.

‍

Don’t disregard resumes – maybe have some outreach groups, sponsor some diversity hackathons – there are a lot of initiatives now where you can go look for people. Just be open.

‍

I think also being a remote-friendly company helps a lot, [because] some people can’t move. I feel a little like a hypocrite saying that because we haven’t been so remote friendly, but we’re starting to now; we’re hiring our first remote person and hopefully we’ll get even better at that.

‍

But the world is an increasingly online world, and so this is one of the steps that you can use to discover and acquire talents that might not be discovered otherwise. It’s a big world. There’s lots of talented folks out there. They’re not all in San Francisco yet.

‍

So let’s move on to the rapid fire round. I’ll ask a question and you give your quick response. Ready?

Yep.

‍

What’s the most impressive thing a candidate has done an interview that helps you realize they were a good fit?

They are able to dive as deep as I can ask them about the problems that they’re solving. Just like no limit.

‍

I usually ask questions about the stuff that they’ve made and so I’m gonna keep asking you to go deeper and deeper and deeper. Some people get annoyed and angry, but if you were able to kind of do that then I know that you’ve thought of this problem in and out and you’ve solved it by yourself, and that’s really impressive to me.

‍

What’s a mistake you’ve seen an engineering candidate make during the interview that they maybe didn’t realize they were making?

I think ego sometimes gets in the way. As a hiring manager and as an interviewer, you’re going to be kind and sensitive but you’re trying to get at the depth of the problem.

‍

Some people get annoyed by that, and feel slighted. I’ve seen people’s egos turn up in these situations, and I think a lot of otherwise good candidates would probably be disregarded because they’ve had some kind of ego problem.

‍

Which matters more when hiring: hard technical skills or soft catalytic skills?

I think it depends on the person. I think 10X engineers – I believe in them by the way which might be a controversial thing – but I think they come in different flavors. I think there are 10X engineers that are connectors; that bring different parts of the company together. There are 10X engineers that are purely individual contributors who go in and hack and create new systems. There are 10X engineers that are able to discover new products and features  – maybe they’re just really good at ideas.

‍

They are so many flavors of really good engineers, and so finding your niche is worthwhile. Keep asking yourself: what is my superpower?

‍

What does a six star culture fit look like at Repl.it?

Six star?

‍

Meaning even better than five star.

Inventive. They would continue to impress us.

‍

We have a culture of impressing each other, which I think it is really awesome. Someone makes something on the weekend, or some day. The next day they’ll show it to us, and our minds are blown, and their respect has gone through the roof in the organization to have a lot more clout now – and other people want to top that.

‍

And so you have this nice competitive edge. When people are competitive, inventive, but also collaborative and kind and inclusive – that’s hard to come by because sometimes people who are you in the weeds might lack some of the collaborative aspects. And this goes back to discovering talents and growing talent – this is an area that I’m willing to work with people.

‍

I’m describing the six star person – I don’t think we can find people like that.

‍

But if we hit a few of those properties then I’m willing to work on the other properties with them; I’m willing to grow them into that person.

‍