Great article. However, I have a slightly different perspective.
No one really disagrees on the fact that most of the work done by the data teams get overlooked. As already said; 200 dashboards built, only 10 are used regularly. However to allow the data team to have perspective and make valid recommendations, they need to be involved in the day-to-day activities of managing the company. Having a clear idea of the company's "true north" simply is not enough, they need to have enough context of why these metrics matter, what the current situation of the company within its market is, what past decisions were made based on these metrics and what were their outcomes. It's another full-time job and the engineers simply don't have the capacity to do all of this next to their everyday tasks.
What I suggest is simply to apply the complete product management life cycle to any created data assets. Break loose for the ticket hell, instead treat every request as a product or a feature within a product. Have a product owner sit with your stakeholders and discuss what they really need. Run analysis on the adoption rate of your product and ask for feedback from the users. Meet up regularly with your team and see how can you attract new users and increase the adaptability of what you already built, and if there is no way of improvement, consider retiring the product.
I've watched analysts send a link to a query or dashboard and call the job done. Sending the link is what the work looks like when the job was defined as produce the artifact, not change the decision.
One push. You put the hard part in the interpretation and frame the fix as a habit. But forming the opinion was never the hard part. Having the authority to act on it is. People stay in the Data layer because the org chart said build pipelines. It never said walk into the room and size the opportunity. Authority is relational, not structural, and most analysts were never granted it.
Define ownership first, or the habit has nowhere to land.
Strong piece. The no-data-alone rule is going in my practice.
Thanks for this post! I wonder why “Building perspective as a habit” is so often overlooked by engineers like myself— maybe because it feels subjective, difficult to measure, and counter to what drew us to engineering roles in the first place. The unfortunate reality is that we’ll never be able to produce 100% accurate and verifiable interpretations, but there’s still significant improvements we can make by deliberately providing our perspective over just sharing out reporting.
Throwing a link to the dashboard over the fence? That almost sounds how we used to work when I started in IT, almost 30 years ago. Wasn't there an Agile Manifesto or something? Something something business people and developers must work together daily throughout the project?
When I'm building data products I'm continuingly talking to the end users: What are you trying to achieve? What actions do you think you will take based on this data? How does that work? Do these numbers sound right to you? I can't imagine building stuff without knowing where it "lands".
Great article. However, I have a slightly different perspective.
No one really disagrees on the fact that most of the work done by the data teams get overlooked. As already said; 200 dashboards built, only 10 are used regularly. However to allow the data team to have perspective and make valid recommendations, they need to be involved in the day-to-day activities of managing the company. Having a clear idea of the company's "true north" simply is not enough, they need to have enough context of why these metrics matter, what the current situation of the company within its market is, what past decisions were made based on these metrics and what were their outcomes. It's another full-time job and the engineers simply don't have the capacity to do all of this next to their everyday tasks.
What I suggest is simply to apply the complete product management life cycle to any created data assets. Break loose for the ticket hell, instead treat every request as a product or a feature within a product. Have a product owner sit with your stakeholders and discuss what they really need. Run analysis on the adoption rate of your product and ask for feedback from the users. Meet up regularly with your team and see how can you attract new users and increase the adaptability of what you already built, and if there is no way of improvement, consider retiring the product.
I've watched analysts send a link to a query or dashboard and call the job done. Sending the link is what the work looks like when the job was defined as produce the artifact, not change the decision.
One push. You put the hard part in the interpretation and frame the fix as a habit. But forming the opinion was never the hard part. Having the authority to act on it is. People stay in the Data layer because the org chart said build pipelines. It never said walk into the room and size the opportunity. Authority is relational, not structural, and most analysts were never granted it.
Define ownership first, or the habit has nowhere to land.
Strong piece. The no-data-alone rule is going in my practice.
What an amazing post!
I nodded along every single sentence.
Congrats and thanks Goutham
Thanks for this post! I wonder why “Building perspective as a habit” is so often overlooked by engineers like myself— maybe because it feels subjective, difficult to measure, and counter to what drew us to engineering roles in the first place. The unfortunate reality is that we’ll never be able to produce 100% accurate and verifiable interpretations, but there’s still significant improvements we can make by deliberately providing our perspective over just sharing out reporting.
Throwing a link to the dashboard over the fence? That almost sounds how we used to work when I started in IT, almost 30 years ago. Wasn't there an Agile Manifesto or something? Something something business people and developers must work together daily throughout the project?
When I'm building data products I'm continuingly talking to the end users: What are you trying to achieve? What actions do you think you will take based on this data? How does that work? Do these numbers sound right to you? I can't imagine building stuff without knowing where it "lands".
values > aptitude > skills.