What is This?
I was inspired by an article on Management README’s and thought it was high time I do something similar. This is mostly for folks I work with, but I hope it’s useful to anyone who interacts with me.
I’m a linux enthusiast and have been since before the 1.0 kernel. I’ve contributed some small things to the linux kernel, including co-designing the Linux Telephony API (which never actually amounted to much, but we tried). I also do electronics and am decent building a variety of things with my hands. I’ll talk more about my geeky efforts below.
My Current Role
I currently work at Cisco and have for the past 4 years. My current role is Principle Architect and Head of DevOps for a group called “CX Platforms” in Cisco Customer Experience (formerly Services). Our group has about 700 Engineers across the world and we build and operate the software systems that Cisco uses to support our products and to offer professional services. We are transitioning years of older software towards modern containerized microservices managed in kubernetes (k8s).
I manage a small team of Architects and indirectly manage all the Senior Architects in our group. I also manage a team of Site Reliability Engineers (SRE). These folks are “player coaches” who treat Ops problems as software problems. We aim to help automate everything our group does.
My Management Style
It’s hard to summarize my style, but these three points nearly capture it:
- Hire people smarter than me and empower them to do great things, removing obstacles along the way
- Ensure that my teams understand the bigger picture and that we are doing the “right work”
- Carefully compose teams, reinforce them, and craft a leadership pipeline of technical and management talent
I believe in hiring people smarter than me and then supporting them. This leads me to what I look for most in folks: good judgement. This is very hard to detect in an interview, but critical if you are going to actually delegate and let folks make their own decisions. Keeping decision-making too centralized and you cannot scale, and you slow down. You have to delegate. And that means that my job is often about clearing out obstacles. It’s making sure everyone understands what’s been delegated, who has what roles and where their responsibility lies. This isn’t usually very technical but it might be the most important thing I do. That said, I believe that “trust but verify” is good policy all around, especially in complex systems. It’s easy for Engineers to get tunnel vision and miss the forest for the trees, and it’s easy for things to get dropped in the “seams” between system components or between teams. A big part of my job is to watch for that. Delegation of authority does not mean I’m no longer responsible. Inspecting what’s happening is critical.
Another major principle is to make sure we know what we are building and why it’s important - and that we have all that we need to do it. It’s so easy to go down a side street, or get caught up in work that is interesting but not strategically important to where we want to go as an organization.
Building teams is as complicated as building software because humans are complicated. Good Engineers are often very complicated. That’s usuall what makes them good! A former boss said that I “make teams that don’t break.” That’s the nicest thing anyone has ever said about my management skills. I take the time and effort to identify talent and nurture it. I am proud that many folks who worked with me over the years are now either key technical leaders or Directors or VP’s in the industry. My leadership pipeline works. I am proud to still get to work with some of those people several companies later. And many of that group gather a few times per year for a pint and some laughs. I’m so proud and happy about that.
My Operational Style
I try to adhere to DevOps principles - read some about it here. I believe that you have to know two important things:
- What “normal” looks like
- How do you know when you are “done?” - what is your “definition of done?”
Fail to define those and you will have more work and lots more stress. And quite often the “pefect is the enemy of the good enough to ship.” It’s usually better to ship something and get feedback - that is, if you can fix it live. Embedded systems are a whole different beast. Note that the two points above imply that you actually have a system for “seeing” how your systems behave, and also a system for “knowing” when you’re done. Going into that is a book though. Another time.
I expect a LOT of myself and those who work with and around me. I think teams can, in general, do more than they think they can. But I strongly believe that there’s a huge risk of diminishing returns if you work too much. Humans need time away from hard work. Making software is as much a creative effort as is it a thinking effort. Tired Engineers lose the creativity. Worse, tired leads to mistakes and bad judgment. I try really hard to make sure my teams are not over-worked. It’s bad for the people and bad for the product we are building. And bad for everyone’s real life. We should all work to live more than live to work.
My Communication Style
I’m very direct. For folks who don’t know me sometimes I am too direct. I don’t mean to be and when it happens I might not realize it. If it bothers you please talk to me. I try to learn from how I come across to people. But the flip side is you can be very direct with me. Just say it. We’re adults. I value open and honest communication. I also place huge value on personal integrity and honesty. Facts matter. It’s Engineering, not literature. The fastest way to lose me is to play loose with the truth. Especially bad news. It’s like cheap wine: it does not age well. Honest, direct communication. Probably what I value most.
I am also heavily biased towards action. A less nice way to say that is that I can be impatient. Time is the one thing you can never get more of. Money yes, resources yes. Time No. Once it’s gone it’s gone. But please say something if you think I’m too impatient. As I said above, facts matter. Sometimes I don’t have all the facts I need and I might make a decision too early. I am very good at making decisions and moving foward with lots of ambiguity and lack of facts. Most of the time that’s a strength. Sometimes not. It’s a learning process. But I do generally bias towards action rather than waiting for more information.
One of the side effects of this is that if you work with me you need to speak up! If you don’t you may keep me from having facts I need. I find that Senior Engineers have no problem with this. Many less experienced Engineers can be intimidated, or shy, or just careful and don’t speak up. You should speak up though! I am no different than a lot of experienced Engineers: I have a strong personality. Don’t let that quiet you. I was just like you not all that long ago. Speak up, even if it’s just to ask questions. Conversation is how we all learn.
My Working Style
I use a lot of async communication (especially email) because I can multi-task well (mostly) and my life often has more meetings than I wish I had. Some people like this. Some need more face to face time with me. Speak up about what you need. I generally try to do 1:1 meetings for 30 minutes once a week with my direct reports. I am comfortable with a flexible schedule that changes constantly. This means our 1:1 schedule may shift around a but. If that does not work for you, speak up. These times are important to both of us. I don’t want these to be status meetings. Please think of things you want to talk about. I will usually have some themes to talk about, probably about priorities.
I believe in stack-ranked lists. Yes, I tend towards kanban as a workflow management tool. But I will use whatever works. Often the best approach depends on the team and their dynamics. But regardless of tool/methodology/approach I strongly believe in knowing your priorities. I borrowed a tool from Rackspace (where I worked for a while) called the “3P Reports” and added Priorities and call it the “4P Report.” The P’s are Priorites, Progress, Plans, and Problems. These are usually one liners. Plans should map to Priorities and Progress should map to last week’s Plans. Problems are not excuses for failing to meet your Plans - they are things that you need help with. These are public. My whole team can see everyone elses 4P Reports. Transparency leads to sharing of facts. Facts Matter. See above.
I use email alot. I often do email at odd hours and on weekends. I do NOT expect anyone else to do this, and I do NOT expect instant replies. Email is for async comms. If a fast reply is expected, IM or Text Messages are better. Those generate interupts and can be expected to be serviced fairly quickly. Email? A day or so, generally. That’s what I expect, and that’s what you can expect from me. If it’s on fire, call me. That’s what phones were invented for.
I use IM a lot as well, in bursts. My teams have used Slack a lot, of course. Cisco uses Jabber a lot. I loathe Spark (much to the unhappiness of my employer).
Monocultures have blind spots. Diversity leads to better results for many reasons, but one of them is that different people bring different viewpoints to a problem and solutions tend to be better on diverse teams. I’ve seen this for my whole career. Beware: diversity means more than skin color or sex. It also means age, culture, socioeconomic background and more. A whole team of about the same age all from the same college may LOOK diverse but might not be.
I am especially looking to increase the number of qualified female Engineers on my teams. This is not just because it’s the right thing to do (it is) but because in my years of experience teams with women get more done and are happier than teams without. Somehow those teams communicate better, understand better, work together better. It’s good business. And it’s the right thing to do. I have a daughter. I’ve seen how biases work against girls in the educational system. I’ve seen it in the workplace. So yes, I do all I can to be a positive force for change. But flat out: teams with qualified women on them perform better. ‘Nuff said.
Praise and Criticism
I strongly believe that proposed solutions deserve intense scrutiny and valid critcism. People, not so much. Behavior yes. People no. Too often I see criticism of a person actually be direct or biased discrimination. I don’t tolerate discrimination even if it’s indirect.
That said, if you propose something that you have not thought through you can expect my teams and I to be pretty vocal about it. Steel is not forged in temperate heat: the best steel comes from a very hot fire. Ideas and designs are no different.
I believe in the old adage “Praise in public and criticize in private.” I strongly celebrate successes and I love to do that publically. I actually think that most Engineers really like the admiration of their peers. That’s why many contribute to open source. Showcasing what people build is incredibly powerful.
Traits I Consider Most Important
Judgement. Hands down. We assume a certain level of intelligence in Engineers. Skills can be acquired. Knowledge can be gained. Judgement is something you have, or you don’t have. As I said above, it’s hard to test for in interviews. Some folks have OK judgement normally that totally vanishes under stress, or when tired. Some folks just seem to make good decisions no matter what. Those are keepers. Folks don’t need to always be right. It’s not about being right. It’s “did you make the best decision you could with the information you had at the time.” More importantly: did you make a decision at the right time?
After judgement comes curiosity. If you are a learner, you probably have the right mindset to be adaptable. The only constant is change. Learners adapt. Tomorrow’s technology is about to hit us in the face. Can you learn how to use it today?
After that comes being a maker. Makers make things. It does not have to be software. It might be sewing. Or metalsmithing. Or pottery. Or robots. Or glassblowing. Or cooking. Or poetry. In my experience the best Engineers create things. It’s a trait that goes well beyond fingers on keyboard with an open editor. Try it. It will make you a better Engineer.
One thing that does not work for me is a sense of “that isn’t my job.” There’s no “I” in team, as they say, and sometimes everyone has to do things they don’t like. I try to align the work to the skills and desires, but a highly functioning team is one where everyone pitches in and gets it done. The most important thing is to “ship it.”
Lastly, while extraordinary effort is always appreciated, I don’t value heroes in the workplace. CMM Level 1 organizations succeed “based on the heroics of individuals.” I try to build organizations that don’t need heroes to succeed. Team effort. Mutually reinforcing team members, prior planning, clean execution. Software is hard enough already. No need to sprinkle the need for heroics into it.
My Personality - Real and Apparent
I am told I come across as an extrovert. Nothing could be farther from the truth. I am very much an introvert. I love to work alone, curl up with a good book or cuddle on the couch with my wife and watch a good movie. I generally don’t like to go out, or to parties, or even walk down a crowded street.
That said, when I decided to manage teams I had to learn how humans worked. And that meant learning to be social, learning to go to parties, to talk, to have a drink or a meal together, to do public speaking, to show personality. But all that takes a huge amount of energy from me. If you see me hit a wall and slip out of an event or dinner or party, just know that I ran out of gas and needed some alone time to recharge. Sorry.
Even though I am an introvert I’ve learned that I learn so much from spending time with smart people. I love to hang out with my teams, especially teams from former companies who still get together often. Customers and partners too. It takes energy, but learning is fun. And so worth it. I trade energy for learning, anytime.
My Interests and Projects
I do geeky stuff on my own time. I build little robots. I write code. I design electronic circuits. I do home repair on my very old house.
I’m an emacs guy. Sorry if you’re a vi person. My favorite language to code in is C. It’s got a purity I cannot stop loving. I’m learning golang. I recently wrote a network use visualization tool called gonetmon that works with prometheus and a CLI tool to lookup MAC address vendors called ouilookup. I’m working on a robotics project that uses MQTT but it’s not done. It uses an XBox™ controller module and controller and a forked version of pi-blaster. I’ve also been playing with some low cost radios.
I’m better at starting projects than finishing them. I have a dozen mostly done things on my workbench at any given time. This is because I get the value out of LEARNING by doing, not out of FINISHING things and then using them. This is not universally true, but more true than not. This is also probably why I push so hard at work to SHIP IT. I know that my personal tendency would be to keep tweaking it.
Personal Stuff, Background, Etc.
I live in San Francisco in a really old house in Cow Hollow. I’ve been here for 20 years which makes me a native to some. My wife is really a native. She grew up here and went to the same school her Mom did.
I’ve been really lucky to have a lot of really good jobs. Once upon a time I was in the US Navy and served in Submarines. I was on the USS Richard B. Russell (SSN-687). I won some awards and the ship won some major awards for things I cannot talk about. Sorry. I also got to work with Woods Hole Oceanographic Institute (WHOI) on the Research Vessel Atlantis. We carried the mini-submarine Alvin. That was a really fun job. And I got to ship some really nice software with teams I’m really proud to have been a part of. I like that. Managing at my level means I don’t get to do code on a regular basis. I don’t like that. That’s why I do side projects. I can’t imagine not coding.
I’ve had the pleasure of writing code and building systems and teams across several generations of technology. The more it changes the more it stays the same. It’s still what I want to do every day. If you really are interested in all that I’ve done you should check out my LinkedIn profile.
OK, some stuff that’s a little more personal:
- Favorite SF Restaurant: tied between Kokkari and Zuni
- Favorite meal: properly grilled steak, arugula salad with lemon dressing, red wine
- Favorite cocktail: vodka martini, up, dry, olives, slightly dirty, shaken, ice flecks on top
- Favorite author: CJ Cherryh, especially her Alliance Universe
- Favorite sport: Baseball. I live and die with the SF Giants
- Favorite city: San Francisco, even though she’s in a rough spot right now
Seems silly, but this document is Copyright © 2018-2019 Gregory C Herlein and released under the MIT License