Psychology for Engineers - understanding your people

[Big Bird]

Greetings all,
I’ve got another essay bubbling away inside my head. I think it is sufficiently different from the “Reasoning…” argument to warrant its own thread, but if you think it should be buried there please let me know.

I’ve been thinking of team politics and harmony, and how they are much better indicators of team success than vehicle specification. I would like to attempt to define some of these factors, rather than just tell you it is “all about people” and then give you nothing concrete to work with. I am not a trained psychologist – but then again I’ve seen qualified engineers who cannot engineer, and unqualified one who can…

I’ve also been thinking of the applications of design process in the real world, given that I see a lot of the lessons we learn as engineering designers (and in particular, FSAE designers), are not learnt by people who are often looked up to as role models and mentors, and who should be smart enough to know better.

I’m going to pick two easy targets for us in the below – politicians and academics.

Some will say that the below is lost on undergrad engineers. I say that even if it is, it might be useful further down the track. I didn’t stop learning from the FSAE experience the day I graduated.

What I like about engineering is that it is practical. At the end of the day, we have to apply what we know and deliver something concrete in the real world. Often, that is an artifact, sometimes it is a process or a procedure. But our success is measured by the results that we deliver – not the arguments that we have, or the ideas that we generate, or anything we say, or anything that is polished up and presented by marketing departments and PR agents. Our challenge is to deliver.

The engineering design process can be described in many ways, and different descriptions may suit different purposes depending on what we wish to understand. The first post in my “Reasoning…” thread contains a methodology and breakdown of the vehicle design process. In the following, I am going to attempt to broaden that out to a general problem solving process – and offer some ill-informed prattle about some psychological aspects of our thinking processes.

For the sake of this argument, I will assume that the problem being confronted is known and understood, and we are about to embark on our problem solving process. I will use the FSAE problem as a starting point, but then draw in some observations from the outside world.


THE THREE PSYCHOLOGICAL STATES OF THE DESIGN PROCESS
I will break the problem solving process into three phases.
1. Generation of solutions
2. Analysis of the solutions
3. Delivery of the solutions

I am being quite broad here, but that is because, psychologically, I see three distinct mind skills that quite neatly fit into the above three phases.

The first phase, generation of solutions is a creative phase. It is all about ideation, opening your mind to new ideas, being adventurous. It is about suspending criticism and disbelief, and being positive. I think humour fits in really nicely here, as humour is effectively about taking something familiar and then providing a surprising answer or twist. For example, I am presently organizing a few charity benefits with some friends, and attempting to be a funny bugger I have twisted the term “friends with benefits” around to come up with the name “Benefits with Friends”. Ho ho hee hee I’m so hilarious – not - but I can never remember jokes and wanted to save you all the collective facepalm if I had have rolled out the standard “what is brown and sticky – a stick!” joke.

Anyway, the point I am making is that this first phase is all about twisting and distorting and looking at problems from different perspectives. Phase one is the fun phase, I reckon.

Phase two involves analysis and criticism of the ideas generated, and requires a different psychological skillset. This phase is all about fault finding, identifying potential failure points, finding limits, criticizing. If phase one is open and adventurous and generative, phase two is confining, critical, and effectively “closes out” the ideas that are not suitable. It is analytical, serious, and is quite “negative” in character. The effect of this phase is to prune down all the ideas to the one solution you are going to build.

Phase three is effectively collaborative. It is about taking the one design you have decided upon and delivering it. It is about putting behind you the arguments and disputes you had during phase two and moving forward together. This is real engineering, this is teamwork and delivering a product and this is what sets us apart from scientists.

So, effectively the process works like this:
1. We go through a creative process to generate ideas
2. We go through a critical process to eliminate options and select one for delivery
3. We go through a collaborative process to deliver on our final product

From a Formula SAE perspective, we could define the transition from phase one to two as the Conceptual Design Freeze, and the transition between phases two and three as the Final Design Freeze. We come up with ideas, we select the best one, we work together to build and deliver on the final product.

If you look at the above a little more broadly, it is not only relevant to FSAE design, or engineering design, but is a rather decent representation of any problem solving process.


SOCIETY STEPS IN…
OK, so now it is time to start shouting from the rooftops about how society is stuffing everything up for us, and how it is not our fault…

The dominant thinking pattern and the one that seems to get the most attention in our society is the critical phase two pattern. We celebrate our critical thinkers to such an extent that many people in our society make a damn good living without ever venturing out of phase two.

Our academic institutions are pretty firmly entrenched in a phase two mindset. In our engineering education, I would say 90% of our material is about analysis, which is effectively about criticism of a certain design. That criticism may simply be in terms of calculating a force or a velocity, but it is generally about assessment of an existing product or system and whether or not it is fit for purpose. Other faculties are typically the same. The teacher gives some information, the student has to perform some exercises to have their understanding assessed, and the teacher then looks over the work to “correct” it and assess where the student has gone wrong.

Our political system, our legal system, and our media are pretty much the same. Adversarial, critical, confining, negative.

Don’t get me wrong, I am not saying that this is a bad skill to have. I am saying though, that it is but one mental skill in a suite of them, and that if practiced solely is ultimately destructive.

Curiously, the only time I really hear celebration and appraisal of the full three phases of problem solving is in team sport, and in war. When I listen to football commentary, I hear the commentators speak of strategies to create opportunities, and shutting the opposition down, and building team spirit, etc etc. We look at our sportsmen quite often as dumb jocks – but in fact they regularly demonstrate a kind of mental agility that spans all three mental skills mentioned above.


MISTAKES WE MAKE
The critical phase nestles neatly between the creative phase and the collaborative phase. So what happens when the critical state creeps in either direction.

Critical mapped over creative: this usually manifests itself in the shooting down of ideas before they have been investigated. The “that is a stupid idea” mentality that kills a lot of creative thought. Note that one of the first rules of brainstorming is to suspend judgement – the intention being to free the mind and expand the set of potential solutions. I have seen very few minds here that are brave enough to be fully creative and exploratory. I would nominate Z and Rob Woods as belonging to this group, and note the chorus of criticism they have attracted over the years. Phase two thinkers can’t wait for a phase one to arrive so they can ply their trade and shoot them down in flames. How often does a Z or a Rob Woods get a “hey, that is an interesting idea – let’s explore it further.”

Critical creeping into collaborative: this usually manifests itself as the divisive “I would have done better” character – the one who can’t accept a team decision and move on. The “things aren’t perfect yet so I’m going to tell everybody I can” character who, often subversively, undermines the harmony of the team by encouraging little cliques of dissent. I have seen an extraordinarily prominence of this kind of behavior in FSAE teams. The teams that control this are the winners.

I would say that a number of teams approach this project with a completely phase two approach, and it shows….

I’ll write more in the near future, but for now it is time for bed. Hopefully I’ve got at least a bit of the message across in the meantime.

[mecwill]

I love your brain man.
The way of thinking its important in every stuff were involved.
I think its a known 'guidance' but people should hear or think of that more often; just like a clock alarm wakes you in the morning.
But that depends on the education system and the 'journey' your in in life.
If you find yourself thinking that the psychology its a good think for you, you start seeing things differently.

[Big Bird]

As I mentioned above, engineering is a vocation of practical fault finding and problem solving.

A purely fault-finding approach is confining and focus-narrowing. You will always find a way that a new system or idea is inferior to an existing system.

How many of us have shot down a new idea because we didn’t like it, or saw fault? I’d say probably all of us.

How many of us have looked at a new idea that we didn’t like, or saw fault in, and then actively looked for the good in it. Probably not many of us. Once we are engaged in fault finding, and are being adversarial, we are often too emotionally invested in the argument to accept any good. And given the engineer’s job is to objectively weigh up the good and the bad, this is a dangerous mindset to get in.

This is the major problem in dealing with engineers. They don’t know when to let go of the scalpel. They are so focused on fault-finding, and cutting out the “wrong”, that they leave themselves nowhere to go. If we go left, there is this bit of wrong. If we go right, there is wrong over there too. We’d better not go left or right, and we can’t go backwards because that is just really dumb. So lets keep marching in the same direction we always have, into this brick wall directly in front of us…

CASE STUDY IN ADVERSARIALISM AND DISPUTE – TUG OF WAR
Forgive me, I have marched this one out a few times, so apologies to anyone who has heard it before. School sports, two teams of students playing tug-of-war. They are given a rope with a flag on it, two lines marked on the ground. On the word “go”, the two teams pull directly against each other, with the objective being to move the flag over the line closest to you. After quite a bit of tugging and straining, one team outmuscles the opposition, the flag crosses the line, and a winning team declared. Result – two exhausted teams, one team satisfied, one team aggrieved, one rope moved maybe five metres to the right.

Maybe there will be additional heats, maybe different teams, but the same game plays out. At the end of the day, everyone reflects on their own results - winners are inspired to train harder so that they can oppose their opposition even better in future, losers get grumpy and vow and declare that they will train harder so that they can oppose their opposition even better in future. Everyone eats a lot to replace their spent energy. The sports staff pick up the rope and takes it back to the sports shed.

Now from an engineer’s point of view, we should look at this situation functionally and objectively.

Functional objective: - move rope
Case Study #1: Tug of War (adversarial model)
Method: Move rope by pulling both ends at once. Two teams of highly trained individuals diametrically opposed, working against each other.
Functional outcome – rope moved 5 metres
Cost: two teams of possibly highly trained individuals now exhausted, much energy spent, individuals fixated on working even harder on working against their opposition in future

Case Study #2: Sports staff pack-up (collaborative model)
Method: Fred the 63yo janitor picks up the rope and takes it back to the shed. Everyone understands that it would be silly to work against him, by for instance standing in front of him, pulling him backwards, tripping him up, or waiting until he puts the rope away and then putting it back onto the sports ground so he has to do it all again.
Functional outcome – rope moved 100+ metres
Cost: Fred’s wages for three minutes, and a little bit of his energy. Fred forgets about it as soon as it is done, and he is soon back home where he can focus his time on his model train hobby.

Put in those terms, we can see the ridiculous inefficiency in opposition and dispute when it is employed as a means of progress.

We wouldn’t dream of hindering Fred’s efforts to pack up the sports ground because we all agree that is a worthy objective. We all agree that the rope should be back in the sports shed, we agree that we want the sports ground to look nice, we all agree that putting obstacles in Fred’s way will only lengthen the packing up time and ultimately cost us money.

Yet somehow, when it comes to politics, for example, we are happy to support a system which is founded completely in adversarialism. In Australia, we have the Liberals and the Labour Party opposing each other on every issue. Members for each team are carefully trained and picked so that they play the game correctly, and oppose their opposition at every step. No-one is allowed to agree with anything the opposite team says, no matter how beneficial the outcome may be to the outside world. Thus we set up an immensely inefficient and unwieldy system that spends an enormous amount of our money and time arguing with itself in the name of progress. Slow, expensive, unwieldy – painful.

I also remember with some amusement the story of some famous gridiron player, built like a fridge, who retired after maybe 10-15 years of playing having only touched the ball three times. His job was to stand there like a fridge, directly opposite another bloke who looked like a fridge, and upon the blowing of a whistle he would engage in this game of grappling fridges where each fridge would try to stop the other fridge from stopping him, so that neither of them would get in the way of the game of football that was going on around them. We celebrate this kind of thing. We hand over lots of money for it.

Now I am probably being overly simplistic about all this. In the case of federal politics there is a bit more complexity than a simple tug of war, as there is a definite need to identify potential flaws and failure points in the topic being debated. Thus dispute (fault-finding) is a necessary part of the process. This correlates with our experience of Formula SAE too.

BRINGING IT BACK TO FSAE
So what are the objectives in Formula SAE:
1. Understand the problem (best done collaboratively)
2. Propose potential solutions (creative, expansive)
3. Analyze solutions to pick out the best one (critical,fault-finding)
4. Manufacture our solution (collaborative)
5. Refine our solution (collaborative)
6. Present our solution to the various judges, informing them of what we have learnt along the way, (collaborative)
In each of the above, we could potentially argue that each of the three mind states can be useful - however I have chosen to present the most prominent state.

Accepting that we need critical thinking / fault finding to be part of our process (but not all of it), how do we engage in the fault finding process (dispute) without it being a tug of war? How can we do it with the least usage of time, energy and resources?
1. Be honest with each other – don’t sugar coat stuff, and don’t put spin on your argument to favour your own favoured solution. If an engineer proposes a certain design solution and refuses to see any fault in it – sack them. If an engineer looks at someone else’s design solution and refuses to see any good in it – sack them. If the whole team knows they can trust each other to offer unbiased, honest information to melting pot – then the layer of complexity and wasted time attributed to breaking through sales spin is averted
2. Be critical – yep, point out what you see as wrong. And if someone finds fault in your critique – listen to that too and see if it makes sense. Ask yourself what you can learn from their perspective on this – rather than get all defensive and feel the need to prove them wrong.
3. Be encouraging – point out the good as well as the not-so-good
4. Be dispassionate about the product – we are building a self-propelled protective chair. Don’t be precious
5. Be mathematical – use numbers wherever possible to decide an argument for you. Don’t under any circumstances fudge the numbers, otherwise point #1 above flies out the window
6. Be thorough – make sure your mathematical analysis is comprehensive but appropriate
7. Be realistic – don’t expect you will solve all the FSAE problems in one year. Know when to say enough
8. Be humble – don’t get all precious if you don’t get the answer you like. You are an engineer. You don’t like. You do.
9. Be team focused – the team helps you to achieve things to a much grander scale than what you can achieve on your own. You would not have this opportunity without your team. Live for the team. Not yourself.
10. Be results focused – Your tasks as a team are to gather competition points, encourage new students to come to your uni, promote your university’s name, secure resources for your project and future projects. Know your objectives, and measure your success in terms of them. Don’t get bogged in petty arguments and don’t shift the goalposts as you go along. Set a deliverable plan, deliver on it.
11. Move on – when the design is frozen, and the disputing stage is done – stop your whinging and move on. Sure, keep an eye out for unforeseen faults, but do everything you can to be collaborative to deliver on that final product.

[Big Bird]

OK, a bit more about the phase two team. That is, the team that approaches FSAE purely from a fault finding viewpoint.

Firstly at the lowest level of engagement there is the team that looks at the winners, finds the differences between the winning car / team and their own car / team, and tries to win the event by eliminating the differences. Utterly uninspiring “design”. This sort of philosophy was behind the FSAE that I walked into in 2001, where an extraordinary number of teams were playing the game by trying to out-Cornell Cornell.
- Our motor is different to Cornell’s. Cornell beat us. Therefore we need Cornell’s motor to beat Cornell
- Our chassis is a different shape to Cornell’s. Cornell beat us. Therefore the type of chassis that is best is a Cornell-shaped chassis which we will need to beat Cornell
- Cornell have an electric supercharger. Cornell won. We didn’t win. We don’t have an electric supercharger. Not only did the team that did win have an electric supercharger, but the team that didn’t win didn’t have an electric supercharger. So we need to both have an electric supercharger, and not have a car that does not have an electric supercharger.

This is the “winning by following” method, which is essentially the “we won’t have a competitive advantage while we are different to our competitors” philosophy.

One step up from here is the pure analysis / fault finding team.

The project will usually start with a fault-finding analysis of the teams effort at the previous competition. Pick out what we did wrong. Fix it. Merit in that? Certainly. You don’t want to keep doing wrong. We then divide the car up into pieces, and fix the faults in each of the pieces. Car isn’t light enough. Chassis not stiff enough. Engine not powerful enough. Roll centres too high. Bob can fix the chassis, Carol can do the chassis, Ted and Alice you can attend to the suspension geometry. Everyone, make your parts as light as possible.

Faults in the fault finding process?
1. To a certain extent you are limiting your scope to the design solutions that are already there in front of you. Your design template is effectively last year’s car but with some bits modified. This is “little picture” engineering, and you will only ever come up with a “legacy car” with some detail changes. If the
2. Very rarely will such a process adequately record and therefore keep all the good bits of the original design. We feel the “wrong” much more acutely than we feel the “right”.

In my time at RMIT, I saw about twenty different pedal trays designed. Every year, some new guy would come along and “design” a new pedal tray. Every year, the process would be – find fault in the old pedal tray (not light enough, not stiff enough, motion ratios were wrong, load paths were all wrong, too hard to manufacture, too wide, too narrow, too steel, too un-carbon-fibrous). Every year we would have a new pedal tray presented to us which was “better” than the previous one, (it must be better, we took away some of the wrongness…). Every one was stiffer, lighter, cheaper, simpler, stronger, better than the one it replaced. The net result after all this progressive and incremental improvement, over about 20 iterations – a pedal tray that is worse than the one Baz designed way back in 2003. We made so much forward progress that we ended up going backwards.

The process is rather easy to understand of course. Dave designs a pedal tray to the best of his ability. Dave’s pedal tray has flexi-pedals and the driver hates it. The following year, the team is told we need a new pedal tray with stiffer pedals – the old ones were lousy. So Brian the new pedal tray designer focusses his attentions on new pedals. He identifies where the flex is coming from, makes stiffer pedals. With much fanfare the new pedal tray is released - but it is way complex and difficult to manufacture. The team learns that manufacturability is important, so Graham the next designer is told that he needs to fix the fault of difficulty to manufacture.

See the pattern? Everyone sees the faults and points them out, no-one really jumps out of their skin to proclaim the good. So the designers find themselves in this downward, constrictive negative thought cycle. If I bow my side impact protection bars to give them greater side impact resistance, that is wrong because they are not good for chassis stiffness. If I leave them straight, that is wrong because they will just buckle under side impact protection. If I do both, and weld a bowed tube to a straight tube, that is wrong because it is heavy. If I ask for advice, I am told that I need to figure it out for myself. So what does the designer do? Rather than risk being wrong, rather than draw the attention of the critics by doing something different, they take the line of least resistance and do what everyone else is doing. Result – lots of cars carefully designed to look the same as each other.

I liked Carroll Smith. I thought he was a cracker of a bloke, and I was fortunate enough to see him in action once back in 2002. From my short impression it seemed that he saw the good, and he saw the bad. And he pointed out both. He made you think, he often critiqued cars by asking questions (So you have a lot of camber gain here – what does that do under cornering? What about braking?). He would not spoon feed you, but he would guide you through a series of questions until you came to an understanding yourself. And if he saw something he liked,he pointed it out. Constructive criticism, but criticism that included positive encouragement too. It is something that I took into my teaching career.


Something that I find curious is that despite our displayed behavior and overt tendency to gravitate towards phase two critical / disputative thinking, we actually don’t really want to be there. When I look back on my time in FSAE, my fondest memories were of:
- Mateship (phase 3, collaborative)
- Dreaming up ideas for cars I wanted to build (phase 1, creative)
- Making stuff (primarily a combination of phase 1 creative and phase 3 collaborative)
- Checking out cool designs and chatting to the designers (a combination of phase 1 creative and phase 3 collaborative)
- Meeting a whole heap of cool people from around the world (a combination of phase 1 creative and phase 3 collaborative)
- Achieving stuff that the naysayers said we would never achieve (anti – phase 2)
- Summer nights having barbeques and shooting the breeze with a bunch of mates that you would do anything for.
- Laughing
And the things I hated:
- Team politics / divisiveness / bickering (phase 2 extending into anti-phase 3)
- Egos (phase 2 extending into anti-phase 3)
- Bureaucracy (which roughly means doggedly abiding by a set of rules implemented on a piece by piece basis from a firmly phase 2 mindset)

So what I think are my natural instincts are telling me that I want to be collaborative, and I want to be creative. Yet my education, the newspapers I read and the news and current affairs that I watch and all our politicians and lawyers and rulemakers want to operate in an almost exclusively fault-finding phase two mode.

Progress is about moving forward, it is not about not moving backwards. Life is an infinite bowl of jelly beans. Do you really want to spend your whole life picking out the black ones? Time spent avoiding the things you don’t like, by default, becomes time spent away from the things that you do like too.

When I get to the end of this life, I want to reflect on my contribution to this world in terms of what I created and achieved – not in terms of the number of undesirable things I managed to avoid. The latter firmly focusses your mind in the confining and the negative, and negative you will become.

So I end my chapter today on positive thinking with a double negative. I obviously need to work on this….

[Loz]

Geoff/Others

In defence of the "critical/fault-finding" or analytical phase/s of the engineering process, it is important that the contribution of critical/analytical phases be recognised to occur more than once throughout the process. The role of critiquing or "fault-finding" and its placement in the problem solving process should really be a free variable. i.e. it can occur at different times and can contribute in different ways which aren't necessarily anti-collaborative/creative. It is also a recurring function that is necessary in an iterative design process.

For example, in the early stages of the problem definition and concept generation (and independently of creative pursuits like brainstorming ideas etc), it is necessary to do a "first pass" critique with fundamental analysis tools (e.g. math about the physical world) to establish some loose boundaries which effectively act as known's until proven otherwise. Newtonian fundamentals are well placed here. Even though limits or boundaries may be generated which are seemingly creativity killers, they only serve such a purpose if the mentality applied when the analyses are conducted is as such. This is where the psychology of a typical engineer can certainly stifle innovation. When providing an engineering solution to a problem, it is always necessary to impose limits reduce the solution space to a manageable region. It is simply part of engineering. Even though it is not specifically a "fault-finding" activity, it can (and mostly does) place physiological limits and constraints on creativity and collaboration in a similar fashion to implementing a purely "fault-finding" design process.

HOWEVER (big however), it is the engineers discretion which determines how this feeds into the process and what it means to the successive solution trail. Just like in the general scientific field, limits are only limits based on the scope of currently available information and knowledge with some level of certainty (or uncertainty as is usually quantified). It is an understanding of the currently known limits which often provide the greatest opportunity for creativity [Note: This is especially the case for engineering minds which usually struggle to be purely creative]. It is well spelled out in your "Reasoning..." thread, the limits and boundaries imposed by a set of rules can be (or should be) perceived as opportunities to pursue something that might be unorthodox (often also referred to as innovation, creativity or thinking "outside-of-the-square"). If the engineer chooses, this process of seeking the limitations through a critical process can in fact increase creative possibilities and expand the solution space if some time is taken to understand what the imposed limits really mean.

The opportunity for expanding creativity occurs again in the middle stages where the analytical (selection) process often occurs. The second phase you speak of (the critical analysis) is used to prune the solution tree and determine which is the best fit to the problem. This doesn't have to be a one shot process (and I'm not suggesting that was your contention), but it often does proceed this way. In more recent times this has become worse as we (as an engineering collective) become more incautious about accepting as truth anything that has an absolute value attached to it, especially anything from a simulation (e.g. becoming less reluctant to question the validity or accuracy of a result that a numerical simulation spits out). This critical/analytical phase should provide a second opportunity for expanding creativity by understanding the facets which prevented (or limited) the other "less ideal" solutions from from being selected as the "best fit". Point 2 and 3 below really need to be (and should be) part of an iterative procedure (and one of multiple iterative loops in the FSAE design process).

BRINGING IT BACK TO FSAE
So what are the objectives in Formula SAE:
1. Understand the problem (best done collaboratively)
2. Propose potential solutions (creative, expansive)
3. Analyze solutions to pick out the best one (critical,fault-finding)
4. Manufacture our solution (collaborative)
5. Refine our solution (collaborative)
6. Present our solution to the various judges, informing them of what we have learnt along the way, (collaborative)
In each of the above, we could potentially argue that each of the three mind states can be useful - however I have chosen to present the most prominent state.

It is frequently recognised that it's often the "ignorant" who generate the most innovative solutions as they are free of prejudice with an unbounded thought process, thus promoting limitless creativity (often referred to as the antonym of an engineering mind). How we perceive the limits established during the critical phase is again at the discretion of the engineer to choose. They can be absolute and deterministic and the process is generally more "negative", or they can be key pieces of information which provides a first step to exploiting the the limits imposed allowing further creative thinking (i.e. more "positive"). It is this part of being critical and developing an understanding of the imperfections or limits of "inferior" solutions which allows one of my favoured activities (as you put it in Post #1) "Achieving stuff that the naysayers said we would never achieve (anti – phase 2)".
However, this only happens if the the critical and fault-finding activities are performed in the more "positive" sense with an acceptance that very few things are actually absolute, almost all solutions have value and/or feasible components that can harnessed.

As in Chapter 2 of the thesis,

Accepting that we need critical thinking / fault finding to be part of our process (but not all of it), how do we engage in the fault finding process (dispute) without it being a tug of war? How can we do it with the least usage of time, energy and resources?
1. Be honest with each other – don’t sugar coat stuff, and don’t put spin on your argument to favour your own favoured solution. If an engineer proposes a certain design solution and refuses to see any fault in it – sack them. If an engineer looks at someone else’s design solution and refuses to see any good in it – sack them. If the whole team knows they can trust each other to offer unbiased, honest information to melting pot – then the layer of complexity and wasted time attributed to breaking through sales spin is averted
2. Be critical – yep, point out what you see as wrong. And if someone finds fault in your critique – listen to that too and see if it makes sense. Ask yourself what you can learn from their perspective on this – rather than get all defensive and feel the need to prove them wrong.
3. Be encouraging – point out the good as well as the not-so-good
4. Be dispassionate about the product – we are building a self-propelled protective chair. Don’t be precious
5. Be mathematical – use numbers wherever possible to decide an argument for you. Don’t under any circumstances fudge the numbers, otherwise point #1 above flies out the window
6. Be thorough – make sure your mathematical analysis is comprehensive but appropriate
7. Be realistic – don’t expect you will solve all the FSAE problems in one year. Know when to say enough
8. Be humble – don’t get all precious if you don’t get the answer you like. You are an engineer. You don’t like. You do.
9. Be team focused – the team helps you to achieve things to a much grander scale than what you can achieve on your own. You would not have this opportunity without your team. Live for the team. Not yourself.
10. Be results focused – Your tasks as a team are to gather competition points, encourage new students to come to your uni, promote your university’s name, secure resources for your project and future projects. Know your objectives, and measure your success in terms of them. Don’t get bogged in petty arguments and don’t shift the goalposts as you go along. Set a deliverable plan, deliver on it.
11. Move on – when the design is frozen, and the disputing stage is done – stop your whinging and move on. Sure, keep an eye out for unforeseen faults, but do everything you can to be collaborative to deliver on that final product.

All of this is is necessary. In addition, it is important to recognise that the activities which are connected to the critical/fault-finding process can (or should be) dispersed among other more positive and collaborative phases. Even though they might be implicitly "negative" activities, the output can perceived to be positive and then used to progress the broader "positive" process. Thus as an extension to the list, there should be a point that addresses the need to not solely be critical for the sake of fault-finding but to support an iterative feedback loop which reinvigourates creativity having outcomes which are used for good and not evil. It doesn't have to be a bad thing for the critical phase to creep into creative phase. In a non-sequential design process such as FSAE where it is necessary to "Design it. Build it. Break it." (Pearson, n.d.), there are many times when a good critique is the most positive thing that can occur.

Loz

[Big Bird]

Nice one, Loz. What a well written and considered response. Thank you!

I'll take a day or so to get back to this - but I will get back to it.

Cheers!

Geoff

[Big Bird]

I’m not going to be too verbose here. Loz, I fully agree that a critical eye needs to follow the whole project. My concern, though, is that a lot of engineers that I have worked with are not too flash when it comes to the discretion you speak of. Their first response is one of finding the wrong – and then there is not much else after that.

Engineering has a culture about it that is firmly founded in pointing out the wrong. I live in a country that no longer has an automotive industry, despite the talent we have here. A lot of this is due to the fact that the industry refused to change despite imminent threats – because there was always a reason to not change.

It takes a brave soul to stand before a team of arguing engineers and broker an action plan. Especially if the action plan is NOT “Let’s just keep doing what we have always done”.

My thesis above is an attempt to break a few minds into being a bit more positive and adventurous. Because to be quite honest, for a competition that is meant to be about fostering creativity, there are a lot of very similar looking cars out there. Where is the next UWA???

Cheers all. Would be glad for a few more to chime in, it feels like I'm talking mostly to myself here...

[Loz]

I agree and and share the concerns. It is apparent everyday that the culture of modern day problem solving continues is trending towards methods which are highly conducive to impeding the the process of finding a solution (especially in the case of engineers).
Without grumbling too much, the plethora of bits and bytes floating around the intrawebs and the "Google generation's" tendency to absorb any and all of it as verbatim truth, is not assisting the matter. I could grumble about schools and education, but Z could do that far better than me...

It would be great to see a team work though the process without once consulting a digital reference, or at least staying away from such external influences until the point of manufacture. It is impossible to remain free of bias as everything which comes before necessarily shapes the future. However, I think it would serve a team well to employ a strategy which was specifically implemented to mitigate creativity constraints to the problem solving process. Part of which would likely be a far greater emphasis on the use of "traditional" tools like logic, reasoning, geometric constructs, proofs (not necessarily mathematical and could certainly be physical e.g. testing) etc.

Perhaps one way would be to treat the first team meeting of the year like an AA meeting where everyone sits down, is honest and admits they have certain biases, fixations and a cache of "old dog" tricks that will be hard to unlearn and they have no control over them. Once everyone's compulsions and addictions are out in the open, all of the contributing substances are locked away and the steps are put in place to prevent the habits from perpetuating.

In the same vein as the twelve step program, the first step to freeing the mind comes from admission that it is constrained.

Loz

[Jay Lawrence]

^ what a great metaphor!

Personally, we had (and still have) some very creative minds on the team (myself not really among them. I am, somewhat sadly, better at criticising rather than creating). Unfortunately the arrogance of some with the creative mindset caused them to either not see the flaws or not accept any criticism (their projects often causing massive headaches for the team). A mixture of creative, rational and critical brains should be a perfect mix for this project, but the 'authority' levels and influences don't always match up. I would say that this is the biggest cause of teams being unable to be consistently high performers.

My 2c

[Z]

Would be glad for a few more to chime in, it feels like I'm talking mostly to myself here...

Geoff,

Thanks for your words so far. This is a subject I feel strongly about, so you can expect a looong post in a few days...

Unfortunately, I am a bit busy feeding the chooks right now. Many, many chooks to feed...

Z