Minimize the distance from idea to executionFri 02 November 2018
My company is getting more and more 'political'. If you wanted to do something new, you used to have to spend weeks getting the proper permissions / sign offs from the relevant leadership, ensure they were bought in to the vision of your project, talk to the resourcing team to make sure you had the critical materials and personnel, talk to legal to ensure they wouldn't block you later, etc.
Nowadays that process takes months. Based on conversations with friends at larger companies, the process is even longer there. That's not necessarily a bad thing - by forcing so much consensus the company tends to build things in line with the existing business objectives. And because those business objectives fluctuate rapidly (at least from an executive's perspective) the company size usually scales with how "top-down" the decision making becomes.
What's been interesting is observing how the increase in delay has changed the ability of the team on the ground to be effective. The more the organization tries to influence a team, the slower it seems to go. Why is that? What actually takes up their time?
My argument would be that a lot gets lost in translation. That is, when the project lead describes what is being worked on to leadership, the leaders don't actually have a tangible understanding of what's happening. But they think they do. And so rather than one unified perspective on what the product should look like, there are several competing perspectives. The project lead him or herself can't distinguish between which vision is right, and so he / she ends up building a melded version of several visions at once.
In most cases, I would argue that the project lead would be better off ignoring the leadership (politely) and just building the v0 or a set of mocks that accurately represents the current plan. When developing a product it's hard to describe what the thing should do and much easier to just show what it does.
One example came up in work a couple weeks ago. I had described a mechanism to accomplish something that everyone wanted done, but my descriptions were not specific enough for the team leads to understand what I was saying to a degree they could act on it. When I finally made a simple example and sent it to them, I could almost hear the "oh, this is what you meant!" go off in their heads. And weeks of back and forth ended almost immediately.
There's another aspect to this which I want to explore more. It's almost as if a promising idea is a pure, concentrated thing at first. It's exciting to go after, one is confident it'll be successful, its scope is small, etc. As more people contribute to the idea to feels like it gets diluted somehow. Not that the contributions are bad, per se, but by adding on so many appendages it becomes this huge monster that's much harder to execute on. In that sense, doubling the functionality (before the initial version exists) usually quadruples the amount of development time. That would explain what happens when the functionality demands continue to rise - velocity of the engineering team asymptotically approaches zero.
The idea that good contributions to a project idea could end up killing it is a counterintuitive one. It reminds me of Warren Buffett's way of prioritizing tasks...
"Write down a list of your top 25 priorities in the next year in order of most important to least important. Circle the first 5. The other 20 now become your avoid at all costs list."