Introduction to the Life Lesson
This story begins during my final year at California State University San Marcos (CSUSM), as I worked toward earning my bachelor’s degree in business administration. The calendar placed us in the academic year of 2000. This was a time when the university was still relatively small, and the College of Business Administration (CoBA) was rapidly growing. One of the defining experiences of that final year was my Senior Experience project, a capstone requirement for all business students. Unlike traditional exams or reports, this project was designed to bridge the gap between academic theory and real-world situations.
My Senior Experience (covered in a previous blog) was more than just a course; it was a professional engagement with a multinational corporation. Our team was expected to operate as consultants, applying everything we had learned in project management, marketing, finance, Six Sigma, operations, and leadership to deliver a meaningful solution to our selected organization, Qualcomm.
The process began with team formation and project selection, followed by weeks of research, strategy development, documentation, testing, and partner meetings. It was intense, collaborative, experimental, and rewarding. For many of us, it was the first time we saw how our classroom knowledge could directly impact a business’s success or results. That project not only helped shape my understanding of business dynamics but also gave me a solid foundation before entering the workforce with confidence, purpose, and my bachelor’s degree.
Lesson 1: Learned about Procrastination
Our team had been making steady and measured progress, but things began to shift when our assigned point of contact at Qualcomm (referred to here simply as the individual) started becoming less responsive. At first, it was subtle with emails going unanswered a bit longer than expected meeting confirmations became less frequent, and the clarity of feedback began to diminish. What had once been a collaborative exchange started to feel more like a one-way street.
The support we were receiving from the individual began to feel more and more transactional. Instead of guidance or partnership, the requests coming our way felt like we were being tasked with completing work that should have been handled directly by the individual as if we were absorbing responsibilities that weren’t ours. It was challenging, but we were determined to stay professional and deliver a strong final product, ensuring compliance with our selected/assigned project.
Then came a specific request that would teach me a lasting lesson. The individual asked that our final report be printed — not emailed — so it could be manually marked up before finalization and ultimately submission. We were instructed to place the printed report in a physical inbox on the individual’s desk. This inbox, we learned, operated on a first-in, first-out (FIFO) system, meaning our report would be reviewed in the order it was received relative to other documents.
When I dropped off the report on Monday, I noticed there were already about ten other items stacked in the inbox. I made sure to communicate our timeline clearly to the individual, when dropping of the document, in-person. I explained that we needed feedback by end of day (EOD) on that Friday, five days from then. This feedback on the report would be in order to incorporate changes and submit the final version the following Thursday. That same (next) Thursday, we were scheduled to present our findings, and our slide deck would include the feedback from the individual.
On Wednesday afternoon, of the placement within the inbox, I checked in to see if we were still on track to receive feedback by Friday. The response from the individual was brief and procedural: the inbox was handled in FIFO order, and our report would be reviewed when its turn came. I reiterated the importance of our deadline and let the individual know I would follow up again on Friday, hoping to have the feedback available.
Friday arrived, and I checked in as planned. The response was disappointing but consistent — the report had not yet been reviewed and was still in the queue. I asked if there was any possibility of receiving feedback by Monday, emphasizing that time was running out and their input was extremely important to our result. The individual acknowledged the urgency and said it might be possible, though the FIFO process would still be followed.
Monday came and went… The report remained untouched and still in the physical inbox stack on the individual’s desk.
By Tuesday, our team was out of options. We met with our instructor to explain the situation — that we had submitted our proposed final draft to Qualcomm but had not received any feedback. We let the instructor in on the status of the communications from our contact and how that impacted us at the moment. After some discourse with the instructor, we were ultimately granted permission to submit the report without Qualcomm’s review. It was a relief. We were still running out of time however, and this flexibility allowed us to move forward without compromising our deadline.
Our team did a final once-over of the report that did not include Qualcomm’s feedback, made minor adjustments, and submitted it to the instructor on time. We also delivered our presentation that Thursday, confident in the work we had done, even if it lacked the final improvements and validation we had hoped to receive from our industry partner.
What I Learned
Interestingly, we received the marked-up version of our report from the individual at Qualcomm the following week — after our grade had already been finalized. It was their final version, not the one we had submitted for evaluation to our instructor. While it was helpful to see their perspective, it was too late to influence our academic outcome and incorporate their adjustments.
That moment was a turning point for me. I realized that while we had done everything to the best of our ability and planned ahead, while things did not go as desired or needed. We had communicated clearly and followed instructions but made a critical mistake: we had placed too much trust in someone else’s timeline and process. We had built our schedule around the assumption that the individual would prioritize our work the way we had. And when that didn’t happen, we were left scrambling… though I still consider to this day that either the individual was just far too busy or maybe didn’t care enough to give our work credence.
FiFo
I also came to understand that systems without flexibility can fail people. The FIFO method, while fair in theory, lacked the nuance to recognize time-sensitive needs. It was a reminder that rigid processes, when applied without discretion, can inadvertently create bottlenecks and cascading impact. That experience taught me to adopt systems that are both structured and adaptable in my work, ones that allow for prioritization when it matters most.
What I pledged to do then, and forever!
I make other people’s work more important than mine, by giving it extra credence based upon agreements they may have made themselves. I do not ever want to make someone else say “I am waiting for Greg to get that for me” or that “Greg am holding up my work”. Afterall there is no better time to do something than now. I work to respond to requests and inquiries ASAP, with the most descriptive and precise explanation of how much their work matters and when I will deliver the results.
Lesson 2: A Team Member Left Behind
While most of our team worked tirelessly to meet deadlines for our Senior Experience Project and deliver with high-quality, there was one member whose journey didn’t follow the same path. Initially, we had confidence in this individual. We had taken classes together before, and based on prior relations, we believed they would be a strong contributor — someone who would carry their weight and help us succeed.
Unfortunately, that expectation didn’t hold through the end deliverables on the project. As the semester progressed, interaction began to break down between the full team and the individual. Emails went unanswered and scheduled points of connection were skipped. Even class attendance became sporadic for the individual. At first, we gave the benefit of the doubt — maybe it was a temporary issue, maybe something personal or health-related was going on. We didn’t want to jump to conclusions or make assumptions because we would not want the individual to do that to us.
But as deadlines approached and the workload increased, the absence became more than noticeable, and it became disruptive to results. We found ourselves covering tasks that had been assigned to this individual, reworking sections of the report, and adjusting our presentation to account for missing input. It wasn’t just inconvenient; it was disheartening. We were a team of five but functionally operating as only four.
Eventually, we brought the issue to our instructor by explaining the situation, provided documentation of our communications, and outlined the impact on our project. After reviewing everything, the instructor made a decision that validated our efforts and relieved some of the pressure: we were allowed to submit our final report without including the individual’s name on the bottom line.
It wasn’t a decision we took lightly, and we understood the gravity of leaving someone off a team submission. But in this case, it was the best option for the team and the deliverable. The work reflected the contributions of four people — not five — and the instructor recognized that.
This experience added another layer to the life lesson I was already learning. It reminded me that teamwork isn’t just about collaboration but about accountability. Everyone has a role to play, and when one person doesn’t show up, the rest of the team feels that weight. It also taught me the importance of addressing issues early, documenting communication, and being honest about performance even if it’s uncomfortable.
In the end, we delivered a strong project, earned one of the top grades for the class, and presented with confidence. But the absence of one team member served as a powerful reminder: success is shared, but so is responsibility.
Conclusion: What I Learned
My experiences, from navigating delayed feedback to managing team dynamics, taught me more than just how to complete a capstone project. It taught me how to lead, how to adapt, and most importantly, how to take ownership. I learned that I should never make someone else wait an unreasonable amount of time for results that I am to provide. Their work is important, just as mine is. When someone is relying on my input, I need to treat that responsibility with the same urgency and respect I expect from others.
I also realized that prioritizing tasks doesn’t always require a complex system — it just takes a few moments of thoughtful decision-making. The individual at Qualcomm could have looked through the inbox and made a judgment call about what needed attention first. Instead, they adhered strictly to FIFO, missing an opportunity to support a time-sensitive project that at the time “meant my future world to me.”
And perhaps most importantly, I learned that relying on others to match my priorities can be risky. Often, I must take matters into my own hands. Being proactive involves establishing clear expectations and preparing contingency plans for situations when outcomes differ from what was anticipated; it does not necessarily require handling all tasks independently.
Another key takeaway was the importance of emotional intelligence in professional settings. The individual at Qualcomm may have been following protocol, but what was missing was empathy and their ability to see our urgency, our effort, and our investment in the outcome. That absence of empathy left us feeling dismissed while it also reinforced for me that being technically correct isn’t always enough. Ultimately, how we make others feel in the process matters just as much as completing the task.
The Lesson
The life lesson was clear: Procrastination isn’t just about waiting until the last minute to do something. Procrastination is also about relying too heavily on others without a backup plan or mitigating factors. We hadn’t procrastinated in the traditional sense, but we were impacted by someone else’s inability to prioritize and support us. We were delayed and, in the end, took ownership of the final steps, because hoping someone else would come through didn’t work.
From that experience, I learned to always build contingency time in a plan when relying on others. I learned to follow up more often, set firm agreements from the beginning, to establish definite expectations agreed to by both parties, and to prepare for the possibility that others may not operate with the same urgency or accountability that I do. Most importantly, I learned that when something matters — whether it’s a school project, a business proposal, or a personal goal — I own my timelines and my results.
One of the most profound realizations I had was that urgency is not universal as what feels critical to me may not register the same way for someone else. That disconnect can create resistance, especially when timelines are rigid and expectations are assumed versus clearly communicated. I learned that it’s not enough to communicate a deadline to some people. I must communicate why it matters and what’s at stake if it’s missed.
The main lesson I walked away with is this:
I will do whatever I possibly can to ensure that work I’m doing for others, or data I’m providing, is moved towards the top of my priority list.
- I never want someone to say, “I’m waiting on Greg to get back to me.”
- I own the results and that is not just for myself, but for those who rely on me.
That mindset has shaped how I approach professional relationships since. Whether I’m part of a team or leading one, I strive to be the person who follows through, who communicates clearly, and who never lets someone else’s progress stall because of my delay.
Finally, I learned that leadership often means stepping up when others step back. Whether it was covering for a disengaged teammate or navigating silence from a key stakeholder, I found myself in situations where waiting wasn’t an option. I had to act, decide, and move forward even when it wasn’t comfortable. That’s when I realized that leadership isn’t always about titles or roles because it’s about responsibility, initiative, and the willingness to carry the weight when others can’t or won’t.
The lessons from this blog have stayed with me throughout my career and up to today. Whether I’m leading a project, managing a client relationship, or working on personal items, I always ask myself:
- What’s the fallback plan to mitigate any risks?
- What happens if someone doesn’t deliver?
- What can I do to mitigate potential issues in the future?
- Can you confirm your understanding to ensure we are flying in formation?
- What agreements did you make regarding this, outside of our conversation?
- What timelines are you working with, that I need to work within?
It’s not about being pessimistic — it’s about being prepared. And that’s how a simple inbox and a missed deadline taught me one of the most valuable lessons of my professional life.