Comparing development cultures

Searching for engineering in investment banking vs startups returns so many results on your search engine of choice, that it is clear that many people are curious to know what the differences between them are. So let me preface by saying that this post doesn’t attempt to answer questions like “Which is better — Startup or MegaCorp Inc., Silicon Valley or Wall Street”. I want to simply present my viewpoint, comparing my experience of working in engineering teams at both investment banks (past) and startups (current).

Before joining Semantics3 as an engineer, I previously worked for almost half-a-decade at the technology team in an investment bank. At both the engineering teams we shared a common goal — help business drive growth. Given that the aim of the engineering teams were somewhat similar, I would like to focus on the finer aspects of software development process to present my observations.

Product Development Cycle

In the investment banking world, when a product/application is built, its lifetime is expected to be a few years at a minimum. Considerable amount of time is spent on planning and strategizing on how to build the product. Discussions usually involve logistics on what tools to use, how to maintain the product, and timelines to look at.

“The line between disorder and order lies in logistics” — Sun Tzu

The striking distinction I felt was that startups tend to move at a much faster pace and are not afraid to break things (aka move fast and break things).

Startups seem to have shorter product development cycles and in each iteration features are added, removed or re-built depending upon the need. They also tend to focus on the problem at hand rather than over-think and over-engineer the task. At the investment bank, product enhancement releases were only done over the weekend because the system needs to be running in the weekdays and it breaking intra-week would have been very expensive in terms of money and time spent to fix it. Whereas, in a startup enhancements are often released faster, sometimes within a one week cycle owing to the fast-paced environment.

Distributed Decision Making

In a startup environment, the relationship between engineering and business teams is symbiotic. There is a two-way flow of ideas/feature-concepts for the overall product development. At the investment bank, business teams are very clear on what they want (citing their experience) and feature requests are heavily business driven. Usually, the business ideas trickle down as development tasks, often being marked with higher priority and urgency.

Team Structure and Management

There were separate teams for managing infrastructure and providing support apart from the application development team in an investment bank. Within the development team, it was always ensured that more than one person knew about any particular project/application. Even if you had doubts about any technology, there were other people to help you out. Even when there were ad hoc requests/BAU work, teammates would take turns to handle them so that the knowledge gets spread out and dependency on a single person is eliminated. Bus Factor > 1.

Whereas, in an early-stage startup this may not be the case. There is often a single person managing taking complete ownership of the project and overlap with another person is very minimal. The person becomes very specialized in the technology that he works on.

Tech Stack

Investment banks tend to use well validated and proven technology. In recent years, with concerted efforts from senior tech leads, they have started to accept the use of non-traditional technology, but have a long way to catch up with the pace of startups. Startups are ready to use innovative, well-documented and community supported technology if it would get the job done.

Case in point, I would like to just leave this table here, comparing the tech stacks I have seen so far.

                  IB          Semantics3
Database          KDB         Postgres
Message Queues    EMS         RabbitMQ
ETL Workflow      JAVA + Q    Perl
Scheduling        Autosys     Crontab
Monitoring        Geneos      Console
Scripting         Bash + Q    Zsh + Perl

Testing

Investment banks spend a lot of time and resources on testing and code review. Code review is a very important step especially when teams from multiple regions are involved in the development. In startups, there is limited code review because there is only one person working on it and often by being agile, the testing is done by the developer himself. Investment banks usually have a separate testing team, but now can be seen moving towards DevOps and agile workflows.

Automation of tasks

If a considerable amount of time is spent daily on a manual task, our culture is to immediately look into ways of automating it. Put in some glue code as it saves lot of developer’s time in the long run. If there are other high priority/urgent tasks such automation work gets shelved in banks. Such glue code may not pass the code review and production standards in investment bank and the automation task would become a project by itself.

Summary

There is no right or wrong approach. Different teams based on composition, vision and mission have different cultures when it comes to engineering. Both investment banks and startups work in a fast paced environment. Investment banks tend to follow a structured and systematic workflow when it comes to product development. Investment banks can benefit by learning from startups on how to be innovative and change the traditional mindset.