Taro Logo

Good place to start right out of college, but rampant incompetence

Software Engineer
Former Employee
Worked at Fidelity Investments for 4 years
June 19, 2020
Durham, North Carolina
2.0
Doesn't RecommendNeutral OutlookApproves of CEO
Pros
  • There is a big focus and investment on education and training employees.
  • There is a strong focus on diversity and Employee Resource Groups.
  • Colleagues are friendly, and managers treat their employees with respect and kindness.
  • The company has a new talent pipeline in its internship program and a great bootcamp program for new hires. The company's best employees come from this program.
  • Embrace of Agile Scrum and Kanban.
  • Upper technical management is staffed by good, eager, and talented people that want to change things for the better.
  • If you are a go-getter, there is much opportunity to make it up the ranks.
Cons
  • Low technical talent: The company uses about 45% contractor workforce (even in the US).

A lot of technical knowledge leaves the company every year.

Huge turnover rate in the technical ranks.

Many of these contractors have low skills that do not match their resume.

  • While it is good the company gives people low on experience a chance (sometimes the first chance of their career), the flip-side is that there are a lot of people that don't know what they are doing.

Huge brain drain in the early 2000s at this company that the company never fully recovered from (many firms in the same industry experienced the same).

  • Very incompetent teammates. "Very" with a capital "V".

You have to constantly get on people just to get the work done that they promised to do.

Sometimes it takes weeks to find an administrator to grant access or turn a setting on.

Sometimes requirements are completely misunderstood.

  • Agile scrum meetings go on for too long. Oftentimes, over half a day is spent in meetings.

The prevailing attitude at the company is that strictly adhering to Agile ceremonies will magically get the Sprint work done.

  • Non-technical people are scrum masters (SMs): Although it is technically not a requirement, it is a bit of an obstacle to have non-technical people as SMs for Software Engineering work.

Despite my 17 years of experience as a Software Engineer, I often found myself being contradicted by SMs with less than 5 years experience, and zero years as a Software Developer.

Sadly, most (but not all) SMs have very little interest in understanding the work they were SMing for.

  • You ask a question, and people are either too busy to answer, or nobody knows the answer.

Either way, you are basically on your own to figure things out.

Advice to Management

I think technical management is on its way to fixing things. The only advice I can give is:

  • Lower the percentage of the contingent (contractor) workforce. High turnover will never allow you to make strides on the technical side and execute long-term plans. 40% contractors is an astronomically high amount compared to companies in the tech sector (more like 5%). This company views itself as a "tech company in finance". Start by getting rid of the dead weight (and there is a lot of it), convert the good contractors to full-time, and start hiring direct hires.
  • Stop being so strict on Agile ceremonies. Modify them to allow people to have more time to do Sprint work. Agile ceremonies don't get Sprint work done; people do!
  • Reduce the amount of meetings. No Software Engineer should be spending over 50% of their time in meetings.
  • Have technical SMs: One of the things that I found really discouraging was how most SMs have little to no technical aptitude. While the Agile Handbook doesn't require it, technical SMs are what most top Tech firms have. Imagine having a say in priorities if you don't understand what your teammates are working on.
  • Onboarding: More focus should be put on getting a new hire productive in the first week. An onboarding "buddy" should be assigned that actually has time to get you productive; it should be their top priority. Setup instructions specific to each area should be documented and tested out. All of the required access for a new developer in the area should be figured out and granted from day one. Otherwise, it takes over a month to get productive.

Was this helpful?

Fidelity Investments Interview Experiences