LeadDev London 2023
Hello, on June 27–28, Olda and I attended the LeadDev conference in London. The LeadDev conference is one of the technology conferences focused on developers and technical leaders. People from various positions come together at this conference to get inspired, share their experiences, and discuss the latest trends and strategies in software development and team leadership. The conference is full of lectures, workshops, and discussions that help create strong technical communities and support professional growth. There were also several sponsors who had their booths in front of the main hall and were open for discussion and getting new contacts, such as SensioLabs, Skiller Whale, Shopify, incident.io, and others.
The program was really full throughout the day. There were always 3–4 presentations followed by a break with speaker discussions. We will try to describe at least the key ideas that stuck in our minds.
Notice -> think -> persuade -> proceed
If you want to be a good leader, don’t skip any of these points. I believe this motto applies in personal life as well. “Do the right thing” was another saying that sounds clear to the core, but is not always followed in large corporations and we, as responsible managers for our teams, should not put business bullshit before people. We should act as a kind of mediator — on the one hand to implement the interests and visions of the business and on the other hand to meet our employee’s needs and not make them uncomfortable at work.
What is important for successful on-call?
Flexibility — Important is to have enough people willing to participate in on-call duty. It’s not just about scheduling, like assigning Mondays to John and Tuesdays to David, but being truly flexible. If John needs to take a break for 2 hours on Monday to gym exercise, there should be a way for someone else to cover that short time period. Communication is the key in such situations.
Autonomy — The person on-call should have everything necessary to fix any potential problems. It’s not just about tools and access (although those are also important), but also about knowledge. Let’s not hesitate to involve juniors in on-call duty, but provide them with someone who can advise them (that’s the best way to onboard them). Related to this is another important piece of information. People must know those specific systems. If an on-call person sees the production database for the first time during their duty and is afraid to touch it, they are completely useless to us at that moment.
Support — Let’s not limit on-call duty to developers only. It’s important to have support from non-technical aspects as well (such as scrum masters, product owners, etc.). It helps with potential escalations of issues, where intervention may require business decisions.
Tooling — The last part is the aforementioned good tooling. It needs all the necessary tools to solve the problem as quickly as possible.
And how do we know that we are improving with on-call duty? Here is a beautiful metric to consider: (Alerts * Time to resolve) / people.
Many lectures were about onboarding (it will be mentioned several times). Remember that even the process of rewriting a monolith into microservices is a form of onboarding. People learn much better when they have smaller cohesive units to work with rather than one huge spaghetti code.
TDAA (Technical Design and Architecture Advisors)
I must admit that this lecture was the one I was most excited about. One of the biggest problems in large companies is communication between departments. A typical example is when the business comes up with a task, the product owner takes it over and assigns it to the developers. They may interpret it differently several times because they lack context, and then the UX department comes in and sees it in a completely different way. But why not approach it differently? In Webflow, they started using the TDAA (ta-da!) system, which aims to prevent this. Let me briefly describe it.
It all starts with creating a TDAA group. This group consists of representatives from each department (one developer, one scrum master, one business person, one UX person, etc.). It’s important to note that these people are not there permanently but are selected for a specific period (3 months, 6 months).
Then anyone in the company can create tech specs (a document with a predefined format) describing new features, improvements, etc. The TDAA group has 4 days to take over the document and another 3 days to make a “decision.”
The decisions can be as follows:
Sponsored -> the request is valid, approved by the group, and work can begin on it.
Needs updates -> the request needs further clarification on certain unclear aspects.
Not recommended -> it’s not recommended to proceed with the request for specific reasons.
Review not needed -> a minor detail that doesn’t require approval.
Escalated -> passed to other departments for further analysis (e.g., business impact of the feature).
The view of productivity is very subjective. According to some studies, most managers believe they are productive, but their subordinates see it differently. It’s important to communicate everything we do, even if it doesn’t seem relevant to a particular person! If developers see things from a high-level perspective, they will be more productive themselves. That one struck directly into Jardas brain as “Whoa, I should share more stuff within the team!” he started as the Developer in DrMax who always have plenty to share in stand-ups and other ceremonies, but there is a lot of stuff that is not directly related to the day-to-day team agenda while being the team-lead.
A few notes on successful hiring:
- Clearly define the type of person we are looking for in detail. Personality-wise, technically, etc. It’s important to have it documented somewhere; just thinking that we know it is not enough. If we don’t have an idea of who we are looking for, we won’t be able to find them.
- Act during interviews as if we want that person in the company and that we are interested in them.
- Don’t give too much weight to the past. The person may have had conflicts in their previous job due to burnout or reasons we will never know. Give more weight to their current skills and attitude.
- Don’t worry to be active and try to look for your new junior stars in e.g. technical schools. The company and management’s approach has to be mature enough to do this, true, but this approach will pay off over time. People are the key.
To have a successful company, it’s important to set the right goals and not just scatter metrics. It’s like with an airplane. It’s nice if the plane has successfully landed and taken off a thousand times, but what matters is how many people it transported and whether it flew unnecessarily.
There was a great lecture about how everyone struggles with integrating OPS things. Companies first tried the DEV x OPS approach, then DEVOPS, then DEV x SRE, and one of the latest trends is DEV x platform engineers. There were many interesting thoughts, such as an exemplary problem-solving approach:
Goals (establish the goals we want to achieve) -> problems (identify potential issues) -> solutions (develop all possible solutions, including backups) -> building (let’s get to work). For example, the goal was mentioned as really important because sometimes we identify a problem that we want to solve, but it’s not relevant to the company. At the end, an interesting thought was shared. If the platform engineer team no longer makes sense (which can happen in certain project phases), we can disperse the developers into product teams. It helps to keep them close to the product.
Another one of the few technical talks was on code cleanliness. How important it is to develop in a clear and transparent way because of potential bugs and technical debt, or newcomers for whom readable and well-documented code will simplify onboarding and improve the overall view of their new day-to-day activities. Although this theme is well-known and almost self-evident, it is not always followed, so it doesn’t hurt to remind ourselves of it from time to time.
Currently, FE developers of DrMax together with UX designers are implementing StoryBook which requires first of all a proper implementation of components in the code base. The vision that even business people will be able to not only conveniently browse the list of these components, but also change parameters and see changes in real-time is motivating. This is also why the topic that also appealed to us at the LeadDev conference was a collaboration between UX, developers, and product managers. The earlier we include the developers themselves in the design of a feature that requires a visual on the front end the better. This can avoid a lot of misunderstandings and adjust the design so that it can be implemented efficiently to achieve the desired result without requiring major constraints in the design.
Another interesting topic was about letting people go. In every company, there are situations where someone becomes toxic or burned out in a team. The lecture didn’t focus on how to prevent it or how to bring the person back to a productive state, but rather on what to do if we decide to address it this way. It’s important to reassure everyone else that they are still important to us and that we value them. Otherwise, toxicity can spread within the team so it is a good idea to have something like an “exit plan” to not be surprised when someone wanted to leave our greatest most people-friendly company. This topic was closely related to one, which was about people that are “happy where they are” and doesn’t seek promotion etc. It is absolutely fine to have such employees and we should let them become better in their field of expertise — to offer them lectures, visit conferences (thank you Honzo), or meeting other professionals.
And one final thought: leadership can be learned, but let’s also share information and experiences among ourselves. Without that, we won’t move forward.
Conclusion. Although Jarda and I are used to more technical topics, the conference certainly gave us a lot. We both perceive that people leadership is a difficult discipline in which we need to continuously improve, and this conference confirmed that. Don’t forget to pass on information internally as well, because communication is the key to everything.
