When we deal with organizations, we typically act toward the people we’re connecting with in the organization based on our default ‘map’ of the organization.
It’s important to understand that – like most things – we can represent things (including organizations) using multiple maps, all equally valid – and all useful in the right context. Here are three maps of Los Angeles (topographic, freeways, rail lines):
Similarly, we usually represent organizations with different maps.
Foundationally, there is the map of the explicit power within the organization – I think of this as “who can fire who.” It’s represented by the typical hierarchical org chart. Everything in the organization intersects this map – because people want to keep their jobs or advance, and the relationships in this map will determine whether they do or not.
(with apologies to Bertrand Russell..)
For a living, one of the main things I do is to advise and train technologists on how to deliver better – better systems, with better quality, better business value, better timeliness and predictability. I teach and coach lean-agile practices and patterns, and I know that they work.
But I’m wondering if I’m – we’re all – doing it wrong.
I’m at a conference with a bunch of people who do what I do, and what I’m hearing – over and over again – is that we’re having success… to a point.
And I was sitting in the sunshine outside and realized that what we’re doing is bolting a layer of lean-agile practices onto traditional hierarchical management structures.
It looks a little like this:
We’re lowering the friction of traditional organizations,
…a continuation of the earlier post about what I’m going to tell a class of undergraduate system engineers)
Let’s talk about people first.
Immanuel Kant had a great quote that you should memorize: “Of the crooked timber of humanity, no straight thing is ever made.” (Idea for a General History with a Cosmopolitan Purpose)
He’s right. No one is perfect, and nothing any person makes is perfect. When we start doing things that involve more than one person, the imperfections multiply.
Even if it’s one maker and one customer
• The customer doesn’t always know exactly what they want
• The customer can’t always articulate what they want
• The maker doesn’t always understand what the customer wants
• The maker can’t always make the materials do what the customer wants
• The maker can run out of time or resources
So I’ve been asked to give a talk to an undergraduate college class in Systems Development (within CompSci). The professor is a friend, and knowing about what kinds of work I do, he asked me to come up with a 90-minute instructional block on anything I thought would be helpful to them.
So I thought a bunch about what I wished I’d been told when I was an undergraduate, and came up with this; I’d love feedback (actually, they’d love feedback – it’ll let me do a better job presenting to them).
Imagine this in the form of lecture notes:
The topic is the difference between Engineering and Physics.
What’s that difference? It’s simple – physicists can be successful with gedankenexperiments – experiments that you run in your imagination. Engineers just build stuff.