Britt is currently a Project Manager at Facebook. In the past, she led the mobile engineering teams of various startup companies in Israel, the “Startup Nation.” Britt is a Google Developer Expert, a worldwide public speaker, who is passionate about developers and startup communities, and diversity in tech.
Connect with Britt
What is your definition of a good leader?
A good leader demonstrates empathy and humility and finds a balance between vision and execution.
A leader is a visionary who can transform a vision into a plan. A good leader can create a plan that’s bigger than what they can do alone, leaving gaps for others to play a role, without dictating. Leading means facilitating the growth of others, toward a shared goal. You have to choose your battles to do that.
You must be able to listen to the team that you’re leading, as well as the team that manages you, and then build the intermediate layer. You have to see the bigger picture and the details simultaneously. The details help you understand the bigger picture and help you find the balance between theory and reality.
For example, when I was focusing on mobile development, I also thought about the business and the product to better prioritize my work. I learned about the server and architecture to understand the best options for the client that I was responsible for. Since I became a manager or a leader, the proportion of my focus shifted. Now I focus more on the bigger picture but make sure to be hands-on enough to be able to dive into the details when I need them.
The ability to move between the big picture and the details, between vision and execution, between ideal to pragmatic is a great skill for leaders. As you evolve, I believe that you still need both ends.
The biggest change is in the proportions of how much focus you spend on each.
How would you recommend a fellow software engineer transition from Software Engineering to Developer Relations? What are the relevant skills in each field?
Developer Relations, or Developer Experience, which is my focus, is an intersection of many different roles. At least for me, I experience my day-to-day as somewhere between engineering, user experience, product management, support, marketing, community management, and entrepreneurship. And if that’s not enough, you need great people skills! At the heart of it, though, is being a great developer. You have to deeply understand the work process, the way of thinking, and developers’ preferences. The other skills are wrappers on top of your engineering heart.
If being an advocate is something that you want to do, I believe that in one way or another, you’ll find yourself drawn into it. You’ll find yourself conference speaking, blog writing, building libraries, contributing to open source, or otherwise involved in the community. After contributing for a while and enjoying it, many engineers are tempted to get into advocacy despite having little development experience.
My recommendation is to acquire a strong foundation as a developer before taking an advocacy role. All your experiences will reflect in a DevX or DevRel position. There’s endless room for improvement and evolution. However, your perspective shifts when you move from being a developer to thinking about developers and representing them within your company. You’ll be writing smaller educational code rather than a core, complex system. Often this kind of role limits the growth you can achieve as a developer. I’d highly recommend obtaining a strong technical and engineering base, before stepping to the other side as an advocate.
While you’re a developer, try stepping into DevRel tasks before you leap. Explore which types of tasks you enjoy more than others, and work on improving your skills. It will also be helpful for you to start getting involved in the community and start building your professional network. DevRel work is often individual by nature, making its activities harder to learn. The set of tools and skills you bring to the role is essential, as well as your network and having professionals to advise with.
I’d suggest starting as a developer who’s doing DevRel activities, and when you’re ready, flip the ratio and become an advocate who does development activities.
Describe your work-life balance. How do you stay productive?
It took me time to realize that the secret to productivity is to take a break when you need it. I used to fight with myself to soldier through things. But we’re human beings, and we have physical limitations.
For an instant refresh, I take a walk or do a handstand—if you need a boost of energy, a handstand, even against the wall, is magical! It gives you an adrenaline boost and increases circulation. If you do that with friends at the office, smiles are guaranteed.
The idea is to have healthy habits in general so that you can be more productive as a routine. Doing enough things that you love and that make you happy are essential as a base for everything. The entire package of your well-being, as a pattern, will yield positive results over time.
I’m a yoga enthusiast, and I mean yoga as a lifestyle, not just a physical workout. It teaches you many things about life. For example, in yoga, you practice being aware of the resources, either physical or mental, you put into something. Then, you practice relaxing unnecessary effort. It’s a more subtle aspect of being focused.
Many times I’ve found myself diving into a task that I didn’t anticipate will take that long, or trying to over-perfect my work, or taking too many commitments, or being overly concerned about one thing while doing another. The return on investment for these tasks might not be worth it. Yoga is one tool that has helped me learn to be aware of demands on my resources, to direct them consciously.
In terms of time management, I strictly keep an elaborated updated calendar. I block time for all of my personal and professional tasks. Even exercising, meeting friends, preparing for meetings, thinking, anything gets a slot. It helps with having a more concrete sense of time, focusing on what I should do when, and balancing personal and professional events.
What are the three tools you cannot live without as a developer?
First, the online, worldwide Android community. It has been life-changing for me in many senses. I’m not even sure I would love being an engineer as much without that amazing community, culture, and support. Second, Android Studio, our beloved IDE. It’s not perfect but makes programming much more enjoyable compared to other IDEs. There is a handful of the more obvious things, too, like Google search, Stack Overflow, crash reporting, and YouTube.
Which three books have had a lasting impact on how you do your work?
I love reading, although I haven’t done it enough in recent years. Three books that have been impactful on my life and therefore on my work are The Power of Now by Eckhart Tolle, Wishes Fulfilled by Dr. Wayne W. Dyer, and Conversations with God by Neale Donald Walsch. I write this in my head to see all the people who expected a more technical answer and are raising an eyebrow. In the context and timing with which they came into my life, they opened the door to transforming my life. Work is just one aspect of life. Having a healthy, happy and mindful life and soul will reflect in any other aspect of your life, including work.
What resources do you rely on to keep yourself current in your industry?
I got into tech communities to keep my knowledge current while making new friends and creating a professional support network. Not long after the first meetup I attended, I joined to lead the Android community in Israel and later started a Women Techmakers community. Now, I’m fortunate enough to speak around the world, to be a part of Google Developer Experts, and the worldwide wonderful Android community. Most of how I stay current comes from there and from conferences, listening to other people’s talks, and conversations we’re having. I pick up interesting topics and read about them and learn and explore more. Now I’m lucky to have many connections to people in the community and to the devs who are working on features and libraries, so I have enough people to ask questions if I have any.
What is something you wish someone had told you back when you started software development, that you had to learn the hard way instead?
Some things we have to learn the hard way, or rather, we have to learn them by experience. Even if someone had told me what I wish I’d known, it wouldn’t be helpful. One of the challenges I’ve been facing is that you can’t know everything, and you can’t keep up with everything constantly. The world of technology and development is faster and broader than you can grasp at a time, and that’s perfectly fine.
What negative trends do you see on the rise in our industry?
Once in a while, there’s a new architecture that becomes trendy, and everyone’s talking about it and thinking about using it to rewrite an existing project. A recent example is the single Activity navigation in Android, with multiple fragments. Once in a while, there’s a recurring effort to advocate for using that pattern. There are many different reasons it’s not always the right solution. Often Google listens to community trends like supporting Kotlin. However, this is an example where it’s the other way around. There’s an attempt to advocate for this particular trend because it was the initial idea, but the community has been voting differently. The way trends find a foothold in the industry is an interesting process.
An alternative would be to use whichever architecture makes sense to the team. Rewriting is often more painful than expected. Think hard before breaking things that work. Good architecture is very important! You should plan it with an eye toward the future. However, don’t overcomplicate things for the sake of an idea or a trend.
What do you think is one core concept that most software developers don’t pay enough attention to when growing their careers?
I can only share my specific experience. I’m from Tel Aviv, where we have a thriving startup-dominant ecosystem. In that industry, the teams are small, the resources are relatively sparse, the pace is very fast, the focus is more on innovation in a volatile atmosphere. Many devs who grow up in that environment are mostly self-taught and are educated to be confident and run fast. That’s great in many senses, but sometimes the price of confidence is a lack of humility. I’ve often felt that the startup culture seems to cultivate this lack of humility in some way. I don’t criticize it, I understand its relative benefits. However, it’s also important to learn from others and to listen. When you move to bigger companies and face bigger systems and projects, you suddenly understand that there are different rules and motivations.
I think it goes both ways. There are many things that devs in big companies can learn from an experience in a small startup. It’s incredibly beneficial for a dev to experience and learn from both worlds and build a more complete picture for themselves.
The importance of continued learning and a commitment to good interpersonal communication skills is emerging as a theme here. How can a developer implementing these principles move up the leadership ladder?
First, decide that you want it. Some people think they are interested in leading only because it sounds good to them. This is never a good reason to do anything, except for maybe music.
Then, start practicing being a leader in your daily tasks. Later, initiate a small project. It could be a partnership with someone from the company or another team. Most importantly, I believe, is to be present. More than anything, be there, listen, observe, and experience. After a while, the stakeholders expect your presence, and they’ve experienced you as a daily leader, it will be natural to move you into a leadership role. If you listen and observe and experience enough, your perspective, skills, and experiences will be richer and will help you be a better leader.
The Power of Now: A Guide to Spiritual Enlightenment | Eckhart Tolle
Wishes Fulfilled: Mastering the Art of Manifesting | Dr. Wayne W. Dyer
Conversations with God: An Uncommon Dialogue | Neale Donald Walsch