This was also a great comment by Candice Ciresi, the Director of Global Risk and Compliance, 3 months ago:
> Sorry, I am coming in late to the game here.
> Saying we want the UID for easy ID and deletion is one thing. If we actually intend to track and do something, then that is another issue. This former benefits the user, the latter benefits us. Because we stand to get a benefit, users should opt-in. We will also need to amp up our privacy policy. There needs to be full disclosure in what we gather, why we gather and with whom we share.
>I don’t understand. This should not be an opt in or an opt out. It is a condition of using our product. There is an acceptance of terms and the use of this data should be included in that.
It doesn't seem to me like he is calling shots on critical architecture. He asserted an opinion on something that would affect the revenue stream, which as CFO, is exactly his job.
Reading through the MR comments, it seems to me like that's the case with everyone. The CFO is pursuing profitable options, the legal & compliance teams are making sure everything stays in compliance, the engineers are building what is asked of them, the data analysts and product managers are asking for the data they need to get insights on product enhancement...
The big issue seems to be that everyone is so narrowly focused on just their job function that they are missing the forest for the trees. I also noticed a distinct lack of anyone from any type of customer advocacy teams (does GitLab have anything like that? Account managers, evangelists, developer relations, etc?) that probably would have been able to put forth actual data about if customers would be for/against this change.
> It doesn't seem to me like he is calling shots on critical architecture. He asserted an opinion on something that would affect the revenue stream, which as CFO, is exactly his job.
> Reading through the MR comments, it seems to me like that's the case with everyone. The CFO is pursuing profitable options, the legal & compliance teams are making sure everything stays in compliance, the engineers are building what is asked of them, the data analysts and product managers are asking for the data they need to get insights on product enhancement...
Ideally everyone should be would also be thinking about whether the feature is ethical, even if it's not "exactly their job", because there generally isn't anyone whose job is specifically to decide that.
If you want to talk to your spouse about the possibility of taking the kids to get ice cream or whether the dog has had a treat today you have to speak in code that the short mammals can't understand, otherwise you've all but promised it to them and have to deal with the consequences.
The problem is that for salespeople and business devs, the consequences of putting a bad idea in front of impressionable ears are too abstract and so they never learn. So they put an idea in front of a customer or the board about how they can make a shitload of money and the imaginary check has been cashed even before they've stopped for air.
Without some tough love these problems will be with us forever. Oh, you're going to have to walk back something you said? You'll be embarrased? Too fucking bad. Maybe next time you'll think before you promise someone $500k of work for $250k minus your bonus. Twist in the wind like you deserve.
So someone has sold an idea of making millions and once the engineers or just plain human beings get ahold of it that looks like $200k and a giant pain in everyone's ass. And everyone jumps straight from denial to bargaining with a little detour to anger to yell at the messengers for breaking your shiny dream... that you are not and were never entitled to.
One of GitLab's core values is transparency, including making all of their internal communications public via public merge requests. It's kinda cool, but on the other hand, I've previously spent some time reading their MRs about security policy that made me wary about using GitLab at all.
https://gitlab.com/gitlab-org/gitlab/merge_requests/14182#no...