Izar Tarandach - Sr. Staff Engineer at Datadog

Izar Tarandach: personal site, Twitter, Mastodon, LinkedIn

Tell us a little about your current role: where do you work, your title and generally the sort of work you and your team do.

Right now I am a fresh Sr. Staff Engineer at Datadog, where I work in the Cloud Security Products team helping develop new security solutions and approaches. For most if not all of my career I have been “Security Something Or Another,” both as an IC and as a people manager, holding many Staff+ and adjacent (or parallel. Or same-job-different-name. Go figure.) positions along the way. I’ve founded start-ups (and saw them go where they went) and I’ve been part of huge organizations.

How do you spend your time day-to-day?

Being “the new kid on the block”, right now most of my time is spent figuring out what is what, learning as much as I can about the organization, the products, the philosophy behind both the product development and system development, and beginning to identify areas where I can help. Much if not most of this effort happens about reading existing documentation, “playing” with the product, and most important, meeting with and learning from the people.

Thinking back, this is a constant I have seen at Staff+ positions - there is a huge focus on mapping the topology of the organization, both in terms of hierarchy and composition but also in the sense of “how do things actually happen around here.” Then you need to find the places where you can exert pressure the right way to move levers to the right positions and help objectives be achieved. These levers certainly take the form of technical leadership, but more and more I see the need and the usefulness of them being “technical-plus”, with the plus involving processes and people. The Staff+ position, in my experience, gives a unique perspective about how the engine runs and what parts to oil and what parts to tune so it runs better. My experience at the different levels of organizing and organizations has led me to believe that the Staff+ role is the one where the diagnosis can be as important, if not more, than the cure.

It looks like you moved into a Staff+ engineering role after time spend both as a founder and a Director. Can you talk a little about the process for moving into that technical leadership track?

Looking back at my career, almost all of my leadership positions have been technical and, for the lack of a better word, mentorship related. My forte is not budgeting or working with prices; I can do it but I found out that I really enjoy aligning people and systems and processes into a well working symphony. I am happy that my current position lets me explore how the experiences I have had as a founder, a technical leader and sometimes a people manager and channel them into something like technical leadership.

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

Curiosity, perseverance, and knowing I am not always the smartest person in the room. Those three factors let me pursue new shiny things, keep at them when I can’t understand or make them work, and most important of all, keep a beginners’ mind and learn from others. I have been really lucky to have had impactful role models in my career, some that I aspire to emulate and some that I really try to do the opposite; the important thing is that all of them had something to teach me. My work career spans 3 countries, with daily interaction with people from many more; that led me to openness towards other cultures and other ways to do the right thing.

Some of Izar’s Public Work

• Threat Modeling: A Practical Guide for Development Teams

• No, We Won’t Be Threat Modeling

• Threat Model Every Story: Practical Continuous Threat Modeling Work for Your Team

Where do you feel most impactful as a Staff-plus Engineer? A specific story would be grand.

Security is my bailiwick - in a way or another I have been in a Security position for most of my career. Inside the vast domain that is Security, I have taken a deep dive into Threat Modeling, which is “analyzing representations of a system to highlight concerns about security and privacy characteristics” (Threat Modeling Manifesto definition). That has put me in situations where I sometimes need to offer advice to teams where they may see it as interfering with their work or “calling their baby ugly.” It has been a long personal journey to figure out how to work this the best way so they see me as an ally trying to make sure their baby thrives rather than a critical problem seeker.

I like to tell the story of a product team I advised once upon a time, when I learned that there was an email making the rounds: “Please don’t speak to our security advisor; everytime he learns something new he finds new problems”. That team saw me as an adversary, when my goal was to make them more secure. The problem was in me, not in them - they wanted to put the best product out - but our approaches diverged. It was not even a communication problem, it was seriously a perspective one. I was pointing at anything I thought was a problem and making it a P0. They needed to get the product out. Until I learned to calibrate and understand their values, I was a bad advisor; I was a pebble in their shoes. Once I started measuring things with a more appropriate stick that took into consideration not only my view of security, but theirs of product development, things took a different turn. There were so many new skills and changes I had to exercise in order to get that working, I think it was one of my biggest learning experiences.

Can you think of anything you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done before reaching that title?

Much of my work as a Staff+ and Principal has included pathfinding, “going into the jungle“ without knowing where things will end. That kind of exploration requires not only a liberty to poke at things, but also a longitudinal view of the organization and its objectives that helps guide the poking towards where the most value may reside, and being able to do that with a set of peers (like the ones I was and am fortunate to have) that can question the approach and offer alternative points of view is invaluable. That’s the kind of freedom, visibility and cooperation you start getting once you reach Staff level, I believe, and it makes a difference. The scope goes up, the depth goes further, the responsibility is bigger and the uncertainty becomes certain.

What Staff Engineer archetype do you consider yourself? Why?

I’m not very fond of the archetypes approach. I prefer a mixed set where one can be a bit of this and a bit of that. I see myself as, and have received good feedback as a mix of Solver and Architect.

How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role? We’d love to hear a story.

People much smarter than me have said in many ways that the best way to learn something is to teach it. I try as much as I can to mentor people who show interest in what I can teach or just need a leg up in their career development; I truly enjoy that part of the work and I feel like a proud papa when they succeed. Over time I have met amazing people who became mentees who became friends, and I’ve learned from each one of them at least as much as I taught them. I really cherish being able to do it.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

I am incredibly lucky that I have met so, so, so many amazing people in these last 30 years or so that I have been doing what I do. Smart people, caring, patient enough to share some of what they know and how they learned it. The list is, I am happy to say, way too extensive to put in here. Most of them are still in the prime of their journeys, and I look at them with interest to learn even more. At this step in my career, if I had to answer “who I want to be when I grow up”, one of the names that jumps up immediately would be Brook Schoenfield who not only is a much, much, much accomplished security architect, book author and thought leader, having held leading positions in some of the biggest companies around where he was the first creating much of what today is common in Security, but also and before anything is a true mensch, exemplifying a career where he cared not only for the bits but also for the people that work with him.

For a book, Tanya Reilly’s “The Staff Engineer’s Path” is hard to beat. She is herself an incredible Principal Engineer (and a much valued role model!), with so much experience and so much to teach. The book has content that applies for the new Staff engineer as much as for experienced ones, practical advice as well as more “think about it” material that will surely be valuable to all interested in the subject.

What about advice for someone who has just started as a Staff-plus engineer?

Curiosity didn’t kill the cat, curiosity taught it a new skill and showed it how to do new things with it. Even if that skill was how to fail. Stay curious.

Do you spend time advocating for technology, practice, process or architectural change? Can you share a story of influencing your organization?

All of the above. In my role as a threat modeler person, at times I have been asked to introduce Threat Modeling as a practice and a value into organizations. The problem is that there isn’t a “right” way of doing Threat Modeling. There isn’t a “right” way of measuring the outcomes. There isn’t a “right” way of knowing if you’re doing it right!

That, let me put it mildly, can make things difficult. Again, it is a matter of perspective. Once I went into an organization with guns blazing, here’s how you do this, here’s what comes out of it, here’s how you people will do it, call me if there are any issues. Well, it didn’t work. Turns out that the organization was not yet at a level of maturity that enabled it to support the threat modeling process and to extract the most value from the results. I had to stop myself, learn where the organization (and the teams that made it - the many teams) had their compass pointed at, and then slowly start introducing the ideas, building up the momentum for a time when they would be able to, without almost noticing, introduce Threat Modeling as a process that worked for them, in the way they already did their development and that they could turn into a repeatable, measurable process down the road.