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.
If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub. The featured image from this post is taken from Flickr under the Creative Commons licence
Hi Patrick,
while I empathize with your sentiments, I see one big problem with it: if you give up coding in the way you describe, you are very likely to just become the next manager the coders will complain about.
Taylor’s idea of separating thinking about how to do the work from actually doing the work – that is, having manager positions – might have made sense a hundred years ago, but simply doesn’t any more in todays complex work environments and with todays highly educated workforce.
So, in my opinion what’s really needed is a work environment where coders actually *do* have control over organizational design.
Nice work Pat. I’m giving a talk tomorrow at the CTO Summit on the homomorphic effect of Conway’s Law and how system design can (eventually) have some control on the structure of the organization. I’ll share thoughts next time I see you.
Hi Ilja. Thanks your comment. I whole heartedly agree with you that we should be careful when we separate thinking from doing. It would be dangerous for managers to design software, only to have developers implement it without really understanding it.
I see the role of (some) managers slightly different. Where developers focus on creating a balanced-enough solution for a domain that is constantly changing, managers focus on the right environment that balances out business concerns that enables developers to do what they need to (along with other people in the business).
I’m not sure developers should have control or even want control over organisational design. They should certainly have input and influence but those are two different things. There needs to be a close relationships between different roles in an organisation to effective collaborate, but I think the different roles, when fulfilled well, focus on different things.
Hi Josh! That certainly sounds interesting – although I have no clue what homomorphic effect means! I would love to hear about it next time we meet, or if you write an article about it – point it out.
Cheers!
Hi Patrick. I totally agree that there is a difference between influence and control. And I mean control.
Yes, there are different roles in an organization, with different focus. And a role with the focus of controlling the work environment that others then have to do their work in is a dysfunctional one.
I know from experience – and there are lots of other examples out there -, that if you give developers (or any other non-manager) control over their own environment, and mindfully support them in making decisions together with everyone affected, as well as in understanding the consequences of their decisions (for themselves and the business), they are quite capable and willing to do so. And Good Things (TM) happen as a consequence.
Hi Ilja,
I agree with you that Good Things (TM) can happen when you give more authority for people to change their environment. In any sizeable organisation, this will be bounded by what control they were given. By managers (or other people with accountability)! Delegation is still effectively a different “control” mechanism, and more effective in some, but not all, circumstances.
But I feel we have moved away from the point of the post, which was to highlight that “not coding” does not automatically equal “bad.” A developer, moving into a Tech Lead role, or a Tech Lead moving into a management role will, regardless of their working environment, have a greater influence over their work environment. Their authority comes with the accountability and responsibility.
There are, of course, many other optimal organisational designs for more effective software delivery, but those are ultimately created by the upper-echelons of an organisation… management. They’re not all bad 🙂
My point is exactly that “not coding”, in fact, is “bad” – for the organization. Or more specifically, separating “having accountability” and “creating business value” into different roles and positions.
There are organizations – and I am working for one – where the “upper-echelons” are not managers, but coders (and other workers); and they are often wildly successful.
When you are in a more traditional organization, you certainly have the choice of moving out of coding to take on more accountability – and become another loathed manager (I am exaggerating for effect ;). Or you can decide to take on more accountability as a coder. The latter might be the harder choice.
Hi Ilja,
Thanks for your insight, discussion and sharing your own situation.
I am not arguing that “having accountability” and “creating business value” should be separate. In fact, everyone in the organisation should be “creating business value,” but they do so in different ways. I would also say that just because someone doesn’t code, doesn’t necessarily mean it is “bad” for the organisation – finance and marketing are typically roles that add tremendous value in business operations without needing coding skills… but I digress.
I believe that coding and management roles are not mutually exclusive. However I do not believe that any (normal) person can play both roles and fulfil all responsibilities of both roles in a sustainable manner. Time thinking/discussing/agreeing on (typical management) responsibilities means time/effort less spent on other responsibilities.
Going back to a Tech Lead example. A Tech Lead cannot spend their full week programming, when they were “just a developer.” Instead they have other responsibilities to take care of and they have traded off control (for certain amounts of code) for a broader influence. They are still writing code, but they do so less.
Hi Patrick,
my point is that they shouldn’t be separate roles. And they don’t need to be. In an “agile organization”, you don’t need Tech Leads in the traditional sense.
And I get the feeling that maybe we should just agree to disagree on that… 😉
One more point: of course, in an organization where managing is done by everyone, not by managers, coders will code less. And when they code, they will be much more effective. I find that actually to be *more* sustainable than the traditional way of working.
Hi Ilja,
I agree with you that Tech Leads in an “agile organisation” look different, and that in some organisations, they shouldn’t be separate. In others, they are and always will be (e.g. more traditional organisations).
I’m glad, also, to hear that this model is more sustainable for you. I’d love to read a blog post about your situation. It’d be great to hear about: How big the organisation is, how the structure was first established, how decisions are made (and when disagreements occur), and how accountability and consistency operates. It’s probably a bit too much for a comment.
Thanks again for the discussion.
Hi Patrick,
it’s actually also too much for a blog post. 😉
Fortunately, there already are a couple of blog posts. When you read them, keep in mind that all of those are snapshots – a month later, they were already outdated, at least in some aspects.
http://stefanroock.wordpress.com/2012/01/30/it-agile-state-of-play/
http://stefanroock.wordpress.com/2012/09/02/it-agile-28-weeks-later/
http://stefanroock.wordpress.com/2014/02/13/how-we-decide-at-it-agile/
There is more at http://www.it-agile.de/ueber-uns/unternehmen/ but most of it in German, sorry.
And, yes, we are relatively small consulting company. But there is enough evidence out there that the *principles* scale across domains and company sizes. Just take a look at Semco, for example….