I know it's way above my pay grade but this treatise on teams provides the bottom up view of how Fidelity Teams can be organized. In an ironic power/knowledge asymmetry, I, a low low developer on the front line who has no voice, posses the knowledge that the higher-ups would never know. For example, when it comes to which middle managers to cut, I know exactly who's coasting, who's contributing, who's busy kissing the as--s and who's envisioning... A "who in your report chain you would cut?" secret ballot offered to the frontline associates would work if the anonynimity is guranteed and the trust of the upper management is there.
So I can't be specific, instead I provide general principles here which the higher-ups may consider in the up-coming squad to team mass restructing. Please chime in as your feedback will be incorporated and the whole thing will be provided as my comments for the next Pulse Survey. For our voices to be heard, Please be thoughful and constructive and refain from whining or hate.
(1) Team Nature
Fidelity (actually any enterprise) teams can be categorized along two dimensions:
- What does the team offer (product vs service). Product teams build (dev), service teams operate (ops).
- The context in which the team functions (general purpose vs domain specific). Data extraction load and transformation (ETL) is general purpose, automatic understanding of scanned PDFs is domain specific. Phone reps in the call center is general purpose, relationship management with institutional clients is domain specific...
Some example teams in each of the four resulting quadrants are provided below:
- General purpose product team. The team which builds FidCentral or MyAccess. The team which builds the Snowflake data uploading tool...
- Domain specific product team. The team which builds automated tools to deploy AI Models. The team which builds automatic tools to extract information out of scanned user submitted PDF documents...
- General purpose service team. Phone reps who answer generic customer questions. Vendor database administrators.
- Domain specific service team. The team who provisions load balanced top level URL with vendor products such as AVI or F5. The team who manages digital certificates lifecycle with vendor product such as Venafi(?).
(2) Team Leadership
- Product Team leaders must be technical with engineering qualification and experiences. This in essence is the "engineering driven culture" in Meta and google. MBA's and humanitiy majors with only project management experiences aren't qualified (this is why AWS su-ks innovation and culture-wise).
- Domain Specific Product Team leaders must further posses the domain specific qualifications and experiences.
- Service Team leaders can be less technical and more manegerial, such as MBA's and project managers. In many areas, these managerial kind of leaders are needed more than technical ones.
(3) Team Compensation
- Product team should be compensated more than service team
- Domain specific teams should be compensated more than general purpose teams
(4) Team Assessement
- All teams must be assessed with clearly defined metrics. Both service and product have industry standard metrics: Daily Active Users (DAU), Monthly Active Users (MAU), Net Promotion Scores (NPC)...
- Apply process improvement methodology such as Six Sigma's DMAIC to improve service team metrics
(5) Team Diversity
While MAGA's h1b hate can be extreme, Fidelity Tech's widespread 100% single identity teams are inexcuseably extreme. It's only fair to recall "diversity" in current anti-DEI environment to counteract the extreme over-representation:
- No single enthinity represents more than 75% of any (tech) team.
What do I missed? What do I get it wrong? Thanks.