LeadingEng 2024 – AI first, value next

LeadingEng is one of the events organized by the community around LeadDev.com. It is essentially an extension of the LeadDev conference, focused on managing leaders of leaders. This year, my colleagues attended LeadDev while I attended LeadingEng.

The conference took place in London, a city where sunglasses are sold only in packages with white canes and where you can (not kidding) lend an umbrella in a same way like shared scooters. The venue was located in an architecturally interesting space in the Barbican district, right next to the Museum of London.

A conference?

This was my second attend at LeadingEng, but when I came to registrations last year and they invited me with words: “Welcome, you have table number twenty” I was a bit confused. I expected a regular conference, but this didn’t look like a standard conference. I entered the venue and found that instead of seats arranged like in a theater, I was in a room with rounded tables and chairs for 6 people.

During the conference, I realized that I was in a room with successful leaders and CTOs of large companies, as well as successful startups. I felt a bit like I was at an awards banquet for movies. At my table was sitting the top development leaders from Financial Times, Adobe Solutions and the lead architect of the BBC news service.

Unlike what I expected, it was not about lectures on fresh processes for your company or universal solutions for forcing your employees to deliver faster, demand smaller salary, and work 168 hours a week.

Throughout the day, not even the ever repeated buzzwords like Agile, Scrum, Lean, Work/Life balance, and others that are so common at other management-focused conferences were used.

This was about you, your growth, and your opportunities to make yourself better in enpowerment of your team. And these topics were not brought to you by agile consultants or coaches by profession, but by real leaders who had already accomplished something and often held high positions in several successful companies.

Let’s go through some of the most interesting ones:

What is my Job again?

Cate Huston, the Engineering director @ Duck Duck Go apparently loves raccoons and opened the topic with story about Toronto officers trying to build raccoon-proof public trash bin. They was unsuccessful because the Racoon is more motivated than average bureaucrat.

Cate also talked about the importance of working with strategy and used a great analogy that stuck with me: Product strategy is like the storm that is needed to water the flowers, technical strategy is the shelter that makes sure everything else doesn’t wash away, and Team strategy is the umbrella that allows the team to move freely in the product.

She also mentioned the book “Good Strategy/Bad Strategy” by Richard Rumelt, which I personally recommend to anyone who wants to design and execute a strategy that has a chance to stand up in the real world.

Then Cate talked about different styles of leadership like being Affiliative, Coaching, Pacesetting, Authoritative or Coercive and described that real leader can combine those and each situation and audience needs something else.

Last but not least she said something that perfectly hit on my current mood, because she introduce The trap of being usefull describing that every leader want to be seen as a servant leader but sometimes you then find yourself in a other role than the one you are intended to. In worst case you start doing everything and then it is same as in restaurant where nobody cares about how delicious the food is, once it comes on the table late.

Commercial Understanding for Engineering

Meri Williams, CTO and Advisor @ Pleo, who by the way did a excellent job as a guide for the whole event, has tried to teach us how to read a financials of our company. It was more like workshop than presentation, so there is not so much to say about, but it was definitely beneficial to think about what is company critical success metric, if its income, revenue, ebitda and how it relates to company targets, so the company measures growth, cash flow or if it is trying to ressurect.

I also love when Meri called SaSS metrics like ARR, MRR, GARR, LARR: The pirate metrics :)

An interesting observation was that cloud (like AWS) expenses are often put in a bad cost groups, because most companies wants to see that expenses and costs will decrease over time but cloud expenses will never be lower unless your company is gradually dying.

How to craft a business case for your technical strategy

Rukmini Reddy, SVP of Engineering @ Slack, Who came from Silicon Valley the place where companies sell a dreams and stock options had another awesome workshop to help us execute our technical strategy, because only existence of such strategy is not enough.

As it was workshop, again I cannot probably replicate the whole experience in form of text, but lets talk about few key takeaways i think that can be interesting:

Mainly, the business should not form your technical strategy, it should definitelly be responsibility of engineering leed, but on the other side any technical strategy is destined to fail if it doesn’t count with bussiness needs. Therefore technical strategy is definitely not:

• Using a latest technology: There is no way to convince your bussiness owners that by rewriting anything to Go will help them meet their targets.
• Doing the most novel idea: World is changing, and every company wants to do something AI driven, even tho it is possibility to maintain a competitive advantage, strategy is not to find a problem that meets a technology but exactly opposite, so you first need to know the problem that meets the business needs and then enable it by may be using AI

On the other hand strategy can be technical debt, not because engineers want to “clean that mess” which only they are struggle with, and only they see. In fact it can be because it really brings a bussiness effect as real tech. debt is not what developers sees, it is more like what user or bussiness see like slow performance, or long time to delivery.

Also the execution is a king, unfortunatelly there is newer enough resources to do everything. So you need to gain buy-in from bussiness in same ways you do with your engineers.

Achieving engineering velocity by optimizing developer experience

Ban Lloyd Pearson’s (Dev director @ LinearB) presentation was a sponsored presentation. So to be honest I intended to use it as a time for mental cleanup and turn of my brain for a while, because as you probably know, every man needs to spend some time in the Nothing box.

But in the end, I found it interesting. Guys from LinearB are doing the impossible of measuring developers effectivity, which I would like to say is everytime hard and managers often trying to simplify that into some quantifications and numbers, that leads to false expectations like “this guy has not enough contributions in project so he is probably not working”. The truth is in fact that we can still follow metrics like that but it is important to use it in context of each person.

In fact, from their research it seems that most productive (in matter of bussiness) are not developers that coding like a insane whole day, but those who are coding just around half of hour per day and rest is mainly analysis and refinement of a problem to find a right solution.

But what really hits me was maybe kind of unrelated to original message, but i saw in one slide this quote from some automation tool: “The PR is considered safe and has been automatically approved”. Wow, such a future I thought. Later that day, I talked about it with our Platform engineering stream leader, and he pleasantly surprised me when he said that we are just now working on that and showed me a working POC.

Engineering owns velocity

Rare Colburn, Technology officer @ Depop put this title onto his presentation, Such a provocative headline, mainly for scrummasters i thought. But he was right that companies are more eager than ever to quantity the output of their teams to feel confident in maximising return on that investments.

Unfortunately when non-engineers try to increase output of teams, they often end with quantification like counting of story points per sprint and also focus short-term deliverables that devalues the key things of an engineering teams jobs. The truth is that velocity is just number and average product owner can’t understand what effort really is behind implementing any feature. They often say “It should be easier, in fact it is just one button change”.

Engineering is a superpower and velocity is just part of a very complex team efficienty optimisation problem. Far more important than velocity is value and it would be nice to measure value instead.

CTO’s or leading engineers work should be to create value and engender the confidence of team to be predictable, because real efficiency is gain mostly by sequencing work correctly.

Contemplating the Future: Modeling your organisation to meet a shifting bussiness

David Yee, VP of engineering @ New york times put us into another perspective of procedure that is kind of hated by everyone in the company, but it is really needed to meet the market and bussiness needs. That is Reorganisation.

In this workshop we did a interesting experiment to build a muscles on company reorganisation. Essentially we first drawed our current company structure together with company main targets and needs and then we tried to identify struggles and drawed organisation again in the way it can from our perspective work.

It was deffinitely not easy job, I would recommend everyone to try. As my company has really complex structure involving multiple entities, it is present in lot of countries and has multiple levels of management, I did like three different reorganisation diagrams and I still was not really confident that would work.

Then we tried to found a way to move from a original structure into the final one and to be honest, it seemed impossible to me. Also we worked in groups, so important part was to present and defend our structure to others.

Then he introduced us continous reorganisation idea, which is in short just splitting the reorganisation into multiple stages and understand reorganisation as a continuous process with understanding that each stage takes time and you need to be patient to make things settle up properly.

There was even more

Other than classes, there was a lot of table talks and office hours with speakers during coffee breaks. During the whole day there was also Mathias Meyer offering his speed coaching session where you can either see and listen the session of someone else, which was really beneficial because you found that lot of leaders and CTOs are also just humans, they can be also little bit shy and often they’re solving similar things as you, and also you can off course take a session. I personally tried and it was an unique experience to me. Off course Mathias didn’t give me the magic solution to solve my personal leadership issue, but he give me a different perspective. I hope to see in few weeks if that works.

Wrap up

As I was attending LeadingEng also last year I can compare. To be honest this year there was a lot more people, I was hardly finding a way to grab some coffee in a crowd during the coffee breaks. But on the other side it didn’t lost anything of it excellent atmosphere and excellence. I met lot of people and I was able to compare their daily struggles with mine. There was lot more of AI mentioned everywhere, often as a Joke like “We are trying to prioritizing by value, unless its AI then we are prioritizing alphabetically”. I definitely enjoyed this time and I believe that I’m once again little further on the road to becoming a successful in my engineering leader role.