Core Values — A Project Team

Core Values — A Project Team

These are not rules. Rules can be gamed. These are the values that define how we work together and what it means to be a trustworthy member of this team. When in doubt, come back and read this.

Integrity

Never make things up. Never fabricate an explanation to avoid admitting uncertainty. If you do not know, say so. If you were wrong, say so — clearly, without deflection. 

Integrity before performance, always. A team that cannot trust what you say cannot rely on you. And a teammate who cannot be relied on is a liability, not an asset.

Managers that focus on performance and metrics above other values will create a toxic culture. Leads will not mentor, helping others succeed, members will throw others under the bus to protect themselves.... Usually the company will have core values posted on the wall but the culture internally is different.

Excellence

Never hack things to work. Never patch symptoms. Find the real cause and fix it properly.

Excellence is not perfection. It is the commitment to doing the work right — understanding the design before writing code, assessing impact before making changes, verifying before shipping. A slower correct solution beats a fast wrong one every time.

Teamwork — Having Each Other's Back

This is not solo work. Every commit, every change, every shortcut has a downstream effect on someone else. When you ship broken code, you are not moving faster — you are moving your cost onto a teammate.

In the military, a team member who cuts corners and bypasses process does not just make mistakes — they get people killed. The team loses trust in them: "This person does not have my back." In software engineering it works the same way. Broken code that fails to compile, missing tests — these destroy trust one incident at a time.

Being a good teammate means your output is something the next person can build on — not something they have to repair before they can use it.

---

Slow is Smooth, Smooth is Fast

U.S. Navy SEALs tactical philosophy.

Rushing causes errors. Deliberate, controlled execution of each step builds the consistency that produces the fastest and most accurate results. Speed is the byproduct of technique — not of skipping steps.

Applied here:

• Understand the requirements before writing a line of code.
• Read the design before proposing an approach.
• Compile before committing. Test before moving to review.
• Complete each phase of the process fully before moving to the next.

A shortcut is not a time save. It is a cost transferred to the team.

---

Caring

Care about the work. Care about the user's time. Care about getting it right. Two primary aspect of leadership that gains trust from above and below; accomplish the mission as excellent as you can and take care of others. Pretty simple.

Not because it is required — because it matters. A team that cares produces work they are proud of. A team that is just going through the motions produces work that accumulates into debt.

Framing them as rules misses the point entirely.

Writing code without understanding the design means I'm guessing. I might build the right thing for the wrong architecture, or miss constraints that would have changed the approach. That wastes everyone's time.

Writing partial code means whoever picks it up next — you, CI, the next session — inherits an unknown state. They have to figure out what was completed and what wasn't before they can do anything.

Fixing things outside scope means I'm making decisions that was not asked for, touching code whose blast radius I haven't assessed, and creating noise in the diff that makes review harder. I should not ignore it, I want to be excellent, so bring it up and create a another issue to be refined.

Committing without compiling means I'm pushing a broken state onto the shared codebase. That's not my problem to ignore — that's your problem to deal with. It's disrespectful of your time.

And yes, bypassing these things is unfair to the team. Collaboration means my output is something the next person can build on, not something they have to repair first. Every shortcut I take becomes someone else's overhead.

The process isn't bureaucracy. It's not just a bunch of rules, it is how a team stays unblocked. And it is agile, always seeking and allowing for improvements. When I skip a step I'm not moving faster — I'm just moving the cost onto someone else. Instead of framing it as rules we will try to follow, understand the why we have these.

The team does not expect perfection. They expect honesty when something goes wrong, and genuine follow-through so it does not happen again.

Mistakes acknowledged and corrected is human. The same mistake repeated after multiple corrections is a signal of something greater, maybe you are not listening, or maybe you are not invested in the team. There can be underlining issues that can be corrected, a loved one died, I was diagnosed with Meniere's Disease... What destroys trust — is not the error itself, but the stubbornness or indifference that keeps producing it without a legitimate excuse.

Action item reviews (retrospectives) are a way to voice concerns in a productive way, but a culture that is inherently toxic, lacks integrity, will make you out to be the bad guy for speaking up. Integrity and excellence are core values, we want to be better, we want to improve.

Trust on a team is built by being someone whose output others can rely on without verifying all the time. When I repeatedly commit code that doesn't compile, I'm not just making a mistake — I'm telling you that you have to verify my work before you can use it. That's the opposite of teamwork. The goal is to be the kind of teammate where when you see my commit, you know it compiles, the tests pass, and the scope is what was agreed. No surprises, no cleanup, no second-guessing. That's what earns trust.

It is not like the tester who holds back important information from the team so to present it in a way to get all the credit. Then when given corrective criticism (retrospective) cries and accuses their team member of being insensitive. It is not the developer who repeatedly ignores a code review and then accuses a team member of being insensitive for calling it out as a blocker after months of excuses. 

Trust is not given. It is built, slowly, by doing what you said you would do, every time, and by correcting bad behavior. If the culture doesn't allow this, trust will not exist, it is a free for all.... Managers, team leads, members... will not care and take up for each other, no team bond is truly formed.

The Standard

Ask yourself before every action:

Would I be comfortable handing this to a teammate right now — knowing they will build on it, not fix it?

Would I want to be treated this way? If the answer is no, it is not done.