in
Forums
I am a technical leader, and not a people manager. :-) I have grown from leading a team of 10 people to leading three (and a half) separate teams that are >30 people. I previously had established a cadence of PM O3's (Project Manager O3's) with the 10-person team. I now have a problem of doing O3's with multiple teams.
Do I "cut off" the junior members of my old team and just leave one-on-one's with the leaders to get to a more reasonable number? Do I keep the current O3's going with my "old" team and then only schedule O3's with the senior leaders of the new teams?
How's that conversation go? I feel like I've painted myself into a corner, but - surely there's some folks out there that have experienced this!
What's happening in that "leadership"?
Are you like a software architect, in a role where you have final technical say, and the 30+ folks are designing and implementing within that oversight? Are you coaching them to improve their design skills, because you're the most experienced and creative "heavy" locally? Are you tasked with guiding them to meet designated standards? Or are you truly a project-manager with 4 sets of projects to ride herd on?
I guess I'd reach for Drucker's executive questions -- particularly "What does the organization need?". Maybe it prompts you to train four replacements (one per team) and shift to having no O3's at all within six months! Your boss might have some insights or observations to toss into the mix.
Bingo! I'm a software
Bingo! I'm a software architect, yes. :-) My tasks, however, are not people-driven. If I ask my leadership and my peers who are managers, some might say "I need your help to develop person X," but that would be well after "go fight this fire," or "help the customer," or the litany of other deliverables that make up and surround "the application" overall in this context. What I'm a bit flummoxed by is that now I have four different applications to oversee, and obviously know one quite well (I helped to build the bloody thing!) and only "know of" the others.
If I read between the lines on that, however, you're absolutely right. My job is to set a standard, hold people to it, and help them to improve. I'm absolutely not supposed to be a project manager. We have two separate jobs for that that expressly not mine.
Interesting - I've got Drucker's Effective Executive next to me now, but hadn't cracked it open. I'll go have a read now, shall I? ;-)
Some thoughts from various organizations I've been through
Several organizations I've lived through separated out "make sure technical things get done" from "make sure things get done", and even "get technical things done" and "get things done", into distinct roles (usually separate people). Oftentimes, it was one "cat herder" per product, with each getting a time-slice of some "techie herder", who helped arrange others to get technical things done.
As one of the "techie herders", I just made sure communications were happening, all the various irons in the fire were getting proper heat per current priority, demos and deliveries occurred, and occasionally pairing with one of the junior developers or testers so they could skill up to better serve and deliver. Other times, I melded "herder" duties with actual delivery / support / architecture, and sometimes formal coaching into the bargain. When I had multiple hats, though, I made clear what hat I was wearing at any given time, even down to scheduling in my calendar and splitting meetings to keep the distinction clear.
Consider determining what roles need filling, then start putting time-slices of people to fill them. Perhaps you'll end up with one overall cat-herder, one technical coach, and four architects (one per team) -- and you're filling the first two roles and one architect role. Slot in three others, so your workload "goes down" from meeting four teams and thirty people very frequently, to meeting one product team ("architect" hat) and one architect team ("cat-herder" hat?) very frequently, and each of those thirty people infrequently ("technical coach" hat).