Jamie Dicken's Readme

This README is intended to be helpful for my current or prospective colleagues at GitLab. Enjoy!

My Role

I'm GitLab's Director of Security Platforms and Architecture. There are three functions in my department:

1. Security Research
2. Security Architecture
3. Product Security Engineering

My Story (and security philosophy)

I started my career as a software developer, and I had some rough experiences working with security teams who didn't understand the nuances of practical software engineering. Those interactions were downright painful. Had you told me 10 years ago I would have become a security leader, I would have laughed at you.

After several years as a software engineering manager, my perspective changed. I was really excited about the features my teams were delivering, and I became worried about possible security issues that would threaten to undo all of our hard work. I was fortunate enough to have the opportunity to transition to a security team, and I found it equally frustrating to be on that side of the table. I'd see teams dismiss concerns that seemed so obviously bad.

From there on out, my passion became enabling better interactions between engineering teams and security teams. After all, they both have the same goal: building awesome, quality, reliable, and secure solutions customers loved.

These are some of my strongly-held security beliefs:

• Our job as a Product Security Organization is to enable GitLab product and engineering teams to design, develop, deploy, maintain, and refine GitLab's technogies securely.
• Very few people want to do the wrong (insecure) thing. However, we force people into an impossible choice when security processes or solutions add undue friction or toil to their jobs. Therefore, the best security solution makes doing the right (secure) thing the easiest thing to do.
• The best security solutions are pragmatic and applicable, not theoretical. Security best practices or "best of breed" tools mean nothing if no one actually uses them.
• The best way to build security solutions is to talk to the people we need to use them, build for their optimal user experience, and iterate and improve those solutions over time.

Now in my role here at GitLab, I can continue in my pursuit of pragmatic, high-impact, user-friendly security solutions. The Security Platforms and Architecture team work in concert to identify system-level challenges and risks, design their solutions, and implement them in the product for the benefit of both GitLab team members and customers.

My Leadership Philosophy

• The most important part of my job is to give my team what they need to be successful. That can include go-forward strategies, priority adjustments, removal of blockers, resources, aircover, encouragement, feedback, coaching, a sounding board, tools, training, or anything else. I will prioritize enabling the success of my team so they can deliver great results for GitLab.
  • To my team: If you need something, tell me. Don't hesitate to follow up if you feel it has slipped from my radar. You are not bothering me; this is my job.
• I take a collaborative approach to leadership, strategy, and roadmap planning. I believe the best solutions come from harnessing the collective intellignce of the team, not just myself. I need and want inputs from everyone. I want you to push back on me, and I see productive debate as a signal of a healthy, high-functioning team.

My Working Days

• I am most productive and creative in the mornings. Therefore, I proactively reserve the first 2-3 hours of my day for deep work and focus time.
  • If meetings are required during that time, I'd prefer they be scheduled early or late during the Focus Time blocks on my calendar to preserve a contiguous block.
• I need a midday break to recharge but can often be flexible on when I take it.
• I safeguard time between 5-7pm ET to eat dinner and spend quality time with my family.
• I avoid Friday meetings when possible.
• I generally do not check Slack on my phone so I can unplug and recharge. If you need something from me urgently or off-hours, please use Signal to contact me.

Tips for working with me

• Give me something to look at or read. I am a visual person. Talking is great, but if you want my best ideas, feedback, or questions, write it down or draw a picture.
• I like to self-service. I just may not always know where to look. Don't hesitate to send me links to boards, issues, MRs, the handbook, or other docs so I can ramp up.
• Tell me what you need from me. When I hear about a problem, I immediately want to solve it. However, that's not what you always need or want. Tell me clearly when you want my action, awareness, feedback, brainstorming, or empathetic listening.
• Tell me what to expect. Everyone is a manager of one here at GitLab, and we all have different priorities. Tell me as early as possible if something is taking longer than expected or needs to be deprioritized so I can adjust my expectations or intervene and help. Ideally, don't wait until after a deadline has already passed.
• Avoid surprising me when possible. This is two-fold:
  • If a problem is brewing, tell me as early as possible, even if you don't need anything from me yet. I'd rather have a false alarm than find out a problem for the first time when it has become a raging dumpster fire.
  • I need time to process new information before effectively responding to it. It's best to send me information in advance (ideally async). Otherwise, you will see me take a lot of notes and commit to get back to you at a later time.
• Give me feedback of all kinds. I crave feedback. Tell me when I am doing something well so I know to continue doing that. Also tell me and give me specific examples of where I have opportunities to improve so I can continue my personal growth.