A missing image of a manager

You must have seen this meme. A group of people is pulling a stone. The first one, that is in the front of the group is labeled as a leader. There’s also another picture, showing a person sitting on the stone and doing nothing. This person is labeled as a boss. If you are a software engineer, this image probably resonates with you. In my opinion, this resonance, is a result of the confirmation bias kicking in, just proving that technical leadership is the only one that’s needed. In my opinion, there’s one more image that should have been added, but was omitted.

The missing picture came to my mind, when I was on my book reading quest, consuming First, Break All the Rules. The  book is based on a Gallup’s institute research, testing how people are being managed and how this changes the way they work. At the beginning, authors are dissecting the poll that they used for their tests. Also, they show a very important difference between the outward and the inward thinking. They describe a leader as a person that looks outward, pulling the line in a new direction, helping other to conquer new territories. It’s interesting that they don’t discuss the boss figure. They discuss the manager, looking inward.

The third picture that is missing is one showing a manager role. It’s not for looking outward, it’s for looking inward, at the people, at the team. Asking them about their goals, their needs and motivating them. I wrote manager role, as this is just a role. Maybe in your organization you’ll find people having two, or even three roles (startups, anyone?). Maybe, unfortunately for you, you’ll find none (complex organizations, gov related companies ruled by policies).

At the end, I’d like to ask you for one thing. Next time, when you see this extremely fitting or soothing presentation slide or meme, think again, why does it suit you? Maybe it’s just a confirmation kicking in? It’s popular to question authorities. Unfortunately for us, it’s still not popular to question self.

Processes and The Cone of Uncertainty

The Cone of Uncertainty is a management phrase describing the fact, that we cannot foresee the future of a project with a constant probability. The longer period we want to plan for, the less probable it’s going to be exact. That’s the reasoning behind sprints in Agile, to keep them short enough to be in the narrow part of the cone. But it isn’t only the planning! The shape of the cone can be modified by some good practices and reducing the manual labor. By modified I mean greatly narrowed.
The are plenty of processes and elements that can be introduced:

  • continues builds
  • proper db deployments
  • tests
  • continues deployments
  • promotion of application versions between environments

Each of them improves some parts of the development process making it less manual and more repeatable. Additionally, as you introduce tooling for majority of these cases, the tools run with a similar speed so you can greatly lower the uncertainty of some aspects of development. Then again, if some of aspects are constant, only the real development will affect the cone and your team with a manager get what you wanted: a more predictable process and a smaller cone of uncertainty.