In my first job after graduation, I had a boss with no formal qualifications who had not only a technical flair, but the leadership skills to share a vision & make people follow. He was also very opinionated. I remember him once saying of the engineer that oversaw the draughting office that he should be promoted or fired, on the basis that he was doing nothing where he was. Anytime that engineer visited our project team, we'd smile, accept his latest 'brilliant' idea, & wait until he left before we pulled it apart & did something better.
However, I suspect that, without that bad idea, we would have continued on along a steady path of acceptance that what we'd been given was good enough. We knew it wasn't, so we did it ourselves to prove a point.
Disruption is good.
I don't say that lightly. Not distraction, disruption. A change in requirements often makes you rework the solution. Knowing that there are always changes to requirements makes you rethink your approach to making a solution. That's rarely going to make a worse solution. It makes you, the team, the deliverable, the process of development, all more resilient, both in terms of the deliverable & the quality of the artefacts.
Way back in the 1960s, IBM was a powerhouse of thinkers. Not just that, they delivered some extraordinary ahead-of-the-curve hardware. They did it by working through the night, being over budget, getting burnt out, & basically doing everything we are told good project management avoids. It is a well known fact that, since the introduction of good project management, IBM has produced nothing close to that kind of innovation.
When a bunch of middle-aged white guys got together to define Agile, a new way of working in software development, their aim, was to get a team to a point where it was working at peak efficiency for as long as possible, which usually means achieving a steady state: knowing what you can produce, committing to that, then delivering. Changes in requirements, etc, will always mean changes to either the deliverable or the timeline, because the steady state allows for no third option, where everyone puts their personal life aside & the project succeeds or fails by the original expectation.
Morality gets in the way of innovation. Social responsibility is not compatible with wonder.
Now, I'm trying to avoid saying that I want to force a team, or be part of a team, to over-commit & then burn out trying to deliver the impossible. I don't want that. Any honest executive does.
However, what works is the bit of grit on which the pearl is formed, the itch that keeps you scratching until you come up with the idea of flea powder (or bathe), the idiot who keeps interrupting your flow to ask 'hey, have you thought about this idea?'. Every so often, it's not the idiot's idea, it's their asking that triggers something in the creative genius (common or garden engineer) that sparks a conversation that leads to questioning assumptions that leads to redefining 'correctness' that leads to a late night session where no-one dares to go home unless they miss something that will change the world.
If everyone believes the same things, then no-one will learn anything new. If everyone thinks the same way, then no-one will produce anything new. If everyone agrees, then there can never be anything new.
Disruption is good.
Don't go out there intentionally disrupting everyone & everything, but be more open to the process of disruption.
I worked with an excellent executive once, & we were strategising how to build a brand new team that would create a new product based on a prototype. Selection was based on 60% technical match, 30% team fit, & 10% being a good person. In his experience, you only needed one bastard in the mix, & that was going to be him. Role filled. Move on.
He was the disruption. He was not a technical visionary. He was certainly an excellent leader, but I'd never seen him build anything. He was also a good corporate tactician. That team, which stayed together as is for more than a year, but many of whom remained for several years, backslid to producing mediocre output as soon as he stepped away from the role.
I will admit to my own failing in not being disruptive enough when I stepped in as designated bastard, having designated myself bastard on a different arm of the business in the meantime as a technical person with almost no grasp of market analysis.
Again, I stress that being the disruption is not essential, but being able to recognise the disruption & their role in kicking the project forward - or sideways - is key to delivering surprise & delight to your stakeholders.
No comments:
Post a Comment