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 it also sheds some light on me personally.

My name is Greg Herlein. I am an Engineering Leader and Maker based in San Francisco California.
I am active on LinkedIn and sometimes on Twitter. I keep my open source work on Github.

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.

I currently work at Cisco and have for the past 3 years. My current role is Principle Architect and Head of DevOps for a group called "SSO" in Cisco Services. Our group has about 1000 Engineers across the world and we build and operate the software systems that Cisco uses to support our products and 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.

I believe in hiring people smarter than me and then supporting them. My job is to make sure we know what we are building and why, and that we have all that we need to do it and to clear obstacles out of the way. I believe that "trust but verify" is good policy all around, especially in complex systems. I adhere to DevOps principles - read some about it here. I believe that you have to know what "normal" looks like and you have to understand what your "definition of done" is. Fail to define those and you will have more work and lots more stress.

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.

Building teams is as complicated as building software because humans are complicated. Good Engineers are often very complicated. That's what makes them good, usually. 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 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.

I'm very direct. Sometimes I am too direct. If you observe this please give me feedback. 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.

I am also heavily biased towards action. A less nice way to say that is that I can be impatient. I try to be reasonable, but sometimes I'm not. Please say something if you think I'm too impatient. As I said above, facts matter. I often don't have all the facts I need. 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.

One of the side effects of this is that 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. 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 years ago. Speak up, even if it's just to ask questions. I promise that I don't bite.

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). Lately I am using Keybase a lot. It's a good chat tool and it lets me easily share encrypted files.

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. Note that 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. I do all I can to be a positive force for change.

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.

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. And 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."

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.

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(tm) 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.

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.

Seems silly, but this document is Copyright (c) 2018 Gregory C Herlein and released under the MIT License