Chasing the Dragon

Chasing the Dragon

I know many folks who have a powerful desire to build great products, and great software for great products. Many of these embrace the mantra:

“How do you build a great product? Build a great team and let them build it for you.”

Sadly, most of these folks are working in organisations that do not share their passion for great work. So they find themselves, quite naturally, and without much conscious thought on the matter, limiting their ambitions to their own little corner of the organisation.

Thus we see some “great” development teams, and development shops, embedded in the IT silo – or, more rarely, some other silo.

The folks with the passion beaver away, learning, experimenting, building, evolving, growing and adapting. Embracing change. Doing great work.

But it’s never going to be satisfying. Not really. Because there are so many other folks outside of “development” involved in creating a product that however engaged the development team, the customers’ experience depends on not only the development folks’ efforts and passion, but on many other folks’ inputs too. And getting this all joined-up across the silos of a typical organisation is so fraught with difficulties, missteps, confusions, conflicting priorities, ball-dropping – and other dysfunctions too numerous to mention – it’s just never going to happen. It’s never going to result in a truly great product, and neither in a truly great customer experience.

The bottom line is that in siloed organisations (by far the most common kind), the whole idea of a “great development shop” is a chimera, a delusion, a dragon.

Are you still chasing that dragon?

– Bob

5 comments
  1. Let’s assume you currently find yourself in such a siloed organization, what is the best way to change it? Pray for a leadership change in heart (e.g. have the CEO see a vision “in hoc signo vincit” and then attempt to remove all siloes)? Or are there ways to remove the silos from the bottom up?

    Or is the implicit message of this post to abandon such an organization?

    • Hi David,

      Thanks for joining the conversation.

      I see organisations much like (individual) people, in that I wouldn’t try to change someone, and thus neither would I try to change an organisation. If an organisation wants to change, and wants help in changing, then it meets my need to help it/them in their journey.

      The literature is replete with examples of failure when trying to turn a hierarchical organisation into a horizontal, e.g. value-stream aligned one.

      For me, the best choice is to not go down the hierarchical, siloed route in the first place. Given that some organisations are already there, then there are some few examples in the literature, and my personal experience, of ways to tackle the challenge. See also: /2012/12/28/approaching-change/

      – Bob

      • Thanks, Bob! Your blog post on approaching change was just what I was looking for.

        I think I’m open to attempting to change (or “rightshift”) what I see as a failing organization because that would fulfill a personal need. Not only mine, but probably other’s needs as well.

        There are non-violent ways of approaching change as your blog post points out. I would think in many siloed organizations, there is simply a lack of knowledge that things could be better. Attempting to enlighten people and managers of alternatives wouldn’t be violent (that is if it’s done correctly), but would healing and loving.

  2. David said:

    Bob’s thoughts are very true and congruent with many experiences throughout my career. It is thus that I developed Berg’s Second Law: “An IT product will be only as successful as how well its developers understand the business context of the enterprise it serves at the operative level.” This is how silos – however disparate they may be – become connected to achieve a common goal. It is also how developers of the underlying foundation of a product become motivated and passionate about their role in creating a superior product.

Leave a comment