From developer to managers and vice versa

In the winter of 2012, a colleague suggested that I, a C ++ programmer with five years of experience, write the first application for Android. A year later, I began to lead a small team of mobile developers, and since then the size of my teams has grown steadily. But last year, after 2 years of managing the mobile development department, I blew dust again with my favorite IDE.



Let’s tell you how it was on the other side, why I returned to the developers at the age of 30+ (spoiler) and do not regret it.

Way to Android Developers


Android, which was a curiosity in my provincial city at that time, seemed to me another funny “toy”, playing which you could safely drop it and return to the usual Qt. And so it all started: a friend threw up the idea of ​​a simple application for accounting for income and expenses, we began to saw it in our free time, and six months later MVP was ready for publication.

image

Our Money Keeper had a rather primitive design, but a well-thought out UX: income or expense was recorded in one click - tap on the category icon immediately opened a window for entering the amount.

I remember very well how I saw download statistics: the first person to download my application was someone from Egypt. And this one did not delete the application that same week, but continued to use it!

Little by little, several dozen downloads per day, the audience grew, the rating grew, the first positive reviews appeared. To say that it inspired was to downplay. I responded to the reviews in the market, planned further development based on the wishes of users, simply because my application is needed by users, they thank and put fives. And all our advertising was in a single post on w3bsit3-dns.com.

It was also striking how much mobile development differs from the development of embedded systems and desktop applications that I worked on before. The application path to the user and his feedback is very short. The audience is huge, and everything that you do, you should do at least well, otherwise the application will not be needed by anyone, and all the work can be thrown away.

How I became a team leader, "because_to_to_someone_something_is due_"


The application grew and became more complicated, a paid version with additional functionality appeared. My pair of hands for the development of two applications has ceased to be enough, especially taking into account the fact that I wrote them in my free time from the main work. There was no special budget for hiring employees, because monetization did not bring so many incomes.

We refused the idea of ​​“freezing” a free application for a paid one, because we did not want to let down the grateful user community, from which we had been drawing energy and ideas for development all this time. Therefore, we decided to take on a small salary two guys who were far from development, and burned to break into it. It was decided to lead them along my path, but with a significant difference: I had to teach them to move and navigate the world of the green robot and show them all the bumps and holes I knew on this road.

image
I was not afraid to take on difficult tasks)

I wantedother people shared my enthusiasm for the development, and two pairs of hands were clearly not superfluous to us. I went to their home, explained, taught, advised, helped. I set tasks and checked their implementation. So I quietly became a small but manager.

The application, however, had to be closed ... I went to a startup, then another one, then came to product development in a large business. Everywhere where there wasn’t enough people for the lead role, there was an approximately similar scenario: “You figured out the subject area, made friends with the team, are not against leadership work, and do you even have such experience? Let's try to set tasks for other people. At least in this sprint ... ”

But there was another important aspect: I was thinking about the future - and it seemed foggy.A very long time ago I came across an article about the average age of developers. It said that the "peak career" of the developer falls on 27 years. I began to notice similar articles - and involuntarily I asked myself: what will I do as a developer, for example, at 32, when “a young shit comes that will erase us from the face of the Earth”? Isn’t it better to slowly tread the road to managers and solve the “30 years problem” for yourself?

My principles as a Timlida


By the time I abandoned C ++ and left for Android, I had already worked with various leaders and knew exactly what kind of leader I wanted to be. And later, in completely different teams: product (consisting of analysts, designers, developers, testers) and development teams - I tried not to depart from my principles.

Need to work with those who are


A student with burning eyes, who is being sent on the right track, after some time may begin to bring more benefits to the project than a “rock star”.

At one of the projects, I decided that it was time to move away from the familiar MVP + Dagger + RxJava bundle, and try in production those tools that Google recommends using to create modern mobile applications. We planned to implement the recommended architecture using only Jetpack and Kotlin with Coroutines.

All experienced developers and bosses twisted their fingers at the temple and said that with a team of two jones who had never used anything from the stack I selected, we would fill up the project and the responsibility would be on me personally. But those two joons were delighted that they would work with what Android developers wrote on the blog just yesterday.

image
Yes, of course, we caught a bunch of childhood diseases of the alpha versions of libraries at the start ...

But the guys worked hard, climbed into the source and studied issues on Github, profiled at night, and in the end we got:

  • clean, stable and easy to maintain code,
  • successful product in production,
  • and a bunch of invaluable experience.

On another project, a very cool developer came to the team, who did not immediately make friends with the whole team, but sawed off the tasks perfectly. The guys contacted him through pain, tears and bosses, and someone even said that it would be better to take any June instead of him, but in the end I reduced the live communication between them to the necessary minimum, and everything became calm.

You have to work with “rock stars,” no matter how difficult it is sometimes.

Naturally, there are people who do not knowingly do their job: someone thinks that he’s got to the “boss who will do everything for me”, someone it simply cannot or does not want to work. If conversations and time do not help, you should not be afraid to part with these.

I work not with subordinates, but with people


Each has its own circumstances, needs, temperament and mood. Once, before passing a difficult sprint, a tester girl, from whom everyone was waiting for the result of the final product testing, came to work angry because of a scandal with her husband who could not find clean socks. Deadline, this is not the first day of intense testing, but here it is. She did not have the mood to work at all. In this situation, it was possible to crush, demand and threaten. But I tried to understand it and redistribute the resource of other testers in such a way as to cover the gap. After half a day, it cooled down and we successfully invested in time.

image
Who before the holidays did not sit on other sites during working hours, let the first throw a monitor at me)

Or another story: a colleague stopped doing something a couple of days before the vacation, simply because he was busy with the last gatherings for a cycling trip to Europe, which he had been preparing for almost a year. All this year he meticulously performed work tasks, and here - as a substitute. And I gave him these two days. After a two-week vacation, he returned rested and set to work at the same pace, but I managed not to spoil the relationship in the team.

In a difficult situation, no one will go forward unless I lead


In one new DevOps team for me, I’ve been “dynamic” for a couple of months with the deployment of CI, and the developers openly sabotaged its implementation, not agreeing with the arguments about its usefulness. It’s not that they were lazy retrograde, it just seemed to me that they didn’t work in the environment where CI was prepared correctly.

Hugging with Google, I sat in the evenings and picking the settings. Gradually, DevOps and the developers got involved in the process. As a result, we were able to configure CI and the necessary bindings for building and distributing applications, which quickly and quietly became the standard for different teams in the company.

Do I close the holes in the organization of processes with personal intervention and micro-management? Maybe. But, it seems to me, in such a stalemate situation, there are two extremes: “tightening the screws”, more and more moving away from the team and becoming the “boss”, or try to help a person when it is difficult for him, even having completed his work, becoming “his”. But they don’t leave “their own” in trouble.

You need to develop yourself and develop everyone in the team


image
Typical workplace of a leader.

The longer I sat on a project, the more I felt that modern development was floating past me. A stack of technologies, languages, and frameworks was selected several years ago, and has not changed significantly since then. This was due to eternal burning dates, weak business interest, but most of all - the developers' fear of something new, when there is such a familiar old.

It got to the point that the newly accepted developers were forbidden to write in Kotlin, because the leading programmers did not know him and did not find the time (did not want to find?) To teach him. These problems were solved quite simply: I held tech talks, meetings and courses on topics that were interesting for the whole team. It’s easier and more interesting for developers to sort out a technology on a pet-project for a week and tell the rest about it than to blindly drag it into production.

And it’s easier for a business to justify a salary increase for a person who is studying and introducing something new and useful for the whole company.

One cannot go far from development problems


As soon as you no longer understand the problems of developers with technical debt, platform features and the interaction between different parts of the system, the percentage of sprints is flying down.

There were cases when managers were genuinely surprised that it was impossible to publish an iOS application on New Year’s Eve because Apple’s reviewers had gone on some holidays. Designers sometimes do not understand the problems of Android developers with typesetting on different screens. Backenders who have not worked with mobile clients before must explain that they don’t need to give an HTML page error instead of JSON.

And if you “look through” such moments when developing the system or its part, the consequences for the deadlines can be very deplorable.

image
Oh, how much good can be achieved simply by taking on technical solutions. And even if they give the tasks to distribute - you can roll mountains!

Did I manage to lead?


I do not presume to say that these are the correct principles. I don’t even know if they correspond to what they write in the books on personnel management, because I have not read any of them. I judge by several facts:

  • The relations in the team improved. If before me there were scandals with the clarification of relations with the authorities, then with me - a maximum of small skirmishes.
  • In general, we fit into sprints. Even the impossible. And if they didn’t fit, then not so much that the customer was angry. Naturally, this is the merit of the team. But probably a little mine. I always tried to take into account all the risks and carry out task planning taking them into account.
  • We constantly refactored and improved the product and development processes, technical debt decreased.
  • Developers grew in rank and salary.
  • My direct guidance was also pretty.

Okay, what about the downsides of leadership?


For me they are:

  • The more you are a manager, the less a developer. No matter how you try to keep track of the intricacies of the technical part of the project, they elude you every day further and further. And the larger the team and the more active the development, the faster. Gradually, the volume of new information received about Android and iOS was reduced to reading release notes of new versions of operating systems and a couple of articles on Habré per month.
  • . — , . , “” . .
  • . . , . - - , .
  • . , . , 2-3 . - — 70-80% !

!


No matter how you like it in some place, you will have to leave sometime. And at some point I began to search for a new job. Predictably, I wanted to get into an even larger business in order to continue development.

The next Skype interview was going on: 10 interviewers, 2 hours , requirements - knowledge of the technical part of the Senior Developer level and the ability to manage people. And after 2 hours, I realized that in managing people I know almost nothing. At least I don’t know the theory, and am based only on my principles and experience.

It looked something like this:
— ?

.

— ?

, . , .

— ?

— …

— , scrum kanban?

.

— ?

— …

Well and so on. I failed the theory. I somehow succeeded in implementing, but to explain the basic principles of why one way or another had to be done - no. After the interview, I realized that I had reached my ceiling in the amateur management league and that further sitting on two chairs would not work. To develop, it was necessary to decide where I want to go.

image
This is my current away team for remote workers. At least one more person in it went the same way: went to team leaders and consciously returned to the developers.

The first way is to managers. Still, read the very correct books. Start watching videos and attending management, planning, and motivation conferences. The professional managerial league has its own rules and its own specifics.

Second way- immerse yourself in development, if possible catching up over the years of management.

Well, the third, compromise, option is to “pull up” the theory and try to continue to be “in the middle”, hanging “in amateurs” for a few more years.

And then I remembered how it all began. With the feeling that you are changing the world, doing something useful for others. Even if you painted the button green, and it became a little nicer for thousands of users. Even if I corrected a typo. And if you have already washed down a feature long expected by users, and you are thanked for it in the comments - this is just an explosion of emotions and a good mood for a couple of days!

Have I experienced such a strong feeling from working as a manager? I think no. Even when customers, team and leaders praise you. And when users praise the expected feature, then this, of course, is primarily due to the one who prepared, sawed, tested and displayed it. And quite a bit - mine as a manager.

Therefore, I found a pleasant place to work, I write code and so far I have no regrets.
Is there life in developers at 32? There is!

PS

What has given me as a developer the experience of leadership?

  1. Now I better understand business and PMA, even without words. Often I know what question they want to ask me.
  2. I plan the time and tasks more competently taking risks into account.
  3. Contrast. After seeing how it was on the other side, I realized what I like about this one.

All Articles