An organization's appetite for failure is the one true measure of innovation.
NVIDIA, Microsoft, OpenAI, Tesla have all run huge bills on failed starts. Compare that to other large companies that appear to be scared to fail - Intel, Apple, Google, Ford. A culture where innovation is projected as an important 'goal' eventually starts treating innovation as a thing to be measured, tracked, reported. Bundled with other measures, trackers and reports, a failed innovation attempt sticks out and makes the management chain look bad. Naturally attempts to try any radically new approach are discouraged - 'what if we fail?'. Updates transmitted up the chain are watered down or reworded to create an appearance of progress or success. This creates a spiral of imposed positivity which slowly drains the spontaneous energy that generates true innovative solutions.
jul'24
Measuring Success
Does your leaderboard measure effort or outcomes?
The start of any new initiative or project is marked by optimism and the energy to show quick results. Naturally reports designed to check 'are we making progress' focus on individual, mini-tasks. These could be backlog development, feature designs, wireframes, workflows to be automated, environments being built. None of these are outcomes. These are steps that should lead to outcomes in an ideal world. Just a few weeks in, reports find roots in the weekly routine, especially in organizations that depend on people for reporting. People form habits. They also develop lethargy towards change.
A report that is very relevant during 'take-off' is misleading when it is time to check progress and direction.
Ideally leaderboards, dashboards, recurring reports should be taken back to the drawing board when they look similar across weeks. They should be refactored to talk about how close we are to a goal, instead of how much work was done. People avoid doing this. There is a satiated feel to seeing reports that say - all ok, nothing to see here. This is easy to do when the report structure expects progress updates. This mechanism does not help the leader catch what is not being said. It does not talk about if we are where we should be. Nor if there are inefficiencies building in the workflow.
jul'24
Methodologies Age
The age of new methodologies, practices, collaboration frameworks in tech is coming to an end.
These were crutches to help overcome weaknesses in us, humans. Can't deal with complexity? Break it down and iterate with Agile/Scrum/Kanban/PMP. Panic and confusion in production? Let's put some structure with ITIL/COBIT/SRE. We have petabytes of material, centuries of recorded trainings and whole careers built studying and exercising these prescriptive practices. They were all developed with a few common assumption.
Assumption #1 : Building and maintaining large software products and services will continue to be complex, difficult and time consuming.
Assumption #2 : Bigger, more complex projects will need more people.
Assumption #3 : Only people have the depth, perception and imagination to bring structure to chaos and herd a large mass of other people.
Each of these assumptions is wrong today. You can potentially build better software products faster with fewer people and fewer interruption by framework champions. GPTs are helping structure thought and organize work. Coding agents are helping build software at the speed of thought (shoutout to Cursor). Once the cost and security of AI reach maturity, we should see more advanced tools managing the complexity, data density, integration and people collaboration across large software projects.
The basic tenets of these methodologies and frameworks will continue to be relevant, but the arc will lean towards using common sense and great tools rather than depending on strict adherence to pre-defined workflows and processes.
2030 software development will still be human driven, but there will likely be less need for dedicated, certified framework champions herding developers and support engineers.