Acronyms

Today we talk about what design work is like in industry and spend a lot of time on the importance of FMEA.

Creators and Guests

Producer

Michael Crocco

Engineer and Educator. AI in Engineering innovator.

What is Ctrl+Alt+Engineer?

A podcast for mechanical engineers beginning their studies in Design.

(Music)

but not exclusively towards

my students in design one.

Um, so today we're going to talk to, uh,

we want to talk about

industry a little bit more heavily.

Um, and want to talk about, want to start

off with how does, um, university sort of

prepare you for industry.

So what kinds of units really sort of

mimic what's going on in

and around the universe.

Um, so Mike, you've been in and around

the university system as, um, a staff

member here at a university for what?

Seven years, seven years.

Yep.

Yeah.

And you have a unique perspective because

you work for the faculty rather than a

department, whereas I'm

working for a department.

So I'm, I, I teach almost

exclusively design units.

So I teach the kinds of units where

problem-based learning is

well, and truly ingrained.

It's well known to work

really well for students.

Um, although it is slightly artificial,

we can't do everything the way we'd

normally want to try and do it in

industry per se, but we

do our very best for that.

Are there any other units that you've

noticed that sort of

have that kind of impact?

Oh, you're putting me on the spot.

Um, any other units other than design,

it's funny, it depends on what your

definition of design is, right?

And that is very much a discipline

specific, uh, definition in part.

Um, and, uh, of course, the phase that

students are in at a given, you know, uh,

like whether they're first, second,

third, or fourth year, or, or

postgraduate really

contributes, I think to that as well.

Um, so maybe my simple answer is that,

yeah, a lot of those

units are design units.

The intent of those is that they do

replicate, um, uh, industry practice, at

least try to in

microcosm or, or whatever.

Um, but then the, the

gambit, uh, is that a word?

Of, of different types of

design units is quite large.

Like, as you know, um, from experience

with final year design versus second year

design, and then projecting back into

first year design, those are very

different, uh, beasts.

And then master's design sort of, uh,

because I've taught into master's design,

master's design kind of opens up to, like

you said, the different, the different

disciplines and what sort of constrained

or defined as design and the real

worldness of those sorts of things.

So, um, I'm going to pick on civil

engineering, not because they're bad or

anything, but thing that I found

fascinating the first time I taught that

was when you're talking about design and

the integration of diversity in teams

from a civil perspective, if you're

looking at a site, then they want to have

traffic management engineers and they

want to have people who are doing

structural engineering work and they want

to have environmental.

So within civil engineering, because the

scope of civil engineering is so large,

they have a lot more diversity than what

we might have in mechanical, even though

in my units, like my earlier units, we

would have mechanical students, robotics,

mechatronics students and aeronautical

students, but civil engineering have that

broader and bigger diversity throughout

their entirety of their degree.

I think so.

I, you know, I'll bring up somebody who,

who, I won't bring the person up, I

guess, but I'll make reference to someone

I know who argues very strongly, that,

you know, structural engineering is not

the same as what a lot of people think of

as civil engineering.

Now, Kathy, I always think of structural

engineering as that's what civil

engineering is, but I'm

actually wrong, right?

That's just my

experience, my exposure to it.

The only civil engineering I really did

other than a bit of soils and things like

that was structural engineering.

Absolutely.

But, you know, they actually have their

own designation depending on what

jurisdiction you're in, things like that.

So yeah, absolutely.

And, and what you just mentioned,

actually kind of raises something that we

were discussing the other day is

the advent of data centers being so

prevalent in, you know, in engineering

right now, that data center, I guess,

infrastructure development, all the rest

of it, that that's a great project for a

civil engineering student because you get

to see all aspects of civil engineering.

And what we're talking about is, you

know, the energy aspect, the

transport aspect, structural,

there's water involved,

all these kinds of things.

Sorry.

What a large component of civil

engineering, actually, but like your

ability to deal with water has, you know,

there's almost no crossover into dealing

with, let's say,

structural steel or something.

No, definitely not.

Completely different.

And so different disciplines, right?

Yeah.

So, I mean, you know, your original

question about, are there other units

that are, that are doing this?

I mean, yes.

But we do tend to separate into, let's

say, there are units or courses,

depending on where you're coming from

that deal with

fundamental technical aspects.

Yeah.

There's design units.

And then there are those other kind of

experience based or, you know, industry

exposure based sort of

units and courses, I guess.

And that's probably the answer to your

question is yes, there are some.

And they tend to be in that, that

experience, working in a greater practice

or working in a learning.

Professional sort of professional side of

things, as opposed to the sort of nuts

and bolts as to how

engineering kind of works.

Yeah.

Because what does an engineer do?

I don't know.

Let's go with 60% of the

time, maybe 70 or 80% of the time.

Possibly 99% of the time is not

engineering stuff, but it's well, not

direct design engineering stuff, but it's

all the things related to it.

It's not, it's not the

down and dirty mathematics.

It's not sitting there with stuff.

A lot of what we do is communicating and

managing data and documentation and all

of those sorts of things.

And this is where a lot of students who

come to us go, Oh, I decided engineering

was right for me because I'm good at math

and I'm good at science and English is,

it's there, but it's not, you know, it's

not my, it's not where

I feel most comfortable.

But as you sort of grow into your

engineering, it is one of those things

that you go, actually, there was a bit

that was in my, you know, my high school

English classes that's really sort of

propelled me and really helped with that.

We talked to students a lot about

narratives of, of reports and stuff and

just how important that sort

of training has been for them.

But I mean, those aspects emerge in a

design curriculum though too, right?

Just because they're not, I mean, I don't

mean to, to silo everything here.

There are certainly units that are

focused on professional attributes and

things like that, which don't involve

design, for example.

But I don't think you can go through a

design unit, of course, without dealing

with some of those aspects.

No, I think you have to deal with it.

At least I hope you can.

Agreed.

I think that they sort of, they come up

in, in smaller ways, but

they still come up within that.

I think because most of the project-based

learning that we do, we never actually

work as siloed engineers.

It's very rare for an engineer to be

locked in a corner or in a room or at a

desk and just work by themselves.

They may have part of a project that

they're kind of working on independently,

but the majority of that then sort of

feeds back into a much bigger team.

I mean, you said smaller ways.

I mean,

yeah, maybe smaller ways in terms of

assessment balance, but perhaps even more

significantly in terms of

just getting through the work.

Yeah.

I mean, looking at your students,

how are they going to do it without

talking to each other on a regular basis?

Yeah.

Dealing with friction on teams,

you know, trying to communicate your

ideas when it's difficult to do because

you're a novice, you know, all these

kinds of things contribute a lot.

I was saying this to another colleague of

ours, even as recently as today, someone

said, it's really hard when you go past a

design unit, because a lot of the

students will be standing around talking.

And I said, yeah, but what they're doing

is really, really important because you

can't be creative unless you can actually

be yourself and you can't, and you feel

some sense of security around the fact

that your ideas aren't going to be

trashed and they

might be, and that's fine.

You mentioned creative.

Yeah, I know.

I'm going to pick up on that in a second,

but please finish your thought.

But you can't, you can't

be a creative engineer.

You can't bring forth ideas if you don't

feel safe and you

don't know those people.

If you've ever seen a brand new group, a

team together, then

they're very, very silent.

And it's building those connections that

allows you to interact with each other.

In a safe and meaningful way.

So to creativity, I know you're normally

the one who asks me questions to, to

progress the conversation, but I'm going

to reverse roles here for a second.

What in your view does creativity

contribute in the

engineering design process?

Ah, I think that creativity is one of

those very, very underrated things.

But I also want to clarify what I mean by

creativity in an engineering sense.

So lots of people think that creativity

is creating something brand new that's

never been done before.

Whereas I found that being a creative

engineer is taking things that have

already been done and

applying them in different ways.

So looking at the world around you and

the more you can sort of look at the

world around you and

pick up, how does that work?

Oh, that's a really interesting hinge.

Is that a friction hinge here?

How does, how does that work?

You know, what's going on there?

Why do they use a dovetail

joint in a set of drawers?

Like I'm talking innate, seemingly

unconnected engineering things, but they

all have engineering applications that

you can then utilize in different ways.

Well, here's a good example.

The Shinkansen in Japan that was creating

like the sonic boom when

they were going through tunnels,

and then they found a way to style the

nose, you know, or shape the nose in such

a way that it didn't do that.

That came from- The

inspiration from that was-

Biomimicry, right?

That was Kingfisher's, I

believe, from recollection.

I read a similar article.

That was creative, right?

But it wasn't creating something new.

It was, like you say, identifying that

there are other sources of information

out there, there's other

inspiration and things like that.

And I guess, I mean, you know, cause what

I was driving at is, well, how does

engineering differ from art?

If they're both creative pursuits, then,

you know, let's compare and

contrast along those lines,

mimicking biological process in art is

creative as well, right?

And there's plenty of that.

Totally.

And yet they are different, right?

And I think we can

acknowledge that it's very different.

And I guess I want to go to the, like,

okay, let's not just talk about art, but

let's talk about design, be it industrial

design or, I don't know, website design

and human interface

design and engineering design.

Because we use the same word and I'm

going to pause it that it's actually a

very different thing, right?

I think it is.

Yes.

It's not,

there are elements of

design in engineering,

but there's little to know.

There's far less engineering design in

other aspects of design, I guess.

Yes.

I think with confidence.

I think what you're trying to allude to

is that with engineering design, it's not

so much create something from nothing.

It's take your technical prowess and

knowledge and what you've seen in the

world and utilize that

into a different scenario.

Whereas I think that when you

talk about artistic endeavors,

someone will start with a slab of clay or

a blank canvas or a bunch of supplies

that they then construct into something

that hasn't been seen before.

Or a thing that they want to do.

Or a thing they want to do.

As opposed to a thing

that they have to do.

Now I know that that's a simplification

of artistic process.

But anyway, I guess I want to touch on

the fact that, you know, I studied design

a bit in university and then my first job

out of university was as a designer.

And not a lot of my colleagues, in part

because of where I lived and things like

that, had design jobs straight away.

They were doing other things.

But I went and worked a big automotive

manufacturer doing design and I was told

I'd be doing design.

And it was not at all

what I kind of expected.

Right.

I mean, to some degree, yes.

But I was generally creating drawings and

by that, I mean churning out drawings and

drawings that were 10% visual and maybe

90% informational, something like that.

And then...

Whereas an artistic endeavor would be the

exact opposite of that.

Yeah, exactly right.

So you know, 90% artistic endeavor and

10% information, maybe.

And then I eventually worked for another

automotive company where I was a designer

and I did even less, let's call it

design, as in creative process of coming

up with a solution to a

problem and things like that.

And a lot of it was, let's make sure, I

don't want to overgeneralize, but a lot

of it is let's make sure that our current

ideas are not going to fail, right?

Yeah.

And that they're going to continue to

meet specification or targets or things

like that, or we might change the target

by a small percent this year and we have

to make minor modifications.

And I think that, you know, in general,

that's what a lot of design actually is.

Right.

It's, it's, it's rare that you're working

at a startup that's coming up with a new

thing, albeit there are people who do

that clearly, but a lot of engineering

design is going through the paces and the

process of making sure that things aren't

going to fail while

still meeting their targets.

But even in those startup situations,

you're also having to...

You still have that responsibility.

So you might have more of what you would

deem design in there.

Excuse me.

Sorry.

It's late and it's Friday.

You would still have aspects of what you

would consider design to be in the

processes that you're having as an

engineer, but you still have to make sure

that is it manufacturable?

Is it going to be fit for purpose?

So all of these problems that, or surface

level, or not even surface level, but

very deep diving engineering things that you might want to do, but you still have

to be figuring things that

you would be thinking about.

Is it going to vibrate itself to pieces?

Is it going to cope with heat?

Is it, you know, are we, are

we dropping it in the ocean?

Like where are we putting it?

That sort of thing.

I guess I think of, you know, our

curriculum here at this institution and

we, we, if we look across four years of

design for a mechanical

engineer, for example,

you know, first year introduction, second

year three and fourth level, I think that

we transition from the purely creative to

the more balanced toward what engineering

design generally is on a day to day

basis, which is those things that you

were just mentioning.

I think we do do that

reasonably effectively.

There's like a gradient there,

I suppose, and a rebalancing.

And by the time you're exiting,

you know, the scope of your design, your

designed parts is small, let's say, but

the breadth is narrow and

the depth is much deeper.

Right.

I think that's, I think that's accurate.

And I think that the thing that a lot of

students who are coming into second year,

it's we, we don't give you all of the

technical sort of

elements before beforehand.

We get you to very much sit within that.

Yes, I can do this.

I can solve this problem.

And we do that for a number of reasons.

Number one, it's, it's kind of fun.

And, and that's, that's an aspect too.

It's like sometimes to do a design where

you have to stop, think about everything

and make work out every single detail

before you even start can be really,

really challenging, especially if you're

feeling that you don't necessarily have

all of the technical capabilities yet,

which is why we sort of add that you've

got this, give it a go.

Try early, fail early, pivot well, keep

going, you talk to someone about it.

And again, it's that

communication aspect too.

Yeah,

I think there's a lot about, well, I

don't know, for myself, a lot of that

once I went into industry was about

finding confidence in my own process.

Yeah, I was gonna say creative process,

but it's not just not a purely creative

one, but the process of just approaching

a design and and I was lucky enough to

have in my second role at a uni have one

that where I was kind of

given the time to make mistakes.

Certainly my first job, there

was no time to make mistakes.

And so you had to rely on weird

structures within the company.

But then I ran my own new product

development department after that.

And it was, you know, the

timescales were relaxed enough.

Yeah, you know, they could do that.

And so that's something that I didn't

personally have at university.

But I think we are

offering to some degree.

And I think we've alluded

to this in previous episodes.

But yeah, go ahead.

And it's okay to fail.

And we've had a lot of discussion before.

But the thing that I did want to raise

with you here is one of the things that

students really sort of

struggle with is diversity.

We talk about a lot of diversity within

teams and having different opinions and

different thoughts and not letting one

person sort of take over.

Let's take let's pause for a second.

Sorry.

Define diversity in this.

Ah, yeah, diversity in

this context, different ideas.

I was gonna say at university, though, we

can sort of constrained.

So in my second year unit where I do have

students who are who are choosing to do

different streams, so

mechatronics, robotics,

robotics, mechatronics, mechanical and

aerospace, we try and mix up which

disciplines the students

are going to come from.

And, you know, their cultural backgrounds

and all that sort of stuff.

But that's not what we talk about

diversity in industry, is it?

So when we're talking about teams and

diversity and having different people

look at design, because lots of different

people look at you design when you're in

industry, what's

diversity look like out there?

Well, I mean, there is though there are

sorry, there are those aspects of

diversity that you've just mentioned,

diversity of background and diversity of,

you know, race and sex

and all those things.

But then there's

diversity of like priority.

Right.

I think that's maybe what

that's what you're getting.

Yeah, absolutely.

And I guess I'm going to draw on an

experience that I had of doing design

related documentation, very important

design related documentation when

involving kind of

everybody in the company.

Right.

So we had our engineering office with I

don't know there were 10 of us or so in

there, but there's 75

people in the company.

And so most people are not an engineer.

Yeah, everybody's got some kind of, I

don't know, skin in the

game or some, you know,

they're attached to that project somehow,

be they from finance, or, you know, the

dispatch desk or manufacturing side or

the warehouse or, you know, whatever that

logistics, that kind of thing.

And we did a process

involving all those people.

And again, it is an engineering document.

It's an engineering

process, but we involved everybody.

And that was quite valuable.

It was,

were they cranking out the

majority of the work for that?

Well, maybe not.

But they had certainly had contributions.

And that was that was really interesting

to observe, I guess.

And this is when I was a reasonably young

engineer and got a chance to see this and

found it actually quite valuable.

Yeah, I was going to say, part of my

experience when I worked at Defence

Material Organisation, we did a tender

evaluation process for a project that's

still ongoing called

Project Overlander 121.

And we had people from logistics, people

from finance, people from engineering.

And engineering was split into, I think,

about 10 or 15 different areas.

We had three different vehicle classes we

were looking at and then people had their

specialisation within those.

But then we also had a

human factors related part.

And we had all sorts of, you know, how it

was going to be delivered, how wasn't it

going to be delivered, what kind of

spares would we need, etc, etc.

To sort of give a greater overview and

greater sight as to what the end product

would look like and how that would

function within a military aspect.

And I'm not even

talking about deploying that.

I'm just talking about

having the thing there.

Yeah.

So testing, etc, etc.

So and I think this is what's really

interesting is that when you start to be

involved with people from different,

different discipline areas, as in, you

know, across companies,

you start to see that, like you said,

people have different reasons for for

interjecting with those that we don't

necessarily think about.

But that diversity is

really, really valuable.

One of the processes that quite often

happens and it came out of the Challenger

disaster, forgive me if I'm wrong for

this, but it's used a lot by the

automotive industry is called failure

mode and event analysis.

And that's a particular form of

documentation that we don't have time to

teach, but is done a lot in engineering.

Yeah, failure mode and event analysis.

Oh, no.

Failure mode and effects analysis.

But I've heard it called

so many different things.

And I think I mentioned you in the past

that at both Honda and Toyota, we had a

completely different

listening word called DRB FM.

And don't ask me to tell

you what exactly it means.

But it doesn't matter.

It's still the same document.

And this is like you and I, I think feel

very strongly that it's a

very, very important document.

And guess what?

So do the courts.

Yeah.

And this is the thing.

This is why I raised the Challenger

incident, because the process of going

through this particular documentation was

the reason why the organisation that had

built that rocket was not

prosecuted for that failure.

Yeah.

Because they could show that they had

done everything in their power to prevent

that from happening.

And they'd done an analysis as to what

the risk was and how that might fail.

And this is a really interesting point

for me, in part because my background,

but in part just because I find all this

stuff interesting, where, you know, law

and engineering meet, right?

Yeah.

So we have, you know, there's terms in

law about like, you know, would a

reasonable person expect and that like,

this is the kind of

standards to which things are judged.

And the same applies to FMEA, where it's,

you know, would a reasonable person, what

would a reasonable person with

appropriate knowledge expect to do as a

countermeasure or as a

design in this particular case?

And then you're documenting that, right?

Yeah.

At least that's the way I like to talk.

But also, how can you, how can you stop

what, what a reasonable person might do?

So how can you prevent them from putting

their finger in an electric, you know,

into a PowerPoint, for example?

And I know that that's very, very basic.

But how can you mitigate

that so that they won't do that?

And of course, then that ends up in

hierarchy of control

and that sort of thing.

But then these are all things that we

sort of stop and think about.

And this is the kind of thing that we

really do utilize in industry where we

pull in people from all kinds of

different areas and backgrounds.

So there's an aspect of risk analysis,

sort of documentation.

But I would say that

it's more than that, right?

It is more than that.

It's not just can you identify risks.

It's can you identify risks and can you

put engineering controls in place?

And then can you reevaluate

the risk after that is done?

And then can you adapt to new risks as

they arise and absorb those or

countermeasure those

and things like that?

It's like, I mean,

it's a document.

It's a living document.

People think that you

do it once and it's done.

And that's that way you're safe.

It's not not the case.

You have to keep addressing these things.

But it should tell the story and explain

to me or to any reader of it that you've

thought of everything, essentially.

And that's kind of the role of an

engineer is to make sure that they've

thought of absolutely everything.

And within the statistical norms of the

universe accounted for all those

potential, not just dangers, but but

failures of of specification and failure

of of structural integrity.

And a

failure doesn't mean that someone's going

to be injured or hurt.

Sometimes a failure is just that a

product is no longer fit for purpose.

And that's also something that as an

engineer, we're trying to avoid.

We're not talking

about design obsolescence.

Yeah, that's off the table.

Yeah, I don't like that either.

No.

And most engineers will feel that way.

And it's but going back to FMEA for a

second, it's the one thing I would love

to be able to have room to teach.

But it's really, really difficult with

the short amounts of

time frame that we have.

Well, and there's a risk

of not doing it adequately.

Correct.

With under experienced

or under motivated people.

And you wouldn't want to communicate that

is less important than it is.

So yeah, it's that, you know, I'm in two

minds about this as to whether or not we

should address it in university.

And I think we should introduce it, but

make it clear that it's an

introduction sort of thing.

So we don't, you know,

make people too complacent

around it and things like that.

But it would be good, I

think, to have some idea around.

I think the hardest part, though, is like

you said, it's it's not a one and done.

It's not you've done it once and

therefore you never

have to look at it again.

And I think this is where we would

struggle is because 12 weeks doesn't 12

weeks, 12 weeks when you're a second year

student, it seems like forever away.

But when you know the older you get, the

faster 12 weeks sort of travels.

Isn't it just the beginning of semester?

That's how it feels.

But, you know, you can

do a targeted one, right?

You can you can say, this is

a part of a larger document.

Why don't you focus on this and let's

really do this part

to death, essentially.

And, you know, we're talking about

breadth and depth before, so maybe you

could go really deep on one aspect of it.

That kind of thing.

You know, you

mentioned I you mentioned FMEA.

I tried to say FMEA before, but I almost

put the D before it.

Because there are two

clear camps around FMEA, right?

Not camps, I shouldn't say, but two clear

documents, which is D FMEA.

Yes.

And P FMEA.

Yes.

And so what do those stand for?

Well, D stands for design and P stands

for production production.

It is production and

production or product.

And here's something that we kind of tend

to we've neglected in

this conversation, certainly.

But I mean, how many engineers out there

are not design engineers,

but production engineers?

And therefore use P FMEA all the time.

All the time.

How many design engineers have to prepare

for production and therefore are involved

in the P FMEA process?

And, you know, then we get into that kind

of to and fro between the design office

and the and the factory.

The production office, yeah.

And yeah, that's it.

Like, what a great way to hand all that

over to write is through these documents,

which are, again, living and, you know,

participated in by all parties.

So just going back to that that idea of

two different engineering camps.

I shouldn't say camps.

No, that's not fair.

But two different engineering streams and

ideologies within one organisation.

Because design engineers do designs of

the product or the end thing that the

company is going to produce.

But a production engineer is the person

who designs how that's going to happen.

So they quite often have to take that

design and then turn it inside out.

Yeah.

You're dealing at the moment with an

organisation and dealing with production

tools and that sort of thing.

So you're looking at cavities within

metal, still called a tool.

And so it's really interesting.

The if you ever get a chance to see it

again, it's not something that we're

probably going to very deeply, but there

is two different camps quite often in a

manufacturing organisation where it's

design in one camp or in one office and

production in another office.

The difficulty is is that because they're

in different offices and they have

different roles within the organisation,

those communication between those two

groups is super, super critical.

Well, yeah.

And it's probably poorly done in so many

instances too, right?

And it's something that requires a lot of

effort because the time

frames, the schedule, etc.

And the kind of daily

distractions are so different.

And it's really hard to get those groups

together because when design is ready to

talk, production isn't and vice versa.

And I think those two groups are really

hard to get together.

But of course, it's really important.

We had the companies I worked in, we were

either I was either in a place where we

were right on top of production, like

literally in the mezzanine above the

production floor, which is really common,

at least where I'm from.

Drop things downstairs.

And that was important.

That was something I learned early on.

And then when we got to larger companies

where you might be

separated by miles or kilometres,

really organised points of

contact and events, I guess.

To drive that interaction

because it's so, so important.

And so one of my like,

what am I hitting at?

It's like, well, how much do you know, we

say we don't do

enough DFMEA in university.

How much PFMEA do we do?

And who does that?

Are you aware of anybody, I guess?

I haven't seen anyone doing PFMEA.

I'm I don't think I'm even aware of some

of anybody who's doing FMEA.

Yeah. Or if they are, it's

very lightly touched on.

So a corollary would be

we learn a lot of CAD.

Yes.

And who learns CAM?

Computer Aided Manufacturing.

Yeah.

There's some of it there, right?

Yes.

So we do we do a couple of weeks of it in

at this institution.

We do that in fourth year.

And then mechanical students.

That's kind of those two sides, right?

But it's but that's a very narrow aspect

of production, right?

Yeah, because you have nothing to do with

volume production or that.

In saying that, I mean, I did do a lot of

production engineering as

a design engineer, right?

Just because of the places I

worked and things like that.

And it was one of my favorite things to

do is to to go to generally Thailand to

go into the factory and to point out all

the things that they were doing wrong in

my view and how this is

going to be a problem.

This this is not something you've ever

gained any kind of joy

out of anywhere else.

No, no, of course not.

But it and there was, you know, another

again, look, I didn't even plan this to

talk about this, but there was my

diversity of experience where I was

versed in the production facilities in

Japan, and then we'll go into Thailand

and there are a lot of differences.

But I knew why certain things needed to

be aligned and why others didn't.

And so that diversity of opinion, you

know, you've got many, many dozens of

years of experience there in that

production facility.

But I know because my experience, what's

going to be a problem?

And I get to go in there and say, I know

you've been doing this for 20 years, but

you have to change this.

And here's the reason.

Anyway, and sometimes it's sometimes I go

back and do it again.

Fade to music.

What a great time that

was, though, honestly.

Yeah,

some people enjoy it.

Some people don't.

Yeah, I really enjoy it.

You know, it depends.

Yeah.

I again, I remember doing a time study

for an auto, an automotive supplier.

We're not talking

about whom or where or why.

And I said to the production engineer who

was in charge of the area, like, why does

that take three and a half

minutes to run a bead of glue?

And he's like, oh, we got

the top person in on that.

And I'm like, that's so slow.

Because I'd seen it done

in a different organization.

I'd done.

I'd seen something done very, very

similarly that was

done very more eloquently.

Yeah.

And I could actually add into that

because I'd seen

something very similar to that.

You've just struck on an interesting

aspect of production engineering, which

also involves design

engineering, but tact time.

Yes.

And what

is tact time?

Do you remember what it was called?

I mean, because I don't.

Yeah, it's like.

So the basic premise is that every single

operation has a specific time and you can

work out some things happen in parallel,

some things happen in series.

So one after the other concurrently.

And when something's happening in

parallel, those things that have to

happen in parallel, you need to have an

in the same sort of time frame or else

you end up with a bottleneck.

Yeah.

And that's what tact time is working out

is how long does something take and where

are your bottlenecks?

Where are the things

that take the extra time?

Basically in a factory, every time a

factory worker starts or repeats the

task, the interval between the

repetitions, you know, iteration one,

iteration two is that tact time.

And one of the greatest things I got to

do ever as a graduate engineer is spend

two weeks on the factory floor.

With a stopwatch?

No, no, no, doing the tasks.

Oh, cool.

So so, you know, we'd go in, we'd do like

a half hour at each

station sort of thing.

And so you work an eight hour day and you

do a half hour at each trying

to keep up with the tact time.

And only like I'll tell you,

it was quite something else.

If you cross thread the bolts when you're

fitting the bushing mounts for the

stabilizer bar on the

time to be like, you're out.

No, you have to fit within the tact time

and you have to back those bolts back

out, swap out from the socket to the tap,

re tap the hole with the same gun, take

the tap out, throw that in the bin of

bolts that you got there, grab another

bolt in the socket, find where you left

the socket and and drive the bolts.

Wow.

And, you know, I would like that was the

first station I ever worked on the one

I'm describing just there.

And so I would, you know, the person who

worked there would get would go really

fast for a while to get me right up to

the start, you know, and the other thing

is, you're like moving horizontally as

you're doing this because everything is

moving really, really slowly, but you've

got your little station,

your little boundaries on it.

And so I would start up at the front and

then buy like, I don't know, eight

iterations or something like that.

I was I was running into the

next person station, right?

And then the person who was overseeing my

work, whose station I was I was working

in, they would then get me back to the

front in about, you know, five or six

sort of goes, because they could work at

actually something like, you know, 80% or

70% of the attack time.

Yeah, attack time here, we're talking at

least a hono is in

the order of 45 seconds.

Yeah, it's fast.

And you are doing, you know, four or five

operations with, let's say, on the order

of nine to 10 fasteners

or something like that.

Yeah.

And inspecting a thing and then also

maybe torque checking something else that

somebody did up the line and then getting

the pen out and marking that like it's

it's it's it's it's why the demands on

factory workers are massive.

And but this is all to

make it profitable, right?

Correct.

And so you have to design a car.

This is my experience, not just that can

get down the road, not just that, you

know, is safe and doesn't fail and

doesn't rust and all these sorts of

things, but that somebody can manufacture

at an incredible pace.

Yes.

With using basic tools.

Now, this is something that I would

highly recommend to any person, whether

they be undergrad or

recent graduate, especially.

In fact, even someone as old as, oh,

well, maybe not as old as maybe it

definitely almost as old as you.

But if you get that opportunity, would

you agree that take it

like, oh, yeah, do the do this.

And even if it's only for two weeks,

like, you know, you find that your own

appreciation of what has to happen and go

into manufacturing skyrockets.

Yeah.

I mean, as a mechanical engineer, if

you're not seeking out those

opportunities, you

know, you really should.

Yeah.

I think I mentioned to you in the past

that, you know, before I was working in

the industry, as I was working through my

five years of degree, I worked at, among

other places, a

cigarette tube manufacturer.

And I still like remember every drum,

all, you know, 23 of them in a cigarette

manufacture machine.

We actually the factory I worked at, we

didn't actually manufacture cigarettes.

We manufactured cigarette tubes with the

filters included, but that there were

there was no tobacco in them.

Yeah.

But what an amazing time, you know, I

learned more about mechanical engineering

in that factory than I did throughout

five years of tuition, I think.

And I've worked factory lines.

You know, I grew up in

fruit growing country.

So you you are not a local if you haven't

worked at the local preserving company.

And there are two of them in the area.

And work at an old factory if you can,

because then you get to look at the cam

follower setups that do everything

instead of all these servo controls and

all that kind of stuff.

Now you're showing your

age, but they're fantastic.

I mean, if you don't get enjoyment of

that, again, like this

is what I'm getting at.

If you're studying mechanical engineering

and you don't find that fascinating,

maybe consider different disciplines.

Perhaps.

I would also point out that if you think

that engineering is or you think that the

right job for you is where you sit in an

office all day, don't do engineering.

Even though you probably will spend most

of your time in the office.

You'll spend a lot of time in the office,

but it should be one of those things that

you're going out and and seeing things

and looking at what's going in and around

you is really, really critical to your

growth as an engineer.

Cool.

That was a fun discussion.

It was.

I think we're done.

Now, I'm going to tell

you where we are today.

So we are currently in the Alan Finkel

building at Monash

University and we are in my office.

And I didn't think that we would be able

to cram everything we needed in here,

given that my office looks like a shovels

at the moment, but you've managed to make

it completely and

utterly, infinitely messier.

So thank you so much

for your time today, Mike.

No problem.

It was a

(Music)