Non-determinism is the job

Early in my career, and partially because I worked at a place that was a little silly and I didn't have much contact outside the organization, my title in my email signature was Spaghetti Straightener / Cat Herder. The first part was a nod to the code I was untangling as an engineer. The second was a nod to the fact that I was also a manager.

On the engineering side, things made sense. I'm building a system. It has reasonably well defined expectations for inputs and outputs, for behavior in a given scenario. When the structure needs to change, there are well established patterns for changing it, mostly thanks to our refactoring forefathers. You can reason your way through code. You can trust that the same input produces the same output tomorrow as it did today.

The people side doesn't work that way. You can set expectations for your employees. You can communicate them clearly. People still carry an element of non-determinism that no amount of clarity resolves. It's not always obvious why someone makes the choice they make. One of the hardest parts of managing is trying to predict the unpredictable, trying to find the right way to guide someone toward the behavior that will actually help them succeed.

That difficulty is especially sharp in software. Most managers in this field come up the same way: college, first job, years of writing code, then one day you're a manager. Some of that is a paradigm inherited from our parents' generation, where progressing meant eventually running a team. It's also that nobody actually teaches you about career paths in this field, certainly not as part of the computer science curriculum. Unless you happened to land a manager who was thoughtful about that kind of thing or with an organization with that kind of thinking, you never had the conversation at all.

Either way, becoming a manager has often felt like the obvious next step for a senior engineer. It isn't. There's a split at senior levels that a lot of organizations refuse to acknowledge: more leadership is expected of you as you grow, but leadership is not the same thing as people management. There's a real technical leadership track (Senior / Staff / Principal / Architect / Technical Lead) and a real people leadership track (Manager / Director / Vice President / CTO), and while there is certainly overlap between those paths, plenty of companies pretend there's only one. Layer the standard corporate instinct on top of it: find someone excellent at a thing, then hand them the next thing and assume the excellence transfers. That's how you end up with a lot of previously-excellent engineers running teams who were never actually evaluated for whether they could do it.

Why does the transfer fail so often? Engineers tend to be good at engineering because they're wired for structure, for definitions, for algorithms, for predictability. Building systems that reward those instincts is a good match for how they think. Then they run into a team, with its own incentives, its own history, non-determinism baked into every person in it, and the instinct doesn't disappear. They try to force it to hold anyway.

I've watched this play out two ways, over and over. Some managers respond to unpredictable people by adding more process, trying to engineer their way to consistent behavior. When the process doesn't produce it, because people aren't a system you can patch your way into compliance, they fall back on something uglier: belittling the person the way they'd belittle a peer who doesn't understand the architecture they built. Other managers just give up on the people side entirely and pour everything into the technical work, coaching the codebase and ignoring the humans writing it. There's real value in the second kind of coaching. But a software organization is a people system before it's anything else, and people need tending, not optimizing.

If you aren't all in, actually all in, instead treating management as a chore between the real work, you are doing damage. People don't leave jobs, they leave managers. So ask yourself the real question: do you want to be the reason your direct report is quietly updating their resume tonight? That's the actual stake, not some abstract turnover number. And it isn't free. Replacing them costs months: recruiting, onboarding, the ramp-up time before they're contributing. The team eats the gap in the meantime, covering the work, training whoever shows up next, watching someone good walk out the door because their manager couldn't be bothered to actually manage.

Almost none of this gets taught. Engineers get promoted into management with no training, no framework, nothing beyond a title change and higher stakes. I got lucky, in a way. Yes, I've been fortunate to have great managers and mentors who invested in me. But I've also spent my whole life studying behavior just to understand how to fit in, so by the time I became a manager, I'd already been studying every manager I'd ever had. That's still the advice I give new managers: think through every manager you've ever worked for. Do the things the good ones did. Don't do the things the bad ones did.

It isn't much more sophisticated than that. It's ironic that my best advice for a job that resists algorithms is a heuristic rather than a real methodology. But building your management philosophy off scattered memory isn't training, it's luck, and people going through a transition this significant deserve better than luck. They deserve real training: what the role actually expects of them, what good practice looks like. That should come from the manager promoting them, and it should come from HR.

Performance evaluations should be designed to expose how well or how poorly someone was actually prepared and is actually performing. Top-down review does not tell you whether someone is good at this job. The people who actually know are the ones reporting to them, and that feedback rarely makes it into the review that decides whether a manager keeps the role, or gets handed a bigger one. Even if 360 reviews aren't a standard for the entire organization, they should at least be part of the manager evaluation.

As I gained experience, I stopped trying to find the algorithm and started applying something I'd actually learned about managing people before I ever became an engineer. The book The Alliance by Reid Hoffman, Ben Casnocha, and Chris Yeh names the shift better than I can. Treat the relationship between employer and employee as an alliance, not a transaction, not a lifetime obligation, where both sides are honest about what they need from each other and the relationship holds because it's mutually beneficial, not because someone signed something. That's the real shift. You stop managing behavior and start genuinely wanting to know the person: what matters to them, what they're actually trying to get out of this job, this year, this stretch of their life. When you need something from them, find the version of the ask that also serves what they want, position it so that doing the thing you need is also good for them. This was concerning the first time I heard it, but it quickly made sense in that context: my job is to prepare you for your next job. Not because I want you to leave, but because I genuinely want something good for you, and by investing in your growth, both the company and I get the benefit of that.

That might sound soft. It isn't. That might sound manipulative. It kind of is, but with good intent. People notice effort. They notice when you're actually trying to understand them versus managing them at arm's length. They notice when you're investing in them because you want them to be better, not because you need a number to move. And they reward that noticing with something process never buys you: perseverance and loyalty.

I'm not sure I always have a good read on whether it's working. We're all playing a role at work, and if you carry a title with any real power attached to it, people are going to treat you with a certain baseline of respect, and probably some fear, whether you've earned either one or not. What happens to that fear over time? Do they start constructively challenging you, pushing back because they trust the relationship can absorb it? Do they start bringing you more of themselves than the job requires, not because they have to, but because they want to? That's the difference between trust you've earned and trust that's just a byproduct of your title. If you're only getting the second kind, you're not actually trusted. You're just the door they have to go through.

Somewhere in the middle of all this, I became a part-time therapist, and I don't mean that as a joke. People want to be heard, and sometimes the job is just listening. Sometimes they need to dump, and there have to be boundaries on how much of that you take on: it can be highly informative about why something isn't going the way you'd like, but it still isn't a bottomless well you're entitled to draw from. I'm usually older than the people I manage, and there's a version of that gap where offering a little guidance on life outside of work is valuable to someone, not overstepping.

Underneath all of it is the diagnostic part. When something isn't going well, I don't open with a process question. I open with "How are you?" Then I ask how things are going with the team, with the work itself. If the answer is fine, that's usually where the real conversation starts, not ends. That's when I name what I've actually noticed. "I've seen these couple of things lately, what's your take?" And if that still doesn't surface anything, only then do I ask about life outside of work. It isn't the opening move. It's where the digging ends up when the surface answers don't hold.

More often than I'd like to admit, that's where the actual answer is sitting. A good performer who's suddenly not performing usually knows it. That awareness creates its own anxiety, and the anxiety makes the work worse, and now you've got a spiral that has nothing to do with skill or effort. Asking the question gives them some safety. It says you've noticed, and it says it's okay to not be okay for a while. Not indefinitely. At some point they still have to deal with it, and the job still has to get done. But you want people bringing their whole selves to work, and if you actually mean that, you have to be willing to deal with what shows up when their whole self is a mess.

That's the version where I have to go looking for it. Sometimes people just bring it to me first, no digging required, and that calls for something different. The instinct is to jump in, to problem-solve, to ask a dozen clarifying questions before they've even finished a sentence. I try not to. Let them tell you the whole thing before you do anything else. If you need clarity once they're done, ask for it then. But the question that actually matters, the one I come back to every time, is simple. What do you need? Not what I think they need. What they say they need.

Raleigh Schickel is a VP of Engineering with 15+ years of experience leading engineering organizations. He writes about engineering health, team metrics, and what it actually takes to build high-performing teams.