Who the Developer Advocate defends, and how
My name is Alexey Kudryavtsev, and I have been working as a Developer Advocate on the iOS team at inDrive for six months. This job is rare and needs to be better described. I wanted to share some insights on what a Dev Advocate does to help the development process and how you can start doing the same thing.
Background
A well-known formula can describe my career: “The dude was well on his way to success, but Lady Luck had other ideas.” Because initially, I did not want to be a developer, but ten years ago, I could not dodge the bullet, and then I got sucked in. I started learning, developed my projects, and stumbled across Avito. Over there, I spent some time working on product and platform teams. In parallel, I assembled Podlodka iOS Crew, Mobius, and training courses on iOS development.
I joined Avito in early 2017 as a regular iOS developer. Also, starting in late 2020, I advocated informally within the company because I saw a need for that. Management supported the idea, not as a separate job but as an additional role in the development process.
It all happened like this. In early 2020, I suffered a major crisis — I became bored with software development and felt increasingly drawn to working with people. I started taking management courses and reading up on them. At that time, my colleague Katya Petrova joined JetBrains as a Dev Advocate. I began to wonder to myself, “Hmm, what is that anyway? How does that work?” At that point, I was already fed up with only doing public activism, and I wanted to do something for my crew and the people around me.
My interest was piqued, so I began to develop a similar agenda within Avito: building up the community, exploring ongoing development issues, setting up discussions at staff meetings, and preparing speakers, but technically still acting in the capacity of an engineer. I even contemplated going into IT consulting — this shows how little faith I had in finding a position as a Dev Advocate.
At the end of 2021, I left Avito, striking out to run a private practice and do some consulting. Establishing a private practice is a long process, and I started by building a client base.
This lasted six months, and at that point, I looked at the stories posted by one acquaintance I knew from attending trade conferences. He was hiking in the mountains in Kazakhstan, and I wrote, “Looks like you’re having fun up there.” I had already lived some time in Bali, then in Turkey, but this wasn’t my thing, so I said, “Maybe I’ll move to Kazakhstan.” He suggested I try out for the Developer Advocate position with him at inDrive. Just what I needed! So I went for it, passed all the interviews, and got stuck in the new job. The only thing is that I ended up not in Kazakhstan but in Cyprus.
Dev Advocate at inDrive: CustDevs and Current Reality Map
There are two types of Dev Advocates. The first type is people just like Katya Petrova at JetBrains. Her duties and responsibilities are closer to those of a marketing specialist: you have an external community and work with it. For example, you collect user feedback, investigate their pains, problems, and preferences, and then explain how your product addresses those concerns. From this perspective, the role of a Dev Advocate grows out of that of an evangelist.
The second type is advocating for the development group’s internal community. This is me, a person who represents the interests of iOS developers within the company among businesses, product managers, and so on. I aim to foster a strong engineering culture and improve the quality and speed of development. I once described my role to a former colleague, and he said, “Ah, well, you’re like the union chair.” This analogy struck me as particularly apt.
Since the Dev Advocate position is uncommon, the performance expectations are not crystal-clear. During my job interviews at inDrive, I tried to understand what was happening at the company and what needed to be done. I told them I wanted to build an internal community and improve the developer experience and the development culture. I defined my expectations and was the one driving them.
My main goals in the initial phase were the following:
1. Evaluate the status of the development process and find ways to improve it.
2. Draw up a Dev Advocate manifesto.
3. Organize a community of developers.
The first thing I did was talk to all the iOS developers. People complained about things like “this is a pain” or “that is a pain.” As a result, I developed an extensive questionnaire on various design criteria. I finally ended up with almost 50 questions used to calculate something like eNPS, i.e., an indicator that measures the satisfaction of feature developers only in terms of technology, rather than across the entire company. The survey looks like a Google Form containing a whole bunch of questions. People answer how much they agree with the statement on a five-point scale. Next, in-depth interviews are conducted with a sample of people who gave low scores. I asked them why their scores were behind and what could be done to revise them upward. I worked and got to the bottom, recording the answers in the table alongside the respondent’s scores.
Let’s imagine that we learned their pains from all the iOS engineers. You get a lot of information at the output. What should you do now? How do you put it all together? I created a Cause and Effect Diagram in Miro. It turned out to be huge, almost like a crime investigator. It does an excellent job of giving you the overall picture when presented to the business teams as an explanation. Or a demonstration that if we, for example, fix the pain here, the improvement will impact the entire system. I borrowed this technique from Eliyahu Goldratt’s famous book, “The Goal,” which I had read before working at Avito.
I plan to run surveys every six months to track how the metrics change. This indicates how successful I am in doing my job and how the engineering culture within the company is set up.
The first assessment helped me define the basic scope of the work involved, i.e., improving the architecture and navigation in the iOS project together with the DevSpeed team. The survey data shows these were the most critical points in the iOS app that developers dislike and affect business performance.
Other initiatives emerged from this research as well. As a sideline focus, I study how the documentation is structured and how to revise it so that all the developers are comfortable using it. I also assist the cluster head in implementing a product approach within the platform teams. It’s essential to ensure that platform products develop as products rather than just as a set of initiatives. This improves the developer experience and brings clarity to teams and businesses.
Team Maturity Model
Team Maturity Model (TMM) is the second major project. I’m doing that together with the Process and Practices team. The project is also responsible for fostering the engineering culture within the company. In a nutshell, this model is used to evaluate teams’ maturity. It consists of four levels, from zero to three. At level zero, there are no practices that the team adheres to, whereas, at level three, the couple lives in a world of rainbows and unicorns where everything is perfect. The targeted level is the second one, where the team is said to have certain practices in place. This gives us the basis to believe that the team is mature.
For example, there is a model for following the testing pyramid. The tests run by the team can be poorly written or based on the pyramid to ensure the best quality/labor ratio, which is the metric being evaluated here. Or for instance, the TTM can track how much time a team devotes to tech debt. There are many process-related factors to consider, such as following Scrum, Kanban guidelines, etc. You can learn more about the experience of implementing the TMM at Avito from Misha Sukhov in his articles posted on Medium.
inDrive has its specifics to consider. For this reason, we put in so much effort to thoroughly analyze the performance of the model and the related process within the company. You can’t apply your experience to a set of new realities. That’s different from the way it works. So I get in touch with the coaches, QA people, or backend staff and make sure that the questions and the levels are described and worded as crystal-clear as possible and tailor-made to suit our realities.
Dev Advocate Manifesto
Every role should be clearly described. With Dev Advocates, the situation is tricky and subtle as this job is often interpreted differently in different companies. Plus, it overlaps with three other areas: Developers, TechLeads, and DevRels. Who should be responsible for what to avoid conflicts? How are they supposed to interact? Even back then, during the job interviewing process, I knew it was advisable to describe the role in detail to synchronize the expectations of all concerned and ensure that I was doing what I needed.
First, I described the concept, the advocate’s areas of responsibility, and products. Example, areas of responsibility, include:
- Internal and external communities.
- Improvement of developer experience.
- Implementation of new approaches in development, as well as growth and development of engineers.
All of these things become weaknesses for cross-functional teams.
In my role, the advocate performs essentially the same duties as the Head of iOS at many other companies but is more focused on meeting the needs of developers. Plus, they don’t have to deal with responsibilities such as people management, budgeting, or “firefighting.” For example, advocates are quick to run and put out a fire themselves. Instead, they look at things systematically and say, “Okay, what does it take to put out a fire and ensure this situation never happens again?”
Let’s imagine a classic Tech Lead regarding the growth of engineers. They are usually well familiar with the one platform they have much experience with. But if they work on the backend side, they might be approached by an iOS developer who would say, “Help me upskill,” but this isn’t work. I can build a platform, so iOS developers can level up each others’ game and keep the pain off the Tech Lead’s back. The same goes for iOS onboarding. I’m building an effective system of creating an immersion experience with the platform that the Tech Lead can leverage without making up their own.
My goal for the first quarter was to build an internal iOS community. I made project meetings a regular practice, described the processes, set up the pipeline, and picked out a few people to help me. And now we’re just rotating, having meetings once a week.
The community is gradually phasing out the “broadcast” format, where one person “broadcasts” a message while everyone else listens. Now you can suggest a discussion item for a meeting agenda and say, “I have a pain point,” and a general discussion around this will result in change.
The ideal process flow is when creating a change, and the person will collaborate with their other colleagues and get to know each other better because they work in different teams. This makes sure that people don’t feel alone and isolated. In cross-functional and distributed teams, especially when working remotely, the situation where you are the only iOS developer and need someone to discuss a professional concern with is a big problem. This also becomes an issue for businesses because people get tired, cut corners developing the platform, and eventually leave.
The manifesto is how things should be so that the advocate becomes a catalyst for engineers’ initiatives and processes around them to improve design quality. Globally, I have two goals to pursue: to make developers feel comfortable in their working environment and to make others want to join inDrive.
External community
You build the insides first; only then can you show and reveal them. Companies often do it this way: “Why don’t we bring up this issue, hold our meet-up, and hire some new employees?” And then, the person joins the company and gets disappointed. They’ll work here for a while, but it’s not a win-win situation. This is different from our approach.
Instead, we are invested in our internal community and expect that, sooner or later, this will produce positive results. My colleague Aziz’s article on Live Activity was recently nominated for a TechnoText Award. The idea for that piece came up while he watched WWDC and wrote in a chat session, “Oh, that’s a cool feature.” I replied, “Aziz, will you get this one down in code?” And he did, with some other colleagues lending a hand.
This idea came from the inside, got recognition, and we shared information about it. This is how we work with the external community, i.e., I identify promising initiatives from communications between the developers, and we do something about them. And then we always remember to bring this up and pass them on to the Developer Relations team.
When it comes to communicating with developers from other companies, I’m less immersed in that now than when I was doing conferences. But when necessary, I have a social graph and pull up the person I have to talk with. We’re now working on the architecture and navigation design, so I called this engineer from Apple, asking, “What’s up with your architecture? What kind do you use?” I checked in with this other dude regarding the navigation framework and gave one of our guys the contact information for someone to consult with.
As a sideline gig, I’m setting up CocoaHeads in Cyprus. Using the social graph as well, but on a smaller scale because it’s a local activity on a small island. Asking the guys, “How is your development project coming along? What are you doing?” It’s essential to understand how the iOS industry is doing, what exciting things are out there for re-use, and determine whether we’re headed in the right direction. Why reinvent spaceships when the expertise is already available from your peers? You can share your stuff on the sidelines as well.
How to become a Dev Advocate
There is a risk that, in most cases, a good developer will not make the best Dev Advocate because this job will be of little interest to them. A developer’s mindset often (but not always) requires that, at the sight of any issue, it should be tackled and resolved as quickly as possible, being transformed into and approached as an engineering problem.
To become a good Dev Advocate, your mindset should be refocused on addressing global challenges. Rather than think about development, your thinking should be attuned to the psychology of people and processes. My knowledge and skills in project and product management and coaching techniques help me a lot here. This allows me to get people together, launch a process, and keep track of the metrics.
But an engineering background is essential and “a must.” Preferably, it would help if you had some experience working on platform teams or creating a product for developers. With that under your belt, you communicate with them as users and have empathy and understanding for their problems. And then you inevitably drop out of the paradigm of solving only engineering problems.
If we take a case where a person is willing to become a Dev Advocate within their company, the first step for them to undertake might be to try their hand at building an internal community. As you make a community, you establish yourself as a leader. And a leader is a person who represents the interests of a group and does everything they can to promote them. As a consequence, you seek to serve others more than yourself.
Books on community building have helped me a lot in my time. Two titles merit special mention here — Building Brand Communities and Get Together. My former colleagues also were a big help and shared a lot of good resources.
A step-by-step guide to starting a career as a Dev Advocate can look like this:
- Gather up your community, and listen to the pains experienced by people.
- Try to run one Activity or do a project.
- The community will begin to take shape, and then at some point, it will become able to function without your involvement.
That’s one way to go about it. But, as described above, there is another approach to consider, i.e., to get into a Dev Advocate role from the marketing and public brand side. You can start speaking, doing conferences, and doing podcasts to do this. Katya Petrova is in a better position to tell you about this.
I have told you a little about the Dev Advocate role at inDrive, what it looks like, and what I’ve done in six months. But this is just the beginning of the journey to improve DevX within the company, and I will certainly keep writing about our further progress down this path. I will happily answer any questions in the comments if you have any questions.
