The source code to your application and/or product is a representation. It is a model of a digital world you are creating. But remember:
All models are wrong, but some are useful—George Box
All models by definition are conceptual. Until the rise of “knowledge work” models referred to something tangible, something physical in the world we could touch. Software is metaphorically compared to construction, but in construction you have physical boards, nails, screws, and steel. When completed, you have a building. Software “knowledge work” is the first time (that I am aware of at least) where we create a conceptual model of a referent we cannot touch. Well, we can, but its electricity, it hurts to touch it.
There used to be a time, long ago, in our galaxy, where source code wasn’t a model. During that historical time your source code was Assembly, an instruction set for the specific hardware chipset your code would run on. You were programming, very specifically, about the electrical binary state of memory addresses. We’ve come a long way and we don’t want to go back.
High level languages are now representational models of a conceptual digital world that doesn’t actually exist. To repeat, all models are wrong. And I don’t just mean bugs here, but truly “what you think is happening, is not what it really happening.” This truth is why the space for instrumentation, observability, and server-less (or just containers) is growing exponentially right now. We are, finally, admitting to ourselves things are complicated and we cannot simply conceptually reason our way through why N% of our distributed systems are always broken:
“We used to have an illusion that we were in control and nothing was broken. But our systems are full of emergent behaviors and are broken all the time.”— Charity Majors
Today, our languages and code is more powerful and expressive than ever before. You need fewer engineers to do more. So if you have two-pizza team (or more) you are probably solving a problem with a very large surface area. We know that the more nodes — humans — we add to a network — team — the more we will be forced to communicate.
The job of technical management is to create a shared understanding in your team of an imperfect representation. (Aside: the job of people management is to keep the humans happy, and working together well. A manager is responsible for both.) There are some additional things that make accomplishing this task tricky:
There are lots of good tools now to understand what your system is actually doing. There are lots of good tools now for understanding what your users are actually doing. But within your team(s) no one person has the big picture. Everyone has a part of the model of how things ought to work. Stitching that together repeatedly, with little margin for error, is very, very hard. There are not very many tools that are specialized for that.
I’m currently working at the largest company I’ve ever worked for. That, along with being at the $previousGig for nine years (which was the smallest I’ve every worked for) meant that I have a lot of re-learning to do. A lot of growth and change happens in nine years.
There is a lot of advice when you get promoted that takes the form of “Imagine what you would have wanted from __________?” You can fill that blank in with your manager, your peer, etc. When you get promoted to a line management position this looks like: “I’m going to prioritize all the things I wish I had for my direct reports.” What this approach misses is that—all your direct reports do not work like you—their brains are fundamentally different.
This is something I am learning quickly. Spending nine years working with a very small team of people led me to believe that most engineers were like us. By the end of nine years we were finishing each others sentences. Great for spreading information, knowledge, and decisions. Bad for…just about everything else.
One of the more fundamental differences in people’s brains are how they collect and organize information (these types are obviously not exclusive, this is a fluid spectrum). There are mechanical, and methodological types. And there are organic, and freewheeling type. I am, undoubtedly the former. Key take-away: There is nothing right or wrong about being one or the other. Both types are smart, intelligent, and get things done. It’s merely how they go about it that is different. And that makes working closely with someone of the other type very difficult, because each type thinks the other type is bonkers.
When you change roles the things you wanted may not be the the things your team wants, or needs. Being a manager means taking care of your team. It does not mean doing what you wish was done to you. It is not some sort of strange business-revenge-situation; or even a business-savior-complex: “If only everyone did it my way there would be profits AND world peace”
You have to understand who you’re working with. You have to understand how they tick, how they get things done. Otherwise, some of your reports will start looking at you like the worst boss they’ve ever had. This is just one piece of the puzzle to demonstrate to engineers that when they become a manager they’ve changed careers.