Thank you for the share! I think the only thing I would have a different opinion on is Fail #1. From your profile, you have a lot of experience with really big companies like Mercedes-Benz, Bosch, and IBM. Those are companies with huge head counts and user bases so in that space, you do have to be really careful about breaking things. But I have worked with SMBs for more than half of my career at this point after being at a big corporation and the situation is vastly different. I can take the risk to break things without it being a huge deal because the user base could be like <20 report users max and they all know me and that I can revert if needed ASAP. The lines of communication are much shorter in the space I am in and that allows us to move faster than we would if we were 10x bigger.
Why do I do I think this? It's because I've seen stakeholders say hold onto everything "just in case" but then not use it anyway and then I end up with a sprawling mass of unused data. This runs into fail #2, #6 and more. Sometimes, people have no idea what they use (but they also won't tell you that). If you remove it and there are crickets, then there is no use case. Context is important too of course. If it's truly operational, then err on the side of caution. But if it's a YoY or MoM report checked once a year or month, then does half a day of the report being down make that big of a difference?
I agree with you on the first point, if you are so close to your customers and you have only like 20 then the toleration is high but still communication is the key.
I think I have over 10k customers in my data products and ofc we do changes but with careful communications and this ofc makes us slower than you.
There is word that we use a lot in tech world “it depends” so there are really not one gold rules that fit all companies all projects .. we have always try to push on stack holders to understand requirements and only design systems based on it.
This is a great post. Those mistakes are perfectly matched as my mistakes currently i am making. Yet haven't learned how to solve this mistakes.
At present, as a planning engineer in a transformer production company, i collect data from the production floor, then i plan for next 6 months consumption. My data has lost trust due to the mistake. And also all of those ten mistakes i am currently in.
Thank you for sharing these valuable lessons. They really helped me a lot.
Thank you for the share! I think the only thing I would have a different opinion on is Fail #1. From your profile, you have a lot of experience with really big companies like Mercedes-Benz, Bosch, and IBM. Those are companies with huge head counts and user bases so in that space, you do have to be really careful about breaking things. But I have worked with SMBs for more than half of my career at this point after being at a big corporation and the situation is vastly different. I can take the risk to break things without it being a huge deal because the user base could be like <20 report users max and they all know me and that I can revert if needed ASAP. The lines of communication are much shorter in the space I am in and that allows us to move faster than we would if we were 10x bigger.
Why do I do I think this? It's because I've seen stakeholders say hold onto everything "just in case" but then not use it anyway and then I end up with a sprawling mass of unused data. This runs into fail #2, #6 and more. Sometimes, people have no idea what they use (but they also won't tell you that). If you remove it and there are crickets, then there is no use case. Context is important too of course. If it's truly operational, then err on the side of caution. But if it's a YoY or MoM report checked once a year or month, then does half a day of the report being down make that big of a difference?
Wow Chris I like your take.
I agree with you on the first point, if you are so close to your customers and you have only like 20 then the toleration is high but still communication is the key.
I think I have over 10k customers in my data products and ofc we do changes but with careful communications and this ofc makes us slower than you.
There is word that we use a lot in tech world “it depends” so there are really not one gold rules that fit all companies all projects .. we have always try to push on stack holders to understand requirements and only design systems based on it.
This is a great post. Those mistakes are perfectly matched as my mistakes currently i am making. Yet haven't learned how to solve this mistakes.
At present, as a planning engineer in a transformer production company, i collect data from the production floor, then i plan for next 6 months consumption. My data has lost trust due to the mistake. And also all of those ten mistakes i am currently in.