Thiemos Archiv

I had the pleasure to join the workshop »Tech Lead Skills for Developers – From Maker to Multiplier« back in December 2019. Instead of waiting for this to become an actual blog post, I'm going to dump my notes now.

Key learnings:

  • »Tech Lead« is not a position, it's a role.
  • Tech Lead is a cross-section between Developer, Architect, and Leadership.
  • Tech Leads absolutely must touch code.
  • »Leading« means communicating. Work on your communication skills!
  • Draw diagrams of your software architecture!
  • Read!


  • Hosted by Patrick Kua (@patkua), a speaker from Australia. Very clean English, very easy to follow. Later I asked him how often he did this workshop, and he said about 50 times. I think it showed, in a very positive way. For example, he was able to incorporate a lot of examples and details he learned from other devs previously attempting the workshop. That added to the already strong impression of a very fresh, very relevant workshop.
  • The venue for both the Workshops and the conference a day later was the Radisson Blu hotel in Berlin. Quite impressive, but not over the top.
  • There was a chocolate santa clause for everybody. I loved this detail.
  • Enough breaks, long enough, with a very nice range of food.
  • Set up in a room with 3 very large circular tables, arranged so everybody was able to see the host in the front. That setup became an actual part of what Kua asked us to do during the day.
  • Only 2 female devs in a room with about 25 guys.
  • The introduction round was done in a way I have never done it before. The host asked us to talk to each other in pairs (without saying how these pairs should form). Everybody had to write down what they learned, and then introduce the other person to the rest of the table. I loved this. It even included drawing a portrait.
  • It was called a »workshop« for a reason. A nice mixture of presentation, writing things down, interacting with the rest of the table or room, working together as a team, and a few post-its to write, share, and order. Nobody fell asleep.
  • No laptops. No phones. Very helpful.
  • We learned where the role of a »Tech Lead« comes from, what it typically involves, and even what it should not involve.
  • One of the main learnings probably was that there is no »pure« Tech Lead. It's not a job position, it's a role. People typically have more than that single role, e.g. they are also Engeneering Managers, or also Developers.
  • We learned a few different ways how the role of a Tech Lead can be described. Some say it's a cross-section of a Developer, Architect, and Leadership skills. Some say it's a role that balances right inbetween »enganging with the team« and »engaging with the buisness«, as well as balancing »delivery & risk« (fast, low-quality output) and »architecture & infrastructure« (high-quality, slow output). In other words: a Tech Leads main job is not to master any of this. Actually the contrary. The main job is to ballance all this.
  • We even had to describe our own take on that, which became super fascinating when the room started sharing and grouping these personal points of views. There was so much overlap!
  • One thing that suprised me very much was that »actually writing code« was kind of forgotten and not listed as a core responsibility by anybody. Later this became a bit more clear: sure, a Tech Lead still must touch code. Otherwise it's not a Tech Lead but an Architect. But touching code is a thing people in this role don't really think about, and don't list as something they want to focus on. It's more a given, like being on time or having lunch.
  • We have been asked to rate our abilities on a given matrix with skills typically relevant for a Tech Lead, and which skills we want to evolve. Three groups: leadership skills, developer skills, and architecture skills. A common thing in the room was a lack of leadership a.k.a. communication skills, as I expected, considering devs are often introvert people. Then we learned what are good strategies for each of the 3 groups of skillsets.
  • Kua talked about »Non-Functional Requirements«, but highly suggested to call them »Cross Functional Requirements«.
  • He suggested a ton of books to read, and highlighted some: »Emotional Intelligence 2.0« by Travis Bradberry and Jean Greaves. »Facilitator's Guide to Participatory Decision-Making« by Sam Kaner.
  • The workshop attendees got a copy of the book »Talking with Tech Leads – From Novices to Practitioners« by Patrick Kua. I wasn't able to read it yet.

Kommentare zu diesem Beitrag können per E-Mail an den Autor gesandt werden.

[ ← Zurück zur Übersicht ]

Impressum & Datenschutz