And how have you kind of managed to bridge the two of the engineering kind of team leader? How do you manage that conflict between the engineering team, the business and the marketing or kind of product requirements, and especially when things change when needs change and you have to maybe even drop some work and that the engineering team has done the developers have done and that can lead to a lot of loss of morale, those kind of periods, but they're necessary for the company for the business as a whole
Shashank Shekhar
@sshekhar · 3:22
And if that why is sort of communicated often enough and repeated clearly, whether it's in terms of a vision document or whatever our goals, then maybe that helps the scaling up of operations, because assuming everybody buys into the Y and if they don't, clearly they're not a good fit and corrective action needs to be taken. So anyway, just my intuitive answer there. And I'll post a separate swell on what this book contains about organizations. Oh yeah
Shashank Shekhar
@sshekhar · 1:32
Here again. So I guess I realized I didn't exactly answer your question in terms of engineering pure net purity versus scaling up. I just kind of blabbered about scaling up and my thoughts on it in any case, specifically. And I don't think I have all these answers anyways, but in terms of engineering purity and kind of keeping the court clean and doing it the right way versus doing it fast enough. My own approach is that there is no right way
Dan Willis
@DanW · 3:06
Or I questioned a leader's decision because we had everything in front of us. We knew why we were incurring this technical debt and we moved on. And it just makes the process much cleaner and people get on board. So like I said, that's probably not the answer you were looking for. But I think there's just so many different variations of that question
And that's where it gets tricky when you have multiple layers involved in there and a smaller team is much easier to do. But yeah, I think that's a good kind of guidebook and a good way of thinking about what you're working on and a good way to get everybody aligned to have the big picture and understand the core of what you're trying to do. So thanks for that book reference as well regarding the actual problem itself