Currently working at a place that considers itself 'flat' I can say that it's one of the most confusing things ever, and the management tries to continually tell me that it's such a great thing that everyone can take ownership of things themselves. It's a bunch of bull really, it just means no one has to take responsibility for failures to meet goals, there's no pressure to meet deadline and there's no actual ownership of product. This article hits all the points on the head about said flat structures, and how they don't work at all. They breed distrust, and resentment toward management because of an apparent (or real) lack of defining what's expected.
Whilst I don't doubt your experience - your anecdote doesn't mean that there can never be a functional "flat" structure for a business and that any attempt to implement such a thing will destroy your company. I don't really think the article comes close to showing that either, but that's just an opinion.
I have also found that the flatness fails quickly when the loudest, most aggressive, least-respectful-of-authority, best-dev-in-the-room type takes the (de-facto) leadership position, bullying others who challenge him. Schoolyard stuff, to be sure, and since most people don't like conflict for extended periods of time, you end up with a local "leader" (scare quotes intended) despite the intention to remain flat. It's the "rock star dev who's also a jerk", and eventually it creates chaos.
I actually think that's where flatness works best.
Rather than being whoever can kiss the most ass and not upset the boss (the usual system), a flat system ends up being a battle for leadership which puts the smart and commanding at the top. "Rock star dev who's also a jerk" is who should be the boss.
Where I work we have a role called "project anchor". It comes with no extra pay, no special perks, no particular enumerated powers.
The anchor does not determine product features or direction, that's the product manager's role. The anchor doesn't hire, fire, reward or punish other engineers, that's the engineering manager's role.
The anchor isn't necessarily the strongest engineer on the project, either.
Anchors are mostly there to break ties and hold project context over a longer time frame. A founding anchor has a strong influence on the project's technical direction, but it's not a fiat power. You still need to discuss it with your peers.
And it works pretty well, because the only reason you get asked to anchor is due to the feedback of your peers.
Then again, our hiring process has a notorious bias against rockstar jerks.
I work for Pivotal Labs. Our starting point is XP for engineering, Lean for design and product management. Daily standup, weekly IPM, weekly retro.
Lots of people know us mostly for Pivotal Tracker, which is built to support our daily and weekly workflow.
On any given engagement, we always argue for a minimum team of one product manager, one designer, two engineers. We used to be a purely engineering shop, but (before my time) the thinking grew to include all three roles in each project. Previously anchors were also de facto product managers, which is a tricky and exhausting doubling-up of duties.
When this happens now, we call it "super-anchoring" and it's seen as a project smell. I've had to act as a super-anchor once or twice; it's how I learnt that having a separate product management role is essential to a healthy project.
I like how we work. As an engineer I trust product managers to worry about what to build next and why, I trust designers to be across the user's needs and UX flow and conceptualisation. They trust me to pick a simple, robust engineering solution without gold-plating.
Anyone can give input, of course. I've had PMs make great engineering suggestions. I've seen engineers with UX breakthroughs. Engineers in an IPM ask all sorts of fiddly questions that will typically lead to product changes.
We ultimately own our own roles and get final say on them. It works because it's built on mutual trust and respect.
Really? "Rock star dev who's also a jerk" is typically driven by ego, whereas the actual leader should be driven by the needs of the business and the needs of the customer, and be talented at balancing the two. He should also be a good consensus-builder and emotionally capable, which this guy is by definition not.
So you'll get "impressive" code that leverages sexy technologies that is also late, buggy, and not what the customer actually needs. And on top of it all you'll have a demoralized drama-prone team.
I challenge you to find actual leaders in the past, ones we use as examples, who would fit your description of "an actual leader".
A leader is someone who can get people to get shit done. Usually it means convincing them that what the leader wants done is the thing to be done. Consensus-building can be done in many different way - in particular, a very good way is to just arbitrarily announce what the consensus is. In most fields, and in pretty much 99% of business, almost decision is better than prolonged periods of not knowing what to do. And if a leader is competent in the field in question, his arbitrary decisions will usually be good.
So as long as you can align their ego with business/customer needs, a "rock star dev who's also a jerk" isn't the worst choice for a leader.
As for your challenge, just about anyone I have worked for and respected. You don't know them, so you can use a No True Scotsman defense, I guess. That won't change that ego/jerkiness is completely unnecessary.
Bad decisions are catastropic in tech. That's a driving force for things like Agile. Running off and coding or building things without a plan is a recipe for disaster.
I can make you do something by screaming at you. That works to get you up over that hill to attack the pillbox. Doesn't work so well in tech where you will just quit.
But why do you assume that "rockstar dev who's being a jerk" means a despotic leader who only screams at people? I read it as a leader who is a) very opinionated, b) doesn't tolerate bullshit, c) may express himself in an offensive way. You could say that e.g. Patton was a rock-star jerk of military warfare, but it didn't mean he screamed at everyone all the time.
> Bad decisions are catastropic in tech.
No, they're not. What's the worst that could happen? Your SaaS cats-on-Instagram-to-save-the-world startup will flop. Or you won't deliver some product that's being delivered by 2000 identical companies around the world. Or some people won't get to see some annoying ads.
We're not talking medicine or space travel here. If we were, we'd be focusing on whether a leader is effective, not whether he's a nice person.
I happen to agree with you, in this scenario the leader is someone who leads, not someone who is given a title.
The downside is that their goals may not align well with the company.
pros and cons to everything, but I think it's a mistake to dismiss the idea that the person who stepped up, took the responsibility, and was able to get others to follow isn't the person who should be the leader.
Eric Schmidt at Google was pretty close to that description. He made decisions effectively, but he also listened extensively to input, respected his employees, and would build consensus rather than shouting loudly.
"If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea."
It works if you build a ship, little worse if you have to carve out 10 000 bricks from stone slabs before the end of the week. Working on your passion is something not many of us can experience, and is absolutely not the norm on the job market, even in tech.
I hate the term rock star dev because it brings up an image of a node.js guy using MongoDB as an ACID data store and writing his own unknownium.js or something like that - if the rest of your team is impressed by that - you're in deep shit anyway.
But I've noticed that in IT/programming people recognize and respect each other on skill and also form "respect based hierarchy" implicitly more than usual. Not suggesting that IT/programming is utopian meritocracy or anything just that from my impressions it's much more meritocratic than other professions I've worked in/by (print, news editing, management) - so it's more likely you get positive results with such open structure.
At my company the "rock star devs" are the probably-autistic guys who knows the answer to everyone's archaic legacy and interoperability questions, are the only guys who actually know assembly, catch the subtle mistakes at code review long before anyone else sees them coming, force us to move technologies when it is absolutely necessary and no sooner, and their code makes up roughly half of the code-base.
What's more, they are complete assholes. And yet, everyone under them respects them and marches to their drumbeat. Their teams get real work done.
If someone thinks there is a better leader than that I'm not sure who the hell they're talking about.
I've met (only a few) devs who are as you describe, but instead of socially incompetent assholes they were committed to humility, cooperation, and professionalism in the best sense of the word. They were better leaders than what you describe.
I actually don't get where this stereotype that the best in our field are inevitably jerks comes from. If you're smart enough to rise to the top engineering-wise, you're probably also smart enough to realize that ours is a collaborative field, no one is right 100% of the time, and that you catch more flies with honey than vinegar.
> So you'll get "impressive" code that leverages sexy technologies that is also late, buggy, and not what the customer actually needs.
The rock star dev is by definition the best dev you have, so no you'll the best code you could from your team since the best guy would be spearheading it.
> a flat system ends up being a battle for leadership which puts the smart and commanding at the top
It ends up putting the person who's the least bother in that role compared to all the other roles they could occupy in charge. People you go along with while looking for another job, because at the end of the day it's not your company and it's not worth the enormous emotional cost of fighting them.
While I have no experience with an organization that is officially flat, I have plenty of experience with large dev teams with indifferent managers that effectively created a flat organization.
In my experience, it's rare that the most "commanding" dev is also one of the more talented devs. If anything, my experience is the opposite: the stronger personalities are great examples of the Dunning-Kruger effect, while the best devs have more passive personalities (or just don't care enough to try to commandeer leadership of the team).
It's not like "kissing the most ass" is limited to kissing the ass of upper management. The same types that are exceptional at kissing the ass of management can also be great at playing Lord of the Flies with development teams (forming alliances, turning devs against eachother). It makes for a terrible work environment.
I much prefer strong hierarchical management, assuming management is competent enough to promote those with both development expertise and the people skills necessary for management (consensus building, mentorship, clarity of purpose, motivating people, etc).
Maybe it's worth distinguishing between developers who are opinionated about how something should be built because they care about the process/results, versus those who are self-promoting with whatever cause-du-jour is convenient.
> a flat system ends up being a battle for leadership which puts the smart and commanding at the top
The problem is you've described someone entirely different, here, IMO.
A smart leader isn't the loudest. Because they know when to listen to their subordinates, and don't need to be the loudest to command attention when they do speak.
They don't need to be a jerk, or rely on bullying - for this is morale destroying counterproductive pettiness, and again unnecessary when it comes to commanding attention and respect. It might not chase away all of your talent, but it will chase away some of it, who will leave for greener pastures where they're respected.
In my experience, the "Rock star dev who's also a jerk" was both the worst leader and the worst dev. They wrote a bunch of short sighted hacks - making them "productive" "rock stars" - that constantly broke things that other people had to fix. They were quick to assume their half baked ideas of how to proceed were the one true way - and that you were an idiot for thinking otherwise - and quick to dismiss any and all concerns about things they overlooked in their plans. It was bad enough that the best way to get anything done ended up being to hide it from the "rock star dev who's also a jerk". This is the antithesis of what good leadership should result in. That they were too busy doing development to do any real leadership was perhaps a blessing.
That's not to say the ideal leader can't ever be loud, or stern, or a dev. These can all be useful qualities at times. But they're not "a jerk", and may find they have less time available to spend on development in response to the burdens of leadership.
> In my experience, the "Rock star dev who's also a jerk" was both the worst leader and the worst dev. They wrote a bunch of short sighted hacks - making them "productive" "rock stars" - that constantly broke things that other people had to fix.
Those are not rock star devs, those are just shitty devs. The term rock star means your best devs, not your worst, by definition. If you're applying the label to shitty devs, you've missed the point of the term. A rock star is someone who's awesome, that's the entire point of the slang.
I see a rock star dev as the guy that seems the best from the outside: most likely because he completes tasks fast at the expense of being maintainable, documented, or understood by the rest of the team. The rock star must be smart because they're using a ton of technologies that nobody else understands. But do you really want that?
Part of the disagreement is surely semantics: if you want to define "rock star" as the best, then I guess they're the best (however you measure that).
But being a jerk is not semantics. If that works for your organization, great. But I don't want to have to deal with that.
> I see a rock star dev as the guy that seems the best from the outside: most likely because he completes tasks fast at the expense of being maintainable, documented, or understood by the rest of the team.
That's not a rock-star, it's not what the term means.
As for your main point, most people don't want to deal with jerks, so what? That doesn't mean anything when it comes to whether the jerk is a good leader or not. Lots of leaders are jerks, it's rather common to people who feel "they should be in charge".
Leaders are those who take charge, and lead. Naturally they find ways to take charge of a leaderless group and while you want to say they shouldn't be the leader, they are by virtue of being the only leader there. The smart guy you think would make a better leader, generally doesn't want to be leader and will let the jerk take charge; that actually disqualifies them as good leaders because a good leader wouldn't do that.
> That's not a rock-star, it's not what the term means.
How are we defining "your best devs" then, exactly, if "rock star who's also a jerk" isn't a contradiction?
> As for your main point, most people don't want to deal with jerks, so what? That doesn't mean anything when it comes to whether the jerk is a good leader or not.
Do you not see the inherit conflict between being "a good leader" and "driving away the talent on your team"? If your leader is toxic enough that everyone would rather quit than work with them, how are they supposed to function as a leader? There's going to be nobody left to lead!
Let's say they're not quite that toxic. Instead, they're merely driving down morale, merely making everyone want to think about anything but work, stressing them out. Will these people be bringing their A game? And doing their best work? And communicating effectively with leadership so the correct work gets done, instead of avoiding the jerk as much as possible?
Let's say they're not quite that toxic. Instead, they just forgot to bring doughnuts into work on your birthday. Are they actually a jerk?
> Naturally they find ways to take charge of a leaderless group
No such thing. There may be no official leader, or no clear singular leader, but if nothing else people will always lead themselves. Anyone displacing that leadership must provide more value than what exists for their leadership to be a net positive. That may be a fairly low bar at times, but sufficiently toxic individuals won't clear it - as they'll be removing value instead.
> The smart guy you think would make a better leader, generally doesn't want to be leader and will let the jerk take charge; that actually disqualifies them as good leaders because a good leader wouldn't do that.
Well, I'd agree it isn't good leadership. I've seen people learn from this mistake.
>"If your leader is toxic enough that everyone would rather quit than work with them, how are they supposed to function as a leader?"
No one said toxic. They said jerk.
I quite like working with a bunch of opinionated assholes that are willing to argue to the bottom of something, and have no personal investment in me liking them.
The great thing about jerks is that they don't take it personally. When you see the jerk the next day, you're still at square one. You will always be at square one.
Not friends, not enemies, just coworkers doing your job -- willing to step on each others toes to get things done the right way.
I've worked at places where everyone is nice. It's hell. "Nice" people are bad: morally, ethically, and for the bottom line.
Being a jerk is toxic. Being an asshole is toxic. If they're not toxic, why are you calling them these things?
> I quite like working with a bunch of opinionated assholes that are willing to argue to the bottom of something, and have no personal investment in me liking them.
I like working with opinionated people that are willing to argue to the bottom of something. So much so that I ended up following the most argumentative person from my previous job to my current one.
None of that required them to be an asshole. We have a boardgames night every couple of weeks now.
> The great thing about jerks is that they don't take it personally.
Jerks tend to make it personal. That's one of the main reasons they tend to be jerks!
> Not friends, not enemies, just coworkers doing your job
I'm entirely fine with professional relationships. Professional doesn't imply jerk.
> willing to step on each others toes to get things done the right way.
Sure. But a professional can do this without finding their cleats and stomping as hard as they can.
> I've worked at places where everyone is nice. It's hell. "Nice" people are bad: morally, ethically, and for the bottom line.
Your inconsistent air quotes betray the problem here, I think.
People who are bad morally and ethically are not nice people. They are jerks. They are assholes. That some of them are grinfucking everyone to appear nice doesn't make them nice.
And, conversely, the fact that some people aren't grinfucking you doesn't make them jerks. That they're willing to debate something honestly with you doesn't make them an asshole. That they're trying to do things right - and save your team from future stress, crunch, or whatever other consequences would come from doing things wrong - sounds like they're trying to do everyone a favor. If anything, they sound nice.
-------
EDIT: Ultimately, I wonder how much of this thread is you saying...
At most of the places I've worked, especially outside of tech, "professional relationships", "aren't grinfucking you" and "willing to debate something honestly" are the three criteria for being instantly labeled a jerk.
Adding one thing not addressed directly: sometimes people disagree and there needs to be a decision mechanism.
Consensus is obviously preferable. But it scales very poorly. A simple workaround is to nominate someone as the tie-breaker. To avoid secondary rounds of nonsense, you try to pick someone with the respect of their peers.
Conway's Law & micro-services help maintain flatter organizations at least in tech focused companies. When disagreements arise & consensus is hard, the various parties can simply introduce a new service boundary & go their different ways.
We have exactly that. Eight microservices that should have been two, all using slightly different technlogy, and still nobody buys our product since everybody disagree on what customers actually need.
Holocracy actually doesn't use consensus. The mechanism in Holocracy for decision making can be summarized as "do whatever you think is right to fulfill your stated role. No consensus nessesary. If the way your doing thing is actively preventing someone from fulfilling their role, then you two work it out (through a strict mediation process) but other people's opinion of what you should do is irrelevant (i.e. No consensous). Only the roles directly effected have to agree." Consensous seeking usually descends in to hypotheticals, theory, and butt covering. far better, according to Holocracy to just let people animate their assigned roles however they think is best.
> Consensous seeking usually descends in to hypotheticals, theory, and butt covering.
If reward and punishment are tied to individual judgement, everything descends into hypotheticals, theory, and butt covering.
Consensus is nice because it's a relative of shared understanding. When it can't be achieved, trying to achieve it still increases shared understanding. Having a tie-breaker is the only role you need in small groups.
I know a number of people who have quit Valve and almost all of them would cite organizational dysfunction as one of the top reasons for quitting.
I don't know whether that is true -- I have never worked there -- and I don't wish to spread any ill rumors about Valve. I'm just saying that I know a bunch of people who have worked there who think the flat thing is one of Valve's biggest problems (another one being the incentive structure; of course these two things go hand in hand).
Gotcha. I haven't worked there either; but I find the boosterism I sometimes observe to be annoying because of the confounding factor of massive free cashflow.
What I've heard is that Valve is a typical "flat" org. Wherein there is an elite/cabal of folks who need to be on board any project for it to actually get done. As a consequence, almost no major projects get done. When was the last time Valve shipped a game? Dota 2? That and incremental work on Steam has been most of what they've done for the last many years.
Yeah, I was a fan when I'd first read the employee handbook, but then I thought about it and of course, it would just look like high school again. The cool kids set the course and nothing else is taken seriously.
Valve has multiple products, and each project has a team, and each team has a leader. Individual teams have structure and autonomy. The success of their projects is measurable and attributable to the team and its leadership. The startups that try to be flat and fail usually have one product with lots of projects and no real leadership. Everyone and no one is responsible for everything and nothing.
Another issue with flat structure is that once implicit management roles arise, other people tend to hold those individuals responsible for results even as they lack official support for the role. It builds resentment towards them and puts them in a difficult position.
In my experience, the thing that I've seen kill the motivation and productivity of any team, is the feeling – true or not – that the team isn't being listened to. From what I've seen, most people seem to be able to cope with most any structure, but if feedback goes (seemingly, at least) unnoticed then that more than anything will kill their motivation. No amount of flat, or structure, or holymoly organization voodoo will fix a team that's lost trust in their ability to do anything because they aren't being listened to.
My understanding is that you can be flat and still have a project lead who is in charge of driving the project to the finish line. I'm skeptical of flat myself but I'm not sure if it is to blame in your situation. Rather, you seemed to need a lead whose job is to ultimately make the project succeed.
Flat systems value the accumulation of power over the actual work done. So if you are good at working the system, then you'll do fine. Otherwise, you have no protection. Wikipedia is a good example of a flat system where people accumulate power in other ways, usually by banding with others to enforce a particular point of view. While the goal is ostensibly creating content, much of the time is taken up on power disputes that are not aligned with the goal of the organization. This political infighting leads inevitably to harassment of those who do not fit the system. In Wikipedia's case, minorities, women, and non-aggressive users find it difficult to gain power from the entrenched power groups, while those in power think nothing is wrong because they erroneously think the flat system gives everyone a fair chance. Combined with a lack of leadership, flat systems result in inefficient processes and inconsistent work compared to hierarchical systems where everyone knows their role and a leader guides the project, and has the final say.
Except every problem you just listed with flat systems is endemic in hierarchical systems too, to the same extent (including everyone in power thinking the system gives everyone a fair chance). Nothing about an org chart and formal channels of action has ever stopped politics and informal channels.
This article is very interesting but fails to address one point. Why companies go for "Flat" or "Holocracy" organizations? I know three reasons:
- People tend to hate managers, they don't trust them.
- Flat team are faster removing the management complexity.
- There's more flexibility and more creativity around the problem tackled by the team.
The last reason is reasonable but is true applied for small unit inside the bigger organization, not the whole organization, as this article explains well. Nothing prevent to create a small unit with a specific task inside a bigger organization and to organize this unit (usually made by "star" employee) in a flat structure.
The second reason is disputable, it doesn't scale has the article suggest.
But the first reason is not addressed. And it is the real issue. I think everyone had terrible bosses and great bosses. We usually remember terrible managers as an example of the average managers (Mental association: Dilbert's Pointy Hair Boss) while we consider the great bosses we had as mentors, role models, guide. And we forget that they were also our manager. It is a form of selection bias.
There's also another issue at play, changing organizational structure, trying Flat or Holocracy is easy (I'm not saying that it's easy to do it right, it's easy to give it a try). Promoting the right person, with the right skills is difficult. And if you promote the wrong person (it happens) removing from a managerial position or moving him to a position that is a better fit is extremely difficult. So we all decide to do what is easy instead of what is difficult. Not sure I could blame someone, it is the people mindset, but doesn't mean that what is easy is also correct while what is difficult, when done right, proved to be correct.
There is a lot of talk about how the problem is "bad" or "crappy" managers, which I think allows many of us in the vast masses of untrained tech managers to feel warmer and fuzzier, because while we might not really know what we're doing, we're good-natured and right-thinking, so surely we're not crappy managers! In reality, I think mediocre management is the much larger problem. Or put another way, the idea that management skills are not something to be invested heavily in, but rather something to be "figured out". It may be true that a well-managed organization full of good professional managers is more efficient than less management-focused structures, but I'm not convinced that most organizations are willing to invest the resources to hire or train their way into having one of those, so other structures are a sensible alternative to explore.
> There’s an impulse among companies these days to differentiate themselves .... or most recently and most astonishingly, [by] raising your minimum salary to $70,000 per year.
Really? Raising the minimum wage was about "differentiating" themselves, and not out of the realization that everyone needs a comfortable wage to live on?
I'm sorry, but I can't take an analysis by such a person seriously. This attitude demonstrates a fundamental lack of understanding.
This isn't a real counter-point, imo. This basically says "flat didn't scale, so we introduced some structure or other workarounds, though 'teams' can stay flat".
That basically is called hierarchy by a different term. And I suspect, as most with quite a bit of experience would, that as olark grows, more layers (aka, hierarchy) would be introduced. It's natural and it's fine.
It's fine! I know it's a dirty word, but hierarchy is fine. It really is.
I contend it's NOT the problem that people want to solve, rather they want to solve a different one. It's the classic case of treating the symptoms and not the disease. I highly suspect that in most flat companies, the real thing people are after is some subset of [trust, autonomy, mission, vision, ownership, accountability, flexibility, empowerment] etc. But, instead of focusing on those, the focus shifts to the structure. If in solving for the subset it is found that structure is at fault, by all means give it a go. That is not how I've seen it done, though. Rather, people /assume/ flat is better with no mindfully explicit reasons why they would adopt it.
>"I think some civic training would be good for people working in flat organizations. They need to be un-educated."
Do you mean 'de-educated' or 're-educated'? There are plenty of uneducated people.
You asssert that flat organizations could do well, but without any examples or evidence to back you up, I am inclined to disagree. If flat organizations were better, I would expect that some out of the hundreds of thousands (if not more) companies in the developed world would use that system.
Slavery lasted over thousand years as an economic system. Feudalism lasted just as long. Your argument back then would have been "if capitalist firms were better, I would expect some. People in the feudalist world would use that system".
As a matter of fact, there are thousands or such flat firms. Just as during feudalism there were thousands of capitalist firms that would fail.
Failure is does not mean it won't work in 10, 50 or 100 years.
There will be a time when we think of managers the same way we think of kings now.
It's possible that flat organizations are the future, but it is not true that all organizations were lord-serf in feudal times or that slave labor was the only sort of labor in its time (, in fact slavery still exists). Please show some examples of flat firms, which are not the highly centralized sort described in the OP, I am interested in reading about them. As far as I have seen, all so-called flat organizations are actually very centralized for all important decisions.
I think there be trouble on both ends of the spectrum: too flat, and too hierarchical. I think there's a sweet spot in the middle: my gut-feeling is about log_10 (N) + 1 layers, where N = number of employees.
It sounds like the problem isn't flatness so much as a complete absence of mission and direction. Any team needs a mission to organise itself around solving
Flat will only kill you if you do a half-assed job of it. Functional flat organizations require motivated members. If you have a goal that everyone can agree on, and you trust those people to stay on target, you don't need structure.
The unfortunate truth is that traditional businesses will never be able to motivate their employees enough to make this work at any kind of scale. You have no reason to care that much, especially not long term.
Personally, I think workers-coops are the answer. But that remains to be seen.
77 comments
[ 5.0 ms ] story [ 157 ms ] threadRather than being whoever can kiss the most ass and not upset the boss (the usual system), a flat system ends up being a battle for leadership which puts the smart and commanding at the top. "Rock star dev who's also a jerk" is who should be the boss.
The anchor does not determine product features or direction, that's the product manager's role. The anchor doesn't hire, fire, reward or punish other engineers, that's the engineering manager's role.
The anchor isn't necessarily the strongest engineer on the project, either.
Anchors are mostly there to break ties and hold project context over a longer time frame. A founding anchor has a strong influence on the project's technical direction, but it's not a fiat power. You still need to discuss it with your peers.
And it works pretty well, because the only reason you get asked to anchor is due to the feedback of your peers.
Then again, our hiring process has a notorious bias against rockstar jerks.
Lots of people know us mostly for Pivotal Tracker, which is built to support our daily and weekly workflow.
On any given engagement, we always argue for a minimum team of one product manager, one designer, two engineers. We used to be a purely engineering shop, but (before my time) the thinking grew to include all three roles in each project. Previously anchors were also de facto product managers, which is a tricky and exhausting doubling-up of duties.
When this happens now, we call it "super-anchoring" and it's seen as a project smell. I've had to act as a super-anchor once or twice; it's how I learnt that having a separate product management role is essential to a healthy project.
I like how we work. As an engineer I trust product managers to worry about what to build next and why, I trust designers to be across the user's needs and UX flow and conceptualisation. They trust me to pick a simple, robust engineering solution without gold-plating.
Anyone can give input, of course. I've had PMs make great engineering suggestions. I've seen engineers with UX breakthroughs. Engineers in an IPM ask all sorts of fiddly questions that will typically lead to product changes.
We ultimately own our own roles and get final say on them. It works because it's built on mutual trust and respect.
So you'll get "impressive" code that leverages sexy technologies that is also late, buggy, and not what the customer actually needs. And on top of it all you'll have a demoralized drama-prone team.
A leader is someone who can get people to get shit done. Usually it means convincing them that what the leader wants done is the thing to be done. Consensus-building can be done in many different way - in particular, a very good way is to just arbitrarily announce what the consensus is. In most fields, and in pretty much 99% of business, almost decision is better than prolonged periods of not knowing what to do. And if a leader is competent in the field in question, his arbitrary decisions will usually be good.
So as long as you can align their ego with business/customer needs, a "rock star dev who's also a jerk" isn't the worst choice for a leader.
As for your challenge, just about anyone I have worked for and respected. You don't know them, so you can use a No True Scotsman defense, I guess. That won't change that ego/jerkiness is completely unnecessary.
Bad decisions are catastropic in tech. That's a driving force for things like Agile. Running off and coding or building things without a plan is a recipe for disaster.
I can make you do something by screaming at you. That works to get you up over that hill to attack the pillbox. Doesn't work so well in tech where you will just quit.
> Bad decisions are catastropic in tech.
No, they're not. What's the worst that could happen? Your SaaS cats-on-Instagram-to-save-the-world startup will flop. Or you won't deliver some product that's being delivered by 2000 identical companies around the world. Or some people won't get to see some annoying ads.
We're not talking medicine or space travel here. If we were, we'd be focusing on whether a leader is effective, not whether he's a nice person.
The downside is that their goals may not align well with the company.
pros and cons to everything, but I think it's a mistake to dismiss the idea that the person who stepped up, took the responsibility, and was able to get others to follow isn't the person who should be the leader.
But I've noticed that in IT/programming people recognize and respect each other on skill and also form "respect based hierarchy" implicitly more than usual. Not suggesting that IT/programming is utopian meritocracy or anything just that from my impressions it's much more meritocratic than other professions I've worked in/by (print, news editing, management) - so it's more likely you get positive results with such open structure.
What's more, they are complete assholes. And yet, everyone under them respects them and marches to their drumbeat. Their teams get real work done.
If someone thinks there is a better leader than that I'm not sure who the hell they're talking about.
I actually don't get where this stereotype that the best in our field are inevitably jerks comes from. If you're smart enough to rise to the top engineering-wise, you're probably also smart enough to realize that ours is a collaborative field, no one is right 100% of the time, and that you catch more flies with honey than vinegar.
The rock star dev is by definition the best dev you have, so no you'll the best code you could from your team since the best guy would be spearheading it.
No, that isn't what it means. Your actual best dev is your rock star, that's the intended meaning of the phrase.
It ends up putting the person who's the least bother in that role compared to all the other roles they could occupy in charge. People you go along with while looking for another job, because at the end of the day it's not your company and it's not worth the enormous emotional cost of fighting them.
In my experience, it's rare that the most "commanding" dev is also one of the more talented devs. If anything, my experience is the opposite: the stronger personalities are great examples of the Dunning-Kruger effect, while the best devs have more passive personalities (or just don't care enough to try to commandeer leadership of the team).
It's not like "kissing the most ass" is limited to kissing the ass of upper management. The same types that are exceptional at kissing the ass of management can also be great at playing Lord of the Flies with development teams (forming alliances, turning devs against eachother). It makes for a terrible work environment.
I much prefer strong hierarchical management, assuming management is competent enough to promote those with both development expertise and the people skills necessary for management (consensus building, mentorship, clarity of purpose, motivating people, etc).
The problem is you've described someone entirely different, here, IMO.
A smart leader isn't the loudest. Because they know when to listen to their subordinates, and don't need to be the loudest to command attention when they do speak.
They don't need to be a jerk, or rely on bullying - for this is morale destroying counterproductive pettiness, and again unnecessary when it comes to commanding attention and respect. It might not chase away all of your talent, but it will chase away some of it, who will leave for greener pastures where they're respected.
In my experience, the "Rock star dev who's also a jerk" was both the worst leader and the worst dev. They wrote a bunch of short sighted hacks - making them "productive" "rock stars" - that constantly broke things that other people had to fix. They were quick to assume their half baked ideas of how to proceed were the one true way - and that you were an idiot for thinking otherwise - and quick to dismiss any and all concerns about things they overlooked in their plans. It was bad enough that the best way to get anything done ended up being to hide it from the "rock star dev who's also a jerk". This is the antithesis of what good leadership should result in. That they were too busy doing development to do any real leadership was perhaps a blessing.
That's not to say the ideal leader can't ever be loud, or stern, or a dev. These can all be useful qualities at times. But they're not "a jerk", and may find they have less time available to spend on development in response to the burdens of leadership.
Those are not rock star devs, those are just shitty devs. The term rock star means your best devs, not your worst, by definition. If you're applying the label to shitty devs, you've missed the point of the term. A rock star is someone who's awesome, that's the entire point of the slang.
Part of the disagreement is surely semantics: if you want to define "rock star" as the best, then I guess they're the best (however you measure that).
But being a jerk is not semantics. If that works for your organization, great. But I don't want to have to deal with that.
That's not a rock-star, it's not what the term means.
As for your main point, most people don't want to deal with jerks, so what? That doesn't mean anything when it comes to whether the jerk is a good leader or not. Lots of leaders are jerks, it's rather common to people who feel "they should be in charge".
Leaders are those who take charge, and lead. Naturally they find ways to take charge of a leaderless group and while you want to say they shouldn't be the leader, they are by virtue of being the only leader there. The smart guy you think would make a better leader, generally doesn't want to be leader and will let the jerk take charge; that actually disqualifies them as good leaders because a good leader wouldn't do that.
How are we defining "your best devs" then, exactly, if "rock star who's also a jerk" isn't a contradiction?
> As for your main point, most people don't want to deal with jerks, so what? That doesn't mean anything when it comes to whether the jerk is a good leader or not.
Do you not see the inherit conflict between being "a good leader" and "driving away the talent on your team"? If your leader is toxic enough that everyone would rather quit than work with them, how are they supposed to function as a leader? There's going to be nobody left to lead!
Let's say they're not quite that toxic. Instead, they're merely driving down morale, merely making everyone want to think about anything but work, stressing them out. Will these people be bringing their A game? And doing their best work? And communicating effectively with leadership so the correct work gets done, instead of avoiding the jerk as much as possible?
Let's say they're not quite that toxic. Instead, they just forgot to bring doughnuts into work on your birthday. Are they actually a jerk?
> Naturally they find ways to take charge of a leaderless group
No such thing. There may be no official leader, or no clear singular leader, but if nothing else people will always lead themselves. Anyone displacing that leadership must provide more value than what exists for their leadership to be a net positive. That may be a fairly low bar at times, but sufficiently toxic individuals won't clear it - as they'll be removing value instead.
> The smart guy you think would make a better leader, generally doesn't want to be leader and will let the jerk take charge; that actually disqualifies them as good leaders because a good leader wouldn't do that.
Well, I'd agree it isn't good leadership. I've seen people learn from this mistake.
No one said toxic. They said jerk.
I quite like working with a bunch of opinionated assholes that are willing to argue to the bottom of something, and have no personal investment in me liking them.
The great thing about jerks is that they don't take it personally. When you see the jerk the next day, you're still at square one. You will always be at square one.
Not friends, not enemies, just coworkers doing your job -- willing to step on each others toes to get things done the right way.
I've worked at places where everyone is nice. It's hell. "Nice" people are bad: morally, ethically, and for the bottom line.
Being a jerk is toxic. Being an asshole is toxic. If they're not toxic, why are you calling them these things?
> I quite like working with a bunch of opinionated assholes that are willing to argue to the bottom of something, and have no personal investment in me liking them.
I like working with opinionated people that are willing to argue to the bottom of something. So much so that I ended up following the most argumentative person from my previous job to my current one.
None of that required them to be an asshole. We have a boardgames night every couple of weeks now.
> The great thing about jerks is that they don't take it personally.
Jerks tend to make it personal. That's one of the main reasons they tend to be jerks!
> Not friends, not enemies, just coworkers doing your job
I'm entirely fine with professional relationships. Professional doesn't imply jerk.
> willing to step on each others toes to get things done the right way.
Sure. But a professional can do this without finding their cleats and stomping as hard as they can.
> I've worked at places where everyone is nice. It's hell. "Nice" people are bad: morally, ethically, and for the bottom line.
Your inconsistent air quotes betray the problem here, I think.
People who are bad morally and ethically are not nice people. They are jerks. They are assholes. That some of them are grinfucking everyone to appear nice doesn't make them nice.
And, conversely, the fact that some people aren't grinfucking you doesn't make them jerks. That they're willing to debate something honestly with you doesn't make them an asshole. That they're trying to do things right - and save your team from future stress, crunch, or whatever other consequences would come from doing things wrong - sounds like they're trying to do everyone a favor. If anything, they sound nice.
-------
EDIT: Ultimately, I wonder how much of this thread is you saying...
Rock star "jerks"
And me hearing...
"Rock star" jerks
You don't seem to realize you're talking to more than one person.
Your edit is correct.
Consensus is obviously preferable. But it scales very poorly. A simple workaround is to nominate someone as the tie-breaker. To avoid secondary rounds of nonsense, you try to pick someone with the respect of their peers.
Holocracy actually doesn't use consensus. The mechanism in Holocracy for decision making can be summarized as "do whatever you think is right to fulfill your stated role. No consensus nessesary. If the way your doing thing is actively preventing someone from fulfilling their role, then you two work it out (through a strict mediation process) but other people's opinion of what you should do is irrelevant (i.e. No consensous). Only the roles directly effected have to agree." Consensous seeking usually descends in to hypotheticals, theory, and butt covering. far better, according to Holocracy to just let people animate their assigned roles however they think is best.
If reward and punishment are tied to individual judgement, everything descends into hypotheticals, theory, and butt covering.
Consensus is nice because it's a relative of shared understanding. When it can't be achieved, trying to achieve it still increases shared understanding. Having a tie-breaker is the only role you need in small groups.
(My guess is: it would not).
I know a number of people who have quit Valve and almost all of them would cite organizational dysfunction as one of the top reasons for quitting.
I don't know whether that is true -- I have never worked there -- and I don't wish to spread any ill rumors about Valve. I'm just saying that I know a bunch of people who have worked there who think the flat thing is one of Valve's biggest problems (another one being the incentive structure; of course these two things go hand in hand).
Their customer support/sales people are apparently much more traditional
Relevant: http://www.jofreeman.com/joreen/tyranny.htm
https://news.ycombinator.com/item?id=8270601
https://news.ycombinator.com/item?id=9513604
https://news.ycombinator.com/item?id=9367390
- People tend to hate managers, they don't trust them.
- Flat team are faster removing the management complexity.
- There's more flexibility and more creativity around the problem tackled by the team.
The last reason is reasonable but is true applied for small unit inside the bigger organization, not the whole organization, as this article explains well. Nothing prevent to create a small unit with a specific task inside a bigger organization and to organize this unit (usually made by "star" employee) in a flat structure.
The second reason is disputable, it doesn't scale has the article suggest.
But the first reason is not addressed. And it is the real issue. I think everyone had terrible bosses and great bosses. We usually remember terrible managers as an example of the average managers (Mental association: Dilbert's Pointy Hair Boss) while we consider the great bosses we had as mentors, role models, guide. And we forget that they were also our manager. It is a form of selection bias.
There's also another issue at play, changing organizational structure, trying Flat or Holocracy is easy (I'm not saying that it's easy to do it right, it's easy to give it a try). Promoting the right person, with the right skills is difficult. And if you promote the wrong person (it happens) removing from a managerial position or moving him to a position that is a better fit is extremely difficult. So we all decide to do what is easy instead of what is difficult. Not sure I could blame someone, it is the people mindset, but doesn't mean that what is easy is also correct while what is difficult, when done right, proved to be correct.
Really? Raising the minimum wage was about "differentiating" themselves, and not out of the realization that everyone needs a comfortable wage to live on?
I'm sorry, but I can't take an analysis by such a person seriously. This attitude demonstrates a fundamental lack of understanding.
(disclosure: i used to work for olark, and their system works quite well)
That basically is called hierarchy by a different term. And I suspect, as most with quite a bit of experience would, that as olark grows, more layers (aka, hierarchy) would be introduced. It's natural and it's fine.
It's fine! I know it's a dirty word, but hierarchy is fine. It really is.
I contend it's NOT the problem that people want to solve, rather they want to solve a different one. It's the classic case of treating the symptoms and not the disease. I highly suspect that in most flat companies, the real thing people are after is some subset of [trust, autonomy, mission, vision, ownership, accountability, flexibility, empowerment] etc. But, instead of focusing on those, the focus shifts to the structure. If in solving for the subset it is found that structure is at fault, by all means give it a go. That is not how I've seen it done, though. Rather, people /assume/ flat is better with no mindfully explicit reasons why they would adopt it.
Is it any wonder people don't know how to work together independently of authority figures?
I think some civic training would be good for people working in flat organizations. They need to be un-educated.
Do you mean 'de-educated' or 're-educated'? There are plenty of uneducated people.
You asssert that flat organizations could do well, but without any examples or evidence to back you up, I am inclined to disagree. If flat organizations were better, I would expect that some out of the hundreds of thousands (if not more) companies in the developed world would use that system.
As a matter of fact, there are thousands or such flat firms. Just as during feudalism there were thousands of capitalist firms that would fail.
Failure is does not mean it won't work in 10, 50 or 100 years.
There will be a time when we think of managers the same way we think of kings now.
Flat is usually called "Socialist" in the rest of the world.
The setting is radical feminism rather than tech management, but the drivers are the same and so are the results.
The unfortunate truth is that traditional businesses will never be able to motivate their employees enough to make this work at any kind of scale. You have no reason to care that much, especially not long term.
Personally, I think workers-coops are the answer. But that remains to be seen.