Software systems to innovate and grow

Episode 42

Building a Compatible System Architecture and Company Organization: Bill Salak with Age of Learning

Show Details

In Bill Salak’s words, “Promoting career growth should not be an afterthought.” On today’s episode, Bill Salak shares the philosophy behind his approach to company architecture. As we get deeper into structural methods, Bill offers insight behind his controversial opinion on agile project management. Listen further as we get into the details of Bills method and how encouraging his team members to learn from interactions with one another helps to run a successful company.

Show Transcript

Carlos: Bill, it’s a pleasure to finally have you on the show. How are you doing today?

Bill: I’m doing great, Carlos. How are you?

Carlos: Doing well. Well, you and I have been working on getting you on the show for maybe a couple of weeks now. I’m really pumped for this episode because we’re going to talk about a couple of topics that you have a strong interest in and I think a lot of listeners and some people that I know might be very interested in this topic. So before we get to much in-depth into it though, how are you doing?

Bill: I’m doing great. Busy as usual, tons of stuff to do not enough time to do it.

Carlos: Well, I think that’s a common denominator amongst us. With that said, I think that’s a good way to introduce yourself to your audience. Bill, tell me a little bit about yourself and what you do at ABCmouse.

Bill: I’m the Senior Vice President of Technology at ABCmouse. I’ve been in this role for about two years. The company is actually Age of Learning. ABCmouse is our flagship product. We have multiple other products including some flagship products coming out right now. Anyway search for us,, is our website and you’ll find more than ABCmouse out there. Before my current role at Age of Learning, I was a VP of Engineering for about two years. And prior to that I work in consulting for about 16 years where I own three consulting companies was successful exit. I work at three other ones mainly focus on large scale mission critical projects, high visibility projects where scale mattered.

Carlos: So for those who maybe don’t have young children or maybe are not participant with the education world; tell us a little bit about ABCmouse in terms of what it is and I know that there are millions of users up by now. Tell us a little bit about that background.

Bill: ABCmouse is really interesting I would say early learning digital resource for children ages 2-8. It’s full curriculum. It’s a really fun interactive way for children to be introduced to new concepts as well as traditional concepts. We cover the gamut from reading and writing, to science, to even learning other languages.

Carlos: I mean, from that I know, you guys are also in China so it’s a global system by now.

Bill: Yeah, that’s right. We are teaching Chinese children how to read and write English, and speak English as well. It’s pretty amazing our reach.

Carlos: Well, as I always have told you, I am always impressed by what you guys are doing. With that said, I thank you for taking the time to chat with me about some of these topics. Well, today’s topic is, and I’m going to introduce at a very high level but the way that. Is your vision of reconciling system architecture and the company organization, I think that topic is very near and dear to your heart and how you’ve implemented or have worked to implement some of these principles at ABCmouse or as the company name is Age of Learning. But tell me a little bit about this concept. What is this concept about and why is it that important in today’s…

Bill: Let me start with full disclosure. None of these ideas are new. I am certainly interested in them and I think I have a take on some of the concepts and maybe take things a little bit further. But it’s sort of been the trend in the last three or four years to bring up Conway’s Law and discuss Conway’s Law. And for any listeners who don’t know Conway’s Law came three decades plus ago. It was a paper that was written and the thesis was that an organization design systems, they will design a system that will be a copy of the organization’s communication structure. So effectively stating that the way you organize your company will impact the way that your products are designed. This is something that in the technology world people see a direct correlation. There’s been definitely studies on this and that idea on one point are in the study that correlation. But this is a topic that has been trending out in the last three years or so. I’ve been seeing it on the conferences. And I’ve been really sort of fascinated with this because I see this. I’ve been seeing this for 20 years in my work, and taking it a step further there is sort of this additional correlation between the quality of engineers and the design patterns that you’ll see in the code base. I don’t want to say that that’s necessarily good or bad but there is a correlation.

Carlos: In broad strokes though, I just want to try to paint a perspective of it, so tell me a little bit about in practice. I know that we’re going to have many layers of what these looks in practice. So let’s try to think of what the broadest of them looks like. Just thinking of what this might look like is we need to be thinking of the way that we organize and build our teams in the same way that we expect our systems to look like, right? We want them to reflect. But in practice, how do you envision this from happening if you could. If you have an organization you have an x numbers of engineers, leads etc. How does it look from a high level in terms of structure?

Bill: Yeah. Well, that’s the big question. That’s the one that I think everybody needs to answer to themselves. I certainly have opinions, and I think it ultimately depends on the people and the company, and it depends on the processes and the management style of the company. But to kind of bring this to light for everybody listening, we’ll start with examples at the lowest level and I’d mention the correlation between the quality of engineers and the solutions or divine patterns from the code base. On the surface it’s not obvious. People may think like, “Oh, you got great engineers, you got great codes.” When you have engineers operating let’s say an intermediate plus level. You tend to get code solutions, code designs, actual design patterns implemented in code that are more complicated than they need to be. And this is all anecdotal evidence. This is all sort of the history of my career but I’m sure there is some people now going out. That’s what we’ve seen as well. It takes a very very senior developer or a very novice developer to sort of look at our problem and say, “What’s the simplest way to solve this problem?” and “What’s the least expensive way to solve this problem in terms of total cost of ownership of the code?” I guess in more real world terms if all you have is a hammer everything looks like a nail. So if you’re a JavaScript developer it’s easier for you to implement some transition or some effect in JavaScript than into CSS. You’re not thinking about the guy who’s going to come after you, or maybe a novice, or maybe isn’t a JavaScript guru, and think about, “Ok, well, I’m going to build this thing in the simplest way so the lowest level of skill that comes after me can maintain my code base.” These developers are probably thinking like I am a JavaScript guy, I know how to do this in JavaScript. I’m going to knock this out in 60 seconds moving on with my life, right? But then what you see overtime is a series of solutions in your code base which have raised the bar of skill to be able to maintain that code or modify that code. And that’s the problem that we see again at the intermediate sort of senior level. It’s really when you get above the senior level to the more experienced senior or you get below the intermediate to the guys who just don’t have those skills to be able to do it in a more specific way. That you get a more optimal solution that’s optimized for like entry level. Like you are using an entry level solution for entry level problem. That make sense?

Carlos: Yeah, and as you’re saying that, of course I think we spoke about this earlier. Of course brings me back to thinking of pros and cons, right? And I say cons not in way that I am sure that these things are cons but potential cons. Let’s start with, just so we could leave the best for last, let’s start with the cons. Let’s start with some of the pushback that we might get from this because from what you’re saying, just to the way that I would think about this is. In my world, I would think like, let’s say we’re building an Angular application or let’s say our system is Angular based. I’ll just give you an example, we have 20 developers and this is a large system at scale. The way that I am kind of translating what you’re saying is not everybody needs to be an Angular developer so we’re going to architect things in a certain way to allow non-Angular developers to do their work without them having to write code at a higher level. It’s a good thing because you can hire for those roles but at the same time how do you balance out the growth paths? And I know that this is also a benefit like some of the benefits of what we’re talking about. But how do you bridge the gap and skill, right? Somebody who is a junior developer who is only doing HTML, CSS over and over, how do they learn to be a senior person if you’re putting them within that role alone? How do you balance those two things out? Let me know if the question make sense because that was a little out.

Bill: No, it makes perfect sense. I think that this is where the transition to Conway’s Law comes into play because that’s what I sort of started out the podcast with, right? We’re looking at the very lowest level now. We’re saying, ok well; let’s think about how we staff an organization to accommodate people of different skill. And if we’re going to staff a company that has people of different skill we need to have a code base that allows people of different skill to work there. Otherwise, what we’re going to end up with and this is sort of a foreign spectrum. Worst case scenario is that we have to hire experts to work on our code because simply editing a newsletter or editing the display markup requires a senior JavaScript engineer who’s going to dig in to some low level component to then modify the way something behaves or something looks. That’s kind of the worst possible scenario is to be paying tons and tons of money for stuff that frankly an intern can do. And not having that highly skilled developer working on the hard problem. It’s bad for that developer because they’re going to be bored, and it’s bad for the company because they are overpaying for the work product that they are getting out of that engineer. As a company if you’re working about how do we accommodate having sort of entry level developers, intermediate and senior developers? You have to think about your solution design patterns and ultimately that will then bleed in to what is the architecture of our software product look like. And directly to answer your question, how do you accommodate them, how do you help them grow? I think that’s inherent in the system. A lot more company is not paying attention to their code, not specifically designing for allowing entry level people to contribute. And they are sort of excluding those folks from the ghetto. They won’t even consider them in the hiring process because their requirements are that you have to be an expert to work here; maybe because they’ve had a bad experience with people who have a lower experience level or because their code is just so complicated that the bar is so high now. But all of that comes back to sort of the same problem and nobody put the thought into designing the technology solutions in a way that you can accommodate people at a lower skill level. Once you do and you have the ability to bring in interns or you have the ability to bring in first year engineers or developers. The process of growing them should be something that you pay a lot of attention to. You don’t want to pigeonhole someone who has always been the markup guy. You want to provide a career path, provide a path through the technology supports, to have and take on additional responsibilities and learn new things, and grow up in the organization both in terms of their responsibilities but also their understanding of the technology in the stack. That’s where a good piece of software, good piece of technology that’s designed to work with the organizational goal and actually help engineers grow faster and can promote longer retention times. And let’s say a software product that doesn’t have that purpose built into it.

Carlos: Yeah, I mean, as I was kind of hosing my question I started to think about. I was obviating that the company already had junior people within their rank. So what you’re saying is that this way of thinking forces us to be thinking always, be thinking of skill set levels because people are going to be spread out through their skillsets. And because of that we are going to be consciously thinking of the best place to put them and where they can grow to versus if we’re not thinking of architecture in this way. It’s like ones and zeros. It’s a binary decision, “We are not hiring you because you are not senior enough.” Because all of the decision will have been made at a senior level and everything is going to be over complicated. Like you said, you’re going to need a front end engineer to send out a newsletter now which is ridiculous. But I’ve seen that happen, that exact example. Instead of, and I’m not joking, instead of putting all the email templates or something like MailChimp. The email templates are coded in SASS and all these different. Like all that has to be within the source code. It’s a story form the past, old client. But yeah, I saw that once and basically we were sending out emails as a software engineering group made no sense. We are now talking about skill set and specific people. How do we think of process though? Like I know that if we have these very. And I am calling them very structured, right? But correct me if I’m mistaken but it sounds like some of these to have make a mirror of the system architecture in a company organization we’re going to have certain level of structure. With a rigid structure, how do you keep things like Agile in balance? How do you keep processes and improvement in processes across groups being shared if you don’t have a hierarchy of people or actually if you have such a strong hierarchy of people?

Bill: Yes. So you’ve touched on a keyword there and that keyword I think you know kind of raises the hair on the back of my neck a little bit. So Agile, it’s great. I don’t disagree with the principles of Agile. What I disagree with is Agile is a noun. I’m all about putting agility into the process. I’m all about sort of picking and choosing what works. I use this analogy all the time. The relationship that I have with my wife is very specific. It’s the two of us together. It’s not that she is in a certain way and I’m a certain way. We just needed to find someone who’s going to click with the way we are. It’s the way we are together. It’s different than the way I am without her or I am with somebody. For me it’s the same relationship within a team, a group of people. I don’t think of them and I don’t want to treat them as some anonymous resources and I’m going to stick them in a framework and they are going to behave properly. To have true agility, I think that you need to be respectful of the personalities. I do a lot of consulting for companies. I get the honor for sitting in on a lot of different projects and throwing my opinion out there for whatever it is worth. Let’s say projects of all different sizes, with all the different types of frameworks, SDLC, methodologies etc. And I can tell you from experience, 20 years of experience, you can have four people working in one specific SQL methodology and add a fifth and that methodology no longer works. It’s not because the fifth guy is a jerk or because he doesn’t agree or whatever, it’s the personalities in the room change, the way that they interact with each other changes. Not usually everything but enough changes to where you have to adapt your methodology as the manager of that team; to take different approaches, to work in different ways. That to me being that adaptive to the team and respecting the personalities and getting the most out of your team, being respectful how they work together is agility. I don’t think that Agile is a noun. It promotes the agility, you know the adjective agile. I think that it’s a very prescriptive way to treat people and treat processes that frankly need more agility. We have Agile, it can be used as a starting point or a guide, or as a reference. But it shouldn’t be taken as dogma and it certainly shouldn’t be looked at in a vacuum. There are a lot of other methodologies out there and frankly the people who are most dogmatic about Agile can’t name any other process other than Waterfall which seems to be the constant comparison. “Oh, it’s either Agile or Waterfall” or “We were doing Waterfall and now we’re doing Agile.” Well, no, you weren’t doing Waterfall if you really understood what you’re doing, or at least before we see you were doing Waterfall, name other SDLC methodology please and then at least I’ll know that you three. I tend to see a lack of maturity in these conversations and it is really turning “agile” as a noun into just another rigid framework. With that rant, I’ll get myself for a minute and answer your question. The way that you handle this is exactly in a way as suggested. You treat human beings as human beings. You respect that these group of people is going to be efficient working in this particular way and we should organize our processes around how they work. How those personalities work. We should have some superstructure to the way we work as a company so that we can have metrics that run across the company. We can have some measure of efficiency in some KPI measurements as a company. But if this particular team wants to do stand ups and this particular team doesn’t benefit from stand ups, let’s not force them to do stand ups. In the same that if this particular team want a flat self organizing structure because they seem to self identify what work they should be doing really well and this other Team B doesn’t do that well, then we probably need more guidance or more structure on Team B that the right work is being assigned to the right people. And we are not getting the junior picking up the senior’s work or the senior over complicating the easy stuff or even the senior is maybe honing it in and doing the easy stuff because he knows he can knock it out well as ignoring sort of the hardest. And it’s not to say that’s a common occurrence and that’s what most people do but it certainly comes up. And the point is that some team will self organize really well and we can’t just say, “Well, we are doing Agile as a noun so let them self organize.” We should say, “Ok, what are the personalities in the room? Is somebody shouting everybody else down?” That’s not self organization. Now we are close to what the intention was, right? That’s just hierarchy by self imposed dictatorship. Let’s take that out of the picture and let’s treat people as people and as managers it’s our job to make those teams more efficient. We should be knowledgeable and step in and recognize these things.

Carlos: Just to add something to that, I framed this at the beginning of the conversation, I kind of framed these are as potential cons and you are explaining they are actually pros. But one thing that we’re on our thing as a bit pro is what you’re saying is that by keeping things organized in such a way we’re also keeping eagles at bay. I say that because I think that that conversation about Agile and people to saying, “Oh, Agile this, Agile that”, is because of that. It’s trying to be right, trying to one up the other. You’re just using the rules, “Hey, you are not following the rules”, as a way to impose themselves in some way. But overall this whole thing is a benefit of a hierarchy or a status within a team. It kind of makes me think that it’s going to be more based on your skill set. You know your passion for the work that you’re doing than just shouting harder, right, and getting political. The way that you’re positioning this sort of allows us to keep eagles at bay. What do you think with that?

Bill: Yeah, I think that’s definitely a benefit. There is a couple of things that come into play when you start to level people within an organization. And I say this as an opposition to sort of having a flat model where you have, again worst scenario you’re saying, “We only hire the best.” That’s one type of organizational mantra and I’ve seen it. A lot of people still say that. In fact, it’s a pretty popular thing to say that you do is that “We only hire the best”. Well frankly, you shouldn’t and it’s because if you have the best guy doing the easiest work they are either unambitious, lazy, probably not good at their job and they are getting overpaid. But certainly if they are none of those things then as an organization you are overpaying for their work product. So going back to which you had noticed. Once you start to level people you get this sort of hierarchy of mentorship that happens. The benefits start out with egos. And even the egos get fed a little bit by the benefits. And that is sort of positive way to feed the ego. If I am a senior developer and I have something to teach, am I going to another senior developer and be like, “Hey, check this out. Let me show you this awesome thing.” And like there is this design patterns that I’ve been using for 5 years and it’s some time. And I don’t want necessarily have a philosophical debate with another senior developer over my design pattern versus his design pattern. I’m certainly going to get a room for those and there is enough to go around like I’m done with that. I learn from those sometimes but frankly I’ve had those discussions enough times where I’d rather discover it on a blog post. But if I really want to mentor, if I have that innate desire to teach people and share what I’ve learned over my 20 years, and I see somebody struggling. It’s definitely rewarding for me to be able to say, “Hey, let me show you something that can help you in your career and help you solve this problem right now.” That sort of hierarchical relationship which is fed by the organization’s hierarchy to say, “We’re not all flat. We are not equal on this team. You are better than me. You have something to teach me. Teach me, I want to learn something from you.” Right? Like you have to be a pretty big jerk to not learn from some guy who is a lot better than you, who is being by the recognized by the organization as being better than you; and you’ve been paired with this person on the team to do the work that if put it out there is deemed beneath that person because they are doing the harder stuff. You are doing the hard stuff, I am doing the “easy” stuff. I have to be a pretty big jerk to not recognize that you have something to teach me. You may not want to teach me, that’s a whole different thing. That’s where we step as managers to make sure we got the right team vibe going on with the right people. But definitely having that leveling and building an organization where you have a spectrum of skill set. It allows for people to be mentors and students at every level. And I think that is the type of place where most people find their work rewarding. Where most people look forward to come in to work and say, “I want to learn something today” or “I’m going to teach somebody something today.” That’s a fun place to be and that’s a fun place to want to be. That’s not necessarily impossible in a flat organization but this conversation is about organizing software, designing software and designing architecture in a way that promotes an organizational concept. And this organization concept that I’m saying will ultimately promote this sort of interactions and these ideas.

Carlos: So I’m going to be the devil’s advocate here, I want to put myself in the position of somebody who is listening. But he will probably say, “Well, Bill you are the Senior VP of Engineering.” You have a voice in your company. This is you can try to shape things internally because you have access to the inside of the company as you’re higher up, your leadership to the company, directors etc. or the actual business, but also you have control from the top down. So you are able to influence the business in order to make decisions but you also have the authority to make decisions internally. What do you say to those that are, well actually, I’m still thinking I’m the guy. So he is saying, “Alright, but I don’t have that. I am a Senior Engineer, I am a Director, I am a Manager. How do I influence this organization?” To think more in this way and I know that it depends, right? Each story is going to be different. Maybe we can try to outline a couple more benefits. So what benefits would you give this person, and maybe some ideas as to how we can promote this sort of thinking across organization? By the way, you can always share this podcast with whom you are ever convincing. But if they cannot do that, what’s a real potential conversation that they could have with the leadership.

Bill: Yes, for your specific I think it does start with the conversation. I think the more that people talk about these ideas and the more that we treat the way that we design software as a purposeful activity and not a byproduct of getting stuff done. And there is this concept the “accidental architect” and frankly like a lot of the software that I see. Again, I’m not speaking about Age of Learning, but I get to sit in a lot of projects and sort of look at a lot of different things. A lot of software gets designed as a byproduct of just getting something done. And a lot of that design and architecture is a byproduct of speaking directly to Conway’s Law. It’s a byproduct of that organization of the company. So in your example, there is a senior engineer who is hearing this and they are saying like, “Oh, that’s sounds great but how do I have that conversation with my leadership.” How is that conversation now? Start talking about it. Start talking about the concepts of like what is our total cost of ownership for our code base. Like what does it take senior developers or developers of a certain experience to change the homepage looks on our website or whatever sort of that trivial task is that you feel could be done by anybody who knows each market.

Carlos: There is a direct correlation having this conversation on money. And with that said, whenever you touch your leadership sprockets then they have your ear, right?

Bill: Yeah, exactly. And if you start to have those conversations now and start to have them in a professional manner where we’re talking about like purposeful design. The next time it comes to refactoring something you can start to introduce these things into your code base. You can start to say, “Look, how are we going to refactor this area of our code or this smaller side or this smaller project.” How are we going to refactor this in a way that an intern can come in and take 30%, 50%, 80% of the daily duties of our tasks as engineers. There is one constant in technology and that’s that there is not a lack of things to do. Like we are going to be asked to do more and more and there is not going to be enough resources and not going to be enough time. As a responsible organization, as people who want to see our company succeed we need to be thinking about how do we get more done with less. And it’s not going to be have senior developers work longer hours or have the senior developers write more code. It needs to shift to what’s the cost of our work product. We have a lot of people getting into technology. They are coming through the bootcamps, three months of experience, they are coming out of school, they’ve got no practical real world experience. Like where do they get started? Are we saying that we want to employ these people because they have hit the bar of being able to edit out ungodly complicated code? It shouldn’t be that way. All of us who actually do this on a day to day basis can change that. We need to have the conversations and then we need to start implementing those ideas. And what you’ll find is that when it gets down to it and eventually you have that product or that website or that thing that it is easy to do the easy stuff and you don’t need the senior engineer and you go to your managing and you say, “Look, we’re spending half of Bob’s time and Bob is a Senior Engineer with 10 years of experience. We can have his time doing something that we could have an intern doing. Let’s get an intern for that. Like those managers, those directors, those executives are going to hear that especially if you primed on the conversation.

Carlos: I think the conversation is to be had so openly and so strongly in a way that doesn’t cost Bob to fear for his job. You see what I mean. You just said that whatever Bob is doing an intern can do but Bob costs 200 grand a year. Bob might be scared like, “Oh, I don’t want to have this conversation. I don’t want to put my job at jeopardy.” But in reality there is a lot more for Bob to do at his skill set. And if the organization realizes that they are going to be able to make better decisions. Also again grow the junior developer or the intern into a future Bob.

Bill: That’s right. You know, that’s something that a lot of people done understand on the ground, that a lot of engineers don’t understand on the ground. There is no lack of work for a good engineer. Every company that I talked to, every company where I get the honor of sitting and understanding how they work. They all say the same thing. We have this really long list of things to do that we want to get done to further our business. Then we have this really long list of things we have to do to maintain our business. It’s the have to do to maintain our business that seems to get the most attention because it’s a luxury to invest in yourself moving forward. And frankly what businesses are doing is they are bringing in outside work, they are bringing in vendors, they are bringing in new hires to work on the new stuff. But Bob is not getting to flex his technical muscle but he is being pigeonholed on stuff that’s well below his pay grid and his career isn’t benefiting from that. Bob shouldn’t be scared. Bob should be welcoming that so that he can move on to the new stuff. The more complicated stuff is more gratifying from a technology point of view.

Carlos: You see, immediately this gets me thinking of, by the way it’s my being at different podcast though this is probably an opportunity to save conversation for something else but things in the realm of technical debts, right? The company does sometimes the business, and when I say “the business” I mean the non-technical people within the business don’t know the impact of this has to the cost of ownership of the technology that makes the business work. By having this sort of company organization and system architecture kind of match allows us to solve for that kind of inherently.

Bill: That’s right and really what it takes is being aware of it, being aware of the possibilities. I think for a lot of business leaders, they don’t understand that there is a spectrum of skills here and that there is also a spectrum of labor cost here. Again, it’s the mentality of “we only hire the best” but you shouldn’t.

Carlos: You don’t hire 20 chefs at the kitchen.

Bill: Yeah. You don’t hire 20 chefs and you certainly don’t hire a chef to go work at McDonald’s, right? Maybe in the test kitchen somewhere, way over in some R&D building. But you certainly don’t put them in the corner of McDonald’s and you certainly you don’t put five of them in there.

Carlos: Exactly, you want to build, that’s probably a good analogy. You need a chef and you need cooks on the chef that at some point will become chefs, but not everybody needs to be a chef. Because if everybody has to be a chef then you’re not going to give any work to those cooks and I know this some kind of we’re in an analogy but it’s true. It’s that secession and being able to grow people and nurture them into their career paths. Maybe this is the last benefit and we’ll probably talk about it but somewhat this benefit is promoting a career growth, right? Having levels of growth and allowing for that nurturing of the junior people.

Bill: Yeah, that’s right. I mean not to think about that in your organizational structure. It shouldn’t be something that we do as an afterthought. It shouldn’t be something that we don’t keep in mind when we think about how do we want to organize our companies. We should always be striving, like when we think about like how do we organize our people? We should always be striving for what is the effects we want this organization to have. Most everybody says we want to get stuff done. Great, let’s just put that into the side. There are a lot of ways to get stuff done. There is a lot of contributing factors to how we get stuff done like retention, cost of product, employee happiness. Just like even having employees that want to come to work to write code and who will be heads down writing code instead of like talking to their neighbors or taking a walk or going and smoking a cigarette. That kind of day to day work avoidance means you’re not happy with what you’re doing. If you’re happy with what you’re doing you want people engaged, want them challenged, you want their egos being feed by either being mentored or mentoring other people. They should all be promoted by the way you organize your people. You should think about those things because they matter and not just have it as an afterthought and say, “Well, your career path here is like you spend three years and you get Software Engineer 2. You spend 10 years you get senior.” That shouldn’t be a thing. It should be much more rewarding and engaging and much more gamified than that. Like I should be able to be Software Engineer 1 and jump up to Senior Developer in 12 months if I earned it. And that’s a thing, if I earned it. It shouldn’t be like, “Well no, you got to put in four more years to hit that level and by the way the only way we can judge you is by arbitrary opinion.” There should be a system of meritocracy for that. But this is sort of getting off topic. It’s related but it’s like all these support systems for our organization need to work together. You give people real value out of them. Otherwise, we are just going through the motions. We are sort of organizing in a vacuum towards some purpose without understanding all the causes and effects.

Carlos: Yeah, in the end we are definitely really architecturing our organization. The topic here is how to reconcile them both but in the end we need to really think in that architect’s mindset in terms of people. We’re not only putting people in teams but also the paths to grow from one team to another level to another. As you said, thinking in this way forces us to think of those levels. Bill, this is a fascinating conversation. As you know, this is something that throughout the years spoken about in some form of another. I’ve seen some of the work that you’ve done so I’m very excited to talk about this in such detail. I really appreciate you coming on the show. I think this is going to be one of those hard hitting episodes that we’re going to have some fans of and some haters of because I think some people might think of, “Well…” You know, I think we know that there is some that might not agree with some of these views. But I think because it is semi polarizing. I think this is the sort of episode that really most people forward and gets people thinking about all these issues that we raise today.

Bill: Yeah, I agree I think anytime you mention Agile in a bad light you’re going to get sort of dogmatic immediate reaction to, “No, this guy doesn’t know what the is talking about. Agile saved the world.” I am looking forward to the haters, Carlos.

Carlos: I think the good thing here is it’s this concept that we’re going a little bit more in depth that it’s more than just throwing out Agile as a term as a solution. And really think of things a bit more in depth. Otherwise, Agile becomes a dictatorship of this. We can talk about this in length but it’s not Agile, if it’s not done in an Agile way. It’s like kind of obviously more on if you think about it, you’re not being Agile enough if you are conforming to too many rules of Agile.

Bill: That’s right, yeah. You want agility, you don’t want agile, you want agility; and we should keep our eye on that like where is the agility in our process.

Carlos: You don’t want Agile, you want agility. I like that. Well, thank you so much for coming on the show. I do have one last question. A lot of people are usually interested in applying for jobs and whenever I have somebody senior like you in a company they want to find out, they want to know like, “Ok, so what do I have to do for this guy to pay attention to my resume.” What are the sort of things you look for in an applicant that might be interested at a job at ABCmouse, at And how can they apply to any position if you guys may have open.

Bill: Yeah, good question, so the applying part is really easy. You can go to You will see a link for careers on the top of navigation. Click on that and review our jobs. I can tell that we’re always looking for good people so if you don’t see something there that’s a good fit reach out to HR anyway and let them know what you’re interested in and what you’re all about. And I can guarantee you that if there is an inkling in there that, even though we don’t have an official job open but we think that you can bring value to our company we will reach out to you and we will if not have an immediate conversation with you. We’ll have you on our list to talk to when something comes up. But in terms of what I look for I touch on it a little bit. I look for people who are excited about technology. I look for people who are interested in learning. I look for people who are open minded and have potential. And by potential I really mean that they spend their time learning how to be better with what they do. I don’t mean potential as in has pedigree or paper. I really value people who are self learners or self starters and who spend their own time getting better at whatever they do. Be it as a manager, they are reading blog posts about managing and books about management or if they are technologist. They are spending time learning new skills or doing R&D, or practicing new things. If you’re into what you do it’s going to come and then interview with me because my interviews are very conversational. I’ll look for what your passion is all about. And if you’re passionate for something that I need that to me is more important than any piece of pedigree or any piece of paper.

Carlos: Well, you heard that here first. I love that point of view. I like your style of doing that, so anybody who is interested into coming to work for you. Well now they know your vision as to how companies or teams should be structured so to their benefit what you vision is in this realm. But Bill, again I want to thank you so much for coming on the show. I think we have, just from this conversation I was able to potentially have two more podcasts recorded to be honest. You know we could talk about the whole meritocracy process. In a company how do we measure that, how to measure growth? Because it’s one thing for us to talk about it but there is another conversation to be had about it. How do actually measure that with numbers? That’s an interesting conversation on its own and there is potentially another one about things like technical debt and how do we deal that, how do we deal with those within the company at the level that you are? Hopefully you’ll indulge us and come back on the show because you’ve been a great guest. Thank you so much!

Carlos: Thank you, Carlos. I’ll be happy to come back.