The Intern Who Taught Me About Seizing Opportunity

-

Back when I was working at a startup, we brought on two engineering interns for the summer. Steve was personable and well-liked around the office. He had good technical skills and could handle the tasks we assigned him. When things got slow, you'd find him chatting with the team about weekend plans or the latest tech news. Sometimes he'd even catch a quick nap at his desk during those inevitable startup lulls.

Isabelle took a completely different approach. She was equally capable with her assigned work, but when the inevitable downtime hit, she had her laptop open learning Ruby on Rails. This was the web application framework our entire product was built on, but it wasn't something we expected interns to master. While Steve socialized or rested, Isabelle was diving deep into documentation, working through tutorials, and even building small practice applications on her own time.

I watched this play out over the course of their ten-week internship. Both interns completed their assigned projects successfully. Both were pleasant to work with and showed up every day ready to contribute. But only one of them was actively expanding their value to the organization beyond what we asked of them.

When the internship ended, we offered Isabelle a full-time position as a software engineer. She accepted and stayed with the company for over a year, becoming a productive member of our engineering team. Steve received positive feedback and a good reference, but we didn't extend an offer for permanent employment.

The difference wasn't talent or personality. Both were smart, capable people. The difference was how they chose to use their unstructured time. Steve saw downtime as a break from work. Isabelle saw it as an opportunity to become more valuable.

This experience taught me something important about professional development that I've carried with me ever since. In any role, but especially early in your career, there are moments when you can coast or you can climb. The people who advance are usually the ones who consistently choose to climb, even when no one is watching or explicitly asking them to do so.

Isabelle didn't learn Ruby on Rails because someone told her to. She learned it because she recognized it would make her more useful to the team and expand her own capabilities. She invested her slack time in skills that directly aligned with the company's needs and her own growth.

Years later, I've seen this pattern repeat itself across different companies and industries. The professionals who get promoted, who get the interesting projects, who build strong reputations are often the ones who proactively develop skills and knowledge that make them indispensable. They don't wait for formal training programs or explicit direction. They identify what would make them more valuable and they go after it.

The lesson isn't that socializing is bad or that you should never take a break. The lesson is about recognizing opportunity when it presents itself and having the discipline to act on it. Isabelle saw those quiet moments as a chance to invest in her future. That investment paid off almost immediately.

When you find yourself with unstructured time at work, consider what skills or knowledge would make you more valuable to your team and your own career trajectory. Those moments of downtime might be your biggest opportunities for advancement. 

Popular posts from this blog

The Dual Faces of Technology: Enhancing and Replacing Jobs

-
Image
Automation has been on my mind a lot lately, more immediately due to a book I read , but also because of the looming reality of artificial intelligence. To understand what's involved, making the distinction between replacing technologies and enabling technologies is crucial. As we traverse the timeline of the 20th century, we observe how each type of technology has distinctly influenced employment. Automated technologies have transformed industries by replacing manual labor with machines. Consider the automated switchboards introduced in the early 20th century. Previously, telephone operators manually connected calls using physical connectors on a switchboard. With the advent of automated switchboards in the 1920s and 1930s, many of these jobs were eliminated as calls were routed through electromechanical systems. Similarly, in agriculture, the introduction of mechanical harvesters like the combine harvester in the 1930s drastically reduced the need for manual labor. These machine...
Read more

The Technology Trap: Capital, Labor and Power in the Age of Automation (Book Review)

-
Image
In his compelling book, " The Technology Trap: Capital, Labor, and Power in the Age of Automation ," Carl Benedikt Frey offers a sweeping examination of the historical and ongoing impact of mechanization and automation on society. Starting with the onset of the first Industrial Revolution, Frey deftly navigates through the evolution of technology up to the modern age of artificial intelligence, presenting a nuanced view of how technological innovations have reshaped labor markets and power dynamics. Frey categorizes technological innovations into two types: enabling technologies, like the typewriter, which enhance worker productivity without displacing the labor force, and replacing technologies, such as robotic machinery in factories, which eliminate certain job roles altogether. This distinction forms the backbone of Frey’s analysis, as he explores the varying implications of each type of technology on different segments of the workforce. The book traces a historical patter...
Read more

Deputy Product Owners

-
Image
"The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner." - The Scrum Guide There are a lot of ways in which my approach to Scrum differs from what's in the official guide, and since that document refers to Scrum as 'immutable,' let's just call what I do 'Notscrum™.' In Scrum, there is only one product owner per team. That person is the sole person responsible for the product backlog, and the person who advocates for the work to be done. In Notscrum there is one product owner, but there can be multiple deputy product owners. Here's how it works. When my program at Viacom was first forming I met with the then-director of the Library & Archive group and learned that while he set the priorities on work done, the archivists were organized in three distinct areas with a team lead ...
Read more