Hi everyone,
I’m looking for advice and knowledge-sharing about organizing one-on-ones in a department where project teams are constantly changing and people frequently move between them.
I have a team of 70 people at one of the sites. There is a manager at the top of the department, and test leads and testers are assigned to projects based on need. Test leads report to the test manager.
Because of the nature of our work (software testing), we don’t have permanent teams. Testers and leads are assigned to a project for a limited duration - ranging from one week to several months. Once a project ends, testers and leads are typically reassigned to different projects.
Since one-on-ones are intended to develop relationships, I’m concerned that organizing them based on project assignments might be counterproductive given the frequent team changes. I’m considering introducing “hard” reporting lines between leads and testers, so that each lead is always responsible for conducting one-on-ones with the same group of testers - even though testers will often work on different projects with different leads.
I’d really appreciate it if anyone with experience running one-on-ones in a similar environment could share their insights on how they handle it, along with any pros and cons they’ve observed. Thank you.
Do project-OOO as well as manager-OOO
Search up "project manager one on ones" in the "Map of the Universe" -- listen to the podcasts in late May 2009, for instance. This lets trust build within project teams, as well as making sure the line-manager responsible for end-of-year reviews has sound fodder for good reviews of their directs.
Be aware that setting up "hard" reporting lines will encourage the accretion of teams around specific leads and (especially senior) testers. If your org wants each project to start with a boost of project team cohesion, this is one viable strategy. You then will have to somehow oversee these relationships, with relevant authority in place to break up bad groupings, ensure juniors get mixed-in to learn while contributing, and otherwise cope with this extra visibility into what's already happening informally.
I served on contract into several software development organizations whose effectiveness relied on close interactions among developers, testers, product owners, and supporting experts (mostly in "Agile" style). No leads per se, but plenty of senior folks and wide-band communication and leadership bubbling up where needed as needed, within relatively stable rosters of teams. (Search up "professional updates" and "peer one on ones" for related ideas.)
Some of those organizations had "guilds" to deepen specific roles (eg tester, developer, product owner) where very senior technical folks mentored juniors, taking technical-skill-growth off the people-managers' hands. Throughout, everyone had long-term stable reporting to some specific people-manager. One org had everyone form role-specific "pools", held together by a tree of people-managers, whose individual contributors got assigned out, often as pairs or sub-teams. Another had leads carry their own teams with them, so the unit of assignment was the team not the individual. (Just like the military's wisdom of keeping platoons together instead of continual scatter/gather.)
If this is a single-role department (70 which are only testers, leads, and their managers), I've seen several reporting structures work. [Spitballed numbers ahead, fair warning.] Do you treat your "leads" as individual contributors -- only technical responsibilities? 2 people-managers handle 15 leads, 6-7 people-managers serve a pool of 45 testers, and those report to the department head. Do some "leads" take on some people-management such as OOO? Each such lead keeps 2-3 testers to move jointly as a squad, reinforced when needed from the pool. Maybe one of those squads serves a test-tools and -architecture function; others, extra functions like onboarding new hires, or interviewing, or exploring technologies and techniques, or preserving knowledge of vital legacy systems.
Thank you
Jrb3, thank you so much for your time to provide your insightful comment. That's great food for thought for me. I might try different approaches at different sites to see what could work best in our setup.