Did you hear the one about the bank that hired a naval architect?

Sorry but there’s no punch line to this one.

It’s just a story.

This is the story about how I became an IT professional in Finance. It’s not that I believe it is a story that you need to know, it’s just that once people learn that I actually graduated from university with a Bachelor degree in Engineering (Naval Architecture), they always ask how I made the ‘leap’.

Baby steps and a lot of initiative are the answer.

No, really. If I have manage to pique your interest, please read on…

I always wanted to be a Naval Architect. I loved design, industrial arts and I loved boats. I realised this early in 1989 whilst on school experience with a regular architecture firm. Houses with all their variation and creativity just didn’t do for me. It was those 4 walls, roof and floor and lack of mobility that did it for me. I released there was something to all this design, but the missing element was my passion – boats. Yachts, ships, destroyers, tankers, submarines – practically anything that could float quite literally would float my boat – (pardon the pun).

So I did it. I studied and became a Naval Architect.

As it turned out, this was a very niche market so I had to find a job that would suit and as you can imagine, there is not a lot of jobs for Naval Architects. Eventually I was offered 2 jobs: one as a mechanical engineer designing heat-sinks for electrical lighting components and the other one as a marine underwriter. I followed my heart and stuck with the boats and became a marine underwriter.

My life as a Marine Underwriter was very un-glamorous. Clerical in fact. Whilst I was well qualified to go out and inspect boats and estimate their insurable value (if they were seaworthy), that wasn’t my job. Instead, I was stuck in a call centre answering calls from Joe Public when they rang to insure their yacht or trailer boat, or cruiser. “Is it moored or on a trailer?” “What year model is the engine & how many horsepower?” This was in 1997 when the internet was only just starting to take off and you couldn’t do your insurance on-line. Much of the role was around manually processing insurance applications sent in from the various branch offices, keying them into the mainframe system, updating name & address details, and giving estimates over the phone. Often you would get irate customers calling to question why their premiums had gone up or that their boats insurable value had depreciated. It wasn’t all that bad as I learnt some valuable customer service skills and all about the world of insurance, premiums and claims.

Then I took some initiative. I figured there had to be an easier way to do an insurance estimate without having to look up values from Glass’s Guide books and manually add up the estimated value of the boat, motor and trailer based on the details provided.

So I built an Access Database application and worked with Glass’s Guide to get the boat valuation data on disk so that it could be loaded into my database. I presented my new application to management and demonstrated how it would improve productivity and allow for estimates to take place faster with less boat knowledge required from the underwriter. Little did I know the company was looking to upgrade their entire insurance system for the impending Y2K situation (the infamous Year 2000 bug that would affect computer stored dates with only 2 digits), so given my demonstrated initiative, I was nominated to represent the boat insurance team as a Business Analyst in the IT team to assist in the design and development of a new insurance product that would be trialled on boat insurance – and if that succeeded, it would be rolled out across the rest of the insurance product spectrum.

As a Business Analyst, I worked with the Application Design Team and documented the business requirements. Then I became a test Analyst and wrote and performed test cases to ensure the system was functioning as expected. Once the work was completed and released, I returned to the Boat insurance team to provide on-site support for the new system. After about 3 months, I transitioned permanently into the IT team and completed the process for the rest of the insurance products.

Once the entire system was rolled out across the hundreds of branches and offices, I was given the opportunity to train as a developer to fix the bugs in the code that I used to find. 6 weeks of intensive training at IBM brought me up to speed on mainframe OS390 systems, CICS, DB2, SQL, COBOL & JCL. I became a systems analyst and searched out the bugs and wrote code to remedy the issues.

About 6 months later in late 1999, I went to an internet Conference and whilst there, met a recruiter who told me about a job working on the internet. I considered staying but this represented an opportunity to work at the bleeding edge of technology, and given it paid more, I jumped at the chance.

So I left insurance and found myself working in a start-up venture. One of the original dot com babies – an independent equities research firm. I was their second IT hire, the first guy being the Network Administrator and then me as the primary developer. I had been playing with HTML over a few years and understood the basics. I had even been building some sites privately under Mammoth Technology. I also had some experience writing VB and VBA code back in Uni and for my Insurance quoting application, and with my training in SQL, I quickly picked up the basics of Microsoft ASP server side technology and SQL Server databases. Over the course of 2 years, we built a dynamic 2-tier secure web based subscription service selling research online of the top 500 Australian stocks and I moved into a management role with a team of 5 developers. When the network administrator left, I picked up responsibility for that as well, managed a few server upgrades and backup schedules, before outsourcing the network administration and help desk.

During this period, I learned a lot about white-labelling websites and we provided a range of commercially branded research sites and reports for a variety of top financial institutions, brokers and financial planners – all based on the one dynamically generated, database driven website. As a research firm, once the delivery mechanism was complete, the research could continue, and further development becomes unnecessary so I moved on.

I then moved into a role as primary developer for an industry representative organisation supporting their existing websites. This was a full time role with not quite enough work for full time development, so this role provided additional valuable experience in setting up and administering Linux web servers. During this time I formally learned the basics of OO programming with JAVA and JSP and Struts. I also went on to learn more about Apache, Tomcat and jBoss web application servers and MySQL and Postgres databases. Due to the large amount of time learning, I was often coming to terms with the challenge and asking my boss for the answers was replied with “RTFM!” (Read The F#$’n Manual”).

When the traditional pattern of in-sourcing IT turned to outsourcing, I was made redundant and went back onto the market. Fortunately due to some valuable networking in my previous role, I picked up a job as a web developer with a former client – an on-line Broker.

This new role was an opportunity to test my ASP, SQL Server and COM skills and very soon gave the opportunity to learn a new language C# or ASP.NET. Throughout my training I was over-come with the similarities to JAVA and syntax which made my ability to pick things up so much easier. At First I worked fixing random production bugs which gave me a great introduction to the architecture and overall coding techniques. Then I worked on building a new .NET site and churned out dozens of pages that linked into .NET web services that my colleagues help provide.

On top of some database tuning tasks, I turned my attention to white-label again and worked on adapting the entire online broker site to suit the requirements of one of the top 5 banks. After successfully delivering this and learning a lot about the value of non-functional testing, I was rewarded with a leadership role – leading a team of 12 developers on a 12 month project to build the equities portion of a wrap solution for one of the country’s leading fund managers. A large part of this role, apart from the HR aspect of managing resources, was around owning the design – making architectural decisions and managing the project from a technical sense.

Before the project was delivered, I had become entangled in a lot of the corporate politics and disagreed with the direction management were taking the company, so I left as soon as the first opportunity presented itself.

That opportunity presented itself in the form of a technical project manager role for a global finance software company. This new role moved me into a global project environment where the various project members were spread across the world; Architects in Sydney, Developers & Testers in Bangkok and Business Analysts and Clients in London with the parent company management in Kansas City. I got my Prince 2 certification to ensure that I was operating to some expected standards and travelled to the UK and spent many late evenings on conference calls with the wider project team. Ultimately, the company restructured and decided they no longer needed an IT presence in Sydney, so once again I was made redundant.

My first experience working for a bank was not for one of the top 5, but they had a reputation for only hiring the best candidates and getting in felt like an achievement itself. Since working there, I have found through my network of friends, associates and recruiters, having this company on my CV will help me to go a long way. This time I was hired as a Development Manager – the perfect hybrid of IT Project Manager and Solution Architect – at least that is how it was sold to me. This was a role I thoroughly enjoyed and given the company’s hiring policy, everyone I worked with was exceptional at what they did -professional, intelligent, talented, motivated, driven and committed to delivery; they made the job so much easier.

Being such a prominent Bank, they were constantly undergoing restructures to keep in line with the market. Ultimately, the division I worked in was merged with another that had a different model to how software projects were run. As a consequence, they no longer recognised Development Managers as such and they migrated into Project Manager roles. Since I was enjoying so much of the software development process, I decided that wasn’t for me and subsequently left.

So that brings me to now.

Now… I am working for another bank. One that values quality and customer satisfaction. As a result, they focus a lot on system stability and high availability – and that is where I work. My job as a Senior Solution Performance Engineer is to help ensure that the bank’s major platforms are always up and running. We look at a lot of metrics and charts and engage throughout the SDLC process to ensure that performance and capacity is considered and tested before anything goes into production.

SO here I am, working in IT and finance. No regrets.

Of course I still love my boats and could stare at a set of blueprints all day long, but alas I have long since lost the skills that go with being a Naval Architect. I guess the thing is once you have the knowledge, you have to use it otherwise it gets forgotten.

Every now and then I come across a mathematical, or fluid dynamics problem and smile – I used to know that stuff.

Now, I know a whole lot more!

Comments are closed.