The article misses something super critical: why?. More specifically why a key few hires can change the trajectory of a company. The answer almost always comes down to one word and applies companies of any size: leadership.
Leadership is a concept largely foreign to the software industry for two reasons.
* Most software developers are never exposed to strong personalities and have no idea what strong leadership looks like. An excellent software developer tends to score high in agreeability, but a strong leader knows how to turn that down to 0 for maximum confrontation and/or defiance.
* Strong leaders know when to not follow trends with extreme criticality. This is highly paradoxical since so many software companies are funded by advertising which is a business of growing trends. Real leaders set new trends and take share from existing players setting their brand reputation in the process. Most people in software are deathly afraid to abandon conventions of comfort whether in business or in product/process innovation.
> Leadership is a concept largely foreign to the software industry
Maybe in the companies you’ve worked for, but I haven’t found this to be true at all
> An excellent software developer tends to score high in agreeability, but a strong leader knows how to turn that down to 0 for maximum confrontation and/or defiance
Hard disagree. “Maximum confrontation and/or defiance” has never been a goal of good leaders who are trying to build a team that works together.
Encouraging people to speak their mind is good. Encouraging “maximum confrontation” is just going to create chaos. The goal is to work together to ship, not to argue and defy all the time. I can’t think of anyone who would want to work on a team where everyone had agreeableness dialed down to 0 where leaders encouraged confrontation all the time, except maybe for people who just like to argue a lot.
> Most people in software are deathly afraid to abandon conventions of comfort whether in business or in product/process innovation.
Another strong generalization that I can’t agree with. Most people I’ve worked with in software have been so aggressive about bucking trends and trying new things that we’ve had to dial it back a notch. A lot of the debates I’ve had with teams have been about choosing boring, stable technologies over the newest cutting edge technology that’s popular on Twitter. Same goes for business strategies, where I’ve had to deal with everyone from product managers to sales people trying to do things their own creative way when the standard, boring practices are what finally got the job done.
Leaders do more than build teams. Team building is inward looking. Real leaders are outward looking and have to be willing to defend their team(s) at personal cost.
This reads as a criticism of team building (maybe that wasn't your intent, but it was my first reading.)
Strong teams need a balance of transformational leadership, servant leadership, some laissez-fair management and some micromanagement (etc, etc).
I.e. situational leadership.
In my experience, given how many ANDs you need, the most successful teams have a combination of leadership styles and roles from different people at different times. Balancing leadership and responsibilities across people also allows the personal cost of such activities (whether it's emotional labour, political backlash, etc) to be distributed as well.
This, I also believe, is why co-foundership appears so often in stories of successful companies. You always end up with "the leader that is good at X despite Y", and there is always someone who can come in to provide "Y without necessarily X" in a way that makes their joint leadership work in ways that individually they would fail.
> Encouraging “maximum confrontation” is just going to create chaos. The goal is to work together to ship, not to argue and defy all the time. I can’t think of anyone who would want to work on a team where everyone had agreeableness dialed down to 0 where leaders encouraged confrontation all the time, except maybe for people who just like to argue a lot.
To "turn that down to 0" doesn't mean operating 100% of the time in non-agreeable mode. It also doesn't mean doing that only with your team. It also doesn't mean encouraging people to do it. It's just that sometimes you gotta put your foot down.
You jumped to another extreme, but the whole point is just that both extremes are problematic. An always 100%-agreeable leader needs a lot of luck to succeed.
I can see where you’re coming from and I have some more context to add, which can be helpful.
This phrase:
> a strong leader knows how to turn that down to 0 for maximum confrontation and/or defiance
Feels like something uttered by a cocaine snorting MBA who gets high off creating hostile work environments and enjoys firing people.
I’ve been in environments where everyone is agreeable because they have to be agreeable. They are agreeable to a fault. These environments have a banal toxicity that is hard to pin down, but it shows when there is disagreement. These orgs value agreement above all else, above performance, above achieving goals. They suppress valuable insight because it is uncomfortable to them. FUD is a great rhetorical strategy that I’ve see used to squelch conversation, thinly veiled appeals to authority is another. This breeds complacency and destroys value.
We have a management class in the west that believes that management can be a mechanistic exercise of gathering metrics, assessing performance, and assigning corrective actions. That it can both be systematized and abstracted away from the work is a core assumption of western management. This is a paint by numbers approach, similar to Searle's Chinese room, and works to take the leadership out of management.
You’re right that most of the time the best choice for your business and customers is to choose the boring, stable technology that works. Avoid the rewrite, don’t use the hottest new frameworks, or languages that are in vogue.
Experience shows generally to dismiss developer desires for novelty. But sometimes you do need a novel solution and your developers are the ones who are going to tell you. You will not figure this out by following the rules taught in management school. Metrics like CPI and SPI are only going to tell you that you’ve made the wrong choice on your project when it’s too late. You need to make a decision, which means seeking out information and making the best decision based on the information you can get. This takes leadership.
The best programmers I know have strong opinions. They will tell you that you are wrong. They do this to learn both to test themselves and the people around them. If they are wrong, the withdraw, then more on. It’s the most healthy thing I’ve seen and is actually what builds success.
Disagreement is healthy and good and should be encouraged, when the goal is knowledge gathering. A leader who is turning agreement to zero is a leader who wants to be decisive.
Stop the madness. It does not matter how things feel. It matters how things are measured, which includes employee retention and delivery and product quality. Most of the comments here loudly scream none of these people have been in management.
The one big difference between a leader and a contributor is ownership. Everyone here has danced around the idea of ownership without addressing it. Unless you have owned liability in a managerial capacity it doesn’t matter how things feel, because your perspective is too narrowly construed.
Disagreement, when voiced, is a form of confrontation. It is healthy. Healthy teams are brutally honest. Most of software absolutely abhors confrontation.
I'm sure all software developers have been exposed to strong personalities. Often in the form of bullies, primadonnas, class clowns, big men on campus, pointy haired bosses, etc.
The problem is that—as a generalization—strong personality tends to correlate inversely with competence, and software engineers esteem the latter above all else (because a machine is not swayed by charisma, after all).
Good leadership is really the combination of strong personality and competence. That combination is so rare that for most software engineers, the safest bet is to simply try to avoid employers with strong personalities entirely.
Aggressive personalities aren’t the same as strong personalities, in precisely the way status trinkets aren’t class.
I’d say strong personalities are essential for consensus:
When it’s clear who is holding court, there’s much less talking over each other and bickering, precisely because the leader has made it clear what the expectation is — and everyone knows it will be enforced.
“Let’s quiet down for a moment, I really want to hear what @edmundsauto is saying.”
There is a class of people who believe leadership is something you can learn on its own. These are the people who join all the useless commitees for resume building purposes. Leadership only has value when paired with significant knowledge in some domain.
> Avoiding strong personalities purely for the sake easing hostility sounds a lot like cowardice.
Cowardice is when you avoid something, because of fear. GP is talking about avoiding people who will annoy you.
> Cowardice is when you avoid something, because of fear. GP is talking about avoiding people who will annoy you.
That sounds like autism. Avoidance for what ever imaginary reason your creative mind can conjure is still cowardice. The excuses only fool yourself. Other people will see it as they choose.
what you call the "software industry" aligns with my experience in the "enterprise software industry"
outside of that, it couldn't be further from my experience. many many defiant and confrontational founders/PMs, who often actively avoid the accepted "best practice" and rethink what they're doing if they find themselves in the majority
> many many defiant and confrontational founders/PMs, who often actively avoid the accepted "best practice" and rethink what they're doing if they find themselves in the majority
My experience as well. Big enterprise software companies reward keeping your head down and toeing the line, but "confrontational and defiant" personalities trying to reinvent the wheel are a common feature at every other type of software company.
You may have missed the point of this article. Here, we’re being exposed to the “how”. Then why is unrelated to the why. If you have a why, the is the how to follow.
Leadership is a concept largely foreign to the software industry for two reasons.
* Most software developers are never exposed to strong personalities and have no idea what strong leadership looks like. An excellent software developer tends to score high in agreeability, but a strong leader knows how to turn that down to 0 for maximum confrontation and/or defiance.
* Strong leaders know when to not follow trends with extreme criticality. This is highly paradoxical since so many software companies are funded by advertising which is a business of growing trends. Real leaders set new trends and take share from existing players setting their brand reputation in the process. Most people in software are deathly afraid to abandon conventions of comfort whether in business or in product/process innovation.