Available Now Fear has quietly and insidiously woven its way throughout the very fabric of how we do business in Technology. Our goals are driven by failure, rather than success.
Design Thinking is a powerful adjustment in how you approach change, helping you address this fear, and enabling you to be more effective in your Technology career whether you are CTO, CIO, Architect, Project Manager, Engineer, Developer, or you hold any other role.
- How fear effects the human side of technical people
- The Principles of Design Thinking
- How to use Design Thinking in technical leadership and planning
- How to use Design Thinking to effectively make change
- Identifying and ending toxic behavior
Activator is a must read for anyone strategically planning with any level of complexity. Simply written and powerfully driven home. Brandon takes us down an interesting and thoughtful road that leads to great results.
-Alan Rencher, CIO
A thoughtful explanation for building tech software or infrastructure, with valuable strategies for the people factor.
-Seth Law, CSO, nVisium
Brandon has a breadth of experience, through his career including CTO, CIO, Director of Operations, Architect, Engineer and Developer across the public, private, and nonprofit sectors. These experiences have given him a unique insight into the behaviors we so often exhibit.
From the blog at Surfing The Cloud
Rapid Technology Innovation
The high rate of change sets the technology industry apart from all others. What is new today is old hat in a matter of years. This is true with consumer devices, as well as the expensive enterprise systems that drive the backbone of the world’s computing systems. Multi-million dollar investments are made each year, with an expected lifespan of three to five years. How different would things be if we did the same with our houses—expecting to get the full value within a few years, after which we tore it to the ground and found a replacement.
I know of no other industry where a major investment is discarded and replaced so quickly. We tolerate this because the needs being met by the new technology are so valuable that they become critical to our plans, sometimes before they are even implemented. The technology that makes it into common use, however fractional, is often already obsolete, sometimes at just the point when we finally understand how to use it best. With such short life cycles, this dilemma has become perpetual.
Should we discard a partial investment and go to something new, or continue to hack away at something we know is already halfway into its grave?
A great example of this is server automation and the emerging world of containers. The industry just came to grips with how to automate and manage servers—or to use a car analogy: a robotic repair shop, making it easier and cheaper to do maintenance and updates. But just as this technology is coming into its own, along come containers. These are encapsulated vehicles that can be created easily, with little effort, and since they are so easy to create, there is no reason to maintain them—simply discard when finished. Suddenly, the investment in server automation seems wasted. People who spent years learning the inner workings of these automation frameworks (Puppet, Salt, Ansible, Chef, etc.) are now trying to figure out how to leverage these frameworks in containers—when the simple answer is don't! The world has changed, at just the point when it seemed to stabilize.
This rate of change creates an atmosphere of severe anxiety for anyone willing to admit it: How is it possible to understand the new technology, when it grows in complexity with every iteration, and each new release means everything we used to know is rendered useless? Because of this, it has become acceptable to ignore the big picture in order to cope with the immediate challenge. We just pick smaller pieces that make sense to us, and we focus on those fractions, while telling ourselves we are helping our customer. ⤧ Previous post The Devops Startup