9 years in The Bank – lessons learned

I worked at RBS for almost a decade. During my nine years at the bank, I got the opportunity to work with very talented and smart people, and I learned a lot. I want to use this opportunity to summarise some learnings and experiences that I encountered during that time.

Large Organisations are like Big Ships

Large Organisations, like traditional banks, are like big ships, hard to get going, require an enormous amount of energy to move and a long distance to stop. When it finally departs, it’s impossible for it to quickly and swiftly change the direction. The organization is on the constant lookout for problems far into the horizon, to be ready for a direction change maneuver. Finally, if unexpected happens, just like the Titanic, the ship will not be able to avoid the obstacle and will crash into it. Make a mental note as this will impede decisions and choices you’ll have to make.

Smart people do dumb things – the fallacy of targets

I’ve seen people make irrational decisions, sacrificing Software quality and Customer Experience for the sake of delivering to deadlines. Deadlines quite often self-imposed, making no commercial reason. Those decisions were driven by localized targets, imposed by line managers. Values that the organization pursued, the good of customer was forgotten because the way performance was assessed, was against the targets.
The result was a poor quality software, delivered at a high cost, and at the end had to be scrapped and re-written. Beware of personal targets as those are often in direct opposition to organization vision and objectives.

Smart people do smart things – if you give them some autonomy

I’ve seen and been working in the hugely successful teams. Teams were focused, creative in solving problems and very productive. Motivation was high as well as team satisfaction. What was common for those teams was the autonomy in solving a clearly articulated problem they were given.
When you hire smart people, give them problems to solve, guide them in organization intricacies and help get the resources they need to solve problems but don’t tell them what to do (don’t micromanage).

Shared services for technology don’t work

Creating a team of specialists (for example DataPower developers), co-locating them in one place and offering their skills as services to delivery teams via the ticketing system is a recipe for disaster. Something that makes sense from the accounting point of view doesn’t work for agile teams that are building software. Again, localized targets for Shared Service teams are never aligned with the vision for product teams.

Beware of re-inventing the wheel

I’ve seen the countless amount of open-source frameworks and tools wrapped in a “thin” wrapper, offering the “same” functionality as the original. In reality, central platform teams started with good intention but hardly ever had the time, resources or expertise to deliver the promise. Avoid re-inventing the wheel, instead of wrapping try to integrate and use extension mechanisms.

Management and Leadership are two different things

Leaders inspire people to take actions; managers help people to overcome obstacles and deal with distribution of work. It is possible to be a great leader but at the same time a terrible manager, and the other way around as well. During the nine years, I’ve not met a single Great Leader who was a great manager as well. I believe that in a large organization this happens due to a simple lack of time to perform both roles well. Beware of giving Leaders the responsibilities of managers. They might do a mediocre job at both instead of great at one.

Distributed work is hard

Distributing work on a single product creates communication overhead. For example, scaling one team into two teams creates the illusion of doubling productivity. In reality communication, teams synchronization and integration overhead will only yield a fraction of improvement. Introducing new teams, distributed across different location only amplifies the problem reducing improvements further. When scaling for improved productivity, first look into augmenting existing team and fixing all issues in the delivery process to achieve a smooth flow of work.

Working with vendors require much care

Agencies and Consultancies like to deliver software or services on their terms. The typical sales pitch will mention how beneficial it is for the customer and how productive they can be. The only problem is that quite often after the engagement is done, resulting work doesn’t integrate, is build with incompatible or problematic technologies or lacks on quality. When choosing vendors, make sure to have a set of requirements ready, including technologies to use, ways of working (e.g., integrate early and often), engineering practices and quality standards. If you hear questions related to the above list from the vendor, it’s a good sign, but don’t take anything for granted.

Scaling teams to early could backfire

This point is the expansion of the previous mark of Distributing work. If appropriate software architecture, engineering practices, and delivery pipeline are not in place, the resulting product will lack in quality and cohesive solution. Multiple teams will try to isolate itself via designing architecture and solutions that make it possible for them to work in parallel in relative isolation. This time it’s a Convey’s law applicable on the micro level. If you need to move faster, first try to optimize your delivery process before looking into scaling.

Technology is hardly ever a problem

Majority of issues that arise during software development have very little to do with technology and are associated with people relationship and communication problems. Bad communication leads to missed requirements and invalid assumptions. Make sure to validate all the assumptions early and keep revisiting information you gathered. When you have all the requirements, keep on going back to the Product Owner to confirm that what you are building is the right thing. More importantly, if it is still needed.

Finally

Above are just some of the lessons I learned. I will use this knowledge at the new organization I just started work. I think that the above might provoke some thinking for you as well as re-affirm the lessons learned for me.