Growing pains - consumer vs producer
“What exactly is it that I’m meant to be doing?” It’s a question I asked myself when I first moved into a role as an Engineering Manager (and to be fair, it’s a question I still ask myself quite often!)
After giving it some thought, I realised many of the concerns I had were more about growth in general and so prompted a series of blog posts I’m calling Growing pains.
What does it mean to grow?
This question is the focus of this first post and the answer I think is one that I’ve distilled down to:
a transition from being a consumer of information, to a producer of it.
I believe that growth and development in any discipline can be described as a journey along this spectrum. Take software development as an example; at the start of your career you are mainly focussed with learning and growing your skills, i.e. you’re a consumer of information.
Over time as you grow that balance slowly starts to shift. You start to get more involved in making bigger technical decisions and increasing your influence both in terms of the codebase, the technical architecture and the people and team around you. You start to produce information which others consume.
Keeping a close eye on where you think you are on this scale can be a simple yet effective way of measuring your own performance. To see if you’re growing in your role, ask yourself “Am I producing more information than I was doing 6 months ago”, or perhaps “Am I consuming different information than what I was consuming 6 months ago” (depending on how far along your journey you are).
It’s funny because I can remember very clearly when this idea first came to me. It was when I first changed roles from being a developer to being an Engineering Manager and was trying to understand what my new role entailed. I initially described it in exactly in this way; I considered that becoming a manager meant being in a role that produces information, and specifically, produces information for the tech team to consume.
With hindsight now I can see it’s not really a shift, but rather just a redefinition of what information I’m dealing with. While it was true that my move into engineering management did indeed involve producing information for the product team to consume, in reality it was closer to a transformation of information that I was consuming, at least at first.
I had failed to account for the fact that while I had managed to grow and become relatively experienced and senior as a developer, I was starting a new role; I was also now a junior manager. I had to first re-learn how to consume information; consume from the CEO, consume from the CTO and other more experienced managers. I had to learn, take that information and translate; I had to work my way back up to being a producer.
Shuhari
My thoughts on this post were influenced by the Japanese concept of Shuhari; the path to mastery. it talks about a process of learning that can be described as
first learn, then detach, and finally transcend.
the 3 stages of learning according to this philosophy are:
Shu (obey)
Stage 1 involves strict instruction and rules to follow. For example, when learning to cook, follow a pre-defined recipe to the letter.
Ha (detach, digress)
Once sufficiently experienced, you no longer need to rely on the recipe. You start to adapt and innovate, building upon the original recipe.
Ri (transcendence)
You have reached mastery. You no longer use existing recipes as a base for your ideas, but rather create your own.
Interested in making an Impact? Join the carwow-team!
Feeling social? Connect with us on Twitter and LinkedIn
