Respect that the sysadmins have a job to do, and let them do their job. A lot of companies have incompetent sysadmins and this is often not realistic. But I have seen arrogant developers ignore the advice of systems groups even after the sysadmins have proven their competence.
Discuss the design of a new system with sysadmins. There is often valuable insight. Developers often look at discussions with sysadmins and giving initial requirements as "premature optimization". I actually saw the head of a development group say that it was a waste of his time do discuss requirements for new database servers with sysadmins and DBAs, even to the extent of describing whether it is a write-intensive or read-intensive load, or how much storage would be needed.
Discuss performance problems with sysadmins. Honestly only sysadmins are capable of properly interpreting performance metrics on systems. I've seen developers decide that Linux always leaks memory because the free memory reported by "free" always decreases, even after the 10th time the output of "free" is explained.
Don't draw conclusions without discussing it with sysadmins. I've seen developers get stuck on theories such as "databases are always diskbound" (they didn't know that iostat even existed), "RAID 5 is faster for transactional workloads" (based on a recollection of one database system that was moved from one hardware platform to another - it was a read-intensive workload, the RAID5 solution had more and faster drives spread across more controllers. But they forgot these details and only remembered the conclusion.)
Don't design a solution to a systems problem without discussing it with sysadmins. I worked in one pathological environment where developers would design a solution and come asking for small implementation assistance. The members of the Unix group besides myself, the head of the Unix group, and his boss, wanted to treat developers as "customers", not as co-workers trying to make an overall infrastructure function. The customer being always right meant not questioning what they were doing or why. I was the only one who would insist on having the problem described so that a correct solution could be determined. Don't act in ways that create pathological environments such as this. It doesn't result in a net benefit - instead, systems managers will act defensively and everyone will suffer.
You're not in school anymore. These are real-world systems and they do not act in an ideal manner. For example, not everything has zero latency. When a sysadmin warns you that clustering solutions are only for political purposes, and the added complexity of the system decreases overall reliability, take it seriously. You have to design for real-world failure modes, for example when you lose the server you're talking to via TCP, the connection will probably not be reset for you. Sysadmins understand real-world failure modes.
Either listen to what your sysadmin tells you, or complain to management that your sysadmins are incompetent and need to be fired. Ignoring your sysadmin makes no sense.
Consider how you will deploy your application. Realize that discussing this with your sysadmins makes sense. If you have 100 servers that are identical, differing only based on a single configuration file, you may want to consider storing the master copies of these config files in a central location. Realize how much better off everyone is if your application is easy to re-deploy. If there is a problem with a system, would you rather re-deploy in under a minute to a spare, or wait for ages while the broken one is repaired? If you can re-deploy your application, the OS can be upgraded more easily and safely. You might care about this in the future.
If you have a problem that you think might be due to the OS, it makes sense to immediately call the sysadmin to check it out. But after a cursory investigation reveals nothing, you have a duty to explain the problem.
Understand that there is a difference between "responding slowly" and "not responding at all".