I was watching Star Trek a couple of weeks ago and I was thinking – wouldn’t it be cool if work was just like Star Trek.
Then I realised that work is actually a lot more like Star Trek than I thought it was, so let me explain:
The whole crew nearly die in every episode in Star Trek (we don’t nearly die each week, which is good). Since they are in a starship, the Star Trek crew’s survival almost always depends on their ability to work with technology. But I guess the show would be a little boring if everything worked as planned:
Captain: Yikes – that looks like a rare Lithiam based ameoba that eats starships, we need to warp out immediately
Pilot: No problem, the engines are working well within their design perimeters. We have escaped easily.
(end of episode)
We don’t see many episodes like this though, we see the ones where they are in real trouble.
Of course, since they are a great team, they never seem to get into trouble because of their own defects or technical debt. Instead they constantly run into problems that push their technology to places where no technology has gone before.
Again, we don’t get to see the episodes where other teams confront this problem.
Captain “yikes – we are doomed unless you can get us out of here or blow the bad monster up”.
Pilot/product owner: “I am trying captain but the system is not up to it. We can only go at warp 8 and the rare alien metabolism is sucking us back at warp 9.67”
Captain: “Engineers, can we get out of here at warp 10”
Engineer: “That is technically impossible”
Captain: “Oh come on – it looks pretty easy to me. You just go as fast as now but then a bit faster”.
Engineer: “Sorry captain, technically impossible. But we do have a new Facebook interface we can show you as we die”.
Captain: “Oh OK. I guess that’s it then”
(episode ends in chaos and mayhem as the crew get metabolised while trying to fix their Facebook interface before being eaten)
If you believe in Star Trek (some people do) then you must believe that a lot of crews die because they hit things that are technically impossible. But the Star Trek crew always seem to overcome the “technically impossible” problem.
Of course they are on TV and we live in the real world. But this iswhere I think our teams are a lot more like Star Trek that people realise. The product owner/sponsor asks for something hard so the team say it is “technically impossible”, after which:
- The team go off to work on other things while the evil monsters of deadlines and customer expectations slowly start to threaten the team; or
- A long discussion follows that takes up the whole episode (or sprint if you do Star Trek Scrum); or
- A passionate discussion follows, that involves some problems being put aside and others being tackled with the full creative force of the team.
What I have learned from Star Trek is that while they have room for improvement, their approach to technically impossible things is usually successful:
- The engineers always say something is technically impossible, but it turns out that:
- They can solve the problem some other way; or
- They need the crew to do something to buy enough time to make it possible, which means it was not technically impossible, just “something we don’t have time for yet”.
- The pilot does not just say to the captain “I am waiting on engineering” and the engineers do not just say “we are waiting on better requirements”. Instead they all get together and collaborate as if their lives depended on it. Every problem in Star Trek is a problem for the whole team.
- After they collaborate they usually find out that they can solve the problem, even if the original request was “technically impossible”. Somewhere near the end of the episode, the team say “we can’t do X, but we can do Y” or “If you can buy us this much time we can fix it” and then they all work together to survive in time for the ending credits.
- They always experience a lot of drama and stress before they fix the problem. This seems to work well when there is only one monster to fight per episode … the whole crew of 500 seem perfectly aligned to the goal of “not dying today”. Maybe though, their approach would not work so well if they have 2,3 or up to 10 monsters to fight every episode.
- Every third or fourth episode the team see the wreckage of another starship where the crew could not be innovative enough or spent too much time fixing their Facebook interfaces while the real monsters came and killed the crew.
So from now on, I think we can say “that is technically impossible” as much as we want in our projects. It can add a sense of drama and it is a cool sounding phrase. But the result is always the beginning of a longer conversation because whether or not the solution is feasible, the problem is still there.
So maybe a better approach is to
- Provide enough information to clarify whether:
- We don’t know how to solve the problem – in which case we need to guess how long it will take to understand it;
- We understand the problem but our technology will not allow us to solve it – in which case we need to estimate how long it will take us to research a solution;
- We just don’t want to do it right now – in which case we should say “I would rather not” rather than “that is technicall impossible”.
- Use this information to prioritise which things to work on, so everyone knows the biggest monster every episode (or sprint if you want to use Star Trek Scrum)
You might have a better format. But I think it would help if you search and replace your use of “technically Impossible” with this more mundane but potentially more useful approach:
- This is my understanding of the problem:
- I understand that you want to {something} so {something}. The problem we have though is that {something is wrong}. For example “I know you want to escape that monster or we will all die. The problem is that the engines won’t do warp 10”
- This is why it is wrong . “The engines are only designed to do warp 8 because of you budget cuts in engineering last year you wally”
- This is where it is wrong “the engines in the main ship can not do warp 10, so the while main ship is doomed”
- This is what we could do about it
- Option 1
- If we do {something}, it will take {a vague guess at the effort} and then
- When {event}: {The system} will {something} if {conditions}
- When {event}: the systen will NOT {Something} if {condition}
- Option 2 (etc)
- Option 1
- This is what I recommend. “Let’s use the life boats and ditch the ship” or “lets run the antimatter backwards so we can go at warp 11 for a day with a 20% chance of death”
- What we need to decide now is “Let me know what you think of my summary”
So I guess I think my team is as good as the one on Star Trek, and yours might be too. But even the crew on Star Trek could work a little better if they replaced “technically impossible” with the right information for a longer conversation.