Hi, my name is Bartosz Frąckowiak, for over three years now I’m the so-called Technical Leader at EcoVadis 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 technical base, not necessarily be a guru in 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 at EcoVadis, 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, 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, let’s split it even more.

Self-development

The first one is the 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/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, etc. As the market is going fast in various directions, it is a tough nut to crack.

Usually, not experienced 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 thru the night, makes you searching 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 specification differences between open API specification version 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 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. Technical leader’s responsibility is to make sure the goal itself should correlate to a high-level shape of the software architecture. Architecture simple as possible at the same time 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, Clean Code: A Handbook of Agile Software Craftsmanship

Being a medium

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

Being a connector between the technical leader’s 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 leader’s community took this approach. In the long run, communication lets the team understand the goal where we are heading, therefore, be more independent in making decisions and at the end be 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 position title. Leader means leadership for the team. How to be the best one for the team? Here I will present to you 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 golden bullet suited for every team in every corporation? For sure, not… Simply looking from a statistical point of view, those 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. Idea is to create a safe space to share any topic you want.

One rule only 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 that 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 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 meeting 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 teams meetings stays the same — safe place as it was designed before. There is also a place to share the knowledge with the bigger crowd — to the whole IT department. Sure, it requires a little bit more preparation than just a piece of paper and an idea. Nice presentation is one of the unwritten requirements. The audience is multinational, so it also requires globalization for your presentation. Globally hosted knowledge sharing meetings are a much bigger deal than the local one. Both meetings are held hand by hand. In the end, the outcome is to improve team knowledge with no additional cost.

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

Meetups

Starting from local dev knowledge sharing idea, we have moved even one step further. We hosted a meetup. The first meetup 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, it was in the workshop formula and it was specially designed to guide participants to the same mistakes we made. We showed how we handle challenges and what we had learned. More about the event itself can be found in the article.

Technical excellence meetings

On the other side, inside the team, we have team members NOT resources. Each team member is a human being with different backgrounds, 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/her needs. The concept name is “technical excellence”. There are two kinds of meetings during the month, the first meeting is quick and it takes up to half an hour. The goal of the meeting is to quickly find an area that will be later developed. Ideas usually come from the developer. He/she knows better what he/she is interested in (well, sometimes it is not the case as some people need a small hint). This meeting is a planning and negotiation meeting for the next one that is coming. My role in these meetings is to ensure that the idea is valid at the basic level and try to find common ground between developer needs and company goals.

With having some plans in place, there is a proper longer meeting usually around two hours once or twice per month. This relatively small time is completely for the developer. We can do whatever he/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 technologies inside Azure features. During the meeting, we can either research the topic itself, work on problems related to this topic or even do a presentation that will be shown later on the IT department knowledge sharing meeting.

The ones that touched me the most are about self-improvement. 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/she wants to handle when the 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 can not 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 about technical excellence in the feedback forms’ and most of them were very positive. For myself, it is simply a win and a way to go.

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

The second matter that bothers me a bit is pure egoistic. Each team member gets a few hours per month to develop himself, but what about me? 🙂 Answer is simple: I do technical excellences with myself (sounds like a split personality). I simply book some time during the month for myself and learn what I’m interested in the most, at the moment 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 developer and situation. Starting from just simple sitting together and being a rubber duck for the partner, to hardcore pure pair programming with the whole team inside the dedicated room. Having not just one additional pair of an eye but three members watching. 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” (sitting together and switching keyboards from time to time) pair programming to smaller problems, like bugs, before planned tasks or user stories and “the whole team is watching” meeting for solutions that will affect the future work of everyone. Usually, meetings about core decisions made at the beginning of the project or changes in the direction where the team was heading.

A lesson learned here for technical leaders is to be prepared to monitor the involvement of others during “everyone is watching” meetings. “Tool” is so simple and so powerful, in terms of team building and knowledge sharing 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 EcoVadis are backend based. Usually, we have a 5:2 ratio of the backend to frontend developers inside the team. Team members produce source code daily. Most of the code is usually not visible to the end-user, therefore, it is harder to appreciate the craftsmanship of individuals.

Here, the idea was to share our concepts to the external world. Share it with the IT community in the form of YouTube videos, source codes on GitHub and articles on medium.com exactly like this one. Each IT member can express himself/herself to the community about the topic he/she had mastered during nine to five work. Every content is signed by the developer’s name, not anonymous content. The sharing idea brings both sides clear benefits. Developers build a brand for their names as well as build a brand for the EcoVadis as a company 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/methods described here are working for my team. What I’ve found during the few years of being a technical leader is that the team evolution is faster than you think. Each member works hard to become a better version of himself/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 make 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