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.
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.
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.”
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.
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.
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.
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.
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].