Once upon a time, I was a software engineer. Then someone said, “Spencer, you’re a very good software engineer. You grok our vision, you produce well designed code that aspires to and can grow into as well as beyond our vision, and you have a knack for working with the other engineers (though your relationship with your managers could improve). How would you feel about leading design and development efforts for our team?”
And I said, “Aw shucks,” and so my downwards spiral into management began.
At first all was well. I had a 3 man sub-team and my co-lead had a 4 man sub-team. My sub-team was kicking butt and taking names. I was doing mostly design, code reviews, and mentoring. I could have done with some more coding work – but I always manage to sneak in some significant chunks in under design work. But we were mostly hitting our milestones, and I saw no reason to fear. If worse came to worse, I could step in on a weekend and get us back on schedule – but I wanted these guys to do it largely by themselves. Good for morale and growth all the way around.
And then it was deemed that my co-lead, who also had a high-level architect hat, needed to wear only one hat, and so he passed his software lead hat to me. And so it came to pass that I was the one software lead to rule them all.
It’s at this point that my downwards spiral into management hell began.
I knew I had to schedule a lot of meetings to figure out where my co-lead was leaving off, where I was picking up, and where the progress of his sub-team was really at. And all the sunshine and happy flowers that I had been hearing about started to wilt and die before my eyes.
I basically picked up 2 very needy non-engineers, realized that my co-lead really wasn’t on top of requirements, design, or implementation progress, and that we needed to cut a bunch of features and rework the other half. Oh, and make sure the entire thing was REALLY being tested.
As petals wilted and flowers died, I flowed the needed scheduling information up the management chain. This, of course, caused new meetings which caused new meetings which caused new meetings which … well, you get the idea. Forget engineering (outside of dealing with my 2 very needy non-engineers). I’m just doing scheduling, tasking, and status … with a good dose of requirements analysis, requirements rejection, and a bit of upper-management scolding (most people think I’m insane because I’ll scold my management – I tell them what it is they have done, should have done, and should be doing – and why I shouldn’t be doing any of it … but the way I see it, if I get fired (and no one is ever really fired), it’s probably because things got to a point where I really am better off leaving anyways).
Ok, ok … it’s not all bad. Really, I’m enjoying it mostly. I just want to get back to the engineering side of things. But I have to fight, for the success of this project, this titanic management battle to get all that is screwed up with our engineering process and management turned around.
It seems that since I’m the only one who doesn’t mind expressing a very solid, actionable opinion, I get delegated with all the managerial crap that everyone else should be doing. What features do we need for our next release (you should be asking the architect)? What support do those features need (again, the architect)? Are we sure we’ve done a top to bottom analysis (I don’t mind helping out, but does the architect have an initial blueprint)? Do we have a tasking breakdown (if we have a top to bottom analysis, then yes)? Do we have initial tasking assignments (sure, I can do that)? Do we have estimate sizes per task and engineer (I can do that too)? Hoooooo crap, why am I doing this?! My part should be small, but I feel like I’m doing it all. I feel like I should be providing data, not doing the friggin’ work. (But the work is that data, they say, so either we’re data entry peons or you do all of it – managers don’t like being peons – and you’re the only one who really knows the data top to bottom)
Anyhow … this is a very long post to say: Sorry I’ve not been around much. Hope things change soon, but I’d expect radio silence to linger on for a while yet. If you want to mail me beer or wine (or money for either), I’ll appreciate it.
Last night, I was in the office messing around while Josh was getting ready for bed. I saw that Lisa had a book by Flannery O’Connor, so I picked it up and start reading. It was a collection of short stories.
A few minutes later, Josh comes in yammering about something, and I absently tell him to get continue getting ready for bed. So he leaves but returns 5 seconds later, but in those 5 seconds something in the book has caught my attention.
He snuggles up behind me, still talking, but I’m still reading through the paragraph … no time to bother with him yet. Then I realize he’s saying … something … something … familiar and yet nonsensical.
“What are you saying, Josh?”
“I’m trying to reeeeeeeaaaaaaad.”
“You’re what?”
“Trying to read!”
“What are you talking about? What are you reading?”
“A .. good .. maaaane .. is hared .. to fend”
“What? Point to what you’re reading.”
Josh points to the top of the page where the title of the short story is: “A Good Man Is Hard To Find”
Awesome!!! Josh is reading! So we work through the proper phonetics, he gets all spun up, and then off to show off to momma!
After that, instead of me reading to him for bedtime, I help him read to me. It’s pretty awesome.
So … one of the big jokes amongst the developers is my constant scheming to “pull one over” on management. Generally there is something that we know they (irrationally) will not want but is in the best interest of pretty much everyone else. Every now and then, I also host a game of “dream team org chart”.
Today, though, I think I hit a real resonating chord with the senior developer. He’s da’ man on the project. I’m pretty good at getting a vision of what ought to be done and how it will look – certainly better than your average bear. He’s significantly better. In fact, one of the best I have ever worked with – and I’ve worked with a number of crazy smart people. Everyone looks to his expertise, and when he isn’t brought in, quality suffers.
Today, I pitched a covert coup to the senior developer. The main thrust is that since we have the best handle on the development efforts in progress and have the most to say about design and implementation, we need to be overseeing the design process before it gets handed off to the developers. Thing is, there is already suppose to be a structure for all of this as part of the existing systems engineering team.
So, the coup is simple – we are put in charge of developers, and we manage the work that developers do. As part of that (and this is where the coup is manifest), we facilitate the process of system design becoming software design, which is where we are perhaps the strongest of anyone else on the team. This amounts to a coup because the senior developer and I almost always view the system design we’re presented with as a very rough draft that needs a lot of refinement – and in the end, we have something that kinda resembles but mostly doesn’t look like the original design.
The present justification we can use is that, really, the systems engineering team is presently too busy to address the needs and concerns of the developers … and we get bugged by all the developers when systems engineering is not available (i.e. all the time). There’s also the added benefit that the system architect doesn’t need to be a language weenie – he can focus on being a systems engineer, which is what he really only has time for it seems.
Right, so how is this covert. We’re making this covert in that we’re going to try to make this the system architect’s idea. This is the tricky part, but … it’s doable. The system architect already knows he’s overworked and too spread out. He freely admits to this. So, the plan is to bring up his workload, try to get him to express his frustrations (which he rightly has), and then do the whole “so what I think I hear you saying is …” and voila. It’ll take some time for it to ferment and mature for him, but it is so logical and “duh” that I don’t think it’ll take long for him to get on board. And if/when he comes on board … score!
This will free us to really optimally design our software and keep the engineers engaged and busy as appropriate. It lets us manage people we’re already managing more or less. And it lets us decide to take some risks within reason of our areas of responsibility to get things done.
All in all, I’m really pumped about this. I just need to make sure senior engineer is with me to follow through on it.
So, in between being heard by upper management and being offered a promotion … I forgot my immediate situation: my current management sucks.
Today, I had a urinary joust with my project lead. Loads of fun. I have a hard time being told to do something I don’t want to do … and I have a tendency to throw it back: “You want it so bad, do it yourself. In my judgement, it’s unneeded.”
Then I had a rant fest with #2 on my project. I leveled with him – I don’t know what he does, I’ve expressed interest in knowing, I feel like I have a right to know, and in the absence of knowing, I’m left to assume that it’s zero value added because I never see any product coming from the management team to help us do our job.
He didn’t like that. He was fine when I said they should be doing more by way of leadership; he was not fine when I said I had a right to know what they did.
After all of this, I found myself wondering … why did I stay?! Oh yeah, I have a get out of jail free card. I think I had better play it sooner than later.