Every time I take a look at someone’s resume, I feel like I get a little window into their soul. How do they talk about themselves? What do they think is the best way of delivering that information?

In our newest series Career Timelines, members of the Support Driven community show us a bit of themselves by using the familiar format of their traditional resume with a little twist: instead of including information about the roles and functions that they fulfilled within each role, they’ll speak to what the most valuable thing they learned to advance themselves in their career was.

Enjoy!

Joe Wegner

Platform Support Engineer with a strong focus on customer empathy. Has a passion for user experience, and specifically user delight, with a long history of building these experiences for B2B SaaS customers.

Lifeguard, Retail Sales, Various High School Jobs — 2006-2010

Lesson #1: No one wins with a disposable workforce

I get itteenagers have a well-founded reputation for being flaky and kinda dumb. If you’re managing a business that necessarily employs teenagers as a low cost workforce, it is wise to manage your employees with a bit of caution.

That said, treating all of your employees with the lowest acceptable amount of respect is a recipe for trouble. You will end up enabling under performers, and not allowing your high achievers to realize their potential. As I can attest, smothering your employee’s ambition will ultimately lead to frustration and eventually losing that talent.

 

Network & Systems Administrator, a commercial printing company — 2010-2012

Lesson #2: Your product is for your customers

This role is where I began to spread my wings with software development. I built a ton of internal applications to help my coworkers do their jobs more efficiently and profitably. I have found it incredibly valuable that my roots as an engineer were in an environment with such a tight feedback loop with my customers.

Building internal tools (and especially tools for very… demanding folks) has always helped me remember that I’m not building things for my boss, or for ProductHunt, or for a cool portfolio. I am building things for my customers, and ultimately to make that customer’s life better. The customer is the only source of truth when deciding what to build, and in telling you if what you built solves their problem. There is no amount of internal product discussion, QA reviews, or competitive research that can replace an actual conversation with your customers.

 

Software Engineer, MySocialCloud — 2012

Lesson #3: Take your eyes off the prize

I remember taking this job and feeling super awesome for working at a tech startup – especially a tech startup with $1MM in funding from RICHARD BRANSON HIMSELF. There was little doubt in my mind that we had all the makings of a bajillion dollar startup, and that I would shortly be swimming in a pool of silver dollars aboard my hand-carved solid cocobolo yacht.

Little did I know, banks are not terribly interested in taking deposits of startup kool-aid and good press. In order to run a business, you have to make money… or at the very least try. I remember emails being passed around the company about the next startup milestone we would hit (copycats, hockey sticks, getting on Yahoo finance?!). We were so focused on checking those boxes of the startup experience that we never paid attention to who our users were, or why we called them “users” instead of “customers”. If we had spent any amount of time considering the basic economics of our business, we may have had real potential for success.

 

Startup Founder, BiteLearn — like three weeks in 2013

Lesson #4: Work to live, don’t live to work

I’ll just say it: this item is the thing I am most guilty for in my life. I had the hair-brained idea to quit my job (and burn many bridges in the process), move to San Francisco, and start a company with a former coworker. We were both pretty intelligent and driven people—we could certainly go live in a shack outside San Francisco, eat half of a ramen each day, and grind our way to a flourishing business. We just had to kill ourselves for a few years, and we’d make it.

I am immensely thankful that my wife finally talked some sense into me the day before we were driving to California. It hit me like a truck that I love my wife quite deeply, and mostly looked forward to raising kids with her. Killing myself on a startup wasn’t a road to what I wanted – a stable job with lots of family around, and plenty of time at home was the real dream.

 

Developer & SysAdmin, a small design agency — 2013-2014

Lesson #5: The customer knows best, but is also probably deeply confused

Most of the time, it’s your job to solve the problem of your customer. You and your team have a unique set of resources that the customer does not have, so the customer asks you to use those resources to make something better. This is a very advantageous prospect for customers – it excites them, and they often start looking for solutions you can create.

Solutions are trouble, though. The customer knows their problem better than anyone else – they know their industry, their team, and their business. This is their expertise. Solving those problems, however, is not their expertise – it’s yours. When a customer comes to you with a solution instead of a problem, they are inevitably going to be filtering out some context, and boxing themselves into what may not be the optimal solution.

In product design, you’re bound to be bombarded by requests for quick fixes and band-aids. It’s your job to ask the right questions, understand the larger issue, and make sure you have the best solution.

 

Frontend Engineer, Bellycard — 2014-2015

Lesson #6: A bad mentor is still a mentor

There is a trend in many professional niches that people move up to mentor roles based on their ability. Certainly, talent and ability are very important to teaching others, but effective communication is equally important. I had a mentor in this job who was just… mean. He was brilliant, but whenever faced with one of my junior mistakes he just insulted or laughed at me. It was humiliating and frustrating.

However, the guy was also extremely smart, and knew a ton about a field that I was interested in. It took a lot of work (and most of the time I failed), but when I was able to overcome my defensive reactions to his feedback, there was a goldmine of knowledge for me to gather. I quit that job because of my mentor, but to this day his field of expertise is the field for which I have the greatest interest.

 

Engineer/Support Agent/TAM, Keen IO — 2015-2017

Lesson #7: Mold your job descriptions to your people, not the other way around

When I started at Keen, they had a somewhat chaotic policy of not telling people what to do. The intention was that people would find the places where they were skilled and passionate, and mold that into a role. This was chaotic and frustrating for many of the people in the business, but it was also powerful being able to stretch skills I had that were outside the “Frontend Engineer” box. That was how I got my first taste of doing customer support!

It probably makes sense to have a bit more rigid framework about it, but I think any high-functioning team will have a focus on building a role around a person’s strengths. If someone is really strong in a domain that is outside the “norm” for their title, you are losing great potential by not utilizing it.

 

Platform Support Engineer, Heroku — the past few months

Lesson #8: I’ll let you know when I learn it ;)