Skills I Offer Companies

Recently, I was speaking with a company about opportunities they have. It's a regular, casual affair that I do every so often. It keeps me grounded about what the job market is like, and allows me to see if there are other opportunities out there (because if you never look, opportunities never exist). At the end of the day, I like to help people solve problems because it makes me feel valued.

This company made a request that I've never encountered before. They asked me to think about what skills I have to offer a company. At first glance I was very intimidated by this request, as I naturally am not the type of person to talk about myself (glowing or otherwise). But I set forth to enumerate the different skills I have to offer, and have written them below in the hope that others can do the same type of "sales" with their career. To me, this reads like a "Praise Scott" but it's not. I'm trying to provide an objective view of how someone else can measure themselves while still helping me meet the company's request 1. I'll start by boiling down every skill I have into a single sentence:

I help companies optimize, automate and secure their processes so that they can focus on delivering value to customers cheaper and faster.

I never listed security, software development, or The Cloud in there because they are all a means to an end. Instead, I use an engineering mindset to watch for impediments and other dysfunctional processes in companies, architect a solution and then implement the solution. I measure and improve, then move onto other problems. This has worked well in my consulting gigs, and has worked wonders in my full-time positions.

However, this poses a problem to companies. I don't easily fit into the standard hierarchy of a company. Am I a software developer? How about an infrastructure administrator? What about a Cloud security person? I'm all of them, yet none. While it is a bit hippie to say this, I don't want labels to define what I am because that gets in the way of eliminating the waste at companies. I seek senior positions at companies that allow me to continue being technical, while still providing me with a "seat at the table" with the rest of management to help avoid potential future risks. But this is not the natural type of career progress at companies, which I've spoken about in The False Fork. This is what causes companies to initially stumble on when they meet me 2.

When companies take a chance on me, either with work or further conversations, they realize that they can put my skills to use in many areas. This is useful as I can jump between executive leadership and management, then jump again between management and individual contributors. Case in point, I know several security people in high-ranking positions at companies around Vancouver. One of the common threads about these people is that they are not classified as individual contributors. They must delegate and rely on others to implement a solution (be it in software, infrastructure, etc). I don't need to delegate. I'm one of the few Heads of Security that not only works with executive management to model threats and risks to companies, but also implements automated solutions to help secure and reduce human error. The net result of my skill set is that I end up saving companies a lot of money because they don't need to increase their headcount. Outside of money, the company gets a more cohesive team and robust workflow. That's a win-win in my books and it makes me happy.

Here's a sample of the various things I've done in the past year as a Head of Security, dipping my toes in both the upper and lower parts of a company's ranks (in no particular order):

  1. Build KPIs and metrics to show company security posture
  2. Maintain PCI compliance program
  3. Maintain the company-wide incident response plan
  4. Maintain the secure development training program
  5. Maintain the structure and integrity of our AWS multi-account strategy
  6. Perform triage of software systems
  7. Provide answers to customer security questionnaires
  8. Provide AWS technical solution guidance
  9. Provide company-wide threat modeling and risk assessment
  10. Provide product security design reviews
  11. Provide security awareness training and onboarding
  12. Provide secure software development guidance
  13. Provide secure architecture solutions and guidance on GDPR compliance
  14. Provide technical solutions to teams migrating their systems to The Cloud
  15. Provide vendor assessment and review
  16. Perform vulnerability management and triage
  17. Write and maintain the Information Security policy
  18. Write code to automate security monitoring and checks on infrastructure

What I'm trying to show here is that an employee can be much more fluid than just the typical Programmer, Manager and Administrator roles that you normally see. What defines a good candidate is their ability to adapt quickly to multiple roles, especially if those roles are wildly different (e.g. software development vs policy writer). These are all intangible benefits that cannot be easily defined by certificates or whiteboard tests. They are difficult to find and highly sought after, yet they are difficult to peg a salary to due to having multiple skills. But this is what companies really want, even if their job descriptions don't state it.

Lastly, there is currently no job title for this type of adaptable multi-pronged employee, but maybe in the future we just call them "employees".

Footnotes

  1. In other words, I'm a lot more humble and quiet about this stuff. 

  2. This is ultimately ironic because of the recent trend toward a DevOps culture. The movement is intended to reduce or remove the walls between two technical teams, which then results in increased collaboration and more robust solutions. But at least the Dev and Ops teams in companies are within the same realm. Yet, HR and organization planners at companies still see the world in rigid terms. By jumping over these departmental fences, I've achieved what most companies wish they could do: provide a cross-department collaboration between teams that typically see no common thread. So what's stopping the company from doing the same as me and have a more fluid structure? Beats me.