It doesn’t have to be the individual genius that drives innovation–community and location can do more to foster creativity and innovation.
While kicking off the IT Revolution’s Enterprise Technology Leadership Summit last month, Gene Kim introduced me to scenius, a word suggested by Brian Eno in 1996. Brian said, “Scenius stands for the intelligence and the intuition of a whole cultural scene. It is the communal form of the concept of the genius.”
It’s often something you don’t realize you have until it is gone. I encourage you to dig into the inspiration behind scenius.
A few other takeaways:
Lauren Woods delivered the opening keynote. One of her points was, “Changing altitude changes your perspective and helps you rise above the turbulence.” Yes! The ability to change perspective is a deeply undervalued quality experienced and intensely curious senior leaders can bring to an organization. Too many leaders (and organizations) believe that navigating into and through turbulence is why they are there. Nope- the best leaders know to go above and beyond.
I found myself nodding again when Michael Nygard flashed “Data - The Land that DevOps Forgot” on the screen. The challenges of escaping 24-hour-long batch cycles are sociotechnical, even when it is about data. Remember Nygard’s Change Management Basics:
- “Once you are tired of saying it, people are just starting to listen.”
- “Cost attribution feedback loop needed to help the same person understand cost+value.”
- “Don’t create a legacy world and a separate promised land” (I’m looking at you, Mode 1 and Mode 2)
- “Change happens in the whitespace of the organization.” Only expect change if you are creating sufficient slack in the system.
Next up…don’t let your finance model drive bad behavior (and thus outcomes). It should be a tattoo on my back–I am always down for geeking out on procurement and its impact on change. Elizabeth Ayer takes this to another level. 18F’s updated Derisking Guide is coming this month, and I encourage you to check it out. Until then, she asks us to keep in mind:
- “Many times, needs are more strategic than they (the buyers) think. A bias towards demanding certainty worsens this, resulting in contracts that stifle the ability to adapt over time.”
- “Buyers must contract so value is being delivered to customers, not just to the buyer…which drives structural problems.” If I’m buying consulting services to build and supply a product, the contract needs to include the point of view of the end customers of that product, not just the buyer who is having the product built.
Steve Smith gave an entertaining talk going into three ways you are screwing up Platform Engineering:
- Power Tools. Implementing core capabilities with heavy-weight tools (K8s, Istio, Kafka). Config and Integration complexity creep in
- Technology Anarchy. The platform enables autonomy but doesn’t offer technical alignment.
- Ticketing Hell. Your platform is an Ops Service Desk behind the scenes. Ticketing happens because teams (intentionally or unintentionally) silo themselves away. Please stop it.
I wasn’t expecting to get much new out of “The Science Behind Team Cognitive Load,” but Dr Laura Weis proved me very wrong. If you ever have a chance to see her present, do it. I now have a list of theories to dig into, such as the Capacity Theory of Attention, Attentional Control Theory, Cognitive Load Theory, and Information Theory. All the while considering her warning, “Information Overload is a form of pollution in our environment.”
Remember that guy who coined the term DevOps? Yup, that was Patrick Debois. He has been digging into all things AI. In “Every AI Engineer Deserves an AI Platform (team),” he reviewed the current state of AI platforms in the enterprise and some gotchas. I’m coming around to the idea that coding “agents” may become more mainstream in the enterprise sooner rather than later. Patrick offers some ironies to think about during this transition:
- “The developer’s role is changing, becoming more of a manager of code…more like an ops person.”
- “As agents complete more of the app, you will experience a gradual loss of situational awareness.”
- “There’s a big problem with never producing code. How do you learn enough to become a reviewer for the agent?”
- “Learning will take the time saved in producing. (For example, chaos days to learn how it fails and practice troubleshooting).”
I enjoyed catching up with friends and hearing what other folks are doing in the enterprise. While I had a nagging sense of “all of this has happened before, and all of this will happen again,” I remember the importance of us doing the hard work to move the plot forward. Or, as Lauren Woods put it, “Choose effective over doing it right.”