Get my email lessons on how you can build a tech team you can depend on.

A slightly silly (and bit sad) history of leading programmers – Final chapter

This one’s longer than usual, so you can read it on-line here.

Just joining in? Catch-up with:

part one

part two

part three

As we return to our story, I want to thank those who wrote in this week. You provided many new viewpoints and ideas of where to take the story.

And now, back to our story.

Recall that the Executives and Managers selected a computer person to manage the other computer people, and promptly sent them off to Management Training. Pat, the new manager, was both excited and nervous about being chosen for this “honor.”

Pat went off to training where he heard all about the art of command-and-control and six-stigma-stuff. Pat learned many things, such as how to motivate people to work faster, hold someone’s feet to the fire, not to accept excuses. Truthfully, Pat wasn’t sure these ideas would work, but since the instructor said management was rooted in “science,” they seemed worth a try.

Pat worked diligently to apply the management training at work. Sometimes they appeared to be working, other times… not to much. When problems arose, Pat discussed them with their Manager. Of course, their Manager had never had much luck with the computer people, so they sent Pat back to re-read the management books.

In time, Pat realized some success, but it came from unexpected sources.

For example, when Pat left for two weeks vacation, there was a great deal of concern that the computer people would not get any work done. Quite the opposite happened, though, and Pat returned to find a great deal of good work had been accomplished.

Another time the Executives called Pat in to solve a particularly thorny computer problem. Feeling over-tired and overwhelmed, Pat brought three of the best computer people to the meeting. They proceeded to take over the whiteboard and brainstorm possible solutions. Pat said very little, as did the Executives, but the computer people found and fixed the problem that very day.

Pat also noticed that the more time spent with each computer person, and the better they knew each other, the less Pat needed to pretend to have all the answers. The team trusted Pat more, which led to Pat trusting them as well.

All this caused Pat to sometimes forget to act “managerial” – and Pat noticed during these times that everyone seemed happier and got more done. When people had problems, they confided in Pat during their one-on-one meetings. Though Pat didn’t have great relationships with everyone on the team, most of the group was undoubtedly coming around.

Pat began to think it was quite impossible to manage the computer people – but for some odd reason, the less managing Pat did, the more people followed.

“What a surprise. All that exhausting commanding, controlling, posturing, telling, yelling, measuring, ranking, and brow-beating didn’t get much done, but a bit of kindness and compassion sure goes a long way. Maybe if you can’t manage them, you can lead them.”

When Pat reported these ideas, the other Managers and Executives chuckled. You’ll see, they said, it won’t work for long.

However, Pat persisted and refined the approach. Surprisingly it did continue to work, and the longer Pat worked with the team, the better it worked.

Soon other computer managers came and asked Pat about this unique approach. Word spread and more people came to see Pat: marketing managers, design managers, accounting managers, R&D managers, and other managers of skilled-smart-people.

Finally, the CEO got wind of Pat and summoned him to the executive suite.

Rocking back in his tall, leather chair the CEO asked, “Pat, how did you get the computer department working so well? What’s your secret? Also, will it work for other departments?”

“Truthfully, I cannot say how it works, or if it will work with other people,” Pat replied. “My approach is simple, but not easy. It’s as much ‘gut’ as ‘head’… so it may not be simple after all.”

“First, relationships with each person on the team seem to matter more than I thought. I try and get to know them and allow them to know me. This builds trust between us, and I end up caring about them. It’s not fake; I really do care about each one of them, even the ones I don’t always like.”

“Second, I like to think of everyone as working inside an interconnected system, with differing pressures, vacuums, and forces at play. Each person on the team impacts the others, and one department impacts another. We’re all a system of connected parts, and I help my team see how others impact them, and how they impact others. This helps them be aware and empathetic toward each other.”

“Third, I noticed that computer people tend to pretend they can be perfect, and expect perfection from each other. I see this happening with non-computer people too. I encourage my team to ‘get real’ about what can be done, stop expecting themselves (or me) to be perfect. Instead of pretending mistakes don’t happen, I ask them to admit, discuss, and learn from them together. This relieves a great deal of pretending which causes all sorts of problems.”

“Fourth, I noticed that when I got promoted, my team had all sorts of unspoken expectations about me, and what kind of person I was. I found this curious, and noticed they had unspoken expectations of each other, other departments, managers, and even the executives, sir. In fact, the less they knew someone, the more expectations they had! Most of these expectations were based on dealings with different people who had the same titles, maybe even at different companies! So, I try and get them to talk about their hidden expectations, and I try to talk about mine.”

“Fifth, I found that when my team failed at something they often said, ‘I’m just not ‘cut-out’ for this.’ This silly phrase, “cut-out,” was causing problems – preventing them from even attempting to learn and grow. It’s like they thought they were a piece of cloth “cut-out” in a particular shape by a suit maker. However, that’s not the way with people; we’ve learned all the important things in life, especially how to program computers! No one was born knowing that! When I started pointing that out and helping my team understand that they could do many things they didn’t feel ‘cut-out’ for, they began to see new possibilities.”

“Sixth, and last, I found my team knows the answer to most of the questions, especially the hard ones. Instead of doing a lot of ‘telling,’ I try to use them like a high-priced management consultant. I ask for their advice about problems. Through these discussions, we’ve solved the hardest problems and allowed everyone to contribute. They get a kick out of solving problems, and I don’t worry about getting their ‘buy-in’, because they come up with the ideas! Such good things happen when we talk things through.”

“Sir, I’m sure other things are happening that I can’t put my finger on. I try to create an environment of mutual respect and safety, where everyone’s ideas are valued. I use my power and authority to get the resources they need, especially those they can’t get for themselves. Above all, I try and be a “regular person” in all situations, and avoid pretending I’m better than they are. All of this is just common sense, I suppose.”

Now, dear reader, we must pause, for we have gone on entirely too long.

I would love to report that Pat received a promotion and a raise, and spent years teaching this style of leadership to everyone in the company who led smart people, (which turned out to be all the managers.)

Though this is a silly tale, it is not a fairy tale.

Change is hard, and sometimes it is just too hard to accept how mistaken we are.

Thus, Pat was not promoted but was reprimanded and demoted for “abdicating management duties.”

Pat soon left the company, taking a job as a computer person at another company and avoiding management at all costs.

So there our silly story ends, on a bit of a sad note.

However, maybe, just maybe, our work is not quite finished.

If we choose, we could ask ourselves questions like:

  • What might I learn from this silly story?
  • How might this relate to the real world?
  • What lesson will I decide to remember?
  • What change might we attempt?

I’d love to hear your thoughts, so feel free to write me back.

Have a great weekend,


About Marcus Blankenship

Where other technical coaches focus on process or tools, I focus on the human aspects of your Programmer to Manager transition. I help you hire the right people, create the right culture, and setup the right process which achieves your goals. Managing your team isn't something you learned in college. In fact, my clients often tell me "I never prepared for this role, I always focused on doing the work". If you're ready to improve your leadership, process and team, find out how I can help you.

1 Comment

  1. Relational Leadership Model – LogicScience on April 13, 2019 at 9:19 am

    […] In the interview for my current job I was asked about my management style but since I’d never been sent on any management courses at that time and even usually avoided admitting that my role was management I found it a very difficult question to answer.  Now that I’ve been in my current role for a while, I’ve been sent on SLII training which I have found to be a useful model and it has certainly improved me in my role. However I’ve still been looking for ways to be better at my job and fill in some of the gaps not addressed by SLII. Many of the other theories I’ve looked at like ‘Servant Leadership’ for example have cross over elements that are important like ethics and emotional security but so far I’m attracted to the model that presents a solution to what is a real problem working in IT with distributed teams in this new millennium. The problem and solution is well described in this amusing and relatable article from Markus Blankensup, A slightly silly (and bit sad) history of leading programmers. […]

Pin It on Pinterest

Share This