Our current org structures inhibit how we develop software, and therefore how we deliver on business capabilities. Changing the org structure to feature teams, that are self-sufficient, multidisciplinary and cross-functional will lead to better business results.
I couldn’t sleep last night, as I tried to understand why other people just couldn’t get it when I say "Lets just get it done". I keep on hearing things like:
- We need to have a proper architecture
- Do you have capacity requirements for the next x years
- Whats the full plan?
I love this excerpt from Singularity regarding Blitzscaling:
Speed and uncertainty are the new stability.
The goofy but appealing coinage “Blitzscaling” refers to an organizational management strategy in which one places growth above nearly other objective. Uncertainty is embraced, a certain amount of mess and waste are tolerated, with the goal of growing larger and larger as quickly as possible. “Large” here means both large in terms of team size and large in terms of number of customers served.
Blitzscaling is how we got the tech titans now dominating the AI field: Google, Amazon, Facebook, Microsoft, Tencent, Alibaba, Baidu. It is also the only plausible way a tiny little upstart like SingularityNET is going to divert the focus of the planetary AI ecosystem away from these big tech companies toward a decentralized, participatory ecosystem.
“Speed and uncertainty are the new stability” doesn’t mean one makes huge strategic decisions thoughtlessly and heedlessly. But it means one needs to evaluate the situation incisively and quickly, and then clearheadedly and rationally make the best choice one can, and act on it decisively in spite of the large amount of remaining uncertainty. This does not provide any sort of guarantee of success. But in the modern business, social and economic climate, it provides the highest odds of massive success.
What specifically kept me up last night was a 6 week development project. I found a development house to build an MVP, consisting of a few APIs and microservices. But I kept on getting held up by procurement, as they are now on week 3 of them reviewing the contract. 3 weeks to review an engagement for 6 weeks. It seems every department is far too keen to make their mark, to add their little value, that they don't look at the bigger picture.
Each role player sees themselves as a gate. That every requirement must gain their approval, and on their own times. Just cogs in wheel, spinning along, with no concern for what the end-game is. They care more about the process, than the outcome.
The corporate circus - everybody looks very busy, but hardly any work gets done.
I see architects trying to come up with complicated architectures, infrastructure peeps want to understand every element and its capacity - all in the name of making sure that you understand what 'value' they bring to the table. Nobody cares about just getting something done - putting it out there, seeing how it goes, and modifying it as you go along.
In the last few weeks, as we trying to onboard a new platform and way of working that finally will deliver us into the Digital Age, we have been held up by:
- Legal - taking weeks to review a contract. They are utterly unfamiliar with anything cloud-based. They cant understand why we cant have a custom contract just for us
- Regulatory - again, the concept of cloud is utterly foreign. They asking why Google and Amazon cant have data centers in our own geographies. They want to see the server that our data lives on:
- Finance/Accounting: "If we cant prove what physical server our cloud server is provisioned on, then its OPEX." They cannot fathom paying CAPEX for anything we dont physically own.
Time to Value (TtV) is the time between a business request and the initial delivery of that request. The goal of any business is the minimize TtV in order to realize some level of business value as quickly as possible. There is a direct correlation between IT agility and fast TtV because a business can do very little nowadays without considering and including their IT systems.
The above graphic is an example of shortening the Time to Value by having small functionality from the start, and then building on it. As opposed to doing architecture and planning, and then implementing 15 months later. I've drank the Agile cool-aid, about delivering potentially working software every sprint, and I love it. Which also says that progress is not measured on documents, or architectures, but working code only.
Check out this infographic, which I have a snipper of below:
What really gets me, is that people don't count the value of their own time. They will happing spend lots of time (like the legal guys taking 3 weeks to review a 6 week contract), but they don't count the cost of their time - if they earn $x per month, then if they spend 3 weeks on it, they have actually spent a fortune of the companies money on something that is far less than than value of the thing they discussing. Add in senior managers and Execs into these escalation meetings, and it becomes so obviously expensive.