6 ms·

In my experience it is rarely enough to just "lead" more thoughtfully, which seems to be what the author here is promoting. Software development does not just r

by eggie 8y ago

In my experience it is rarely enough to just "lead" more thoughtfully, which seems to be what the author here is promoting. Software development does not just require servant leaders in the helping sense, but in the working sense. The best leaders in software and technical domains are also those who can write (either code or ideas) better than anyone else. They have the power to move the project forward on their own, and working with them lightens the effort for everyone. Those who also adopt the ideas in this essay do foster the sensation among those they lead that they were never led at all, and rather achieved their common objectives together.

marmaduke 8y ago
I don’t think these are exclusive. A technical lead should be able to write a proof of concept and support its evolution into a MVP by a team, fading in and out when required. I think the value of the article is in arguing that the ego typical of leaders has no place in engineering.
qznc 8y ago
It depends on what kind of leadership we talk about. Technical leadership: such leaders are often called architects. Of course they need deep technical knowledge. Project leadership: such leaders are often called project managers or product owners. They only need shallow technical knowledge and can mostly lean on their experts in their team. Human managers: they deal with personal growth and employment. They need enough technical knowledge to make employment decisions but need not be great programmers. In large companies these are usually different persons. In a startup the CTO does it all, so of course he must be very technically competent.
- citation_please 8y ago
  I think that these are different persons leads may be one of the causes of a lot of the negative symptoms we're seeing in project management in our industry. If I compare the teams that I've been on, a lot of the frustration was due to the communication (or lack thereof) between the leadership roles that you've described. The best teams where were single people were responsible for all types of leadership - even if it was more than one person. It does not always pay to specialize.
  - CamTin 8y ago
    This. The dominant way software teams are managed seems incredibly bonkers and is not the norm in any other industry I know about. In the "real world", you have a boss, and probably he has a boss and so on. In the software world, everything is "negotiated" and "consensus-driven". Totally different people are responsible for hiring, firing, promotion vs. everyday decisionmaking. No programmer has a single boss, they have many, often implied and nowhere on an official org chart. I think I understand how it got to be this way, and from a long-term professional point of view, it is probably good for programmers since it makes them less "cogs in a machine". It's also somewhat similar to "real" professions like lawyers, engineers (the kind with a title and professional responsibilities and, in Canada, an iron ring), and doctors, which I suspect programmers will ultimately become, thought it make take several hundred years. Still, it can be maddeningly complex and seems like a lot of the time is too much overhead. On the other hand, a team is an engineered thing just like any other, in that there are tradeoffs. Management and capital largely seem to prefer predictably-scheduled software projects with accurate estimates to fast iteration and low overhead. One way to make this tradeoff is to have several clipboard-holders on a team looking at metrics daily, and spending 1 day out of every 10 in "sprint planning".
    - CamTin 8y ago
      I should add that this "overhead" is, IMO, a good bit of the reason why other "professional" industries are so intractable to cost reductions, so long term the "professionalization" of programmers is probably bad for non-programmers (i.e. almost everyone) in the same way that the high cost of lawyer time is a disaster for ordinary people seeking justice (i.e. almost everyone), and the high cost of doctor time is a disaster for sick people (i.e. almost everyone). For example, rarely does a firm just "hire" a lawyer and tell him what to do: they have to at least play along with the fiction that they are "junior partners" in a "partnership". They have professional obligations (to the Bar, for example) that are outside their employment obligations. It's not unreasonably for there to be more "overhead" positions for a practice than there are lawyers, because his time is to incredibly valuable that it makes economic sense for him to hire several paralegals and a secretary, not counting the "junior partners" that are employees in all but name. If lawyers were cheap (i.e. there was no cartel and fewer barriers to practice), the practice of law would look much different, and vice versa.
monkeydreams 8y ago
> The best leaders in software and technical domains are also those who can write (either code or ideas) better than anyone else. Technical and programming skills have very little overlap with successful team management skills. It's the very essence of the Peter Principle.
- codingdave 8y ago
  I would say they have little inherent overlap, but they are not mutually exclusive. A leader can cultivate both skill sets. I think the problem arises because as we advance in technical skills, it is an incremental advancement over years. However, switching to a leadership role brings on a large, deliberate, fast learning curve to pick up brand new skill sets. Many new leaders just keep learning incrementally, taking far too long to get good at their new role. But the ones who do make a fast jump, and actively pursue their missing skills, tend to be great people to work with.
- dithering 8y ago
  Teaching skills are the bridge. That's what servant leadership is to me - not teaching in the "stand in front of the classroom" sense, but teaching in the "lets pair on this and figure it out together" sense.
- dropit_sphere 8y ago
  Sure, but team management skills often have no application without technical skills to give them context. The best leader in the world (whatever that means) will be severely hampered if they don't understand the problem domain.
- dfjliasjg 8y ago
  Management and entrepreneurship can be learned. That's what MBAs are for. Hell, the only reason I know what servant leadership IS is because I took a business degree about 10 years into my software career.
brlewis 8y ago
The best leaders in software and technical domains are also those who can write (either code or ideas) better than anyone else. Do you really believe that? When you're interviewing someone to be your manager, is that what you look for? I don't. I look for communication skills, career development ideas, and evidence that they stay cool under pressure. Software development experience is definitely a plus, but I don't look for someone as a manager who can code better than anyone else.
- eggie 8y ago
  I look for all of these things as well, and they are critical. But none of them have any relevance in a technical domain if the person who has them isn't capable of pulling more weight than anyone else. Management is only approximately a learned and transferable skill. At the end of the day, lack of capacity in the target domain will make any managerial knowhow useless. Also to be clear, I'm not talking about software development in the mythical man month sense, but systems thinking and a facility with abstractions and math combined with the ability to make such ideas real. Such people have the power to lift everyone up to their level, guide the group along an easy path, and fill in the gaps in ability present in their team. There is a reason that people learn martial arts from people who have developed skill at them, not those who are good at managing workouts. The latter will only teach you how to manage your workouts. If you want to learn an art, learn from a master. In technical domains the masters are the best leaders, and you learn from them in every sense.
  - bonecrusher2102 8y ago
    Martial arts are an individual pursuit. Software development is a team sport, which is precisely where your analogy falls apart. The best boxing coaches are not the best boxers. The best football, basketball coaches, sure, they may have experience as players, but you don't see the best players consistently go on to become great coaches. That's because leadership and coaching is a different skillset. I agree with a lot of e folks in this thread that perhaps the best combination here is a good (servant) leader to lead the team as a group, and an individual like a tech lead to train up on technical skill.
- 8y ago
TheReveller 8y ago
I disagree with this entirely, its basically the opposite of the point of the article. It sounds like the kind of leader that would have to insert their superior technical knowledge into every decision the team makes and who won't recruit the best people to take technical leadership of different aspects of the project. Maybe we're envisaging different kinds of projects here. If it were 3-5 people building some component I'd expect there to be a technical leader in that group that can push it forward, as you say. But even they might not be the 'best' coder, whatever that means. A 50 person project is never going to have a single person like that though.

by eggie 8y ago

marmaduke 8y ago

I don’t think these are exclusive. A technical lead should be able to write a proof of concept and support its evolution into a MVP by a team, fading in and out when required. I think the value of the article is in arguing that the ego typical of leaders has no place in engineering.

qznc 8y ago

It depends on what kind of leadership we talk about. Technical leadership: such leaders are often called architects. Of course they need deep technical knowledge. Project leadership: such leaders are often called project managers or product owners. They only need shallow technical knowledge and can mostly lean on their experts in their team. Human managers: they deal with personal growth and employment. They need enough technical knowledge to make employment decisions but need not be great programmers. In large companies these are usually different persons. In a startup the CTO does it all, so of course he must be very technically competent.

citation_please 8y ago
I think that these are different persons leads may be one of the causes of a lot of the negative symptoms we're seeing in project management in our industry. If I compare the teams that I've been on, a lot of the frustration was due to the communication (or lack thereof) between the leadership roles that you've described. The best teams where were single people were responsible for all types of leadership - even if it was more than one person. It does not always pay to specialize.
- CamTin 8y ago
  This. The dominant way software teams are managed seems incredibly bonkers and is not the norm in any other industry I know about. In the "real world", you have a boss, and probably he has a boss and so on. In the software world, everything is "negotiated" and "consensus-driven". Totally different people are responsible for hiring, firing, promotion vs. everyday decisionmaking. No programmer has a single boss, they have many, often implied and nowhere on an official org chart. I think I understand how it got to be this way, and from a long-term professional point of view, it is probably good for programmers since it makes them less "cogs in a machine". It's also somewhat similar to "real" professions like lawyers, engineers (the kind with a title and professional responsibilities and, in Canada, an iron ring), and doctors, which I suspect programmers will ultimately become, thought it make take several hundred years. Still, it can be maddeningly complex and seems like a lot of the time is too much overhead. On the other hand, a team is an engineered thing just like any other, in that there are tradeoffs. Management and capital largely seem to prefer predictably-scheduled software projects with accurate estimates to fast iteration and low overhead. One way to make this tradeoff is to have several clipboard-holders on a team looking at metrics daily, and spending 1 day out of every 10 in "sprint planning".
  - CamTin 8y ago
    I should add that this "overhead" is, IMO, a good bit of the reason why other "professional" industries are so intractable to cost reductions, so long term the "professionalization" of programmers is probably bad for non-programmers (i.e. almost everyone) in the same way that the high cost of lawyer time is a disaster for ordinary people seeking justice (i.e. almost everyone), and the high cost of doctor time is a disaster for sick people (i.e. almost everyone). For example, rarely does a firm just "hire" a lawyer and tell him what to do: they have to at least play along with the fiction that they are "junior partners" in a "partnership". They have professional obligations (to the Bar, for example) that are outside their employment obligations. It's not unreasonably for there to be more "overhead" positions for a practice than there are lawyers, because his time is to incredibly valuable that it makes economic sense for him to hire several paralegals and a secretary, not counting the "junior partners" that are employees in all but name. If lawyers were cheap (i.e. there was no cartel and fewer barriers to practice), the practice of law would look much different, and vice versa.

monkeydreams 8y ago

> The best leaders in software and technical domains are also those who can write (either code or ideas) better than anyone else. Technical and programming skills have very little overlap with successful team management skills. It's the very essence of the Peter Principle.

codingdave 8y ago
I would say they have little inherent overlap, but they are not mutually exclusive. A leader can cultivate both skill sets. I think the problem arises because as we advance in technical skills, it is an incremental advancement over years. However, switching to a leadership role brings on a large, deliberate, fast learning curve to pick up brand new skill sets. Many new leaders just keep learning incrementally, taking far too long to get good at their new role. But the ones who do make a fast jump, and actively pursue their missing skills, tend to be great people to work with.
dithering 8y ago
Teaching skills are the bridge. That's what servant leadership is to me - not teaching in the "stand in front of the classroom" sense, but teaching in the "lets pair on this and figure it out together" sense.
dropit_sphere 8y ago
Sure, but team management skills often have no application without technical skills to give them context. The best leader in the world (whatever that means) will be severely hampered if they don't understand the problem domain.
dfjliasjg 8y ago
Management and entrepreneurship can be learned. That's what MBAs are for. Hell, the only reason I know what servant leadership IS is because I took a business degree about 10 years into my software career.

brlewis 8y ago

The best leaders in software and technical domains are also those who can write (either code or ideas) better than anyone else. Do you really believe that? When you're interviewing someone to be your manager, is that what you look for? I don't. I look for communication skills, career development ideas, and evidence that they stay cool under pressure. Software development experience is definitely a plus, but I don't look for someone as a manager who can code better than anyone else.

eggie 8y ago
I look for all of these things as well, and they are critical. But none of them have any relevance in a technical domain if the person who has them isn't capable of pulling more weight than anyone else. Management is only approximately a learned and transferable skill. At the end of the day, lack of capacity in the target domain will make any managerial knowhow useless. Also to be clear, I'm not talking about software development in the mythical man month sense, but systems thinking and a facility with abstractions and math combined with the ability to make such ideas real. Such people have the power to lift everyone up to their level, guide the group along an easy path, and fill in the gaps in ability present in their team. There is a reason that people learn martial arts from people who have developed skill at them, not those who are good at managing workouts. The latter will only teach you how to manage your workouts. If you want to learn an art, learn from a master. In technical domains the masters are the best leaders, and you learn from them in every sense.
- bonecrusher2102 8y ago
  Martial arts are an individual pursuit. Software development is a team sport, which is precisely where your analogy falls apart. The best boxing coaches are not the best boxers. The best football, basketball coaches, sure, they may have experience as players, but you don't see the best players consistently go on to become great coaches. That's because leadership and coaching is a different skillset. I agree with a lot of e folks in this thread that perhaps the best combination here is a good (servant) leader to lead the team as a group, and an individual like a tech lead to train up on technical skill.
8y ago

TheReveller 8y ago

I disagree with this entirely, its basically the opposite of the point of the article. It sounds like the kind of leader that would have to insert their superior technical knowledge into every decision the team makes and who won't recruit the best people to take technical leadership of different aspects of the project. Maybe we're envisaging different kinds of projects here. If it were 3-5 people building some component I'd expect there to be a technical leader in that group that can push it forward, as you say. But even they might not be the 'best' coder, whatever that means. A 50 person project is never going to have a single person like that though.