A Technical Manager’s View of Imposter Syndrome

July 17th, 2017 by Patrick Thomas

“Hey [boss] — am I fired?”

This is one of the those “ha ha, only serious” jokes; one of those places that we all use humor to broach a topic that’s hard to just come right out and ask. I remember using this (admittedly hamfisted) line with various managers over the years. What I really wanted to know was “Am I doing okay? You’d tell me if I wasn’t, right?

I remember one job where I was so deeply uncomfortable about whether I was measuring up that the sound of the Skype ringtone (of a boss or coworker calling) would give me an instant anxiety attack. To this day I can’t hear that sound without it triggering a Pavlovian response. But, when I finally left that job, they made an aggressive counter-offer: our internal barometer is not necessarily a reliable indicator of our external effectiveness.

Fast forward to recently as I was managing a team, except that I was on the receiving end of the “Am I fired?” (or equivalent) joking. It’s a whole different set of emotions to hear it from people who have every reasonable expectation of knowing where they stand with you; even more, this was coming from people who are diligent, talented, and effective at their jobs. Exactly the sort of people who really shouldn’t have to be walking around with some doubt in the back of their minds.

Chuttersnap on stocksnap.io

I recently changed jobs from that position where I was a manager of a technical team, to one where I’m member of a team and not in a managing role. It’s not a move that a lot of people choose to make, and it has given me an unusual perspective and a chance to reflect on some things that technical managers can easily become disconnected from.

The Imposter Phenomenon

InfoSec has gone through some previous rounds of talking about imposter syndrome, so I won’t re-explain the concepts here. If you’re not already familiar with it, Jess Barker, Ben Hughes, and Micah Hoffman have all shared good explanations and perspectives on it (or outside of infosec: Neil Gaiman, Adam Savage). Likewise, the original paper on the “imposter phenomenon” (they specifically didn’t think it was a disorder, so “syndrome” is wrong) is still a relevant and interesting read, and has some actual thoughts on approaches to dealing with it; I highly recommend it. Finally, I think many people know about the main point of Dunning-Kruger (“Unskilled and Unaware of It”), but the core idea of of imposter syndrome also shows up on the right hand side of each of the graphs in that paper; even high achievers tend to perceive themselves as essentially just a little better than average. Put another way, we tend to devalue a skill as we improve. That’s the insidious thing about imposter syndrome: it doesn’t go away as you get better.

Figure from Dunning-Kruger. Notice the top quartile: top performers who assess themselves as performing similar to the third quartile.

With all that in mind, I’d like to use my recent experience and perspective to share some approaches to addressing and handling the imposter experience for both managers and individual contributors.

How Managers Can Mitigate Impostor Syndrome In Their Teams

Encourage “I Don’t Know”

As a manager, you should both foster and model team norms that encourage asking questions, getting help, and learning without judgement. Treat good questions as a valuable resource: ask questions publicly yourself, and encourage others to seek help visibly (on shared mailing lists or channels), and then summarize the answers and how they found them. When people share new learnings in private, encourage them to proudly share it more broadly; from something as trivial as a new keyboard shortcut to big strategic ideas, both the knowledge itself and the meta-level learning of how someone came to that knowledge can help the team. I would even argue that the latter is more important: it represents an investment in getting better at learning together, an investment which compounds over time.

Startup-stock-photos on pexels.com

As a corollary to this, be vigilant for people undermining these values; a toxic individual on a team can affect this for an entire organization. Which takes us to…

Don’t Tolerate “Brilliant Jerks”

There are lots of ways that “brilliant jerks” manifest, but the bottom line is that their negative impact on the team always outweighs whatever individual contributions they’re making. If we truly value the investment in collective learning discussed above, then it becomes easier to reason about the damage caused by these people. Particularly in relation to imposter syndrome, I think some of these “jerks” thrive because other people who are as good but more cautious don’t call them out on it. That silence emboldens and normalizes the behavior, and the effect spreads. As a manager, specifically screen for it when hiring, and excise it if it slips through.

Give Specific Feedback (Both Positive and Negative)

There’s a lot of guidance out there about how to give critical/constructive feedback, so let me focus on positive feedback for a second. For strong performers, “good job, keep it up” is lazy feedback. It’s an easy trap to fall into, and I’ve personally been guilty of it, but it’s a disservice. It doesn’t help the recipient grow or continue to improve and it passes over an important opportunity to reinforce values, but there’s something more germane to imposter syndrome: it doesn’t come off as credible. Remember that the challenge here is that someone doing good work simply doesn’t believe it’s good. So specificity is an important tool here to address a bug in the recipient’s perception.

Especially for more junior positions where roles are relatively concretely defined, I encourage you to put in the thought to tie “good job” back to specific, areas of professional development and, hopefully, their next tier of advancement. If we, as managers, can’t link “good job” back to accomplishment of specific, collaboratively-set goals and visible milestones then we’re robbing our best people of a chance to recognize their own accomplishments and maybe even surprise us. (Aside: More senior roles need different types of feedback, where the specificity is about helping to bring patterns and trends into focus. But that’s a whole other post.)

Encourage Collaboration

Finally, find ways for people to work together. This can take the form of pair programming, cross-functional projects, outside blogs/talks/research, or really anything that has people of different skillset and skill levels doing meaningful work together. I’m a fan of the mantra that “we all have something to teach, and we all have something to learn.”

Close, collaborative work helps people move from the view on the left to the one on the right (Graphic from @aliciatweet & @rundavidrun)

Nothing drives that point home faster for team members than having them plunk their laptops next to each other and actually work on a problem together using their differing approaches. As a manager, look for ways to help your team internalize that lesson.

How Individual Contributors (IC) Can Reduce Impostor Syndrome.

Position versus Trajectory

The first thing you probably need to know about good managers is that they care a lot less about where you are than about where you’re going. If you’re making progress, learning from mistakes, and getting better at your role, then you shouldn’t worry too much about individual day to day bumps.

This also applies importantly in hiring: it’s not uncommon for folks to somehow think they “lucked” or “conned” their way into a job offer, that they’re not actually good enough to get the job they just got. From a manager’s perspective, this is bollocks. The single most important thing that people managers do is pick their team. Jess Barker does a good job of translating a technique from the original Clance & Imes paper into an useful infosec context: imagine for a moment “confessing” to your new manager about how you feel like you conned them into giving you the position, and then try to imagine the response. Realistically, the response should be something like “I put a lot of thought into who I hire, and there are really good reasons I think you belong here; it’s my job to see that.

Stop looking at your feet; look at the road ahead. Ask “where should I be in 6 months?”, then work on getting there, a little bit at a time.

Embrace the “Thirty Percent Feedback” Protocol

Fear of not being good enough can make us less productive. There’s a strange, destructive feedback loop that I’ve noticed (and been a victim of) where the more we worry about our work being worthwhile, the longer we’ll hold it away from scrutiny and criticism. This can manifest as trying to perfect a project or assignment right up to deadline, then dumping the entire thing in “final” form, without ever soliciting meaningful feedback. Ultimately this is counterproductive because it means that we’re not getting potentially useful feedback at the earlier, formative stages of the work. Worse, that lack of useful feedback increases our uncertainty about the quality of our work, which increases the inclination to work privately longer. Ever felt like you worked really hard for really long on something, and even at the end thought “that’s really not my best work”? Yup, that’s this. It sucks.

That’s a tough cycle to break. One approach I really like is Jason Freedman’s “Thirty Percent Feedback”. Give it a read for the entire concept, but the essence is to force yourself to seek feedback early, and provide context to your reviewer about how “done” the thing is. An outline, a whiteboard sketch, or a chunk of pseudocode is totally fine if you preface it with “this thing is 10% done”. Then you’re inviting responses that are useful at the 10% or 30% mark and can drive important holistic improvements, instead of getting bogged down in discussing things that aren’t important until the 90% mark.

Startup-stock-photos on pexels.com

Don’t Shoot for 100% Perfect

The “X% Complete” protocol actually helps with another challenge in complex fields: there is rarely a single, completely correct, un-nuanced answer. This can lead to analysis paralysis as we try to force a solution asymptotically to 100% complete and correct. Likewise, it contributes to imposter experience as we are best positioned to see the flaws in our own work. I’ve listened to phenomenally talented people absolutely *trash* their own work, even though it was objectively useful and important. Whether it’s releasing code as open source, giving a conference talk, or delivering a PhD thesis, the creator is inevitably the greatest critic. All the work that goes into understanding a topic or building a thing makes us better at seeing failings, which means that the horizon of perfection inevitably moves during the process.

There’s no fix for that, nor would we really want one; it means that we’ve grown while doing the work. To counteract the imposter experience that comes with this effect, change your goal: explicitly do not aim for perfect. Make your goal instead to make things a little better, and also to make it easier for others to make them better still.

  • Don’t write all the code to solve a problem: write enough, and make it maintainable and extensible.
  • Don’t write an entire textbook in a technical answer: write some guidelines and examples, and document the most useful references for others to expand later.
  • Don’t try to cram everything into a 50 minute conference talk: instead, try to convey the improved mental model you have after doing all the prep work, and help listeners get to your level faster than you did.

 

Coda

The entire impetus for this post was my recent change of roles; a good reminder that starting a new, larger job is a chance to be both excited and scared. Does knowing this stuff on an intellectual basis actually help with the feelings? I truly think it can, but the reason this article focuses on technical managers and leaders is because the real meaningful solution is in the culture of an organization. One reviewer pointedly asked if these ideas can work at high performing companies. I think that’s reversing causality; these are the kinds of ideas that *create* high performing teams and companies.

The role that’s currently scaring and exciting me is application security at Netflix. When I have a little more perspective I’ll certainly write about the first sixish months, but in the meanwhile I’ll answer the reviewer by pointing at Netflix’s recently updated culture essay. It really is how the company operates, and the cumulative effects of an entire organization working from those principles and at that level is a strong argument for the effectiveness of building a team around those values (…and if the culture deck resonates with you, you’ll find that we’re always hiring).

Talk Back

These are my thoughts, but I really hope they encourage others to share theirs. Managers — are there approaches that are useful in your team that others should use? ICs — are there things you or your managers do that improve or exacerbate the challenges of imposter experience? What am I not asking about that I should?

Please share in comments, twitter (@coffeetocode), or email (pst @ this domain).

Thanks to the many reviewers of various drafts of this post. 

Lastpass, Risk, and Security Expectations

March 29th, 2017 by Patrick Thomas

Last week was a rough week for LastPass. In his continuing work of scrutinizing security products in general, and recently password managers in particular, Tavis Ormandy has released a series of critical bugs against LastPass (Tweet, Writeups). They’re exactly the sort of nightmare scenario that scares the crap out of users adopting password managers, and especially cloud-connected ones. However, it’s too easy and too simplistic to look at this week and conclude anything sweeping about password managers.

Don’t Lose Sight of the Big Picture

Password managers are a hugely important measure for most people, and something that all information security professionals should be advocating for. It’s not necessarily an easy sell, so it really pisses me off when I see self-professed experts muddying the waters with security absolutism (phrases like “well a hacker could still do…”, or advocating pet approaches that are infeasible for most people). When a vulnerability like this comes around, it provides another opportunity for those sorts of folks to shout and snark and win some personal points, at the expense of laymen who don’t have the ability to put these histrionics in context. So, even if these issues were a death knell for LastPass (I don’t believe they are, but more on that below), then password managers would *still* be a good idea for nearly everyone.

One important-but-often-overlooked benefit of password managers is that it conditions users to emphasize specific passwords less and be more comfortable with the abstract idea of authenticating to a service using some intermediary. That forms one part of the bridge (along with the spread of federated auth and mobile push authentication, among others) toward a post-password future.  

So, 3 bad vulns in LastPass, but the concept of password managers is still a net positive for security. How do we reconcile those?

Let’s put two points together:

  • All software has bugs, and (essentially) all important software has had critical vulns at some point (MS08-067, Stagefright, Heartbleed, Dirty CoW on Linux, iOS Trident, and various IE vulns)
  • Risk is more than just the count or severity of known vulns

I would argue that although the severity of the vulnerabilities were “critical”, the actual risk was relatively low for most users. By the time most people became aware of the issues, they had already been fixed or patched and effective for anyone who was online to receive the update. I don’t have metrics on how long it too the patch to be actually deployed to users, but my browser picked it up before I even got finished reading the published disclosure. For highly-targeted users, that might be enough time to put together an attack, but for the vast majority of the population they had a fix before they needed to care. A non-browser based manager is an option that avoids some of these issues, but I rarely meet a person using one who’s not in infosec already.

For the rest of users, they continued to realize all of the risk-reduction benefits of a password manager (in addition to convenience, etc), and never actually realized significant risk from the vulnerability.

Planning for Failure

There’s a longer blogpost here about the significant attack surface of a browser, defense in depth, and security configuration decisions around that, but that’ll have to be another time.

At the moment, I just want to point out LastPass’s ability to respond to a bug submission, triage it, then develop and deploy and appropriate fix in in time to limit user impact is not luck or accident; I would argue that it speaks to internal engineering values, and that it’s table stakes for a modern software shop, *especially* in security software. Even while he was hammering on them, Tavis pointed out that their responsiveness is a better experience than he’s used to having with vendors. One of the most controversial points in my BlackHat talk from a few years ago was congratulating WordPress on their approach to automatic updates; while it’s easy to dump on the project as a poster child for security vulns, in practice their effort in automatic updates actually do more to keep their users safe than some other projects with fewer bugs.

Final Thoughts

They got beat up pretty bad, but I’ll continue to use LastPass. We don’t often get to see in a very public way how a company handles a security issue, but when the response shows us that they’re thinking and doing the right things both before and during (Lastpass 2015, Kickstarter 2014), then it helps with the decision about whether to continue using them.

Netgear r7000 Command Injection Temporary Workaround

December 11th, 2016 by Patrick Thomas

On Friday CERT issued a warning about the Netgear r7000 and R6400 lines of routers. They are vulnerable to a trivial, unauthenticated command injection via the internal-facing HTTP administrative interface.

proof_of_vuln

Yeah, that’s almost as bad as it gets.

There’s plenty of other reporting for confirmation, exploit info, and further details. However, CERT’s official guidance is, well, not all that practical for a lot of people:

The CERT/CC is currently unaware of a practical solution to this problem and recommends the following workaround: Discontinue use”

Since Netgear is so far mum on when they’re going to issue a patch, and not everyone has the luxury of getting a new router or doing without indefinitely, there are a couple of workarounds. The first is to use the vulnerability itself to kill the admin web interface; that appears to work, though the router will become vulnerable again next time it reboots.

A better solution is to migrate clients to a network that has no access to the admin interface. The r7000 at least (I can’t speak for other lines) has the ability to make guest wireless networks; since the guest networks have no access by default to the admin web interface, clients on those networks can’t be used to exploit it. This won’t work to isolate clients that physically plug into the router. Also, if you’re currently using the guest network feature for isolating some machines from others, then you all get to be on one network until a patch comes out.

So, as a temporary workaround, we can rename and hide the “main” network and create a new guest network using the same configuration options as the old main network. Clients will see the new one and migrate to it.

Step 1: Physically Connect to the Router

Physically plug your machine into the back of the router; we’re going to be messing with the wireless networks, you don’t want to lose access in the middle. Access the admin console (http://[router-address]/, where your router address is probably 192.168.1.1 or 10.0.0.1), and log in using your credentials (admin/password if you haven’t changed it… which you should have).

Step 2: Record The Configuration

Browse to the “Wireless” tab on the left and copy down details of your primary wireless network. You’ll use these to configure the new guest network.

Step 3: Disable Main Wireless Network

Still on the Wireless tab, change the “Name (SSID)” of the network(s) (both if you’re using both 2.4GHz and 5GHz) to something like DONOTUSE. It’s not necessary, but unchecking “Enable SSID Broadcast” will prevent it from cluttering up your network view. Hit apply, and wait for the change to apply and the page to reload.

disable_primary_network

Step 4: Configure and Enable Guest Networks

Browse to the “Guest Network” tab on the left and fill in the details you copied down from the primary page. Ensure that “Enable Guest Network” is checked, and “Allow guests to see eachother and access my local network” is unchecked.  Hit apply, and wait for the change to apply and the page to reload.

guest_network_config

 

Now, any clients will transparently migrate to the new guest networks, and clients on those networks won’t be able to exploit the vulnerability.

So, it’s something, but keep watching for an official patch.