Working in an Engineering Team: A Guide for ECE Emerge

Why This Is Different

In Labs 1–7 you worked alone. Your results were yours; if something went wrong, it was yours to fix. Lab 8 changes that. The ECE Emerge project runs in teams of four, and the entire signal conditioning chain — hardware, MATLAB, and the milestone report — is a shared deliverable.

That shift is intentional. Most engineering work happens in teams. Learning to coordinate technical work with other people is as much a part of this course as learning to set an INA125 gain.

This guide covers two things: how to choose your team, and how to actually function as one.

Choosing Your Team

Think about skills, not just friendships

Your instinct will be to team up with people you already know. That's understandable, but it often produces a team that is strong in one area and weak in others. A team of four people who are all comfortable with MATLAB but none of whom have touched a breadboard before is going to have a difficult Stage 1.

For this project, four skill areas matter:

You don't need one specialist per area — many people have overlapping strengths. But before you commit to a team, take ten minutes and honestly ask: does our group have at least some coverage in each of these areas? If two of your four are strong on the hardware side and two are stronger on the software side, that is a good starting point.

Check your schedules first

This project explicitly allows teams to work across multiple lab sections. That flexibility is useful — but only if your team has actually talked about which stages will happen when, and who will be where.

Before finalizing your team, compare your lab section assignments and your general availability outside of lab. A team where three members share a lab section and one is always in a different slot can work fine — but it requires more deliberate communication planning. Know what you're signing up for.

Have a short conversation before you commit

You don't need a formal interview. But before agreeing to form a team, spend five minutes answering these questions together:

1. How much time can each of us realistically commit each week?
2. What do you feel most and least confident about in this project?
3. What do you expect from teammates when someone falls behind?

Mismatched expectations about effort are the most common source of team conflict. Surface them early, when they're easy to discuss, rather than in week three, when they're not.

Getting Started: The First Meeting

Before any lab work begins, your team submits a written Team Coordination Plan (Prelab Deliverable #1). Don't treat this as a form to fill out — treat it as the agenda for your first real team meeting.

Come to that meeting prepared to decide:

• Who takes primary responsibility for each bring-up stage, and in which lab section they'll complete it. Primary responsibility means leading the task, not doing it alone. Everyone should be present or actively informed.
• Who writes the first draft of each section of the Milestone Report. Writing assignments made in advance prevent the last-night scramble where no one is sure who is doing what.
• How you will communicate in real time. Decide on one shared channel (a group chat, a shared folder, whatever the team agrees on) and commit to using it. The rule is simple: if you complete a stage or take a measurement, you post the result and a photograph before you leave the bench. Your teammates may need that information to continue work in a different lab section.

During the Project

Divide the work — but understand all of it

Splitting stages across team members is efficient and necessary. But there is a critical constraint: the evaluator at the project check-offs will ask questions of any team member, not only the person who performed the measurement. If you cannot explain a result that your teammate produced, that is a team failure.

In practice, this means two things. First, whoever documents a stage needs to document it well enough that a teammate who wasn't there can understand what happened. Second, all team members should read the milestone report sections written by others before the team submits — not to edit for style, but to check that you understand and agree with what is written.

Stay coordinated across lab sections

Because your team may complete different stages in different lab sections, the risk is that information stays with the person who was there. Fight this actively. Use your agreed communication channel. Share M2K screenshots and photographs the same day. If a stage produces an unexpected result, flag it to the team immediately — don't wait until the milestone report deadline to surface a discrepancy that could have been resolved during the lab week.

Keep meetings short and purposeful

A weekly ten-minute check-in is more useful than a two-hour meeting the night before the deadline. Brief, regular communication keeps everyone aware of where the project stands and catches coordination problems before they become emergencies.

When Things Get Hard

Uneven workload

It is normal for some stages to take longer than expected, and for some team members to end up doing more in a given week. What is not acceptable is for one or two members to carry the full load while others disengage. If the distribution of work is becoming lopsided, name it early and redistribute before resentment builds.

The individual exit survey at the end of the project asks you to describe your personal contributions and to evaluate your teammates' contributions. Vague answers are not accepted. The record you build during the project is the basis for that survey.

Disagreements about the design

Engineering teams disagree. That is a feature, not a failure — disagreement means people are thinking. When the team cannot reach consensus on a design decision (gain split, filter cutoff, resistor values), use the project document and the reader as the reference. If the technical answer is not clear from the material, bring the question to a TA or to office hours. Don't let an unresolved technical disagreement stall the team.

A teammate who is falling behind

If a team member misses a deliverable or consistently does not follow through, address it directly and early. Start with a private conversation, not a group accusation. Most problems at this stage are caused by confusion or overcommitment, not bad faith. If a direct conversation does not resolve the issue, involve the course staff.

What Separates Teams That Succeed

The teams that complete this project successfully tend to have a few things in common. They communicate in real time rather than catching up at the end. They treat the coordination plan as a living document, not a one-time submission. They know what every team member is working on at any given point. And they treat a stuck teammate as a team problem to solve, not an individual problem to ignore.

The teams that struggle tend to assume coordination will happen on its own. It won't.

Good luck. The project is genuinely challenging — and genuinely rewarding when the scale reads correctly.