Episode 6 Transcript: Learn better ways to work with your direct reports

This is the full transcript of the sixth episode of Inherited Composition. You can read it below, or listen to the episode

Gonto: Welcome to the sixth episode of "Inherited Composition." I'm Gonto, your host, and I'm here with Guido.

Guido: Hello.

Gonto: So, today we're gonna be talking about how to work with your direct reports. We're gonna divide this episode into four different sections. First, we're gonna talk about one-on-ones, how often do we do them, what do we talk about, how do we structure them, etc. And we're gonna give you a few tips on how we both handle one-on-ones. Then we're gonna talk about performance review, how often do you do them, does it impact the salary, how does it work, etc.

Then we're gonna move to talk about, like, sync-ups, and basically discuss what is the difference between a sync-up and a one-on-one, and again, how often do we do them, why, what is the format, and a few tips on, like, how we handle them. And then, finally, we're gonna be talking about, like, staff meetings or our leadership team meetings, and then, again, why do we do them, how often, what's the objective. So, basically, we're gonna be talking about the four different ways in which you usually interact with your direct reports.

So, let's start with one-on-ones. Like, how you manage one-on-ones, how often do you do them, what do you talk about. Can you tell me a little bit about it?

Guido: Yeah. I usually have a formal one-on-one with my direct reports once per month, but...I don't know, everything I read and listen to usually suggest having one-on-ones once per week, but, at least, for me that's too much because I already have weekly meetings with my direct reports where we discuss about, like, how projects are doing. So the one-on-ones is more to talk about, you know, career path, personal stuff, things that they want to accomplish. We also set the right structure and start the conversation to get ready for the performance review, and align ourselves on the goals and things we need to accomplish in the following month.

So, yeah, for me, usually it's once per month. Obviously, I have, like, informal conversations with my direct reports every now and then, and if they want to talk something specific, I always tell them they can bug me. They don't have to wait for the one-on-one. But, I think having a regular schedule sets the play for the conversation when you know that some time you will have that opportunity to discuss some issues that is not just project updates.

So, that's [inaudible 00:02:48]. So, how often? Once per month. What we talk about? We talk about, as I said before, you know, the different things that you need to improve. I also give them, you know, positive feedback of the things that they need to keep doing, and, every now and then, we grab the performance review, we review the objectives with...I give them tips about the thing that they should start doing to get to those goals, and I also review every talent and behavior that's described in our performance review, and also give them tips and feedback about the things that they need to accomplish, so when they get to the performance review they already know what to do.

Yeah, and that's it. So, what about you, Gonto?

Gonto: So...before that, you were mentioning that, like, one-on-ones are recommended weekly instead of monthly. Something that, to me, is important to note about that is that every person, every company defines one-on-ones differently. So, to me, it's interesting to understand, like, what does a one-on-one that is weekly mean, and why? Because, to me, like, a one-on-one in which you discuss career path, how are they feeling with what they are doing, are they happy, helping them with other stuff that is not particular tasks, that, to me, more than once a month, maybe, like, twice a month is, like, too much. But actually, something that I do regarding that is, actually, I talk to my direct report. I tell them, like, I usually do them once a month, "But, how often is it useful for you?" And then, depending on that, like, we change. And, usually, it depends on, like, who am I working with, how much am I helping them, etc.

So, for example, lately, I've been working with Ceci [SP] who leads the Marketing Design Team, and she's having, like, some struggles, and I'm helping her with, like, management, leadership in design, etc., and because of that, I'm doing a one-on-one every...actually, every two weeks, and it's, like, a one-hour, one-hour-and-a-half, or something like that. But, in general, I'm like you. I also do them once a month.

Also, you were saying that you do one-on-ones to, like, talk about career, etc., but do you use any software? Like, do you take notes? Yes? No? Why?

Guido: Yeah. So, this is funny because this is the kind of conversation that we are having in the company right now with formalizing one-on-one meetings, but, yeah, I do take notes. Regarding software, I use Bear up, but you can use whatever you want.

Gonto: Bear is, like, local. You don't publish it anywhere? It's, like, local notes on your computer?

Guido: Yeah. It's local notes on my computer. I don't publish them. I do publish them when I'm having the transition. So, we can discuss that in a little bit, but usually, it's just for me. I tag them, you know, by date, and I just write down both things that need to be accomplished or things that I need to take action. For example, sometimes people tell me, "Oh, I'd like to get this particular issue fixed," or something, or, "I need you to talk with another manager to solve a particular issue with another co-work," whatever. So, I use that to take notes and see the things that I have to provide an answer in a short time. So, say, "Okay, I'm gonna give you an answer about this particular issue in the next two days."

So, that, and also take notes for the things that I need to keep track on and things that I need to review for the performance review. So, let's say, "In the next two to three months this person should accomplish X, Y, or whatever, and if she or he does that, then that should translate to this particular behavior in the performance review." So it's easier for me, when I have to do the performance review, to gather all the data I need to provide the arguments of why I'm doing the things I'm doing.

Gonto: And I was asking because, like, for me, for example, like, I always send the note for two reasons. I don't save it just for myself because, one, if, unfortunately, you have to let them go, or something, you need proof of, like, why. So, actually, having sent that to him or her means that they know and they've acknowledged it, so you have, like, proof in your dog. If you only keep it for yourself, I think it's hard because it's a conversation and it's not, like, easy to prove. So I definitely recommend everybody to, like, take notes.

And then, the other thing is actually sending a list with [SP] an acknowledge makes it easier for some people to process, because some people are more, like, audio, some people are more visual, and, with this, you get two things. Like, you do the audio, but you also send them, like, the visual list of, like, "This what we chatted about. Do you agree?" And then, that's the final one.

So, for me, for one-on-ones, I've never used a software. I actually...I use Slack. I send it on Slack, and then I just pin it, but we are now...we actually just decided last Friday that we're gonna be using Small Improvements to take notes for one-and-ones. So now we're gonna be working on, like, doing a training company-wide on how to use it, and then start using the software for one-and-ones because it's an easier way to find it, track it, etc.

Guido: Yeah. We're in the process of evolving [SP] the software for both performing reviews and one-on-ones, and I do have to say that Small Improvements is the best I could find about one-on-ones. And, I agree it's better to have, you know, both the reviewer and the reviewee have shared notes. And, Small Improvement has a feature where you can set an agenda or the things that you'd like to discuss beforehand, then you can both have shared notes and you can also have private notes, all inside in the same tool. So that's a good option.

Gonto: And, for me, in general one-on-ones, I do it same as you, once a month, except, as I was saying, sometimes I do it once every two weeks, or something like that for special cases.

Guido: How long? Like, an hour?

Gonto: Yeah. It's always one hour once a month. And then, what do we talk about? It's very similar. So, first off, I have select...set-up questions I always ask. One is...not every one-on-one, but I tend to talk about their career path. And that's basically asking them, like, "Where do you see yourself in one year or two years?" And then, based on where they see themselves and where they wanna go, I basically work with them on how to get there.

So it's basically, "Okay, if you wanna get there, these are the things that we need to work on. These are the things that are working." So it's basically trying to create that career path with the other person, and I think it's very important to talk about it, because if you don't talk about it, the person will think that, like, maybe there's no career path, or, "This is it. I can't grow anymore." So I think it's very important to be conscious about it.

And I always ask, like, general questions, like, "What things are you doing now that you don't like?" To see if we can help change some tasks, or, like, "What things...like, how do they think that they are doing? Like a self-assessment, to be self-aware. I then give them my feedback, and I also, of course, every time, them for feedback for myself to see if I can do something better for them.

Guido: Yeah. That's a good point. I think something that is really important is that one-on-one is not just for the reviewee. It's for the reviewer, also. It's a good opportunity for you to get feedback about what you do as manager. And, as you say, I think it's important to align expectations and to provide feedback frequently. And, also, particularly for me, I use them to check on the other person's life projects. So, for example, somebody is moving into another house, and I know that that's gonna take one to two, three months from the moment they're trying to do that. So I ask, "Hey, how is everything going on with that? Can I help you with something?"

And, I also...going back to career, I always ask, "What can I do to help you accomplish X?" So, that's...I think is a good question.

Gonto: And I agree. And, some other things for one-on-ones is that I always think that they have to be awkward, because one-on-ones are about...and we mentioned that in another chapter. One-on-ones are about something that's personal, and anything that's personal is always uncomfortable. I've read a book called "The Advantage." If you haven't read it, it's amazing, one of my favorite management books, and something they talk about is this idea of vulnerability-based trust. But, in order to have conflict, discussion of good ideas, etc., you need to have trust with the other person, and it's vulnerability-based, which means that they know who you are, what are your errors, or the things that are not great with you? What things are great? And you can talk from that point, and I think that that's something that we should always try to do.

And then, something I found, which is crazy, is that the best things that I do in one-on-ones is not help them with one particular task, or something like that, but rather I actually learned a lot for my one-on-ones from talking to my psychologist because he helps me understand myself, my brain, how it works, and that, plus some books that I've read, help me help others, because usually, what I'm doing is I'm managing managers, and they have either problems with their direct reports, or some peers, or this, or that, and I just help them think what things to do, why, etc.

For example, I was talking now with somebody on my team, and they were saying that they were being insecure. And, I'm insecure as well. I'm less insecure now than before, but I've had my share of insecurity. And I think that as you start recognizing yourself and being more aware, you can realize some of the things. So, for example, my tip to her about it was about the fact that, usually what happens is you think something and then you feel something inside, which is insecurity, and then you get these thoughts of, like, "But is this right? Am I sure that I should be doing this, because maybe I don't have an experience, or I don't know, or this, or that." And then, that basically creates this untangled thing, which is a mess.

So, I think that something, for example, that helped her was I was telling her, "Go to the past and look how many times your first idea was right and how many times your self-doubt helped. Once you start realizing, for example, that your self-doubt doesn't help at all, then you start noticing that your first idea was right, and maybe this insecurity makes no sense. So, then, by being more aware, when you start getting the thoughts of, like, "Oh," like, "I don't know how to do this, I don't have the experience, etc.," you just are aware of that in that moment and you discard it because you know, based on your rationale, that, in the past, that wasn't right, you just killed [SP] it. And that's something that is very helpful. And then, change is about repetition. So, then you repeat that consistently, and then you're gonna change.

So, those are some of the discussions, for example, that I have with my direct reports. And I have a lot that are new managers, so I talk a lot about these kind of things.

Guido: Yeah. For me, what's really helpful, I'm in the process of...I'm transitioning from being the head of communication to be the director of people care. And, in that process, I need to delegate all the things that I was doing as the head of communication to my direct report. So, it's also a good opportunity to be transparent of the new challenges that I'm facing, and say, "Hey, I'm also not really sure about these particular things, so I'm being transparent. I'm probably gonna need your help." And I always ask them or tell them, "Please, if I'm doing something wrong, or if you don't agree with something that I'm doing, this is a good opportunity to tell me so I can change that behavior." So, I think it's a good opportunity to have that conversation both ways.

Gonto: I agree, and I think that one-on-ones are just like a fictional moment that you create to talk about these things, but, in general, as you've said before, like, I talk about this, like, when something happens, but then I actually use the one-on-ones as a fictional time for the people who don't like talking about it, so then you create that moment, and also it's good for reinforcement. So, even if I have given them feedback on things during the month, I've reinforced that both the good and the things that need to improve, so that then repetition and consistency, which is basically what creates change, I think.

Guido: Yeah. Now that you said that, I remember having a one-on-one with a person that didn't like one-on-ones, and the first one-on-one I had with that person, everything was fast, you know, like, "How are you?" "Good." "Okay. So, are you okay with what you're doing now?" "Yes." So, it was, like, 10 minutes, and when I finished that, I felt really bad, you know. It's like, "This was the worst one-on-one ever." And then, for the next one, I really prepare myself. Like, I did research about how to ask questions to person that maybe don't like to have these sort of conversations. I started to take notes during the month of the thing this person did well, and things that need to be improved, and things that I realized that this person was struggling with other team members.

So, with all that information, that took a lot more work than I used to, I had more direct questions, I provide feedback with examples, and then this person, at the end of the meeting, told me, "This was the best one-on-one I ever had." So, yeah, it changes a lot depending on the person that you're having this conversation. So you have to adjust to the other person's style.

Gonto: Yeah, 100%. So, let's talk a little bit about performance reviews. So, you were talking a little bit about you set up one-on-ones, like, those are the set-up for the performance review because, in the performance review, you're gonna use the info for the one-on-ones. But, tell me a little bit more about, like, how often do you do the performance review, how are they structured, and what things do you like and don't like about how Wolox does it.

Guido: Sure. We do performance review every six months, so it depends when you start working with the company. So, we don't have, like, a fixed period for the entire company. Our process has, like, different behavior talents or skills then you need to pick 12 skills. Sorry, you need to pick 12, 9, or 5 depending if it's your first, second, or third performance review, and after that is always 5 skills. And then, we took the 12 that have the more, like, the higher scores, and then we use that to compute the score, and that score will give you the level or category that you are in, and that is used to calculate your salary.

So, yeah, a review has, like, what we call universal skills or talent, so everybody gets evaluated on those, and then you have specific talents depending on the area or department that you're working. So, if you're a software developer, you have skills about how you code, you know, how you do code review, your coding style, things like that.

So, we are now changing the process a little bit. So we are adding fixed meetings every two months, where you have to provide feedback about particular talent. You don't actually set score, but you tell them the things that person should accomplish the next period, so once you get to the performance review, is just checking on those skills and those comments if things had been accomplished or none. So, that's the process at a high level. I usually used these intermediate meetings, so every two months I replace the one-on-one for this particular meeting, where we have the high-level discussion, and then we go to the performance review and we talk about specific behaviors.

Things I like about the performance review that we do at Wolox is that, if you understand the model and you take the time to do it, you usually get a good result, and it gives you a framework to provide feedback, but the bad thing is that it takes too much time, and if you have too many direct report, it could be a burden.

And, as I said before, it needs a lot of training. So, we are struggling a little bit when we add new managers because we realized that we need to do more training than we're used to because, again, we grow a lot in these two years, so the people that...you know, the founders and the first employee, we are really familiar with the performance review. We know the good things about it, the bad things about it. We know how to work with the framework, and we know how to structure the conversation. But, people that is new in the company need a lot of training, so we need to get them in couple performance review just as an observer, and to get the feeling about how to execute them.

And the other problem is that we don't have a particular software to execute them, so we have a lot of operation time that we need to do, like, you know, scheduling the meetings, what happens if somebody forgot to schedule a meeting? You know, keeping track that everybody is doing the performance review, then providing updates to HR. So we are in the process of evaluating both Small Improvements and Impraise. We're probably gonna pick one of those to start executing the performance review on those softwares.

Gonto: Make sense. Something that, to me, is interesting about what you're saying is that all of these, like, training...and that's something, for example, that we are working [inaudible 00:20:49] in Auth0, which is, like, training for managers, in general. Like, as you were saying, like, to me, training is not just like getting them to be ghosts for some performance review, but actually to, also, give them a formal training on how to do performance review, how are they done, etc.? And we're now creating a leadership development program, for example, for those kind of things.

Something we set up is, like, a mentor-mentoree program, where you have mentors and then mentorees say what things do they wanna learn? And then they are set up with a mentor to learn, for example. But then, about our performance reviews, I'm not a big fan, actually, about how we do them at Auth0, so I'll explain first, like, how we do it at Auth0, and then what things I like, what things I don't like.

So, at Auth0, it's very different. We do performance review only once a year, mostly, like, October, November, something like that, and basically, they are done just before we do the yearly salary upgrade, which is in January. So, this is the [inaudible 00:21:47]. And our...like, we worked a lot on this in the past. It was, like, a lot of disagreement on how to do it, etc., and then what we ended up agreeing is something as very simple and very qualitative, which is something as simple as, "Start. Stop. Continue." Like, "What things should Gonto start doing? What things should Gonto continue doing? And what things should Gonto stop doing?" And I get a 360 review from people that report to me, some of my peers, and then my direct manager.

And I like the qualitative feedback, but there are a few things that I don't like about the process. First of all is that, even though we're transparent, and I believe in transparency, I strongly believe that performance reviews should be anonymous, because some people...even if you're a transparent company or afraid of saying something, if they like you, they want to make you mad, or something, so sometimes they won't give you a comment, or something, which may become worked [SP] with vulnerability-based trust, but I think it's hard.

And then, the other thing is we don't have anything that is quantitative. So, when you start thinking about, "Start. Stop. Continue," you have to think a lot about good [SP] things, and what I do is I use the stuff that I wrote for each of the one-on-ones and I basically put that, because the idea is, once a year, I put all of the feedback I've given them during the year.

But, then what we don't have is, like, more specific things on, like, we do now a 360 with...that is we've done for the Marketing Leadership Team, and we're gonna do it again now in the next off-site [SP], a 360 that is anonymous. And it's basically very qualitative. It's, like, different topics, six questions per topics, probably 50 questions total where you grade somebody from 0 to 5. And that makes you think of specific things, like, are they good with change? Are they good with, like, leadership? How are they with meetings, with these and that? So, it's very structured, and it makes you think about things, and if it's qualitative, and just like an empty text, you don't think about.

And then, the other thing I like [inaudible 00:23:48] is that you have to give yourself the same test, and do the points, and do that, which actually makes you think how self-aware you are. So, basically, how do you rate yourself versus how people rate you. And that is very, very important because if you rate yourself bad on some things, and make yourself aware, and that makes it more prone that you're gonna improve, whereas if people rate you 1, or something, and you think you're a 5, you're not gonna improve because you think you kick ass, but you don't.

So that's definitely something that I would like to see more in our performance reviews. And, as I said, for the Marketing Leadership team, we're gonna basically start doing that. I stole the idea from the CRO, which actually does that. I liked it, so, we're definitely gonna do it.

Guido: Couple of things on what you just said, regarding self-assessment, I agree, in our performance review, the reviewee is in charge of doing the self-assessment, complete all the performance review. Myself, as a reviewer, has to do the same thing, and when we get to the meeting, we check on each particular skill and, kind of, negotiate what should be the final score. And I think that that's a good conversation, in general, because it provides a way of checking if you are aligned with the other person.

Regarding anonymous feedback, I strongly disagree with that because my main point there is that if I don't know who is providing the feedback, and the feedback needs some action to be done, I don't know who to iterate this with.

Gonto: But you don't think that people won't tell you things if it's anonymous?

Guido: Yeah, I know, but I think it's being able to iterate with the other person and know who to talk with, it's more important than that, but, yeah, I don't think that there is a right answer, so it depends a lot on the company and the culture, and how you work with your direct reports. But, we do provide anonymous feedback as a company, so when we have the all-hands meeting every six months, people can ask questions anonymously, and they get, like, a survey every six months, also, where they provide feedback to the company anonymously. But, when we talk about direct reports, we don't do them anonymously.

I also liked what you said about 360 feedback. We are also incorporating that this quarter. What we're doing right now is you, as a reviewee, got the chance of selecting three peers, and, as a manager, I can also pick three peers or other managers to provide you feedback, so, at the end of that, you get six people, top. Right now we are asking three questions. I stole that from you, your "Start, Stop, Continue," and we are also adding, in the next month, two more questions regarding two specific skill that the reviewer chose. So we're gonna provide a question to provide feedback for that particular skill so we have more information when we get feedback.

Gonto: That skill, was it because they set it as an objective for them, or something to learn, or why do they pick that skill?

Guido: Because, when you get a notification from People Care about, you know, you having to schedule your performance review, from all the skills that you have available, you have to pick five. So, we grabbed one or two from those five and ask feedback so we have a more guided conversation.

Gonto: I like the idea of the skills. I actually might steal that. And, yeah, I agree that 360 are key. Only last thing that I wanna mention is that we also use a tool, and we actually use Small Improvements, as well, for the performance review because it's very configurable and it has Slack integration, which, for us, being a remote company, is something that is definitely key.

So, let's go to the next topic, and this is something that a lot of people confuse, which is, what is the difference between a sync-up and a one-and-one? Because a lot of people just do them together, and I strongly think they should be separated. But, what are sync-ups for you? How often do you do them? What's the format? Why? And, like, how different are they from your one-on-ones?

Guido: Yeah. I think we do completely different things here. I don't have sync-ups with my direct reports, like, you know, schedule beforehand. If I need to have an update on a particular project, I will call my direct report and schedule a meeting, but what I do have is weekly meetings with each direct report and their team.

I'm in the process...I don't think I should do this, you know, like, forever, but because I'm transitioning from being the Head of Communication to the Director of People Care, I need to get into each head team to understand how they're working, helping them structure their weekly meetings. And, I think, eventually, I will stop doing that, but right now I participate in five weekly meetings with each head and their team, and in that weekly meeting, we review all the things that need to be accomplished for this particular week, what we're gonna do for next week. We prioritize the backlog. We have any discussion about a particular issue than needs solve, and they may require my opinion. And I take notes about the things I should do, and things I should start coordinating with other areas or departments.

Regarding the format, is a one-hour meeting with the team, and I usually...all the software I use right now to keep track of what's happening in the company or in the People Care department is just Google Docs with each particular area or team, and I write down things that need to be accomplished this particular week. Any comment or any decision that has been made is documenting there. Then, on the next meeting I check what was written on the previous entry, go through that, add new actions, document what we agree on, and that's it.

Gonto: Makes sense. And, for me, as you say, is completely different. So, I do, actually, sync-ups with each individual that reports to me half an hour every week. And that's what I was saying, like, what is the difference between sync-up and one-on-ones? Because, for me, I do them once a week because this is basically, like, status report. It's like, "What have you been working on this past week? And what things have your team been working on?" Something that, to me, is interesting about this is, like, when you have a team that reports to you that are all IC, is different than when they are managers of ICs than when they are managers of managers.

And, how my sync-ups have changed is a lot. So, when I had ICs reporting to me, I was basically knowing what the tasks were, what were they doing? And, basically, like, if they needed help or feedback. When it was a manager of IC, that changed, but I still know what each of their ICs do, and I try to help them, but when it's a manager of a manager, no chance I know basically what everybody is doing.

And I find it very useful because, again, it's a fictional half an hour where we both talks about what things have been happening, and it's a good time to brainstorm and work together, and also give them feedback not on what they are...like, not specifically on their behavior, like a one-on-one, but more on the tasks and the things that they are doing. So, they give me, like, reports, or, like, documents, white paper they wrote, they provide feedback, or, like, those kind of things.

So, I find them, like, very, very useful, in general, all of the sync-ups. And, why do them? Is just to stay in touch with everybody that reports to me. But the sync-ups are different depending on the person. So I have people that...like, I have two that create Docs. So, before we do every one-on-one, they sent me a Google Doc the day before with things like updates, questions and discussion topics, and then I actually comment on that, on questions, on their status update, things, feedback, etc.

And they set it one day before, so then, when we do the meeting, I actually think it's more productive because we've already worked a little bit on it before offline, and then, when we talk online, it's the discussion points, and the questions, and the things that we have instead of telling me exactly what all of their team were doing or things like that. But, without it, it's more informal, and it's just like a chat.

But I actually find them very useful because the best...like, I think best when with other people. Like, when there's people and I need to talk to them, and then they talk to me, I'm a very gut-feeling-based person. And, because of that, having this pressure of talking to somebody and having to answer at that precise moment, and then getting their thoughts after that, it helps me think and create better ideas, so I actually think I can help them more. And, in the sync-ups, I also try to make them the owners. I make sure that they are the ones who make the decision.

So, usually, as I said on the other episode, I do a lot of questions, Socratic method, but it depends on the person. I have some that come ask me questions, so I ask them questions back, and others who are very autonomous, and they don't like being told what to do. So that's another thing that I definitely work with each of them differently.

And then, tooling, I actually don't use any tooling, only Google Docs in these cases where we actually prepare them before.

Guido: Yeah. The good thing about using Google Docs is, like, it's a simple tool. It lowers the amount of inboxes that I have to check on, and it's easier to comment on a particular item. It's not a good tool if you wanna have a synchronous conversation. I wouldn't recommend using Google Docs for that, but, for me, I tried a lot of things. I tried using Trello. I tried...I don't know, Evernote. So, the thing that only worked for me was using Bear to write down notes or things that I need to do, and having a Google Doc per direct report where I check the weekly status, and that's it.

Gonto: That makes sense. So, let's go to the last topic of the day, and that's, like, staff meetings. So, how often do you meet with your leadership team, so the people that report to you, but all together instead of, like, just one by one? And, again, like, how often do you do them? Why? And what do you talk about?

Guido: Yeah. I do that once a week if the...what we call the People Care Heads Meeting. So we are six people in total. It's a one-hour-and-a-half meeting. We are changing the methodology a lot, and we are trying to stick to the one provided by EOS, which you basically have the first 50 minutes about checking on what they call goals or stones, which is basically metrics, the quarter metrics, and checking how you are doing with that. If you have five minutes to provide headlines, which is basically telling something that happened during the week that it's important for everybody else to know. For example, a particular team member accomplished something and you want everybody to know about that.

And then, you have a period of time where you have to go through the issues that you have over the week, so you need to write down all the issues that need to be discussed, then you prioritize those issues, and then, based on that priority list, you start working on them as a team. You may work on one issue during the meeting. You may work on several issues. It depends. And, at the end of the meeting...

Gonto: Do you change the order of the issues? Like, how do you set up the priority of what issue to discuss?

Guido: We have, like, a slot of time where we only prioritize. We don't discuss all the issues. We say, "This is the most important one." Once that's done, we start working on that particular issue, and you move down to the list. And, five minutes before the end of the meeting, everybody has to assess the meeting and put a score. And then we have the remaining time to discuss about what we need to accomplish for the next meeting to get to a score that we like. We are aiming to get to eight. Right now, I think we are in six, so this is the second time we're doing this. So I'm hoping that, over this month, we're gonna get to eight.

Gonto: That makes sense. And, we hold [SP] something similar, so, like, weekly meetings. We call them the MLT weekly meeting, which is, like, Marketing Leadership Team, and we actually also have, like, a very standard format, that the idea is that it cascades throughout the organization. So, I have a staff meeting with the Executive Team, called the SLT meeting, where we do basically every week on Friday.

So then, on Monday, we do the Marketing Leadership Team meeting. What we do is, first part is SLT updates. Like, what are the updates from the Executive Team? What has the Executive Team discussed about? Where are their notes? And the idea is that we basically spread the knowledge and spread, like...communication is something very important. So, basically, decisions or things that were discussed, we chat about them with the Marketing Leadership Team. We let them know when something is confidential for now until we can be fully transparent about it.

Then, after that, we have, like, a "Good News" section where, basically, people just say good news, like what things happened that were good? Maybe it's an award that the CEO get, maybe it's a PR that we're sending, maybe it's a new landing page that we shipped, etc., or the other thing that can be on "Good News" is things that you're doing that might help other teams.

Then, after the section, we have, like, a "Prioritization and Blockers." So, the idea is, "Are you blocked with something, and how can you help unblock that?" And, in marketing, we have a lot of different teams, and, actually, something that happens is that we have, like, a lot of teams asking things for the Shared Resources Team. So, we have teams like Marketing Engineering that basically serves the other marketing teams. They serve [inaudible 00:38:51], they serve Content Marketing, etc., so something that happens is that, as they are setting their goals and their tasks with [inaudible 00:38:59], maybe, for example, they have everything set up, and then Product Marketing needs a new landing page, and they say, "I can do it in two months." And they say, "No. That's, like, too long."

So, then those discussions, we do them on the MLT meeting where basically, that's a blocker and it's a prioritization issue where the Product Marketing person will see and they say, "Hey, like, this test is supposed to start in two months. What is starting in the next week, or the next two weeks, because we need it by this day because of this, this, and that?" And then, once we find out what is gonna be done before, we let those two people discuss and see if they can get to a rich point that works for both. If not, then I will intercede and help them out on, like, prioritization. But, the main idea is they can solve those prioritization issues and blockers basically by themselves.

And then, we also, as we do that, we set a lot of action items for people, and then you can see, like, all of the meetings, we have a menu that we put on Confluence. And, in Confluence, the good thing that we came from Atlassian is that you have tasks and to-do items for people, so then you can see what things you should be doing that maybe were discussed. And then, other things that we have is we also have some meetings where we have scheduled time for representation, or something. So, for example, last MLT meeting, we had a presentation around the new homepage where we sign in the new home, and this was, like, a milestone. The design is almost finished, so it was presented to all MLT to get feedback.

Another thing is, for example, we're changing the work house, and that the work house is now gonna be using, like, a dimensional data model. So we presented that in the team and we saw, like, how it was. We also get people from outside the MLT team sometimes to present on things they are doing, like the new customer marketing, or new partner marketing, or basically some of those things. And I find it very useful because it helps with cross-team collaboration inside my org. And we have, like, so many diverse teams, but I think it's important that they all meet together and try to create synergies for them working together.

Guido: Now that you said that, I also remembered that one of the managers at Wolox, the VP of Operations, he has a weekly meeting with all the team managers, and they have a slot of 50 minutes where they have a guest from...anybody else from the company, let's say the head of Design, for example, and they provide a 50-minute lighting talk about a particular topic. I don't know, like, working with communication between designers and developers, for example. So, the team managers start getting a lot of information about how other teams work, and that's really good idea, and I think I'm gonna start doing that with the People Care team to, you know, have other people on the company tell us about anything. That's a good idea to start. You know, understanding how other teams work, and about their struggles and how they think, I think that's a good idea.

Gonto: Yeah. I like it. We don't do that. Ours is more like presentations on things like plans, strategies, etc., to add feedback, but I actually think that that's a good idea. We do get other teams to present things in the all-hands meeting, where we get all marketing team, and we share something. But I definitely think that that's a good idea.

Guido: Cool.

Gonto: So, we wanted to release a 20-minute episode, and I think we're, like, 45, or something like that.

Guido: Yeah.

Gonto: So we were great with timing. That's the problem when you have an outline and not really a script, but, again, thank you, all, for listening, and we hope you really enjoyed the show. See you next time.

Guido: Bye.

Thanks for listening to this episode. If you want to know more about us, you can check our website inheritedcomposition.com. In there, you'll have a sum-up of our episode, as well as transcripts of everything we have said, and links to everything we've mentioned. You can also follow us on Twitter @theICcast.

Gonto: We love feedback. We're trying to improve this every day. So, if you have feedback, please send it to us at podcast@inheritedcomposition.com. Finally, if you loved the show, please leave us a review in your favorite podcast app. If you hated it, just send it to your worst enemies so that we have more business.

[00:43:15] [music] [00:43:35]

Episode 5 Transcript: Apply transparency in your org in a successful way

This is the full transcript of the fifth episode of Inherited Composition. You can read it below, or listen to the episode

Gonto: Welcome to the 5th episode of Inherited Composition. In this episode we're going to focus around transparency. What does transparency mean, when is it good, when does it work, when doesn't it work, and once you've finished this episode, what we want is that you get out how to apply transparency in a successful way in organizations. Both Wolox and Auth0 have gone through multiple iterations around transparency, and we both believe in transparency, but we've had to make some adjustments as we went through. So in this episode we'll be talking about some of those adjustments and some of the things that we've learned. So first thing that we want to talk about is that, in order to be transparent, something that is really, really important is that you need to educate people before. Why do you think that that's like that, Guido?

Guido: Well, I think you need to spend the right amount of time educating people, because otherwise people may get a wrong impression of what you're trying to communicate or they may not be able to participate in the conversation because they don't have the right tools. So yeah, you need to invest educating people. For example, if you want to discuss, I don't know, something that you shared from a meeting with a board of directors or if you want to share the financials of your company, it's important that at least there is a common base ground and people have a least amount of knowledge that can help them involve into the conversation. So both Auth0 and Wolox have iterated on this a lot, and I think we can discuss a little bit about, for example, sharing knowledge from the meetings with the board of directors. So what you guys did there.

Gonto: So for us, transparency is basically one of our values. It's one of the values in the company. So that's something that we always want to be. And because of that, in the past we've always shared what we discussed with the board of directors, and it was mainly like a big set of slides or the big talk, and then we were doing an all-hands meeting one hour with the entire company to explain and go over the different conversations that we had with the board.

One problem that we had was that a lot of people didn't pay that much attention just because they didn't get a lot of the things. And something that we realized is that, for example, finance goes over their section. Some things that are really important for all investors are CAC, CAC payback, and churn. A lot of people don't know what CAC is, what CAC payback is, how is it created. So then the VOD shared wasn't that useful for people, and they just weren't paying attention, and I think that they weren't given the tools to understand that. So because of that, what we ended up doing is we started doing some workshops on explaining people these things that were important to understand the VOD.

A good example that is sort of related to this is, for example, a lot of people were receiving stock options in the company. Actually every employee in Auth0 has stock options, and a lot of them don't get it, and they actually prefer money to it, but just because they don't get it. So for example, one of the workshops that our CFO did was a stock option workshop so that everybody learns. But something that ended up happening with us is that we felt that the board of directors sharing that wasn't that useful because people weren't paying attention, they didn't understand, they weren't asking questions. So then what we ended up doing is we changed that, and we started sharing, instead of that in the all-hands meeting, we started sharing OKRs.

So something that a lot of people were asking about was, "What is the focus for the company? What is the direction? Where are we going? Why?" And the idea of the board of directors was to do that, like the idea of the VOD was to answer those questions, but because people didn't get it, when we switched to OKRs they all did, because it's more focused on what are we doing in Auth0 next quarter, why, what are each of the teams doing. So that change was very positive, but it doesn't mean that we don't share the VOD anymore, because again, we're a transparent company. We just don't share it in an all-hands because it's not useful, but if anybody comes and asks me or any of the other managers, we'll all be loving to explain it, anything that is in there, but of course with some context so that people get that. What was your experience with sharing the VOD in Wolox?

Guido: It was quite similar. For a period of time we realized that we couldn't share the meeting agenda minutes as it was, because if you weren't there, it was hard to understand everything that was written in that document. So we have to, you know, spend some time editing, rewriting and adding more context, and that took a lot of time, and when you have a meeting once a month, if you take more than a week to it, that document gets outdated quite quickly. And in a company like ours that changes a lot and we are growing a lot, if you avoid sharing document or delay sharing that document for a month, once you get it, it's completely outdated.

So we struggle a lot with that, and we decided to stop doing it, and we didn't communicate that, we didn't say, "Hey guys, we're going to stop sharing these documents because we think no one is reading it." We just stopped doing it and nobody asked for that document. So that was a good indication that we were doing it in the wrong way. But again, we want to share more information with the company. So one of the things we did was similar to you guys, we started sharing the financials, and then we realized that we needed to have an all-hands meeting to explain how to read the PNL from the company, and then the CFO did a workshop explaining how to actually read balance sheets and all the different statements that you can find there and what it actually means.

I know there's a lot of things that we can improve on that direction, but I think that's a good approach, starting to give more tools to the people so they can better understand how the company and the business works as a whole. Also regarding stock options, we give shares to people that have an outstanding performance, and sometimes we give shares, sometimes we give cash, but again, we had a similar situation where people didn't understand what those shares mean and what, at least from the management who think it's better to have shares or stock options rather than cash, but that's also up to each person and what they want to optimize and what they want to have first. So it's important. We learned there that we need to explain all the benefits that the shares and the stock options gave them. So we're probably going to keep doing workshops and keep iterating with them what that actually means. That's something that we're going to put more focus on the next Q. But yeah, so a quite similar story to you guys.

Gonto: What is your plan for the VOD? You said that you stopped doing, but you would like to do it again in the future. Are there any plans? Is there a plan on how to do it again or what's going to happen in the future?

Guido: Well, my actual plan now is, I'm now in charge of handling the internal communication department. So what I want to do for next Q is, for all the shareholders, have a once a month meeting with the CEO, keep an up to date document on what's happening with the company and share that more detailed information with the shareholders, maybe doing a Google Meet or something like that, and probably doing something similar with the rest of the company, like just have a call once a month without having a particular agenda. Obviously I plan to, you know, compile a set of bullet points that I want to share with the company, but open a channel where people can ask me questions, and I'll be prepared with structured information and documentation, but I'm not going to share a document which requires a lot of preparation. I think it's easier to get the answers from me and from other members of the management right ahead, and record those conversations, and if you are not able to participate in the meeting and you want to just have more time to understand what happened, then you can listen to it. I think it's a good tradeoff between structuring a lot of information and having a more human conversation.

Gonto: That makes sense to me. Another thing that you were very passionate about is this fact that you don't think that transparency should be analyzed based on the ROI. Why do you think that?

Guido: Well, we had a couple discussions around this with some members of the management. I do think it's important to educate people and invest a lot on that, and sometimes that goes against your margins, or if you analyze it from an economic perspective, maybe it doesn't make any sense. But I don't think that that's the right mindset. I'm convinced that an organization should rise to the level of education of the people that are involved, and we should give everybody the tools necessary to be able to participate in the conversation. And if that means that I have to invest more resources on educating people, I will do that. So that's why I don't analyze that from an ROI perspective. Obviously you have to take into consideration how that is going to impact your workflow and your batching and how you are going to allocate tasks to your team. But it's something that is completely aligned with our values, and I think it's something important for us to be in.

Gonto: I agree 100%. I'm personally a big believer in being genuine. I always say that I used to be a developer evangelist, and I always say that in order to be a good developer evangelist, I think that the main two features are empathy and being genuine. Being genuine to me has a lot to do with transparency, which is like showing what's happening for real. So I agree with you that it doesn't mean that it has to have an ROI, and for us it's aligned with our values, but I do actually think it has a lot of ROI, because to me a company is people. Like the main thing of any company is the people that are working on it. Not just that, but actually, like, the biggest expense for us for example is headcount. We annually do a survey in Auth0 to ask everybody in the company anonymously different questions, and one of the biggest things that people praised about Auth0 was transparency. They all loved how information was communicated to them and how all of their managers were open to feedback, to questions, and I think that that is something that is, I'm a very data-driven guy, but that's something that is very hard to measure, but if a survey shows that everybody likes that, then I do think it actually does have a big ROI.

Guido: Yeah, and that's something that's hard to measure, but the other day I was having a similar conversation, and we came to the conclusion that sometimes when you share a lot of information and you need to prepare that and invest a lot of time on, I don't know, like preparing a document for example, if you do share that, it's hard to actually tell what was the impact or if people actually value this or not. But if you don't share it, you get people complain, "Hey, you stopped sharing information." So when you share it, maybe you don't get a lot of people saying, "Oh, this is actually really good," but when you stop doing it, you probably realize that people were paying attention.

Gonto: I agree. There's actually a phrase from David Cohen, one of our investors. I think he said that one of the biggest ways of understanding if a product is working is when it goes down. If it goes down and people are complaining, that means it's really important to them, because otherwise they wouldn't be complaining. And I think that, as you're saying, the same applies here to transparency. And also talking about this ROI, I also think that transparency can actually be a very good PR tool. I don't think it is that case for Auth0, but it's like Buffer, the company that you use to share updates on Twitter, Facebook, Instagram, where you just schedule them, they got very, very, very popular because of their transparency not just internal, but actually external transparency, and they share every person's salary, every person's stock options. They also share what investments are they getting, at what valuation, how much are they diluting, and that is a great PR tool for them because a lot of people know of Buffer just because of that. Having said that, I don't believe in external transparency. I do believe in internal transparency. What do you think about it?

Guido: Yeah, I just wanted to say one thing first. Sorry for the background noise. There seems to be a lot of traffic jams outside. So if you hear a lot of background noise, that seems to be the issue. Regarding Buffer and sharing salaries on all the staff, whether you agree with that or not, I think it's a good strategy, not as a marketing resource. Obviously you can use data as a marketing resource, but I think it's a good option to understand the company culture and it's value, and to show people what type of people you want in your organizations and avoid having a mismatch when you're doing recruiting, for example. So you're being open and showing the things you value, the things you want to encourage and the things you don't want to encourage. So I value that on that side. And then each company will figure out what's aligned with their values and if they want to share salaries or not.

Gonto: I agree, and we do share some things externally. I just don't share the salary/stock options, but for example, something we wrote a few articles on, like, how is the company culture at Auth0 and what are the values that we have and why so that people, before they even come to an interview, they already know of them. We've talked about this in the past. We focus so much on culture that we actually have employees whose role is Director of Culture. So that's something that shows how this transparency and other things around the culture are very, very important.

Guido: Can you talk a little more about that? What's that person's day to day job? You hire somebody, like external people to do that? How was the process?

Gonto: No, it's actually an internal person. They were working on another area of Auth0 and we moved them there because we wanted somebody who already knew of the Auth0 culture that could run that team. This person has been with Auth0 probably two or three years, and what they focus on is how can we make sure that the culture and the values are shared consistently and repetitively in the company so that everybody aligns to them? I think that culture is one of the most important things for the company, because that's what's, again, a company is people, so that's what's going to make the company either work or not work. So some things that he works on, for example, he works now on, we have a Q&A with Eugenio, the CEO every one week or two weeks where people can ask questions, and then they [inaudible 00:16:35] That's part of the transparency. Another one for example is that now we have confluence, and each team has blog posts that they share in confluence with updates of their team so that other teams can know also part of this transparency thing. And then other things, we have like value awards where every month we try to talk about value stories, what people are doing, why, and try to show stories of people who are living by our values, basically, and in general it's anything that's going to be related for culture.

Another great thing that we did is actually not related to transparency, but it's called Donut. It's a Slack plugin and the only thing it does is it matches three people every two weeks randomly from the company to chat. That's something that makes me be able to talk with somebody who is a project manager in Europe and maybe a country manager in Japan, and we just talk about random things, but that's something that, even more being a remote company, something that I think is important for the culture.

Guido: Yeah. We are starting to do something similar. That is not actually random, but we started opening offices in Santiago, Chile and Medellin, Colombia. So we have what we call Ambassadors. So some it's some Wolox-er who is in charge of representing that particular office, and we're going to start doing calls with them every 15 days with no particular agenda. But we figure out, that's a good opportunity to start building a relationship with them, share information about what happened in the last 15 days. It could be anything like new projects, financial updates, news from the CEO, what's going to happen in the next few months, anything new that's happening inside the organization, and we give them the responsibility of sharing that information with the rest of their teams. Obviously we do have, like, formal communications that we send to everybody, and we have an internal newsletter, but I think having those informal communication channels is really important, and they know what's relevant from their perspective. It's something that we're going to start doing next week, so maybe in a future episode I can tell you more about it. One quick question about this culture role. Who does that person report to?

Gonto: So we don't have a VP of People. We're looking for now. So for now it reports to the CFO who is also acting as the VP of People. The idea would be that these roles report to the VP of People.

Guido: Cool.

Gonto: So going back to transparency, something else that I think is a big misconception on transparency is this fact that being transparent doesn't mean answering immediately. A lot of people think that being transparent means once something happens you just need to let everybody know, but I don't think that that's transparency. What do you think, Guido?

Guido: Yeah, I agree with that. I think it's important to have the time to think about what happened or what needs to be communicated. It also gives you a chance to control the narrative, especially when something bad happens and you need to explain what happened there. In those cases I think it's really important to be transparent, to be honest, but you need to be able to control the narrative and avoid misinterpretations. That being said, you need to understand what's the best timeframe to share information. And I think I learned that the hard way. But yeah, you don't need to share your information when things happen. You need to share information when it's the best time. So maybe you can share some experiences on that side.

Gonto: Yeah, I agree. I have two experiences to share on this. One was actually this week where we had another company that did a blog post about this supposed flaw in Auth0 that was only a phishing attempt, which if course phishing is something that we need to take seriously, but phishing can happen on any website. And then that got picked up by, like, two big media outlets, and that's something that happened on Tuesday, and we only let the company know on Friday. And we let them know once the situation had been controlled, because we didn't want to inform people without us actually knowing what's going on. So in this case I feel we were transparent. So we might have waited like, two, three days to answer these things, but we were transparent as a whole. And something interesting is that when I did get DMs on Slack from people asking specifically about the problem, I was answering them, we just didn't want to share that with the whole company, again, until the situation was resolved.

I think another great example of that and also controlling the message is, when we had one of the people on my team, on the content marketing team, did some inappropriate comments on Twitter, and because of those inappropriate comments, we let him go. And this is something that, for example, we shared internally in the Slack in Auth0, and it was actually a message from Eugenio, the CEO, saying this behavior will not be tolerated. And this was something that wasn't really good, but it also needed to be shared, because it's about being transparent, being honest, and being genuine, and it is something that also helped us reinforce our values because we acted quickly and we told everybody, "This is not tolerated at Auth0 even today." And thanks to that, actually, we had a diversity and inclusion...It had to do with diversity, we had a diversity and inclusion channel in Auth0, and after this happened it got 4x the people and we have like more and more people engaged and doing things. We now are sponsoring more women who code and doing other things. So I think that from being honest and transparent about the bad situation, we actually got something very good about it. And this is something that to me is linked with, as you were saying, being honest and genuine.

Guido: Yeah. On our side, something that I learned the last few months, it's been a really challenging year for us. We've been growing a lot, and we are accommodating to that growth. So we have a lot of things to do. So we try to make things as smooth as possible, trying to tell people, you know, everything is going to be cool, we're just adjusting to this growth, but actually what happened was that there was a lot of demand, we needed to work really hard and it will be [inaudible 00:23:57] structure of the company to this new company size. And I think that we made a mistake there. We should have been more honest and more transparent in that sense and say, "Hey guys, the next six months is probably going to be a little bit harder, we're going to be growing really fast, and we need to catch up with the company structure. So probably the next six months are going to be a little bit harder. And that was feedback that I got from people from the company. They said, "I'm okay with a little bit of extra work as long as I know why that's happening and where we are going," and we learned that lesson and we took that feedback and that's something that's not going to happen again, but you need to be through that phase and you actually need to hear people's feedback, and it's not always about, you know, giving perks and having fun, which is super important. But when you need to do extra work and you need to, like, you know, just do a little bit of work, you need to be more transparent, and people really appreciate that. And I learned that and I think that's super important.

Gonto: That makes sense. I agree and I think that again, like being honest is something that's key. We had the Auth0 offsite where the whole company meets in Panama. This time we were like 300 and something, and something that to me was important is that we didn't only talk about the good things, we actually had one talk that was delivered by Dave Wilner, our VP of Sales, which was talking about all the things that do not work right now in the company, because I think that's good in several ways. One is, it brings awareness to people who don't know about these problems so that we all know about them, but it also shows that the management team is not playing blind to the problems that we have. We actually know these problems and we're working on fixing them, because I think that sometimes when you don't share the problems people think that management doesn't know, they don't care, blah, blah, blah. So that's why I also think that being honest show them that you care and even though it might take time to solve problems because some problems take time, you're working on them.

Guido: Yeah. And I agree. Some of the hardest problems are probably going to take a little more time to get fixed, but I think it's important to share a timeline and at least share your known unknowns and what are you trying to do to avoid possible problems, and maybe some things will work, some things won't, but at least people get a clear idea that they're doing something about it. So on the other side, when you don't communicate that, people start imagining things, and that's where everything goes wrong.

Gonto: I agree. Any last comments?

Guido: No. I think we're pretty good. Maybe it's a little bit shorter compared to previous podcasts, but I think it's good enough. So I don't know. I'd like to get our audience opinion on this episode. So if you want to share some experience or anything, feel free to contact via Twitter or email.

Gonto: Cool. Again, thank you for listening to the 5th episode of Inherited Composition. We hope you really enjoyed the show.

Guido: Bye. Thanks for listening to this episode. If you want to know more about us, you can check our website, InheritedComposition.com. In there you'll have a summary of our episode as well as transcripts of everything we had said and links to everything we mentioned. You can also follow us on Twitter @DICcast.

Gonto: We love feedback. We're trying to improve this every day. So if you have feedback, please send it to us at podcast@inheritedcomposition.com. Finally, if you love the show, please leave us a review on your favorite podcast app. If you hated it, just send it to your worst enemies so that we have more listeners. Thank you.

Episode 4 Transcript: Working with UX and Design: From good (or bad) to good

This is the full transcript of the fourth episode of Inherited Composition. You can read it below, or listen to the episode

Gonto: Welcome to the fourth episode of Inherited Composition. In this episode we will be talking about how to work with UX and design, from good or bad to great. We first start with Guido and me telling the stories of how design and UX has evolved, both at Wolox as well as at Auth0. During that story, we will mention some of the programs that we've had in the interactions with design and UX, and then we'll go over each of those problems, those seven problems that we will mention, and then mention some solutions for all of them. So let's start. Guido, what was your experience since Wolox was started with UX and design, and how did that story evolve?

Guido: Cool, I think it's important to give a little bit of the backstory about how design department evolved inside Wolox. So going a little bit back in time, seven years ago when the company was originally founded by seven software engineers, so that gives you an idea of how design was involved in the early stages of the company. We had no designers. So the first products that we worked on, well, we have the luxury of, you know, implementing the nice UI's. So you can imagine how gorgeous those products were at that time.

Obviously and quickly we realized that we needed to incorporate some designers, and then we realized that the UX and UI was a key essential part of the product creation process. So the design team grew, and over the years it became the first point of contact right after sales. So the team was resource-constrained, and had the responsibility of understanding the customer needs, understanding the problem the customer was trying to solve, and also help the client diverge and converge in order to elaborate the hypothesis that needed to be tested throughout research, prototyping, and defining the scope of the first MVP. But also they have to work on the UX, the application flow, and how the UI was going to look like.

They also needed some business skills, because they needed to be able to understand the domain that the customer was involved in. Remember that we are a service company, so we work with different industries. So the designer has to be flexible enough to be able to understand the customer's business. But also they have to deal with internal requirements, like for example, make presentations for the CEO, or work on the internal trainings or work on the company website, and the brand and merchandising. So as you can figure out, there was a lot of responsibilities for this small team.

Gonto: Cool. So for Auth0, the story's a little bit different, I think mostly because it's a product company instead of a software consulting. And first at Auth0, we were a really small company, and our CTO, Matias Woloski, is very, very, very design-focused. So design was included from the beginning on everything that we were doing, but at that point everything that we were doing wasn't that much. It was like the dashboard and starting with it as well as some landing pages, but that was it. As you were saying, you know, we eventually had more things like, I don't know, slides for the CEO or slides for somebody, etc.

Having said that, the company started to grow, and then something that started to happen from there is that we didn't only have, like, product needs for design, but we also had marketing needs for design for landing pages, white papers, and other things. And because there was only one design team, we were working with Product and we were having conflicting priorities. So one month, all Design was working on marketing, one month product, one month marketing, one month product, and this is where one of our first problems came, which is what is the focus of design?

From there, we actually created what we called the Marketing Engineering Team, which was a team inside marketing that was dedicated for engineering and design. However, it had a weird setup, because designers still reported to engineering even though we had, at that point, one designer that was fulltime focused on marketing. So here we had the second problem, where designers had two bosses, the head of Marketing Engineering as well as the head of Design. So if they were given like one task by each, which one did they follow and why?

And also something that we started to see here is that we only had one designer, and partly because of these conflicting things and because of other reasons, we were also starting to have some tasks that were taking a lot of time from Design. For example, building a new landing page for a feature or a new product that we were shipping was sometimes taking five to six weeks, and we needed it to be shorter, based on how often we were shipping.

So from there, we started to have a more focused Design team only working on marketing tasks. But one problem that we had in there, and we'll talk more about it, is that Design were feeling that they were order-takers. They were sort of included late in the process and they were given a spec and they needed to work on that spec.

Then again, we kept on moving around time. We then started to have a visual design lead in marketing, and then one of the problems that, as we kept on growing even more and more, was around should design be all together or split into teams? Should we have one big design org that then serves all of the functions, or should we have like one design org in Marketing, one in Product, one in Docs, etc.? And then at the same time from the product side, something that at first we didn't have product managers. So UX, like you were saying, were mostly doing everything. But then we started to have more product managers, and then as well as the growth team and my team started to talk more to customers, do user testing, do interviews, surveys, and then at this point something that started to happen is that UX were complaining that they were both included too late in the process, and they were also complaining that they were receiving a mockup, and that removed their freedom.

So based on both of these stories, our plan now is to start talking about each of these problems that we've both shared, and actually most of the problems I would say have been shared by the two of us, and then going one by one, understanding what was the definition that we did and what was the solution that we have? So the first problem that we chatted about was the focus of design. How do you guys solve that at Wolox?

Guido: Well, I guess we waited until the boiling point, you may say. Yeah, we suffer some of the same issues that you said. There was a lot of tension between the marketing team and internal tasks that needed to be done by the design team, and also working on clients' products. We were tackling these issues with the same team, and one of the symptoms was that, when their professional career started evolving and we needed to provide further, I don't know, teaching courses or lessons or spend more time doing research, they realized that working on brand and product design was a completely different career path. And again, we started having a lot of issues with the operations teams when we needed to allocate a design resource to work on a particular task. So what was more important? Like working on the company's brand or working on a client's project?

So the decision we made there was to split the design team and hire more people to work on the marketing side of the design and keep most of the team working on clients' products and, like, focus on their skills on building products and having more skills on the UX/UI side. And then eventually we came to the conclusion that inside the product team we needed to split the team even further, but we can discuss that later. Now I want to understand what you guys did.

Gonto: So for us it was really similar as well. We ended up also, we had the same problem. It was one month product, one month marketing, and we ended up deciding we need two teams, or we need two people who are specialized, one more in marketing and the other more in product. However, something that happened in Auth0 is that design, as I was saying, is something I think very important for the CEO and for the company in general. So we still, even though we have specialized team, one for marketing and one for product, the marketing team still reports to engineering and still reports to design even though they focus on marketing problems. So in this case, at least for us, it's something that's still weird, and this brings us to the second problem, which is that designers now have two bosses. So what's happening with that? Do you have the same problem where they have, like, two bosses? Or have you completely separated it and they have different heads?

Guido: Well, in our case the design team that is working with marketing reports directly to the marketing director. Obviously they share, like they know what the other teams are working on, regarding high level things. In design they share knowledge. But yeah, they report to completely different people. And I think that's a good thing to do if they want to keep their priorities in the right place. But you have to find a way of sharing knowledge, because at the end of the day, the Wolox brand is impregnated both in our branding material and also in the products that we built. So there needs to be an alignment there.

Gonto: How do you guys do that alignment? How is that working for you now?

Guido: Well, it's pretty early, actually, to tell you, because this plate that we made was pretty recent. And now that we are growing and opening offices in different countries, so we also are assembling design teams in those countries. So we are still in the process of figuring out what's the best strategy, but the design product team, they have monthly or biweekly meetings where they discuss a particular blogpost or maybe a book that somebody is reading. So they share for a couple of hours to share knowledge, and they were also experimenting on recording these meetings, because it was hard for them to get all in the same place at the same time. So they're experimenting with making an internal podcast regarding design. So we'll see how that goes. Maybe in the future we can make it public.

Gonto: Nice, I like that. So for us, as I was saying, design, even though now we have a marketing team, they still report to engineering. And something that we needed to do in there is, like, a lot of working with each of the managers. So as I was saying, something that was happening is, we had one designer that was working specifically on marketing, but she was getting tasks from the head of design that were unrelated to marketing. So there we had to work on two things. First we needed to work with a manager on, like, this can't happen, and we're happy to help, but those requests need to go through the head of Marketing Engineering, because he needs to know everything that's going on with design, and he will be the one who can tell you whether we can do that or not.

The other thing that we needed to do is, we are a remote company, but everybody's always happy to help and collaborate, but once you are more than 300, it doesn't scale. So something that we needed to do is train people on saying no. I remember talking to Varbu, [SP] who was our first marketing designer and talking to her about, every time you get asked something, sometimes you think it's going to be 10 minutes. It's never 10 minutes. It's always like a couple of hours. So by default say no, and just let them know they need to talk to your manager, because he's the one who's checking the priorities and where can we help and when we can help. So that was something that we were working on right now.

And then something ended up happening, as you were saying, is that the marketing team is more focused on visual design and brand and basically less on UX. But that's also a change we did. In our case, it was a little bit more ago, like, I don't know, two years ago or something like that. But something that I don't know what will happen in the future is, like, should we separate those teams in designs. So you were saying that Design in Wolox reports to Marketing. That's not the case for us, but I do think that we should do that in the future, but at the same time, as you were mentioning, we should have a way so that these teams can, like, interact and know what's going on with each other. So definitely happy to understand how that works for you in the future as well.

Guido: Yeah. To make things clear, the design team that works on the Wolox brands reports to Marketing, but the other team reports to the Operations team, which is the same team where Engineering reports to. And last week we made another decision to split the Design team that was working on the brand, on the Wolox brand, and make part of the team report to the internal communications team, and the other part of the team report to marketing. And we realized that we needed to do that because something that you just said.

For example, when we do the internal all-hands meeting at Wolox, we suddenly needed to prepare all the slides for that presentation and all the material that we were going to share across the office, the banners, the flyers, and then I don't know, like invitations for the after office. And particularly working on the slides required a lot of hours, because we needed to work on the speech that the CEO was going to say, align that with the vision of the company, align that with all the expectations that the employees had, and work that with the design team to show and apply the Wolox brand to that. And that took a lot of hours from the marketing team. They were not happy at all, and they needed to do a lot of work for sales. So we decided to do that, to split the internal design team in two teams, and this is something that we decided last week. So maybe in a couple months I can tell you a little bit more about that.

Gonto: Cool. That makes sense. Another problem that we both discussed together about this is that, at least for us, as I mentioned before, some of the design tasks that we had were taking a lot of time, like a landing page for a product was taking like five weeks. And for us, that was a long time, and we're still working on this problem, but I know that at Wolox you had a solution for this. So I'm curious to learn more about it.

Guido: Yeah, this is a little bit weird. It happened a couple years ago when we first realized that the design team needed to be a team as a whole. Like, the engineering team had a head of design and apply more processes to it, but at that time we didn't have a head of design. So what we decided to do was to grab one of our engineers that was working more often with the design team, and put her on top of the design team. So all the designers report to her.

So obviously she didn't have a lot of technical knowledge about design. She had a good eye on design, experience building frontend, but the good thing about having an engineer in that early stage was that she was able to apply the same methodologies that we were using to build software for the design process. So that gave designers more constraints, gave them a methodology to accommodate to, and a way to be able to trace the work they were doing, you know, have their estimates and their metrics. And constraints, I think those are the key, and it happens the same with engineering. You have to give them constraints, because if not, they tend to diverge a lot and try to perfect the design. And at the end of the day, you need to meet a deadline.

Gonto: Can you give a few examples of what was the process that you guys set up, what were the constraints, and what were the metrics?

Guido: It's the basics, like things that we were doing in engineering just like, in our case, having Trello, planning the sprint, allocate or split all the design tasks in different Trello carts, as atomic as possible, estimate them, negotiate with the project manager the amount of tasks that were going to be accomplished in that particular week, and set the right deliverables that we were going to show to the client. And that was really important, like having constant feedback from the client, but in a structured way so we can pinpoint to the right direction, because you know, clients like to give their opinion a lot about design. And sometimes it's hard to figure out what is the right design if your arguments are based on opinions.

So accommodating that with the product process where we actually tried to test our design with users, that also helped a lot. But yeah, I have to say that basically metrics too and the sprint planning was the key thing at that early stage.

Gonto: When you say metrics or sprint planning, what does it mean? Like, was the task estimated and finished on time? Or like, those were the kind of metrics?

Guido: Yeah, I think, like, seeing the errors in estimation that we were having, the amount of hours we were spending on a particular task, and how much [inaudible 00:19:02] in general.

Gonto: That's cool. I think we're starting to have some of those things. So for us, as a visual design UX, they are different. Some of the things we did for this is that, from the marketing side and visual design, something that helped speed up some of the projects a little bit is actually having more than one designer. Like, when you start having more than one and they can work together, interact, the result is better, and a lot of times it finishes sooner. But other than that, something that we're doing, like the growth team is set around doing experiments, and right now we're focusing on retention activation. So we're going to be doing experiments on the onboarding, on the dashboard, etc.

And I remember reading a software engineering book where something that it said in there is, every project has to be constrained in some way, and that can be some constraints either by time, by quality, or by number of features. So you need to pick, but everything you can't have. So something that we're starting to work on now from the growth team and UX is actually having time constrained experiments. So now we say, we're going to do an experiment in the dashboard. It's going to be on the onboarding, you have two weeks, and that's it. Because something that we fight in there is that, our design team is pixel-perfect. And I love the phrase, "Perfection is the biggest enemy of good," because you never ship anything if everything is perfect. And even more for experiments, where the idea is to keep on iterating. It doesn't have to be perfect. So that's something that we're working hard on, which is having this mentality of, it doesn't have to be pixel-perfect to be good. You can ship something much better than what you have, and then eventually iterate.

And at the same time something that I get told a lot, I have to be honest, is that the fact that design takes a lot of time is just a feeling of mine. Maybe it's true. I don't know. I don't have this magic ball, but we're definitely working on different angles to try to solve that.

Guido: Yeah, and I like one of the things that you said about, like, making designers work together. That actually also works really well with engineers, and I think in general. But I've heard designers say that a lot. They work sometimes two designers on the same client's project. So for example, instead of having one designer work on a project and another designer work on a different project, they pair and they both work on those two projects. We have seen a lot of good results after that. I'm doing even informal checks with the engineering team as soon as possible.

For example, I used to work in the floor where the design team was working. I was the only engineer on that floor, and I always kept them discussing and hearing their conversation about a particular project that they were working on, and I gave them my feedback, my opinion on how I would implement that particular features, and some constraints that they were taking into account about a particular STK or API or how a particular platform worked, because obviously I'm a nerd and a I had a lot of technical knowledge that I can share with them. And then they told me that that helped them a lot, like having those 15-20 minutes informal talk, showing me some designs and hearing my feedback was something that ended up helping a lot to the end result of the product.

So we are now incorporating those practices and seeing what's the best way of having engineers and designers get involved in the product design phase as early as possible. And also another thing is having the design sprints, like maybe at the end of each particular sprint where maybe the design allocates a couple hours to review how the engineers implementing all the screens and gave feedback, because obviously you know, you may have a good spec, but there are always cases that we're not taking into account. So sometimes what we try to do there is define a design system which is flexible enough for developers to take small decisions here and there and avoid having to talk to a designer. But sometimes they need to because a new company needs to be designed. So having these weekly checks with the design team I think is a good idea.

Gonto: That makes sense. Another different problem that we had with design is that, from the marketing side at least, they were complaining that they were mostly order-takers. Like, we were giving them a spec on, "This is what needs to be done," already with a lot of constraints, etc., and asking them to do something. So they were sort of, to them at least, included late in this process where we already have all of the order and everything defined, and we just give it to them. I know that this wasn't a full problem for you in Wolox, but something that was interesting for us is, it was mostly because design again reported to engineering.

So even though design reports to engineering, what we did is, the visual design lead is now part of my marketing leadership team. So they will come to all of our weekly meetings, our monthly meetings, our quarterly offsite, etc., and she was saying maybe she doesn't have all the answers, but she has the right questions. And also another thing that's interesting for us is that they know what's going on. They know where the new things are happening with, I don't know, demand generation, content marketing, all of the team. So they already have the context, and by having that context it's easier. Another thing that we did is we are a remote company. I remember that for events and ads, we had like, big problems, because we have the Auth0 brand, and for places where there's a lot of content that's saturated, like an event, you have a schedule of booth or ads, you see so many ads. If you follow the brand, for example, nobody will click on it, nobody will see it, etc.

So something that happened, two things, first of all, is we flew the design team, part of it, from Argentina to the U.S. so that they could meet together. And they started talking about what were their fears, what were their concerns, what things did they think weren't working and why. And by talking about those, what they realized is that they both actually wanted to do the same thing, but they were coming from different perspectives. So the person who was leading the enterprise imagination team, for example, was talking about strategies to increase the people that we get leads or increase the people [inaudible 00:25:40] or things that are needed, etc. And they were talking about being bold, bigger font size, etc., and they were thinking that design didn't want to do that, and it was the opposite. It was just lack of communication. So that's something that by flying them out there and meeting in person and discussing not just about the project, but also about the feelings, as I was saying, what are the fears, what were the things that they liked, what were the things that they were scared about, etc., that increased the team collaboration a lot.

And then the other thing that we did is prove things with data. So we did an A/B test of ads. I can actually put it on the site. I will put the slides on the site, but we have a very ugly ad, which is like a stock photo with text in white that you can't read almost, but it is flashy, it gets your attention, versus an ad that is designed using our brands, and it's statistically significant difference where it's 60% better. Sixty percent better is fucking insane. It's a lot better. So by showing this data we were showing to design, like, the ads that you're making us don't work. We're not using them.

And at the same time I remember I was talking to Ceci [SP] about it and she was feeling bad and guilty because she once asked to use the stuff. So by actually talking with this data and showing how things sometimes work or not and starting both better communication from the feelings as well as better communication from the data, we can now start to plan together. So now we're working on a new branding plan that we're going to be focusing on Q2 and Q3, and then we're going to think about how does branding plan changes for saturated channels, like evens and ads for example. So this is something that definitely started at least our conversation on these kinds of things. But at least adding them to the marketing leadership team was by far one of the best decisions even if they still report to engineering.

Guido: Yeah. In our case it was a little bit different, because early on or at least in the last couple of years, right after the sale process when we closed deal, the next team that got involved was the design team. And the problem there was a combination of, you know, communication problems and having too many responsibilities for the design team. So they were in charge of understanding what the clients said to the sales department, and then focusing on understanding the client needs, figuring out what was the best solution for the problem, try to understand how the business works, make some hypotheses, and try to validate them as soon as possible, and as cheap as possible, avoid having to build a completely MVP to, you know, test some hypothesis.

So that was taking, and obviously, you know the UX and UI. So that took a lot of time. So they were complaining a lot that, you know, products were not specified as [inaudible 00:28:45] or there were too many things that needed to be done in a small period of time. So that made us realize that we needed to split the team again. So now we are building a new business unit called a product unit. So we have product managers and product people that are only going to be focusing on product discovery, idea discovery, diverging and converging, and applying, for example, design thinking, and then the deliverable will be a much specified idea and product for the UX team to start working on the actual application flow, and obviously incorporate designers and engineers in this process. So yeah, that's something that we are working on in this Q and we are eager to scale that team, too, because we think we are adding a lot of value to our clients now. And now I think over the last years Wolox shifted from an engineering focused company, and now I see ourselves as product-focused, as a product studio, and engineering's one part of the process. But it's as important as design, as important as product. So there's no department which is more relevant or important than the others.

Gonto: This is actually, I think, a good segue to our next problem, which was the fact that UX, at least from the product side, we were talking about visual design and brand UI before, but the UX side was also complaining that they were included too late in the process and also that when they were included, they were already given a mockup which was already restricting their freedom or the things that you could do. So I think this goes with what you're talking about, like the product, engineering, and design working together, but when do you think it's a good time to include the UX in this process, and why?

Guido: I think as soon as possible. We are seeing that even having UX people talking with sales to understand how sales are pitching the company to the possible clients and how we are telling them how our process works and where skills, is really important because, you know, designers and UX-ers and also engineers have different perspectives, and that gives salespeople a lot of tools to talk with the clients, and also allying the expectations after the deal is closed. And also, in the product phase, in this phase that we were talking about, you know, design thinking and idea discovery, once we start converging, it's important to have a designer that can place some constraints and start maybe doing some mockups, like low level mockups to give something more concrete to discuss with the client. And also it's important to get engineers in that process, because they can tell you if one of your ideas is feasible or not or can be implemented in a period of three to six months.

Gonto: And what about from the product side? You're, a lot of time, doing interviews or reading, I don't know, analytics to understand what is the next feature or what are the next things you're building based on the problems that you have. Do you think that UX should be included, for example, in these calls and talking to the customers, understanding the problem? Should they be included in the next step, and why?

Guido: That's a hard question. I don't know. I don't think there is a recipe. I think it borrows a lot on the skills that the product manager has. I think it's not necessary to include the UX-ers and designers in every meeting with the client. We have that structure in different modules. So in some particular modules, UX-ers get more involved. In other modules, engineers get more involved, and sometimes businesspeople get more involved. But it's important, I think, to have a weekly check with all the people that are going to be involved in the creation process to, again, align expectations and to have feedback about what you are discussing with the client.

But again, I worked with the design team in the same floor for, I don't know, a couple months, and I think that helped us both a lot. It gave me a different perspective to understand how they were thinking about the product and how they were thinking about the software development process, and I give them also a different perspective, my knowledge, my technical knowledge, and give them more tools to understand how things are going to be implemented when they hand off their work to the engineering team.

So at the end of the day, I would say that it's all of building cross-functional teams, and maybe you have different phases where a particular team gets more involved, but at the end of the day the entire team and the entire profiles should be incorporated during the product creation process.

Gonto: And what happens when you have, like, it happens every time, like limited resources? You were saying that UX needs to be included in that process early. And okay, let's say that that's true. But now you have five projects, you have three UX designers. How do you choose when to include them? Is it, like, do you still include them early? Do you stop the project? How does that work?

Guido: We never stop the project. Now, yeah, that's tough. You always try to do the best you can, and you're right, sometimes you're resource-constrained, you don't have the amount of people that you need for the project that you are working on. I would say that at least allocate some time to have these weekly checks, at least one hour per week. So for example the product people can show what they are working on, get feedback. Getting feedback doesn't take too much time. You can do that even while you are having lunch or maybe you can invite your UX-er friend to have a beer with you and, you know, show them the things you're working on this week, and at least having that informal check is necessary. So I think it's a combination of having a structured process and building the network inside a company so the people know who to talk with.

Gonto: That makes sense. I'll stop with my harassing questions and I'll share some of my thoughts. To me it is a very interesting problem, and I don't know the full answer to it, but I do think that sometimes it gets too territorial. Like UX is talking about, we need to include it from the first step of the process because we are going to be the ones who are going to solve the problem. Product managers are, we need to talk to the customers, get the insights, create the business case, because we are going to be the ones who think about what is the problem. And then the UX team will work on the user experience.

So I sometimes think that it gets too territorial on, like, we are the ones who do this or we are the ones who do this, and I think it's something on the middle point. So to share some of my experiences, now with the growth for example, we're doing a lot of interviews, surveys, user insights, user testing to understand how to improve the dashboard or the product. And then we didn't include, for example, the UX team on the calls because they are working fulltime on other things. But they wanted to be included, but if we include them before, what happens? How will they work on another project, etc.?

And at the same time, if everybody has an opinion, you have a team of like 50 people that have an opinion, shit never gets done. So if you want to get shit done, I think it's about having a racing model where you can consult people for an opinion, but you have a well-defined person of who is responsible. That way it doesn't get that territorial.

And then another thing that happened is, again, I think a lot of people are biased. So to me, mockups are a very good way to explain a thought process. So for example, I got a lot of insights. Based on the insights, I have a thought, and that thought is hard to explain in words. So I just do a mockup to explain that. I send that to UX, UX tells me, "You don't send us mockups. We do the mockups." And I don't think that's right. To me, mockups are ways to describe how you think of the problem and how you think one of the possible solutions would be, but I don't think it restricts freedom. I think the freedom restriction is in the mind of the person who is doing the UX or design, because they feel that they are anchored to that mockup, and that's not true. It's just about sharing something.

So I think that, to me at least, solutions can come from both sides. So solutions can come from, for example, the growth team. By talking to the insights, having ideas, and then doing a mockup, some other ideas can come from the UX and design team. They do another mockup, and then from the two of them, create, like, a mix-up with the best ideas of each, or the person who, based on their racing model is set as the responsible or accountable, he or she is the one who makes the decision of what we are going to be doing. But I think that, to me, is the most important part about that.

And then when is the right moment? I don't know, because we're so resource-constrained, and that happens, I think, in absolutely every company. So would we want to invite them to all of the interviews that we do? Yes, but the more people that you add to an interview, the more hassle it is to schedule it, and maybe we take three weeks to schedule one instead of one week, and I don't want that to happen. I want that to happen quicker, but at the same time, something that I do make sure is that, even when we send a mockup, and that's like a possible solution, we also send what is the problem, what are the insights that we've got, so that it's not only a solution, but it's both a problem and a possible solution so that then UX with the problem can have their own solution.

I think the part that's wrong about sending mockups is when you only send that, and that's the only solution. And I feel that UX in general has been burned so much with that that they are scared of mockups or scared of those things, because they think that their opinion will not be valued because UX is something very new. But I definitely think that UX adds value, but again as I said on, I don't know what episode, but to me what adds the best value is diversity of opinions, diversity from the UX side, from the product side, from marketing, from growth, and then again, the responsible or accountable person will make the decision.

Guido: Yeah, I agree with that. So for me the answer to that question is, as soon as possible. Try to incorporate people as soon as possible. I like making mockups, I think because...

Gonto: I love it.

Guido: I love the designing process. I'm very shitty at making things nice and sexy, but I like, you know, building the mockups, give the designer my high level view of how the application should look like, and I always tell them, "Destroy this. Just challenge it and tell me what you think. This is just my way of showing what I'm thinking." Mockups are a tool and it's a visual representation of how the application should work in my head, but it's a starting point.

And I remember working when I was working on Sumo, part of my responsibility was, I was wearing too many hats, but I was also wearing the product hat. So when I had to give a product specification to the designer, I built most of the mockups and how all the screens should connect with each other. And I remember that that helped a lot, working with the designer, because he was remote, like several hours apart from me. And he received a mockup, he asked a lot of questions, I answered them, and then the first iteration that I got from him was pretty close to the final one. So that helped us a lot to accelerate the iteration cycle. So I will tell you that, yeah, use mockups, and everybody should use mockups. It doesn't matter what's your role. It doesn't matter if you are the official UX-er or the engineer or the product guy or some sales person. It doesn't matter. It's just another way of communicating.

Gonto: That makes sense. I think that with this we've already talked a lot. How much time are we?

Guido: Like 40 minutes, more or less.

Gonto: Yeah, I think we're done. Forty minutes is already too much time for the podcast. So thanks for listening to us, and we'll see you in the next episode.

Guido: Thanks for listening to this episode. If you want to know more about us, you can check our website, inheritedcomposition.com. In there, you'll have some of our episodes as well as transcripts of everything we said, and links to everything we mentioned. You can also follow us on Twitter, @TheICCast.

Gonto: We love feedback. We're trying to improve this every day. So if you have feedback, please send it to us at podcast@inheritedcomposition.com. Finally, if you love the show, please leave us a review in your favorite podcast app. If you hated it, just send it to your worst enemies so that we have more listeners. Thank you.

Guido: Bye.

Episode 3 Transcript: The evolution of learning during our lifetime

This is the full transcript of the third episode of Inherited Composition. You can read it below, or listen to the episode

Gonto: Welcome to the third episode of "Inherited Composition." I'm Gonto, your host, and I'm here with Guido. Say "Hi."

Guido: Hi everybody.

Gonto: In this episode, we're going to talk about learning and how that changes throughout the years. At first, when you're a junior developer or a junior marketer, you're like a sponge, trying to learn every new thing, every shiny thing that appears, etc. But is that good? Should we always do that? So, we'll first be discussing about, like, you read new blog post about a hype and you want to use that hype. Is that good? Should you do that?

Then we're gonna move to talk about, sometimes you see, like, older people, and you think, "Hey, they are comfortable. They don't want to learn new things. They don't want to apply them." But, is that really the case? How does that happen?

Then we're gonna talk a little bit about, like, clickbait titles. Like, "What are the top 50 things you can do to improve SEO?" "What are the 20 things you can do to improve your life-cycle marketing?" Should we read those blog posts? When, how, and why?

Then we're gonna talk about, we're in the time of, like, information, and there's so much information that one of the hardest things is separating real information and things we want to learn with noise. So, how do we do that? How do we avoid, also, analysis paralysis of continuing to read and learn new things? And then, finally, we're gonna have a final question about, like, "Then, is it good to learn new things, what things is it good to learn, and why?"

So, let's start with the first one. So, as I said, the first part I want to talk about is like, you read a new blog post about a hype, and you want to use that hype. So, I have some questions in here. For example, yeah, you use that hype, and then you ship it to production. So, what happens then? Like, do you have bugs? Who supports that? How much time and effort was put into that blog post? How does that work? So, what are your thoughts on this, Guido?

Guido: Yeah, I think as a junior developer you're always trying to learn and, you know, use the new, shiny technology. And you can, you know, talk about you using this framework and being one of the first in the community to have experience with. And then you try to do everything possible to use that. Maybe in your product, or maybe when you're working for a client.

But, maybe you forgot to consider other things apart from, I don't know, like, the language syntax or how easy it is to implement a particular feature with that framework. As you said before, like, community. And I mean, like, the size of the developer community and also the companies that are behind those technologies. What happens when you don't know how to do something with that particular technology? Is documentation good enough? Do you think that that technology is gonna live at least for the next five years?

So, maybe those are the things that you don't consider, and after a while, you start seeing problems because you decided to choose for a particular technology just for the syntax or for some particular feature.

Gonto: And besides that, something that happens is, like, is there support? So, sometimes, like, there are companies that support, like, open-source frameworks, and you pay them for support. Like, do those companies exist? Because maybe you will need that, as there are new bugs, and then nobody's using that technology. And something that happened that I would consider related to that is, like, at first, for example, like, we were working with some of the new, shiny technology at that time, and we were, like, working faster and faster to deliver new features. But then, now we have a product where it's using, like, some old technologies. Nobody's maintaining it. There's no community. So, how do you make changes? And it's hard. And you need to read the old documentation, or read the source code, or those kind of things.

So, it's starting to be harder now, and we're working on, like, how do we migrate to a new technology part-by-part? And you start feeling that technical depth, and that technical depth starts to slow you down. So, then, how do you separate also, like, working on that technical depth versus, like, working on the new stuff? So, maybe sometimes, like, working on, like, these new hypes, you just think on the present moment, the learning that new thing, but then you don't think of, like, what Gonto in two years is gonna say about that technology. Because in two years, maybe, they don't have... Like, AngularJS. A lot of companies worked on AngularJS 1. Now it doesn't have that much support, not that much community. So it's getting harder and harder, for example, to work with that technology. And even more with Components, by [inaudible 00:04:30]. It was, like, their thing to use, like, Components and, like, with dependencies. We used to have that, but now nobody uses that, so how do you work with that?

Guido: Yeah, and also, there are other things to consider, especially if you are in a situation of having to choose technology for the next years for your product. For example, what about getting new talent and onboarding new engineers to that technology? And again, there is no rule of thumb here. It depends a lot on the context. But you need to consider that maybe that new technology or that new language that has really cool features, then it's gonna be really hard for you to get talent and to train them to use it.

And there are stories on both sides of here. For example, I've been following the community a lot, and I'll need, say, a functional programming language for doing front-end development. There's a company that's behind that do a lot of that language that's called Novra, Inc. [SP]. and they've been telling a lot of about being, really, easier for them to get new people because there are a lot of developers that want to use that technology. So they got a lot of applications since they're starting backing the language. And I've heard similar stories for people that are looking for a Haskell developer, for example. They get really good talent because, in order for you to be a Haskell developer, the learning curve is harder.

But there are also stories of other technologies where, for example, it's really hard getting developers in the market for that particular technology. So, in those cases, maybe going with a more traditional or not-as-cool technology is a good solution. And this is a conversation that I have a lot with clients when I tell them, "I'd prefer to go with Ruby on Rails. We may not be as sexy as five years ago, but it's proven. It has a really good community behind it, and it's easier for us to get talent."

Gonto: And also, like, something that to me is interesting is that there are a lot of articles about hype, and something that I always do is, like, check the date of the developers. Like, when was it created? So, if it's old, then maybe what they are saying about the support, the community, etc. is not really that new. I also check, like, who is the author? What is their street cred? Have they spoken at conferences? Have they done research on this? Have they created a framework?

And then, based off of that, you can also think about...that gives you context to think better about their blog post. Like, at least for me, because maybe if it's done by somebody who doesn't have experience working on that technology, doesn't have the street cred, and is only writing one blog post about it, maybe the things that he or she is telling me are not that interesting or are not that important to me. So, that's another part, another tip that I always do for checking, like, if it's worth reading a blog post on a particular hype.

The second problem that we want to work on is...so, we were saying, like, when I was a junior developer, I remember I was seeing sometimes, like, older people. I was working in Globant, and I was seeing older people there. And I remember one of the guys told me, like, that he hated new technologies and how the world was because there were so many options. He actually only liked working with Microsoft because it was, at that point, closed-source. C# and only, like, a few frameworks you had to use. But Java, at that time, had, like, so many frameworks, and he hated that because you had so many things to learn, so many hypes. And at that point, it was like, "He doesn't work anymore." Like, "Why is he not wanting to learn new things? Why does he hate all of these, like, so many repositories, so many frameworks, so many things?" But maybe that's not the case. Maybe these, like, older people have some thinking about this that we don't know. And, why don't they want to learn some of these things? So, what are your thoughts on that, Guido?

Guido: Yeah, and I remember when we were working together that I had a similar feeling with people I respected a lot from that company, that they thought of us as maybe the loud kids trying to play with new things. And sometimes they gave us the space just to play and, you know, be happy with that. But then, over the years, I understood why they were skeptical about using new technologies that weren't proven enough. And again, you may find people that don't want to learn new things and aren't comfortable with what they're doing. [inaudible 00:09:01] But that's true, that happens.

But also, the thing that you need to understand is that people that have more experience than you have a lot of issues, and been...probably suffer from the choices that your junior developers made about technology. So, it's important to understand their position, and trying to have a conversation with them. And saying, "Is this just because you don't want to learn a new thing because you're lazy, or because you don't want us to spend time losing focus, and just doing research, and not moving forward with the project?" So, I think it's a matter of, you know, having the right context to know when you have time to explore new things and when you need to ship and be comfortable with that.

Gonto: Something else that I think that you learn as you have experiences is that technologies, frameworks, marketing tactics, etc., everything...like, history, I think, in general, is like a cycle, that it always repeats itself. So I remember, like, back then, a lot of time ago, like, you had the mainframes. And it was, like, a central computer power, and then the computers were just, like, dumb screens that you sat at. From there, we moved to something where now our computers were, like, really powerful. Lots of processors, lots of RAM, and all of the applications were done in that computer. That was the era of, like, desktop applications. But then we moved to the era of internet, where most of the processing power and most of the things are done in the cloud. And then our computer, this just shows the contents. So, we're basically kind of going back to mainframes. Even though now it's the cloud. the idea, the concept is the same thing.

And I think that the same thing happens, with example, with frameworks. So, for Microsoft, there was a framework called CAB, and it was around, like, having, like, form controls which, basically, you were able to put objects in there, and then the view was that you were going to see objects from there, etc. And that was, like, very similar to what AngularJS was doing. And that was, like, 15 years ago, like, before Angular. And again, like, history a lot of time repeats itself. And I think that as you gain experience, you start seeing how things repeat itself. And then, by knowing the past, it's easier to predict what might happen in the future.

So, I think that as you get more experience, it's easier to understand, "Oh, this is a hype. It's gonna go away, and then it's gonna go back to this or go back to that." So you also have that knowledge, and that's maybe why...it's not that you don't want to learn a new thing, but it's actually that you really already know that paradigm because you've learned that same thing in another way. But now, like, it changes just a little bit, and it's like, "This is gonna be something that only, like, will last, like, a few years, so it's not for me."

So, that's the other part. And also, as you were saying, you know, like, for Java and, like, things like that, they have, like, a lot of support, lots of people using it, etc. So, in those cases, I think that it makes sense to use something that's proven. Even more, if you're doing, like, a big project that is gonna have a lot of code and be maintained for a long time.

Guido: You know, once you start seeing these previous technologies and these cycles, you start, like, seeing the patterns. And it's important to learn your history here, you know? Like, sometimes, some particular communities, they want to invent everything from scratch. And they don't want to look back and say, "How this problem solved before?" Something that comes to my mind is, like, the front-end community, for example. It's...like, doing UI, it's really complex. And we have a lot of history of best-of native apps before. And again, there are some solutions that didn't scale really well, but there are a lot of other solutions that work really well. And we need to learn from previous technology and know what to improve and what not to improve. And so, it's important for new developers to take some time to do some research of previous technologies to avoid making the same mistakes and learn from the good things from the past.

Gonto: Another problem, and another thing that happens, like, very often, is that now we're seeing more and more, like, clickbait blog posts. We're seeing more content that targets people so that you just click on it. Like...

Guido: Fake news, fake news, fake news.

Gonto: It's like, "Three best SEO tactics." "The 12 best tactics or," like, "things that you can do to do," like, "email marketing." And a lot of them are just empty of content, or a lot of them have tactics. So, like, do you think that...is it worth to continue reading those? And, like, why?

Guido: Every time I see one of those titles, I probably don't click on them and avoid reading them, with the exception of if those things were shared by people that I respect. But yeah, I'm very skeptical about those sort of titles, so I try to avoid them. But yeah, I think you need to spend more time curating the sources of the information that you consume. And try to, you know, get sources that you feel comfortable getting information from. And then you can relax and just read them, and be sure to...at least you trust those sources, which is not easy.

And then, as you said before, you know, once you read something that you like, you need to find the problems there. For example, if you like a technology, read a blog post about a particular technology, well, then spend time looking for people talking bad about that technology or, I don't know, raising issues, so you can have the bigger picture about it. Just don't buy the good stuff and that's it.

Gonto: Something that I like about what you say is, like, curation. And for that, I actually used an app that's called Nuzzel, N-U-Z-Z-E-L. And that application basically checks all the people that I follow on Twitter, and it checks the links on tweets that were faved or retweeted the most, and it sends me, like, a daily link of that. So, I only follow people that I think have, like, have good thoughts or interesting stuff, and then that gives me a help to not use these clickbait titles.

And then the other part is that I think a lot of these clickbait titles have things that are, like, big mistakes. So, for example, "The 12 Tips on SEO." Like, those are just tactics, and those tactics might be good for your company or they might not. So, it depends on your company. So, I think that first of all, you have to think whether those tactics apply or not. And a lot of them, as I was saying, were, like, low-hanging fruits or, like, big mistakes.

So, I think that at first, you have to do 'em. And, like, reading at first, all of those posts that are, like, clickbait do make sense. But then as you start reading more and more, they are all the same, eventually. And something that starts happening is that you're reading about tactics without thinking of strategy. So, I also think that you need to focus first on what is your strategy, and then, based off of that, start thinking, like, what are the tactics?

I've seen, at least in marketing, a lot of people saying, "I need to do a account-based marketing." And they want to do it because it's a new "shiny thing" on marketing. However, it depends on what is, like, your target market. Because maybe, for your target market, it discovers new technology solutions by searching themselves, where that means that it's gonna be inbound for you because you can write content. But, maybe your target market doesn't search, and they go to, I don't know, some particular meetup. So then you need to go to meetups and not do account-based marketing.

So that's the part that I think, for example, at least in marketing, you need to understand your audience, understand your target market, understand where their hub is, and then, based off of that, start thinking, "Okay, what things work?" And once you know what things work, then it's time to go to these clickbait titles and understand, like, what tactics you can do for those.

And then the other thing, which is something that I got as I become older that I really like, is everything is the same now. There's not, like, so much new content on this stuff. There's not, I don't know, like, new SEO tactics every day. So I think that a lot of the new knowledge comes from actually reading books that are around completely separate topics and apply it to what you do. And also, in a book, it's probably somebody who, like, put a lot of effort on it, learned a lot, did research, and it goes much deeper than a blog post.

Because I know with the blog posts, even more now, it's shallower and shallower because it's all around, usually, marketing. Like, somebody marketing their own brand, or their company, or something. And that's why they make it clickbait. So, to give you an example, I read recently "Thinking, Fast and Slow." It's an amazing book about, like, cognitive biases in people and how our brain works. And then what we did is, for starting to work on outbound marketing, we're gonna be doing, like, an A/B test. We're doing an A/B test where, for a couple of the messages, we're gonna be writing them taking into account the cognitive biases of people. So, we're applying this thing about cognitive science into marketing to try to see if we can exploit some of them and get more people, not to buy, but to at least pay attention to Auth0, in our case.

So, that's definitely something that I think is worth applying, and "Thinking, Fast and Slow," like, the guy who wrote it is a Nobel Prize winner. He's, like, an expert in behavioral economics. So, why not apply behavioral economics to marketing? And I think you can do the same thing with other topics as well. So, I definitely recommend, more and more, read books that go deeper and apply those learnings to your subject of expertise, instead of going to these shallow clickbait tactic titles.

Guido: Yeah, I really agree with that. And again, I want to reinforce the concept, like, of, "Look for the skeptics." For example, I've been doing a lot of blockchain reading, and having a lot of plans that I want to do blockchain for X, Y, and Z. And I do consider that the technology is...it's amazing, and it could be a breakthrough in different industries. But I also follow a lot and read a lot about the opinion of the blockchain skeptics, because it gives me another perspective of how to criticize the technology and find holes in it.

And a person that I really respect, I like his opinion a lot, is DHH, the creator of Ruby on Rails. He's a really opinionated guy, but he's always on the other side of, like, web frameworks and the cool new thing. He's really...like, he critiques a lot, like, React and all the new front-end technologies. And something that I learned from him that I think is really good is, don't try to apply the same solutions that companies with completely different backgrounds have to your company. For example, maybe React is the best solution for your product. But acknowledge that React solves a particular problem that an organization like Facebook has, who has a lot of engineers that need to work on a huge code base that has a lot of microservices, for example. Well, microservices is another example, that you shouldn't just apply microservices to any new product.

So, take that into consideration. Understand where were the motivations for that organization to create that solution, and try to understand if that way of tackling the problem makes sense for your organization. So, being a 50-engineer organization is completely different from the problem that Facebook has at the scale they have. So, don't try to copy everything they say because they are Facebook and they wrote it. But you need to make sure that the problem you are solving and the technology that you're using fit well together.

Gonto: As I was saying before, another thing that happens a lot now is that we are in the world of information. We're in the time of information, where there is so much information that we're actually creating artificial intelligence machine-learning algorithms that can help us process that information. So, as we start to learn new things, how can we differentiate information from noise? And also, how can we avoid this analysis paralysis where there's so much information that I keep on learning, learning, learning, learning, learning, learning, and I just don't do anything because I don't feel that I know enough things? So, what are your thoughts here?

Guido: Well, that's a tough one, because I like to learn and read a lot, so this is a particular struggle for me personally. But I would say, just start doing things. You know, like, don't spend too much time analyzing what's the best solution. Just try them and see what happens. And we need to understand that we are, most of the time, building a product or solution, and that's where our focus should be. The technology and how we accomplish that, this is something secondary. We need to solve the problem. And obviously, you need to take into account how you're gonna maintain that solution and all the things that are necessary to build a healthy product. But, at the end of the day, you need to solve the problem, and you need to pick the technology that helps you solve that problem. So I would say, like, experiment, but just try the things and get information from the real work to make the final call.

And I think the challenge is of finding this balance between when you're gonna explore, when you're gonna learn, and how you do that inside of your organization. How you generate a culture what is healthy and you have safe spaces to learn, and also know when you need to, you know, deliver and ship a new thing. So, I would like to know how you guys handle that, that tension between, you know, exploring new technologies or new methodologies and moving forward with the product.

Gonto: I think that a lot of things to differentiate noise from information are some of the things that we've said before. So, for example, one thing to me is that we should focus on [inaudible 00:24:01], strategies, and frameworks, and not tactics. Because once you learn a framework on doing something, then you can just apply it to any company and anything that you do. Tactics can only explain in a narrow thing. So, to give you an example, one tactic could be what Airbnb did to start, which was, like, paying photographers to go to people's houses just to, like, bump the pictures of them, bump how many people were, like, booking those. That's a tactic. There's a lot of blog posts about that.

But then you could have a framework on how to create better retention activation for your product, which is around understanding how to create a habit, how to create the "Ah-ha" moment, how to set up the experience, and going through all of that. I've recently done a course called Reforge. They do a course on growth and one on retention and activation, and they really focus on framework and strategies that can apply to anything. They don't give you specific tactics. They give you a tool to pick the tactics. And I think that that's definitely one of the things to be able to separate information from noise. Because once you have the strategies and the frameworks, then you can pick the tactics, and then you can understand which of these clickbait titles will work for you, because some of them you just won't scale.

So, that's a good way to separate noise. And the other thing, as I was saying, is that I think that a lot of blog posts are just done by people who just learned something, and they just write about it, etc. And they don't have the background, they don't have the experience, etc. Lately, I've been reading a lot of books from, like, Nobel Prize winners, because I know that they've done a lot of research, a lot of deep understanding, and then they wrote, like, books about it. And as I was saying, then, applying those books to what you do, you are sure that this person has put, like, enough thought about it. So, this is information and definitely not noise.

Guido: Cool, and maybe regarding engineering, or even in marketing, how do you allocate time to experiment new things without putting at risk the progress and the quality of the product? Do you have a particular, like, technique for that? Do you spend, I don't know, X amount of time per month? Do you have a methodology for that?

Gonto: So, basically, like, how we do it is, like, we treat everything as an experiment until it works. So, we try to do, like, experiments, and for the experiment, we set, like, "What is the problem that we have? What is the hypothesis of the thing that we're gonna to improve? What is the metric that we're gonna, like, check what happens? What is the goal, and what is the timeframe?" And we start doing experiments. And once we see that one experiment starts working, then we spin up a team that will work on that experiment and basically create a machinery around that. And once that works, then we create another experiment. And we keep on experimenting until we find something.

So I think that in our case, we keep on building teams, and we have teams that focus on things that already work and teams that focus more on experimentation. So, for Auth0, for example, at first, like, we didn't know how to attract new sign-ups. So, we had a lot of experimentation around, like, content marketing, type of blog post, where to share, who to share with, how to create the [inaudible 00:27:11], or how to create the content, etc. At first, nothing worked. We did a lot of work on that. Eventually, we got it working. I actually have a talk about that called "The Power of Friends" you can look at online.

And then, after that, we were, "Okay, let's create a team that does content marketing. And I will have, like, ten technical writers that work on that full time." But then the new experimentation that we started, like, two years ago was around, "How can we do better," like, "outbound marketing now, for people who are not developers? For example, are product managers or enterprise [inaudible 00:27:41]?" We started, like, trying different things, different things, different things, and then were finally starting to find something. And then we started to build up the data on that. And now we're experimenting, for example, with, like, [inaudible 00:27:52] relations and public relations. So, I think you always have to keep on experimenting, but knowing when something works and when something doesn't work.

So, lastly, and to sum up mostly everything that we've said in this episode, is it good to learn new things, and why? And what kind of things is it good to learn? What are your thoughts?

Guido: Well, I think that yeah, obviously, learning new things is a good thing. The challenge is how you manage the time to do that, and I want to apply it in the right scenario. But to give you a complete example, for example, I like learning a lot about functional programming. And I think that maybe...well, there is a lot of talk nowadays in the community about functional programming, but I encourage developers to learn about functional programming not necessary to apply that new functional programming language to your day-to-day job, but to understand the concept, to look at how you write code from a completely different perspective.

And then, when you go back to your more object-oriented programming language, you start thinking differently. You start challenging some assumptions that you thought were true, or what's the only way to write code in a particular way. And then you realize that you have a new set of tools to tackle the problems that you have. So, I think learning new things is always good to, you know, broader how you think and get new tools. So, in this particular case, it's functional programming. But, as you said before, it's also good to learn things from a completely different industry to, again, gain more tools. And you never know how you're gonna use them, but it's always good to learn new things. And you put your brain, like, in...it's like going to the gym, you know? Every day, you're challenging yourself and going out from your comfort zone. And you get that muscle, and over time it's easier for you to learn new things.

Gonto: Yeah, I definitely agree with that, and I like your point. Like, to me, learning is about opening your head or opening your brain. And to me, it's around getting new perspectives. So, for programming, maybe, if you're, as you're saying, like an object-oriented guy, learning functional programming is cool. If you're a marketer, maybe learning about, like, behavior and storytelling, etc., could be cool. But to me, it's around getting new perspectives, just because that's gonna make you think differently. It's similar to diversity. Like, you talk to other people because even talking to others is gonna make you think differently. Learning about different subjects and different things is sort of around that. That's why we're talking about, like, reading books from other subjects, focus on strategies and other [inaudible 00:30:47] and frameworks, and just, like, experimenting on new things that you know nothing about. And that's gonna, like, I think, again, like, open your mind.

Guido: Thanks for listening to this episode. If you want to know more about us, you can check out website inheritedcomposition.com. In there you'll have some of our episodes, as well as transcripts of everything we've said and links to everything we've mentioned. You can also follow us on Twitter @theiccast.

Gonto: We love feedback. we're trying to improve this every day, so if you have feedback, please send it to us at podcast@inheritedcomposition.com. Finally, if you love the show, please leave us a rating in your favorite podcast app. If you hated it, just send it to your worst enemies so we have more listeners. Thank you.

Guido: Bye.

Episode 2 Transcript: Moving from being an Individiual Contributor (IC) to a manager of a manager of...

This is the full transcript of the first episode of Inherited Composition. You can read it below, or listen to the episode

Gonto: Welcome to the second episode of Inherited Composition. In today's episode we're going to be chatting about how to move from an IC, or individual contributor position, to being a manager, and a manager of managers, and the managers of managers of managers. We're going to divide today's episode into four parts. Each part will have a context and a problem statement, and then different solutions or case studies that we've had throughout our lives. We're going to start talking about being a control freak and what happens when you stop having full control of everything.

Then we're going to move to talk about what happens when you're a first level manager and you need to enable people. Then we're going to talk about what happens when you need to manage people who know more than you in certain regards. And then finally we're going to close with what happens when you're the manager of a manager of a manager.

Guido: Yeah, and again, this is going to be based on our personal experience over the last few years, and I think it's going to be fun to listen to our different perspectives. Probably becoming a manager in a product company has some differences with a service company. So I'm eager to have this conversation with you, Gonto.

Gonto: So before starting, how did you start to be a people manager? How was the transition? Did you think about it, did it just happen? How was it?

Guido: Well, in my case it just happened. At the beginning, I wasn't really conscious about it. I started working at Wolox after I worked in another software company with you, and I needed to start managing a team, because I had a product that I needed to develop with a client, and I had another group of developers that started to work with me, and I remembered that my first project was with a person that was the first Wolox employee, apart from the founders.

So I don't know, I didn't spend too much time thinking about. We just started working the project, and that's it. But eventually, once I started to work in other projects, I realized that I needed to start learning a little bit more about managing people and try to understand what my actual role was, because I still was a software developer. Most of my time I was writing software, but there were problems and situations that needed to be solved regarding people, and I needed to find a way to learn how to handle those situations.

The funny thing is that, you know, being a software developer, you know where to look for answers. For example, you go to Stack Overflow or whatever. And trying to find solutions regarding managing people is completely different because there is no right answer, there is no formula. You're probably not going to find an answer on Stack Overflow. So it felt different for me. It felt that I needed to do more research than I was used to.

Gonto: I think that for software development you also have to do research, it's just about getting used to stuff. And for me actually, how I learned most around management was actually applying things that I talked with my psychologist or that I learned in meditation or that I learned from philosophy and those kinds of things. But for me, I actually had two situations where I became a manager. First it was in software, where we worked together, and I was managing small teams, like two, three people. I was actually your technical leader, I remember. And it just happened, but then from there, I moved to do freelance and talks, etc.

And then in Auth0 when I joined, I joined as an individual contributor, and becoming a manager was actually organic, and it was around scaling. So I was working on things that started to work and show that they were working. So because they were working, we wanted to create a machinery that made them just continue to work and made me focus on other stuff. And that's how I organically started to have managers and managers of managers, etc., after the organization started to do more things that worked and started to scale those kinds of things.

Guido: Yeah. Now that you say that, I realize that one of the things that is both a good and a bad thing, being an engineer, when you transition to a manager position is that the feedback loop is different. The things that you're trying with your team take more time and it takes more time to see the changes of the things you're trying to do to improve how the team performs. So at first that was tough for me, because I wanted to find about a solution, put that in practice, and see the results right away. But on the other side, I think we're used to a way of working that structures how we think in a way that could be better when you want to scale your practice and tackle the problems with an engineering perspective.

Gonto: Makes sense. So let's go into the first topic. We said that the first topic was going to be about being a control freak, and the main idea is that when you are an individual contributor, you have full control of everything, or mostly everything. You might have dependencies on other people, but you know what you need to do, and you just need to do it. But then when you move to be a manager, that's no longer true, because now you have people that will be doing things that are basically out of your control. So something I want to chat about is how can we fight or how can we live with that need of control? So what is your experience with that?

Guido: Yeah, that's a hard one. I think the first thing that comes to my mind is, you know, trying to let go, if I have to summarize that, is understanding that you have to accept that other people have other ways of solving problems and other ways of writing software, or whatever, and you have to accept that. I think it's about setting the right expectations and defining how are we going to work and what you expect from them, but don't tell them how to do things, and don't try to impose your way of working. You have to learn to let people do their thing with their style.

Gonto: And something I like about what you're saying is that everybody's now talking about diversity, but at first I didn't understand diversity at all, because everybody was talking about diversity, and I was saying, I don't know, like, more women speak at conferences, more people from Africa or even from Argentina, where I am at. But then what I understood is that diversity is not about that. Diversity is about having different cultures and different opinions. And something that I really value at Auth0 is that we are remote-first. We have people from so many different countries, and actually getting a different perspective from my own is something that definitely helps me understand better what to do. And then the other part that you said that I liked is about letting go.

To me, that has to be very together with the expectation management. So in the beginning, something that was happening to me is that I was asking somebody, "Hey, please do this." And then I pinged him one day later or one week later and asked him, "Was it done?" and he was saying no. I was like, "Why the fuck didn't you do it? What happened? How can I work with you?" And then because of that, I started to do more micromanagement, but that wasn't the solution. And what I realized is that the problem, of course, as usual, was me, because I needed to be better at setting expectations.

What that means is that, hey, I want you to do this by January 15. Do you think we can do it or not? And then what you or whoever reports to me should be telling me, "We have these tasks for January 15. So if we need to do this, we need to stop doing these other things." So once you start setting dates, it's easier for people to understand, "Okay, he wants me to do it by that date and he wants me to do it in a certain way." So that way you start talking to them and you start generating these expectations that you have, and everybody starts understanding time is finite, so you need to have a start, stop, and continue. So basically, if you're asking them to start something new, and they don't have bandwidth, they need to know what to stop, and that's something that you need to work with them, I think.

Guido: Yeah, and that's funny because at first, I realized that when I start asking maybe junior developers, "When do you think this particular task is going to be ready?" they usually underestimate the task. And obviously, when you have more experience, you start considering maybe edge cases or maybe impossible integration problems that you think you're going to have, or maybe you're considering that you have to make more documentation or talk with the QA team. And maybe a junior developer that doesn't have the experience forgets about it.

So in my case, it was at first struggling with developers and telling them, "No, I don't think you're going to get that in two days. It's probably going to take a week." But you get the risk of them then relaxing and saying, "Okay, he's always going to tell me a couple more days than I'm used to. So I have more buffer there." So what I did at first was, okay, let's try to break this task together. So how would you implement this? Have you considered these cases?" I was struggling with myself trying to not give them the right answer, you know? I was just asking questions, and try to pick and understand how they think and show them how I think, and maybe converge to a better solution together. So yeah, I think it's a lot about helping the other person go through the process of tackling a particular task.

Gonto: That makes sense. I want to talk more about enabling people in the next section. But before going to that, I have two more things that I think are important, that helped me a lot, is that at first I was asking people and pushing them on, "Is this done? When is it going to be done? What's going on? What's happening?" etc. And people get sick of that. Well, it depends on the personality. But something that I realized is that it's better if I can pull the information instead of pushing them. So using a simple tool as, like, Trello for task management or like a wiki with tasks they need to do, I can then just go in there, see what they're working on, what's done, what's not done, and based on that, I can just ask them questions on the things that I don't get. But I don't need to continually be asking them, "Is this done? Is this not?" etc.

And that was like the pull versus push, where I think that a task management tool can help you do more pull. The other part is that, together with the task management, as we were talking in the previous episode, we're doing OKR's, so objectives and key results. And every person in the company has their own objective, and we check them monthly to see if the key results that drive that objective are being done. And because of that, we don't need to do micromanagement, because everybody knows what to do, and also when we hire people, we are trying to hire more of what we call responsive adults or something like that.

Guido: Yeah, and also I think it's really important not to force a deadline. You know, sometimes obviously you have some strong deadlines that you cannot move, but it's important to get a commitment from the other person, to tell them, "When do you think this is going to be ready? You know we have, I don't know, biweekly sprints. So you know that you have to do a certain amount of work within two weeks. So do you think this particular task can be tackled in the next two weeks?" to try to get a date and a commitment from them and avoid pushing a particular dare. I think that works way better, because then the person says, "I committed to this date. I said that I was able to do this in that particular date."

Obviously you can underestimate or overestimate, and in those cases I think it's a good idea to have a sync up every day and be transparent about that, say, "If you don't think you're going to reach the goal for any particular reason, I need to know that as soon as possible so I can fix that issue or help you or whatever."

Gonto: I think that you're saying [inaudible 00:13:48] etc., to me it's about ownership. Every time that somebody has ownership, they're going to be better at doing that. You were mentioning daily sync-ups. In my case I do actually weekly sync-ups. I chat with some people more, with others less, but I know that every week I have a sync-up where they are going to let me know what have they done, what haven't they done, what are they blocked, and what do they think they're going to ship or do by a certain deadline we agreed, and what we said that they weren't, basically.

Going to the next section, which I think is actually related to this is, like, once you start being a first level manager, the other thing besides losing control, the other thing that you start to notice is that your job is now to enable people. You're not the one who ships things anymore. You're not the one who is actually doing stuff. You're just enabling people to do so. So how do you solve this problem of, like, "I'm not shipping stuff. What should I be doing? How can I work with that? What things can I do?" and those feelings, but at the same time being a good manager and enabling the people on your team to be doing actually a much better job.

Guido: Yeah, for me that was the hardest thing, and sometimes I still struggle with that, because I don't know, if you're a passionate software developer, to stop doing your craft is hard. Every time I get to the point of writing code and get in the zone and forget about everything, I get a really good feeling about that. But that's not your role anymore. Of course, you can have some time to still write some code if you're a software developer or have a particular task where you still are the individual contributor. But that's not your key role anymore. So I had to learn that my role was to help people fulfill their job and grow as a person and as a professional. So that's what I think is the most important role of a manager, that would be helping other people become a better professional.

Gonto: And for me it was pretty hard. I remember that I actually had a conversation about this with one person of my team where he's now leading developer evangelism, and I've done developer evangelism for a lot of time. So he started asking me questions and I was always answering them, and then at some point he started to come to me with ideas that weren't fully baked and weren't fully done, and he was coming to me, so I was telling him, "You need to do this, you need to do this, you need to do this." And that's not good for me, that's not good for him, and that's not good for the company.

So I was talking about philosophy, and something that I really like about Socrates is his Socratic method where what he does is he starts asking questions, as you said before. And that's the only thing that he does, and the main idea is, like, when you come to me with a problem or a question, I'm going to start asking questions to you. So the first thing I remembered is, when he started to come to me with half-baked ideas, I was like, "Did you spend some time thinking about this? Is this finished? Do you want me to review or do you want more time?" And at first, he was like, "Okay, give me more time," and then when he came with a conference idea, it was like, "Okay, who's the target for this conference? Who's going to attend? Who's going to be listening to the talks? Who are the speakers? Why do you think that this is important? How is this going to affect the bottom line?"

And by that, you do two things. First, you help people think. You're enabling them to think and you're making them better, because now they're going to make the decisions. It's not you that's making the decision. And then the other part is ownership, because now it's not me who's telling you what you needed to do. Now it's you who decided what you needed to do. I was just guiding you and asking you questions.

Guido: Yeah, and I think that that's really, really important, and even more if you are communicating over a written channel. So for example, pull requests, when you do co-reviews. Asking questions to understand the trade-off that somebody made in their head that drove them to do the particular design or whatever, or how they wrote the code, it's really important because if you start suggesting ways of how you would have solved that problem, then you are, because you have a hierarchy, you are imposing your solution, even when you don't want to do that. So people will say, "Okay, my boss is telling me that I should do this, and this particularly works. So I'm going to do it because I don't want to get him mad," or whatever. So asking questions is a good way of starting a conversation.

And the other thing that worked really well for me, and I still do that a lot, is, when somebody asks me a question, let's say through Slack, maybe what they are asking is not something super critical that needs to be solved right away. I don't answer the question. I wait maybe an hour, maybe two hours, and then most of the time I get another message from that person saying, "Don't worry. I've already solved the problem. Here's the solution." And I really like that because people tend to go with the quick answer. It's like, they know that you may have the knowledge. So it's easier for them to just ask and get a solution, and don't worry about it. But the problem with that is, yeah, you may get problems solved quickly, but in the long-term that's not a good solution because that person is not learning through the experience of going to do the research, face the problem, and think about it.

Gonto: At the same time I think you're generating a dependency, because the more they ask questions and the more you answer, the more they will come and ask because they know that you can answer or that you will answer. So you're generating this dependency where instead of growing them, they're just asking questions and acting on whatever you're saying, which to me, that doesn't make sense. But at the same time, something that happened to me is like, okay, I'm going to start asking more questions, I'm going to start enabling people, but I really like executing.

I still really like executing, and something that was happening to me, and again, it's like a feeling that probably will go away eventually, but it's like, being a manager and not shipping things, I feel that I'm not adding value to the company. And it's crazy. I know that's bullshit, I know that's on my brain, but the difference from the brain of what I know and what I feel is huge, and there's not a bridge for that. So what I ended up doing is, I actually now book myself time to work as an IC. There are particular projects where I work as an IC. So what I do is I book myself in the calendar four hours every week, or sometimes like six hours every week, to work on a project that's not time-sensitive and that's not in a critical path. The main idea of that is that I get the feeling that I'm doing something myself, but at the same time I'm not delaying anything, and it's something that I feel can add value.

So for example, something I worked on in the past was the new version of the pricing. We didn't have an urge to update it, but at the same time I felt I could add value to that, and it was very interesting to me. So that was one of the projects that I worked a lot of time on. Another project, for example, that I do an IC on now is talking to analysts. So that's another thing that I go, I spend some time, I talk to them, etc., because again that's something that I feel I can add value, and it's just a particular time constraint, like one-hour meeting or something like that.

Guido: Yeah, and it's the same for me. I still enjoy writing software, and probably going to still do it, but it's true, I can no longer be the person in the critical path. I'm not the one that's supposed to write software for a client project. So what I end up doing is I allocate time to work on open source projects that I like. Maybe I want to explore a particular pattern, or maybe, I don't know, learn a new language or maybe improve some internal tooling that nobody is doing in the company and it's not a high priority, but everyone would benefit if something is done on that side. So I take those projects.

Then there's a problem for me, because I cannot move as fast as I used to. So I need to learn not to be that anxious, and maybe an approach that I would take normally one or two months is going to take me four, but it's a good way of letting my inner developer still code and also learn new things and be able to keep my skills up to date and still have conversations with developers and know what's the latest tech. Or sometimes it was good for the company because I used my time to learn a new technology that the rest of the team didn't have the time, and then I was able to introduce that technology into the company.

Gonto: For me, I don't code in my day-to-day life anymore. I actually sometimes do it in my free time. So for example, I was very interested in Etherium. So I started coding smart contracts. So that was another thing that I started doing. So you were talking to me sometime before now about investing time on raising junior devs. Can you tell me more about that?

Guido: Yeah. One of the things I'm proud about Wolox is I think we're pretty good at getting junior developers and raising their skills. But you have to be conscious that you need to invest a lot of time on that. And sometimes it was hard. I remember being on a project and saying, "I need to get this done by Friday," and this person is probably not able to do it because he lacks the experience to do this in this short amount of time. So yeah, the easy answer there is just me, you know, writing code and shipping and that's it, let's forget about it. But I actually always try to spend time with a junior developer and just working side by side doing [inaudible 00:24:45] so okay, I know this task, if I do it, I'll probably do it in an hour, and if you do it, maybe it takes four or five hours. But let's do it together. We'll probably do it in two or three hours, and you're going to learn how I think and probably learn some new tricks.

And next time you're going to be better prepared for [inaudible 00:25:08] and it's a good way also to introduce them to more complex parts of the systems or maybe to different parts of the organization. So I think it's really important to be conscious about it, and sometimes what we do is we over-assign developers to a particular project to, you know, have a quick way of getting a junior developer into a real-world project and give them small tasks that are not in critical paths or are not supposed to be done in that particular sprint. And that helps them to get on track really, really fast.

Gonto: That's cool. Let's go to the next topic. So this is something that personally happens to me a lot. Guido said that it doesn't happen to him that much. It's around managing people that you feel know more about something than you. This is something that, I don't know if it's an insecurity of mine or what it is, but sometimes my question is, I'm hiring somebody that's smarter than me on something, and I think that that's the best choice. You should always hire people who know more than you. But my question was, "How can I add value to these people if I feel that they know much more than me?" And particularly there are two things that, to me, are very interesting about this and that I keep on thinking and that have helped me with this.

One of them is that the people that I manage really value my different point of view. So I'm an engineer, I'm doing marketing. That means I'm better at technical things, growth, I'm good at storytelling, but for example, I knew nothing about integrated campaigns. Now I do because I'm learning, but I hired Carrie, who has done it before, she knows a lot about it. And my question was, "Can I be a good manager for her?" She has so much experience doing integrated campaigns, trying things out. How can I work with her?

She actually gave me, during these two years that I've been managing her, she has been giving me different feedback about this. One was around a different point of view, which to me is something that I never thought about before. But she has experience, and when people have experience in something, they've done it before, and they're going to try to do it the same way that they've done it before because they know that it works.

But because I know shit about that, I can basically have a very different point of view because I was giving her new ideas or new things, and actually from the combination of the two, we got to a really, really good and interesting point, and we started chatting and having good ideas. And then the other part that, to me, is interesting is that managing people is not about knowing and being a subject matter. Actually sometimes there are managers that have absolutely no idea of who they are managing.

Something that I saw is that I'm working with my direct reports a lot about how to deal with stress, how to do problem solving, I talk to them about meditation or things that I've talked with my psychologist, for example, or something like that. All of that stuff, they value it a lot more than I thought, and I actually got comments. They were saying that, because of that, they considered me a good manager because I'm helping them. With one of the guys, with Sika, [SP] I remember that he was always saying, "No," and being conflictive, etc., and he actually told me that working on this actually helped him with his relationship with his girlfriend, which to me is even more amazing. So managing people is all about people, I think.

Guido: Yeah. I just want to clarify that I wasn't facing this situation not because I think I know more than the rest of the people, but just because I was in a situation of managing other developers who were probably junior developers. But yes, I found myself in the situation of working with people that were from a completely different area or have a completely different background, and I needed to work side by side with them. Or maybe me being a cofounder gave them the impression that I was maybe in a high role. But in those cases, what I found really interesting is, it related to what you said. Because you know nothing about that subject, you're entitled to ask some questions that maybe somebody that is an expert in that area wouldn't ask. And that triggers a really good conversation and is a way of unwrapping a problem.

Also, I think in my case it is good to maybe use your, let's call it political powers. So maybe you can raise somebody's voice or maybe you can use your skills inside the organization to help that person accomplish a particular task. So yeah, as you said, it's all about helping people. So in those cases, I think your role is just to unblock people and help them accomplish their goals and be a support on a personal level.

Gonto: Something that to me is interesting about this, and it's related to this, I feel that a lot of this is related to personal insecurities, and there's a lot of talk about, like, impostor syndrome. I love that topic, where you feel like you got there by chance or you don't know why you're here, you don't know what you're doing. And usually that's bullshit. Like, nobody thinks that of you. Sometimes when you listen to people saying, "Hey, this is great, you're the best manager that I've had," you're like, "No, they're lying to me because I'm managing them," or something like that. And in reality, that's not true.

Something that I've learned is that most problems around this are all in your head. And to me, being conscious, as I said in a previous chapter, is the first step. So as you start to be more conscious that all of this comes from thoughts in your brain, then you can say, "I've done this before. This is working. Everybody says that I'm a good manager. Stop listening to those thoughts, because they make absolutely no sense."

Guido: Yeah, and again, it's all about having good communication with the people you work with. So yeah, I think having a regular chat with them, having a space where you don't talk about work and you start growing a personal relationship, they don't need to be your friends obviously, but they need to realize that you are also human, that you make mistakes, and you are there just to help. Once you start bonding on that level, I think the best things are the ones that come after that.

Gonto: There's a post that I read that's related to this that talks about, if you're doing a one-on-one that's not awkward, you're doing it wrong. What I do, for example, with the people that I manage is that I have the weekly sync-up, as I mentioned before, and in there we talk about tasks, we talk about what they're doing, etc. In the one-on-one we talk about, "How are you feeling? What's going on?" etc. I agree with you that it's about communicating with people at a personal level, because then they're going to tell you the real problems that they have, and you can actually help them. What this post was saying is that, unless there's something awkward or weird in a one-on-one, you're not doing it wrong because you're not talking about the real problems or the real things that are going on. And something that I always try to do is share how I feel or what things happened to me, because that makes people share more, and there's a good Ted Talk about the called "The Power of Being Vulnerable," that I'm not going to go into, but it's great. I love it. So you should listen to it.

Guido: Yeah. It's funny, I was just going to say something along those lines. This is something that I still struggle a lot with. You need to show people that you're vulnerable, and you have to be comfortable with that, but it's tough. Maybe we can discuss that on another episode.

Gonto: Yeah, let's go to the last section of this episode, which is, what happens when you are a manager of a manager of a manager. So at the beginning you were managing people, and those people were shipping something. But then you start being a manager of a manager of a manager of a manager, and you're not that close to the people that are shipping. So how can you work on detaching from the day-to-day to work on more strategy topics? Personally, this is something that I struggle a lot with, because I like being involved, but I know I should do it less. So this is a personal struggle that I have right now, and for me, something that I started to do is hiring and training more senior people that I don't have to tell them what to do. They know what to do. They just do it, and basically I talk with them, I give them feedback, I help them out, and it's not me telling them what they need to be doing.

The other part for me about this is that at first I wasn't understanding what's strategy, as I was saying in the previous episode. To me, strategy is just, instead of thinking, "What will happen tomorrow?" or, "What will happen next week?" it's starting to think, "What's going to happen in the next quarter? What's going to happen in the next year? And how can you work to get to where you want to be on those times by thinking and spending some strategic time on that?" And because I was having a hard time with this, something that I started to do is actually book myself time. I'm a big fan of booking myself time. So now, for example, if I want to think about something, I book myself two hours on Tuesday to say, "Okay, I'm going to think on this topic, write a one-pager, and then share it with the rest to see what they want to do."

But this is something, as I was saying, that's still a struggle of mine, because I feel that I still am in the day-to-day and helping with execution, because something that happens a lot is that one of my teams is doing something, another team is doing another thing, and I know that if they were talking to each other, they would do great things together. So for example, we were doing an online meetup the other day, and the online meetup was for developers and enterprise architects. And that was being done by the developer evangelism team, which just does these things for brand awareness. But developers don't like getting emails, but maybe an enterprise architect and product manager doesn't care that much. so because of that, I connected that team with an integrated campaign team so that we can actually do follow-ups on emails and see if they are interested, eventually set up a call or get them to an ADR, and I'm still doing that, like, joining things, which is part of my day to day job right now, it's like gluing things.

And it's something that I want to get out of, and I feel that, with OKR's objectives and key results again, that's helping me a little bit change that, and the other thing that we're doing is we have a marketing leadership meeting where everybody is sharing good updates or blockings or things that they are doing so that they can interact with each other, but as I said, it's still not solved, to be honest. So if anybody has feedback on this, I'm happy to hear it.

Guido: Yeah, I think that's something really interesting about what you said. Being at a high level is all about, I think, breaking the silos, because you are in the position that you can see how the entire company works, and maybe people that are focused in a particular department lose sight of the big picture. So if you are in a position that could take time, analyze how all the things are working together, I think it's your duty as a manager to make different teams work together. And that's where the most rich ideas start to appear, I think. The other thing is that, going back a little bit about what we discussed in the previous episode about culture and making culture explicit, once there are different managing levels, I think a process needs to be set in place, and a lot of things that are part of the culture or maybe things that are in your head, what you expect from managers, once you have two or three people or two or three levels, you need to start writing down how things work so they can be repeatable and you can scale as a company.

Gonto: I agree. Something that happens to us related to that, is that before we were using Slack and chatting in Slack, and everything was in Slack. Slack, things die there and nobody knows. It's like tribal knowledge. So as you're saying, "I'm working with my team to write more stuff in the wiki, have more processes, and break the silos, but again, I'm not sure if that's exactly what I should be doing. But that's what I'm doing now. But again, this is a thing that I'm personally working on now, as now I have managers of managers of managers, which to me is fucking insane.

Guido: Yeah. Maybe to close this discussion, I just want to mention that today I read a post about, I'm going to put it in the show notes, about flavors of engineering management. It's a good post. It talks about the different styles of engineering manager. One of the things it says is, if you are a technical leader that is focused on a particular stack of technology, you have more knowledge of the people that are reporting to you and you have a lot more experience to have a conversation with them. But for example, if you're a product engineer manager and you're at a high level and you manage people from different technology stacks, you most probably lost sight of the particular things of each platform. So you need to start relying on other managers to help you assess if what your particular team member is doing is the right choice or not. So I don't know, I think it's a really interesting conversation, because then a lot of your decisions start to be based on other people's feedback, and you need to develop some sort of intuition to realize which is the good feedback from the bad feedback, and trying to put your own judgement there and try to make the best decision you can. So I really recommend reading that post. And also, we're going to list a lot of materials in the show notes, podcasts that we consider really good. For example, "Manager Tools" is a really good podcast that at least gave me a lot of tools to improve my skills as a manager. And you're probably going to find different blog posts, a couple books. So yeah, let us know what you think about the material. And if you have something to share with us, feel free to share it.

Thanks for listening to this episode. If you want to know more about us, you can check out our website, inheritedcomposition.com. In there you'll have a sum-up of our episodes as well as the transcript of everything we have said and links to everything we mentioned. You can also follow us on Twitter @TheICCast.

Gonto: We also love feedback. We're trying to improve this every day. If you have feedback, you can tweet us @TheICCast. You can also send us an email to podcast@inheritedcomposition.com, or you can tweet me @MGonto or tweet Guido @GuidoMB. Finally, if you love the show, please leave us a review in your favorite podcast app. If you hated it, send it to your worst enemy so that we get more listeners. Thank you.

Episode 1 Transcript: Scaling up from a startup to ... not a startup

This is the full transcript of the first episode of Inherited Composition. You can read it below, or listen to the episode

Gonto: Welcome to the first chapter, episode, or however you want to call it of Inherited Composition. In this episode we'll be talking about how to grow a company from a startup to, I don't know how to say, like, not a startup. I wouldn't like to call what I am an enterprise company. And for that, let us first introduce a little bit about what are our histories and what is our experience with this. What's yours, Guido?

Guido: Well, we started being friends out of college that wanted to do something together. So we decided to do a software company that helped other people develop their products. So in our case, we got offers from different people that wanted to get us to be their CTO, but we wanted to work together, so we decided, okay, there are a lot of people that want to start new companies. So maybe we can be that CTO for them and help them build their technology team and help them build their first products. So that's how Wolox started.

Gonto: It makes sense. For me I was actually at an inflection point in my life. So I've been always coding, and I realized that I didn't want to code anymore for a living, like all of my time. Because something that I realized, I like talking to people, being with people, and I wasn't doing that enough at my job. So I got an opportunity at Auth0 because I was introduced to Matias, the CTO, through Guillermo Rauch, one of their advisors, and I joined the company when there were actually eight people. That was four years ago, and now we are 300 people, and as I said, I'm the VP of Marketing and I have a team of like 30-something people. So it was a crazy experience these four years.

Guido: Yeah. In our case it's been six years since we started Wolox. As I said, we started with being seven founders, and now I guess we are more than hand ranks 65 maybe, around that number. So yeah, it's been crazy. We were a bootstrapped company. So we started as a close group of friends, and now we are at the point that we start maybe struggling a little bit with the culture and trying to figure out how to go to the next level.

Gonto: Which was the inflection point, at least for you? When did you realize that you're not a group of friends anymore, and now you need to be working on scale?

Guido: Well, that's funny. I guess if I had to throw a number, I would say around, I don't know, when we started being over 40 or 50. But I guess the moment I realized that something needed to change in the way we handled things was when...We started having issues when we did inception process at Wolox. At first, I would say the first 20 employees were all friends or people that we knew from college, people that we hang out with regularly. So after office, we were having a party, obviously there was a lot of alcohol, and so part of the inception was drinking a lot and having fun, but then we realized that, hey, new people started to come to the company and they don't know us. So we need to stop doing this. We need to have a more, a different process and more friendly. So that's when I clicked and I said, "Okay, we need to grow up a little bit. We're not teenagers anymore. We're over 24, 25. We're trying to have a serious company. So I think we need to think more about the process of inception."

Gonto: That makes sense. For us it was a little bit different, because Auth0 is VC-funded. So we're focusing on exponential growth, and for us the inflection point, I don't know how many people there were in the company when it happened, but to me it has to do when you realize that culture is not organic anymore. So when I was reading a book, it's called "Scaling Up," they were talking about something very interesting, which is around the number of connections that you have between people. So if you only have like two people, there's one connection. If you have three, you start to have more connections. If you have four, five, and it grows exponentially.

Something that we ended up realizing is at some point culture wasn't organic, and it was something that had to be a conscious decision. We had to consciously say which was our culture. Actually, not just say it, like get it from the employees of the company, and then starting to be conscious about how to we hire and how do we do different things around culture. So for you guys, how was it when you realized that, hey, we need to start working on this? What were the first steps that you started to take to make culture something important?

Guido: Yeah, and to be honest, I think this is something that we're still doing. I would say that we're starting to have formal meetings to discuss what culture meant for us, the things that we wanted to reproduce, and the things that we didn't want to reproduce. So yeah, I think it became part of the agenda [inaudible 00:05:16] that needed to be discussed. So I think it started about, like, putting in words what everybody thought about the culture but was never written. So when somebody new joined the company that didn't know any of the founders or any other employee, we needed to find a way to introduce that person to the culture.

So I think one of the first formal things that we started to do was formalizing the process of having a buddy, somebody that's going to be the person that's going to walk you through the process of getting into Wolox. So in our case that's a process that you're going to be assigned somebody from the team that's going to show you how, you know, the tools that we use, could talk to you when you need something regarding, I don't know, technology for example, or anything related about having your bank account set up, or anything like that. And the small things like, where do we go to get food or the places that we like to hang out. So having somebody that's going to help you get in touch with anybody else.

Gonto: We took it from a very different perspective. For us, once we realized that culture was important, we actually had an offsite of XLT, which is like the executive team [inaudible 00:06:46] like once a quarter mostly, and the first thing that we started to discuss there is around what are the core values, what are the values that we think that every Auth0 employee has and should have. So we started thinking about it, debating about it, and after like four hours or three hours or something like that, after debating it, we had a draft. But we didn't want to push that, because that's what we thought was the culture, but maybe, like the executive team doesn't really know what is exactly the culture.

So something interesting is that then we have like a company offsite. We all go to some cool place because we're a remote-first company, and we went to Cancun. And something like a really cool exercise we did there is, we presented the values and we asked everybody, they put into teams to say which of the values would they remove, which ones would they add, and which ones would they change? Then we took that feedback and we created a new list of values.

And what we are working on now is to have those values as part of the onboarding. So we actually don't have buddies, and that was an idea that we brought up, to have like a mentor, but we've never done it. So I'm curious to learn from you about how did that work. But for us, what we're working on now is to have an onboarding, and it's like a cascaded onboarding. We have the company onboarding which is going to be about the values, then we have the department onboarding, like marketing, and then we have each of the teams' onboarding, and then a person has to go through that onboarding to start feeling some of the culture and the things that we have here at Auth0. So as I was saying, how does the buddy system work for you guys?

Guido: Yeah, I'm going to talk a little bit about that right now, but I also wanted to ask you about the offsite and the buddies. So you did that with the whole company, I mean the executive team first, and then you shared the first draft of the values with the rest of the company, so to discuss about it. That's cool. We had that sort of, like, retreat with the executive team to discuss basically about the future and about values for the company. And now we're thinking of a way of formalizing that and probably iterating that with the rest of the company. So that's really interesting.

Regarding the buddies, I don't know, I think it's a really good thing because if you're new to a company and you don't know anybody there, it's hard maybe, if you're kind of an introvert for example, to get to know people. So maybe you get to a company, obviously you're going to know your manager and the immediate team that's going to be working with you. So what we try to do is to assign somebody as sort of a mentor, which not necessarily is going to be working with you in the day to day. So it's a way to broaden the connections that you have inside the company. So I think that's really good. And also we try different things, like, I think it's called [inaudible 00:09:48] So you can write your name, and randomly somebody's going to be assigned to you to help lunch.

And that's cool, because after a while and after growing, it's hard to know everybody in the company. So that's a good opportunity to get in touch with other people that maybe don't work in your area. Once you start growing, you start in way different areas, different departments. So for example the marketing team or the sales team and the development team. And over a while, people just hang out with engineers, like engineers hang out with engineers, designers with designers. So I think that's a cool way of mixing the groups and having a more holistic view of the company.

Gonto: For us it's a little bit different because we are a remote-first company, and even though we have headquarters in Seattle, Argentina, Tokyo, Sydney, and London, with people there, we have employees in more than 70 countries. So that's very hard and that's why we thought of a buddy system, because it's even more important, because to us, hang out is actually [inaudible 00:10:55] and that's why, like something that I always do in every call if I can is try to start with small talk the first minutes. And also, sometimes it's hard to work or to ask somebody for something if you've never met them.

And that's why the offsite for us is really important. It's one event, one week, all of the company meets together in a cool place and we all hang out, and we do some sort of activities, like you're saying. We do activities where we get people from different departments to meet, and a really cool activity that I like is, as you say, we don't even know everybody in the company. So we actually separate into each of the small teams, so not just marketing, it could be like growth and demand generation, etc., and all of the company is in a [inaudible 00:11:40] and then each team says what they do.

So we are like half an hour, every team talking about what they do. So we bring awareness about the different things that are being done in the company. Like, something that happens here in Argentina I loved is that one of the engineers comes and they say, "Hey, what is this position, I don't know, professional services appliance worldwide?" And those are the kinds of things that we need to learn, because to me it's important to know what everybody else is doing, and also at least one of the values that we have at Auth0 is collaboration. We always try to help each other. So to help each other, you need to know what they are doing.

And then one thing that I want to mention separately to that, is that we actually published a blog post about our culture and the core values because something that is really, really important to me in culture is hiding. Like, we put so much effort in culture that if somebody is very smart, is very intelligent, but he's a jerk, we would never hire them because that's very important to us. So we actually ask even questions in the interview that are related to which of our core values to see if they have the same, because that's what creates the synergy that we all work together in the same way.

Guido: Yeah, that's cool. I think it's really important to try to know what everybody else is doing. We're not a 100% remote company yet. This year I would say we started to be more remote. One of the guys that wants to try to convert their company to a remote friendly company, because well, maybe we can discuss this in another episode. I worked from China for six months. So that was rough, you know? And that taught me a lot about being remote. This year we started opening offices in Chile and a broader presence in the U.S., and also other Latin American countries. So we started going through the process of improving our remote experience.

So starting to know what everybody else is doing is very important, and that's true. One of the chats that I had with one of the managing directors in San Francisco was, well, you know, when we have an argument and we have that argument through Sumo or Skype or whatever, and you are maybe angry and you hang up, that's the last feeling that I have about the conversation. And when you have that sort of argument with a person face to face, you argue about approach or whatever, and then you go and have a beer, and that's it. But when you're remote and you have that sort of conversation, you end the call and that's it. So that person, when she told me that, I said, "Whoa, that's true. I never realized that." So there is a lot that you lose when you start becoming remote. Then you have to pay a lot of attention.

Gonto: That's what I was going to say. I think that's like everything in life. It's all about being conscious, because if you're conscious about things, then you can change them and improve them. One of the things that we do is, I like to sometimes have meetings without an agenda. Because when you work together, you have these hallway chats where some awesome stuff can come up. So what if we do that? What if we think about that and we actually do that for our company? So something that we do is a no-agenda meeting. Let's just meet, and I don't know, we'll see what we talk about. Sometimes we talk about, I don't know, I would say a soccer match, but I hate soccer. So sometimes we talk about technology or something like that, and relate it to work. Sometimes we talk about work, and to me, it's all about that.

Something interesting but unrelated to this is that I think that from those conversations is where the great things come, because to me, innovation in different areas come from applying things from other companies or other areas to what you are doing. But I think we're going very far away from the culture thing, and I think we've talked a lot about culture, but something that to me is also very interesting is how my view changed.

So I remember when I joined Auth0 and I was like, "Yeah, startups are cool. We hate processes. Let's just ship stuff," it's like...So we used to have a phrase. It was, "Fuck it. Ship it." And we can't do that anymore. Another phrase that Joan, our CISO has a very good phrase that says, "God was able to create the Earth and the universe in seven days because he had no install base." And now we do. We have an install base. We've grown. So how do you feel that your view of companies, startups, have changed from when you started with your cofounders to now?

Guido: Well, yeah, that's true what you say. I remember being a software developer when we worked together. You remember that software. I always focus on coding and the latest framework or whatever. I remember having that feeling, okay, I'm going to start a company, I don't want to be a big, huge company full of processes. We don't need that. And for a while that was cool, and that gave us a lot of agility. But then when we started to grow, and for example, in the first days, we were doing everything. We were doing sales, we were doing project management, we were doing software development.

So maybe one or two people had the entire overview of the company in their heads. So there's less communication that you have to do because everybody knows what everybody else is doing, everybody knows how the full process works. But when you have a sales team and an operations team and they're really decoupled, you need to have a way of handing off from one department to the next one. For example, from sales to UX design, from UX design to the engineers. So obviously we learned the hard way and we keep learning, but that was the moment we said, "Okay, guys. We need to write down what happens between each phase, how do we sell."

I remember also onboarding new engineers. So at first it was, "Okay, hi, you're going to be working with me. Here's the repo, check out the project and start coding. And if you don't know something, ask me and I'll teach you." Obviously that didn't scale very well. So yeah, we had to start thinking about, okay, what are new engineers going to be working on? Obviously the first month it's not going to be as productive as you expect. So you have to teach them your ways of building software, the tools you use, the process, how you create the pull request. And if you're a junior engineer, what a pull request is and why it's important.

So in that case we started thinking about building the trainings. So you're working a toy project and you exercise through that project. So each area had that training and onboarding process. And that's when I realized a process is good. It gives you way of thinking that can be reproduceable.

Gonto: I like particularly two things that you said. One was around, like, people had all of the knowledge in their head. So they just could talk to each other. And at Auth0 we talk a lot about that, which we call tribal knowledge. And something that I feel that happens is that Slack is partly a creation of that, because you have tribal knowledge in your head, and then you chat about it, maybe you share it, but then it's lost in Slack. And that's when we realized that Slack is great for chatting, but it's not great for the other things, and we needed to move that tribal knowledge so that everybody could know about it.

So things that we did there, for example, was like starting a wiki and starting some onboarding. But at the same time, that tribal knowledge generates problems, because when somebody has the tribal knowledge of everything, everybody goes to that person. And that creates that culture of superheroes, and who doesn't like to be a superhero? Who doesn't like to save the situation? And what that means is, I'm the only one who knows everything. So if you want to do something, you need to come through me and I'm going to save the day. So something that I think is very important as you grow is moving from that superhero culture to something that is like organizational excellence.

To me, I hated processes, to be honest, because I felt that they were bureaucracy, that they were like, "Oh shit, I need to fill in this form, it's huge, I don't want to do it, it's a pain in the ass," but then when you start thinking about it, you can create a lightweight process that doesn't create bureaucracy. And at the same time, something that's very interesting to me about this is that the processes are needed, because if you don't have processes, if you don't have a racing model, then how does execution work? Because at first if you're, like, four people, it works. But once you're a 300-person company, how do you execute if nobody knows what they are responsible for, what is the handoff for other teams, when is something done? And all of those things, like the definition of done and the handoff are processes. So sometimes processes sound very bad, but maybe they are not.

Guido: Yeah, and that's funny because I think, what's the first thing that you try to do when you identify this problem? You read a book, you read a blog post, you talk to other companies, and everybody is going to tell you something different. Obviously there is a lot to learn and there is a standard way of doing things, but I think also that processes should be tailored to the company, and that's the hard part, because at least for us it's like, you have to learn what a good process for your culture, for the type of company, and for the type of business that you're in. It's going to help you be more effective. And that, I think, is a journey that you have to go through. There is no way of keeping that. And that's the hard part. I think that a lot of companies struggle with that. I think we are still struggling with that, and it's something that you have to keep improving. It's probably something that is never going to end. So obviously you start building off a solid foundation, but you have to be flexible enough to realize when the process stopped working and needs to be updated.

Gonto: I agree, and one of the funny things for us is how we started to define one of the most important processes to us, which is from product ideation to shipping. Because at first we thought that, like, just shipping a product or feature is like merging the code. But there are so many more things, because auth marketing we need to know because we need to check what is the retention activation, we need to do a PR release, we need to do a blog post, we need to, I don't know, maybe write a white paper, put it in a campaign. Support needs to know because they need to know how to answer questions, CSM needs to know because they need to talk to our customers about the new features to see if it's good for them, sales needs to know so that they are able to send the feature. And all of those handoffs need to be done.

So we started to prepare that. We did an offsite, and it was an interesting activity. So the first thing that we did is we went and we defined the timeline of one of the products that was shipped. And it was actually like three white boards. And it had so many problems. It took one year and it was, like, insane. So after that we actually separated into groups and we wrote sticky notes about which were the problems, and then we clustered them, and then we used that as a unit test. So those were the problems that we had, and then what we wanted to do is, we worked on defining a new process, and then those problems were the unit test to see if that process solved the problems that we had.

I remember that the first version that we came, of that process, actually solved 40%. At first we were like, "That's too low," but then if you imagine that it comes from nothing, doing 40%, that's actually pretty good because if you aim to do the 100%, it will never work, and that's why Matias, our CTO, has a very good mantra that I love, which is, "N+1 is greater than N." So what we are trying to do is work on the problems that we have, what are the problems that we have, use that as a unit test, define the processes, and then keep improving them as we can. And that way it's tied to our culture because it's tied to the problems that we have as the company keeps on growing.

Guido: Yeah, one of the tipping points for us was this year when we started to become a more metrics-driven company. This year was rough. We had to change our entire sales process from scratch. And obviously, now thinking back, it was a really good thing, but at the moment it felt really chaotic. It's like, we need to improve how we are reaching our goals. We need to completely destroy what we're doing now and think about something completely new. So the first thing you say is like, where do we start? We know what the end goal needs to be, but how do we get there?

So a couple months were rough and we had to tell everybody, "Okay, we're going to change how we're working. So everything is going to be different from now on, and we have to move fast." That's the thing. You don't have enough time to, okay, I'm going to think about this process and see how it goes, and take my time to iterate. No, you have to react really fast. So after a couple months we were able to become a more metrics-driven company, and we still have to do a lot in this area, but it's really important when you start thinking about the metrics and you start thinking how the things you do impact a particular metric and that ties to the objectives of the company.

Gonto: Yeah, so one of the things that we're in the process now is, so we are working, and we were working very hard on execution. We're actually using our own model about goals and OKR's, it's like a mix of it. But the main idea is that every person in the company has some key results assigned to them so that they know what to do, and those key results have to be measurable. So it's either a metric or a delivery or a milestone or something. So that way we're cascading something, and that's our process. Our process is like, XLT, the executive team defines the goals, they define the key results, then each of the department leads goes with their leadership team to define what are their goals, what are their key results, and then each of them goes to their teams and to their teams and to their teams, until everybody has goals, everybody has objectives, and everybody has key results.

And to me, the good thing about that is that then you know how you, an individual at the company, are moving the company forward, because you know how your key result is linked to the objective of your area, how that's linked to the objective of the department, how that's linked to the objective of the company, and how that's going to drive the company forward. So I agree 100%. And one more thing, unrelated, that I liked is that you are saying that you had to move fast. I sometimes feel that we are on a plane at like full speed, and we're changing the engines, we're changing the windows, we're changing everything while we're going. And even though we need to do that because it's around exponential growth, it's innovation, at the same time something I like is, like, Chris Peck, our head of product, he sometimes says that to move fast you sometimes need to move slow.

That's something that we are starting to accept, because when you start doing things like everywhere, it's a mess. And that's, to me, where processes fit. Processes make some things move a little bit slower, but greater quality, and then overall it's faster. So when we did this exercise that I mentioned before, I remember that to ship a feature fully, we took one year and a half, and we were always running. And when we stopped running, then maybe we can ship it in one quarter. So how is it that by going slower, we're actually going faster?

Guido: Yeah, that's weird. The other thing I wanted to discuss, maybe this is a discussion for another episode, but how do you pick the correct metrics? Because if you pick the wrong ones, you maybe encourage behavior that you don't want to foster in your company. And maybe you don't realize that until it's too late or maybe after, I don't know, a couple months or next quarter. Maybe you hit your sales goals, but that affected the culture in some way or how the team relates with the operation teams. So that's tough. Picking the right metric is really, really hard, and I don't know if there is a right answer for that.

Gonto: I think that for picking metrics, you're always learning. Something that I think is the first thing that should be chosen is, what is the north star metric? Like, what is the north star metric of the company? And that to me is a metric that's linked to activation and retention, because if your acquisition is working great, then activation and retention metric will work. Then if your activation and retention is cool, your revenue will grow. But at the same time, you cannot act or do changes based on a revenue metric, because if you're like us, a B2B, the sales cycle might be longer. So we might take, I don't know, 90 days to sell something. So we can't use that metric to understand if we're doing okay or not. So we need a proxy metric. And to me, the north star metrics are very good proxy metrics. But having said that, I think we're always learning. I remember our first funnel for activation and retention in the features and the usage. And at first, when we finished it we thought that everything was going down and that the company was going to go to shit, because everything was going down.

And then we realized that the problem was that we weren't being fair, because we were giving the people who signed up one month ago, one month to get, like, features and things approved and done, and then we were giving the people from yesterday just one day. So once we realized that, we changed that to actually start showing the metrics based on a cohort view, because what that led us to do is, like, from the people who registered in March, what happened the next month and the next month and the next month? We're giving everybody the same chance to get to something, and at the same time, by having one line per each cohort, if you make changes, you can see the differences in conversion rates, or if something is going up or down. So now I'm a big fan of cohorts, and I think that's a thing that we need to do everywhere. But probably, like three months, I'm going to say, "Oh, the cohorts can do something, and then there's one more thing."

So to me it's not about picking the ideal metric. There's no such thing. To me it's about continually be thinking about evolving about which are the metrics that matter.

Guido: Cool. I think this was a good start, I'd say. Obviously we could be speaking for the next two hours, but I guess it's a good stopping point. Maybe we can continue this topic next episode, or, I don't know, maybe we can talk about a completely different thing. Who knows.

Gonto: Something that I would like is, this is the first time that both of us are doing a podcast. And I really value honesty and feedback. So if you guys have any feedback, you can tweet it to us @TheICCast, or you can also tweet it to me, @mgonto or you, @guidomb. And we'd love to hear feedback on what did you like, what didn't you like, what topics do you want us to cover, and any other things.

Guido: Yeah. That's cool.

Gonto: Thank you guys for listening. As we say in the first one, we hope you guys enjoy the show.

Guido: See you next time.