Mastering Excellence in Technology
(thanks to pixabay)
I visited a company and talked to the CTO. Like many he complained about skilled people leaving the company as they could not become a manager post being a senior developer. I simply asked why tech career will stop after becoming senior and his answer was something like “it always was Junior-Regular-Senior”.
I’ve seen so many companies failing in letting become technologist real masters in what they are doing and I assume it happens in Marketing, Sales and other departments too. But simply said there is no reason doing so. There is no rule that after becoming Senior you either go down the management path, stay as Senior or leave to become Senior somewhere else.
What I did in my last few jobs as Interims CTO or advisor to the company was establishing a path to mastery beyond Senior. It may sound obvious to go further and create new profiles like lead developer (architect, operator, QA engineer …) or principal. The question is, how do you manage to move them towards those goals and what kinds of additional freedom do those roles imply.
When I started establishing such rules I was mainly motivated by Daniel Pink, the author of “Drive”. In his book he writes about the 3 pillars to get into a flow. While freedom in team, task, technology and time is one of them and purpose of the organization the other, the 3rd one is mastery. He asked the simply question why skilled and well-paid developers leave office to get home coding open source for free. His answer was beside the 2 others that people always want to get better in what they are doing. May it be coding, playing guitar or painting.
Next I figured out that mastery in technology can be tricky. Who is the better engineer to become lead developer. The one who knows everything about technology or the one who knows a lot about technology and is really good in supporting and educating others in the organization? The answer is: Both are essential for a working team. So figure out, how to best address their needs, desires and interests!
Finally we asked ourself what the benefit beside payment could be. The answer is freedom and responsibility. Freedom because you want them to become master. You only become master if you have a good trainer/teacher, the right environment and the ambition to become master. The more rigid the system the less the willingness was our approach so we defined levels of freedom. The better you are, the more responsibility you should get. There is tons of responsibility in a tech team without the need for a manager. Architectural decisions, devops design, assistance in product tech design, representation of the company on tech events and much more.
As a result we created an excel sheet showing everyone what we expect them to do in order to get promoted. It is a 2 path approach with the extras of freedom and responsibility. I learned from different organizations that it helped them in mastering technology. So I decided to publish it for free. Feel free to use it, adapt and change it. You are very welcome to send back feedback or your version of a tech mastery plan.
Download as XLS: skillmatrixv04generic
the knowing-doing gap
There is a great book out there from Pfeffer and Sutton writing about the difference in knowing and doing. Even if you know it will not become reality you often start doing something in that direction. Even if you know this brings you into a dangerous situation, you keep on running. It is scary, honestly but human too.
The same often happens when talking about operations, QA and development. Some examples: Even if developers know that untested code often results in bad behaviour, stress and pain, the code gets deployed. Even if operators know that they should provide a service (the infrastructure and related daemons) they much more try to build barriers to “ensure stability”. Even if QA knows that controlling isn’t enough it is much easier to tell somebody that he did not reach the line instead of helping him/her coming there. We are all obliged to support the company we work for. If the company is run by idiots, please leave otherwise do your work as you promised with your signature.
We all live in a time where time becomes an evident issue, pressure is high, likelihood to fail too, but we are no longer allowed to fail even if a lot of enterpreneural books write about fail-learn-improve cycles. Often this happens as we react not like we know we should react. Business pressure, politics, friendships and sometimes the missing willing to change make us to some sort of organisational animal, no longer reacting rational in a human manner, much more rational in a corporate manner.
But as we are all obliged to Quality, as it is our wish to product high quality products/services, as achieving mastery is one if the fundamental personal goals of “running” we should try to bring in more evidence, react on what we know and not what best fits know and stop doing if we recognize the difference in knowing and doing. Another reason why this is that hard: the organisational culture has to support such behaviour. Saying “no” or “we must change …” has nothing to do with blaming, it’s a positive escalation showing new ways of working and thinking and propably (hopefully) better ones. This has nothing to do with basic democracy, everyone should bring in his/her expertise and evidence to allow the company grow and prosper – knowing without doing isn’t enough!
Tom Peruzzi's thoughts on digital, innovation, IT and operations 
leave a comment