Hello, welcome! My name is Teresa Melchart, I work at willhaben and today I’m going to talk about T and other shapes and how they relate to the way we work.
First off, maybe a few words about willhaben as a company and myself. If you’ve ever purchased or sold any second-hand goods in Austria, chances are you did that via willhaben. We are Austria’s largest digital marketplace with over 9 million adverts for second-hand goods, vehicles, real estate and jobs. I am Teresa Melchart, I started at willhaben two years ago as a tester… but actually, also test automation engineer… and actually also front end developer – so let’s just say I’m a software engineer at willhaben.
A few words about our products, we have the website, we have an iOS and an Android app, as well as administration platforms for our business customers. Those are maintained by a bit over 80 engineers in our product development department.
Now I’m going to tell you a bit about how we work together at product development in willhaben. And I’m gonna start off with how it was when I started at willhaben two years ago. We had specialized teams for everything. So there were the back end teams working on our core services, we had a front end team, the web team working on our website, we had an apps team working on the two apps as well as a team specialized for tests, one for operations keeping our infrastructure up and running and PM and UX teams. So, that worked very well for quite some time, but also led to a few problems, especially when it came to dependencies between the teams. So when there was a new feature to be developed, it first had to be implemented in the back end, then it had to come to the front end and the apps and there were often different priorities and it led to some holdup.
This is why the organizational setup was changed over the last years to cross-functional teams. So that’s what it looked like after the change. We had one team cross-functional where everybody was together – we had the back end developers, we had the front end developers, the app developers, myself as a tester as well as one site-reliability engineer concerned with operations, PM and UX. Everyone in one team, so we could develop one feature self sufficiently without needing other teams – ideally. This also has the disadvantage that we may have bottlenecks within the team, so when one person is specialized for a very specific thing and isn’t available, work may not be able to go on within the team.
So, for everything there is a solution – the solution for this challenge is a mysterious creature called the T-shaped developer! In theory, a specialist looks a bit like this. I’m a tester, so my main specialization is testing and that’s where you can see my skill-bar. But over the last two years I also had the opportunity to dabble a bit in other topics and develop some skills in many relevant areas, so now I look a bit more like this – an upside down T. Of course, those models are always a bit of a simplification, there are also other shapes that a developer may be described as, as we can se here. Depending on the breadth and depth of our knowledge, we may be described as I-, T-, Pi- or Comb-shaped. So in my personal story, I started as a tester, being very specialized in that field. Started dabbling around in other areas to become a bit more T-shaped. By now for the last few months I mostly did front end development. Becoming more and more specialized in that. One could say I’m developing towards a Pi-shape.
But still, it’s a bit of a simplification and to get a better sense of what’s actually around in my team I devised a list of some relevant skills, knowledge and tools one could know about to be able to work in our team. And I asked my colleagues to self-assess their skillset and their depth of knowledge in all those areas. That’s what we actually look like – that in the end would be me, sort-of me. As you can see, this shape is more that of a broken comb, which is in my opinion the most realistic model for the shape of a developer.
Now, this leads to cross-functional teams full of broken-comb-shaped developers which aren’t a single color anymore – when the colors are defined by the skills – but everybody is a bit more colorful, actually. This setup works very well for us and has significant advantages, most of them are redundancies. Now there is not that ONE person who can do front end, the ONE person who can do operations, but even if the most specialized person for that area isn’t around, there’s someone around who can take over many of their tasks if needed. This leads to fewer bottlenecks and – my personal favorite – also the opportunity to grow and try new things. Of course there’s also a few things to consider to be able to efficiently work in a cross-functional team of broken-comb-shaped developers. Of course it takes time to broaden your knowledge and learn new skills. That also requires commitment on the side of the developer, but on the side of the management as well. There needs to be enough time to broaden our skills and to learn new things. And not everybody likes to do that! I love to learn new things and I’m also very fine with not being a specialist going very deep into one area, but some people very much thrive doing exactly that – and I think they should also be able to do that. For some topics, especially when it comes to legacy systems, sometimes we need specialists with very, very deep knowledge.
So to sum it up, what do we take away from this? Cross-functional teams reduce dependencies between teams. People with a diverse skillset reduce bottlenecks within these teams. And to some extent or another – we are all broken combs, and that’s good!