My years in management: Looking forward

 

As of December, my role at Cisco has transitioned from a leadership role back to an individual contributor.  Gone are the constant approval emails;  gone is the stack ranking of employees;  gone are the performance reviews and the one-on-ones.  It’s both relieving and eerily quiet.  As I make this transition back, after nearly eight years, I thought it would be a good time to reflect on leadership and what it means to me.

I never wanted to be a “people manager”.  When I first started in networking, way back in the early 2000’s, I was explicitly clear about this to my boss.  I loved hands-on work.  I wanted to be in the trenches.  If I were a cop, I wouldn’t want to be a detective–I’d want to be in the patrol car.  I also lacked the self-confidence to take on a team.  Routers I could handle; people not so much.

I worked in Cisco TAC, then at a partner, and then at Juniper Networks.  In all those years, the idea of managing people never once came up.  I didn’t ask for it, and nobody asked me to do it.  I was happy being the hands-on guy.  When I got married in 2012, I told my wife to never expect me to be in a leadership role.

That all changed when I came to Cisco for the second time in 2015.  I had landed my dream job as a technical marketing engineer.  I loved having a lab, doing Cisco Live presentations, writing blogs and books, and working with customers.  I was quite fine with this when my boss, Carl Solder, one day stunned me in our 1:1 by asking me to lead a small team.  I objected lightly–I want to do hands-on work, not manage people.  Don’t worry, he said, you still can.  To my surprise, as well as my wife’s, I said yes.

My first team had 12 people on it, covering Software-Defined Access, Assurance, and Programmability.  A bit of a hodge-podge.  The day the team was announced I was pulled one-by-one by my new team members into a room, to listen to each of their demands.  What had I gotten myself into?  My boss later told me that two experienced managers who were sitting outside the small conference room rolled their eyes and simultaneously said:  “welcome to management!”

The management philosophy I brought to my team didn’t come from books or coursework.  It came from my own observations.  Simply put, there are two management styles:  negative and positive.  Negative leaders are the most common.  They lack empathy and are thus unable to work with people.  They manage by assigning tasks and tracking metrics.  They pile on their people.  They are hard on their teams, task masters, and are mainly interested in their own self-promotion.  They see their team as a tool to achieve their own personal goals.  I’d had many such leaders, and worked poorly under them.  I struggled to remain motivated, and would usually do just enough work to get by.

Positive leadership looks at employees as individuals.  Positive leaders try to understand their employees’ needs and help them grow in their careers.  They look for potential in employees and try to develop that potential.  They try to align assignments to employee’s skills rather than forcing work upon people.  They look for strengths and play to those strengths.  Positive leaders are “servant leaders”, as much as I hate the cliche.  They care more about their people than themselves.  They promote their people rather than themselves.  Under this style of leadership, employees work hard because they feel their leadership cares about them.  They usually want to make their boss look good, and feel personally disappointed when they let their boss down.

I learned a simple rule from my first boss, Henry Sandigo, who practiced this style of leadership.  When your team fails, you take the blame as the leader.  When your team succeeds, you give them the credit.  Negative leaders do the opposite.  When their team succeeds they take the credit, and when their team fails, they blame their team.

One time, my team held up a software release due to critical bugs.  This upset engineering, who pushed back.  One of the product management leaders was furious with me.   He came to me, stood an inch from my face, and with bloodshot eyes yelled at me:  “I want the name of everyone who was in that room making the decision.”  I said to him he could have one name, mine, because it was my team and I was responsible.  It turns out we were right, but I had to endure the fury of that leader for a long time.

If negative leadership is so ineffective, why is it so common?  The answer is simple.  Negative leaders tend to be ladder-climbers and self-promoters, whereas positive leaders are humble by nature.  Negative leaders are always out for themselves, and in the corporate world, that tends to advance you to higher positions.  Additionally, if negative leaders are in power, they have no respect for positive leaders.  They tend to promote people with their own leadership style, and view positivity as soft and weak.

As a leader, you become involved in people’s lives, often quite intimately.  I had two employees go through bitter divorces while on my team.  My philosophy was to give them the room they needed to recover and get back to work.  I had interpersonal conflicts that went to HR.  I had one employee drop from a cardiac arrest and who has been in a coma for two and a half years.  I’ve been in the room with him and his crying family, and dealt with his long-term leave of absence.  Configuring routers is easy in comparison to the harsh realities of life.

I’ve also had to lay people off more times than I can count.  One of the main reasons I didn’t become a manager for so long was that I never wanted to lay someone off.  It’s an unfortunate reality in the corporate world today.  When I’ve made that call, some have been angry, some have cried, most were just quiet.  I can only say I hated having to do it, and that I fought hard to not do it.  In fact, I’ve been criticized for fighting too hard to save jobs.  I cannot really complain as it’s much harder to receive the call than to make it.  But I tried to see my employees as humans and to help them as much as I could.  The unfortunate reality of the corporate world is that people are just seen as OpEx, as numbers on a spreadsheet, and not as human beings whose lives are horribly affected by losing their jobs.  I don’t know if I will ever return to leadership, but I’d be happy if I never had to make those calls again.  (For what it’s worth, I once was on the receiving end of the call.)

I also got to make several happy calls.  Promoting people is one of the great joys of management.  I helped several people get director and principal promotions, which are very hard to get at Cisco.  Although they did the work, I did the back-end negotiation, and I’m proud of each one of them. 

I tried to go the extra mile for my employees.  During the COVID lockdowns, I drove around to each of my direct’s houses and surprised them with a Christmas gift.  They were grateful to see a co-worker after so much time in lockdown.  When one employee, a gin lover, had a really bad day with a difficult VP, I sent him a nice bottle of gin, at my own expense.  I found little touches like this go a long way in building loyalty and positivity in a team.

We all learn from the great leaders we worked for.  I mentioned Carl and Henry.  Bask Iyer was another one. Bask came in as CIO of Juniper at a time when working in IT was like working in a morgue.  We were all depressed, beat up by the business, and unmotivated.  Bask would defend us in company meetings when we got attacked.  He went to bat for us.  He was a great technologist, but what really impressed me was his ability to stand up for us.  Gary Clark, who reported to Bask, exuded the same positivity.  When you met with Gary for the first time, he had a series of lego blocks with different personality traits.  He would arrange them in order while he was talking to you, building a model of your personality.  In other words, Gary wanted to know who you were, how you thought, and meet you where you were.  I always appreciated that.  

At my peak, I had 50 people reporting to me and multiple layers of management.  Then, through attrition, it dwindled to 30, 20, then 8, and now none.  A team of 50 seems like a distant memory to me now.  It’s hard to believe I did that.

Many technical people come to the same fork in the road that I did.  Do you stay technical, or do you take a management job to advance your career?  Notice I put these in opposition.  I can affirm that when you go into the management track, your technical skills atrophy.  As much as I tried to maintain and work in a lab, it became nearly impossible.

There was one day when I was invited, as a senior director, to a meeting on software-defined access architecture with a bunch of distinguished engineers.   They were discussing an idea around multicast.  As I listened, I decided to interject:  “If you do it that way, you’ll break PIM registration.”  One of the DEs rolled his eyes, but then another said “wait, Jeff’s right!”  It was nice to know I still had it.

Those moments, however, become rare.  I know that all of my employees respected that I had a technical background.  It’s important that leaders in technology companies know technology.  But if you go the management route, you will definitely find the technical side of things recedes as people become your main concern.

The hardest thing about being a team leader at a company like Cisco is pleasing all the factions that will ultimately provide feedback on you.  The second you step into leadership, there is a target on your back.  The corporate world is Machiavellian.  Nice guys finish last.  If you try to partner with and please one leader, another leader will get upset.  Pivot to him, and the first guy gets mad.  This was especially true for TME, which is seen as a service organization.

It’s important to remember that the corporate world is vicissitudinous.  Over the course of the years, you will see roles come and go.   I’ve seen executives who were flying high one day shown the door the next, and a whole new regime comes in.

As I said at the beginning, in some ways it’s a relief.  On the other hand, one of our product management VPs saw me with my team and said I was like a “proud papa.”  While it’s nice to do things myself again, I can say I was proud of the teams I lead, and I miss taking pride in my team instead of myself.

Will I ever lead a team again?  Who knows.  If I’m asked I will gladly do it.  If not, I’ll do my job as an individual contributor.  I don’t think there’s much room in the corporate world for leaders with my style, anyways.

The upside is, I can now spend time in the lab.  My routers won’t ask for raises.

23
0

Back in the lab

We all have to make a decision, at some point in our career, about whether or not we get into the management track.  At Cisco, there is a very strong path for individual contributors (IC).  You can be come a principal (director-level), a distinguished (senior director-level), and a fellow (VP-level) as an IC, never having to manage a soul.  When I married my wife, I told her:  “Never expect me to get into management, I’m a technical guy and I love being a technical guy, and I have zero interest in managing people.”

Thus, I surprised myself back in 2016 when my boss asked me, out of the blue, to step into management and I said yes.  Partly it was my love of the Technical Marketing Engineer role, partly my desire to have some authority behind my ideas.  At one point my team grew to fifty TMEs.

All technical people know that, when you go that route, your technical skills will atrophy as you will have less and less hands-on experience.  This is very true.  In the first couple of years, I kept up my formidible lab, then over time it sat in Cisco building 23, unused and consuming OpEx.  I almost surrendered it numerous times.

Through attrition and corporate shenanigans, my team is considerably smaller (25 or so) and run by a very strong management team.  Last week, I decided to bring the lab back up.  I’ve been spending a lot of time sorting through servers and devices, figuring out which to scrap and which to keep.  (Many of my old servers require Flash to access the CIMC, which is not feasible going forward.)  I haven’t used ESXi in years, and finding out I can now access vSphere in a browser–from my Mac!!–was a pleasant surprise.  Getting CIMCs upgraded, ESXi installed, and a functional Ubuntu server was a bit of a pain, but this is oddly the sort of pain I miss.

I have several Cat 9k switches in my lab, but I installed Cisco Modeling Labs on one of my servers.  (The nice thing about working for Cisco is the license is free.)  I used VIRL many years ago, which I absolutely hated.  CML is quite slick.  It was simple to install, and within a short time I had a lab up and running with a CSR1kv, a Cat 8k, and a virtual Cat 9k.

When I was in TAC I discovered IOS on Unix, or IOU.  Back then, TAC agents were each given a Sun Sparc station, and I used mine almost exclusively to run IOU.  (I thought it was so cool back then to have a Sun box on my desk.  And those of you who remember them will know what I mean when I say I miss the keyboard.)  IOU allowed me to define a topology in a text file, and then spin up several virtual IOS devices on the Sparc station in that topology.  It only supported sinulated Ethernet links, but for pure routing protocols cases, IOU was more than adequate to recreate a customer environment.  In 15 minutes I could have my recreate up and running.  Other engineers would open a case to have a recreate built by our lab team, which could take days.  I never figured out why they wouldn’t use IOU.

When I left Cisco I had to resort to GNS3, which was a pretty helpful piece of software.  Then, when I went to Juniper I used Junosphere, or actually an internal version of it called VMM, to spin up topologies.  VMM was awesome.  Juniper produced a virtual version of its MX router that was so faithful to the real thing that I could pass the JNCIE Service Provider exam without ever having logged into a real one, at least until exam day.

It’ll be interesting to see what I can do on virtual 9ks in CML–I hear there are some limitations.  But I do plan to spend as much time as possible using the virtual version over the real thing.

One thing I think I lost sight of as I (slightly) climbed the corporate ladder was the necessity of technical leadership.  We have plenty of people managers and MBAs.  We need leaders who understand the technology, badly.  And while I have a lot of legacy knowledge in my mental database, it’s in need of refresh.  It’s hard to stay sharp technically when reading about new technologies in PowerPoint.

The other side of this is that, as engineers, we love the technology.  I love making stuff work.  My wife is not technical at all, and cannot understand why I get a thrill from five little exclamation points when a ping goes through.  I don’t love budgets and handling HR cases, although I’ve come to learn why I need to do those things.  I need to do them so my people can function optimally.  And I’m happy to do them for my team.

On the other hand, I’m glad to be in the frigid, loud, harsh lighting of a massive Cisco lab again. It’s very cool to have all this stuff.   Ain’t life grand!

Where does time go?

Two things can almost go without saying:

  1. If you start a blog, you need to commit time to writing it.
  2. When you move up in the corporate world, time becomes a precious commodity.

When I started this blog several years ago, I was a network architect at Juniper with a fair amount of time on my hands.  Then I came to Cisco as a Principal TME, with a lot less time on my hands.  Then I took over a team of TMEs.  And now I have nearly 40 people reporting to me, and responsibility for technical marketing for Cisco’s entire enterprise software portfolio.  That includes ISE, Cisco DNA Center, SD-Access, SD-WAN (Viptela), and more.  With that kind of responsibility and that many people depending on me, writing TAC Tales becomes a lower priority.

In addition, when you advance in the corporate hierarchy, expressing your opinions freely becomes more dangerous.  What if I say something I shouldn’t?  Or, do I really want to bare my soul on a blog when an employee is reading it?  Might they be offended, or afraid I would post something about them?  Such concerns don’t exist when you’re an individual contributor, even at the director level, which I was.

I can take some comfort in the fact that this blog is not widely read.  The handful of people who stumble across it probably will not cause me problems at work.  And, as for baring my soul, well, my team knows I am transparent.  But time is not something I have much of these days, and I cannot sacrifice work obligations for personal fulfillment.  And that’s definitely what the blog is.  I do miss writing it.

Is this a goodbye piece?  By no means.  The blog will stay, and if I can eek out 10 minutes here or there to write or polish an old piece, I will.  Meanwhile, be warned about corporate ladder climbing–it has a way of chewing up your time.

Where I’ve been, and what a TME is

Jesse, a recent commentor, asked why I haven’t been posting much lately.  In fact, my last post was August of 2017.  Well, there are several reasons I don’t post much these days.  In part, I’m not convinced anyone is reading.  It’s nice to see a comment now and again to realize it’s not just spambots looking at SZ.

The other major reason was a job change.  I moved to Cisco over two years ago, and I came in as an individual contributor (IC).  I liked to joke that I had never been so busy since…the last time I worked at Cisco.  However, as an IC, I had no idea how easy I had it.

Someone got the crazy idea to make me a manager.  So now, not only do I have the Principal Technical Marketing Engineer title, I also manage a team of 10 TMEs.  The team happens to be driving Software-Defined Access, currently Cisco’s flagship product.  So, the time for blogging is a bit limited.  I’m still working on programmability in my spare time, and I’m continuing to do Cisco Live sessions at least twice a year.  My hair is turning white and I don’t think it’s just my age.

That said, I cannot image a better job or place to be than this job at this time.  It’s an exciting company to work for, and an exciting time.  The team that reports to me includes some of the smartest and hardest working TMEs in Cisco.  These guys are legendary.  (For me “guys” is gender-neutral, for those of you who worry about such things.)  And my boss is considered by many to be one of the best who ever did the TME job.

A quick primer on exactly what a TME does, for those who don’t know:  We are (usually) attached to a business unit within Cisco, and we are really an interface between sales and engineering.  We also work directly with customers, but generally when sales pulls us in.  TMEs are technical (the “T” in “TME”) so they are expected to know their product/technology in detail.  They are, however marketers (the “M” in “TME”) so they need to be able to explain what their product does.

On the inbound side, we learn the requirements for products from sales and customers and communicate those requirements to engineering.  We work closely with Product Managers (PMs) to develop Product Requirement Documents (PRDs) and meet regularly with engineering to ensure that they are building their products in a way that satisfies marketing requirements.

On the outbound side, we develop collateral, which could be white papers, videos, slide decks, etc.  (We do not write the documentation you see on CCO, but we certainly review it.)  We present to our sales team in twice-a-year events, explaining the latest developments in our products and collecting their feedback on what we could do better.  We travel on site to meet with customers in support of sales, or else meet the customers here, at the Executive Briefing Center (EBC).  The most enjoyable part of the year, for most of us, is Cisco Live, our major trade show.

We have four CL events each year:  Europe, South America, Australia, and US.  The US event is the largest of all.  I generally attend both Europe (we were in Barcelona this year) and the US event (Orlando this time).  These events are a blast, but I never realized how much hard work goes into planning the event and developing the content.  It’s also stressful.  I’ve been fortunate to win distinguished speaker two events in a row, which means I was rated in the top 10%.  However, standing in front of an audience of hundreds is always a bit nerve-wracking, and getting ready requires a ton of preparation.  Still, it’s a great opportunity to meet with customers and have a good time.

The pace of work for TMEs is relentless.  I used to say TAC was relentless, because the second you close a case, you take another.  Well, with two SEVTs (sales events) and four Cisco Lives to prepare for, plus a constant and never-ending series of product/software releases…well, it never stops here either.

So that’s why the blogs have fallen away.  I do think I can find 10-15 minutes to post updates at least every week, so I’m going to try to do it.  I wouldn’t mind actually writing the series on programmability I started.  I’d like to clean up and revise the 10 years a CCIE series.  I also have another TAC tale to write up, one of my all-time favorites, so look for that soon.

And to Jesse:  thanks for getting me going!