When I became a manager, it became clear that my role had completely changed. I usually had to organize my tasks to accomplish a goal set by the boss or the company. I got the hands on and delivered. I took for granted the process and everything that ‘just worked’ to allow me to focus on my tasks. Now I am the one coordinating people and creating the processes that allow others to work. I have the leverage of delivering more through my team, but at the same time the deliverables are not the direct result of my effort. And the results of my own work are less tangible: a vision, a direction, allocation of resources, and so on.

Becoming a manager is a construction, and I am aware that I am in the middle of it. Recently I have been thinking a lot about processes. About how each reference I had of what I think is a good manager had different processes to manage the team. I came to the conclusion that, although I can use frameworks and techniques that certainly help, a process that works is highly personal. And that is what I want to explore in this piece.

Management as an operating system

You turn the PC on and Windows is loaded - I am a Linux user though. After Windows loads you see your desktop and you can start using all the applications you are used to - Word, Chrome, and so on. But what is Windows for?

Windows is the operating system (OS) that “coordinates” how your computer - the hardware - behaves while you are using it. Word and Chrome are applications built on top of Windows, they need the OS to access the resources of your PC. That is the reason why you need different executables if you want to run Chrome on Mac or Linux.

Operating systems are a key ingredient for modern software development. Imagine if, for any application to be built the developing team had to deal with building up the interfaces to control you keyboard, mouse and screen. That would have two bad consequences: (i) developing a software would require a lot of specific skills and programming the hardware interfaces would take more time than actually building the application; (ii) the behavior of different hardwares would be unstable when using the computer - different applications would treat your hardware differently. In conclusion, it would be extremely hard to build an application.

Operating system allows for the interoperability of parts and the development of applications. For instance, the manufacturer of a keyboard can write a driver for that keyboard in Windows - using standard protocols - which will make it usable for any applications in Windows. Moreover, a person that wants to develop an application for banking can also use Windows protocols to access the resources in the computer (the keyboard for instance), allowing developers to focus on the solution of the problem - solving the internet banking. Those building the application don’t need to communicate or understand how the keyboard integrates with the OS. It just works.

Processes act as operating systems. When well placed, it allows the interoperability of different people and teams without overcommunication between them. It allows them to execute the task at hand without caring about all the interfaces that integrate the solution to the whole. I will give two examples to illustrate how this works.

As a manager you start caring about the balance sheet and how results compound into financial results. But the teams that produce that result do not need to understand how all the parts combine to achieve the final result. You set goals to them, say, increase sales, and define (I like to do it together with the team) how much the metric can be moved. Then I provide the resources for them to execute and deliver the result. The team should not care about the balance sheet or the interface with the finance team - that is the management task, it is part of the process OS. This is similar to Brandon Chu’s idea of managing as a VC - each team should not care much about the VC portfolio result but should account fully for its product result.

Another example is the organogram. A manager gets the problem at hand, divides the problem in smaller parts that are coherent - and preferably allows teams to solve its slice of the problem end-to-end - and sets up the teams to solve the problem. If the interfaces between teams are solved, this improves the capability of the whole to solve the problem faster by splitting the problem in less complex parts and making individuals focus on a single task - which is more efficient than multi-tasking.

Using proven techniques as a starting point

Building an OS is not easy. Neither the making of a manager. It is a daunting task when nothing has been built. So where to start?

The best way to start is to have a mentor - maybe your leader - and read some seminal books on management. Copy as much as you can and try out everything that you think may fit your team. I started by copying some processes from managers I had before, but that did not work for me. Asking for help really works in my case, I love learning from people in live chats. The best book on the topic, in my opinion, is High Output Management by Andrew Grove. The key here is: just start out and iterate.

Once your OS is put in place you will find several problems - bugs. Don’t panic, this is normal. Just try different proven techniques, find references online, ask for people and try new things. The tip here is to keep a journal of your bugs and what you have learned trying to solve them - this will be the documentation of your OS and will help you clarify what are your “protocols”, which are faulty and will help you when communicating as a leader. In the end people you interact with need to understand how your OS works. A predictable relationship makes a healthy interface with the outside world - continuing with the metaphor, the user expects a consistent behavior from the OS, a blue screen is quite frustrating.

Be transparent and ask for feedback

An OS is not an OS without the interoperability of parties - hardware manufacturers, developers, users - within it. For a manager it is the same. And the feedback of those that “use” or built on top of the OS must contribute to improve it when problems are found.

The best way to improve as a manager is to be clear about your goals, how you proceed with your decisions and how you act with your teams using processes - standardized or not. Be transparent about your “protocols” and ask for feedback. Have a mentor and be eager for knowledge. As software, management practices deprecate fast and need to be constantly improved.