This question could be answered from many different perspectives including culture, people or tools. I'll zero in on Hackathons as a concrete method for fostering innovation. In the past I've been greatly inspired by the productivity and creativity unleashed during hackathons.
- For a big corporate I believe preparation is the key to a success hackathon:
- Thoughtfully pick a hackathon theme.
- Provide real, de-identified data either through and API or as a database dump.
- Create a positive environment with a good choice of venue, food and MC.
- Award the best ideas, executions and presentations.
- Be committed to taking the best projects to the next level.
How can large organisations attract and retain top tech / engineering talent? Is there a difference in the way we hire engineers vs. other talent?
Unfortunately, I can't speak to the hiring process of engineers vs other talent. However, as far as software engineering goes there is a great shortage in skilled people. Google, Apple and Facebook have all gone on record saying they hire everybody that meets their standards and that there are just not enough people.
For corporate organisations it will be equally if not more tricky to attract capable software engineer. I say maybe even more tricky because big corporations do not provide the promise of huge impact and a stake in a company that an engineer would get in a startup but they also don't provide the reputation or culture that many big tech companies promise (To quote a friend: walking through the Google offices is a bit like entering Wonka's chocolate factory).
I believe big corporates need to build on the ability to pay great salaries, allow for flexible work arrangements and using attractive tools. These were at least the reasons that swayed me. The ANZ was the only company that offered a three day work week which made a huge difference to me and my young family. I know quite a few senior software engineers who all prefer to work part time and/or remotely in order to dedicate more time to their private projects and families, and I believe this trend is on the increase.
Equally, I've never been as happy at work with my immediate colleagues and the tools I'm using. I get to contribute to the Open Source community, I work on Github and affiliates, I've been very keen for years to use the Go programming language which I've already been able to do at the ANZ. I got to sharpen my React and Redux skills and I've been collaborating with some really talented and capable people. I've been given just the right combination of freedom and guidance. This is exactly the environment that I've been longing for and I've already been trying to encourage some of my most capable former colleagues to consider employment here - so I sincerely hope being great will also help attract more engineers through word of mouth.
Why should banks be focused on becoming a software company? How do vendors/partners/outsourcing fit it? And how does working with partners affect/impact permanent employees and innovation?
I think people don't realise how difficult software engineering actually is. I believe the trickiest part about it is the rapidly changing the tools, frameworks, environments and standards - I'd say I'm learning a new one at least once a month. Because of this dynamic environment there are no established best practices for any given set of tools, frameworks and programming languages. According to a hilarious blog post, it would look like this if software engineers built bridges: "[T]he bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they’re still sort of holding up parts of the bridge. Nobody knows which parts, but everybody’s pretty sure they’re important parts."
At the same time it is also true that software is never done. As long as a piece of software is being used it will need to be changed in order to fix bugs, update dependencies, address security concerns or to fit new and missed use cases.
If these two are being put together - software engineering is hard and it's never done - then it is most crucial to retain as many people as possible who know a system intimately, especially systems that hold up the core of a business. Paying somebody who works to a deadline and doesn't have to deal with their creation thereafter cannot render the best outcome. In my opinion, great software is built by people who are passionate about their projects and care about them deeply. They feel a sense of pride and ownership. They are the ones who chase problems down, because they feel responsible. People who belong to an organisation and don't see themselves as mercenaries are the ones best suited to evolve systems, most likely to think laterally and to try out new things.
Innovation cannot be vendorised. It is nearly impossible to create software innovations on paper and therefore innovation doesn't lend itself to outsourcing. New software often starts with a crazy idea or an itch to scratch and somebody runs with it often in their spare time (see Google's 20% time). It requires trial and error, rinse-and-repeat, and discarding of the bad peas. That's what innovation looks like in action.