The Chief Architect role — part 1 (my personal story)
I’ve been thinking for a long time now on how to formulate my thoughts about the role of the Chief Architect. I realized that a lot of what I have to say about the role will be my perspective and presented here through my experiences. Since this is the case and since I’ll be talking about how I perceive the role, I figured that the best way to start is simply tell how I got this role. So, this first part will be my story in AppsFlyer and the following part(s) will try and explain what changed over the years, what are my current goals and KPIs etc.
I joined AppsFlyer in June 2012. I remember this distinctly because I started working in AppsFlyer exactly one week after my eldest son was born. AppsFlyer, back then, was just the 2 cofounders — Oren Kaniel and Reshef Mann. I was the first official employee of the company and I always joke that the reason I got the job was because I was the cheapest developer that Oren and Reshef could hire. Joking aside, Oren and Reshef decided to hire me because they just got their seed investment and Reshef, who was the sole developer at the time, understood that he’ll need some help if they want to accelerate building the product. Also, Reshef and I worked together in a previous startup where he was the seasoned developer/architect and I was at a much more of a junior position. Because we had a good dynamic back then and because Oren and Reshef knew that they didn’t have a super high budget, they offered me the position. I was, by no means, a senior developer so my salary expectations were within budget and I ticked all the other boxes.
Life in a startup company at the growth phase is very different from life in a well established company. Titles have little to no meaning and everyone just works and does everything. Reshef was the CTO but, in all actuality, we modeled and designed most of the system together. Same goes for most of the core people that joined us back in the day.
The first time that we understood that I needed some sort of official title, was when we were doing the due diligence process for round B. We were super nervous because we were scheduled a call with Jim Webber and Reshef tole me: “You can’t come into the call as just some regular developer — we’ll need to assign you a title”. Hence, I got my first title in AppsFlyer which was, at first, simply “Architect”.
Suffice it to say that not only did I have no clue about what an Architect is supposed to do, I managed, in the following years, to fall into every trap and pitfall and make every mistake in the book, all while trying to assume the role that the title dictated. This title came, from my perspective, with so much baggage about what it has to mean, that I failed spectacularly while trying to enact every idea that came to mind. I found myself prohibiting the use of technology X, even though we had it in production, just because it was not my cup of tea. I found myself creating technical forums of which nothing actionable came out of. I cajoled where I needed to be assertive and I was assertive where I needed to be understanding and sensitive. I was all the wrong things embodied into a single entity. My only redeeming aspect was that alongside all of these, I was also deeply involved in the day-to-day coding and operations and so I managed to do some actual good work besides all the crap methodology that I was trying bring to the table.
But then things changed. Well, not in one day and not suddenly, but things started to change. Over time, 2 main things happened:
1. I became less frantic, or more comfortable with the title
2. I started doing some research about the role
As for the second item, while I did find some online stuff, it wasn’t nearly enough (hence, this blog post). What I did start doing is reaching out to colleagues in the industry. Luckily for me, I managed to accumulate a good network of AMAZING professionals during my career who are so humble and easy mannered, that it’s really easy to just approach them and schedule some conversations. I gathered a lot of views and opinions and, while not all of them aligned perfectly, I still managed to formulate and synthesize my own perception of the role. Slowly, but surely, I started acting upon more and more of these concepts and ideas, while introducing them into the AppsFlyer workspace.
I guess my main take aways from this last decade of holding the title are quite simple:
1. Understand that it’s OK not to know what you’re doing
2. Don’t try to cover up the “not knowing” via false machinations of power
3. Give yourself time!
4. Learn from others! You’re not the first one to hold this position
5. Always adapt! The culmination of knowledge means nothing if it’s not applicable to you or to the organization you’re in.
The next post will actually dig into the role itself — what does my day to day look like, span of influence, KPIs etc. Stay tuned…
