Skip to content

Professionalism Handbook

The standards this course holds you to as a teammate, and what happens when they are not met.

This page is reference. Read it once now, and come back to it when you need the accountability process or the FAQ. How to actually run a difficult conversation is the Professionalism module, and this page does not repeat it.

Build software. Build teammates. Build yourself.

Why this page exists

Technical skill gets you hired. Professionalism is what earns trust, responsibility, and the work worth doing.

A brilliant engineer who cannot work with teammates struggles. An average engineer who communicates well ends up leading the team. That is not a motivational sentiment, it is an observation about how software gets built, and this course grades against it: you are evaluated on your engineering and on your professionalism.

Seven values

  1. Professionalism
  2. Accountability
  3. Communication
  4. Respect
  5. Ownership
  6. Continuous improvement
  7. Team success over individual success

Trust is the foundation under all seven, and trust is built out of small kept commitments rather than large stated intentions.

What is expected of you

Be present. Attend team meetings. Arrive on time. Tell your team before you miss one, not after.

Be reliable. Deliver what you said you would, when you said you would. If you cannot, say so early enough that somebody can do something about it.

Be engaged. Participate. Ask questions. Review your teammates' code. Volunteer before you are assigned. Never disappear.

Be respectful. Critique ideas, not people. Listen to a disagreement all the way through before answering it.

Be accountable. Own your mistakes and raise your problems early. Nobody on this team expects you to be flawless; they expect you to be honest about where things stand.

What hurts teams

Projects here rarely struggle because somebody could not program. They struggle when teammates ghost the team, ignore messages, miss meetings without warning, stop contributing, or miss deadlines silently.

Ghosting is never a professional solution. Whatever is going on, your teammates deserve a sentence rather than silence. Silence is the only failure in this list that cannot be recovered from, because it is the one that costs you the team's trust rather than the team's time.

There is an important difference between two students, and it is not the one people expect:

The student who struggles The student who disengages
Works hard, asks questions, communicates, wants to improve Disappears, ignores messages, misses meetings, explains after the deadline
I will do everything I can to help this student. Programming ability is rarely the issue here. Professionalism is.

If you are in the first column, come find me. There is no version of this course where asking for help costs you.

Patterns to catch early

Most teams that struggle here struggle in one of a small number of ways, and every one of them is cheap to fix in September and expensive in November. Read this as a mirror, not as a set of labels for your teammates. The names are for spotting a pattern in yourself.

The pattern Ask yourself If the answer is yes
Going quiet Have I left a teammate's message unanswered for days, or gone a week with nothing pushed? Post today, even if it is only "I am stuck on this and have not started that." A sentence costs you nothing. Silence costs the team's trust, which is the one thing on this page you cannot get back.
Costing everyone nine minutes Am I the reason the last few meetings started late? Say so, then either commit to the time or ask the team to move it. Five people waiting nine minutes is forty-five minutes of your team, every week.
Taking more than I deliver Did I volunteer for things last meeting that still have no branch? Hand one back now, not at the deadline. Nobody minds a task returned in week 5.
Merging what I have not read Could I explain every line of my last pull request, out loud, with the agent closed? Read it before it merges. Your name on it is the claim that you can explain it, and clause 6 of your team contract is where your team wrote that down.
Rubber-stamping Did I approve a large pull request in under a minute? Review it, or say you have not had time yet. An approval is a signature.
Saving it for the end Am I planning to write most of my part right before the demo? Split it now. Two thousand lines the night before cannot be reviewed, so what ships is unreviewed.
Claiming a layer Did I claim "the front end" instead of a use case? Re-cut your work by use case, or the integration defect ends up owned by nobody. The AI-Augmented Team explains why.

Two of these did not exist five years ago in the form they take now: merging code nobody read, and approving code nobody read. Neither is about using AI. Everyone here uses AI, and this course requires it. Both are about putting your name on work you cannot explain, which is why "the agent wrote it" is not available as a defense.

If you recognise one of these in a teammate rather than in yourself, do not open with the label. Calling somebody a ghost to their face gets you a fight instead of a fix. The professionalism module has the four-step protocol and the sentences that actually work.

Communication standards

  • Reply in your team's channel within 24 hours on weekdays.
  • Tell the team before you miss a meeting.
  • Raise a blocker the day you hit it, not at the next meeting.
  • Keep your issues and board cards current. A card that has not moved in a week is a message whether you meant it as one or not.
  • Ask for help instead of disappearing.

Your team contract can tighten any of these. It cannot loosen them.

When something goes wrong

Run the four-step protocol: observe the behavior, analyze the impact, investigate before assuming, agree on a fix with an owner and a date. Do it within 48 hours of noticing.

Level 1: the team conversation

Where nearly everything ends. A team that resolves its own problems is what a functioning team is.

Level 2: your TA, then a professional improvement plan

If the behavior continues after an agreement, bring it to your TA with the evidence and the agreement that was not kept. If it continues past that, the instructor meets with the student and writes a professional improvement plan: the observed concerns, the expected behaviors, measurable goals, a timeline, and a follow-up meeting.

The purpose of an improvement plan is improvement, not punishment. Most of them work, and they exist so that the student has a clear, written, fair chance to correct course while there is still term left to do it in.

Level 3: professionalism review

If the improvement plan does not work, the instructor reviews the situation and determines the academic consequence, consistent with the syllabus and university policy. Possible outcomes include adjustments to your professionalism or participation evaluation, reduced peer evaluation credit, individual work replacing team credit, removal from the project team, and, in severe or persistent cases, failure of the course.

Nobody arrives at level 3 by surprise. Every step before it is in writing.

When to contact the instructor

Before asking me to intervene, have done these five things:

  1. Talked to the person directly.
  2. Stayed respectful.
  3. Focused on behaviors rather than character.
  4. Agreed on specific action items.
  5. Made a good-faith attempt to resolve it.

Contact me immediately, with none of the above, for academic integrity concerns, harassment, discrimination, threats, or anything unsafe.

Professionalism counts in both directions

The accountability process gets the attention, but recognition is the more common outcome. Peer evaluations and your TA's notes capture the positive side too: helping a teammate without being asked, communicating well under pressure, taking initiative, resolving a conflict professionally, leading when nobody assigned you to, and delivering good work consistently.

If a teammate does one of these for you, say so where it is recorded. It costs nothing and it is the part of the term people remember.

FAQ

My teammate will not respond. What do I do? Run the protocol. If the silence continues after you have raised it, bring your TA in. Do not wait for the peer evaluation.

Someone is contributing much less than everyone else. Raise it with them first, with evidence rather than impressions. If it does not change, document what was agreed and follow the accountability process. Note that "less code" is not the same as "less contribution": see why volume is not contribution.

I am sick, or something has happened at home. Communicate as early as you can, to your team and to me. Life happens to everyone in this course, including me. Silence is the problem, not the emergency.

Do peer evaluations affect my grade? Yes. Professional contribution is part of your evaluation, and your teammates' assessment of it is evidence. The syllabus has the weighting.

My team is fine but our client is the problem. Different situation, and not one to handle alone. Scope creep, an unresponsive client, or a client asking for something out of scope goes to your TA and to me early.

We disagree about the architecture and cannot settle it. That is a healthy team, not a broken one. Clause 3 of your contract says how your team decides. Use it, write down the decision and the alternative you rejected, and move.

The commitment

Enrolling in senior design is agreeing to this. There is nothing to sign here; you sign the version that matters, your team contract, in Friday's studio.

  • Be present. Be reliable. Be engaged. Be respectful. Be accountable.
  • My teammates deserve timely communication.
  • My commitments affect everyone else on my team.
  • Asking for help is expected, not penalized.
  • Ghosting is never a professional solution.

The goal for December is not only a working system. It is to be the kind of engineer everyone wants on their team.