3 ms·

I've worked at a few startups that have this problem too. Mostly because tech leadership came from a bank. I would never hire someone again if they have worked

I've worked at a few startups that have this problem too. Mostly because tech leadership came from a bank. I would never hire someone again if they have worked at a bank for more than a couple of years.

mk89 4y ago
That's a huge bias to bring in an interview. Sometimes you work on some cool project for a while, then it becomes boring, etc. Or sometimes you're stuck with that job because of lack of other local opportunities. Or whatever other reason.
- roflyear 4y ago
  I agree, big bias. I'm not totally being serious. But I have had really bad experiences with people working at banks.
mirntyfirty 4y ago
I think that working at a bank is fantastic so long as a person can internalize the good parts. The bank I was at had the best data practices of any company I’ve worked at by a mile. They wouldn’t hesitate to write huge checks to make sure that the hardware systems and teams supporting those systems were perfect. Software management was a bit procedural but the results were consistent and high quality.
mring33621 4y ago
I have worked at 2 really big banks and they have many very talented, well-rounded people. The friction is there to protect the firm. It's true, though, that upper leadership tends to be incompetent. Don't hire them. But finance tech VPs and ExecDirs are often highly skilled, smart people.
- xchaotic 4y ago
  A lot of the friction in the banks is for legal reasons - they HAVE to abide by certain protocols. If you treat that as an extra challenge rather than a hindrance it will be more rewarding.
  - thedougd 4y ago
    Yes and no. There are teams and people who protect their headcount and interests under the guise of compliance. But very often they're enforcing one interpretation or implementation of the law. And very often, they're audited as to whether they follow the process they designed and not the process itself. Navigating the regulatory landscape to introduce change is high skill and art that I've rarely seen but does exist.
raffraffraff 4y ago
I worked at a bank for 8 years, but I learned how to work around the red tape and get things done. I wasn't alone. We had a ridiculous project approval process for any work that would take more than X man hours. They'd shut you down because you didn't have have approval for the budget. Yes, even though they're paying you to sit at a desk, you have to get executive sponsorship for the budget to cover the wages that they're paying you anyway. But if you know your way around the incident / problem / change management processes and you know enough of the userbase, you can get 10 incident tickets created over a 1 week period, this gets picked up as a "major problem", you get pulled into the next problem review meeting and asked what can be done. You think about it, tell them you have a solution but it'll take a few weeks to build and test. And either you skip through change control because it's a production incident, or the problem management team do all the process for you.
- daveevad 4y ago
  > you can get 10 incident tickets created over a 1 week period, this gets picked up as a "major problem" This is an interesting perspective but perhaps crosses the line.
  - raffraffraff 4y ago
    Thing is, they were genuine "issues". The bank developed internal software following the waterfall model, with 6-12 months between major releases. Each release had to have a project with a budget. Each release had enormous cost (with individual line items like "$1m: system testing" on the bill). And there was a somewhat passed rollout, but it was pretty much big bang at the end of the dev/test cycle. After a release, there was a very short period of watchfulness where issues found in production would either be marked as "minor" (this will hold until the next release and the users be damned) or "major" and the entire system would be rolled back (for now). So every release had a bunch of awful bugs that drive users insane. They'd complain, of course, but the senior brass would just disperse "release notes" via fax to the branches and tell them how to work around issues. In other words "button it". So the users wouldn't create incident tickets. Fast forward a few weeks, you're bored because you're waiting for project approval, so you make use of the incident process to make some improvements. Perhaps it crosses a line. But I had some direct managers (lower rungs) who loved the idea. "Fuck it", they'd say, "the process is there, use it!" All that from taking the ITIL course seriously. If you're going to hack the system, understand it
reitanqild 4y ago
In Norway it seems you could have an exception for people who worked at Sparebank1, everyone I know who have worked there has been great to work with or listen to. (I never worked in a bank myself.)

mk89 4y ago

That's a huge bias to bring in an interview. Sometimes you work on some cool project for a while, then it becomes boring, etc. Or sometimes you're stuck with that job because of lack of other local opportunities. Or whatever other reason.

roflyear 4y ago
I agree, big bias. I'm not totally being serious. But I have had really bad experiences with people working at banks.

mirntyfirty 4y ago

I think that working at a bank is fantastic so long as a person can internalize the good parts. The bank I was at had the best data practices of any company I’ve worked at by a mile. They wouldn’t hesitate to write huge checks to make sure that the hardware systems and teams supporting those systems were perfect. Software management was a bit procedural but the results were consistent and high quality.

mring33621 4y ago

I have worked at 2 really big banks and they have many very talented, well-rounded people. The friction is there to protect the firm. It's true, though, that upper leadership tends to be incompetent. Don't hire them. But finance tech VPs and ExecDirs are often highly skilled, smart people.

xchaotic 4y ago
A lot of the friction in the banks is for legal reasons - they HAVE to abide by certain protocols. If you treat that as an extra challenge rather than a hindrance it will be more rewarding.
- thedougd 4y ago
  Yes and no. There are teams and people who protect their headcount and interests under the guise of compliance. But very often they're enforcing one interpretation or implementation of the law. And very often, they're audited as to whether they follow the process they designed and not the process itself. Navigating the regulatory landscape to introduce change is high skill and art that I've rarely seen but does exist.

raffraffraff 4y ago

I worked at a bank for 8 years, but I learned how to work around the red tape and get things done. I wasn't alone. We had a ridiculous project approval process for any work that would take more than X man hours. They'd shut you down because you didn't have have approval for the budget. Yes, even though they're paying you to sit at a desk, you have to get executive sponsorship for the budget to cover the wages that they're paying you anyway. But if you know your way around the incident / problem / change management processes and you know enough of the userbase, you can get 10 incident tickets created over a 1 week period, this gets picked up as a "major problem", you get pulled into the next problem review meeting and asked what can be done. You think about it, tell them you have a solution but it'll take a few weeks to build and test. And either you skip through change control because it's a production incident, or the problem management team do all the process for you.

daveevad 4y ago
> you can get 10 incident tickets created over a 1 week period, this gets picked up as a "major problem" This is an interesting perspective but perhaps crosses the line.
- raffraffraff 4y ago
  Thing is, they were genuine "issues". The bank developed internal software following the waterfall model, with 6-12 months between major releases. Each release had to have a project with a budget. Each release had enormous cost (with individual line items like "$1m: system testing" on the bill). And there was a somewhat passed rollout, but it was pretty much big bang at the end of the dev/test cycle. After a release, there was a very short period of watchfulness where issues found in production would either be marked as "minor" (this will hold until the next release and the users be damned) or "major" and the entire system would be rolled back (for now). So every release had a bunch of awful bugs that drive users insane. They'd complain, of course, but the senior brass would just disperse "release notes" via fax to the branches and tell them how to work around issues. In other words "button it". So the users wouldn't create incident tickets. Fast forward a few weeks, you're bored because you're waiting for project approval, so you make use of the incident process to make some improvements. Perhaps it crosses a line. But I had some direct managers (lower rungs) who loved the idea. "Fuck it", they'd say, "the process is there, use it!" All that from taking the ITIL course seriously. If you're going to hack the system, understand it

reitanqild 4y ago

In Norway it seems you could have an exception for people who worked at Sparebank1, everyone I know who have worked there has been great to work with or listen to. (I never worked in a bank myself.)