RE: Perils of a Software Team

If it's any comfort -- you were absolutely screwed over. But it sounds like the deep digging started long before this last week, when nobody was put in charge of actually determining requirements for the architecture in the first place. And over the last eight months, no one higher than you on the totem pole seems to have decided what the actual purpose of the programming effort was intended to deliver, which is the whole point of doing the work in the first place.

Let me repeat that, because a lot of people miss that (but you don't seem to have): The reason that we do work is to accomplish an end, to achieve a goal, and not just to keep a bunch of dudes busy while you give them money. And the time to do that is before you start giving direction to those guys who have to start digging the ditches.

Now any of us can find ourselves in this position plan higher leadership has failed its job and left us holding the bag. And it sucks. Your responsibility as a leader of that group is to step up and challenge the guy who is holding the authority and title of Team Leader but is not doing the leadership of a team leader.

You have to advocate for the guys marching behind you. Sometimes that means biting the bullet and just saying, "that's not going to work, and here's why." And if they are adamant about pursuing that particular path, sometimes you just have to walk away, which sucks for an entire multitude of reasons.

"What the Hell do you mean 'research'?" is probably a phrase that should've come out of your mouth a little earlier. It's all part and parcel of that advocacy. If I'm understanding you correctly, this team was constituted to actually implement testable hardware interfaces, and the application layer had to follow suit on that. Rather than the application being solidified far enough for you to put together the hardware interfaces for it to hook up.

You've been testing over the summer. Are the hardware interfaces effectively complete as far as you're concerned? Are there hooks there for software to connect to to do the job? Do we even know enough about what the job is to make that determination? (If not, that's an even bigger, higher level problem.)

If the interfaces are effectively done, they need to dissolve the team and reconstitute them with a new, clear directive. If building the framework is the new goal, that needs to be communicated clearly and the team effectively reassembled from scratch in order to provide closure and continuity of experience.

It sounds to me like the whole software project has a bigger failing, with not enough ownership, not enough top-down direction, and not enough vision existing -- but that's something only you can find out. You're going to have to step around the current Project Lead and get in touch with people higher up in order to find out if the vision has just not been communicated or whether it doesn't exist.

The rest of the team can't really get their feet under them until that is clear to you and in turn to them.

That's just the way it is.