How to Cross the Lake
Explaining (part) of my day-to-day job as a technical leader.
A while back, I went for some climbing with a friend. We camped, climbed some peaks, and overall had a blast.
On the last day, we made sure to return to base camp early enough as we knew there was some risk of hail for the end of the day.
The local hut was closed but lucky for us, they had a section accessible for mountaineers to use in case of need (mountain huts usually have one of these: a place people can get shelter and even spend the night should they need to).
As we spent the early evening in the hut, him and I spoke while warming ourselves by drinking tea and looking out through a little window at the hail falling down on the frozen lake, with the mountains as the backdrop.
At some point he asked
"So, what is it that you do in this new job of yours? What does an Engineering Manager do? What do you manage? Why is it needed?"
I told him what an Engineering Manager generally does, in the realm of career orientation, performance review and that sort of managerial tasks part of the typical manager work.
But that's not the real value of a technical lead, which is what I embody.
So I thought about the lake we were looking at and gave this analogy, which I find fitting.
Companies like mine build digital products. We're building something the market might be willing to pay for. And in that quest, stakeholders in the company will have insights and ideas as to what that is and say what they want the engineers to build and so on.
For example, imagine they might come up and say to an engineer "See this lake? We need to have you cross on the other side". Consider this the analogy of "we need to build this, whatever this means". So this is the problem given to an engineer, or a team of engineers.
Now, how do you get to the other side? Well you can swim, or you can walk to it clockwise, or counter clockwise. Swimming might get you there quicker than walking, if you are fit enough, but also you might get hypothermia from the freezing temperature. What if you had a wetsuit to keep you warm?
The combination between how clear the ask is - "get to that side of the lake" - and the knowledge, seniority and ingenuity of the engineering team, gets you very differing results.
I operate in this intersection where the ask is made and I help on ensuring it's doable, realistic and formulated well enough so that my team is able to come up with a solution that is sound in terms of time, quality and cost. Furthermore, some engineers are less experienced, or might miss some information to generate a good solution. I also come in to coach them at reasoning about tradeoffs, decision making, risks, technical choices, and so on.
A younger engineer might swim to the other side because it's "quicker". A more experienced engineer might propose walking even though it's longer because they know they might die of hypothermia once they get out of the water, their clothes soaked. So it's a matter of tradeoffs depending on what is desired and under which circumstances and I help the team reason, clarify and navigate those nuances.
Since then, I've used this analogy one or two times with other non-tech, non-startup folks and they mostly seem to get it. Although they always look confused as to why anyone would ask an engineer to get to the other side of a frozen lake.