Effective Engineering Leadership

A few months ago I decided to take a break from working. 

After I announced that I was leaving something happened that I was unprepared for, however. Several people asked me for 1:1 meetings and asked essentially the same question: You were very effective in changing things here. What’s your secret?

This really took me by surprise. I was, of course, flattered but I also never thought I was any more effective than any of the other incredibly smart people I got to work with. I tried to answer, and found myself giving a relatively consistent answer, which is always a good thing. I resolved to write some words about it once I left. 

Pick your battles

After a few months into a recent position I found myself with a little bit of free time and decided to look into the things I had discovered and see if I could address something relatively quickly. One finding was that we lacked a standard for what data to delete, when, and how to ensure it was truly gone. You obviously can’t leak what you don’t have, so I thought that perhaps we should have a clear process for this. In between other things I wrote a data destruction standard and process. However, as I was finishing it up I realized that not only was this not really the most pressing problem - much of our most sensitive data wasn’t even old enough to where we could legally delete it yet - there also just wasn't the appetite and time to prioritize this. I shelved it and went on to something else. About 18 months later in a planning meeting the lack of a process for data destruction came up and I dusted off the old file and within a couple of weeks we were implementing it. 

The lesson: pick your battles. It’s not always the right time for all the things. We have very limited resources and the time may come later for that thing you want to do. There are very few things that are so important that you must fight them right now, at almost any cost. In the past few years I have been incredibly pragmatic about asking myself: is this really the hill to die on? It almost never is. 

It’s not always even right to fight the most serious problem right away. Let’s say you did the analysis and you found 5 issues. One is critically important and would take 12 person years to address. Two are highly important. One of those takes 3 person months and one takes 1 person month. You would improve the situation far more by working on the two high ones and getting those done. You would also establish a track record of success and accomplishment that improves your ability to get things done in the future. A portfolio of successes will build a foundation for future success. 

More Analysis. Fewer Opinions.

All of us have opinions, preconceived notions, ideas based on our training and our experience. These are incredibly valuable, and they are what got us hired. However, every situation is different and we do not know everything. It’s very easy to approach a situation assuming that you know how to solve it, or even what the problem is. After all, it looks very similar to the one you encountered at X company back in the last job. 

The most important factor in effecting change may be to thoroughly analyze the problem. This includes analyzing the environment, the maturity state of the company, and other problems it faces. It’s nearly always the case that there are many problems and in isolation, they all are relatively urgent. An objective analysis will provide insight into the problem and ensure not only that the right problems are tackled, but with the best solutions and at the right time. Good plans are based on data, not solely opinions, casual observations, or prior experience. A data driven approach also helps get buy off on your plans. Trying to ground the problem as much as possible in objective facts helps overcome resistance to change, and the completely natural urge to prefer one's own problems to someone else's. 

It’s Always Your Job

Someone really smart said “effective leaders never say ‘that’s not my job’”. Actually, Amazon has that as its second leadership principle. It may not be in your job description but I find that a willingness to take on tasks outside of what you thought you would do will always be rewarded in the end. It’s also fun as it allows you to learn more about the organization as a whole, which makes you more effective in the long run. Ownership is especially important in security. The bad guys don’t care if something is owned or not, only that it has a hole in it, and unowned things tend to be blind spots. At one point in my career I was asked if I could put together a regular operational status and metrics review for all of engineering. At the time I was in risk and compliance, so this wasn’t really part of my responsibilities, but it was important, there wasn’t anyone else, and it gave me wonderful insight into the company’s operations. Learning about the rest of the company, and being open to take on tasks outside your immediate responsibility - acting like an owner - opens incredible opportunities over the long term.

One Size Doesn’t Fit All

In fact, the one size doesn’t necessarily fit any. It bothered me for years that I kept thinking back, and sometimes verbalizing that, “at so and so company we did … “

Yes, we are hired because of our experiences, but we are not hired to turn company Y into company X. I made a very conscious decision to try to look at the unique situation and use my experiences elsewhere to solve the problems, not replicate the solutions. Sometimes the solutions are right, but not always. You will be far more effective as a leader if you keep an open mind; if you remind yourself that other people may have thought a lot more about this problem than you have, and don’t try to implement the one “best” solution everywhere. Sometimes, that’s what you want, but there is almost always a reason a company didn’t do that. We need to respect our co-workers and the decisions made, and understand why those decisions were made.

Make Your Ideas Concrete

Write your plan down. All of it. It’s far easier to get buy off, and buy in, and agreement, on something that is written. Define the problem well and back up your analysis with data. Describe why it is a problem but don’t be condescending. Nobody needs you to follow “The latency on system X is up 137% MoM” with “This is a problem.” Anyone can understand why that is a problem. Present the facts and make sure the information is there to draw conclusions. “We saw 437 unsuccessful logins per day over the past month” is not useful data. We need the baseline for people to understand if this is good, bad, or indifferent (and if it is indifferent, why is it included?). The first step of effecting change is to convince people why they should be unhappy with the current state. Nobody will change things they believe are working fine. 

Next, present the solution concretely: “by doing X, we can affect Y, and expect result Z. We base this on an analysis that showed …” You already described why we should be unhappy with what we have, now paint the beautiful future in clear, concrete terms that are easy to understand. This is the vision for what you propose and it should tie into the vision for the company or at least your function. 

Once you have the reader hooked, you describe the steps to get there. It’s a pretty simple formula, but it is effective. The key is that the reader has to understand (a) why this problem needs to be addressed, now; (b) what the future will look like; and (c) what needs to happen to achieve it. 

Final Thoughts

Several years ago, I made very conscious decision to try to be far more deliberate and, frankly, careful; about how I worked, how I selected and approached problems, and how to implement change. Maybe it actually worked? I’m not sure if these thoughts are useful, but hopefully they will at least make you think about how you work, validate some things, and maybe even stir some ideas about things you can change. If you have good insights, please hit me up.