In one of my previous posts I talked about what Happy path engineering is and how understanding the time to implement plays an important factor in that.
So, if time to implement is important how can we get better at estimating the time we need and how can we help others understand the benefits that estimates bring (and, the often, innacurate nature of them)?
If you haven’t heard the term before it’s used to describe a user or system flow that goes through all the expected steps without any issues. Everything else is referred to as an edge case, or a state that the user or the system entered that was unexpected or unplanned, which may even trigger an error report.
In the Divergent Tech Lead post I talked about a number of different interpretations of what a Tech Lead means. Since the role is by no means straightforward – you may need to develop different skills depending on your current team.
In my journey I have focused a lot on gaining specialized Domain Knowledge, building up Technical expertise, working on effective Team organisation & Planning, and perhaps most importantly clear & comprehensive communication. Let’s have a closer look at what all these really mean.
Some time ago I decided to do a little research in an attempt to figure out which are the most often requested skills that a Tech Lead is expected to have. If you are interested in that post, it’s here.
Back then I was not surprised to see that there isn’t a universal set of skills that a Tech Lead is expected to have. Quite the opposite actually, different people perceive the role in different ways and have quite different expectations. This has led me in a definition I call the Divergent Tech Lead. But let’s start from the beginning …
But how can we know? The easiest way to get an insight of what the companies expect from their Tech Leads is to have a look at their job postings. So off we go to create our data set of job postings for Tech leads !