A few years ago, during a meetup in Lyon I remember meeting a young graduate, let's call him José, who was interested in Malt. He had a surprising way of starting the discussion. He told me that he didn't want to talk too much and that his job anyway didn't require interactions, just coding. I might as well say that he didn't totally convince me.

But if José was undoubtedly very caricatural, he is not unique.

Yet, far from the clichés of "The Social Network" or the "Silicon Valley" series, IT development is a much more social activity than it seems. The teams that produce the tools you use regularly can be counted in the hundreds or even thousands.

IT development is one of the most collaborative activities. It's a job that requires understanding the problems to be solved, so you have to talk to a lot of users. It's a job that requires prioritizing, so you need to be in the right discussions to get the context. The development activity itself is an activity that involves multiple discussions with users, the product manager(s) and the business. And of course, it's a team effort involving many specialties, front, back, ops, security, data etc...

In short, it is not a solitary activity, which makes it particularly complex. Beyond the necessary individual skills, a major question arises: how to bring impact to a large group of individuals and even better, how to multiply its impact through the group?

On the other hand, how to avoid that this group goes in all directions and misuses its resources?

Leadership, another form of management

There is often a strong ambiguity when it comes to evolving as a Senior.

For some companies, management is the only way for a senior to evolve. The idea is that the most experienced Software Engineers will make the best managers. In fact, they lose their most experienced individual contributors to convert them to another job where there is no guarantee that it will work. This is the famous Peter Principle. I won't go further on this, it is not the purpose of this chapter

But, on the individual contributor side, there is also a persistent stereotype. Some people think that there are managers on the one hand, a somewhat blurred role that serves to hold meetings and fill in excel files, and individual contributors on the other hand, who develop the application.

This is very caricatural and hides a lack of understanding of the role of manager, on the one hand.

On the other hand, it also leads to denigrate the tasks assimilated to management and to think that an individual contributor should never be involved in this type of activities which would be, by essence, less noble.

However, if we take the definition of management from wikipedia :

Management is defined as all the organizational and management techniques used to lead and control the actions of individuals.
Wikipedia

From a senior level, to create more impact, you need to develop your ability to present solutions, argue and convince on a strategy, gather people around an objective, coordinate groups of people, measure results. To do all this, you will need to use management skills, which can be grouped under technical leadership. We are no longer just developing an application, we are starting to "code" the company.

Doing things right is important.
Doing the right things is crucial.
Getting everyone aligned on the right things to do is fundamental.

And despite appearances, this is the role of individual contributors when it comes to complex technical design, architecture and implementation.

What I gather behind the term leadership is so important that it is for me part of the two important barriers, along with improving business understanding, to unlock in order to go beyond the Senior role and increase its impact in an organization.

This is sometimes referred to as the "Leadership chasm (https://www.adachen.com/the-leadership-chasm/)": the gap that must be bridged to grow beyond the Senior stage.

Develop your network

Developing your network means creating the right conditions to successfully move groups of people in the same direction.

When we talk about developing our network, I sometimes hear people say that they don't like to play politics.

I don't know if "doing politics" has the same negative connotation in all countries. But in France, it is very often associated with manipulation in order to get a personal advantage.

So indeed, don't do politics.

But the objective here is to use the leverage of a group to accomplish more than you would on your own.

Alone we go faster, together we go further African proverb

There are many ways to build this network within a product team.

For example, you can regularly be available to provide help or do peer programming work when colleagues need it.

You can do coaching or mentoring with people who want it and/or newcomers.

You can do knowledge transfer through training, BBLs, REX (feedback).

This list is not exhaustive, I do not include all the good teamwork practices (respecting deadlines, regular updates, clear communication etc...). What is important here is to encourage regular exchanges with these peers, to understand the pain points that the team may experience, to work on improving overall productivity.

We often talk about 10x developers, people who produce 10x more. But for a senior person, the objective to multiply their impact is above all to contribute to creating 10x teams.

An expanded network within the company

As I mentioned in a previous chapter, the influence and impact you can have as an individual contributor must go beyond the product team. To do this, you have to expand your network, whether it's across the company or outside of it.

By this I mean shadowing (shadowing people in support, or business teams), taking on the role of someone for a day (support is really great for that), and simply participating in business discussions with other departments.

José would probably tell you that these discussions are not natural for him. He prefers to stay in groups that share the same codes, the same culture. That's the point. Getting out of the engineering team is necessary to build a better understanding of the problems we have to and can solve.

Of course, it's complicated, you have to learn new jargons, new codes. But this is how you can develop your empathy: the ability to identify with the other person, to understand how he or she uses your product, how you could bring value to him or her.
And it goes both ways.

A network outside the company

Finally, you can extend this network of trust outside the company.

If I take my personal experience, I have been blogging since 2006. I've been involved in communities since 2011, notably with the organization of Devoxx France, Blend Web Mix or the creation of Human Talks in Lyon. Currently, I am active on slack channels like Tech.rocks, Rands, or FrenchProduit. Indirectly these actions allowed me to meet and recruit many people at Malt and thus have a positive impact on my company. The future will tell me if I have also had a positive influence on the ecosystem in which I evolve.

But if we think mostly about recruitment, that's not the only possible positive impact. Some have helped create industry-wide standard formats, specifications or protocols. This standardization may have allowed their company to make better use of their resources through greater interoperability and simply not waste so much time on topics that are reinvented over and over again by each player in the same sector.

Others have made their company benefit from their work within a community and I propose to illustrate this with the example of Florent and Olivier.

This chapter is the first of a serie on leadership. While I am well aware that there is no silver bullets, I would like to outline in the next chapters the principles that are common to many effective organizations:

• Hard leadership vs. soft leadership
• The notion of empowered teams
• What is a technical vision and how to create it
• Alignment by context
• The notion of the 10x team

Questions

Would you say that you are the driving force behind the organization of the technology strategy? That is, you initiate the focus groups, list the actions to be taken, monitor the schedules, set the objectives and follow up? Or is this solely the responsibility of the managers?

When was the last time you had a discussion with people from other teams than yours, within the product, but also with marketing, sales teams, customer support...?

Have you recently spent a day with another team to watch them work on the products you develop?

Have you tried to take on the role of someone in customer support, or on the testing team?

Resources

• The Leadership Chasm
• From the 10x developer to the 10x team
• Build 10x teams