paint-brush
Livongo’s CTO Dave Engberg on Servant Leadership, Communicating with Executive Peers + Moreby@FirstMark
669 reads
669 reads

Livongo’s CTO Dave Engberg on Servant Leadership, Communicating with Executive Peers + More

by FirstMarkFebruary 6th, 2019
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

<em>Dave Engberg is the CTO of Livongo Health, where he oversees engineering, service operations, and IT. Before joining Livongo, Dave served as CTO of Evernote for nine years. Prior to Evernote, Dave was the co-founder and CTO of CoreStreet. We got to know Dave well when he spoke at FirstMark’s CTO Summit in New York City in 2018.</em>

Company Mentioned

Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - Livongo’s CTO Dave Engberg on Servant Leadership, Communicating with Executive Peers + More
FirstMark HackerNoon profile picture

Effective Leadership Series

Dave Engberg is the CTO of Livongo Health, where he oversees engineering, service operations, and IT. Before joining Livongo, Dave served as CTO of Evernote for nine years. Prior to Evernote, Dave was the co-founder and CTO of CoreStreet. We got to know Dave well when he spoke at FirstMark’s CTO Summit in New York City in 2018.

What was your first management role? What did you learn from it?

I was a technical leader (Chief Architect and then CTO) with no direct reports at an online file storage company called Driveway during the last tech bubble (1998–2001). Then I moved to Boston to found a crypto/security company where I eventually managed a small team.

My early career taught me that the distinction between a technical “leader” versus a “manager” is very important. In the bad old days, great engineers would hit a ceiling on advancement, compensation, and status unless they moved over to direct management. Leadership was equated with the org chart.

The distinction between a technical “leader” versus a “manager” is very important.

Successful companies now intentionally construct parallel paths for technical leaders to progress as organizational managers or technical leads. These non-managerial leaders should provide significant impact through design, mentorship, and cross-functional coordination. Companies should recognize these leaders with comparable pay, titles, and informal status. My staff meetings include both managing Directors as well as non-managing Principal leads.

Early in your career, before you assumed leadership roles, what was one quality you appreciated in a great manager?

I’ve always been drawn to the “servant leader” model of management, and a big part of that is demonstrating that you’re never “too important” for anything the team needs.

I had some early managers that demonstrated this attitude every day. They’d always drop what they were doing to help someone, no matter how junior. They’d take their fair share of unglamorous tasks. I never worked at Disney, but I love their policy that “no one is too good to pick up trash when they see it.”

When I had managers who did this well, I knew they’d be willing to consider my needs above their own ambitions, and I’d repay that with long-term respect and loyalty.

I never worked at Disney, but I love their policy that “no one is too good to pick up trash when they see it.”

What are the most important daily or weekly habits that you’ve developed as a leader?

When you choose to go into technical management (instead of leadership as a staff/principal contributor), you need to give up on having any deep blocks of focus during working hours. You need to be interruptible and responsive so that your team can afford to flow.

I enforce that on myself by aiming for “Inbox Zero” by the end of the week, and no scrollbar visible in the list view the rest of the week. If I can help someone with a request in less than 5 minutes, I’ll always drop everything and do it immediately to keep the queue from building up. Requests with longer time frames go into the calendar and out of the Inbox queue.

This tends to push larger blocks of work out of business hours, but I’ve got 2 hours on the train with spotty LTE each day to help with that.

What framework do you use for your one-on-one meetings?

I’m of the school of thought that these meetings should be primarily the time for the employee to express their needs and advance their development. My main job as a manager should be to make my team successful in their current tasks and overall careers. So the agenda is mostly owned by them, with explicit instructions that this shouldn’t just be a status update or summary of work. Those are better handled through separate meetings like standups.

Once in a while, I break the rule to ask my own questions or raise an important issue. But that’s either at the end when they run out of things to talk about, or else an exceptional “very special” session.

My main job as a manager should be to make my team successful in their current tasks and overall careers.

What advice would you give to a first-time manager about giving effective feedback?

I’ve been trained on a few different frameworks, such as SMART (Specific, Measurable, Attainable, Relevant, Time-based). I think it’s worth the time to learn one of these and do a couple practice runs.

If you’re only giving feedback once a year when compensation changes are due, you’ve failed.

Of all of those letters, I think the ‘T’ is the one that first-time managers may find the hardest. If you’re only giving feedback once a year when compensation changes are due, you’ve failed. You should force yourself to schedule frequent incremental feedback where you can point to specific recent examples rather than batching it up over a span of months to drop on someone like a pile of bricks.

What’s one unique hiring tip you’d share with a first-time manager?

I’ll skip the usual platitudes about “don’t settle, only hire A players” and focus on a common tactical misstep.

I’ve seen a lot of new hiring managers schedule a group of people to interview a candidate, then get them all into a room and ask them all for either a vote or to give their feedback around the table. This contaminates the signal from each interviewer and sets the wrong expectations about the purpose of the interview.

Instead, you should ask each interviewer to collect substantive information about different skills or knowledge. They should each write down their assessment of those areas first. If you want them to help make the final yes/no decision, that should be separate from the domain review. This will get you a more nuanced signal than if you skipped right to an in-person roundtable.

Have you worked with a coach and, if so, what was the biggest lesson you learned?

I’ve done a bit of coaching, with some mixed results. The most actionable thing I picked up in my last attempt was around communication with executive peers. It’s very easy/common for the technical leader to be stuck in the role of the naysayer since they’re usually on the hook for the actual delivery of their peers' desires.

Always start responses with explicit enthusiasm first, dramatic pause, and then give my input.

My last coach gave me some feedback about always starting my responses with explicit enthusiasm first, dramatic pause, and then give my input. E.g. “Wow, this sounds like a great opportunity. I’d love to help figure out what it might take to get it done. [Deep breath…] Here are two questions I’d want to start with…”

Is there someone who you really admire as a leader (not at your current company) that you think would enjoy being interviewed?

Let us know by sending their name and a short description to [email protected].