Technical Leader: Identity Disorder

Hi, my name is Bartosz Frąckowiak, for over three years now I'm the so-called Technical Leader and I would like to tell you my story :)

A technical leader can be just a simple position in the corporate hierarchy. It can be a safe position reserved for a person technically based with some leadership skills. Opposite to team leaders who generally should have strong leadership skills and a technical base, not necessarily be a guru in the programming stack. The question you should ask yourself is: what do you expect from your career?

One of the ingredients is your attitude. I have never wanted to make this title just a corporate position to me. The footer in corporate mail means nothing to me. After three years of being a technical leader, I've learnt a lot about what it's like to be one of them (in this particular environment). I have ups and downs. One day I would never change this position to a different one, the next day I was almost ready to quit and move on. I would like to break down this position into smaller pieces for you. Let's start with splitting just the name "technical leader". It has two words in it. The first part is strictly "technical", the second is "leader". I will try to address these two parts inside this article and explain what it means to me. What I do to be the best possible technical leader.

"Technical"

The technical part is all about widely known engineering craftsmanship. The whole category is extremely wide, so let's split it even more.

Self-development. The first one is self-development in the context of engineering knowledge. So simple and yet so complex at the same moment. The technical leader needs to join the technical mastery journey no matter what he or she knows already. A technical leader is responsible for analyzing new approaches, new shiny bits and bobs that come to our engineering market. Follow trends, join conferences, and so on. As the market is going fast in various directions, it is a tough nut to crack.

Usually, inexperienced developers are highly motivated. Discovering the engineering world just makes them even happier to go further and further. Somewhere on the road, the developer finds out that it is almost impossible to be a specialist in every branch of engineering.

After some time you find it spiritually releasing to decide not to try to be a specialist in everything, because it is almost impossible. Just find your thing or two that drives you, makes you sleepless through the night, makes you search for the next piece of information about a particular topic. On other topics be up-to-date, more or less. Do you like data science? It's fine not to know the specification differences between OpenAPI 3.0 and 2.0. Just simply know it's there; you will deep dive into details when needed.

"Let him who would move the world first move himself." ― Socrates

Using knowledge. The second chapter is using engineering knowledge in the day-to-day workspace. Making the right decisions and leading the team to the chosen common goal, which should describe where the IT department wants to be in the long run. It's the technical leader's responsibility to make sure the goal itself correlates to the high-level shape of the software architecture. Architecture as simple as possible while meeting all the needs of the business. Easy to develop and easy to maintain in the long run.

Finding this architecture is a never-ending story. The company evolves and software should follow the development as well.

"Clean code is not written by following a set of rules. You don't become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines." ― Robert C. Martin

Being a medium. The third category is being the technical medium and connector between the architect, other teams, and the team itself. At the moment we have eight teams with seven developers each. This is not a space where lack of proper communication can be accepted. Discussing with other technical leaders and the architect takes place twice per week.

Being a connector between the technical leaders' community and the team is an important task which needs to be done every day. Making sure the team knows where we are heading. It's crucial to the whole IT environment to know what decision has been made and why the technical leaders' community took this approach. In the long run, communication lets the team understand the goal where we are heading and, therefore, be more independent in making decisions and in the end more effective.

"The single biggest problem in communication is the illusion that it has taken place." ― George Bernard Shaw

"Leader"

Each technical leader has a "leader" inside the position title. Leader means leadership for the team. How to be the best one for the team? Here I will present tangible ideas and practices that are introduced inside my team. I am sure that thanks to those, my team has improved a lot during these three years. Are those rules a golden bullet suited for every team in every corporation? For sure not… Simply looking from a statistical point of view, they will not fit every environment. I hope I can inspire you a bit and encourage discussion.

Dev knowledge sharing. The first idea is about sharing knowledge in a safe space. I have booked one hour per week, usually at the end of the week when everyone is thinking about the weekend already. The idea is to create a safe space to share any topic you want.

Only one rule applies: you have to talk about engineering. There is no constraint that the topic has to be work-related or has to suit the project the team is working on. Simply, you have something to share? Come and talk about it. What's more, there are no rules about the presentation itself. If a developer wants to have a high-end presentation, it is appreciated; if a developer presents an idea from a scratch of paper, that's fine as well.

The idea found interest quickly and became a permanent part of the team's life. We had meetings where all of us were reviewing pull requests with some new approach, as well as meetings about machine learning algorithms. From TDD to ideas on how to optimize our team efficiency. From coding conventions to project managing strategies. Anything developers are interested in is suited for the local dev knowledge sharing.

After three years of hosting these meetings, I found out that the secret here is feeling safe inside the team. Each presenter received feedback during the meeting knowing that feedback is only for his good and self-improvement. There are no mean jokes, nobody criticizes that the topic isn't important in any context. It is simply time for a developer to shine and be proud of his knowledge.

These meetings evolved from local dev knowledge sharing to company-wide meetings. We keep both. Local team meetings stay the same, the safe place they were designed to be. There is also a place to share knowledge with the bigger crowd: the whole IT department. Sure, it requires a little more preparation than just a piece of paper and an idea. A nice presentation is one of the unwritten requirements. The audience is multinational, so it also requires globalization of your presentation. Globally hosted knowledge sharing meetings are a much bigger deal than the local ones. Both meetings are held hand in hand. In the end, the outcome is improved team knowledge with no additional cost.

"If you have knowledge, let others light their candles in it." ― Margaret Fuller

Meetups. Starting from the local dev knowledge sharing idea, we moved one step further. We hosted a meetup. The first one was about the approach to one of the projects we were involved in. We had space and time to learn (learn the hard way) TDD inside DDD.

We decided to share our journey with the local community. The event took place at our office, in a workshop formula, and it was specially designed to guide participants into the same mistakes we made. We showed how we handle challenges and what we had learned.

Technical excellence meetings. On the other side, inside the team, we have team members, NOT resources. Each team member is a human being with a different background, different needs and different goals.

As a technical leader, there is enough space to show myself useful. The idea is to independently develop each team member's skills based on his or her needs. The concept name is "technical excellence". There are two kinds of meetings during the month. The first meeting is quick, up to half an hour: a planning and negotiation session whose goal is to find the area that will be developed later. Ideas usually come from the developer; he or she knows best what they're interested in (well, sometimes it is not the case, as some people need a small hint). My role is to ensure the idea is valid at the basic level and to find common ground between developer needs and company goals.

With a plan in place, there is a proper longer meeting, usually around two hours once or twice per month. This relatively small time belongs completely to the developer. We can do whatever he or she wants as long as it brings educational value. During these three years we had meetings about blockchain, testing, many topics related to DDD, or specific Azure features. During the meeting we can research the topic itself, work on problems related to it, or even prepare a presentation that will be shown later at the IT department knowledge sharing meeting.

The ones that touched me the most are about self-improvement. The majority of my team members found themselves in a place where they want to take a "step forward", the step that will distinguish them from every other backend developer. Those meetings are the most heart-touching, the hardest ones, but also the most inspiring and rewarding ones. I would recommend it to each technical leader: try to talk not only about facts and technology. Find a way to inspire team members, even a little bit.

The success of those meetings is based on properly planned time for the developer, way ahead. Each of us has some topic that he or she wants to handle when time allows. The truth is that there will be no free time. What's more, you will have less and less "free time" as your career evolves. Those meetings address the problem: the time frame cannot be moved, every participant needs to be prepared. The meeting must take place.

Every year there is a time of appraisals, the time when your performance gets reviewed. What is important to me, there are feedback forms that let others put opinions about me as a technical leader. In the past, I found a lot of mentions of technical excellence in the feedback forms, and most of them were very positive. For me, it is simply a win and the way to go.

Along with those meetings, I found two things that make me wonder a bit. Since each meeting was between me and another team member, I had to be prepared for every topic, which put pressure on my calendar. The idea I want to test is to follow the same meeting pattern, but with team members running the meetings for each other. I would just watch at the very beginning and help until the point where I'm no longer needed. (At this moment I am part of a team of very experienced developers; the idea might not work with a less experienced team.)

The second matter that bothers me a bit is purely egoistic. Each team member gets a few hours per month to develop himself, but what about me? :) The answer is simple: I do technical excellence with myself (sounds like a split personality). I simply book some time during the month and learn what I'm interested in the most. At the moment the hype is on deep learning.

"Be a yardstick of quality. Some people aren't used to an environment where excellence is expected." ― Steve Jobs

Pair programming. Again, simple as that and powerful as that. Pair programming in any form that suits the developer and the situation. Starting from just sitting together and being a rubber duck for the partner, to hardcore pure pair programming with the whole team inside a dedicated room. Having not just one additional pair of eyes but three members watching. A live coding session with a large screen presentation and discussion about specific problems.

Which method should we choose? The rule of thumb is to pick "small" pair programming (sitting together, switching keyboards from time to time) for smaller problems like bugs or planned tasks, and the "whole team is watching" meeting for solutions that will affect everyone's future work. Usually meetings about core decisions made at the beginning of a project, or changes in the direction the team was heading.

A lesson learned here for technical leaders: be prepared to monitor the involvement of others during "everyone is watching" meetings. The tool is so simple and so powerful; in terms of team building and knowledge sharing it is one of the best in my opinion. Be careful not to fall into the trap of being "The Devil's Advocate", which causes frustration. Usually stepping back and taking a huge breath is the cure. After all, being pragmatic and empathic is crucial here.

Open source initiative. Teams at our company are backend based. Usually we have a 5:2 ratio of backend to frontend developers inside a team. Team members produce source code daily. Most of the code is usually not visible to the end user and, therefore, it is harder to appreciate the craftsmanship of individuals.

Here, the idea was to share our concepts with the external world. Share it with the IT community in the form of YouTube videos, source code on GitHub, and articles on medium.com, exactly like this one. Each IT member can express himself or herself to the community about the topic he or she has mastered during nine-to-five work. Every piece of content is signed with the developer's name, no anonymous content. The sharing idea brings clear benefits to both sides. Developers build a brand for their names, and they build the company's brand as one with a strong engineering culture.

"Open source is a development methodology; free software is a social movement." ― Richard Stallman

Power of Small Changes

All the tools and methods described here are working for my team. What I've found during a few years of being a technical leader is that team evolution is faster than you think. Each member works hard to become a better version of himself or herself, not only during work hours but also after the nine-to-five period. To keep everyone interested there is a constant need for small improvements, small changes that keep the technical leader's toolset fresh and joyful for everyone.

If you find yourself in the same corporate position as mine, please share your experiences with the set of tools that you have developed over time.

"Great things are not done by impulse, but by a series of small things brought together." ― George Eliot