My first real job out of college was as the first non-founding engineer at POPSUGAR, which was called “Sugar, Inc.” at the time. I had found the job via Craigslist and thought of it as solid work that would help me become a better engineer. It wasn’t until years later that I understood how lucky I was that my “introduction” to Silicon Valley was as an early employee at a quickly-growing startup with an amazing founding team. The biggest reason was that Brian Sugar, the CEO, made great management seem easy. I didn’t realize how hard this was until I was in the Founder position and saw myself sucking at communication.

I’d like to share some stories from that first job I still reflect on today, as an entrepreneur, when I think about how to inspire, motivate, and help others get good work done.

Learning More

In college, I worked as a web developer for my school’s IT organization – the organization’s entire raison d’être was technical. It didn’t take me long to realize that POPSUGAR’s business was driven first and foremost by ad sales and content, not technology. This was the first place I had worked where technology and engineering alone were not enough to be successful.

Five or so months into my job, I asked Brian Sugar if he’d get coffee with me. When we met I had a proposal for him: “I want to learn more about the less technical parts of the business, especially ad sales and marketing. Is there some way I could spend one day per week working with one of those teams? There might be something I could build to make their jobs easier.”

Brian’s response was three-fold:

That’s a very professional request and I’m happy you’re making it (I was 22 at the time).

You don’t report to me, you report to Brian Dhatt (CTO), so you need to ask him.

I’m all for you doing this, but only if you talk to Dhatt and he agrees.

We then spent time talking about what I wanted and why and left the meeting feeling like he had heard and understood me, even if I didn’t get what I wanted right then. Reflecting on it now, though, I can see much more happening in that conversation.

In the span of a few minutes, Brian managed to:

Show appreciation for starting the conversation and acknowledge that it might not have been easy for me.

Take the time to understand my motivations for asking and not just giving a quick “Yes/No/Ask someone else” answer.

Respect and affirm his CTO’s authority by firmly recusing himself from the decision.

Communication Breakdown

I’ve failed enough times to know how hard it is to leave a conversation hitting any of the notes above, let alone all of them.

For example, early on at Dev Bootcamp, we needed a particular feature built for the first day of class. The problem: it was Sunday morning, class started the next day, and the person responsible for building the feature had not made nearly enough progress over the last week.

Yes, it was my fault we were in this 11th-hour situation to begin with, but there was still no way it was going to be done in time unless I intervened. I steeled myself for a difficult conversation and called him up. “Look,” I said, “I’m just going to say it: we need this done by tomorrow, you won’t be able to pull it off, and I know I’ll be able to. You should stop working on it and I’ll finish it.”

I felt like an idiot for putting him in this impossible situation and then making him feel impotent for not being able to execute. But I just wanted to get it done. The conversation was heated, but I managed to collect my thoughts part way through. “I don’t know why I didn’t think of this at the start,” I said, “but forget what I said earlier. Do you want to come over to my apartment and work on this with me overnight? We won’t get much sleep.” He was elated and showed up at my doorstep 15 minutes later, excited to get to work.

A good leader would have had the instinct to open the conversation with this proposal. A better leader would have avoided the crisis in the first place.

On Their Terms

As I’ve reflected on my time working with people like Brian and the (many) times I’ve struggled to inspire the people I’ve worked with in the same way, I’ve come to believe that one of the most valuable skills is the ability to talk to other people on their terms. The more perspectives one can honestly inhabit, the more effectively one can work with and inspire other people. Imagine being the engineer who designers loved to work with, or the PM who engineers loved to have on their team. We’re trying to weave as much of this into how we teach aspiring developers at CodeUnion.

Here are some questions I try to ask myself in order to get better at this:

If someone says something I disagree with, can I imagine an alternate universe in which I would agree with them? How do I know we’re not living in that universe?

Do I have a clear picture of why, deep down, someone has chosen to spend their waking hours working alongside me? Am I making a conscious effort to respect that choice?

Do people feel like I have their back? Am I the first to hear about something or the last? Do people leave conversations believing that I’ve heard and respect them, and know what will happen next?

In the heat of the moment it can be hard to ask these questions, but they’re useful even when reflecting. What I can say is that my best moments as a founder have come when I’ve managed to answer these affirmatively and speak to people in their language.