On Tuesdays, I write about the top voted question on Ask Berkun (see the lovely archive). This week’s question came via email from Pavel Pavia [43 votes]:

Are engineers more creative than designers?

Both answers (“Yes they are!” and  “No they are not!”) are naive. It’s foolish to compare massive groups of people against each other especially around a sloppy word like creativity. Assuming you work in the making of products of some kind, we all likely know some engineers who are very creative and some who are not. We also know some designers who are very creative and some who are not. I can’t even imagine trying to average them out into two neat little piles and have the resulting comparison be of much use. But what then? Why can’t we have some fun? ok – FINE. Here we go.

Let’s start by ditching the word creative. It’s a romantic word and the wrong one. When someone hires an engineer or a designer they want a problem to be solved. The creative ability we’re talking about is to develop ideas that solve problems into working solutions. Do good engineers and designers both do this? YES. They might be different kinds of problems, and they may use different tools, but both show up at work with the intent to problem solve, not “problem create’ or “problem multiply” (although such people do seem to exist, unfortunately).

The first argument is usually an anecdote about how “all the designers/engineers I’ve worked with suck” and to that I say you might be right. You’ve probably never worked in a healthy, successful organization that respected both roles and hired talented people to play them. But they’ve always existed – look at the teams that made the best products you admire and I bet there was a team of both excellent engineers and designers working together. Until recently it was only in elite companies that these investments were made, but that’s changing.

The next argument is often someone pointing out that designers are really just planners, since they can’t actually build their plans themselves. They need an engineer to go and built them. But so what? Why is the ability to build something necessarily superior to the ability to conceive the plan? It might be superior, but it might be inferior. I don’t think Beethoven could play the trombone, but he could write the plan for what they (and dozens of other instruments) should do, and that’s why we know his name and not his trombone player.

But I’m not taking sides here. Not really. To succeed at solving problems you need both the plan and the ability to build it.  The hard part is that depending on what the problem is, it can be either conceiving the plan or the ability to build it that is more difficult. And people are bad at recognizing when the most important challenge is in a domain that isn’t theirs (“If you have a hammer, everything looks like a nail”). Engineers are notorious for dismissing designers because of their own ignorance of what the customer’s true situation is (and the related potency of the designer’s plans), and designers are notorious for dismissing engineers because of their own ignorance of what the engineering constraints truly are.

The running sardonic joke in all this is designers and engineers tend to share more personality traits than not. Which include:

Which means many of the conflicts between designers and engineers are about bad management, the lack of a leader providing shared goals that unify these traits towards a common cause. Both trades are about problem-solving and when motivated can help each other with their individual tasks. Framed properly, and properly motivated, designers can have insights that help solve engineering problems and vice versa. All that’s required is some respect, shared goals and a curiosity to discover other ways to approach solving problems.

It’s useful to go back to a time when the distinction between designing something and engineering something didn’t exist. For most of the history of invention, people did it all themselves. When Archimedes or Archytas  invented the screw (which is a mind-boggling act of genius), was he designing or engineering? Would anyone at the time have cared in the slightest what label was given? John Roebling, the architect of the Brooklyn Bridge, knew that to make something great required both great engineering and great design. He couldn’t build a beautiful, functional, enduring bridge without them both. He and his team would switch between thinking more like designers and more like engineers whenever necessary, as they were unconstrained by the strict delineations we’ve created for ourselves in modern times, and we should all consider doing the same.

Related:

[Note: Pavel’s actual question was “What is the reason for which we believe that the people who dedicate to the arts are more creative than the engineers?” but as I wrote an answer it morphed into a simpler question.]

On Tuesdays I write about the top voted question on Ask Berkun (see the lovely archive). This week’s question came from J.R. [via email]:

What is a favorite theory that you wish more people understood?

A favorite theory I wish was more well known is the Satir Change Model. It’s popular in some circles, but often when I mention it in talks at events few have seen it before.  Virginia Satir was a family therapist who studied how families behave, and in particular, how they respond to change. Her ideas have been successfully applied to organizations and groups of people.

We like to believe change and progress are predictable, especially if we’re applying an idea we’ve used before or that is widely accepted. But according to her research (based on family behavior), and her model, even when we’re making the right change, at the right time, confusion and fear are likely.

The Satir Change Model is simple and has 5 parts (image by Jurgen Appello):

  1. Late Status Quo – this is the present, where things are stable, at least in the sense that they’ve been the same way for some time.
  2. Foreign element – This is Satir’s term for any change that is introduced, which could be something deliberate (a new healthy diet) or something surprising (new neighbors move in next door). It could be a new idea, process, team member or anything. Often people resist foreign elements, even if they come with the promise of solving a problem. People often prefer to keep doing what they have been doing (status quo), even if there are things they don’t like about the status quo, especially if they don’t have much trust in their leader or their coworkers.
  3. Chaos – (IMO this is the central idea of the model). Even if you are doing everything right, and the change is the right one, volatility will rise for a time. Average performance will drop as people experiment with adjustments to incorporate the new idea. Hidden assumptions, and emotions, will be revealed, which can be painful at first. A new idea may require new conversations, redistribution of responsibilities and more. What makes this phase challenging is it’s hard to predict how long it will take or if the path is the right one (e.g. “do we need to keep going, or is this direction a mistake?”)
  4. Transforming Idea – The job of a leader is to help a team work through the chaos phase until they reach clarity. This is challenging as each person might require different coaching, advice, support or training to adopt the new idea. And the team as a whole may need to reform, with different roles and responsibilities. Someone with leadership skills might correctly identify a new direction, but it takes someone with people management skills to help them through the transitions that the new direction demands.
  5. Practice and Integration – Once the new idea is understood and adopted, finally the expected gains can be seen and progress becomes predictable. And eventually stabilizes again as the new status quo.

The model isn’t predictive. It doesn’t tell you how much chaos a particular idea will generate, if any at all. It can’t tell you how long it will take before you find the “transforming idea”. It also can’t tell you whether the new idea you’re introducing is the right or wrong one (e.g. the chaos will never end, or performance will never recover). It’s simply a useful framework for thinking about the psychological patterns likely to arise when something changes.

Inexperienced people often confuse the chaos phase as a failure in their choice. And if they quit early, assuming “chaos” means they made a mistake, and revert back to the old ways of doing things, they likely will never have the confidence to try something that bold again. They now confuse the chaos phase with failure. This is a kind of self inflicted learned helplessness, where the necessary cost to improve and grow is now too psychologically expensive. People and organizations can become paralyzed here, as they’ve become extremely resistant to any threat of a “foreign element”, even though that’s exactly what’s needed to grow.

Some foolish people dismiss Satir’s work based on the question what do families have to do with workplaces or individual adult choices? But workplaces are based on relationships, and we learn our models for how to relate to other people from… our families! Your favorite, and least favorite, coworkers learned many of their patterns of behavior from their early relationship with their parents and siblings. How we define trust, love, collaboration, friendship and teamwork all come from our experience with the first and primary tribe in our lives.

Anuradha Gajanayaka compares the Satir model to Kanter’s Law, which states that “Everything looks like a failure in the middle.” She suggested that we “Recognize the struggle of middles, give it some time, and a successful end could be in sight.“

And that is a key takeaway from the Satir model. Even if you’re doing everything right in your life, or as a leader, when you try to change something be prepared for surprises. Plan time for “chaos” in response to the change, where it’s normal for performance to drop and for experimentation to happen until the new idea is understood, incorporated and refined.

I’m the I was the closing speaker today yesterday at Digital PM Summit in San Antonio, TX, and I’ll be taking notes (or in fancy terms, liveblogging) for every session that I sit in until it’s my turn. I’ll be following the basic rules of Min/Max note taking and will update this post as the day goes on. It’s the first PM event I’ve been to in years – brings back many memories from my first career.

Please forgive typos, I’ll get to them when I can. Here we go!

1. Brett Harned – Army of Awesome (slides)

Brett, one of the organizers of PM Summit, asked the audience how many people became Project Managers / Producers on purpose, vs. how many fell into it accidentally, and most of the room raised their hands as accidental! (He joked with a slide that said “You are not an accident” 🙂 This isn’t a surprise as often the role evolves as a project or organization gets larger.

It’s also a related observation that most people don’t know what a project manager does, particularly digital project managers. Once during a trip he was stopped by a UK immigration officer who seemed baffled by his job title and asked: “what kind of projects do you manage then?” He shared a list of quotes from colleages who he asked to explain what he did for a living:

He shared how the History of Project Management goes back at least 4000 years, and that there’s a long history of teams of people making difficult things. But that digital project managers have yet to be entered into that history in a meaningful way, and part of what he’d like to see is greater recognition for the contributions digital project managers make.

7 DPM (Digital Project Manager) Principles: The balance of his talk was an exploration of 7 principles about leading teams and projects.

  1. Chaos Junkies – we thrive on problems because we know we can solve them. We break processes to make new ones. We make our own templates. We managed with our minds, not our tools.
  2. Multilingual communicators – listen and take cues from our team and clients.
  3. Loveable hardasses – reputation for being firm but wise and well intentioned.
  4. Consumate learners and teachers – that teaching teammates helps the project, the organization and the pm
  5. Laser focused
  6. Honest Always – cultivate a reputation for straight talk
  7. Pathfinders – do more than take care of budget and timeline

His final question for the audience was: where will you take us? Which principles resonate the most?

2. Natalie Warnert – Show Me the MVP!

The core of her talk was about the concept of MVP, or Minimum Viable Product, and how to apply it to projects. She referenced Eric Reis’ book, The Lean Startup, and asked who had read the book:  I was surprised how few hands went up. Perhaps I’ve been to too many start up events the last few years. I had a hard time following the thread of her talk – she referenced many models and frameworks but it was tough to find salience to pm situations, or connections to each other.

She offered four goals or objectives:

She mentioned loop models, were you have a cycle of behaviors you repeat, such as: Think -> Make -> Check. Briefly she touched on Lean UX, and  how customers must be involved as part of that check process – “Customers don’t care about your solution, they care about their problem”.

Next she talked about metrics, and offered this quote: “A startup can only focus on one metric and ignore everything else” – Noah Kagan. I didn’t agree with this, as it sounded more more like hyperbole than sanity – plenty of successful startups have focused on multiple metrics, or at least prioritized them.

She offered “Pirate” metrics as good choices for what the primary metric should be:

Regarding building software, she explained the Build Model:

Which she compared to the Learning Model (Learning, Speed, Focus), but I didn’t quite understand how they related to each other.

Lastly she provided this outline, in reference to a project she managed:

3. Elizabeth Harin, How Can I Help You Now That It’s Too Late?

She explained that her background is different than most of the audience, but that the importance of feedback is shared: feedback should make it easier for (clinicians) to do their job.

A common mistake in getting feedback is asking for it only when it’s too late, AFTER, the customer has experienced what you made for them. She gave the example of how a waiter at a good restaurant will check in on how you are doing DURING the meal, creating the possibility for them to fix a problem before it’s too late. But projects rarely do this. All feedback is too late.

A goal she has used is to make it possible.. “For all our customers to continually rate the services we provide as good, very good or excellent” and that part of this should be that the customer defines what good looks like (which is important since it forces you to confirm your assumptions about what customers actually want are valid)

Steps:

  1. Get buy-in – does your team support idea of continuous customer feedback?
  2. Set & Spread the vision – “want majority of customers to score us good, very good or excellent”
  3. Decide who the customer is – it’s often not the most senior or visible person (and segment the customer pool if needed).
  4. Define your scoring mechanism
  5. Organize for success
  6. Align your partners
  7. Launch
  8. Do the work (she joked at once getting the feedback “having a change management process is onerous, so… we shouldn’t have one”)

She closed with the following quote, pointing out how we call use the right words, but the impact is only felt through our behavior.

“people may hear your words but they feel your attitude” – John C. Maxwell

4. Aaron Irizarry, Hold Fast: Managing Design Teams When Projects Go Sideways

The number one thing that will screw up a project: people. Feature and scope creep only happens because someone is not communicating well with others.

Projects are complex for many reasons:

The most important thing is to avoid being blindsided. If you see problems coming you can prepare, but if you are surprised by something you did not anticipate the damage will be far worse. Almost every problem can be traced back to communication issues and how people relate to each other.

Be prepared to ditch your process if it’s not working. It’s the ends that matter not the means.

‘Everyone has a plan until they get punched in the face’ – Mike Tyson

You don’t want to be inventing a new plan when you are in the middle of chaos. Have a backup plan. And a backup plan for your backup plan.

The needed solution might not be the ideal solution. There is what’s ideal and there is what’s real.

5. Tera Simon, How to Eat an Elephant (Or Tackle Most Any Big, Huge, Enormous Project) (slides)

First time she worked on a large project she was excited to see a budget so big. The project was to make a video game to teach accounting to high school students. But then she realized her  team was small and the expectations the client had were demanding. This led to a kind of crisis: Why me? Why did I want to be in this situation? (In the end they did finish the project on time, but over budget). Over many projects she’s found good answers to this question.

PM is untangling the most complex project and making it tangible.

Essential skills for managing (complex) projects

  1. Adaption
  2. Collaboration
  3. Communication
  4. Expertise
  5. Leadership – cheerleader and bulldozer at same time. Takes time and practice to learn.
  6. Strategic

Difficulty != Complexity: just because it’s difficult doesn’t mean it’s complex. Factors that make a project complex:

When eating an elephant, take one bite at a time.

Scope Creep causes

Effort Creep causes

Hope Creep

Feature Creep causes

“The single biggest problem in communication is the illusion that it has taken place” – George Bernard Shaw

Swoop and Poop

6. Carson Pierce, Your Brain Hates Project Management

“The brain is fundamentally a lazy piece of meat” – Gregory Berns

Our brains are not as impressive as we think they are. We are not designed to handle the amount of information and the cognitive tasks we ask. It’s like taking the first computer you ever owned and trying to use it today to use web.

“It’s not information overload, it’s filter failure” – Clay Shirky

“My wife probably tells me that I never listen” – Rodney Lacroix

He showed an example of awareness bias (watch this video and try to count how many times the white team passes the ball). It’s easy to miss something you’re not looking for. As a side note, ADHD means it’s hard to focus on one thing.  While someone with ADHD are more likely to see everything (in the video), but also more likely to get the count wrong.

Layering: two relatively simply things using different parts of the brain (singing while driving, one is physical one is mental).

However two mental tasks at same time: does not work well. Instead of doing them at the same time our brain switches back and forth (fast enough so we feel like we’re doing both, but we’re not).

“Multitasking is the ability to screw up everything simultaneously” -Jeremy Clarkson

He asked the room how many projects they manage at the same time: majority of the room was 6 or more.

General stats (reference?) on performance loss when trying to multitask:

He referenced a study of judges and how they granted parole 65% early in the day and drops until lunchtime, when it returns to a high level.

He was going to talk about procrastination, but then decided to get to it later.

  1. Rest – 7 hours of sleep (Most people who think they need less are probably wrong). Taking breaks is good for body and brain (see pomodoro technique).
  2. Eat – don’t eat bad things.
  3. Move – We work in a chair for 8 hours a day. We need blood flow, to stretch or joints, and our brain is part of our bodies after all.
  4. Plan – Avoid back to back meetings. Try for single tasking – where you are focused on one project at a time.
  5. Cheat – shortcuts, rules of thumb, heuristics – ways to make your brain more efficient.

Predictable Mistakes

He gave an example of the conjunction fallacy – is Linda more likely to be a banker, or a feminist bank teller:

“Linda is 31 years old, single, outspoken, and very bright. She majored in philosophy. As a student, she was deeply concerned with issues of discrimination and social justice, and also participated in anti-nuclear demonstrations. Linda is a bank teller and is active in the feminist movement.”

He referenced killer clowns as an example of availability bias, a mental shortcut that relies on immediate examples that come to mind, and also probability neglect.

For PMs an important one is ambiguity aversion – where we will take a known thing, even if it doesn’t work well, over an unknown (known risk over unknown risks).

Another one is illusion of control – dice games where people believe they have an influence over the roll. Or when people yell at their televisions while watching sporting events, or even pushing the elevator button more than once.

Estimation is prone to many kinds of bias (the planning bias documents our tendency, even experts, to underestimate time, costs and more). We also suffer from anchoring bias – whatever first number we hear changes the answers we tend to consider (a factor in speed limits and prices). As a tip, whoever anchors a discussion can likely influence it.

Hofstadter’s law: it always take longer than you expect, even when take into account Hofstadter’s law.

Advice

We are wired with these limitations and it’s not entirely clear how consistently we can overcome them. But there are tactics that minimize their impact and frequency: