Skip to main content

What to read as an Engineering Manager in InfoSec

 A question that I have received a lot over the last few years is:

What are good books about managing and leading people in InfoSec?

So to help prevent others from making the many mistakes and blunt approaches that I have made, here's a list of such books with a short note on why I feel it's a good read and why I've found the content helpful.

P.S. If you don't want to read books,  the best thing to start with as a leader is being a good listener!

High Output Management

This is the management bible in many ways. It's a truly fantastic book that describes how to lead, manage your team(s) and how to best spend your time on what’s important. It’s survived the rest of time, being published first in 1983, and although this is over 30 years later, this book is still highly relevant and educational.

Principles

This was an amazing read - in fact I think it is actually a pretty phenomenal gift of knowledge from Ray Dalio to us all. Clearly both Dalio and Bridgewater aren’t for everyone but through sharing his “principles, I feel that there’s so much education in this book for us all in both personal and professional development. Dalio has spent a lot of time throughout his life improving his decision making and in the book he said:

I learned that everyone makes mistakes and has weaknesses and that one of the most important things that differentiates people is their approach to handling them.

Dalio clearly and concisely describes his principles, providing examples of successes and failures in a humble manner, in my opinion. Through this, he explains and shares the tools that he uses such as an issues log, while also explaining how he encourages “thoughtful disagreement” and what it is, in order to get to the best decision.

Radical Candor

This book is one of the best leadership/management books that I’ve read. The authoer (Kim Scott) focuses on explaining how to have a conversation with colleagues that is direct, i.e. leaving no doubt what is being said, while at the same time, delivering this message in caring and constructive method. There were so many good takeaways and tidbits of practical advice that have helped me have tough conversations in a more constructive and caring way.

Thanks for the Feedback

Although much of the advice is simple and common-sense, "Thanks" was thoroughly enjoyable (funny in parts) and very educational for me. While the book does contain cringeworthy examples in it that bring back memories of awkward conversations from my past, it's truly valuable and actually explains the "how' of giving and receiving constructive and actionable feedback. I have been able to apply the lessons and methodologies from the book in my daily life with success. I have recommended this book to several others and everyone so far has found it very beneficial.

Work Rules

We spend more time working than doing anything else in life. It's not right that the experience of work should be so demotivating and dehumanizing.

says Lazlo Bock.

I have thought of this quote many times from Bock, who basically built Talent/Human Resources at Google. There are many interesting and useful takeways, a few key ones would be:

  • The notion to separate performance reviews from compensation discussions, which makes huge sense these days but in the early 2000s, it was quite revolutionary.
  • The stories on "nudges" and how beneficial they can be to driving change. One such story was around "checklists" to help prevent mistakes (something we talk a lot about to help devs make more secure products)
  • Brain teasers are not useful for deciding whether or not to hire a candidate, i.e. he helped revamp the hiring process to be much better for both the candidate and Google, with research clearly showing huge benefits
  • Encouraging Googlers to teach other Googlers - "teaching gives purpose" was the summary of how he advocated Googles could develop and grow best, while also helping Google.

Managing Humans: Biting and Humorous Tales of a Software Engineering Manager

Lopp is a very well known Engineering Leader in the Silicon Valley tech community, having led Engineering teams at Palantir, Pinterest, currently Slack and many others. Lopp's book was thoroughly enjoyable - the anecdotes were funny but provided very valuable lessons that can easily be applied to the everyday life of a manager. The author comes across as a humble guy, self-deprecating and a good leader who's more than willing to share knowledge, listen and help his people.

Extreme Ownership

I loved how this book emphasised and described the extremely high level of "ownership and accountability" that a leader should exhibit. The authors are ex-Navy Seals and throughout the book, they provide intense examples of leadership from their experiences in Iraq, and then provide a correlating example from the business world. At first, I felt the book was a little formulaic but it subsequently improved significantly and there are several key takeaways such as:

  • discipline equals freedom
  • there are no bad teams, just bad leaders
  • simplicity, not complexity
  • take ownership of everything

Overall, the stories and examples are not only educational but inspirational (which is saying something, given my cynicism :) ).

The Five Dysfunctions of a Team

For me, this book succinctly described the key issues that lead to a team failing. So many of us simply avoid the hard issues and difficult conversations, which ultimately results in teams falling apart with a back-stabbing culture inevitable. I found the book incredibly easy to read and it flowed perfectly, with each chapter building on the previous and providing a good base for the subsequent chapters. The book provides many lessons that you can take away and put into effect immediately with the most important being:

the concept of "First Team", which was fairly new to me and has definitely encouraged me to think differently in terms of "who' my team is, which becomes more nebulous as you progress through the ranks or you begin to manage multiple teams.

Without doubt there are numerous books that I've missed (please tell me what else I should read). As a small footnote, it's worth mentioning other books that have also helped me along this leadership path, specifically in decision-making, focus and how to bring about change:

I often discuss books with others and recently an Engineering leader that I hugely respect recommended:

so I'll definitely be checking that out, particularly as he said he frequently goes back to it and it contains advice on what to do in new roles.

There are numerous blog posts on this topic throughout the Interwebz but if there's one site to start with, I'd say go check out Irrational Exuberance by Will Larson, an Engineering Manager at Stripe. He eloquently shares his thoughts on managing engineers, hiring, development tools, technical standards and many more things.

If this all sounds like too much reading, there was a recent Medium post of "Manager READMEs" that showed what some managers in Silicon Valley have been sharing with their team, which is pretty awesome and the general theme is that "Manager is there for the team first and foremost". A few of us within InfoSec created some for our teams so that our teams understand what we do, how we work and to help us become better through their open and honest feedback (though it was mostly to show we do more than go to meetings). Here are some of those decks:

If you've any thoughts on this post or books to recommend, please drop them in the comments.

Note: Moved from my old site - securityleadership.ninja, originally posted on 2018-06-18, joint post with David Rook.


Comments

Popular posts from this blog

MongoDB Authori(s|z)ation

Introduction Having answered numerous questions on the new and old authori(s|z)ation within MongoDB, I thought I'd write a short blog post explaining how things work as there seems to be some confusion. What's New Prior to version 2.4 , there was a very basic sense of "Role Based Access Controls" (RBAC) within MongoDB as there were only two roles - read readWrite which is quite limited. For example, if the user has "readWrite", that user is essentially "root" and the user can add/remove users as well as inserting data into the database, i.e. there is no role segregation. Version 2.4 added in the following 3 core roles - userAdmin dbAdmin clusterAdmin with a notable extension such that there are now 4 roles that apply across all databases - readAnyDatabase readWriteAnyDatabase userAdminAnyDatabase dbAdminAnyDatabase This increased RBAC is a significant improvement from a security perspective in MongoDB. It is imp

Being a Support Engineer @ 10gen - Part 1

There's a mis-conception around the role of a "Support Engineer".  As a clue, it's not what Urban Dictionary   says   - A person whose job is to answer calls from customers of a small- to large-sized company...... They are teathered to a their desk all day via phone headset........ phone jockeys usually hate their jobs.......they are are paid well enough..........until they completely burn out, and hate everyone.   and doesn't always involve this - Image Source: http://half-bakedbaker.blogspot.ie/2009/11/cannoli-and-broken-computer.html As you can see  here , there's lots of open roles in  10gen  and more specifically with 10gen, in  Dublin . I thought I'd write this quick blog to explain what Support Engineers actually do and why I joined 10gen as a "Support Engineer". I could be wrong but didn't Google come up with term " Site Reliability Engineer " to do away with the stigma associated with being a

Separate MongoDB Syslog by Facility

In my last post , I showed how you can set up MongoDB v2.2 to syslog its logs off to a remote syslog server. As my `tcpdump` snippets show, the syslog messages hit the syslog server tagged as "user.info", which means that they're assigned to the "user" facility with a severity level of "info". I've received a few questions regarding the possiblity of splitting out syslog messages by facility, however, as everything is currently sent to a "user.info" bucket, so-to-speak, this is not possibility. There is a current feature request for this capability and work will be done on this but if this is important for you, I'd strongly encourage you to vote for this feature. In the meantime, however, (whilst not ideal) you can still do some host filtering with rsyslog as outlined here .