Visa

• Work on some high-scale systems.
• Decent pay and great benefits.
• The CEO is good.

• The bureaucracy is very bad. You have to talk to so many people for every little thing.

• The tech stack is cumbersome. Dev environments are down a lot, with tons of manual steps. Tooling is slow and painful. Devs don't get much time to build tooling to make their lives, or their QA lives, easier.

• Processes are very complex, manual, and poorly documented.

• Developer velocity is very slow.

• Code quality is a joke most of the time. Things tend to get shoved together because of a deadline coming up. Frameworks get used incorrectly. Then things get re-written since they become an unmaintainable nightmare, and the process repeats.

• Some management initiatives are a net loss (i.e., required code coverage, absolutely NO rollbacks).

• You have to enter every hour you spend on every project into a tracking system (Rally), which "is not used for performance" but feels like it is. Then you use another tracking system to track code changes (Jira), and possibly other tracking systems (Wiki/Teams). It is an unorganized mess.

• The wiki is slow, and search is very bad. Finding accurate information is difficult.

• Tons of gatekeepers and "onboarding" processes for integrating with other teams. These processes suck. When new infrastructure is built, it is not built in a way to be easy to integrate (i.e., lots of meetings and manual steps).

• The release process is terrible. Use of wikis to keep track of release information and release instructions. The process is not automated or consistent. Some of the releases have Jenkins jobs, but even then you need to add your instructions on how to trigger the job for every release, and a guy in Ops must do the release. Teams can't release without Ops involvement. Releases take a long time and are error-prone. It takes days to prepare for a release and must involve several people.

• A case in point with the release process: it once took 3 months to get out a trivial bug fix that customers were running into (there was a workaround, but still, a bad experience), simply because the release process was so terrible and we have "code freezes." The change was fixed for months in lower environments but kept getting de-prioritized due to the work required to do the release!

• Since releases are so difficult, rollbacks are expensive. There is a lot of pressure to get it right, which means development moves slow. Also, upper management (i.e., 3 levels above my boss) criticize me and my boss if you do end up making a mistake which requires a rollback. Stressful! Sometimes I wouldn't be able to sleep at night because I was worried about a release going bad!

• Since there is so much pressure to get releases right, and it is so difficult, lots of changes end up getting bunched together, decreasing velocity, increasing coordination, and increasing risk.

• Gatekeeping by humans in testing environments! You have access to do stuff in dev, but in QA, signoff (pre-pre-prod), SIT (dev integration), and CAS (pre-prod) you don't have control. You have to make a bunch of Jira tickets to get something done, then you need to ping the person assigned to the ticket to work on it because they are super busy with other stuff. It should be automated!

• Bangalore collaboration is a pain (I worked in the US office). Some work, like perf testing or tightly coupled dev work, is done by a counterpart team in Bangalore. This means you need to stay up anywhere from 8 PM to 12 AM to work with them, while they also have to wake up early or stay work late in order to meet with you (the time zone is about a 10-12 hour difference). I have even seen some engineers from Bangalore staying until 2 AM (their time) just to meet with our team here in the USA (how is that okay for non-emergencies?). What doesn't get done in person must get done over email, so it slows the process even more. The Bangalore teams have excellent engineers, but the time difference makes high collaboration work stressful!

• Lots of penny pinching for projects. I guess it is somewhat normal since companies can't just spend money on whatever, but getting a project funded is a long and painful process.

• So many approvals, including getting rubber stamps from architects that are very disconnected from your projects. It seems to rarely catch problems or enhance the designs (in my experience) and ends up being a big time waster.

• A bunch of TOI (transfer of information) sessions. Rather than having everything clearly documented and easy to find, you need to schedule a meeting with someone to learn how stuff works, almost on a daily basis. This takes a lot of time.

Bottom line: Visa is a big place with lots of real and hard challenges due to the nature of the business. Visa systems can't get hacked (internally or externally), can't go down, can't have critical bugs, must handle large loads, and need to adapt to the changing market. As a result, there are a lot of challenges that Visa must solve, and a lot of risk that must be dealt with. The way Visa is solving them today is very bureaucratic and tedious.

The single biggest thing would be to streamline and simplify developer processes. Get rid of duplicate ticketing systems; try to remove manual steps. This includes all the steps from design, implementation, functional testing, performance testing, security testing, integration testing, and release. If each of these were simple and streamlined, a lot more work would get done, and the engineers can focus on being engineers! Allocate budget and resources to engineers to build great, easy-to-use internal tools! This might not be cheap at first, but will quickly pay for itself!

Minimize dependencies between teams (do I really need to wait for a DBA to write my SQL for me, or do I really need to make a ticket and wait for someone to click a button to deploy my code in staging, do I need to make a PR to some other team's code in order to leverage their platform in a "standard" way?). For every project, there are a bunch of blocks where waiting on someone is required.

Encourage and allocate budget for engineers to make their systems easy and streamlined for other teams to integrate with, rather than having error-prone and manual "onboarding" processes. For example, consider the case when team A builds something for teams X, Y, and Z. Having X, Y, and Z required to meet with A, then make a bunch of pull requests to A's repository, and follow a bunch of steps on a wiki, then create 5 Jira tickets to 3 different teams, then X, Y, Z have to schedule a release with A. This slows down all the teams and is error-prone. Instead, if A was careful with their contract to X, Y, Z and invested upfront on streamlined onboarding, with a product-centered approach, everyone would save time, stress, and make fewer mistakes!

Invest in great and fast tooling for everything that is done manually. The tooling today is slow and flaky.

Think carefully every time you add an extra step to something. Because over time, there end up being tons of steps, some of which are unknown (because it's poorly documented, or not documented at all, or hard to find the documentation).

Don't make people stay up late for normal scheduled work like releases or collaboration (people will do it, but they silently hate it!).

Empower your engineers and increase autonomy. Visa tells their employees, "everyone is a leader," however, in reality, engineers are not empowered to lead because of all the approvals they need to do to get something done.