Quick takeaways
- Developers are often kept in “golden cages” - treated as coding monkeys receiving tasks without understanding the broader context or product vision
- Requirements are usually incomplete or wrong - understanding the business context helps developers spot issues early and deliver what’s actually needed
- Collaboration with stakeholders is crucial - developers have valuable product insights and should be involved in planning, not just implementation
- Event Storming is a powerful collaboration tool - a lightweight workshop technique that brings developers, product managers, and stakeholders together to align on complex topics
- Change takes time and trust - transforming company culture requires starting small, showing results, and convincing people through solving their actual problems
Introduction
In this episode, we talk about why software projects in regular jobs are delivered much slower compared to side projects, and what you can do about it.
We share our journey from building hobby projects as teenagers to working in professional environments, and the differences we encountered.
Developers are often kept isolated from product decisions and treated as “coding monkeys in golden cages” - just receiving tasks without understanding the why behind them.
We discuss techniques like Event Storming that can help break down these barriers, and improve collaboration between developers and product managers.
Notes
- Event Storming - a workshop technique created by Alberto Brandolini for collaborative domain modeling
Quotes
Five days of coding can save one day of planning.
If you want to be promoted, for example, delivering is the very best way to do it. So instead of just waiting for requirements and complaining that it doesn’t work, you can try to help whoever needs what they need.
How it often looks like: it’s like companies are trying to make the programmers coding monkeys in some golden cages, basically.
Instead of complaining that we never get anything done, you tell them, yeah, this feature could have been one week, but we spent two months.
The worst thing that we noticed is that the performance of how fast we’ve been able to deliver new stuff was much worse.
But what if instead, you have this domain expert, this stakeholder meet with developers directly and tell them what they need. And then usually developers will tell them, oh my god, this is so complicated, it will take two months. But if we drop this one button from the dashboard, it will take one week.
Timestamps
- 00:00:00 - Introduction
- 00:01:11 - Our story
- 00:05:06 - Slow projects
- 00:07:10 - Golden cage problem
- 00:09:30 - Incomplete requirements
- 00:13:14 - Developer time optimization trap
- 00:15:15 - Level 2: Collaboration
- 00:19:09 - MVP and simplification
- 00:23:33 - Talking to stakeholders
- 00:28:40 - Levels of engagement
- 00:30:29 - Why you should care
- 00:34:30 - Event Storming
- 00:44:37 - Getting started
- 00:50:17 - Practical advice
- 01:02:22 - Changing culture
Transcript
Robert [00:00:59]: I’m Robert.
Miłosz [00:01:00]: And I’m Miłosz. And this is No Silver Bullet Podcast, where we discuss mindful backend engineering. In this show, we share takes on software engineering that will help you grow into a principal engineer.
Robert [00:01:11]: In this episode, maybe let’s start with a bit of our story, because I think it’s pretty important to understand that, how we started to build some production systems and from where our experience came. So probably some of you know that we met with Miłosz in the high school, so a pretty long time ago. We were just talking before recording. That it was, I think, 17 years ago, so a pretty long time ago. Actually, I know Miłosz two months longer than he knows his wife.
Miłosz [00:01:42]: That’s pretty long, and the reason I know you longer is because we are already working on projects before everybody started. So we started with some toy websites and then grew into more complex projects.
Robert [00:01:59]: And many of those projects actually became pretty successful, so many people were using them. The downside was that, well, there wasn’t great business sense at the time, and well, a lot of people used that, but it wasn’t enough for making for a living of that. So we decided, okay, let’s go to university. Maybe we’ll learn something useful. Long story short, we did it. So we left the university at some point. So we quickly dropped out. Yeah, because, well, it was probably a bit boring since we’ve been already coding for multiple years and we’ve seen that, OK, maybe we’ll learn physics and mathematics, but… That’s not probably relevant in the software that we are writing.
Miłosz [00:02:41]: We still work on our projects in the meantime, but there was almost no money coming from it. We had to just start regular jobs, which was fun at the time, because we didn’t have this professional experience, let’s say that’s our own.
Robert [00:02:55]: I just remember that. During the time, the market also wasn’t that easy. I mean, we’ve been over decoding for a couple of years already, and I was already afraid that I will need to go back to my parents’ home because I I struggled a bit to find a job, despite having a couple years of experience already.
Miłosz [00:03:11]: Even the basic wage we made back then was great for our student life, compared to hobby projects.
Robert [00:03:21]: That’s true. But I think it wasn’t worth thinking about that because, since we’ve been working already on multiple projects, we’ve been working, so we have two people— team basically, so me and Miłosz. It was a bit shocking to start to work in the normal job, let’s say, let’s name it in this way. So, you know, in the way that you are no longer your boss, but instead you are getting requirements from somebody else. You are not inventing the project and product that you are building. It’s totally different dynamics. And for some people, I know it’s fine because they don’t need to touch this ugly business and product they can just code. But we’ve been different. We’ve always wanted to create something and invent something. And it was a bit shocking.
Miłosz [00:04:08]: The upside is you don’t need to worry about… If the mana is coming through. Someone else handles that for you. But alongside this, someone tells you, here’s this system that has been around for 10 years and you need to add some feature to it. And usually it’s not an easy task.
Robert [00:04:27]: Yeah, yeah, exactly. And you know, you have other challenges, like you need to collaborate with more people. So it’s no longer two of us, but the team is bigger, you need to take maintenance into account more because there’s 50% of a chance that it will be the person that will be maintaining it later. In this case, it’s totally different because you’re working with someone’s legacy code that some person who worked here 10 years ago wrote. This person no longer works there. Code that we have written 10 years ago is still running out of there.
Miłosz [00:04:58]: You have to agree with other people in the team how to do it, probably, because you are not the expert anymore.
Robert [00:05:04]: So it’s creating a lot of challenges.
Robert [00:05:06]: Those challenges are pretty important because the worst thing that we noticed is that the performance of how fast we’ve been able to deliver new stuff was much worse. And in this episode, we will discuss some tools and techniques that should help with that.
Robert [00:05:27]: Can give you some tools to handle situations when you are not working in a solo project, but in a team and you need to collaborate in some way and create software that is maintainable. In longer term than one month. So can you keep the same pace as when working with two people or just a solo developer? So if those problems sound familiar for you, please stay with us. So we will give you some hints how to overcome those problems when you are working in a daily job. So at the beginning, let’s think why projects in your daily job are delivered slower. So in other words, why, when you are working with your friends after work or on your pet project, you are much more productive? What do you think it is? So we already mentioned one thing: when you’re working on the project alone, you are basically your own boss and you’re working on your ideas, which is great. But the downside is that it’s also much harder to make business out of that. I mean, we are software engineers, we are good problem solvers, but from our experience, very often we are not best businessmen.
Miłosz [00:06:32]: Yeah and we often start side projects and you know, some websites maybe web apps, but often it’s just something for fun because it’s for learning. And this is how we often are learning, and it’s great. Yeah, but making it into a business is a much different story.
Miłosz [00:06:52]: Which might be also why developers usually in companies don’t have that much impact on the product side. So very often they are kept in a silo of software development.
Robert [00:07:10]: Yeah, I actually like to name it a bit more brutal— and they need a golden cage. So and how it often looks like: it’s like we are companies are trying to make our programmers coding monkeys in some golden cages, basically. I know it sounds brutal, but this is how it looks in multiple components, basically. So what do you mean by coding monkeys? So there are a couple elements of this problem, let’s say, and also a couple of levels of how companies are approaching this. So the most extreme scenario is when you’re this coding monkey in your golden cage and you’re just receiving tasks to code. I even heard about worse cases when some developers even received empty classes and they were diagrams, empty classes and some UNLs and just please feel the methods and don’t care about anything else. It’s similar to LLMs today, just like a human instead. Yeah, yeah.
Robert [00:08:13]: And funny thing, if many people were working like that entire life, well, I can imagine that they may struggle now a bit because… So this is actually, it’s not very performant at the end because the software that is created in this way, obviously the chance of working is very, very low and making some… value. But still, it can be replaced in some way.
Miłosz [00:08:36]: So engineers in this scenario are just kind of implementators of some idea. From the outside. I think especially in product companies it might be an issue because developers usually have great insight into the product area as well.
Miłosz [00:08:53]: It can work better in some very technical domains where you need developers just to work on some specialized algorithms or something like that. I guess even waterfall can work in such a scenario.
Miłosz [00:09:09]: But if it’s a product company, it’s much different.
Robert [00:09:12]: Some of you may wonder, ‘Okay, why is that?’ I can just sit in my nice cage and code. It’s great. But… Unfortunately, it’s pretty unproductive. If you’re working with software a bit longer, you probably already know that requirements that you receive, they’re in most cases… Maybe not wrong, but…
Miłosz [00:09:30]: Incomplete. It’s probably the biggest issue developers have in their day-to-day work. I can’t work on this. This is not clear. This is missing some requirements. And it’s discouraging because you can’t do anything with it. You can just, you know… tell your product owner or manager or whoever that, sorry, this is not complete. I can do anything with it. And then the product owner needs to go back to whoever knows what to do and figure it out and come back to you with clear requirements, which is never the end of it.
Robert [00:10:08]: And needless to say, it’s super unproductive. When you’re working alone, you can ask yourself, ‘Ah, okay, it doesn’t make sense.’ Maybe let’s do it in this way. When you have proxy… Project manager well, it’s very ineffective because probably this project manager also doesn’t know. So this project manager needs to go to another person, that person ask another person, and it can also probably explain why often those requirements are not perfect.
Miłosz [00:10:36]: And worst case scenario is probably when the product owner also decides who gets to do what.
Miłosz [00:10:45]: Split the tasks between developers so the workload is even across the team. So that’s probably the biggest anti-pattern you can see in project management.
Robert [00:10:57]: Yeah, exactly. Because, well, if the project manager is assigning tasks to each developer, probably he may not or she may have not enough context to know. Which person has most knowledge there, or maybe some other things that if team will be responsible for assigning those tasks. It will be much more effective because they have more context to do this decision better.
Miłosz [00:11:23]: Yeah, that’s a better approach because the team knows what they specialize in, so they can share the knowledge as well between the team members. Everyone knows a bit about what’s going on in the project. It’s not like there’s one person responsible for everything.
Robert [00:11:44]: And I think it’s quite interesting because it’s based on crazy and pointless ‘why’ to work in this way. But there are multiple reasons why, in many companies, it’s the default mode. I remember that.
Robert [00:11:58]: In many components, when I was starting at the beginning, it was unfortunately the default mode of working, and it was often some work needed to change that. I mean, it was possible and it wasn’t that hard at the end when you’ve shown what problems it’s generating, but… Yeah, unfortunately, it’s often the default way of working. Do you have some ideas maybe why companies are doing it in this, well, probably crazy way of assigning tasks to people and closing them into the cages?
Miłosz [00:12:32]: I guess maybe it’s just the way things always used to be.
SPEAKER_2 [00:12:36]: Hmm.
Miłosz [00:12:38]: Just the default mode of, you know, we have those developers who are implementers and product people who come up with ideas. So the development team becomes the downstream of those ideas.
Miłosz [00:12:56]: Ping pong between each other.
Robert [00:12:59]: Yeah, I also found one interesting reason for that. And the reason was that developers are expensive. So their time is expensive. So it means that we should use as small amount of their time as we can.
Miłosz [00:13:14]: Yeah, basically use as much as we can for all the tasks we need.
Robert [00:13:20]: So basically, let’s optimize developers’ time so they can code as much as they can because, well, we’re paying them for coding. This is why we’re paying them that much.
Miłosz [00:13:28]: It’s basically like in a factory. You want to utilize all the devices to do the work for you.
Robert [00:13:37]: And you’re trapped, because, okay, from one side you are… ensuring that those developers are using 100% of their time on coding. But if you think about that a bit for a bit longer, you will notice that, okay, maybe they’re coding more. But useless things, because even if we will force them to code some stuff, and they will write them after it will be shipped to production after in this kind of companies, half year let’s say, you’ll see that, okay, it’s actually not what we needed. The worst part is it all feels like a good job. Yeah, and for the developers. You may also feel very productive, like I’ve been coding for 12 hours and it’s so great.
Robert [00:14:18]: Yes, but there is nothing to show for it. You more like wasted the time. Probably one sentence here will be very accurate. And I really like to remind it over and over. So five days of coding can save one day of planning. And this is basically that. Yes. So how…
Miłosz [00:14:35]: talking about or coming up with ideas how something should work feels much less productive than just typing away and creating this. stuff. So we are very eager to jump to implementation, maybe build some prototype. Sometimes it’s useful, but very often it would be better to spend some time. Trying to understand what you really need to build, what will be useful for the users, for example.
Miłosz [00:15:06]: But it doesn’t feel as productive as this starting coding. So developers don’t really have an issue with this most of the time.
Robert [00:15:15]: So let’s all go maybe one level up in our ladder of how good or bad putting developers into cages can be. So the second level. That I noticed in some companies is some a bit better situation. So in this situation, product owner is going to the team. With some requirements gathered from stakeholders. And in this case, the product manager or product owner is not the person who is creating the tasks, but it’s the person who discusses basically what we need with the developers and he’s working or she’s working with developers to learn how to implement that.
Miłosz [00:15:57]: So they present some high-level idea and then developers split it into smaller tasks or come up with implementation, maybe propose some solutions.
Robert [00:16:06]: So we no longer receive tasks. It’s no longer assigned to people. We can talk to our closest stakeholder and discuss what we would like to implement.
Miłosz [00:16:17]: You get even better knowledge sharing this way. So everyone is on the same page. Also easier to work with code later.
Miłosz [00:16:24]: Because everyone has insight how this will impact the end product. You don’t just work on some obscure subtasks on the other end of it. You see the full picture. But there’s also a challenge here, right? It’s not really common knowledge how to do it.
Miłosz [00:16:44]: It can take long hours to come up with the final solution.
Robert [00:16:49]: And can go into never-ending meetings.
Robert [00:16:55]: My observation, obviously, it’s always about balance. But my observation is that often it’s when you have hours of discussion. It’s basically alternative because sometimes even better alternative. I mean, the worst alternative can be that, okay, you are going to saying that, okay, ‘We are discussing already for too long.’ Let’s go. Let’s do what we think should be done. Yes. And later, you’re not spending hours on planning, but you’re spending weeks on implementing something just later to see that why we did it in this way. It’s crazy. It doesn’t make any sense. And nobody’s using that.
Robert [00:17:33]: So I think it’s one popular trap that we’re trying to optimize this discussion part. Sometimes, as you said, we don’t have good tools how to discuss requirements with product owner and/ or product manager. We’ll get into that soon. So we’ll give you some tools.
Robert [00:17:50]: Yeah, it can lead to that, but it’s, I think, important to ask ourselves the question, what’s the alternative here? And often, the alternative is not the best.
Miłosz [00:18:00]: outcome of this can be simplification.
Miłosz [00:18:03]: I think you need skilled developers that can have this. Product vision a bit and can talk with product owner, for example, and suggest some solutions. But because often the reason the meetings drags on so long is that we talk about two big problems at once. So we want to create this full system or big feature up front. And there are many edge cases. Developers love poking those edge cases and they will come up with many many issues. So then you have like 20 things you need to tackle before you start the development because there are so many edge cases to cover. And very often, if you start with a simpler version of the same feature, it may be much, much easier to discuss and start. And also very often you… you later realize and actually, you know this is like 80% good, maybe we don’t need most of what we thought we needed in the beginning.
Robert [00:19:09]: I think it’s some kind of meta advice that it’s already coming in multiple episodes that we had earlier. So some golden standards that we have tried to have in teams that we’ve been working in. To be able to deliver each task within one day and to be able to deliver some, let’s name it, story within one week. Because, if you’re implementing, you’re creating some functionality into something existing. But it helps us to… Simplify those discussions because, if you are discussing some feature for multiple hours, and you would like to implement within one week, you already see that okay it cannot happen. Because, if you are discussing some feature for multiple hours, the implementation of that will just take much longer. So it’s good because you can start a discussion like, ‘Okay, it’s already scope creep. Let’s try to figure out what we can do. Some kind of how we can make some kind of MVP out of that, and start with that, and iterate on that. I said that it’s working for features that you’re already building on already existing functionality.
Robert [00:20:17]: Because, in this case, you can do it faster. It’s a bit different when you are doing kickoff of new project. Because, if you are doing kickoff of some project, sometimes you need a bit more time to have something that is functional. So, but I would say that you should also watch out to not exceed, let’s say, one month. For example, and have in one month some MVP that already delivers something, and somebody can already use that, and you can already receive some feedback on that. And again, I think it may sound very obvious, but…
SPEAKER_2 [00:20:47]: Thank you.
Robert [00:20:48]: It just works, basically. So it’s one of those advices that are too simple to be true, but this is how it works.
Miłosz [00:20:57]: Splitting work is not easy, for sure. We’ll probably need another episode on this. But coming back to this… with product owner. This is probably an upgrade on the previous approach.
Miłosz [00:21:09]: Product owner deciding on everything themselves, but it’s still… not perfect, right? Because this is a single point of failure. This one person, they understand the domain, they talk with stakeholders or users.
Miłosz [00:21:24]: But they still don’t know everything. So they are kind of a proxy between the development team and whoever needs the product built.
Robert [00:21:34]: And if you are working this way, probably more than once you have situation like you are asking some question to your product owner, he or she is seeing you for a while and I don’t know, I need to ask this stakeholder. I will go back to you in a week.
Robert [00:21:52]: And it’s good because if this question is there, because maybe it will save you one week of implementation that it will be useless at the end. So that’s good. But from other side, you need to often wait for some time for having those.
Miłosz [00:22:06]: Yeah, I remember those planning sessions where we were deciding what to… Take on for the sprint for the next two weeks, and of course, we poke holes in some plant features. We see some magic cases that are not solved, and the product owner says, ‘Yeah, you’re right.’ So yeah, I need to go figure out what to do. Meanwhile, here are some well-defined but very unimportant tasks you can do in your sprint. So you postpone the important work this way, and because you don’t have anything better to do, you start working on something smaller but probably something that’s not really game-changing for the company.
Robert [00:22:50]: But sometimes it’s good, because very often you have this backlog of things that we should do later, a . k . a.
Miłosz [00:22:57]: never. Sure, but this way you never do these game-changing features. Probably the product needs the most. That’s true.
Miłosz [00:23:08]: Because they are so important and risky, no one wants to just… start doing them with some simpler approach. It feels like we need this perfect implementation or specification for it. So you wait until you have it planned perfectly.
Robert [00:23:28]: So what’s the crazy alternative for that?
Miłosz [00:23:30]: Because I know— because we tried this crazy alternative.
Miłosz [00:23:33]: Yeah, so if you go one step further, I guess you could have… developers talk with stakeholders directly? Oh, no, it sounds so expensive.
Miłosz [00:23:44]: Or, you know, just domain experts in general, whoever this is, I don’t know, maybe your users or your CEO or whoever.
Robert [00:23:54]: That are often the source of those requirements. So there are people with knowledge, there are people with some interest, let’s say, but basically… those are people who give you the direction of work that you are working on. And those are the people to whom your product owner is going to ask how to do something. Exactly.
Miłosz [00:24:15]: So it might be your VP of sales or your operations specialist in another team.
Robert [00:24:23]: Or even your CEO. Depends on the company.
Robert [00:24:27]: Um, Or it may be also an operation theme. So it really depends on the functionality that you’re implementing.
Robert [00:24:34]: Usually, if you’re implementing some functionality, there is some person that is mostly interested in that and the idea maker.
Miłosz [00:24:44]: go to your product owner and they will tell them I need this new dashboard built and they will reply okay I will talk with my developers in two weeks later.
Miłosz [00:24:58]: I will let you know two weeks later what we think. But what if instead, no, you have this… This domain expert, this stakeholder meet with developers directly and tell them what they need. And then usually developers… will tell them, oh my god, this is so complicated, it will take two months. But if we drop this one button from the dashboard, it will… take one week. And then the stakeholder says, oh, really? I don’t need this button at all.
Miłosz [00:25:31]: Wow, impossible. Now we save two months of development and also two weeks of planning to figure this out.
Robert [00:25:39]: And this is not a story that we invented. It’s actually what happened multiple times for us when, basically, we could spend ages to implement. Something that the stakeholders would say that it’s not that important. But if we have proxy as product owner, it will never happen because the communication between developers and stakeholders will never happen. And to be exact, so it’s not about gathering all stakeholders in the conference room and discussing. Everything because it will be super inefficient. We’ll go into tools very soon. It’s more about having them meet with developers in some way. At some point. And also not doing it for every feature. So to be exact here. So we’ve been doing it for some bigger project kickoffs. So we’ve been not doing it for… every story that we’re implementing because it would be super expensive, especially that our stakeholders were living in a different country. So it meant that gathering, for example, five stakeholders, and discussing everything with them, would cost flights, hotels, etc.
Robert [00:26:46]: So it was pretty expensive, but still it will work for us and we’ve been doing it multiple times because, if it wouldn’t, it will just…
Miłosz [00:26:55]: Yeah, but this is a bit extreme scenario, right? When we fly over people to meet in the conference room. But this same idea can also be applied on a more simple level.
Robert [00:27:04]: It’s easier if you have stakeholders nearby, let’s say.
Miłosz [00:27:09]: Yeah, but even if you have someone in another team that uses your software and they have some issue, you can just have a call with them and have them show you directly what’s the problem they have. It’s the same idea applied to a more shallow level, so you don’t need your… Thank you. product owner to be a proxy between you two. You just talk directly to them and you understand, okay— this is the issue they have. So now I will figure out how to fix it instead of waiting for perfect requirements to figure out what to do. But I think the basic idea here is that it’s difficult to come over, having developers think about the solution and offer some simplification. And I remember some product owners trying to do it themselves. They somehow… In a way they knew the software developers were working on and they tried to figure out themselves how complex it would be to add a feature here or there. It’s a disaster always. I guess today they will ask AI which feature is the most complex and how I can simplify it.
Miłosz [00:28:27]: Because it won’t work, because you need this expertise to understand what’s going on really. That’s why you need to close the gap, have developers in a discussion.
Robert [00:28:40]: Yeah. So to maybe recap this. So I would say that there are three or four levels of how you can basically be engaged in developing the feature.
Robert [00:28:56]: The top level is pretty close to how you are working on this feature alone. In this situation you are together working with stakeholders— people that basically can make decisions if the feature can look in this way or not, because this is very important. So to have people that you can ask, okay, can we… skip this and they can say yes, no, and you can go further and not wait one week for decision. It doesn’t need to be like that for every story. It’s probably better for kicking off a big feature. So when we’ve been working on some features like some bigger epics, let’s say, that we’ve been working for Hazier, for example, or some new functionality. This is what we’ve been using.
Robert [00:29:41]: One lever lower, you have situation when your product owner, product manager, is gathering requirements and you are working on them together.
Robert [00:29:51]: In case of doubt, the product owner can go and ask some stakeholders if it’s problematic or not. It works nicely for some stories because usually you can wait for a while and you’re planning it in advance, so it’s not an issue that it can be a bit delayed.
Robert [00:30:09]: I would probably not recommend the ‘golden cages’ approach when basically you are receiving some specification or some task from somebody else and you are just just writing this without really affecting how it’s implemented because it’s very ineffective.
Miłosz [00:30:24]: So we said that it’s better from product perspective.
Miłosz [00:30:29]: Work directly with domain experts and so on. But why should developers care? Because, for many developers, they are fine being just an engineer and waiting for requirements. Is there anything for them in this scenario?
Miłosz [00:30:48]: What do you think?
Robert [00:30:50]: So, I think that there are two things that you should keep in mind. And, as you said, so… Many developers, most, hard to say, but many developers don’t care that much about, let’s say, component success. They are just here working to code and they don’t care that much. But I think it’s not that simple because… You could be such this kind of developer in the market when everybody could get a job easily. But as we already said, it’s not like that anymore. And you need to be a bit more outstanding to get job easily. And to understand job market now, it’s probably important to understand about what companies… care when they’re hiring developers. And well, they care about hiring people that will be useful for them. Let’s put it in this way.
Miłosz [00:31:44]: So basically, if you are able to deliver stuff that they need, they’re kind of happy and you need to make help them make more money, basically, so they can share some of it with you. Now you know there’s less funding than 10 years ago, it was very easy to Oh.
Miłosz [00:32:03]: get VCs to invest in whatever idea you have. So you need to actually deliver something more often. And it’s quite a rare skill to work directly with product. And I think for me the funny thing is: We somehow don’t test this on interviews very often. Also, no one teaches this.
Miłosz [00:32:27]: Universities or even your job, you’re mostly taught to write code. I would even say that we are probably more prepared to be those coding monkeys. Yeah, exactly. If you go for a tech interview, you will encounter the slit code exercises or you will be asked to write some algorithm.
Miłosz [00:32:51]: On a piece of paper or on a whiteboard. Perfect for coding monkeys.
Robert [00:32:54]: Those are requirements. Don’t ask questions, just implement them.
Miłosz [00:32:59]: Yeah, the technical details. But then you start… Working and turns out those things are really not that much used. They are not that important. You will spend more time figuring out what to build and what not to build.
Robert [00:33:15]: And often you’re hiring this kind of people that are great in algorithms. And later you are finding out that they are expecting them to give them tasks, requirements, and they can just code that. And obviously there are companies where it works, but in the product companies… We already covered why it’s not working.
Robert [00:33:36]: It’s also pretty hard to change your mindset if you’ve been working for entire career in this way. So this is obviously the important thing to think about. I mean, if you’re working this way.
Robert [00:33:50]: And you will be working this way for your entire… Okay, maybe not your entire life, but for longer time, it’s harder later to switch. And companies are also— now better in picking, if people actually have some skills to be a bit more engaged in the in the way how product is developed.
Miłosz [00:34:13]: It’s harder to hide your incompetence behind some algorithm. and technical stuff. For many product companies, it’s not that important. For the technical skills you have, I ignore it.
Miłosz [00:34:30]: You know, data structures you can implement on a whiteboard. They are not that much relevant. They need to deliver something quickly to the market, and iterate over it, and do it over and over. So, if you can communicate well, you can talk with domain experts, you can figure out what they need to build, and you can deliver it. And that’s someone companies probably want to hire.
Robert [00:34:54]: And even if somebody will manage to be hired, many companies are also pretty open to let some people go if they will not meet some requirements of how they expect that some people will be operating.
Miłosz [00:35:10]: And on the other hand, if you want to be promoted, for example, delivering is the very best. Probably why to do it. So instead of just waiting for requirements and complaining that it doesn’t work, you can try to help. Whoever needs what they need. And in many companies, probably in most companies, this will help you get promoted because they will tell your manager or whoever that you do a great job. It’s really quite simple.
Miłosz [00:35:45]: I think we can say it works.
SPEAKER_2 [00:35:48]: Mm-hmm.
Robert [00:35:49]: And we mentioned earlier that nobody is actually teaching us how to do that. So how to work with requirements of product owner.
Robert [00:36:01]: Nobody’s giving us some tools how to do it efficiently. I mean, There are a lot of resources how to build classes, how to do architecture.
Robert [00:36:12]: How to, I don’t know, use vMotion to be super fast in your IDE. And it’s great, but from other sides, I’m not sure if it’s giving that much return on investment. It’s easier to learn, for sure.
Robert [00:36:26]: And you know, it’s coding. It’s—uh— more cool definitely than working with product. But from other sides, I know that many people are also complaining how much time they were spending on meetings.
Robert [00:36:41]: Actually, okay, maybe if you’re spending a lot of time on meetings, maybe it’s worth to spend some time to understand what you can do to do it more efficiently because it’s also a skill and often you may say, ‘Okay, it’s the responsibility of the product owner, I don’t care.’ Yes, but unfortunately it often doesn’t work this way. And in many companies that we worked earlier, if we wouldn’t initialize to do some changes if it would work like it was working earlier, like people will be coding monkeys in case. The default mode. Yeah, yeah. So I think it’s important to get some initiative and to go outside of this comfort cage or comfort zone. Oh, it sounded so coaching.
Robert [00:37:30]: Thank you. Yeah, it is what it is. I mean, sometimes you need to do some things that you are not that comfortable with, and it’s fine.
Miłosz [00:37:37]: Yeah, but I think it’s also important to mention it’s not for… for company’s sake or just because it’s some moral thing to do. It’s basically how you can grow your career this way. Because you become someone who can deliver stuff, and this is what companies want to pay for. Exactly. So I would say do it for your own sake, for your career’s sake. And it will affect your productivity much, much more.
Robert [00:38:08]: I can attest that you can have a bit less of bad meetings that you have. And if you have some tools how to do that. Okay, so we’ve already mentioned a couple of times about that we have some tools, techniques earlier, and probably you are waiting to learn what those tools or techniques are. are. So you can try to use them, experiment with them, and maybe improve a bit how you can do that.
Miłosz [00:38:35]: So, is there any tool you recommend for this?
Robert [00:38:39]: I think I’m not sure if you agree, but I’m quite sure that one of the tools that created most impact in the teams that we’ve been using was brainstorming. When we’ve been working some things that at the beginning was working this default mode close to golden cages, it helped us to… to trigger some discussion between developers and non-developers and to think more how to implement those features.
Miłosz [00:39:11]: Yeah, so maybe if someone doesn’t know event storming, we can… Uh, give a quick TLDR: this is a brainstorming session where you gather developers and domain experts in one room and have them use sticky notes. I know how it sounds—yeah, but basically, the idea is to have this lightweight conversation about complex topics so everyone is on the same page.
Robert [00:39:42]: Even if it sounds, again, maybe I like, again, some coachy, agile, Scrum Master-ish thing.
Robert [00:39:52]: It’s actually a very good technique created by Alberto Brandolini, who is a software engineer. He’s not some agile coach or whatever.
Robert [00:40:02]: software engineer, so it’s very close to implementation. So the artwork that you’re creating is very close to implementation and it can be mapped to the code. Nicely and it gives us some nice framework to discuss some functionalities that we’d like to implement. And we’ve been using it in multiple contexts. So we’ve been using it for this smaller planning for these weekly stories, but we’ve been using it also for some bigger strategic features that we’ve been spending, for example, here. And it’s not about creating a big upfront design. It was rather to have some high-level idea on how everything interacts, how we would like to interact with other teams, to see complexity where it’s there. Because very often… There is one problem with stakeholders. They are going to you with some functionality and they are saying that ‘Why so long?
Miłosz [00:40:57]: Yeah.’
Miłosz [00:40:58]: At least you have a way to have everyone start to discuss a topic in a different way than just sitting and looking at a presentation. And at first everyone is a bit confused, but then very often you have these lively discussions about the product.
Robert [00:41:20]: I can also recommend you to maybe Google event storming so you can see how the artifact at the end looks like. But the idea is that basically you are using notation of domain events.
Robert [00:41:32]: In the simplest kind of session and trying to model how our system works. And it’s nice because it’s creating some visible artifact that’s showing the interactions in the system, but it’s also showing the complexity there. I mean, if you’re working on this artifact together, with product owner or stakeholders, it’s kind of closing all those questions: ‘why is it that complicated because if system is complicated, it’s usually visible in the board— that’s a very visual representation.
Miłosz [00:42:04]: And this is not a technical representation, right? So it’s not about diagrams or database schemas.
Robert [00:42:09]: It’s something that stakeholders can also understand, but it’s also cool because you can also translate it later to your code very directly.
Miłosz [00:42:17]: So very often, if you do it for an existing system that has been around for a while, you will see how developers use a bit different names than other people in the company and start to close this gap.
Miłosz [00:42:33]: It’s very interesting when you ask your colleagues from other teams to map out how it works from their perspective. Hmm-mmm. It’s like you see a bit different system than you are used to. It’s the same thing, but they use a bit different names. They don’t know all the details. And if you do it together, you get a lot of insight from this.
SPEAKER_2 [00:43:00]: Hmm-mmm.
Robert [00:43:01]: And as I said, so for us, it was game changer in multiple things that we’ve been in. And from my perspective, it’s really a shame that it’s not adopted much wider. So, the domain-driven design community is probably best in adaptation of that, so a lot of domain-driven design practitioners are using that by default. I would say that outside of this cycle, it’s not that widely adopted. Again, I think it’s a shame. I’m not sure actually why, but maybe it’s the thing of the forum that for a lot of people it’s like, ‘ah, some agile or coaching stuff, sticky notes again.’ Maybe it’s… because of some cynism. I don’t know.
Miłosz [00:43:43]: You also need someone who facilitates this session so it doesn’t end up with… People discussing stuff in smaller groups and not participating together or just going to some off-topic. So it’s not that easy. Always to run it you have to figure out how to do it a bit, but I think it’s worth it. In a way, it’s probably better than having one person speak and everyone sleep on the chairs in the conference room. After the meeting, you decide to run another meeting because you don’t know what to do next.
Robert [00:44:20]: I think you need to also have some more open-minded people for that. It’s great if you would like to try that, but you’re not always working in teams when you have good climate for running it. I know how hard it sometimes can be.
Robert [00:44:37]: It can be the reason. And in this episode, we’ll not cover into details how to run this kind of sessions, because probably it will be… pretty long. There’s also one very good resource from which we’ve been learning how to do that. This is the ebook from the creator of the technique. It’s named Introducing Event Storming by Alberto Brandolini. We’ll link this in the episode notes.
Robert [00:45:07]: This is what I recommend you to check. But we have some tips how to try to convince your teammates, your product manager and people around to try that. Probably the first tip will be to try it maybe on a smaller scale. So don’t start with this big session of planning for a half year, getting your stakeholders from abroad. And don’t start with booking.
Miłosz [00:45:38]: plane tickets?
Robert [00:45:39]: Yeah, so I would recommend to start with maybe those planning sessions that you are doing with the rest of your team, maybe with product manager. And try to learn how to run those sessions. Because we’ve been running sometimes some bigger session with 20, 30 people. It’s much, much harder than with just your team.
Miłosz [00:45:57]: That’s for sure. Especially if you have someone who’s skeptical of this idea, they will just try to discourage everyone to continue because, oh, we know how everything works already. Why do you do it again?
SPEAKER_2 [00:46:12]: Hmm-mm.
Miłosz [00:46:14]: I remember sessions like this.
Robert [00:46:16]: But also don’t try to look for excuses like, ‘I’m introvert, I don’t like to do that.’ I’m also, and I did that, and you can just do it. No worries.
Miłosz [00:46:25]: It can be tiring, but there is some end goal in all this. You want to figure out the domain. It’s not just a meeting for the meeting’s sake.
Robert [00:46:36]: It’s tiring, but from other side, I think it’s also very satisfying when it was successful and later you are sitting to implement that and you can later feel how this implementation is just flowing. And it’s also causing a lot of questions and solving a lot of problems that we’ve been mentioning at the beginning of the episode.
Robert [00:46:57]: So, if you would like to start with brainstorming, the first good place to try to adopt that is within your team. So, run some smaller sessions. We recommend in-person sessions since the dynamics are a bit better, but I know that also a lot of people doesn’t have this privilege, let’s say, to work in the office. So, if you’re working in a hybrid way, we would recommend to gather and do this in person because it’s working just much better. Because if you’re doing it on Miro or any other online tool, it’s just harder to maintain everybody’s attention because everybody will try to open some other tab. You can do that, but it’s super hard.
Miłosz [00:47:40]: It also happens in in-person meetings when people come to the session with their laptops. Yes, yes, and they are always very confused when you ask them to close them and stand up.
Miłosz [00:47:53]: The first sessions are always fun.
Robert [00:47:54]: But this is mentioned in the ebook, so we’ll not go super deep into that. And it makes sense. So the first thing you should also discuss it with your team. So you should have some better understanding of what problems you may have with delivering and planning.
Robert [00:48:13]: You can use them to try to convince people that. Let’s try to maybe do it in a different way and try to get buy-in from your team to try that.
Miłosz [00:48:23]: I know it’s often difficult, and we often get asked how to convince my team to start using and driven design. This is a similar idea here.
Miłosz [00:48:35]: I think maybe you can find, if it’s not your entire team, a people like likely-minded as you who want to do something better and try to figure out together how you can improve how you deliver software, basically, and like we’ve been mentioning at the beginning—so, in our podcast, we would like to give you some tools that can help you to be promoted to principal engineer, for example.
Robert [00:49:04]: So getting buy-in of people is a very important skill to be principal engineer.
Robert [00:49:11]: We believe that if you’re a principal engineer, you’re not the person that is forcing people to do something. It’s rather showing people some benefits of your ideas. They will just commit to your ideas and they will be happy because it’s giving some solution for the problems that you have.
Miłosz [00:49:28]: Yeah, so if you want to start, you can just take your team, invite them to a session, try to figure it out together, or you can lead if you feel like it.
Miłosz [00:49:44]: Hopefully, you come at something that’s better than your current way of working and this way they see the value. And similar with your… or product person, product owner, or product manager. You can invite them to the session. They should be probably also eager to find better ways to work for all of you because it’s also there in their interest, unless they are, you know, kind of micromanagement freak.
Robert [00:50:17]: But from other side, this micromanagement is often coming out of something, and at the end of that, if you… go deeper, it’s ending up that they would like to deliver stuff faster.
Miłosz [00:50:28]: If you use this card, it’s nice to yeah and it’s it’s usually quite easy to point out the issues you already have. So you can look back at what happened in your recent plannings, let’s say. You can point that out. But this feature took us two months because of all the issues we didn’t know, of all the gaps in the requirements and so on. Maybe we could do it faster the next time. Maybe we can learn from it.
Robert [00:51:07]: It’s also one important argument that is pretty close to the time. So it’s money. I mean, you can say, ‘Okay, last time we one month, which is this amount of money, because this is the average salary of the developer in our teams, if we could spend maybe this next time on planning it better, we could just save this money at the end.’
Miłosz [00:51:34]: Probably the best way to introduce new concepts is to build. Trust first. So, if you just just join the team and you see how that everything is not done the way you would do it— Probably telling the team on the third day that they should reorganize is not a good idea because you don’t know anything about the team and the company. But if you deliver consistently, you build trust, and then people will be more eager to listen to your ideas. You can gradually introduce new ways of working.
Miłosz [00:52:16]: So I would start with this. One common issue with meetings or sessions is the never-ending discussions.
Miłosz [00:52:26]: They tend to make the meetings hours long.
Robert [00:52:30]: And there are some tips about that in the ebook, but I think it’s also worth mentioning because, even if you will read this ebook, it’s easy to get into some never-ending discussions anyway.
Miłosz [00:52:44]: Especially if you have… If you run this big picture strategic sessions with 10 or more people in the room and you start mapping the entire flow on the board, people tend to run into discussions because you know, for every system you have in your company, there will be someone who says, ‘Oh yeah, this is the issue I need this fixed’ and
Miłosz [00:53:08]: It can take a lot of time and it will derail you from the main topic. So it’s useful to have someone act as facilitator and cut that. the discussions early.
Robert [00:53:20]: I’d probably use better work to maybe park it because, if you cut it, somebody may feel like, ‘why are we cutting that?’ It’s probably better. So, what we’ve been doing usually during the session was using the red sticky note. So, we’ve been writing down the problems that we’d like to park, maybe later during the session, maybe after the session, and put it to the board. So, the person that has this problem will feel that, ‘okay, it’s also something that it’s not disappearing, it’s there.’ We won’t forget about it. Yes, yes. But important. Let’s go back to that. Because we’ve already mentioned the trust earlier. So, if you will be parking things and not going back to that later, you may also have problems with this trust part.
Miłosz [00:54:07]: Yeah, so later we had separate discussions, maybe in smaller teams. Maybe not everyone needs to be involved in all of the red cards. Maybe some of them we will… decide just are not important and forget about them or ignore them. But for most, we need to revisit and discuss this again. But this way, we will focus on one thing at a time.
Robert [00:54:31]: Another thing that I think is also in the ebook, but worth mentioning. So this is the time boxing problem. We’ve already mentioned it earlier, but I think it’s one of the biggest issues. So it’s important to emphasize it and mention it again.
Robert [00:54:48]: Getting some balance between cutting discussions but also not skipping discussions that are important. And it’s hard to give some good algorithm how to park some discussion and when to follow it. It’s probably some skill that you need to develop with time, but, as we said earlier, sometimes cutting some discussion may mean that it will go back to you during the implementation and making, changing some. During implementation, it’s much, much more expensive than during planning because you need to go back to planning. Maybe something that you already implemented is not compatible with that and you need to undo that. It’s important to keep it in mind. Experiment. So maybe sometimes try to discuss a bit longer.
Robert [00:55:39]: Maybe sometimes try to cut, and also set expectations that, usually, when we’ve been doing some planning sessions, some vendor storming sessions, we’ve been like, ’excuse.’ After that, because it’s it’s been sometimes hours to do that, but at the end it was worth— I mean, very rarely— we had like, ‘okay,’ we’ve been spending on even storming too much, and we designed it too well.
Miłosz [00:56:04]: We could better deliver something this time.
Miłosz [00:56:08]: This comes a bit back to the topic of cutting scope. If you plan huge features, it will be very difficult to discuss all of it. Yes, but again, cutting scope is not always easy, depending on the project.
Robert [00:56:24]: And again, it’s mentioned in the e-book, but in the… book, you can read that event storming has multiple phases. So at the beginning, you’re generating a ton of ideas. And with the time you’re removing more and more of the things that are not relevant. And usually, at the end, maybe not at the end, but close to the end of the session, you should do some reality check and to think: ‘Okay, is what we plant here deliverable? In depends if you’re adding some feature or doing something big, maybe a week, in worst case one month.’
Robert [00:57:04]: If it’s one month, probably it will be in practice a bit longer. But if it’s longer, probably you should look at it and see what we can cut out of that.
Robert [00:57:15]: To make it functional, usable, let’s say, and work on this basically. It’s not obvious, but we’re often forgetting about that and we are trying to implement a feature that It should take half a year, and it’s going to be two years later.
Miłosz [00:57:34]: Yeah, because no one challenges it. You start planning. Some feature that comes from someone from another team or your CEO or whoever and no one challenges you.
Miłosz [00:57:47]: You need the entire thing. Maybe you need just 80% of it or 50%, and it will be much simpler to deliver.
Robert [00:57:55]: Okay, so we’ve given you some, let’s say, brief introduction to event storming. Again, it’s not something for episode because I think even one episode will be not enough for that. But if it sounds interesting for you, please leave us a comment. Maybe we’ll do some episodes just about event storming. But. Yeah, I hope that it will give you some overview why it makes sense to try to think out of this thing out of the cage.
Miłosz [00:58:29]: Maybe let’s reiterate some ideas. What can someone do if they see this is an issue, if they want to work better with the product?
Robert [00:58:40]: Yeah, so I think at the beginning, you should assess in what level of cage you are, let’s name it. So, if you are receiving tasks and it’s assigned to you, or you are maybe closer to the way when you’re planning tasks with your product owner but you’re never discussing with stakeholders.
Robert [00:59:05]: Tchum! Think on which level you are. Mm-hmm. Uh, later. Discuss with your teammates if they also see those problems. You should be able to identify the problems with feature planning already. On this episode, so it should give you some weapons.
Miłosz [00:59:24]: Yeah, try to figure it out together. Just not try to force. Your teammates to do some of your ideas right away. Try to think together what are the issues you want to improve.
Miłosz [00:59:41]: Can write down specific problems you have or even situations. So I remember we had a very issues like this— one task has been on hold for one month because of something, I don’t know, some miscommunication or whatever.
Robert [01:00:00]: Or maybe you lost a lot of time on implementing something that used to be useless at the end and your stakeholders said… This is not what we asked about.
Miłosz [01:00:10]: Yeah, we delivered something and then it was scraped because no one needed it. And… probably the more specific it is the better because you can then rise it with your manager or product owner or whoever is in charge Instead of complaining that we never get anything done, you tell them, yeah, this feature could have been one week. but we spent two months.
Robert [01:00:38]: In other words, use the language and arguments that other side care about. You know about what product managers will care. your teammates probably they care about their car so you can also say that okay maybe would like to if would like to get better job later or be promoted, maybe we should try to think about that. And again, if this convincing people to change approach to use your approach. It’s a very important skill of principal engineers.
Robert [01:01:10]: Being principal engineer doesn’t mean that you are forcing people to do something. It means that you are convincing people that your solution will help them with their issues. And that’s it, basically.
Miłosz [01:01:21]: And if it really does, then you get trust.
Miłosz [01:01:26]: You need to accept that some people just won’t care, and it’s also fine. Don’t try to force them to do anything, whether they are developers or not. And I would instead try to find people who care and try to work with them. So if your product owner doesn’t care, doesn’t want to change how they work, maybe to go to their manager and tell them there’s an issue. Basically, find someone who cares about work getting done in this company.
Robert [01:01:58]: If it’s not possible due to political reasons, just maybe do it within your team.
Robert [01:02:05]: We don’t recommend that, but it’s better to do event storming session within your technical team without product owner than not doing it at all.
Miłosz [01:02:16]: There’s also the last advice we didn’t mention in this episode yet, which is change your job.
Miłosz [01:02:22]: It’s always the solution.
Robert [01:02:26]: But again, please don’t use it also as an excuse to not include your product manager, because you would be surprised. I mean, how often they care more than you. You think. They just have a bit different goals, but…
Miłosz [01:02:39]: And they also might have been burned working with developers in the past. Exactly. If they worked with someone who’s just like, yeah, I don’t care. I will code and give me what to do. They might not be eager to work with you directly. So this goes both ways.
Robert [01:02:54]: Yeah, but from our experience, it’s not the case in 96% of cases. It’s very, very rarely a case that it’s… those are people that I don’t care. So please try and you will be really, really, really surprised. Also, I think it’s important to set expectations.
Robert [01:03:16]: There are no magic techniques that will make all the planning accurate because ideas will always change during implementation. We are going closer to planning better.
Robert [01:03:31]: It will also always take some time to do planning. It’s not magic tool. There is no magic tool that will totally remove meetings. It’s just about making it more efficient. Also be prepared that, okay, if you, for example, decide to use event storming. It will be not super successful from the first session, but it’s also a pretty simple technique, so you’ll be surprised that the result will be pretty good anyway. But also set some expectations. Be prepared to experiment and also improve after each session. Maybe do some evaluation after every session to ask people, okay, did you like that? What you didn’t like? And improve, improve, and improve.
Miłosz [01:04:13]: Especially if you change company culture, which is very, very hard to change. And especially if it’s been like this for a long time.
Robert [01:04:22]: But it’s possible. We did it more than once and later people were eager to work in this way. So it was cool. And it was also cool later to transform it to other companies and also have some success stories that helped us too.
Robert [01:04:39]: Be in different places later. Okay, so I think it will be all for today. So if you have any questions about windstorming, about getting out of the cage or any similar topics, let us know in comments on Spotify.
Miłosz [01:04:54]: Yeah, also share your stories maybe. I’m sure there are a lot of stories how projects are run. Let us know in the comments how it works. Works for you.
Robert [01:05:05]: If you have any questions, just ask us. We are answering all the comments, so we’ll be also happy to help you.
Robert [01:05:14]: Would be interested in listening about event storming, for example. Let us know so we can maybe also record entire episode just about event storming.
Miłosz [01:05:23]: Hit that like button and subscribe to the channel so you don’t miss the next episodes. We plan to release a new episode every two weeks now.
Robert [01:05:32]: Yep. So, thank you, Miłosz, for your time. And see you in two weeks.
Miłosz [01:05:35]: Thank you, Robert. See you.
Robert [01:05:36]: Bye.
