Keeping an Eye on the Big Picture
 

Hello Everyone,

In my FRC experience, I've largely been a part of teams which discuss general robot design on kickoff, then go into intensive prototyping for 1-2 weeks, and then we start working on how to put the pieces together.

However, after reading the blogs of 1538 and 254, it appears that there is a group that keeps an eye on the bigger picture from day one via strong communication from the prototyping teams.

Now, my question is what does this oversight group look like? Is this group just simply the CAD group that's constantly trying to mesh various prototypes? Or is it a small group of CAD designers and leaders who are working with the prototype results/designs to move forward in the bigger picture?

If this group were to include team leaders and CAD team, do they convene and revisit the big picture after every major design revelation? At the end of every meeting?

Pretty much, how do you keep track of the big picture while you're prototyping?

- Sunny G.

Re: Keeping an Eye on the Big Picture
 

Good thread. We suffer from the same issues. We think we have a plan to deal with it this coming year, but we don't know if we can get it to work.

Re: Keeping an Eye on the Big Picture
 

Once a week we gather our team together and each sub group gives a 1-2 minute presentation about what they have been doing the past week, what they are working on now, and what they are going to need from other sub groups in the coming week.

This format allows the entire team to know what's going on in each of the groups, and gives them a chance to ask questions and voice concerns. It also helps get most of the bugs out especially when it comes to integration of all the different group's parts.

Re: Keeping an Eye on the Big Picture
 

My team is in a similar situation. We've taken a step back and are reconsidering and redefining our entire build structure and process with an effort towards focusing more on "engineering" a robot as opposed to "building" a robot.

I'd share more details, but frankly we haven't tested our process at all (other than lots and lots of discussions), but we're actually doing an entire "fall build" season in order to "retrain" the entire team towards our process.

As for the OP's specific situation/problem, my "80% crap" suggestion is that you probably (depending on the team size) need to get your "big picture" designers in a room with your prototyping people (my extrapolation from your post is that these are two distinct subsets in your team) and get a firm picture of where the team as a whole wants to go with the robot. From there break it down into what individual subsystems need to get prototypes and to what requirements those prototypes (and eventually final products) need to be built to. Be prepared to meet often-- the best way to avoid snags in my experience is to talk enough to the people involved that you're all on the same page but avoid talking so much that no work gets done.

Re: Keeping an Eye on the Big Picture
 

We have a mechanical director(me) who handles all of the coordination of the robot build. We start with a general picture of what we want the robot to look like based on our game strategy. This year we came up with a design almost exactly like 1986's robot. We then start prototyping while adjusting our original design based on our prototypes. This year by week 2 we realized a climber was out of our resources. Additionally, we thought that we could build an overall better robot by focusing on cycling, though we left an easy spot for our intake to attach(based on our prototypes). I coordinate this with the design team(which I also head). Design issues need to be dealt with in prototyping and then the new dimensions, design, etc needs to be dictated to the design team.

I recommend that this person is heavily involved in the design team. Designers tend to know the current design, design issues, dimensions needed, etc. In addition this person can coordinate with manufacturing and programming.

Re: Keeping an Eye on the Big Picture
 

Same situation on 2607. We fail grandly on this last year.

Re: Keeping an Eye on the Big Picture
 

Everything robot-related comes through me. It's not the best system, I'm sure, but it's the most effective one we've found. I am often overwhelmed by the amount of tasks that need attention.

I do what I can to keep the rest of the team informed about how things are progressing. I try to do a "state of the robot" discussion at the beginning of every other meeting or so that keeps everyone in the loop with respect to what we've learned, what decisions we've made, why, etc. Folks that are prototyping jump in during that discussion to talk about their progress as well.

Re: Keeping an Eye on the Big Picture
 

We use QFD, or quality function deployment, to boil down what is the necessary attributes & scoring opportunities versus the robot characteristics. Check out our web page and downloadable info:

http://www.theflyingtoasters.org/#!__qfd

This is usually done the monday night after kick off, and by the end we know what is the most important relationships needed to have a successful robot. Then our team goes to work prototyping, coming up with solutions, doing research, etc. and by the following week (the next monday) we check any solutions back to the QFD and rank them using the QFD. So in essence, the QFD becomes our anchor to keep the whole team focused and moving in the right direction.

The revision we are looking to incorporate this year in our QFD is the addition of of a "Probable Scoring Rate" that takes in consideration time versus point earned. We are still in the development stage on this aspect. Stay Tuned.

For those who do not know what QFD is, it is a way that major corporation use to address customer concerns, product details, manufacturing processes, etc. so that the end result is "built in quality" for the final product. Car companies have used this process to achieve JD Power & Associates awards and thus more market share (and customer satisfaction).

Re: Keeping an Eye on the Big Picture
 

So these are some good suggestions. I sort of attempted to fill this role on my team this past season. Now, I wasn't dictating design, but I was taking information from all the sub-teams and attempting to make sure things sync.

However, this approach can get messy. Like Madison, I was often bogged down and overwhelmed. Ultimately, I felt burnt out by the end of week 2. I also feel like this "overseer" role(s) should be shared between mentors and students. Now, that may be a slightly idealistic view of the role, but I believe the best solution ought to be a tactical collective between mentors and students.

- Sunny G.

Re: Keeping an Eye on the Big Picture
 

A very AGILE process. We use this at work when we develop major software projects. The only thing I would add is a brief meeting (15m or less) at the beginning of each meeting to discuss what teams are working on and if there are any roadblocks.

Re: Keeping an Eye on the Big Picture
 

Once a week didn't work for us when we tried it. There was so much progress in a week things were already out of hand.That's great for design, and for guiding design changes/decisions when things don't go well. But that's the design phase. Our "problem" is in the fabrication phase.

The real issue is that we have the concept and basic design set, but the details - precise dimensions for example - are determined empirically during fabrication. What we end up with is several subsystems that don't work well together, and design decisions from one sub-team that absolutely preclude many possible solutions for another sub-team's problems.

On the other hand, running everything through one person seems like an awful lot of work for that one person. My condolences Madison.

Our idea is to have a small committee of mentors and students take on the 'overseer' role. This way one 'entity' really knows what is really going on and can (hopefully) see and spot conflicts, while not being terribly overwhelming for one person.

We also see a far greater role for CAD. In the past, they were documenting designs after the fact. This year, if I see a CAD kid with a ruler in their hands, I'll know we failed. I hope to see a final design in CAD before the first piece of metal is cut. This gives me the most worry: I don't know if we are disciplined enough to do that.

I'll let you know if it works.

Re: Keeping an Eye on the Big Picture
 

What gives me worry is doing just that. Our final CAD design was not done until around week 5. We start cutting metal on Day 2, before CAD has even started, for certain parts we know we'll use no matter what the design ends up being (sprockets for instance).

If you wait to finish the CAD model before cutting any metal at all, you might have only a CAD model to compete with.

Re: Keeping an Eye on the Big Picture
 

We have a similar system. I keep tabs on everything and then it goes out to the team every night in the form of our build blog and an email to the team with more details than go out to public. This often includes a screenshot of the current CAD and pictures of prototypes. This is normally supplemented with discussions at the end of most build days during clean up with the core group of students that are normally around that late.

Re: Keeping an Eye on the Big Picture
 

We have an all hands meeting after a (usually delicious) pot-luck lunch every Saturday.

Each "squad" does a show and tell of what they are doing. A sketch of some kind of the total robot is drawn on the board. Conflicts and problems are talked out.

We try not to end the meeting until a new or updated plausible "total solution" has been agreed on. Sometimes there are parallel tracks. Needless to say, these solutions are fairly vague in the beginning, but get sharpened up and more detailed as time goes on.

Very often apparent conflicts get modeled in cardboard or something after the meeting.

Re: Keeping an Eye on the Big Picture
 

Appreciated. :) It's my own fault, of course. I am terrible and delegating tasks I think I can handle myself.

For 2014, there are a few students who are up to speed on CAD and have gained a lot of experience with design via past FRC seasons, running FTC teams and summer internships. If I am not the only one with access to and understanding of the CAD model, hopefully that means I'm not the only one who can answer questions about fit and function. Also, for the first time in more than a decade, I don't have a laptop. That means that I'll have to be more diligent about sharing the CAD data in the cloud so that I can pull it down at our lab.

Years ago, when I had more energy and more free time, I was able to prepare work packets in advance of each meeting that laid out, in detail, what needed to get done / which materials to use / what requirements to meet / etc. These days, I do that on the fly. That doesn't work as well.

I know there are lots of different methodologies for running FRC teams and they each have their merits. In my experience, though, most teams that build successful robots year after year have one person (or maybe a small handful) making decisions about how things will go together.

Re: Keeping an Eye on the Big Picture
 

In order to keep tabs on our design, we have design meetings often during "prototyping season". I think this part of our design process can be separated into two sections:

When the design is based on the prototypes
And when the prototypes are based on the design.

I know this year we came to one point where we came up with the basic design of how the robot would function.
Before that day, we had prototypes of all sorts of different shooters/hoppers/collectors. After that day, we knew our robot was going to have a linear hopper, we knew we'd be going with the roller collector, and we knew some other subsystems that would be necessary.
After that day, we prototyped better packaging for the shooter, a side belt to bring the discs up to the shooter from the collector, our hanger and hard stop, and how to lift and lower our tray.
After that one design meeting, we knew what each subsystem would have to do, and how it would have to be integrated. We also knew to no longer prototype the bucket hopper, and to no longer prototype the 180 degree shooter.

Re: Keeping an Eye on the Big Picture
 

Another thing that I find helps, is I try to keep the latest CAD model on the projector in the lab most of the time. That way people have a very good vision for what we are building and can see the changes on the fly if I happen to have time to work on it during a meeting. This also gives our students that don't know Solidworks a pretty good introduction since they can watch me work. We also share the CAD over Google drive so that all of the team has access to the same files.

Re: Keeping an Eye on the Big Picture
 

For the night by night, day by day management of build, the agile development method works quite well. While it was initially focused on software development processes, it can be modified and applied to all aspects of the build. I like to think of the Agile process as a bottom flowing up process. There needs to be a top flowing down process. Scrumming can be very effective but needs dedication by the entire team. It's easy during the craziness of build to loses focus and discipline.

Re: Keeping an Eye on the Big Picture
 

Madison, Allen (plus anyone else who has a similar process) -

I'm not an engineering mentor, but I am trying to resolve issues around organizing the CAD files, designing a process to maintain good master files, etc.

I like the idea of sharing the CAD live via the projector. We've also toyed with the idea of having monitors in our machining area so folks can more easily refer to the design in real time.

Can either of you share how you use cloud sharing and Google Drive specifically to organize the CAD files. One of the things the engineer-types have commented is that there isn't a way to view the files in Google Drive in native format.

I keep thinking Google drive should work. I think there is also an Autodesk cloud solution, but I don't know much about that.

Thanks in advance.

POLLY

Re: Keeping an Eye on the Big Picture
 

True. Several parts are 'standard' and can be fabricated right away, as can most drivetrain components. (I wonder if the CAD model might do better at competition though...)
Yeah, I was young once myself, but then I got old and learned how to delegate ruthlessly. And later still I learned that I hated supervising, and I am now quite content and fulfilled as a worker bee.
I just read he Agile Manifesto on Wikipedia; I'd never heard of it before.

Wow.

Implementing it, to me, means getting everyone together for updates and collaborative decisions. The customer is the drive team.

Re: Keeping an Eye on the Big Picture
 

This seems to be a good point in the discussion where I can add something JVN posted a while back in a similar thread. It was something to the effect of "We will never vote on a design. Voting is not an engineering decision making process."

I agree completely with that, and not everyone should have an equal say, or even a say at all.

If you look at how some of the most successful teams operate, you'll notice that they often have one person driving the design, from big picture to minute detail. They can delegate the work, but they are beginning with the end in mind, and know what the whole thing should look like before any of it is CAD modeled or built. These individuals are often mentors with many years experience in FIRST, and they have often closely studied the successes of others.

Re: Keeping an Eye on the Big Picture
 

This is probably one of the best summaries I've ever seen about why the teams that are awesome are awesome. While hard work and resources are important, having a single extremely competent person with control over the design is probably the most important factor to team success.

Re: Keeping an Eye on the Big Picture
 

I'm curious about how you would reply to people who would say that this method fails to engage students at a higher level? That is to say that if a mentor is managing the big picture, it robs students from getting a chance to weigh into major decisions.

For some teams that operate on the principal of "student built; student designed," the aforementioned structure seems to challenge the very foundations of some teams.

- Sunny G.

Re: Keeping an Eye on the Big Picture
 

We setup a folder on our team Google drive account that is shared with the students that do CAD (and anyone else that wants it). Each student has a subfolder where they upload their CAD files and I have a folder as well. From their thier is a master folder with the current CAD. We copy out the main file when we want to work on something and then we copy it back into main folder. I'm normally the person that adds in people's subsystems and keeps the main file up to date. That is how are system is supposed to work, but it does break down on occasion. We also normally end up stopping CAD at some point which is detrimental around week 4 or 5. We have a few students that should be really good at CAD this year and should be able to keep it all updated. This will help when we go to make new sheet metal assemblies during competition season. This year we never even mirrored the parts in CAD (so we only have about 66% of a robot) which is one of the reasons we didn't publish our robot this year. The CAD was so incomplete it wouldn't be helpful to anyone.

Just because I keep everything running along and coming together doesn't mean the students aren't involved at a high level. I'm not magic and I don't know everything. The students are the ones who do nearly all our prototyping (I rarely touch the tools), so most of the time there is a student sitting next to me while I CAD or if I do it at home I immediately bring it to the people prototyping and get them to tell me how to fix all the things I stupidly ignored about the design. If I made all the high level decisions by myself our robots would be very, very bad.

I completely understand teams that want to be "student built; student designed," and that works for them. In FRC you are able to build your team in many ways and can include whoever you want; which to me is one of the best things about it.

Re: Keeping an Eye on the Big Picture
 

I'm curious of this also. In my opinion, the ideal setup would not be one person, but instead, it would be a small group of 2-4 people including a mentor. This way, the team gets the experience of the mentor while still being student driven. Just my opinion though; I have never been part of a top performing team so my thoughts are a little less significant I suppose.

Re: Keeping an Eye on the Big Picture
 

The Agile development method was created for software projects and most of the online articles are totally software development focused. However, if you look at agile process from the over all concept, they can be configured for other business processes. In fact this year there have been many articles published on adapting the Agile methods to other industries. Particularly in the finance industry. For First teams I would Focus on the scrum and sprint concepts. Also the the role of the scrum master or task master. Scrum comes from rugby. If you don't what a rugby scum is that would be a start.
We have a design team that consists of the mentor and student leads of the the other teams and sub-teams.

Re: Keeping an Eye on the Big Picture
 

We very firmly believe in being a student run, student built team (in fact, it's our motto). In the years where we've performed very well (2007, 2008, 2010), we've had one person who filled that role. They just happened to be a student.

I don't deny that having a mentor be the "team tsar" detracts from student involvement and learning, but on some teams it's part of their culture. Frankly, I hardly find it surprising that high performing teams tend to have a mentor fill this role. It's extremely hard to find a student with enough dedication, let alone experience and political ability, to fill that role in a way a mentor could. If winning is a high team priority, a mentor almost needs to fill that role. (Now, before to all jump down my throat, winning isn't a bad goal...)

Re: Keeping an Eye on the Big Picture
 

You don't have to be a part of a top performing team to have a well informed, popular thoughts considered as significant.

But going along those lines, I think that a group of 2-4 mentor/students is a happy middle ground between having the one, super-experienced person managing the project and general prototyping groups.

The 2-4 person group would obviously include the "one manager" and 1-2 students who would get a strong taste for design and leadership. It appears to be a nice blend of both sides of the argument.

- Sunny G.

Re: Keeping an Eye on the Big Picture
 

In FIRST, there is no best way to do something. If your team prioritizes student involvement, and you believe that this method detracts from that to much, then you shouldn't do it. It's not the only way to achieve success. However, it is true that many of the most successful* teams out there do not put such a huge priority on student involvement (not to say that they are 100% mentor built, but they believe that there are more important things than avoiding mentor involvement, and that in most cases mentor involvement is actually a good thing). This enables them to use this method, and it works very well for them. I am not a believer in the student built; student designed philosophy. I don't think that it is the best way to reach the goal that we all strive for. But just because I don't believe in it, doesn't mean that it's bad. In the end, whether you are 100% student built or 100% mentor built (if there is such a thing), we can all reach the ultimate goal: the inspiration and recognition of science and technology.

*I'm mainly referring to successful in the robot sense, but the same applies to successful in chairman's award sense.

P.S. I hope this doesn't go in the direction of every other student vs. mentor built thread. There was a lot of really good discussion going on, and I don't want to see it fade away. I'm probably just fanning the flames, but I've been wanting to post something about the subject, and this was my chance.
:deadhorse:

Re: Keeping an Eye on the Big Picture
 

I wouldn't. :)

However, I will give a little more insight into the methods of my own team. We used to be a team where everyone got a voice, and often times, everyone got a vote (shudder). Then, we realized our robots weren't very good (every year, and declining) so we set out to change. We began to question why certain things needed input from the whole team, when a select few experienced individuals could manage it just fine. We realized that we spent more time talking, sharing, debating than actually designing or building anything, and even if we ever did reach a consensus that everyone was happy with, it was so late it the game that it all got cobbled together anyhow. The design details were purely vocal, speculative, and if we were lucky, poorly sketched on a whiteboard. Team meetings were woefully inefficient, with each person taking a turn to share what he or she did, in great detail. Most of the time, these details were irrelevant to a majority of the others listening. And while these meetings took place, work did not. When I became the lead mentor, I threw these meetings out the window, and now I just let people work. There are very few times that something needs to be addressed as a whole team, and when it does we do. But we do not make a daily or even weekly habit of it. A good leader does not need to frequently halt all work to gather his people to ensure that work is getting done. He will be walking the floor and he will know it as it's happening.

Our designs are now driven by logic, testing, and experience, not speculation, opinion, and feelings. You'd be amazed how much a team can improve once they do a little self-reflection.

Many teams (including past years of my own) have this "we learn from failure" philosophy that makes me just cringe. It builds a culture of students who think there will always be a next time, and that mistakes are always okay, and who accept lousy work because they are learning. To learn from failure is fine, but to do so without giving every possible effort to succeed is just wrong. And by every possible effort, I mean including the expertise of mentors.

Aww shoot, I guess I did end up responding... Anyhow, this horse has been well beaten, so let's steer the thread back on track as the OP intended.

Who or how is the whole robot envisioned while it's still in the preliminary or pieces or sub-assemblies design stage? Some teams (such as 118) seem to have a VERY integrated design that I'm sure must be envisioned as a whole before any part of it can start to be detailed.

Re: Keeping an Eye on the Big Picture
 

Sanddrag, that's very similar to how we run our team as well. I think we have about 2 all hands meetings during build season and one of those might go away this year. Everything else happens over email or in small groups.

Re: Keeping an Eye on the Big Picture
 

This is how the teams I've been on/mentored operated, I was typically that person, or it was a "brain trust" of 2-3 people fulfilling that role.

I think the mentor leading up this role also has the responsibility of keeping an eye out for students capable of assisting in his/her duties though a capable/motivated student may not exist every year so it tends to require flexbility/awareness in the role.

Re: Keeping an Eye on the Big Picture
 

I've been the "build master" for the past couple of years on my team. It really is very hard. For one there is a lot of work that needs to be done. What I've concluded is that it is really hard to build a competitive robot by a) 100% students and by b) 100% mentors. The best solution in my opinions is a bit of both. You really need an active mentor base to help train your students and you need a good group of students who are willing to take initiative. To any student trying to manage being the "build master" on their team, the biggest recommendation I can give you is to spread out the work as much as possible.

Re: Keeping an Eye on the Big Picture
 

What 1538, 254, and any teams that seem to have that "Big Picture oversite team" have is a Systems Engineering Group. In Madison & Allen's case, they are the Systems Engineer for the team.

I posted a while back on the topic, and I think its perfectly relevant here.

Whether you have a team or a person, its incredibly important to have someone filling the Systems Engineering Role, and I guarantee that all of the teams that perform well and meet their goals have incorporated Systems Engineering, whether they call it that or not.

Re: Keeping an Eye on the Big Picture
 

I think...I think this may be it.

- Sunny G.

Re: Keeping an Eye on the Big Picture
 

My team does basically the exact same thing. The only difference is our team set our expectations lower and never considered making a 30 point climber and actually decided to make a 10 pt hanger only in the last week. We usually don't work on the subsystem until we can fit it into the whole design. I act as the "mechanical director" and communicate with the different groups and help/take over the projects that are falling behind.

But for the rest of the process, it is the same. This process and structure has worked well for us in this past year as it is different than in 2011 and 2012 for us. And we look of continue this method next year and beyond.

Just wanted to put in another teams info, seems like this method is the general consensus.

Re: Keeping an Eye on the Big Picture
 

Yeah, those are the guys who cheat.:rolleyes:

But back to the point: We call it brainstorming, but then we take a vote. And year after year, we see that people who have no idea of what they are doing get a vote, and sometimes bring the design in a bad direction.

Yes. This IS it. What I will try to implement* is a systems engineering role, but comprised of a mentor and 2-3 talented students. Brainstorming still works, but the SE group makes the final decisions and irons out the details.

If we then also keep everyone reporting to the SE group, that will solve our problem of trying to integrate five different teams' output into a single product.

I like this thread.

*I am not the one in charge, I need to use my powers of persuasion, Again.

Re: Keeping an Eye on the Big Picture
 

Do you actually set up formal requirements or use some kind of DOORS-esque tracking tool? Some FRC robot are definitely complicated enough to warrant it. I have thought that writing up actual requirements on Day 1 and 2 would be a fun exercise, but I am not sure we could stick to them.

In my day job, the systems group does not make that decision. Systems tracks your compliance to requirements, but if you have a non-compliance then that is brought to the attention of other affected owners. If you can't agree on your own, then it is elevated up through the program management, who has the final say (and of course has to weigh the advice of all the affected owners). The equivalent of program management for FRC would be your wizard student or engineer that chooses to serve as Chief Designer/Engineer/Wizard/etc.

Re: Keeping an Eye on the Big Picture
 

That's interesting. In the scope of FRC, I believe that the SE group would probably be composed of of the chief designer/engineer/wizard/etc. to begin with.

To talk about System Engineering in general, some documentation (read: wikipedia) seems to imply that the SE folks are involved in design and managing of complex projects. I suppose the specific role tends to vary from company to company.

- Sunny G.

Re: Keeping an Eye on the Big Picture
 

I use DOORs in my job all the time, but never figured on using it with a team. Sure you could, but honestly defining tracking multiple levels of requirements can take a single person or small group weeks upon weeks, and as you mention, things change too fast to really make this a worthwhile tool in a 6 week build. DOORs is all about traceability to the customer requirements, and FIRST is more about defining a strategy - you are your own customer in this case. It may be a fun exercise to do for a summer project... to trace all aspects of a design to the FIRST rules, but Im not convinced there is value in a $6,000 piece of software to track a level or two worth of FIRST Robot requirements.

Its more important for this group to define something like the top 10 requirements for the robot (and even some non requirements). Many teams do this, but fail to stick with it, and that is where they fail. They see something they can add on, or they define requirements that are way out of their means. I would bet if all teams compared what they built in the end to what they said they were going to build at the end of the first weekend, that MAYBE only 10% of them would have achieved their goals, and many would have fallen far short because they ran off on some tangent.

I've now worked at 3 different companies, and every one of them had a different role/view for SE's. I've been everything from a Project Manager/Engineer as an SE, to a Technical Lead, to a Documentation Monkey, to a Requirements Engineer, to a Subject Matter Expert. You will also see SE associated highly with the IT world, but that's not exactly the role I am talking about.

Realistically every team needs a Technical Lead - one who not only understands the integration of the CAD, but what the electrical team can do to drive it, how the programming team needs it to work, and how everything can come together in the end. This Technical Lead can lead an SE team or Integration team or whatever you want to call it to ensure that everything meets the team's initial requirements, that all designs are following along the path of the team's requirements, and that all components are going to work together in the end. The biggest job for the SE team is Keeping the End Goal in mind... always thinking 5 steps ahead of where the design or build is at, and catching any issues before they happen.

Re: Keeping an Eye on the Big Picture
 

Good insight Ian, thank you.

And looking at your signature, I fully agree with the Atlas lathe...but a 618 please, not a MK2!
(Proud owner of a nice 10F (TH42) and an even nicer MFC...financed by selling my 618. Worst Mistake Ever)

Re: Keeping an Eye on the Big Picture
 

Definitely so - I consult with a number of companies and my experience is that the SE roles are very different. In some companies, the SEs are the best and brightest. In other companies the SEs are folks the EE/ME leads did not want. SEs in some companies do nothing but track requirements and advise the PMs but in others the SEs drive the design and dictate to the EE/ME leads. I kinda like environments where the SEs are skilled and experienced big-picture experts - integration seems to go more smoothly.

Our team had a problem with too much input a few years ago. So we adopted a hybrid approach. Our team is very student-run and any student can (still) pitch a design (or a design change) but now they must convince a member of the "design committee" (instead of a single mentor or student) to get it considered. This design committee (a very small group of student SEs) make all key design decisions. I advise them as necessary but primarily I stick to making sure CAD makes sense before fabrication (so we don't tick off our sheet metal sponsors), spending sponsor monies wisely, double checking the physics etc. Some years are still tough but things seem better with a structured and focused decision-making process. I too got older and could not put in the crazy hours! Along with this decision making processs we now prioritize modularity in the design to make integration easier.

Now if we only had better tools and more money... <working on it>

Great thread!