Research has shown [1] that unit testing actually cuts development time by 20%-30%, because in the long run you will spend less time debugging code or fixing code broken by other changes.

[1] - I don't have time to look-up the specific link right now, so you'll need to trust me on this one! :) But I'm sure one can google it. I remember reading it on an IEEE magazine years ago.

I don't want to come across as anti-unit-test or anti-studies but I suggest you run your own study and gauge your own performance rather than assuming you and your team perform as an average team does.

Thanks to the version control tools we use this is easy. Adopt a policy where you commit code for a SINGLE reason at a time. Enumerate a few standard reasons such as BUGFIX, FEATURE, FEATURE_AND_UNIT_TEST, REQUIREMENTS_CHANGE, UNIT_TEST_MAINTENANCE. Estimate the engineering time that was spent on making the change. Log that duration. Periodically analyze your performance and see for yourself how much time unit-testing is costing or saving you.

In what context does it cut development time?

If you only count the initial development time as "development," writing tests will increase your development time. If you take a longer view, and consider maintenance and later development, having a good test suite makes it easier to find bugs and makes it possible to add features and improve code with confidence that you aren't breaking code that relies on your test suite.

That sounds reasonable