Team management practical wisdom, Codemotion Milan

Being a team manager is a big responsibility, regardless of team size. What are the best practices to make the most out of this role? Where and how management and leadership converge? How to manage difficult moments and decisions? A brief history about what I have learned, errors included, with an eye to technical teams.

Slides

(Codemotion Milan, 29 November 2018)

Google Developers community management culture

Working with communities, at scale, means working with a decentralized team of people in different geographies, with a similar, but diverse, professional background and expertise level. One of the few working strategies to keep all of us aligned on main goals, while fostering local ideas and adaptive strategies to better fit the local ecosystem, is to define and maintain a common team culture. Recently I was asked to present what is the Google Developers community management culture and key insights in front of our team of community builders, people like me in charge of supporting tech communities all over the world that want to share knowledge on Google technologies during their activities. Here a list of my main takeaways.

Why we do what we do and what is our role?
Dev communities help to solve the growing complexity of the technological landscape, adding a very unique social flavor. So, as community builders, we accelerate learning, cultivate culture and collaborate with communities on a shared mission and goals. We help them to be more successful because, ultimately, this helps Google dev products to be more successful. And because we love communities.

Community leaders first
We should already be used to the “User first Google’s philosophy principle. In our case, it translates to “community leaders first“. They are our primary focus, and should be treated with respect. We have to build a two-way and mutually useful relationship. All the rest follows.

Embrace goal diversity and work on the sweet spots
We have to recognize, and acknowledge, community leaders are driven by their own goals and reasons, and our company goals cannot be pushed to them. Instead, to keep this relationship prolific and sustainable in the long period, we have to base it on collaboration and independence, searching for overlaps in goals and build on these sweet spots. And we should be the first ones doing that. Sooner or later, opportunities will come.

Be a transparent and servant community builder
Community leaders know very well we don’t do this for charity. Like any trust-based relationship, it’s important to be transparent with them and communicate openly. We’re here to serve them, and not the other way around, as communities can exist without Google support, but we cannot exist without communities.

Treat them equally, as the ecosystem is our highest value asset
Some communities are more mature than others, some are quicker to execute, some able to have a bigger impact. It doesn’t matter, because what we value the most is a healthy growth and development of a vibrant community ecosystem. So they all are our beloved community leaders and we need to support all of them in the mid-long term, regardless of how they could help to reach our goals in the short team.

First save their time, then ours
In case we need to make a choice between saving our or their time, pick theirs: we’re paid to do this job, they volunteer their time. First, we need provide a coherent system maintained by a culture to interact with us, avoiding community micromanagement: in the long period, it will save a lot of time on both sides. Then, we can always optimize something: write easy-to-read, timely and useful communications, avoid asking data useful only to us, etc. Finally, if they don’t know about our initiatives, or they missed something, we assume it’s our fault.

Be data driven and restless student
Getting meaningful data out of communities is hard, but it doesn’t matter. A better knowledge of the community ecosystem helps us to make more informed decisions. We can be brave community builders, trying new things to improve our culture of community management one step at time, relentlessly, for the good of our communities and for a better collaboration with them. Every time we collect a new learning, positive or negative, we should share with each other.

Have fun
This job keeps a consistent part of our life busy: make the best out of this time, having fun while cultivating our passions.

If you’re curious about my life in Google, there are other posts to read.

How to structure useful 1:1 with your team

One of the core components of my manager toolbox is the 1to1 meeting (or 1:1, or one-on-one, or 1on1, face2face, f2f, …), a recurring appointment each team member has with me. How to structure and get the most out of it?

At the beginning, it’s important to set the reasons to spent this time together and the tone. The meeting is all about the team member: their needs, frustrations, feedback, ideas and career growth are the topics of discussion. The 1:1 is a chance for the team member to bring the problems them need help with, and a chance for me to learn more about their work. As consequence, I empower them to be the owner of the agenda and structure it around a unique, core, question: “What can your manager be helping with?

Once the objectives are clear, I set the cadency of the meeting to create an habits, generally weekly and one hour long. Unless something more urgent happens: rush hurts the quality of the conversation, so better postpone to a less busy moment, or shorten, or even make a phone call if there is something urgent to discuss and other conflicting activities.

Especially for the first times, I prefer to use a format that facilitate the discussion centered on the previous question. To make everything more collaborative and transparent, I have a shared and confidential document with every team member that we can both pre-populate, with this general structure for each meeting we have. The use of “you” is important to empower the team member, instead of a more abstract 3rd person.

  • Challenges: Leverage manager support to remove roadblocks and enhance your impact, receive coaching and guidance in areas where you have a challenge
  • Issues and Concerns: make manager aware of any personal or professional issues you have
  • Review core and project progress: an opportunity to demonstrate your impact, to share what’s going on and what’s coming up
  • Performance expectation and feedback: from the manager, to the manager
  • Career and personal development: support in developing your career, skills and knowledge
  • Misc (Out of office, lead updates, other unplanned discussions)

It’s important to constantly remember the point on career and personal development and, once in a while, it becomes the main topic of the meeting. Again, to facilitate the discussion, it can be useful to have a career worksheet template to use as base, touching these main areas:

  • Personal reflection
  • Goal setting
  • Action planning
  • End-of-quarter retrospectives

As final touch, I remember the team it’s always possible to change the structure of our 1:1 and they can schedule extra 1:1s outside of our normal schedule, as I’m here to serve.

Bonus activity for one of the 1:1: ask the reasons they do what they do.

What does a Developer Relations Ecosystem team do?

Some companies have evolved the Developer Relations area to a point they have a specialized orgs. Google is one of them, and I work under the Developer Relations Ecosystem team. What does we do?

Sticking to the broader DevRel goal (see the definition from my colleague Reto), I consider ourselves a connection layer. On the one side, there are the different Google Product Areas (PAs) like Android, Cloud, Assistant, etc, and we solve for them the complexity of dealing with local tech ecosystems. This scales global initiatives by engaging local developers. On the other side, that “articulated” tech ecosystem, where we’re often seen as the “last mile” between them and Google, brings valuable insights back.

How do we connect these two sides? We apply a 1:few:many interaction model. I see us (the one) as “passion multipliers“. We take Product Areas goals and, with a touch of magic, translate them for the “influencers” in their local context (the few), supporting them in doing even more of what they love doing. It could be organize tech communities, share their knowledge on Google techs, run amazing 3rd party tech conferences, solve people’s needs in innovative ways using company’s products, deliver best apps to clients and much more.
The more successful our audience is pursuing their passions, the more vibrant, mature and fun the company 3rd party tech ecosystem becomes (the many). A win-win situation I love and a way to implement Google’s philosophy “Focus on the user and all else will follow”.

We’re a tech team in the relationship business, at scale. Thanks to the trust component of our relationships, we have the rare privilege to be exposed to global and reliable first hand insights about developers all over the world. They let us know who they are and where they are; what they love and hate about our company’s technologies; emerging and descending trends; how they’re organising tech communities in every country; their success stories supported by our technologies. Because of this knowledge, we can be even more effective in building relationships and matching PAs needs, creating a virtuous circle.

Diversity is also deeply embedded in our team culture: there isn’t a project that can scale worldwide without considering how diverse the world is. For example, mentorship activities are very effective in some cultures, and totally against the mindset of others; developer and community dynamics in cities with millions of people are very different from cities with thousands; running a hackathon in Italy is different from running one in Nigeria, etc.
So, we naturally recognize the value of diversity and we focus on it, across our programs and audiences. What does diversity mean? Gender, culture, race, religion and many more.

From a team structure point of view, we approximated the complexity of the tech ecosystem splitting it in several audiences, like tech communities (GDG and all the other communities), Tech Experts, Startups and their developers etc.
Thus, we created work streams to deal with each one of these audiences, organising ourselves around two main roles. One gathers Program Managers that work on these streams at a global level, defining the infrastructure, strategy, goals, tools, budget etc. The other is made by people like me, called Regional Lead, in charge of executing these programs locally. It’s the implementation of “Think globally, act locally” strategy.
Maintaining a bi-directional communication channel between the roles is fundamental. Global work streams cannot evolve without the inputs, knowledge and experience from the local ecosystems provided by regional leads, while high-level directions from global allow us to operate in an aligned way despite we spread all over the world.

The most difficult challenge is linked to Ecosystem’s core: in fact, building these relationships at scale is a never-ending, tailor-made and time-consuming process, as the ecosystem is a living creature in constant evolution. In addition, after a certain point, we suffer from “reach-ability bandwidth” saturation: we simply cannot interact with additional people anymore and with all the amazing stuff they’re doing.

Apart from company PA goals, I personally see another important behavior for being a good citizen of the ecosystem we deal with: act as superb connectors. Pentland wrote in his book “It is not simply the brightest who have the best ideas; it is those who are best at harvesting ideas from others. It is not only the most determined who drive change; it is those who most fully engage with like-minded people. And it is not wealth or prestige that best motivates people; it is respect and help from peers.
Connecting people with similar passions helps the ecosystem to grow and improve in the mid-long term. It’s something you cannot control or measure, but years later, someone that has done something worthwhile your admiration will tell you: “Thanks to your suggestion all those years ago, I’m here now”. Priceless and crucial, this is one of my duties, and my passion!

If you’re curious about my life in Google, there are other posts to read.

Learnings after five years in Google

Recently, I had my fifth Googleversary, meaning 5 years have been passed since I joined Google. In retrospective, it was a flash. An intense, extremely challenging, always learning, positively stressing and joyful flash. A lot has happened and I want to write down some notes on the most important learnings I’ve had.

Disclaimer: this is not a post on Google culture, there are several and more authoritative voices than mine, and the complexity of a company made by tens of thousands people all over the world doesn’t allow to have a “common culture and experience to fit them all”. This is, simply, a wrap-up of my very own peculiar journey.

I spent these 5 years in Developer Relations team we call “DevRel Ecosystem” with the mission of nurturing influencers and their communities all over the world to boost Google technology advocacy, adoption, quality, and perception. So, interacting with tech communities, startups, third-party tech conferences, universities, organising Google-own events etc. Partially a manager of community managers, partially a lot more. I often sign emails for my Italian colleagues with “Your friendly neighbourhood dev-sitter“.

Learning day by day

In DevRel-focused conferences I attended, we often define us a “community of practitioners” because we’re literally crafting our own job day after day, and very few companies have the DevRel org structure and needs Google has: definitively a job with no repetitive tasks and where personal initiative is a key element. For me in particular. I left my job as Android dev in Funambol on Friday afternoon after a mojito party with colleagues, flew to San Francisco 14 hours later, on Monday moved to Mountain View for my first day in Google for the welcome training to collect my badge and laptop. Then the second day back in San Francisco attending Google I/O, thrown into the nonsense madness of such big events, with no idea about my role there, who my team and my colleagues were, even where my manager was and how to reach him. With 5000 attendees asking me any sort of things because I was a Googler. The week later, back in Italy, during my first one-to-one call with my manager, I asked him “Now that I/O is over, what’s the next step for me?” and he replied: “Well, we hired you because you know the Italian dev ecosystem better than me, so it should be you telling me”. When the meeting ended, I banged my head on the table multiple times, thinking about my life just 12 days before, when I was an happy Android dev, shielded from the external complexity of the world by the comfortable shell where every dev “code, breath, repeat”.
So, from that second day in San Francisco onward, I’ve been exposed to a continuous and unique learning experience with lot of autonomy. Everything has been a great playground where exercise my Kaizen approach to life, to learn and improve. But it hasn’t been easy, kind of an endless and restless run, where I was alone and on the wild for the first three years, until I had the first team-mate sitting my side, sometimes a marathon but often a sprint, always with a potential stress factor behind the angle. I still enjoy it because the way I am, but I recognise is not for everyone.

Relevancy, focus and happiness

Easy to imagine, this generated struggle in my work-life harmony, especially at the beginning. Because I’m more toward the perfectionist side, I believe there is always room for improvement: in crafting the idea, organising a project around, execute it and sharing back the experience. And the cost of this perfectionism is my time. During some stressful moments, my whole day time. Luckily, two epiphany moments helped me to find an initial harmony.
First one happened when a colleague said “This company is a machine that produces more tasks than you can manage“: I understood I have to accept the fact I cannot do everything I would love to do within the full and huge spectrum of potential activities available. So, being good in the prioritise only the very relevant balls you want to juggle with and understand what is that relevant in the company context were crucial steps to grow. In DevRel org, and in Google in general, we have so many projects, opportunities, stimulus and extremely unique challenges not yet solved that, added with the positive anarchic culture of the team, it’s easy to lost the north if there is a lack of focus.
The second moment was when my first son was born. In choosing how to spend the non-working part of the day, I’ve always been driven by the approach “use your time to find happiness pursuing your passions and embracing new learning occasions outside your comfort zone“, and being a father added duties that changed the entire time balance of my day. After some try-and-make-mistakes cycles, and thanks to meditation, I understood differentiating among family, personal, work, relax etc time had no sense, that my day is a continuum and finding what’s really relevant in different contexts, over a period, and stay sharp-focused on these things only, and literally nothing else, creates the harmony I need, allowing me to don’t feel overwhelmed, but happily busy and alive. It’s impossible to catch up with everything, quality over quantity and whatever makes people around me happy is time well spent: my family first, then all the rest in no particular order, including my team members, my users, my friends, my manager, myself etc. I haven’t found the perfect harmony yet and it still happens I need to sacrifice some extra hours of sleep but, if I look back, overall life now is better than before.

Servant leadership and team culture

I started to lead a team of 6 people, more or less two years ago, and I discovered that is not an easy task, it’s time consuming and it’s also one of the most empowering experiences I’ve ever had. Leading the team, for me and probably also because of company culture, has something in common with the role of a community manager: you are there for the development of the community with no room for your personal ego; you’re successful only if the community is successful and community members are happy to be in your community; you cannot change or control community members, only guide and help them evolving with your influence and support; a sense of community (team culture) is necessary for the community to survive in the medium-long term.
Because the way I am, my team management style resonates very well with the concept of servant leadership, and the team culture is the glue that keeps us connected together. A culture where it’s OK to make mistakes, but always new ones, where we all have a clear vision, concrete goals and we run all together toward them activity after activity, where we retrospective what’s happened and plan the future all together regardless our roles or seniority, reserve a little bit of our own time to experiment with new things, disagree and commit, provide gentle feedback to others, focus on our own sweet spots and try to connect them together in order to cover as much as we can as a team, know the reasons, the core whys, we are doing what they’re doing, in order to match personal passions with team duties, lead by example.
A team where we share and discuss the ideas we have to improve and solve the projects we’re working on, because when ideas circulate, everyone can enrich them and an open and sharing culture allow to achieve more, both from results and personal growth side. It’s not easy to achieve that while we’re spread across 4 countries and 2 different time-zones, but it’s one of my main responsibilities as manager to allow circulation of these things, and the chats I have with everyone, at least one hour every week, a weekly meeting to share and plan together the next days and a 2-days in person summit three times a year, all together, have been making the job, at least until now.
Merits are assigned on the ownership and the execution of the projects and I would consider a personal failure if a person joins the team and later leaves it with no new ideas, new tools, new experiences, new perspective in its pockets. Does it means we’re all good friends? No, but we like to spend time together, to solve and work on professional needs and, sometimes, also for personal pleasure.
Among the many resources on the topics, I suggest the podcast “The Andy Stanley Leadership Podcast“, a monthly source of invaluable resources on leadership topics, and the book “The 4 Disciplines of Execution“, that helped me to align the team toward unique goals and improve ways to pursue them, quarter after quarter.

Forgiveness, charisma and data

Moving inside a corporate environment isn’t always easy, and I’ve experienced moments where I felt like chained to the ground due to other colleagues behaviours and decisions, luckily very few times during these five years. Once one of my managers told me “When you have such energy and you know what you’re doing, you should ask for forgiveness and not for permission“. It was an important lesson of humility, trust and maturity together, even if I don’t think it can work in all the companies, but Google culture may tolerate that, sometimes and if you choose carefully.
Nowadays I prefer the “influence with charisma” approach, even if it’s slower and more difficult to exercise, but allows a broader impact and when politics start getting into the environment, it’s the only way of achieving what I hope to be able to achieve.
On top of both approaches, I’ve learnt availability of data to support my opinions really can make the difference. Quoting Barksdale, “If we have data, let’s look at data. If all we have are opinions, let’s go with mine“, so having good data to use can put everyone in an advantage position. Of course collecting meaningful data is another art to master, requires discipline, it’s an ongoing process to improve every day and often not easy to keep focused on the non-vanity metrics or researches. And have a good narrative to tell others that data is equally important.

Remote working

Another element I now consider a crucial asset of my job is the possibility to remote working. I have two hours commute time daily and, even if I’m able to work the majority of this time, even if I value the fact I arrive at the office already focused on the next steps and I can dedicate extra time to cool down or finish some tasks on the way back home, even if offices in Google are, generally, among the best I’ve seen in companies, working remotely has way more value than money and time saved. Context matters, and be where I want to be, in a park breathing the blooming spring smell, relaxed at home, next to a person I care, provides an incredible flexibility everyone should be able to experience.
It doesn’t come for free, of course. First, and foremost, a proper remote working culture is required. It starts from a personal responsibility to commit your duties, be easily reachable for the people that need you (hardware equipment, bandwidth quality and reliability, time availability etc), soft skills to interact with the others over a remote conversation, team processes calibrated around this scenario and more. Google offers rooms where I enter, press a button on a display on the table / monitor and I’m connected with the other sides of the meetings: it’s fantastic to have this no-entry level barrier to interact.
Finally, a good balance between remote and office work is necessary, as remote cannot totally substitute in-person presence: the chance others can enrich what I do is simply not available when I’m far from them, coffee machine chats are really a thing, the importance of bonds with colleagues outside working topics, how quickly some questions could be solved simply going and speaking with someone.

Value diversity and have an open mind

Google has immersed me in a hugely diverse environment that can really boost everyone’s personal growth, because of a real multicultural, time-zones and countries spread workforce, where is possible to still make new discoveries after years. I don’t mean only gender diversity, but the whole set of diversities. As for remote working, simply putting together diverse people doesn’t make the magic, and there are several prerequisites needed: among the many, the perception of an open environment, in term or reciprocal respect and trust, freedom to be themselves, possibility to make mistakes, availability to receive feedback and suggestions, understanding of implicit biases we all have and how to deal with them, a personal availability to put additional care to what’s happening around us, that our opinion is simply one of the many and not always the best one, the ability to say a sincere sorry when mistakes are made.
Travelling is another great possibility I have, and inside my team is relatively easy to go everywhere in the world if there is a reasonable working reason. Of course I try to avoid serial travelling (mostly because of I have a family), but meeting colleagues where they live and, thanks to my job of manager of community managers, I can breath the local environment and meet local people, listen to them, go where they go, be a guest, not a tourist, in the local ecosystem.
Nothing more than a semi-empty mind, ready to be filled by the context and able to adapt to it, helped me growing. Because what’s around me is the mirror reflecting, so shaping, who I am.

Put on user’s shoes

Every DevRel role depends on the external users and their (hopefully) happy relation with your products: I value this continuous exposition to the external world as an incommensurable treasure. It fosters diversity, keeps my mind open, allow a flow of new ideas. Even if one of Google’s mantra is “User first”, I’ve sometimes interacted with people maybe too closed in their own bubbles. And this is one of the biggest differences between a well-established company mindset and a successful startup mindset I’ve discovered: startup is forced to always have users and their needs in mind, and the rent to pay the roof covering employee’s heads depends on this ability to understand the customer and speed in execution thanks to a razor-sharp focus. In a well-established company, instead, generally that hurry is less perceived because there is a fix salary, and sometimes a manager / the team / the org / internal complexity / processes could become “the ultimate customer”. After all, putting on user’s shoes is not trivial and exit from the comfort zone requires effort, so making assumptions or serve a different master than the user is the quickest and less painful way. In short, be lean.
Luckily, interacting with “influencers” of the tech ecosystem, like community members, conference organisers, experts in their own tech field etc, remembers me where my attention should focus, my last goal in everything I decide to do, how bad is to expose them internal company complexity, to assume nothing, the many learning occasions this “exercise” can provide me. I’ve found this attention to put myself in someone else’s shoes extremely useful also when dealing with colleagues, friends, family, random people: everywhere there is human interaction.

The one big fight I had. And it was with myself

I want to close this long introspective journey with the most traumatic experience I had in these 5 years: it was about the switch I did from being a developer to cover a Developer Relations role, dealing with communities, project management and manage a team. After the initial period, where the lack of time to code was well surrogated by all the unicorns and rainbows of a new job in Google, I started to realize weeks could pass without me writing a single line of code. I was warned about that, nevertheless was a huge internal conflict to deal with. I wrote my first program when I was 13, I started my first full time job as developer at 19 and I moved to Google when I was 33: nothing less than 20 years dedicated to the art of coding. If you’re passionate about development, you know it’s not a 9to5 job. It is, instead, a passion, maybe even a curse, a delicious curse to deal with, because we’re all happy to pay such high time and commitment tribute in exchange of the positive emotions derived from the happiness of creation, the satisfaction of bringing order and logic where chaotic and unmanaged information was, the pleasure to discover new stuffs and challenge ourselves using them to improve, the pride in teaching others about our craftsmanship. And after 20 years of days and nights immersed in this world, shaping and measuring my professionality and myself through the lens provided by it, switch and reinvent who and what I am was deadly hard.
How I solved it? First, it was something I wanted, it wasn’t an unexpected shift. Then, I’ve applied introspection, a development plan and discipline: I first understood coding wasn’t the only thing able to keep me happy, but I’ve found sweet spots in other areas of my job with positive and impactful effects on me, in particular dealing with communities and supporting them. Then I posed myself the question: “How do I see me in 5 to 10 years from now, both personal and working life, maybe still in Google, maybe not?“. Again, lot of introspection through meditation, and I was finally able to figure-out a satisfying and actionable reply. Now, it’s just a matter of discipline to keep connecting the dots between what I’m now and that picture of myself in the future. And, in the meantime, smile, breath, live and help others to smile too. Let’s see in five year from now ;)

If you’re curious about my life in Google, there are other posts to read.

The importance of asking to the team why we do what we do

Months ago I’ve asked to my team the reasons they’re doing what they’re doing in our Developer Relations team. We were reorganising a little bit our internal structure, and knowing the true reasons moving each one is a great way to understand if we’re assigning the right projects to the right people, potential career paths and, if the matches are done in the right way, it helps to attenuate stress and make the team empowered and propositive in the daily work.

I planned to frame the conversation during the usual in-person meetings (1:1) we have: it’s not an argument suitable for a discussion around the coffee machine, as it could go very passional and personal (and generally does) so an environment able to provide the right privacy is fundamental. In addition, these may be the kind of discussions requiring a decent amount of time, half an hour at least, so 5 mins break in the middle of other duties is not enough.

In order to avoid the “out of the blue” effect when asking the question, I first sent an email quoting Simon Sinek’s video discussing the importance of the motivations in what we do, an anticipating that I would have been very happy to have such conversation during one of our next 1:1, in order to discover the real team passions and build or refine future activities, even potential 20% projects, on top of that.

Then I prepared myself. For transparency and equality, I needed to be ready to provide my personal reply to the question, my whys, if asked. Maybe not everyone would have been interested (turn out everyone was!), but in this case doesn’t count if you’re the most junior or the most senior team member: it’s all about us as human, so we’re all equal.

Finally, during the first 1:1 available and without incumbent duties coming, so the atmosphere was relaxed, I started to ask. Ask if it was ok to ask such question. Ask if, to make the conversation more comfortable, I should have first started with my motivations. Asked if there were additional questions about the reason I was asking. Once cleared all the doubts (and the email I’ve sent really helped to set the right tone and expectations of the discussion), people started to tell me their whys.

And it was amazing. And I felt privileged to be part of such conversations, to discover so much about my colleagues.

I wouldn’t say something totally unexpected has been surfaced, at the end we know quite well each other and DevRel team is auto-selective enough that you don’t stay if you aren’t highly motivated, with lot of passions well known and shared. Instead, I was surprised by the accuracy of the particulars, all the little things, often very hard to spot, that added together clarify a lot why it’s so obvious that this person is your colleague, the life paths that have brought her in the team, how much diverse and peculiar we are, even if we share lot of common trains.

And that it doesn’t exist (yet) a school or academic curriculum that brings you to a Developer Relations or Community Manager career path.

Highly suggested as team building activity!