My Story


I don't think people really read my resume. It's about four pages long. I know, I know; it's too long. There's a lot of really interesting stories behind it, though!

I've worked for startups, enterprises, consulting firms, small clients, coding schools, and a FAANG (kinda). I'm working at Woot, twice removed (TEKSystems -> AWS Proserve -> Woot). I also got an offer from FB, but turned it down.

This page covers my journey and a lot of lessons learned along the way. You might find it interesting. One peculiarity is that some of the lessons weren't apparent immediately in retrospect, but took time to percolate. That might be reflected in fewer or less significant lessons in the more recent episodes. And, you might notice that nearly all of the lessons are connected with my failures and shortcomings. I've had quite a bit of successes, often in spite of my pride and convictions, but that list is, strangely, much shorter.

At any rate, this is my attempt to distill all of the lessons from my career. I may add to it, as the profundities dawn on me, and as I pile on more, ahem, learnings.

Everything here is my personal opinion, and has nothing to do with any of my employers' views, past or present.

I've started each story with a tl;dr of key lessons, and I've bolded the ones that are really important to me.

Table of Contents

  1. College
  2. Tech Writing
  3. Cerca
  4. Avanade
  5. Gesto
  6. MaxSam
  7. ReCharm
  8. Galvanize
  9. Cadence
  10. PushPay
  11. GottaGoGov
  12. Stackline
  13. Elevāt
  14. Empathize
  15. Coinstar
  16. LivePerson
  17. Wellsaid Labs
  18. Lowe's Innovation Labs
  19. NiftyPerks
  20. AWS Professional Services


tl;dr (lessons learned)

  • Success and skills are often a product of just putting in the time
  • Toot your own horn; no one will invest the time an effort to discover your story, but if you tell it well, they might respond
  • College is not a magic bullet, and not for everyone
  • Childhood gave me a superiority complex, took some serious exposure to shake that out
  • The line, "you'll change your major several times" is mostly applicable to liberal arts majors, and even then, it sets the wrong expectations
  • Getting relevant job experience/internships as early as possible is invaluable

I went to college at the University of Washington. What might be surprising is that higher education was never on my radar until just after I graduated. I had...humble plans based on unskilled work and trying to make it big as a musician. It seems silly, 20 years later, but that's just where I was at the time.

Long story short, someone who quickly became a lifelong friend had the chance to meet me at the exact right time, learn of these plans, and, with a perfect touch, suggested that I consider taking the SAT and seeing how I fared. "If you score well enough, colleges will pay you to go. It's essentially free money." Intrigued, I spent the summer after graduation practicing and drilling, day in and out. And, it did work. I scored a 2280, not quite a perfect score, but in the highest percentile.

I stumbled through the admissions process. Not leaning hard enough on my hardships and challenges, I submitted half-hearted essays and got into only several schools. I decided on the UW, as it seemed to be the biggest, broadest environment where I could really stretch my wings. And, it was close to home.

Getting in wasn't the hardest part, either. Having spent a year out of school, my study habits were poor, to say the least. My intended major wasn't for me, and I didn't have a backup. I spent a year and a summer in China, racking up credits (and debt), and at the end, I had to pile up my credits and apply them towards an International Studies major.

The saving grace was a work study job I got in my junior year. My main qualifications were the steep discounts my boss received on my pay, courtesy of the federal work study program, and my fastidious attention to detail. It was in this role that I started to get a glimpse of how the world of business really works, although it would be several years before I really started to piece it together. Acadamia is like a parallel evolutionary track with the world of business; many of the fundamentals are the same, but it looks very different on the surface.

Tech Writing

tl;dr (lessons learned)

  • It's not about how hard you work; it's whether you're delivering something useful, and often in an arbitrary time-frame
  • Recognition doesn't go hand-in hand with contribution; it's often seniority-based
  • Cold calling/emailing works _ You can spend so much time stewed in your product that you don't appreciate the first-time user experience – yes, the benefits and systems make sense to you, but it's just words to someone who's never seen it before.


tl;dr (lessons learned)

  • Just because you can imagine something that's internally consistent and sound, doesn't mean it's practical or realistic. Our imaginations fudge a lot, and miss a lot of key details
  • Don't waste time structuring a business that doesn't exist – go prove the model
  • Just because you see and can address flaws in an existing system doesn't mean that you've come up with something viable


tl;dr (lessons learned)

  • People won't see how hard you work (and wouldn't care, anyway); they see your results, and only care if that helps them and their goals
  • Dressing well is nice, but it can't make up for skill and experience
  • There is usually a way to squeeze in learning opportunities, if you don't mind doing extra work (UX group, Node.js)


tl;dr (lessons learned)

  • Don't reinvent the wheel, especially when starting out
  • Don't be afraid to take a better opportunity; don't let your hangups get in the way
  • Don't worry about being loyal to a company; they typcally won't be loyal to you


tl;dr (lessons learned)

  • Doing what's best for the client actually means taking into account what's practical and makes sense to the client, not just what's "best" overall
  • A lot of beaurocracy exists to justify itself; it often masks inefficiencies in process
  • Grifters gonna grift


tl;dr (lessons learned)

  • Just because you can sell to a client, doesn't mean you should
  • If you can't educate the client on your side of the business, you'll have to do it their way
  • Outsourcing is not a silver bullet – requires attention and management


tl;dr (lessons learned)

  • Some will love you and some will hate you; that's just how it is
  • It's easy to get to thinking that you're exceptional, or unique, but you really need to take your self-view and confront reality with it
  • Not all people can be taught




tl;dr (lessons learned)

  • Sales-driven organizations can be effective, but aren't entrepreneurally "pure"
  • Commutes suck, and they suck more the longer you have them
  • Geographically-split teams are hard to run, hard to be a part of


tl;dr (lessons learned)

  • Useful != valuable
  • Don't expect someone else to pound the pavement for you, even if it's their idea
  • Understand the long-term maintenance profile of everything you build


tl;dr (lessons learned)

  • Set expectations early; don't let a superior judge you by criteria that you don't know about
  • Appearances matter; again, people don't see your hard work, they see what they see


tl;dr (lessons learned)

  • Over-delivery is not a virtue; move in sync with your team or risk upsetting people
  • Be careful about how you word things, especially with new people
  • You can't make people from non-Tech industries understand tech growth strategies


tl;dr (lessons learned)

  • Ship early; just get it out there
  • Don't commit to a project you're not interested in




tl;dr (lessons learned)

  • You have to constantly advocate for things you want to do or change, and like any business, you have to align your goals with the goals of those you're looking for support from
  • Again, sales-driven companies are not optimized for quality or customer success, but for sales
  • Changing a large organization is a tremendous undertaking; harder still if there's no institutional support
  • Leaders each have their own success strategies and philosophies – some will lead to failure and departure in the short or long-term, some will lock them into holding patterns, and some will actually achieve success. Largely dependent on demonstrable impact: not, "did you make things better," but, "what can you prove you improved?"
  • Geographic distribution doesn't make for cohesive teams; instead creates pockets of concern
  • Bringing your own people makes the job 1 million times more enjoyable

A role to grow in

LivePerson (LP) came at a time in my career where I really wanted to settle in and grow into a role. I'd spent a bunch of time at a lot of different companies that each didn't prove to be good long-term fits, often for very different reasons. With LP, I was presented with a starkly different opportunity: build a new office in Seattle from the ground up, and help modernize the company's aging tech stack. How could I turn that down?

Skunkworks in plain sight

The first few weeks were amazing. I was the second engineer in the brand-new Seattle office, right behind my good friend and frequent colleague, Andy Barr. I didn't have a manager or a remit, so I split my time between learning about the platform and helping Andy prototype some cool products. Having just come off of a project where I leveraged the Elasticsearch-Logstash-Kibana (ELK) stack, I decided to dump a bunch of the conversation data Andy was analyzing into a fresh ELK instance. Immediately, I was able to show some really interesting insights into keywords and conversational patterns, and I built a dashboard that enabled a crazy level of exploration into the data.

One of the key things Andy's fledgling data science team was tasked with was intent detection. LP had just hired Alex Spineli of Amazon's Alexa to drive a massive refocus onto NLP and AI, and Andy was the first engineer in that new org. As Andy's team evaluated third-party services to assist in the classification at scale, I took a different route, building a minimal but ergonomic interface for rapid classification of customer utterances. Think "Tinder for intent classification." It sourced unclassified messages from the ELK store, did a similarity search with previously-classified messages to suggest a tag, and let the user choose whether that tag matched the utterance or not. It was a rudimentary system that took me an afternoon to throw together, and I was super proud. We demoed it to Alex and, happily, he got pretty excited about it. "We could put this in the hands of customer agents and have them classify intents while they're going about they're day."

Building something cool and getting positive feedback from the CTO of the company was an awesome experience. Unfortunately, that idea went nowhere. I realize now that it was foolish to expect someone else (Alex or Andy's boss?) to swoop in and start planning its release. I suppose it shows that even good ideas that people like need to be fought for and shepherded across the finish line. I should have advocated harder for it, but I also didn't want to step on any toes – the Data Science team had their own plans.

The other thing that I built for Andy on a whim ended up becoming a full-fledged product, called Zeitgeist. When Andy's boss saw the intent dashboard, and how easy customers could slice and dice conversations, I guess he saw it as a no-brainer to offer it to them. One of the interesting thing about dashboards and metrics is they make you feel powerful and smart, even if you're not asking nor answering specific questions about the data. Hell, I think it's better if you're not asking questions, because then it feels like you could answer anything you wanted. So, Zeitgeist became the Data Science team's first product, and they went on to expand it quite a bit.

The Core AI team

I also prototyped a tool called Recommended Actions, which was basically a listener that would run on ever consumer message and try to identify which actions an agent could take on the conversation. At the beginning, it was just bots that the agent could transfer to (e.g., order status bot, address change bot), but it eventually evolved to include responding with relevant FAQs, and we talked about building support for function-based actions (e.g., paste the status of the customer's most recent order), as well. I was super proud of building and delivering this on my own, and doubly so when I heard that it went over great when demoed at our yearly customers-only event. Eventually, a director was brought in and he hired a team, dubbed Core AI, which I helped conduct interviews for. I handed my baby (Recommended Actions) over to them.

As the new team got up to speed, I showed them the ropes, made architecture recommendations, and tried to support them moving forward. Noticing my involvement, the director asked if I wanted to join his team. Of course I agreed to.

I worked hard with them to deliver the product, sometimes showing up late at the office (1 am) because the infrastructure teams were in Israel (one of the biggest pain points during my time there) and my VPN wasn't working. The sacrifices paid off, though, and we managed to deploy the services. Our launch was successful, and I couldn't have been prouder.

Along the way, my director counseled me on doing too much and not letting the team figure stuff out on their own (not unfounded feedback, but there was so many moving parts and so much to learn, I tried to smooth it over – maybe I made it too smooth), not being invested enough (I did get a bit discouraged after his first bit of feedback, as well as after I got mixed signals about the platform design). What I find interesting is that although I didn't like his management style (a frustrating comination of micromanagement and hand-waving instructions to "build this, no not quite that, no try again"), his feedback was appropriate and helpful. It taught me that I should listen to and try to take something valuable from everybody, even if I'd prefer to not work with them.

Wellsaid Labs


Lowe's Innovation Labs

tl;dr (lessons learned)

  • Confrontation/conflict can be an amazing thing
  • Don't be afraid to question (technical) decisions
  • Focus on connecting with people (over immediate goals) and reap the deep rewards
  • Understand where the business is headed, or at least what it prioritizes, and align or get out


tl;dr (lessons learned)

  • Just because you're excited by a technology doesn't mean you are actually passionate about it
  • Partnerships with no investment can quickly feel imbalanced
  • Hobbyist involvement is nice, but nothing to count on

AWS Professional Services

tl;dr (lessons learned)

  • Large organizations are always going to favor patterns and convention over doing things the most practical way
  • Don't stress about the work; just try to applying yourself and your focus to it at the best pace you can

© Joshua Hutt