A background story
A friend of mine worked as a Tech Lead, let’s call them Jo (not their real name) for most of their career. A few years ago, Jo moved into a management role that involved very little coding. They were no longer working full-time as a developer and they stopped playing a Tech Lead role. Jo now leads an organisation with six or seven large development groups.
In the definition of a Tech Lead, I suggested a Tech Lead should write code a minimum of 30% of their time. Jo managed to find some time writing code, but it was inconsistent – about an hour a week. In a 40-hour week, that is less than 3%. Jo missed writing code. Jo was no longer a developer and Jo was no Tech Lead.
What do you control? What do you influence?
Every role comes with a set of responsibilities, and the authority to fulfil those responsibilities. This authority gives you a certain amount of control.
For example, a developer has control over the code and tests that they design and write. Others may have influence over the code. Examples of influencing factors include architectural or product and/or platform constraints, team code standards and code reviews. Ultimately the developer has control over their own code.
Every company has a certain organisational design. Developers (and other employees) work within this structure. The organisational design impacts on how effective software delivery is. Rigidly hierarchical structures with completely different departments (e.g. developers and testers) have difficulty collaborating. An ineffective organisational design is a sore point for many developers because it makes delivering software much harder.
A developer has zero control over organisational design. They might be able to influence it, but it is ultimately controlled by managers. Some developers may try to change this, but most complain. I have heard this from developers in the past:
Who’s brilliant idea was to setup a development [team] like this?
Another example.
I can’t get anything done because I rely on those people to get something done and they sit on another floor.
Developers can complain, which is an ineffective style of influencing, although there are many more effective ways. In the book Influence: The Psychology of Persuasion, the author, Robert Cialdini outlines six key influencing strategies: Reciprocity, Commitment (and Consistency), Social Proof, Liking (a variant of the Halo Effect), Authority, and Scarcity.
Developers only influence their working environment. They do not control it. Note: An exception is, of course, when a company is small enough that the developer also takes on general organisational management responsibilities (e.g. in a startup)
Trading control for influence
Jo, who moved from being a developer to a Tech Lead, and again from a Tech Lead to a general manager shared an interesting insight with me.
You know those things I used to complain about as a developer? Well, now I have the ability to change them.
Programmers see the “non-technical” path as a path with nothing to offer. When programmers step into a leadership role, they inherit both responsibilities and the authority to control more of their work environment. A developer works within these constraints. A Tech Lead has more authority to change those constraints, and a manager even more authority to control and change those constraints.
How does this impact developers who become Tech Leads?
When developers give up their control in trade of influence, their sphere of influence grows. Instead of developing a single feature, they can guide the entire technical solution. The Tech Lead’s influence also grows between the technical and the business side. A Tech Lead has much more influence over how technology can be used to solve business problems, while developers are engaged too late.
I would suggest to Tech Leads never to give up all coding. Instead, it is trading more of the time you would spend crafting code, in exchange for a wider sphere of influence. The wider sphere of influence helps not just you, but also your team write better code in a better work environment.
| Reference: | Why you want to give up coding from our JCG partner Patrick Kua at the THEKUA.COM@WORK blog. |
