This all depends on what product your IT department is using for server level backups.
For example, in a virtual environment VMWare will take snapshots of the server. If SQL Server is involved VMWare has an option that most Admins enable (or it could be by default I don't know) that will freeze the IO for the databases during the snapshot. Now while this should only take seconds you have the potential for that to cause problems on your application, and is not really a trusted method to use for restoring database.
If you are using a 3rd party product to do server level backups the likelyhood is this is just taking file-level backups of your databases. In that as well it has to have the ability to take backups of files that are locked, because SQL Server has any attached mdf and ldf files locked from Windows perspective. Symantec's BackupExec for example utilizes Advanced Open File Option to perform this, so it can basically take a picture of that locked file. Just the way that sounds will make most DBAs cringe if the have to restore the database with a backup like that, think about the conistency the database is when it takes that backup. There is no guarentee if the backup is fired while a data load process is ocurring, what part of the data load did that backup get?
SQL Server native backups are trustworthy to the respect they are verified as good backups. You know exactly what state they were in when you fired the backup for a FULL, whether you have this scheduled around data loads and such. A log backup for FULL recovery model guarentees you can restore that database down the second.
If your manager is dead set on using the server level backup I would heavily research the product they are using. I would find out if there is any SQL Server "add-on" or backup agent that can be purchased to let it do VDI backups of the databases.
Something to also consider and discuss with your manager is what involvement you will need to have on verifying and troubleshooting if SQL Server backups fail. I have used Netbackup heavily at previous jobs and had a client few years back wanted to me to go through testing use of Netbackup's SQL Server agent for their environment. This included other DBAs that had to also provide support. I told them upfront that troubleshooting backup failures for SQL Server required you to know a good bit about Netbackup. Netbackup master servers generally are run on Unix servers, so you now have to know some Unix....can be fun but more of a pain if you are already busy. Just something to consider and can be a good discussion point with your manager, and find out who is responsible for troubleshooting failures.