hernaes.com

Innovation – Finance – Technology

Uncategorized

Scaling development capacity

As head of business development and IT, making sure we have sufficient developer capacity to reach our goals is a significant part of my job. I thought I’d share the story of how we successfully have scaled our development capacity significantly while maintaining productivity and cost-efficiency.

Steve Ballmers infamous chant for developers almost looks like the embodiment of the recruitment agenda for most companies these days. Whether you have an offensive or defensive approach to the opportunities represented by technology, the need for developers has never been more imperative.

However, this has not always been the case, and the pendulum has swung on several occasions between having in-house IT to outsourcing everything. Perhaps the most notable example of getting rid of everything came from Nicholas Carr with his infamous quote; “IT doesn’t matter” back in 2003. Basing his claim on how IT will get commoditized the same way as every previous infrastructural technology such as electricity and the railway.

While this may be true for many aspects of IT such as IT operations and maintenance, Carrs claim never took into account that IT, as a fairly young technology was to undergo several S-curves rather than becoming commoditized all together. This requires a pragmatic approach to IT, where the technology itself is merely an enabler to reach your business goals.

As a starting point, constantly evaluate and identify commoditized IT that is designed for heavy lifting rather than speed and purchase this as managed services, standardized software or platform as a service in order to free up internal IT capacity to what really matters. This distinction gave the baseline and a necessary starting point for where to invest our development resources.

An important principle for success was to define a clear principle that we always set capability over capacity. It is no goal in itself to have a high headcount unless you have competent resources. With both scope and guiding principles in place, we were ready to scale our development capacity. here’s a short summary of some of the things we’ve done:

Engaged the tech talent of tomorrow

A way to further scale our development capacity while taking corporate responsibility and give something back to the community was to look to the educating institution in Bergen. We wanted to increase our developer capacity, while the students were looking for relevant experience. An obvious win-win situation where we have a pool of students working part-time as developers while finishing their degrees at the local universities. This has proved to be a great success, and the students are contributing to several development activities with high strategic value. As an added bonus, the majority of our part-time developers have chosen to start full-time when they get their degree.

Established offshore development capability

Recruiting developers in Norway is an uphill battle. With demand exceeding the supply of competent resources we needed to look beyond our borders. In order to succeed with offshore development, it was imperative that our offshore teams could act as an extension o four existing development capacity as opposed to a completely different business unit. This gave us some guiding principles. For compliant access to relevant data without too much administrative overhead and increased operation risk, our offshore development center should preferably be located inside the European Union. Also, working in an agile environment, a time zone difference of more than 1 hour would interfere with necessary clarifications underway.

With sound and good advice from the board, succeeding with offshore development required a long term commitment, where the offshore resources were hired solely to work for us rather than gaining access to resources through a consulting entity. While this requires a larger investment in terms of commitment and resource onboarding, I can safely say that this has paid off already in the medium run, and will definitely pay off even more in the long run.

Based on these prerequisites we chose to establish an offshore development capacity in Lisbon, Portugal in collaboration with Inscale last year where we have ten developers so far and is looking to expand further in 2019.

Another success factor was to make sure our new colleagues became a part of the culture in the bank. This is not granted and required that we invested time in getting to know each other.

Reduced dependency on external consultants

External consultants may give a short-term capacity boost, but reliance on external consultants for what should be internal development capacity is not a favorable position. This erodes know-how and ownership to business-critical solutions, as well as having an unsustainable cost rate in the long run. I’m not saying that you should not use consultants at all, but consultants should be used for specific expertise rather than capacity fillers.

Established cross-functional autonomous teams

In our organization, we do don-t draw a distinction between IT and the business side. Even though resources are organized in different departments, teams work together as one unit across various disciplines with shared goals. In order to further leverage this, we have with support from SINTEF drawn inspiration from the likes of Spotify and Supercell and given each team their own business targets with the objective to reach their goals with as little outside interference as possible. alignment_large

By now we are almost 100 developers distributed along in-house developers at the main office, offshore development in Lisbon, Portugal, a pool of part-time junior developers and external consultants for specific tasks.  If you wish to be a part of our journey, we are hiring!

 

 

 

4 thoughts on “Scaling development capacity

  • Jugal Verma

    Thanks for sharing your thoughts and where I work at If Forsikring, I can identify and related how what you say. We have even experimenting with cross-functional autonomous teams for sometime now … I guess we still have a way to go on having the cross functional teams fully autonomous.

    Reply
  • Jugal Verma

    Thanks for sharing your thoughts Christoffer and from where I work at If Forsikring, I can identify and related how what you say. We have been experimenting with cross-functional autonomous teams for sometime now … but I guess we still have a way to go on having the ‘cross functional’ teams fully autonomous. When you have a mix of developers from vendors (through managed services contract) and your own in-house developers in the crosss functional team, achieving full autonomy is a bit more challenging than that of a team setup where you have contractors in a time&material (read as resource augmentation) setup plus your in-house developers. Thanks – Jugal

    Reply
  • Pingback: Seven reasons digital transformation fail – and how to overcome them – hernaes.com

Leave a Reply to Jugal Verma Cancel reply

Your email address will not be published. Required fields are marked *