Creating the Teamwork that Builds the Product
Startup for Startup
Working together on a product is hard. Every team member has their own vision and their own ideas they want to implement. It can easily become frustrating – working on something for two or three weeks, getting denied, cursing the world, you know the drill…
In this episode we’ll talk about a model we’re using in order to deal with this and optimize our teamwork around the product. And this model, the model the referee claims will solve it all, is a model we call “builders”. Those builders are the people who stand behind our product in the most direct manner.
“builders is the term that we use for everyone that helps build the product”, explains Ben Rosenfeld, a product manager at monday since the summer of 2018. “Basically, it’s the developers that we have here, the product managers, the analyst, and the designers, and all of them are working together basically day to day in order to build a better product.”
Although Ben explained the “builders” term pretty well, it might be unclear what it’s all about. After all, there’s nothing special about developers, product managers, analysts and designers working together on a product.
You see, it’s not precisely about the roles. It’s more about how they work together.
The way many companies work is quite simple: the product manager defines the goal, writing down the path to achieve it, and once they’re done, the designer gets to work. After the designer – it’s the developer’s turn. Of course there are different ways to play with this production process, but roughly – that’s how it works. Shanee Radzewsky, a senior full stack engineer, knows the difference between the two approaches.
“I think that there, a lot of times that the product manager kind of defines what needs to be done in a very specific way. And they might come, you know, with some document, for example, in my old company, we had documents for it where it says, you know, why we’re doing this? How are we going to measure it? And this is what needs to be done. And it’s kind of do X, Y, Z.”
For many companies and developers, this method works quite well – but Shanee wanted something different. She wanted to take a bigger part in the decision-making. With the builders’ model Shanee is way more involved in the process, but I’m confident that this involvement has its downsides. I can only imagine how frustrating it must be to have meetings with people on issues that in other companies would be solved alone, without asking for anyone else’s input.
“every decision, every strategic move that you want to push forward or to advance, you need to get everyone on board. And it’s challenging”, Ben admits. Shanee agrees:
“nothing has really kind of passed on from above and something that’s done together. And it’s something that they’re, you know, debates over and fights over and how are we going to prioritize it? And what’s more important what should come first? And it’s something that’s kind of done everyone together. The, the developer is the product, the design, the team lead. And it’s not really something where, you know, I get tasks and this is what I should do. It’s very much, what do I think about it? How do I think is the right way to approach it?”
The pieces of this puzzle don’t fit. We know that our product grows fast, but listening to our builders led me to suspect that our model forces us to work slowly. How come we involve our builders from the very beginning of the project until the very end, and yet we’re able to launch features on a regular basis and keep on making our product richer?
The work at monday happens in small teams. Some companies call it a “squad”, we call it a “domain” – but the principle is the same: each domain has its own responsibility within the product. One is in charge of our automations, another is in charge of dashboards, so you get the idea – every segment of the product has its own domain. Most of the domains have a builder of each kind: one product manager, one designer, one developer and in many cases a data analyst as well. Sometimes though, a domain runs without the function of a designer, or without a product manager. It depends on the need and the capability, as Daniel Lereya – VP of R&D and product at monday – explains: “this means that in some domains you have all the functions, in some domains that are more technical, for instance, you’re only engineering, so it really depends on the mission of the domain.”
But how does it look on a day to day basis? Well, Ben is here to help us understand.
“In terms of the process, I’m always the one igniting the process and setting the table. So I usually would create a board with all of our opportunities and all of the high level opportunities that we have and what they are contributing to, and then I will begin the discussion with all of the relevant stakeholders will be with the team to help understand the estimations and what are the efforts of all of the tasks that we want to do. And the other stakeholders in the company to align everybody about what are the opportunities we want to attack and what to prioritize. And this is something, a process that takes usually a week or two when you were going meeting with everybody, getting all of their inputs, trying to align everyone and prioritizing and close the queue.”
This process demands from Ben a certain ability – the ability to pitch. Whilst, he’d probably need this skill somewhere else, it wouldn’t be as important as it is at monday. Since he’s not the most dominant stakeholder in the project, he better know how to sell his idea to the developer and the designer if he wants them to join his ride. This selling happens in the kickoff – the very first stage in every project we start. All the relevant stakeholders of the project gather together, so everyone will be on the same page when the project starts.
“I am very rational person, and everything for me is super logical”, he admits, “I think in my first kickoffs it was okay, so this is the first step, so this lead to this step, this step, this step, and this is my proof why we need to do that. And this is how my mind works. But I think I learned here that it’s not how most people minds work and they are connecting much better to a story. And so, I think today trying to create a narrative for each few and that way to try to help people understand the way that we see stuff. You really need to fight for your roadmap. And you really need to convince people, the people around the company, that this is the most important thing. I think we have this event that calls kickoff when you are presenting your roadmap for the entire queue. And so usually the feeling you want to do aim to the people will go out of the kickoff and they will say, “Okay, let’s start working on this now. What are you doing? Get out of here and go to work. so, yeah, it’s a super important ability in general but I think in this structure, even more.”
Whilst Ben spends quite a lot of time sort of “negotiating” with his domain colleagues, it’s hard not to think how this time could be used differently. Many successful companies out there tell their product managers to write a roadmap by themselves, without involving the developer or the designer. If you’d ask Guy Greenhut, a product designer at monday, he’d have a definite answer regarding what’s the right way to approach it.
“I think the question is not what takes more time, or if you’re spending time that you are not supposed to spend, because this is not in your landscape of responsibility. The question is what makes a better product? If it makes a better product, even if it takes from one builder to another builder more time, okay. So it’s good. So why not spend this time if it makes the product better? And I’m pretty sure it makes the product better.”
But still, although you are willing to make sacrifices in order to make a better product – there’s a limit to that. No one would go for this builders’ approach if the production would move so slow that it seems like no one’s working. One of the most important things to focus on is the diliberation that we all deal with in one way or another: what you decide to spend your time on. In the builders’ model, its very clear what you want to spend time on – as Ben describes it.
“I think that the thing that we spend most of the time is about what our goal, what are our KPIs, what do we want to achieve and how to prioritize. it could be during the Q, we understand that these… A different way in order to achieve the goal that we set up, which is quicker, requires less effort, so we can just switch to it without getting everyone on board or so on because we agreed on what we’re trying to achieve. So I think this part requires a lot of time. It’s not easy to agree about goals and what are we trying to achieve. It forces you to make the hard decisions, I think a lot of the time. But it also helps you to create focus and directions for the team for the entire Q and this agility.”
Shanee doesn’t think the builders’ model damands more meetings than usual. “I think that, you know, our concept of a lot of meetings might not be a lot of meetings in another company”, she says, “I think we are very minded to the efficiency of our time and something that I appreciate that I think is very hard is very minded to who needs to be in what meeting.”
Part of this “meetings’ efficiency” is the rush to test. Instead of having endless meetings about this or that, the builders go out for a test. Guy, our product designer, says that once a meeting is over, they’re like “Okay, let’s do it tomorrow. And let’s test it the day after tomorrow.” Testing, I mean by taking it outside to our users. Some percentage of them, but we’re going to test it. If you’re going out very fast with MVPs, with tiny and small specs of product so you can work very fast, we are not waiting until something will be perfect, because you can’t do something perfect if you don’t test it.”
Ben says that there are many possible results to a certain test, but there is one thing that he just can’t accept. “I think the worst thing about a test is that you didn’t learn from it and yeah, you can’t make a decision on top of it, so I think there are tons of cases like that.”
Shanee: “If we have a disagreement, then let’s be data driven, you know, let’s make up a test and see what the results are, whether it’s user testing, you know, or we have some like design mock-up and we test it, you know, in these user testing systems or whether it’s an AB test, the end of the day, people have opinions, we respect people’s expertise, but we’re not gonna spend an hour and a half, you know, going back and forth of what’s better. We’re gonna find a way to test it and, and, you know, get a, a conclusion. That makes sense.”
Guy: When we launch a feature, a product, anything, we’ll test it. We’ll test it from the day it launched till the end of the world. We test everyday. We test everything, because this is our way to know if we’re on the right way to get our users satisfied.
Ben: And I think the most important thing is that we’re keep continuing and developing and executing and not getting stuck on discussions. So it really doesn’t matter in then what happened, just the fact that we were able to continue and execute.
Tests of all kinds are an essential tool in our production process, and it’s definitely something many other startups and companies can and do use – regardless of whether they’re working according to the builders’ model or something else. The problem with these rapid tests is that this rush might cause issues that will eventually turn out to be hard to solve later in the project. It’s the same feeling I get when I’m rushing out from my house, knowing I’m going to be late for a meeting in the office. “Why can’t we have it on zoom?!”, I wonder while taking my bag, and making sure my keys are there. Then, checking my pocket, making sure I haven’t forgotten anything else, I realise ,Wait, my phone! Then I’m shoving it in my pocket and running down the stairs, knowing that the cab driver won’t wait much longer than he already has. After a few minutes, breathing heavily in the backseat, I shut the cab’s door behind me and get to our office. It seems like the lift is slower than ever, but finally I get to my floor, and right there on that spot I realize I forgot my laptop at home.
The same thing might happen with tests – the rush might cause the builder to skip on something pivotal. It’s not because he forgot this something pivotal, but mostly because he HAD to skip SOMETHING in order to get things done in time for a test. This has happened to quite a few of our builders, and Shanee is one of them.
“there was kind of a lot of push to have, you know, just a quick proof of concept and, you know, let’s get it out and we’ll see. But I think that we already really knew this was something we really wanted. It was something that was very clear. This was the direction we were going.v I was kind of still a little too insecure to really push and say, Hey, this is something where we really need to build it, you know, better in for here. And we shouldn’t be leaving these technical debts. Cause it was still kind of this place where I said, oh, if I don’t meet the deadlines, then that’s on me. Right. Then I, you know, I’m, I’m not good enough. And what ended up happening is kind of, we left these tax debts and we put it out and it was, as we thought it brought a lot of value and it was highly used. And then we kind of ran with so many of these new features and we didn’t come back to those technical debts and time. And we have this architecture that wasn’t good enough and it cost us a lot when it came to adding new things. And when it came to sinking up with the absent front and it ended up being that like 80% of this amazing infrastructure that I was so happy with just got deleted and thrown away. And when I say God deleted, I meant I had to delete it and write new things. And you know, there is something kind of cathartic about deleting code that you wrote, but at the end of the day, it was, it was definitely one of those times where we should have made that decision to come in and say, no, we need to build something really stable now. And we’re going to be so happy. We did it later. And instead we ended up paying, paying for it in more time than we would have delayed.”
There was a solution for similar cases in her previous company, but Shanee didn’t think it was suitable for monday.
“I worked at a company where it was very, very dev oriented before this company. And whenever you made any feature, that was not like a trivial, small change, you wrote a technical design review. So you wrote like a technical design document and you would send it to all the developers in the company and anyone could read it and comment. So when you start that way, then you have less room for these things, but you also move pretty slow when it comes to feature increments. I think it was very much like the dissonance between monday and my previous company is very large in that regard.”
It’s not easy to find this balance between crucial segments in the product on the one hand and fast testing on the other. You don’t want to work too hard on something that won’t survive its first users’ test, but you definitely don’t want to find yourself deleting 80% of your work because you worked too fast in the beginning.
“I’ve definitely had times in our, I kinda fell in love with the idea and spent too much time at first on the design before even seeing, you know, is this actually the direction we want to go? And the flip side of that I think is knowing when to insist on putting more effort into building the infra and saying, no, this is going to take longer. I can deliver it in three days, but I’m not going to, I’m going to deliver it in two weeks because this is something that needs to be really solid. And I need a good design and good architecture here, you know, in the code. And I think that I’ve made both of those mistakes and you kind of have to make a, both and end up, ended up finding the middle.”
After talking with a bunch of our builders, I was quite frustrated. They all praised the builders’ model like 13 years-old-girls used to praise Justin Bieber. There is just no chance it’s THAT good. I’m sure you can find more disadvantages! To inspire my interviewees, I gave them an example of this one thing that kept bothering me. This model kinda blurs the boundaries between the roles. The product manager finds himself arguing with the designer about the roadmap, and the developer defends her code in front of the designer who thinks that something should function differently. I can’t stop myself from thinking how annoying it must be. But as our VP of R&D and product, Daniel Lereya, says – its not only “annoying”.
“I think that the biggest pitfall of this model is that you are not getting the maximum from each function. Because the roles and responsibilities is not super sharp and then you can say that instead of having each function doing its role, they all are getting mixed and it’s not optimal. And also the accountability about specific things in your specific role is not so clear. So this is actually something that we are constantly coping with. think about design, for instance, suddenly everyone in the team has something to say about the design and thinks that they know which design is that. Then where is the designer place you and his professional place, say this is the best solution? So I think that it’s some kind of balance that we are trying to keep. Always to keep everyone involved in everyone’s else work, but still allow the specific professions to take decisions and to be accountable for things that they need to be accountable professionally.”
This doesn’t happen only for designers though. Our developers, like Shanee, always experience it: “it definitely happens and not only have I experienced it, I’ve also done it to others a bunch of time. And I think that the way that it still works is that, you know, you can get frustrated and then like take a deep breath and remember, you know, that we’re all really trying to achieve the same thing here. And, and remember if you can get frustrated and still listen to the other person and then, okay, maybe not in the first second, but after, you know, 10 minutes then realize maybe they’re right then that’s how it still works. Because the same way that sometimes, you know, some, a designer for example, will say something to me and I’ll be like, no, I know better. I know that this isn’t going to work, but then, you know, maybe 10 minutes later I’ll realize that maybe I should try and it ends up working. I know that the designer on my team, this has happened with her multiple times. I think where she’s coming. She said, you know, maybe you can just make this change and I’ll say, well, you know, that changes in the scope of the original feature and it’s not something I took into account when I planned, how long this was going to take. And she’ll say, listen, I really think it’s a small change. And you know, first instinct is like, okay, great. You think that, but I’ve seen the code. And like, I understand that in the UI, it’s a small thing, but it could be very complicated. You know, I think I’ve had multiple times where I’ve told her, no, this is very complicated. And then in the end I look into it and it really is like, sometimes I’ll say, listen, I think this is really complicated. And then she’ll send me an example from somewhere else in the, in the product where they’ve done this and I’ll look and I’ll be like, okay, actually, this is very doable.”
Daniel: I think that one of the important thing is that when you are aware to your colleagues’ challenges, many times, it makes you a lot more humble. And I’ll give you an example. When we have teams, for instance, that we start a new effort and not always, or usually, we don’t have all the functions from day one. Because it’s hard to align everything in terms of hiring, and like making sure that all the styles of the line to set up a new team. So you can actually see the experience people feel when they don’t have the function, then they get it. For instance, we ever did that is currently only built from engineering and design, and we don’t have a product. So suddenly everyone wants a product first because they understand, at the beginning, they say, “Okay, I can do it. Yeah. I can say what’s important.” And, and suddenly they understand the depth.”
I find the builders’ model interesting. I can’t say I’m fully convinced I’d adopt it in my hypothetical startup, but I’d definitely consider it. It makes all of my designers and developers active in stages that they don’t usually take part in – and personally I find it very important to have these people’s inputs that early in the process. Besides that, I love the fact that this model encourages the company to test fast – though obviously it’s a policy that can be applied to other models as well. But since my hypothtical startup is about to grow insanely fast and become a unicorn very soon, I want my model to embrace this growth. Daniel deals with the growth issue, and he has some insights: “the common pitfall, and we went for it as well, is that you want to have the same cookie cutter for all the teams. So suddenly if you don’t have all the functions, you say, “No, this is not a builder’s team. You can’t move forward” and so on. So we really believe that in structure, you need to be as customized as you can. And that’s the most optimal way to build structure is having like the most, I would say the best decision, compared to the conditions that you have. So I’ll give you a concrete example. Many times you think, “Okay, I want to start a new efforts, but now if a wait till I have a product, a PM and the team leader and all the developers and the designers and the analysts,” I would wait a lot of time and I wouldn’t move forward. So many times we do customize things. We suddenly see that we have a developer and a PM that can take this effort and then to get help from other designers and other team, just to get things going. it needs to be flexible. And another thing is that it needs to constantly change. Many things in us, as people are like creating like a sign wave, and it doesn’t matter if you fix something and make it great. Few weeks after it will probably be less good and you’ll start seeing the disadvantages of what you did. So you need to stay flexible and also we need to challenge it constantly and to make sure you change.”
Guy Greenhut, our product designer, had his own startup with other co-founders before he joined monday. He was the design team lead over there, and they worked in a similar model to the one he currently works in on monday – but today there are a few more people involved than there were in his startup. Over there – about 20 employees. At monday – about 200 builders, and still counting.
“You have to do some adujustemtnes, maybe to arrange the teams differently or the size of teams, but the work and methodology its not different it doesnt depend on the amount of people working on something.”
In a way, it sounds to me that Guy and Daniel are saying “the builders model is great, but only if it’s flexible” – which basically means that “the builders model is great if you’re not too conservative about it”. I’ve been thinking about it, and you know what? I guess that’s the case with many different models in many different departments – not only around R&D, product and Design.
“first of all,” says Daniel, “the most important thing to say is that there isn’t one right structure for everyone and for every challenge. I think that when you’re considering your structure you need to understand your challenges, who are your people, what are the values that you want to promote? And many other things in it. I don’t necessarily think that builders is the right structure for everyone. And even for us, there are places where we are doing customized things like now, because we feel that they work better. So we, for instance, have teams that are very, very into deep technical challenges. And in these teams, the concept of having all the functions is different, it’s suddenly different people from engineering, right? So we take the essence of things. So you need to understand the essence and to see if it’s something that’s suitable for your work and your challenges and your product and so on.”
Guy Greenhut, our product designer, agrees.
“The world is not black and white. I think the world is in the middle between black and white. I think the issue is not about workflow, because workflow you can work in this way, and in other way. As you said, this way can be right, and the other way also can be right. I think the issue is the persons, the human being that’s working in a specific workflow. This is what is very unique in Monday employees. They like to work in this kind of work. They love to work in this kind of work.”
Shanee: I also think that it’s not right for every type of company. If I were going to write you know, the code for airplanes, I don’t want to run fast. I don’t want to run fast and I don’t want to put out, you know, proof of concept that might not work and just see what happens. So I think that there’s definitely different types of things where this isn’t the right way to work, but if you’re putting out a product that people use every day software that people use every day, that is not, you know, the code in some machine, in a hospital that’s and what you want is to be able to bring as much value as fast as possible. Then I think this is the best way.”
Guy: This is not about designer, dev, product, analyst, CS, it doesn’t matter. It’s about the people that you’re working with, and working together. I think he needs to know that he has responsibility about everything. I mean everything by he’s not going to code, but he will be involved, he wants to be involved. This is a very personal issue. Not everyone like this. There is people that like to work in other way, and it’s also good. As you said, as I said before, there is no right and wrong, it depends on your personality. “
Shanee: “I think that it really depends on the person. I definitely think that everyone gets better at it as time goes by. I think that definitely there is a matter of, you know, being more of a junior and having less kind of confidence to insist on something. Even though, you know, your product manager, your team lead is saying something different and it’s something that it takes time to realize that developers are at Monday, truly are expected to constantly be pushing the things they believe in. And if you think something’s painful in your domain and you’re not bringing it up, it’s on you, that it didn’t happen. It’s not on your team lead, like the fact that you thought it was important, you had this in your head and you didn’t fight for it. So that’s also on you. But I also think that there are people that it’s just, it comes very natural to them. And the minute that they understand that that’s the vibe here, they do it.”
Guy: “So when you’re finding this match, this is the golden way I think.”