Adopting Shape Up Through a Series of Experiments – Juan Villarejo (CTO & Co-founder at Nulinga)

I wanted to change the dailies because we have daily meetings every day and I didn't want that. I want to have like, okay, let's the dailies, let's be written like hard check-ins, written check-ins on Slack. And a few people on the team didn't like that. I tried to explain that always my point of view is, okay, let's do an experiment. that didn't work for the whole team we can go back so that was my first like assessment of experimentation with the team right the team was maybe at some point somewhat opposed to change a few things but when i put the the side of let's do experimentation they started to embrace more the the the to adapt to change or try new things Welcome to Shapers and Builders, the show about better ways to deliver great software products. Today I'm speaking with Juan Vicharejo, CTO and co-founder of NuLinga, an online language learning platform. Before founding NuLinga, Juan founded Sinarutina, a subscription service for fitness classes, which was acquired by GymPass in 2018. This conversation is part of a series about companies that use Shaper. a delivery framework originally created at Basecamp. If you've never heard of ShapeUp, check the show notes for a link to the video Shaping in a Nutshell by Ryan Singer, former head of strategy at Basecamp and author of the book ShapeUp, Stop Running in Circles and Ship Work That Matters. In our conversation, Juan and I dive deep into how he's introduced ShapeUp via a sequence of small steps and small wins, how to protect the team's focus, how to help people move from the builder to the Shaper side, and the role of what Juan calls full-stack designers at Nulinga. Juan has been a co-host of two meetups for the Shaper practitioners meetup with me recently, and he has generally been an incredibly active and helpful member of the Shaper community. I'm very excited for you to hear what Juan had to say. All right, Juan, thank you so much for taking the time to speak with me today. Before we get into ShapeUp and all of that, I wanted to ask you to, if you can please describe just briefly kind of the arc of your career and how you got where you are now. Okay, perfect. I will try to be brief, but maybe it's a little bit long story, but I started, I studied software engineering. I changed my career in the middle because I started studying electronic engineering, but I liked software better. And when I started to program in Ruby or try some high level language, you kind of fall in love with them. And the electronic engineering aspect was more like too low level. And that's why I kind of started growing my career in software engineering. My background is mostly a developer and then started working for different companies for mostly software factories that they on the side of consulting. Having had like now is like 14 years of experience in the industry. I work as a freelancer also mainly working as a remote worker for different as a freelancer consulting and but then i started my own business with some partners we called it sinrutina yes well we build our own startup it was mostly a marketplace for fitness access as a subscription based um maybe similar to what is now gym pass or class pass we ended up selling that company we we had an acquisition by gimpas it was very good for us we started working with them we stayed for them with them for two years and that was on 2018 the the acquisition and then to 2020s just before the the pandemic at the end of 2019 uh i started another startup another company for for us it's called nulinga where well we started growing a lot which also is like a language learning solution for b2b for b2b market we offer language learning solutions and access to language learning teachers with english portuguese and spanish uh for the employees of a company so they can have private tutors and where we are building all the software the operations all the distribution and commercial side we are kind of 50 employees now how do those 50 split across uh kind of the engineering side the product org and other functions the areas is a commercial side I will say that half and half. Half is on the supply side and half on the demand side, from the distribution, the commercial side, selling and executive account and client success. But on the, what I call the demand side, sorry, the supply side or the production side is called, we have operations and on the product team. uh the product area we have like um we are 10 people right now uh let me i will check it but it's uh 10. we are like um as i always say what we cannot build right now we kind of supply that with a human power right with people executing things on there on the on the system uh manually executing some stuff uh we call that operation But of course, we want to, the whole development team want to build things and automate stuff. So the operation team doesn't scale in the same way of the whole operation, right? The whole business as a scalable company. One thing I kind of want to make sure is that when people hear your story, that they can kind of in their head compare to themselves how similar is where you are with Newlinger to where they are in their company. And so what you've said is you are about 50 in total, then 10 on the kind of product side. And the company was founded in 2019. Would you... still call yourself kind of early stage startup or how would you how would you kind of describe the life cycle of the company right now it's an early startup in terms of the the business size we have a one one million ARR mostly near right that so in kind of that we are we are an early startup but our goals this this year as same as other startups is to aim for profitability and we are going for a break even in a few months so that's okay we are we want to be a owner of our own domain and in terms of our of our own future in that way so we can that's we don't need external funding in order to keep the operations right and keep on growing of course growing will be a little slower but the the objectives are are those and we kind of want to keep pursuing this business because we think there's a good opportunity nice sounds good fingers crossed You mentioned ShapeUp, so why don't we kind of get into that? Perfect. And to kick things off there, I wanted to ask you, how did you get into ShapeUp and what were your first encounters with it? What was your initial reaction maybe? Well, I was a big follower of Basecamp from the early Signal B Noise blog. I was reading a lot about, well, I'm a Ruby on Rails user from Rails 3, right? So I'm very fan of Rails and also Ruby. So the thing is that when I saw, I also very fond of some of their philosophies. I tried to hire managers of one and try to to have small teams very streamlined me as an entrepreneur and builder I was I had a very good I don't know knowledge or tacit knowledge from what I need to do from a raw idea to ship it right but when I were when we were writing epics for scrum and planning the thing is that when i delegated i wanted to delegate those in into the development team because as a very early startup i wanted to keep on building things right i have more the more productivity was on my side because i could i have the business i have some ideas from design in terms of interactive design or flow design and also i have technical knowledge for implementing it so i wanted to keep on doing because if i become full managed i my the productivity of the whole team will be will go down and it wasn't working like that because when i delegated some epics and some my raw ideas for the development team for each of the developers they were just constantly asking me things, right? Because the idea wasn't shaped, the idea even wasn't framed at least. It was, okay, we want to do this. Okay, that's the use, the user story, right? Or the epic story and the developers should write the... I was expecting on that side to developers to write user stories or at least help them write the user stories in terms of there. But it wasn't enough, right? Because they would... keep constantly asking me, okay, okay, I did this, I did this. Now what's the decision about this? What's the decision about that? Maybe because our hiring budget wasn't high enough. They were very oriented product engineers, but they still weren't aware some, they didn't have too much experience on some sites. So they were asking me also some technical aspects. I didn't matter about the technical aspects because I can help them and we do some, we try to work with pull requests and review stuff and have a common knowledge. But there was some struggle in terms of that I didn't have enough time to dedicate. I will be coming full manager and it wasn't working as expected in terms of, in terms of it was being demanded all the time. I didn't like that. And that was pre-2019? Second quarter of 2020. By that time, I'm sure you must have heard already of ShapeUp or the early kind of ideas floating around, right? In various blog articles. Exactly. So what did you do? I wanted to change the dailies because we had daily meetings every day and I didn't want that. i want to have like okay let's the dailies let's be written like hard check-ins written check-ins on slack but let's stop doing some daily meetings uh synchronous um on that i put that on the retrospective for me this wasn't working and a few people a few people on the team who didn't like that didn't like that proposal for from my side i tried to explain um that if Okay. My, my, always my point of view is, okay, let's, let's do an experiment for the, these two sprints. If someone, if that didn't work for the whole team, we can go back. Nothing is written in stone. So that was my first like assessment of experimentation with the team, right? The team was maybe at some point, some opposed to change a few things. But when I put the the side of let's do experimentation they started to embrace more the the the to adapt to change or try new things um because the the these people were coming from also from other companies that do very by the book scrum right and when i wanted to introduce shape up i also try the same and we have like two develop three developers and two designers at that time so what I the scrum was the sprint was two weeks per sprint and what I did was to propose to propose three weeks per sprint right let's do three weeks per sprint on that side let's try it and once I have once I have that set And the people were comfortable, okay, we have three, three, three weeks per sprint. What I did was to try one developer and one, one, on the next cycle, one developer and one designer to work as a shape up to a method, like a proof of concept separate, like an experiment. And for, of course, shape up says, okay, we can do an appetite. we can do cycle of six weeks, but I didn't care about that. I think, okay, I took the appetite or the this week cycle, the number of weeks per cycle can be changed because it's not written on stone. It depends on the projects that you have. So I understood that. I understood that that was on myself and how much do I want to bet on the projects. And I say we can do some projects like three weeks so we can, I don't have to change that too also for the whole team. So that's why I started to shape a project. I tried some three, I say, okay, let's do three weeks plus one, right? It's one month on that side. And well, that went well, the project, the project went. went smoothly and the the team the the team was very happy to deliver something i was very comfortable because what changed in that project um what i think that project proved is that okay during the week during the cycle this proof of concept cycle i had the team i still help the team and and and be with them with some uh I helped them with some requirements, but I was helping them mostly on some technical aspect on how to solve some things in the technical way because I was CTO too. But I didn't, but, but that, those, those problems that they have wasn't blocking problems that they could continue or, or, or doing some work. They were just helping them in terms of quality of the output, quality of the software. but I didn't have to be on the, mostly every day or maybe on demand about decisions, about the business of decisions, about the flow decisions, about the interaction decisions, about what the user is expecting in some parts because it was written and it was clarified on the pitch. And now it's called package, but now it's on the pitch. And that's what I, it made me a click. Okay. i can help them from the technical side i like to be on them i can also most here it's more asynchronous because we do some pull requests and i can write them there but i don't need to to kind of uh how do you say go into the rather into the rabbit hole every time on during the cycle that was what myself and the team really liked about shape up so just so i make sure I get it right, what you mentioned was kind of this move from two-week sprints up to three-week sprints. And then you kind of also split the team where you kind of created these cycle teams, these kind of shape-up teams of one developer and one designer. And in that process, were you also removing yourself as an active contributor in that when you were still working with Scrum, I assume you were actively working on tickets yourself and that changed in the process as well? I didn't have to tell them what should we do, right? Because the what should we do was defined on the pitch. Before, during Scrum, the answer to the question what should we do had to be answered mostly, I would say every day, but two or three times per week i that answer what should we do now what should we do now was being answered every time and constantly on demand and and that's that's uh that's very very difficult if you want to think about also the other projects i don't know other problems that appear on the on the on the business side on the software side um and plan what should we do next right okay now we are working with this but what are we going to work next And I couldn't think about that because I was always on demand about what should we do now. How did you justify to the team that you wanted to kind of move to three-week sprints and pull yourself out of kind of daily or weekly questions about what do we do? Did you mention ShapeUp as a thing to the team at that moment? Yeah, I mentioned ShapeUp to the team. I think I like to experiment with new things, to try new things in terms of the process, right? And then, okay, we are working with this process. What can we improve? And the retrospective also helped that to acknowledge and know about the team, how the process was working. And I think on that side, I think the retrospectives helped me in order to introduce to the team, the Scrum retrospectives, because that was the, as I said, and I introduced that, it was a safe space for us to talk what was not working. And having this experimentation view or mindset put the... uh set on the team before because i changed the dailies i proposed change the dailies and the and the team the team knew okay oh this experimentation went good okay i think those that side uh maybe i with that perspective i gather more trust as a leader for the team because leaders, we need to be trusted as a team and propose and bring safety in those terms. Because I sense that the team was having some struggle and say, okay, this is going to change. And what if it doesn't work? We will continue doing that. Because I think some companies maybe just impose some things and if the team isn't comfortable with that, they skip. keeping doing that right uh but i i i clarified with the team hey with with changing the dailies if it doesn't work we go back uh if or if it doesn't work let's know what did it what didn't work and let's fix that i'm always fond of this uh kind of uh feedback feedback loop from the process and reiter iteration not only with the product but the whole company and the whole processes. And that was one main point that I gained trust with the team. And when I proposed ShapeUp and they say, okay, let's try. So you kind of, you built up to it. You got the team used through these little changes. Exactly. To kind of, to a bigger... Maybe similar to the myth or the story of the toad in the... in a stove that is being boiled, right? You kind of turn the heat a little bit slow so it doesn't feel that the change was from one moment to another quickly. Just not with the outcome of kind of an untimely... No, of course, of course. This outcome is trying to be better for the whole team, the process and the business. So before when we spoke, you also mentioned to me that you went to the, I think it was called the Shape and Chip Workshop, or I don't remember, but it was in 2020 in Chicago, right? At the Basecamp offices? No, I wasn't there. I wasn't there. I read all the stuff that Ryan wrote. I saw. all the videos including the one from christopher alexander and introduced me to christopher and sander that i really like pattern languages and a timeless way of building and i kind of focus focus just every day i try to so maybe i i saw the videos multiple times the the how we work videos uh that were like different steps i saw it multiple times and trying to understand the principles before that because previously i knew also the the whole process i knew i like to read a lot right and i knew the processes of software of software building from scrum to kanban these more agile attitudes i needed i knew from practice from I needed them from experience working in this zone for factories or consultancies. But just when I was on SinRutina, at the end of SinRutina and also starting Newlinga and we wanted to hire more people, I wanted to get into the deep, right, about this whole new software building stuff. And I started to read a lot of books like Kanban in Action or other books that are from for Scrum, actual coaching and and get into the idea about that. So when I started learning about ShapeUp and the videos on how we work from Ryan and Basecamp, I got into I was mapping the principles, right? I was OK. Some principles are from come from the Toyota production system and Linway and and is building more introduce some principles new principles but some of the stuff is still there from the agile perspective uh way that i think and what i the the course that i made with ryan was the hands-off course that was really also very insightful for for us in order for the transition between okay we have the pitch and then I give it to the squad, we call squad the team that will implement it, the delivery team. Okay, how do they start? How do we negotiate some things that didn't appear, didn't were previously solved on the shaping sessions, on the shape up? So that hands-off workshop was very interesting for me. Okay. I wasn't aware of that. It was a virtual workshop that Ryan made. I want to switch gears a bit and get into some deep dives. But before we do that, I want to just quickly fast forward to the setup you have now. if you could just run quickly through kind of the cycle length you have now, how you do cooldowns or ramp ups, the team setup in the cycle teams and just kind of, yeah, the basic pillars of your implementation now. I have two squads working on proactive projects, that is the strategic projects. And I have one, we call it the... pivot or pivot or the that is working on reactive things and mainly on reactive things more small task bug bug fixing maybe some maybe improvements refactors that we we can do some spikings etc this is kind of we have this for each each cycle now we are doing six week cycles because what we changed from three to at that time we changed from three to three plus one three cycle work and plus one cooldown then we changed to four plus two but then at some time the projects were becoming more complex because as already we have a lot of things built and in order of course if you change one thing okay we it affects the business rule another part and the projects are becoming larger and larger and they say okay in order to achieve good quality and and what i sense was that the team with four weeks plus two was kind of they were shipping on the cooldown right and i needed one that i wanted to be able to ship and streamline uh by the fifth week I want them from them to be shipped and the six week is kind of, okay, let's fix some bugs that appear that we didn't kind of map. And the, the cooldown are moments for us to, okay, do a retrospective. We kind of keep that to the retrospective of the team. We are like 10 people. It's kind of a small team to be able to manage a retrospective meeting. And Also, we do some refactors, maybe some improvements that were left from other projects before. And also, we use this kind of hands-off exercise by the end of the cooldown and starting of the next cycle. I am the one who do all the shaping now. But on this cycle, I'm working with another designer, one of the designers of the team, but I wanted for him to be able to learn and to be able to shape and think some things. And also, I would say that me as having different multiple hats, sometimes I like to to be on the call right and maybe sometimes when i have to shape some things i procrastinate them and and on that way i really like the shaping sessions with other person because we are kind of focused on the problem trying to solve and thinking about them thinking about that and the business rules in the same or similar way as you do with the per programming session right i see that that way okay programming for me was very comfortable and i liked working on that because two people are working two developers are working in a a problem that is kind of maybe hard sometimes or um and if and you are hyper focused on the problem and you know that it's a problem that if you have to do it alone you will procrastinate it because it's kind of okay this is a boring problem or I don't want to do that. I'm trying to do that. And if you do with another person, you kind of feel, for myself, my sentiments are kind of, I feel happy when I'm working on boring stuff with someone else. It's kind of more easy. So in kind of on that way, I'm not saying that shaping session or shaping some stuff is boring, but I tend to procrastinate them or pay attention to other stuff that is going on right and so when i okay let's do this meeting session and when i commit with other person i it tends to go better hey i hope you're enjoying the conversation i wanted to take a moment to thank you for listening and to let you know about the shapers and builders job board on shapers.builders yes that's the domain You'll find jobs in software development, design, product management and other roles at companies that work with ShapeUp. Many of these roles are remote and teams who use ShapeUp generally run at a more sustainable, healthy and meaningful pace than the hamster wheel of two-week sprints. So if you're looking for a job in tech or trying to find great people, head over to the Shapers and Builders job board at shapers.builders. Now let's turn back to the conversation. uh shape up forum i actually went in and picked four of your comments uh which i wanted to kind of grill you a bit on okay and now the order is getting a bit out of line but one of them actually is um and let's just pick that one how to help people move from the builder side over to the shaper side and you actually in this post that you wrote on that topic you said we are experiencing this one person a developer of the team started to think more about the product and wanted to start shaping my approach was to ask them to write three major problems or ideas he wanted to pitch after that i told him what i suspected would provide more value to the user and he started to write a pitch um so it seems like that that is a different story but maybe you can just kind of expand a bit on of course how you think about helping people into the shape of role what i sense on that then that's a i gave them to think about the three problems i wanted to try and and write some pitch right and then what i did was to um review with them or or maybe do a framing say if a shaping session with them or answer some questions doing that side i will change that um that um how do you say that that comment uh i will do it in different way i will give them the problem and they will shape the things in order for them to solve because the first the first step is to end um now after doing the after i did the the course on on shaping in real life with ryan um and the in the post he wrote about okay framing and shaping i think the the value change the value the the sorry the value chain of the whole software delivery process i kind of have it map in the in the whole in in my whole mind and ryan did perfectly that it's kind of from raw idea you have you pass to framing the idea and the output of framing is just a frame idea with the constraint of the appetite and on that side, okay, now we have a frame problem, right? We have the outcome and the context and then after that we have the shaping process, the shaping step, the shaping phase. And that we have, we produce a solution that can go with all the context and the problem and the app that you have. And also, sorry, the frame, the output is also, okay, who's going for us, for example, is who is going to attack this problem because also the shaping changes. If some experienced developer has more experience with the domain, it's not that the shaping won't be the same as if. more junior or less experimented person of the domain has to work on that so on that side then the shaping then the hands-off then the delivery and then some the cooldown again and some Q&A but the thing is that taking a person that is on the delivery team and then putting to work on some to think about some problems i think will be a very a very long jump for them to to do it well because it will jump and skip the shaping it will go skip and to the framing and the problem right on the on this on this on the side they will just from raw idea go to to shaping but okay they won't think about okay why are we doing this or is it this important so in those on that perspective uh what i will do is okay we have this frame problems okay try to shape it and then we review it also what i'm doing with now with with this designer is okay we have this problem i frame the problem and i don't do this kind of shaping and then we reboot we kind of meet into the framing in the shaping session sorry and what we do there is i try for him to provide the answers or think about them maybe sometimes i know what we can do in terms of technical aspect side on in terms of business what i try to do is come on is letting him think before and not giving them solution, try to ask them questions. Okay. And what do you think with that? And what problem does it have, right? Just guide them in a Socratic way or kind of that? One thing that is kind of connected to what we talked about was I found a post of yours where you were talking about the role of designers within ShapeUp. And that is a question that I see come up. quite frequently and you call you you were talking about something um that you called a full stack designer and you compared it kind of to to a full stack engineer understanding um can you maybe explain how what you call a designer on your team kind of what um what parts of the kind of the process of product development that entails? Where does the designer start? Where does it stop? How are the responsibilities of that role? And how does it maybe also map to shaping versus building? I'm very fond of designers in the way Basecamp has their designers in terms of they can write HTML and they can write CSS. Um, because, um, they can, I worked before in some software consultancies on some freelancing that they gave me the Figma file or something like that. And it was very high fidelity. And if they, if they didn't know HTML or say CSS or some kind of how the, uh, web development kind of works for the browser is kind of, yeah, we, we cannot do that. Right. And that was a struggling moment for me as a developer. And also I see that with developers that when the designer that doesn't know their medium, doesn't know how to implement the medium in some ways, they are, they don't have to be experts on that, but they should be able to kind of write that and learn and be able to. map an idea is it just about knowing the medium or is it also about being able to implement the work in what i've seen other teams then call rather a front-end engineer for example my designers in in in the in our development team in our product team don't know javascript so in that way uh in that way they can have an html and then they have um and they can write css very well but they don't they don't are a full front-end engineer um i wanted to keep a a a team as small as possible because maybe our budget or maybe our goals or things like that so in those ways i want to be able to ask because i that's why one one of the main things about rails is ruby on rails is that it's very easy to ship something right because it's everything stuck on the is it has everything every tool that you need for the stack to solve a software problem and in in that way i always like you to work with full stack um full stack developers because i don't need a team of two with development skills for two people with this similar development skills working on the same project because the nodes of communication grow exponentially, right? If two people on the squad are much better than three people. Also, I struggled with that. At first we had two developers and one designer and What happened on that side is the developers were working very concurrently between them and the designer was kind of maybe out of some decisions because the developers move faster in terms of technical stuff. Now, what I saw with that is that, okay, I take out one developer and put the developer and designer together and they have to be able to talk with each other and decide. So now the designer is learning more some technical stuff and the developer is learning more design stuff. We are... what I think is that we tend to stick with what is comfortable for us. and for the developer is more comfortable to talk with another developer than talking with designer with different skills and different minds so can you just explain briefly what you what a full stack designer yes for you totally for me a full stack designer is someone who can think about a interactions flow to think to be able to think about the the flow of a use case of a solution with maybe do some breadboarding or think about the different screens or steps and the affordances that you should have for the user to solve to make progress and also to be able to work in a delivery team and in an artistic way for him or her to deliver a good quality in terms of aesthetics for the project. And also to be able to interview at least a user and be able to know what's the struggle is. to know what questions can be asked in order for the user to know, for the team, to the product team to know what should we do or what is this person struggling with. So that, of course, when you kind of have more general skills or kind of try to map different things, it's very difficult to be a specialist in some aspects, right? but i think in the current stage of our product or current stage of the business the that level of specialization will fill the night the rest of the 90 to 100 percent right it wouldn't be too from the the really 80% of the stuff we are building can be sold with these different full stack skills and in a very cost effective way. In that sense though, if I'm understanding you right, a designer is spanning the world of being a shaper, which would be their skills about understanding problems, speaking with users and kind of ideating through solutions on the shaping side and then also because you mentioned this in the beginning part of a build builder team kind of a cycle team exactly exactly that's that's for me a full a full stack designer to be able to map this kind of three three hats or three circles of skills and and be able to to think about the solution and try to think at least from the flow to the UI artistic way. So the next thing I wanted to talk to you about was how to protect the cycle teams from outside distraction. Our business is kind of, we try to provide a full learning solution. So we kind of connect with the meetings, arrange scheduling, kind of have the whole editor and content for the, for the, we have a learning. learning team that generates the content for giving for giving them for the teachers to give the classes we have some administrations part of the platform we have the clients as we give b2b we are a b2b company and we give the our clients the companies we give them like a portal for them to track the how the the usage is and some metrics so we have a lot of a lot of things going on on our platform, right? And if you have a lot of things going on, that, of course, it doesn't matter if your quality of software is good, you will have more bugs because a lot of more is going on. And on those side, I think, okay, we still have to have some slack to provide time for be able to solve or track some the problems that are occurring on our platform because the our domain the main context is huge so in that way that's why I decided to just split the the into track side and have okay we have strategic problems that we are attacking proactively and planned and we have reactive problems that are attacked by the people developer that is working on that and it's if he it's if he or she has some slack it's okay we they can work on every factor they can work on some improvements they can do some spiking for the next cycle I don't I don't care if they are having some slack and this the main important problem is that this pivot person should be should change for for should change for each cycle because maybe it's a boring task to be continually being done right to if someone is committed for the whole year to do some tasks it will be boring for him or her so it will be good to rotate to have this rotation and the pivot now in this cycle and the people Cool. I mean, I guess the team will be glad to see you also step into this quote unquote boring role. Exactly. I want to wrap up with some kind of quick fire questions, some reflective questions to you. And the first one I want to ask you is what advice would you give to other teams trying ShapeUp? And to frame this, I would say think about What would you tell Juan who's living in a parallel universe that's kind of off by three to four years, that's you three years ago? What would you tell yourself? What I think now about Shape Up is that you don't have to take the book is just, it was one phase of the Shape Up methodology. It was just, okay, it was mapping all the knowledge and it was a... starting point right now the other teams are improving are trying that are are finding some things that they didn't map out that's why i really like this the latest course by ryan because it's kind of the whole value changes is map and you don't have to and also important aspect that he did he changed the term of the rabbit hole into an analogy that he called them a time bomb that the rabbit holes are time bombs that if you don't that you have to defuse if you don't defuse those time bombs previously or before the delivery cycle those bombs will explode or do you will have to have an anti-bomb team or maybe as anti-bomb squad that gather at that point to take a decision And then one of the aspects of shape up that I, I learned through, through the time that it mainly shape up and changing the shaping previously or taking decisions upfront that later, that's the main difference from Scrum is that some, this, some decisions can be, should be taken upfront because it will. demand a lot of people to gather for diffusing these bombs later, because some decisions should be answered with some business perspective, some designs perspective, and those persons, those people maybe aren't available at that time. And that will cause a struggle for the delivery team. And that's why I try to think, okay, shaping is about taking the important decision. upfront for the delivery team to work autonomously it's not to be you can gather those principles with the book like the the constraints are um and the rabbit holes now i i like them better to call them diffuse time bumps and that's one of the main aspects and and also when people say that shaping is an agile or like that that i really i saw sometimes it's like yeah it's the six weeks can be changed you know you don't have to work on six weeks those those the how many weeks do do you have on the cycle it depends on the stage of the building process you are the stage of the business you are right now or the what you are building right now and can be changed you can do some three weeks it depends on the projects how much constraint you want to put on the projects the the the time is a constraint for you to design the solutions and those can be changed um that's why the main the main principle the appetite is it's it's isn't written on stone that it should be six weeks and the decisions taken up front are not for for not to be agile or to be a waterfall thing but to think about the resource allocation later. Wrapping up now, I want to thank you so much for your time and for sharing your experience, your team's experience. Where can people find you if they want to get in touch and hear more on your perspective or exchange ideas with you? Well, I'm fully on LinkedIn and try to... kind of my linking is mostly a lot of things about shape up and on on twitter maybe but my twitter is more broad uh ideas and a lot of nasim taleb ideas that i'm very fond of his book and his work but on linkedin mostly i i will i'm working i'm posting a lot of shape up ideas and i if someone from spanish speaking Spanish speaking businesses are trying to do some shape up or working on shape up. I want to kind of gather a community of Spanish speaking shapers. That's great. Then I'll make sure to put your LinkedIn handle, link to your LinkedIn profile into the show notes. And so people definitely should get in touch there. Thank you so, so much. It was really great to hear your experience today. Thank you, David, for this invitation, and I hope this helps other people. There you have it. I hope you enjoyed the conversation with Juan. I certainly did. If you like this show, it really goes a long way if you leave a favorable review wherever you are listening to this. And to find jobs at companies that work with Shaper, like Nulinga, remember to check out shapers.builders. Yes, that really is the domain. Thank you so much for listening and I hope you have a great day.

#4: Today I am speaking with Juan Villarejo, CTO & Co-founder of Nulinga, an online language learning platform. Before founding Nulinga, Juan founded SinRutina, a subscription service for fitness classes, which was acquired by Gympass in 2018.

This conversation is part of a series about companies that use Shape Up, a delivery framework originally created at Basecamp. If you've never heard of Shape Up, check below for a link to the video "Shaping in a nutshell" by Ryan Singer, former head of strategy at Basecamp and author of the book "Shape Up - Stop Running in Circles and Ship Work that Matters".

In our conversation, Juan and I dive deep into how he's introduced Shape Up via a sequence of small steps and small wins, how to protect the team's focus, how to help people move from the "Builder" to the "Shaper" side, and the role of what Juan calls "Full Stack Designers" at Nulinga.

Juan has been a co-host of two meetups for the "Shape Up Practitioners Meetup" with me recently and he has generally been an incredibly active and helpful member of the Shape Up community. I'm very excited for you to hear what Juan had to say. 

Links:
Nulinga: https://nulinga.com/
Juan on LinkedIn: https://www.linkedin.com/in/juanivillarejo/
Juan on Twitter: https://twitter.com/juanivillarejo
Shaping in a nutshell: https://www.youtube.com/watch?v=h_8M23wVjXk
Shape Up Meetup: https://www.meetup.com/shapeup-practitioners/
Shape Up Forum: https://discourse.learnshapeup.com/
Shapers & Builders job board: https://www.shapers.builders