Interview with Ron Lichty, Consultant, Interim VP Engineering and Author

Location: San Francisco and Seattle
Current role: Consultant, making software development hum: interim VP engineering, VPE consultation to senior leaders, team practices assessment, agile and scrum training for leaders and teams, VPE / CTO / CIO / director of engineering coaching.

It was six years ago that I struck out on my own as a consultant to untangle the knots in software development, after 25 years doing pretty much the same as a manager, director of development, VPE and VPP. At the core of what I do is making software development hum. I take on interim VP engineering roles, provide VP Engineering consultation to senior leaders, assess teams’ practices, train leaders and teams in agile and scrum, and coach VPEs, CTOs, CIOs, and directors of engineering. Nice (and gratifying) mix of work. http://www.ronlichty.com

I co-authored one of the few books on managing software people and teams, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams http://www.ManagingTheUnmanageable.net

I also co-author the periodic, free Study of Product Team Performance, which delivers insightful results on what makes for awesome product teams, http://www.ronlichty.com/study.html

And I co-chair the Silicon Valley Engineering Leadership Community.

My wife and I are this year living both in San Francisco and in Seattle. But my boutique consultancy seems to be worldwide; in the last few months, I’ve also done VPE advisories and delivered agile training in Charlotte, New York City, Portland and Kuala Lumpur, Malaysia.

What’s your background and how did you get into management?

Like most of us in management, I suspect, I’d put in a good stint in programming, during which I was able to make some real impact: I helped invent and coded some popular products, I was awarded a few patents, I wrote a couple programming books. But I was curious about what management might mean. I was programming in a boutique consulting shop – just 2 and sometimes 3 of us – so no management to be had there. Apple was the only other company I really, really wanted to work for. Our little consultancy had got a lot of attention and kudos when Apple hired us to code the “attract” app for its latest model to demo itself in Apple stores worldwide. When Apple made me an offer to manage a group product managing the development tools I’d been writing books about, I felt like I’d been invited to play on stage with Linkin Park (or maybe, then, the Beatles).

Back then, at least, Apple re-orged all the time. When my product management group was re-orged out of existence, I went back to programming – I found a coding role in Apple system software. Only to have them make me a manager not long after. When that group was re-orged, I found another role programming. Only to be made a manager not long after. That third time it stuck. I finally came to grips with how to deal with the mushiness of managing. Managing doesn’t have the clear wins of coding! But I was finally at a point where I was ready to give up the ecstasy that comes from personal coding feats – and I was at the point of truly wanting to enable a team of developers to experience the ecstasy. I spent seven years at Apple, the last three years getting to lead the team developing the UX of the Macintosh, the Finder.

What are the biggest challenges you face?

The biggest challenges I face are, I suspect, shared by most of us who have reached a senior level of engineering leadership: we have to find ways to help the rest of the executive team – non-engineering company leaders – understand our organizations. And we have to expand our own perspectives to grok the general management perspective that’s more than just developing new technology – our only shot at getting trust and confidence from our peers in other functions is communicating a balanced cross-functional perspective. Stepping up to be part of the senior team means collaboration is essential, but now the partners with whom we’re challenged to collaborate don’t speak “engineering-ese”. That’s a challenging transition when our key role as first level managers was protecting our teams from the noise coming from all those other functions, and aside from product managers and designers, our peers in previous roles were all engineers! It took me a while, but I eventually codified it as a rule of thumb for the career ladder: what makes you successful on one rung of the ladder will likely get in your way on the next. We have to step out of the functional silos where we’d grown successful, cooperate cross-functionally, understand those other roles, and help those roles understand our organizations. That’s hard!

Vidal, you and I were talking earlier about whether an MBA has value for engineering leaders, versus spending that same time in an engineering management program, whether a degree program like Santa Clara’s or Carnegie Mellon’s, or short courses you can find at Stanford or UCLA, or the direct experience you can get from books like ours and others you’ve catalogued (https://github.com/VGraupera/manager-resources), or from video training like the Managing Software People and Teams LiveLessons we recorded, or even the general management courseware like Situational Leadership and reflective listening that big companies provide, as Apple and Schwab did for me. Generally, I’d opt for all those other things before an MBA. But I suspect the one place that MBA coursework becomes truly useful is in understanding the mindset of the rest of management.

I think I’d be remiss if I didn’t call out one other challenge, though, and that’s the explosion of technologies, platforms, frameworks, languages, and approaches in the last few years. No VPE worth his or her salt in team-building and organization-building can also be on top of the tech. It’s overwhelming. We absolutely have to be fluent in it. But we also have to have a CTO or at least an architect-level super-senior developer on the ground leading it.

What is your approach to hiring?

Interesting you should ask that. The center section of our book is 300 engineering-manager rules of thumb that Mickey and I had been collecting for a decade – the section is printed on half-tone – on gray – but one reviewer called it the book’s “creamy center.” When the book came out five years ago, one of the early interviewers asked Mickey and me which of those rules of thumb was most important. We both – and we hadn’t discussed it beforehand – answered, “Always be recruiting.”

We both learned – the hard way, given there was no one out there to tell us this – that hiring takes a long time, you need to start it before you need it; you need to have a recruiting mindset in your head from the day you take a management job; you need to be out in the world meeting people – networking; you never recruit from your last company, but you need to manage in such a way that people who worked for you there seek you out because they want to work for you again; (you need to manage in such a way that people who work for you now are telling their former colleagues about what a great team they’re on and wouldn’t they like to come join us!;) and you need to figure out systems for keeping track of people you meet and staying in touch with people you meet and helping people you meet with what they need now, so they remember you and want to work for you when you need them.

That includes recruiters. Find the good ones and make them your friends. (And avoid the bad ones like the plague!)

Given how important we consider recruiting and hiring programmers, we devoted an entire chapter of our book to it!

What’s your advice for managers who are just starting out?

We wrote a whole article on that topic a year ago that Better Software magazine made its spring 2017 issue’s cover story – “Do You Really Want to be a Manager?”

There’s a lot of richness in the article, so let me just share two broad strokes…

First, the career-ladder rule of thumb I shared a few minutes ago applies in spades. What made you successful as a programmer will absolutely get in your way as a manager. What you’ve been successful at – probably wildly successful – as a coder – is now important mostly as context: it gives you a red flag detector to recognize when your team or a member of your team is in trouble, it gives you experience to draw on to get them out of trouble, it gives you context to be a trusted (and useful) coach and mentor. But it’s not your job. Your job is to create the environment, to foment the teamwork, to coach the craft such that amazing outcomes that delight customers result. You’ve undoubtedly become really good at trusting your technical skills, and now, even though you could probably do it better than them, you need to put trust in the skills of every member of your team (or grow them so you can or else get rid of them!). Similarly, you’ve likely become really good at shutting out the world – at becoming “one” with your code. And now your job is about inviting in the world. You need to not only put a welcome mat in front of your door but proactively invite interruptions. Your team’s issues are your issues, and you want your team to share them with you as soon as they arise!

The second broad stroke is to become a learner about managing. We have this idea, having been the great programmers most of us were, that we can wrestle our way through managing the way we wrestled our way through hard coding problems. But if we do that, it’s the hard way to learn managing, it’s the long way to learn managing, and it will likely result not only in low productivity but very possibly in our best programmers fleeing us and our teams.

If you’re in a big company, take advantage of the management classes it offers! I was fortunate my first boss at Apple told me I would take Managers and the Law. That class was so jaw-dropping I realized how much I didn’t know and began signing up for others. (The trick by the way, is to sign up when classes are announced, weeks or months in advance. If your calendar is like mine, you’ll never be able to fit a class into next week’s schedule; that is, you won’t take a class unless you blocked the days for it last month.) Consider it a fringe benefit and take advantage of it!

Big company or small, seek out management books and external public classes and video classes that will accelerate your learning. For the most part, our role models aren’t very good. My experience of managers, before becoming one myself, had been of two types. There were those who micromanaged. I avoided those at any cost. As a result, all the managers I’d had managed on the other end of the scale, the managers who throw their new hires in the deep end and see if they sink or swim. (I’d always succeeded in swimming, but it was pretty stressful!)

I just have not found a lot of role models for good management: managers who delegate, coach, grow their folks, partner, support, and collaborate with their staff.

Let me add one more small suggestion: find a community like the Silicon Valley Engineering Leadership Community or the San Francisco Engineering Leadership Community or one of the ACM or IEEE groups where you can talk with other managers about your challenges.

Whats your work day like and how do you manage your time, emails, etc.?

As a consultant, it’s different. But when as a consultant I take on a VP Engineering role, as I frequently do, my workday looks like it did when I was an employee VPE: I scan my incoming messages (email, Slack, texts, Skype) quickly, for fires, then turn my attention to my organization: my team(s), my peers, and my boss. They come first. And they’re where my real value is.

I block time on my calendar for deep work – I want time to think through what my team or my organization needs that’s not day-to-day. (I find I typically won’t do that unless I block everything out to focus – I otherwise suffer from what Linda Stone called continuous partial attention.)

I may well not respond to many emails until evening, before and after spending evening mealtime with my family.

Oh, and there’s one other crucial time of my day. I mentally review and re-order my personal backlog during my morning shower. I know others who do this during their commutes. But for me, it’s while showering that I free-associate, experience “Aha’s” about my day, see clearly what I want or need to accomplish. It just occurred to me while telling you this, but it’s sorta like a personal daily standup with myself!

What’s a personal habit that contributes to your success?

Saying “thank you.” I think it was all the way back in my first managerial role at Apple, I read a piece about the importance of saying “thank you” and stuck a note in my “to the office” folder to “Say thank you 12 times this week” and promised myself that every time I came across it I’d pause and think about who I owed a thank you to. I still think I under-thank. I still look at the note.

I’m not sure if it would be considered a personal habit, but I’m uncompromising in reserving 1on1 time on my calendar for my reports. I find I sometimes have to coach programmers on what’s in it for them, that it’s a guaranteed time they’ll get my full attention for whatever it is they might need me do on their behalf, and that they don’t get to grouse for lack of support if they don’t ask for it. But I really look forward to time with my team members, even if I come away with more on my to-do backlog.

Share an internet resource or tool that you can’t live without.

It’s not an internet tool, but I’ve moved it to the cloud. I started using a personal CRM system way back when I was at Apple. It wasn’t called a CRM tool back then, of course. It’s a Macintosh application that was then known as Quickdex, was renamed InfoGenie, and is now known as iData. Some of the PC people I know use Microsoft OneNote. Some who started keeping track after the dawn of the internet use Evernote. Or a wiki like PBworks. But I find it essential to have a tool that’s stable over time (decades for me!) for keeping track not only of my network of people but also tools and technologies and thoughts and “stuff”.

The second one I’d name – the cloud I now use iData on – is Dropbox. It lets me access not only iData but all my docs wherever I am. It let Mickey and me share Word files between us when we were working on Managing the Unmanageable and the video training and articles that followed.

If you could recommend one book to managers, what would it be and why?

Mine, of course. Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams. There are fewer than a dozen books specific to managing programmers that we’ve been able to find that have been published since programming got started in the ’40s. Get them all!

Mickey and I started the book based around three things we did not have when we started managing: the 300 rules of thumb that I mentioned earlier that we’d been sharing with each other for a decade before it occurred to us that maybe we ought to make them available to programming managers everywhere; nine chapters from our own hard-won experience on topics ranging from how to onboard new hires to establishing programming culture to how to manage our bosses; and bunches of tools that we and other managers created to make our jobs easier that you get access to, with the book, to download – everything from sample job ladders to templates for performance reviews to spreadsheets for tracking recruiting.

While it took Mickey and me eight years to draft, it’s now in its fourth printing, and the response to it has been very gratifying. It’s been translated into two Chinese scripts as well as Korean, and we last year adapted and recorded it as video training: 84 digestible topic-based segments, released last March through InformIT and on O’Reilly’s Safari network. http://www.ManagingTheUnmanageable.net/video.html

My coauthor, Mickey W. Mantle, and I will (finally) get an Audible version of Managing the Unmanageable out this year.

There are bunches of good books out there on management and leadership, generally. The class most responsible for stepping up my game to the VP level was a class based on the book Leading Out Loud, by Terry Pearce.

But we think managing programmers is unique in the management world, and that focusing in on who programmers are and why we’re different and why managing us is different is useful!

Where can we go to learn more about you? (LinkedIn, Twitter, Github, etc.)

Read Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams. Mickey and I spent eight years pouring ourselves and our experience into that book. Along with the rules of thumb from others, we find essential, and the tools we ourselves can’t do without.

After that, a few choices!

http://www.ronlichty.com

http://www.ManagingTheUnmanageable.net

http://www.ManagingTheUnmanageable.net/video.html

http://www.linkedin.com/in/ronlichty

http://www.twitter.com/ronlichty

This series asks engineering managers to share their experiences with the intent of helping other engineering managers learn and improve. Have someone you want to see featured or questions you think we should ask? Contact me.