The silent devastation of ideas-people

“The reality is that there is nothing quite as useless in this world as an ‘ideas person’. Not only is it excruciating to deal with their egos and misplaced protectionism around their precious ideas, but the reality is simply that anyone can dream and do what they do.”

In the software industry you often come across so called ‘ideas-people’

Behold the unicorn ideas-person. Full of ideas and low on execution.

In the software industry you often come across so called ‘ideas-people’. You usually spot them talking loftily about some idea that they are ‘working’ on. They might even verbally insinuate how big their idea is, and how it is going to change everything. Typically they can flip lyrically between the hundreds (if not thousands) of ideas that they have had. When someone else in industry has had a success that vaguely resembles one of their previous ideas they will publicly lament the fact of how they had that idea years ago, blaming circumstance for not pursuing it. They can go for years carefully nurturing their previous big idea, waiting for life to align just right for them to finally nab that sucker.

The worst part is that their fanaticism around their ideas frequently gets mistaken for passion. Sometimes if the person has the gift of the gab some might be fooled into thinking that such a person is a visionary of sorts. They might get dumb investor money thrown at them. When they fail – which is most of the time – they typically blame external factors for it. The market may not have been ready for their product or the investor funds dried up just before the big breakthrough was made. If they are not technical their darn developers were either too slow, too expensive or too inexperienced. It is very rare that they will blame themselves or their godlike ideas for the (not their) failure. Admitting failure would erode the one thing they hold most dear, their ego.

The reality is that there is nothing quite as useless in this world as an ‘ideas person’. Not only is it excruciating to deal with their egos and misplaced protectionism around their precious ideas, but the reality is simply that anyone can dream and do what they do. Coming up with ideas is not some mystical perch that is reserved for an elite category of human beings that have had some rare grace bestowed upon them giving them raven like vision into the future. In fact if you disseminate most of the things ideas-people come up with you will soon realize that it is nothing more than imitated innovation with concepts simply being copied from other successes they so diligently study and follow.

True visionaries are dreamers but more importantly they are doers. Make no mistake dreaming is a big part of the package of a true visionary but you also have to be able to follow through and actually make it happen. Ideas without execution is absolutely meaningless and wastes everyone’s time. Execution is king.

The devastation that ideas-people wreak is especially magnified in the corporate environment where ideas-people can plow their trade with minimal risk to their livelihood and reputations. If half-baked ideas fail in corporate environments it is virtually impossible to attribute causation since there are simply too many moving parts that may have contributed to that failure. As such a non-execution ideas guru can almost always abscond their precious idea from being the true reason for failure.

In contrast – even though it is not perfect – the startup world does do a fairly good job of weeding out the doers from just the ideas people. Unlike the corporate environment execution is everything in startups. With all the fat taken out of the process there is simply no place to hide. If you cannot build something that is useful to humanity and that people want to use your dead. It is a brutal game that rewards the true visionaries that can actually follow through on their ideas and destroys the pretenders that actually just like the sound of their own voice.

The really tricky bit is that you actually want to encourage innovation and experimentation in corporate environments since this is the only way to evolve and grow. But the people typically tasked with coming up with these strategies and product ideas are usually a little bit light in credentials for following through on those ideas on their own accord.

Advertisements

The learned helplessness of corporate companies

“I don’t necessarily want to elaborate on all the details of the experiment but in a nutshell it pretty much involved electrocuting dogs in controlled experimental chambers where their only option was to take the shock.”

Learned helplessness in corporate companies

It is really hard not to become despondent in bureaucratic organizations

One of the strangest things that I have witnessed in many bureaucratic organizations is the phenomenon of learned helplessness.

In 1965 Martin Seligman and his colleagues were doing research on classic conditioning. I don’t necessarily want to elaborate on all the details of the experiment but in a nutshell it pretty much involved electrocuting dogs in controlled experimental chambers where their only option was to take the shock. The negative conditioning (zapping fluffy) when done enough induced a sort of learned helplessness in the dogs leading them to avoid seeking potential escape. Even when the configuration of the chamber was changed with an obvious exit in plain sight, the poor creatures still settled for the familiar negative reality of being shocked.

I believe that most corporate environments are like these chambers. There are simply too many people in what is more than likely a heavily regulated industry working in archaic ineffective ways with teams structured in Orwellian like configurations. In such a space if you put one foot wrong or deviate one iota from the ordained norm there is a generous amount of individuals that will stand in line to tell you how what you are trying to achieve is simply not possible and contrary to what is expected. These self-anointed guardians of all things process will then place as many obstacles in your way to prevent you from deviating from the learned norm.

The go-to argument most of the time is governance. The sad truth is that in these toxic environments the norm has become for people to use governance and regulation to build intricate systems of excuses whereby they can absolve themselves from ever having to take any accountability for real change or progress. This self-induced learned helplessness gets passed on from culture to culture, team to team until the vast majority of organization live in an eternal state of feeling hamstrung and dis-empowered, never venturing beyond the safety of their constant suffering.

To be fair most of these individuals have been smacked so many times by the same forces of self-induced learned helplessness in others that you can’t blame them for losing hope. It is really hard not to become despondent when facing the illogical reasoning of some of the hurdles that get placed in front of change agents.

There is however one even bigger evil that lurks in the shadows of learned helplessness. It comes in the form of the few that have learned how to exploit the learned helplessness for their own political benefit. The ones that dramatize and use the hyped up implications of these self-imposed governance policies to manufacture artificial urgency in teams and people. This fear based approach forces people to continually go above and beyond to get things done frequently for their own narrow need. In the process employee well-being frequently gets destroyed. This type of behavior almost always obliterates any hope of having a caring psychologically safe environment and can so easily become the norm for a learned helplessness infused environment.

So in closing, all leaders face constraints. I don’t for one second suggest that there is not real constraints placed on many industries. But true leaders differentiate between constraints that must be accepted and those that can be challenged. True leaders show their people that it is not only okay to go against the grain, but that they will be supported by the leader in that moment when they want to make a stand against the machine.

Agile Transformation: How to tell that you are failing…

“So being a geek at heart I present to you my list of anti-patterns regarding agile transformation.”

Behold the agile transformation wizard, here to save the day!

I present to you my list of wizardly anti-patterns regarding agile transformation…

I recently did an article about ‘why corporate companies suck at agile‘. Since writing that post I have had a gnawing urge to supplement the post with something a little more tangible and pragmatic.

So being a geek at heart I present to you my list of anti-patterns regarding agile transformation. For the less technically minded among us an anti-pattern is typically a documented recurring software problem that is usually ineffective and risks being highly counterproductive. They serve as a vocabulary to shape discussions about design based on past industry experience. Since Andrew Koenig coined the term in 1995 it has been adopted in fields other than software design, so I feel its a great succinct format to present my views with.

Anti Pattern: “Not my gig”

If your executive or management layer views “agile transformation” as something that is exclusively the domain of tech teams and if none of the other supporting functions are involved you might have a problem. Agile is a culture not a process or activity. If you only optimize the delivery function and not the supporting business functions all you are doing is over optimizing one aspect of your organization making it incompatible with the others. Agile transformation has to be an organization-wide activity including the executive layer or you are wasting your time.

Anti Pattern: “Don’t worry we’re experts”

If your army of agile experts and trainers only talk about methodologies and process then you have been duped and should strongly consider firing every single one of those expensive consultants on the spot. Agile coaching and scrum mastery are incredible difficult skill-sets to source for. The reason for this is because these roles are geared toward intangibles that are inherently hard to track and measure. Instead of parroting process or methodology the agile experts you are looking are individuals that continually cultivating the understanding that agility is a mindset and culture. The sad truth is that many agile experts are not experts at all. They are former project managers that need to stay relevant and subsequently went on scrum training (typically given by equally inexperienced agile experts). With the blind leading the blind all focus ends up on the tangible part of the role being process and methodology. Unless your agile expert has actually run a real agile project (at scale) and proven it to be a success in from the perspective of the (proper) agile community, you are missing the point.

Anti Pattern: “Madame Secretary”

Related to the “don’t worry we’re experts” anti pattern, the “madame secretary” can be spotted when a great majority of your scrum masters are merely acting as agile secretaries to their squads. Instead of doing any real coaching (or driving any changes) these individuals spend most of their time simply following the ordained agile events in a kind of weird check-boxing exercise. This happens a lot for scrum masters sourced from other roles or people that have been trained by one of these snake oil training merchants. Your agility team members should be students of the human psyche. They should be passionate about understanding human personality theory and should continually be coming up with experiments to improve the psychologically safe work environment of their teams. They should be obsessed by tracking every metric of team happiness. They should be an undeniable expert in their field. If a developer knows more about agile development than your scrum masters, you should be afraid, be very afraid.

Anti Pattern: “Waterscrumfalls hiding”

The waterscrumfall is already a known term but this anti-pattern takes the concept a bit further suggesting the intent behind it. Waterscrumfall refers to when your development teams are doing everything in their powers to run in an agile way, but all the other phases of the project don’t operate in the same way. This typically results in an over optimization of the development phase but unchanged slow moving cycles everywhere else resulting in sub optimal results. Now for the new bit. Agile is rough, it makes everything transparent for everyone to see. Developers embrace this since it beats having nobody else understanding what on earth they are up to. But this level of transparency might not sit well with some of the other more traditional functions in your organization. Waterfall was a great way to obfuscate many of the daily duties and tasks due to its inefficiencies. If you see signs of localized agile adoption it might be the unfortunate truth that there are some in your organization that prefer to hide from view.

Anti Pattern: “Functional Culture”

When cultural concepts get functionalized (and frequently centralized) you’re doing it wrong. Devops is a great example. Devops is a culture, it is a way to describe development and operations coming closer to one another. How do organizations respond? By hiring dedicated devops competencies and raving about them every opportunity. Operations personnel that fear for their future re-brand themselves and start singing from the devops hymn book. Team level devops activities get centralized to fancy new committees tasked with solving holistic problems establishing fancy new standards everywhere for everyone to use. If you are spinning up working groups, committees or new functions left, right and center around culture based concepts, you are doing it wrong.

Anti Pattern: “Just because”

Agile adoption should be tied to a tangible and inspirational goal. Unless there is a compelling ‘why’ as to why you are doing this transformation you will not succeed. Talking only about the ‘what’ benefits (like cost reductions or greater efficiency etc) is not going to get people to embrace a new culture shift. If you are getting a lackluster response from your people you should probably watch this excellent video by Simon Sinek, and reconsider your approach to leadership.

Why corporate companies suck at agile

“Sticking feathers up your butt does not make you a chicken.” – Tyler Durden

Why corporate companies suck at agile

Agile has become like a religion where everyone in corporations feverishly beat their breasts and shout at the top of the voices for all to hear how great it is.

It is amazing that 16 years after the agile manifesto came to life that many corporate software environments still talk about ‘Agile Transformation’. Agile has become like a religion where everyone in corporations feverishly beat their breasts and shout at the top of the voices for all to hear about how great Agile is and how totally on board they are with it. For many business professionals it has even become a career risk not to buy into the virtues of Agile.

For those paying close attention you will notice that when corporate environments talk about agile development, (like the paragraph above) they tend to talk about it in capitalized noun form. Agile development has been reduced in substance and is simply seen as a process or framework that needs to be adopted. It is seen as a magic bullet that is finally going to solve the inefficiencies in those pesky technology departments that just don’t get the subtleties of high brow business folk’s needs.

The problem is that this capitalized noun Agile mindsets miss the point completely. In the immortal words of Tyler Durden, ‘sticking feathers up your butt does not make you a chicken’. Similarly taking an agile (read nimble) process/methodology and following its steps to the tee without really understanding its purpose does not make you an agile organization. It was never about process or framework.

Agile is an adjective, it describes a culture and mindset. A desire to be adaptable, collaborative, lean and evolutionary. Agile is about early feedback loops, about failing early and fast. It is about constantly reflecting on yourself and coming up with experiments to improve things. It is about partnering with your client and involving them in the development process.

It is about transparency and externalizing risk at all times. Its about building products lean and incrementally. It is about accepting that you don’t have all the answers up front and using natural ways of working to figure them out just in time when they are needed.

If these words resonate with you I implore you to go read the agile manifesto again and to start focusing on the values and principles behind agile development instead of fixating on process. Be mindful of how people become fundamentalists about something they do not even truly understand in the first place.

We need to stop the army of Scrum Alliance trained ‘Agilists’ that parrot fashion recite SCRUM methodology to you claiming to be the answer to your waterfall world.