Technical Midwife
Once upon a time I wasn’t in software development. One of my first real jobs was a lathe operator in a large mechanical shop. For a year all i did i was making nuts, bolts and washers. A bit menial job by 21st century standards — it’s all automated now — but, it’s a fair pay for a fair day of work; and the fam gotta eat.
Making nuts in a lathe is a rather simple process. You take a hexagonal steel beam, lock it in the machine, then you drill a hole through the middle of it making this sort of a thick hexagonal pipe, then you tape a thread in the hole, and then you pretty much just cut nuts out of this weird threaded pipe.
And so, I remember this question that was bugging me back then: “am i actually making things?”. Someone fabricated the hex beam. Someone had built the lathe machine. Someone figured out how to make those nuts, and someone passed that knowledge to me. All I was doing is taking orders and then cut existing material into something. It was fun, i love making stuff. But, somehow it didn’t feel like creating. I sort of felt like a meat robot, repeating movements over and over again.
A decade later i was a software developer, and i was cranking up my first serious opensource projects. The same question was bugging me though. “am i actually creating something here?”. It was the time when our industry was playing with cults of big names: Linus made linux, Guido made Python, DHH made Rails. And so following the vogue I wanted to make things too. Things I could put my name on.
In retrospect it’s kind of funny now. Middle kids are always like that, you know. The first kids gets all the stuff because they are the first. And the last ones get all the love because they’re the last. And the middle kids sort of always need to prove their worth all the time. And so, I wanted mom to be proud I suppose.
It turned out, that the world doesn’t work quite like that. My ambitions and ego wanted to own the entire thing. I wanted to say “I’ve built this”. But I didn’t. All I knew I learned from others. A lot of ideas I put in my code I took from someone else’s work. Even the problems I was trying to solve were neither created nor articulated by me. Moreover, with time I realised that neither Linus or DHH built their creations either. Most successful opensource projects are result of collective effort.
And so the question of “what am I doing here?” was still open. To combat the problem i sort of distantiated myself from the code I was producing. ”I am not my code” was my mantra for almost a decade. It helps to mitigate ego problems. It helped me to focus on honing my skills rather than trying to claim ownership of the result of my work. Still, the question of “who I am, and what I’m doing here?” remained.
When I started leading people, things started to become even more vague. Whatever you build is always a team effort. If the engineers that you work with are good, half of the time you don’t even touch major blocks of an application. Even your ideas and guidance — if you’ve done your job well — are reworked heavily when the actual code is written. And so, I spiraled back to the good old question: “what does a tech lead make?”, or more recently “what does a CTO make?”.
Some tech leads would write in their resume that they “build teams”, but that never felt right to me either. Maybe one could say that HR builds teams, but even that is quite a stretch if we be honest about it. Teams are essentially systems, and, as systems, they are responsible for their own behavior. We’re trying our best to throw the most fitting people into the fire, but fire does what fire does. It consumes coffee and produces code.
With time I have realised though, that my problem was that I was always trying to think of it in terms of manufacturing. A baker bakes bread. A digger digs holes. A welder welds metal. Etc. One’s identity comes from what they make. Even useless people come from making nothing, and a-holes come from making life miserable. So, it kind of makes sense intuitively. After all, programmers program computers, right?
And the more I thought about it, the more I started to see that no-one really “makes” anything. As in “making” something entirely as a whole. Only God makes something out of the void, and we’re not entirely sure about that either. It’s more like things and ideas are _born_ into the world, and we humans sort of help them become reality.
Think of it in terms of how sculptors approach their work. Sculptors don’t say “i made this” and “i made that”. Good sculptors often say that a sculpture was already in a block of marble, or a piece of wood. They simply chipped off all the unnecessary parts that were hiding the sculpture inside.
In this aspect, one could think of technology in terms of a child birth. A seed of an idea gets into an engineer’s head, and it starts growing in there. It’s building up, and shaping, and morphing until it is ready to see the light. And then a developer sort of barphs code out into files; labours on them for days until the idea becames a thing capable of standing on its own two legs.
And if you start thinking about technology emergence as a sort of a birth process, a lot of pieces of the puzzle start to fit together. For example, in any birth there are usually three perspectives: the child that is being born into the world, the mother, and a midwife.
Then you can say, that a software engineer cannot claim ownership of the code they bring into the world more than a mother can claim ownership of a child it rears. Engineers get ideas out of the common knowledge space, they mostly use tools that created by someone else, even tasks themseleves are created mostly by product owners. Engineers make an idea a reality, but they don’t own ideas or code, they own their love and dedication they bring into the process of building something.
Now this mother <-> child relationship parallel is simple and intuitively makes a lot of sense. But, what is interesting to me at the moment is the concept of a midwife in this whole process. A midwife carries out a crucial role of making sure that the child is born without complications for themselves or the mother. Midwife is usually a person who saw enough births to be avare of most possible complications. But, more importantly a midwife is a person outside of the immediate labour of the child birth. Someone who can see it from an external perspective and guide the mother through the delivery.
I think, I now realize that “technical leadership” is a rather misleading term; no pun intended. Almost every time i try to “lead” a team by charging ahead of a pack, very soon I realize how easy it is to loose persepective on what’s actually happening; what’s important. Every time I step away too much and switch into the “strategic paperpusher” role, I allow a team either to hurt themselves by pushing too hard, or moving in a wrong direction and hurt the outcomes.
So, what if we call it a “technical midwife” instead? I think this would give a lot of meaning to what a technical lead actually does, or supposed to do. The role of a technical midwife is to see, understand and guide the birth of technology. Not technology, or engineers, or stakecholers in individually, but all the pieces together as an emergence process.
Yes, a “technical midwife” must understand what technology needs, they must understand what engineers need, and they absolutely must understand the needs of a pumped on adrenaline husband — the CEO — who just wants to cut the umbilical cord and be over with this. But, more importantly, a technical midwife needs to see and respect the spirit of the birth. A good midwife needs to know when to ask the mother to save energy, when ask her to push harder, or when yell at a husband to leave the room. Well, and, sometimes a midwife has to grab a scalpel and cut a baby out, to save both it and the mother from an impeding death.
Well that was a bit cathartic, wasn’t it?
I still like this parallel though; there are some good reasons for it. Firstly, it helps me not pretend that “i built something”; engineers did, and they deserve the credit. Secondly, it doesn’t put me in a position above the engineers, which is dignifying to say the least. And finally, it makes the answer to the good old “who am i, and what am i doing here?” question simpler.
There is an old — arabic I believe — wizdom that resonate with me a lot.
If one understands A, and they understand B. One cannot say that they also understand A and B. Because to do that, they also need to understand the and.
In software development we have a rather weird careers progression. We all start as engineers, we learn technology, but once you pass your “senior” grade, a strange thing happens. You get promoted to a “lead” position, and, depending on an environment, you’re usually required to do one of the two. Either to charge ahead of the pack, Richard the Lionhart style, or beef up your poeple skills and become essentially a manager. The first one basically truns you into an overpaid developer, and the second one is anticlimactic to a technology person, to say the least.
The interesting thing is that both of those approaches are not entirely useful ways to look at the problem. One of them is focused primeraly on technology — the A — , and the other is focused on people — the B. What a technicall lead needs to be focused on is the magic stuff in between, the and. Which is a hard thing to see, because it is mostly in the blind spot of both technical and managerial people.
This is why I like the concept of a technical midwife, because it is a mental instrument that allows me to peek into the A and B space. To see the emergence of technology as a thing.
And that is what a technical lead makes.
Well, at least for me.