3 ms·
Color me a little confused, but I think I kind of would lean toward letting the database person make the decisions about database rather than the titular manage
by at_a_remove 5y ago
Color me a little confused, but I think I kind of would lean toward letting the database person make the decisions about database rather than the titular managers. Haven't we all been through enough "management heard X technology is hot so we are gonna use that" fiascos?
Management's job is not to make decisions about databases for the database person, but to communicate about problems and priorities, and so on. Don't get me wrong, the dark hilarity of malicious compliance can be great when someone commands you, like they are some bumpkin who just rubbed a lamp and acquired a genie, to do something that is gonna bring down production at noon, cutting off your about-to-be-voiced objection, but let the managers manage and let the experts be experts.
- deleted 5y ago[deleted]
- lstamour 5y agoThat assumes the experts are indeed experts and not just saying no to an experienced consultant/contractor that management hired. Though I agree from the perspective that if the system goes down after the consultant leaves, it’s not their problem. I’ve been around enough to know that these ultimately are political and cultural problems, and you either have to expect change to be slow in these situations or leave to find a different team… I’ve tried a bit of both, and gotten frustrated, and in the end, the stance I’ve settled on is to be helpful to change people’s minds. It’s hard though. Being persistent and pushy with help will fail. Having the person you’re helping describe a problem or agree something is a problem, that is the first step to helping find a solution. I guess another way of putting it is management can suggest using technology X but there should be some kind of identifiable problem to solve. There is always the exception though. For example, the problem identified might be that there are too many technologies and X is the new standard. That’s… sometimes the reason and … what can you do? Having been on both sides of the fence here, you never know, X might not be so bad… or you’ll need to fix a ton of bugs. As long as you stay happy and helpful, you can maybe nudge things in the right direction? For example: X has uptime issues. If X is already adopted, document the known issues for devs or DevOps, or identify consultants for X that can provide training and support. Figure out how to get data into and out of X if you want to refactor later to a different approach and political winds blow that way. Write cheat sheets that can map what you’re using now to Technology X, and what might be unexpected. Who knows, maybe enough people will have heard or seen your materials on Technology X that they’re not as impressed or share your viewpoint on it. And if you’re really unlucky, you’ll set yourself up to be the cheerleader for technology X. So… there are both risks and benefits to getting too involved in technology shifts/adoption.
- hn_version_0023 5y agoHow do you handle the case where Technology X is being deployed because the C-suite was gifted Super Bowl tickets to deploy Technology X? I have been in this exact situation. I left the company as a result; kickbacks and graft aren’t my thing.
- lupire 5y agoSame as any legacy requirement or legal mandate. Deal with it until you get a better job.
- hinkley 5y agoYou can’t have a dozen middle tier and front end people at the whims of one backend guy why isn’t interested in ramping someone up to load shed. That was a terrible contract, and at the end I’m sure they went back to the status quo. Him holding the reins of the data and his job while the initiative ramped down and they waited for the next time they got the political will to spend a bunch of money.