Planning a Covert Coup
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.