Why GitHub Finally Abandoned Its Bossless Workplace(bloomberg.com)
bloomberg.com
Why GitHub Finally Abandoned Its Bossless Workplace
http://www.bloomberg.com/news/articles/2016-09-06/why-github-finally-abandoned-its-bossless-workplace
248 comments
I work at a product company that works in a very flat way. We accomplish our goals by having a product owner who doesn't actually have any direct authority over the technical team. The technical team is managed by a member embedded within who handles HR-style questions and otherwise works like a peer.
Technical decisions are made by majority vote.
The team handles uninteresting work like documentation, bug fixing, broken builds, and training with full-time promiscuous pair-programming.
This means that attitude and maturity are our most important attributes, as technical skill quickly will be taught while doing regular work. Several times in my career we've had to say to someone, "perhaps this isn't a good fit for you, why don't you start looking..." because they hate the exposure and boring work required to build a massive Enterprise system.
We almost always fix bugs and broken builds immediately, followed by product work. We spend 25% of our time fixing technical debt (this is typically the least fun work!).
Through all this we are able to ship release after release on time, adding in new features and regulatory standards with ease. It's given me hope it _can_ be done, but also that the circumstances to maintain it are almost impossible to force. It requires all the right people in all the right places to change a typical hierarchy into something like this.
Technical decisions are made by majority vote.
The team handles uninteresting work like documentation, bug fixing, broken builds, and training with full-time promiscuous pair-programming.
This means that attitude and maturity are our most important attributes, as technical skill quickly will be taught while doing regular work. Several times in my career we've had to say to someone, "perhaps this isn't a good fit for you, why don't you start looking..." because they hate the exposure and boring work required to build a massive Enterprise system.
We almost always fix bugs and broken builds immediately, followed by product work. We spend 25% of our time fixing technical debt (this is typically the least fun work!).
Through all this we are able to ship release after release on time, adding in new features and regulatory standards with ease. It's given me hope it _can_ be done, but also that the circumstances to maintain it are almost impossible to force. It requires all the right people in all the right places to change a typical hierarchy into something like this.
That's very interesting way of running a company. Is everyone in the company a partner, including the secretary, researchers, interns etc? How are these folks "managed"?
By the way, I am not asking from cynical perspective. I run a project team, and I am working through on how much autonomy to give the team members.
By the way, I am not asking from cynical perspective. I run a project team, and I am working through on how much autonomy to give the team members.
Isn't every one of those partner lawyers a boss to one or more paralegals? And usually there are a bunch of new grad lawyers around trying to make partner, I'm sure they don't consider themselves equal.
Law firms are very different in how they generate revenue and operate than every other company. There is no basis for comparison.
This.
I previously worked for a company that does purely outsourcing work; they nowadays have a bossless hierarchy (apart from project leads, who are named anew for every project, and basically anyone willing can volunteer). It seems to work well for them, and I don't see why not.
Now I'm in a "product company", and the needs are completely different. Like has been stated elsewhere in this thread, when making products, there just has to be someone making the final decisions, i.e. being the product owner.
I previously worked for a company that does purely outsourcing work; they nowadays have a bossless hierarchy (apart from project leads, who are named anew for every project, and basically anyone willing can volunteer). It seems to work well for them, and I don't see why not.
Now I'm in a "product company", and the needs are completely different. Like has been stated elsewhere in this thread, when making products, there just has to be someone making the final decisions, i.e. being the product owner.
The more I talk to lawyers the more I like the way they operate. Is there really no way to steal a lot of that structure for our field?
Sure if you are an application developer (like an integrator, BI, ERP, etc). Make cooperatives. But they won't be flat. You still have a boss - your partner. Every partner is like a mini company and they share resources and partners vote on future direction. It's not that rare actually. The ad agency conglomerates operate similarly. So do management consulting firms which are increasingly getting into tech consulting. Don't know how Accenture operates, but I would think it would be very similar. Ditto for Capgemini, Infosys, Cognizant, the list goes on.
Probably similar to a software consulting firm, but yeah different than a software product/service company.
I wonder if this is in response to out-of-control GitHub employees enforcing arbitrary "Codes of Conduct" on their users, including flagging repositories for using language that's not inclusive enough, or might offend someone?
Seems like without management, an employee with an agenda--especially on that's not related to technology--could go off unchecked for a long time.
Seems like without management, an employee with an agenda--especially on that's not related to technology--could go off unchecked for a long time.
No, it's almost the opposite. This kind of thing started happening for the same core reason they added management: because of the Tom Preston-Werner / Julie Ann Horvath scandal two years ago.
It made them understand the importance (and risk for the business) of such issues, so added HR and middle-management with a focus on them. As a side effect we ended up with things like this happening.
The people with an agenda are not random employees in a flat company here, it's the management.
It made them understand the importance (and risk for the business) of such issues, so added HR and middle-management with a focus on them. As a side effect we ended up with things like this happening.
The people with an agenda are not random employees in a flat company here, it's the management.
Seems unlikely that an organization of GitHub's size would overhaul the entire management structure to deal with problems brought about by a single employee (or even a few).
Can you elaborate?
I think this might be a reference to the "WebM for Retards" repo which was banned. After that event, someone ran a search and found myriad other repos containing "problematic" language which were ignored.
Not just that repo -- see https://news.ycombinator.com/item?id=12232250
I'm honestly so jaded by the injection of language policing into everything that all I can do is sigh nowadays.
I once worked for a company with a very flat organizational structure. It was just the CEO and thirty people underneath him.
Every day I had 10 people coming to me with issues they all thought were critically important. I was being pulled in every direction and I couldn't focus on anything. It was a complete mess.
Now I work at a company where I have one boss, and he acts as a funnel for all the work that comes into our department.
I'm never going back to a flat company again, if I can help it.
Every day I had 10 people coming to me with issues they all thought were critically important. I was being pulled in every direction and I couldn't focus on anything. It was a complete mess.
Now I work at a company where I have one boss, and he acts as a funnel for all the work that comes into our department.
I'm never going back to a flat company again, if I can help it.
Not to say it's an unimportant difference, but the only difference is that your boss knows how to say "no" to immediate requests for you time and you don't.
Flat management structure is not the problem, is it? Someone always has more of a say in what gets done for whatever reason- seniority, skill, charisma, anything.
What should really be flat is the pay scheme: pay every worker 1/n of the company's assets at the end of each financial period.
That means anyone who wants more money must work to make the company prosper as a whole. Employees should also have the chance to decide who gets hired (because they have a motivation to hire only the people they think can increase their own pay).
Btw, I'm totally willing to try this in my own company one day. And if it doesn't work- who the hell cares. Most companies fail for much more common reasons than their management or pay structure anyway.
What should really be flat is the pay scheme: pay every worker 1/n of the company's assets at the end of each financial period.
That means anyone who wants more money must work to make the company prosper as a whole. Employees should also have the chance to decide who gets hired (because they have a motivation to hire only the people they think can increase their own pay).
Btw, I'm totally willing to try this in my own company one day. And if it doesn't work- who the hell cares. Most companies fail for much more common reasons than their management or pay structure anyway.
Are they still using the Code of Conduct that explicitly allows "reverse-racism, reverse-sexism" etc. for members of marginalized groups?
Gitlab is cool but with things like webrtc, ethereum/swarm/ndn, gittorrent etc. out there eventually we will be able to get away from servers and definitely having one company in charge of storing all of the code is not the most ideal final solution.
The link to Medium's experiment is interesting too.
https://blog.medium.com/management-and-organization-at-mediu...
https://blog.medium.com/management-and-organization-at-mediu...
The genius of github is git. Did a manager help Mr Torvalds construct that?
If GitHub was only git, we'd be talking about Gitorious (or Gitweb, or...) having hundreds of employees, not GitHub.
I've heard people describe GitHub as the "Facebook of Open Source" and that's not as absurd a statement as it may seem at face value.
GitHub is basically the SourceForge of Web 2.0. It's where you go for open source projects and it makes it easy to participate.
I would hope to see GitLab succeed GitHub by virtue of being open source at heart (rather than just at the surface level) but as much as I love GitLab I'm not holding my breath.
Either way, git is ultimately an implementation detail to GitHub's success. Git's success may have given GitHub the edge over BitBucket (back when BitBucket was hg-only and GitHub was git-only) but it feels like the inverse is also true.
I've heard people describe GitHub as the "Facebook of Open Source" and that's not as absurd a statement as it may seem at face value.
GitHub is basically the SourceForge of Web 2.0. It's where you go for open source projects and it makes it easy to participate.
I would hope to see GitLab succeed GitHub by virtue of being open source at heart (rather than just at the surface level) but as much as I love GitLab I'm not holding my breath.
Either way, git is ultimately an implementation detail to GitHub's success. Git's success may have given GitHub the edge over BitBucket (back when BitBucket was hg-only and GitHub was git-only) but it feels like the inverse is also true.
Next step: TPS reports.
I've worked at a place that had a 'flat' organization, it was a mess. Hidden power structures, informal and outside of office 'meetings' where decisions were made and arbitrary decisions made at a whim.
When looking for a job, be careful when leadership says their organization is flat. You will probably find people at the top (C level) who hate being told what to do and hate management. That will poison the structure and coordination of the company. People need some sort of structure so they know where to turn to for help, responsibilities are assigned and there is accountability.
I'm not advocating having rigid, strong management and structure at a company, just that if you don't have an official structure, an unofficial and hidden power structure will emerge. And that is far, far worse.
When looking for a job, be careful when leadership says their organization is flat. You will probably find people at the top (C level) who hate being told what to do and hate management. That will poison the structure and coordination of the company. People need some sort of structure so they know where to turn to for help, responsibilities are assigned and there is accountability.
I'm not advocating having rigid, strong management and structure at a company, just that if you don't have an official structure, an unofficial and hidden power structure will emerge. And that is far, far worse.
> I've worked at a place that had a 'flat' organization, it was a mess. Hidden power structures, informal and outside of office 'meetings' where decisions were made and arbitrary decisions made at a whim.
OTOH, every place I've seen, corporate and government, with a visible and formal hierarchy has also been a mess featuring hidden power structures, informal and outside of office meetings where decisions were made, and arbitrary decisions made at a whim.
(One big feature of California's "public meeting" laws is to try to limit and expose this in the highest levels of certain representative government decision-making bodies, but its pretty much a universal feature of human societies.)
> if you don't have an official structure, an unofficial and hidden power structure will emerge.
That will also happen, pretty invariably, if you have an official structure.
OTOH, every place I've seen, corporate and government, with a visible and formal hierarchy has also been a mess featuring hidden power structures, informal and outside of office meetings where decisions were made, and arbitrary decisions made at a whim.
(One big feature of California's "public meeting" laws is to try to limit and expose this in the highest levels of certain representative government decision-making bodies, but its pretty much a universal feature of human societies.)
> if you don't have an official structure, an unofficial and hidden power structure will emerge.
That will also happen, pretty invariably, if you have an official structure.
Sure, but if you're not part of the informal power structure, having some influence through an official structure is better than having no influence at all.
In my (somewhat limited) experience, you need a balance to get good work done: too much official structure slows things down and limits good people, but too much informal structure leads to the kind of place described in "The Tyranny of Structurelessness."
In my (somewhat limited) experience, you need a balance to get good work done: too much official structure slows things down and limits good people, but too much informal structure leads to the kind of place described in "The Tyranny of Structurelessness."
It seems like what people forget is that whether you have structure or not, it takes effort to make it work well. You can't just throw someone a job title in leadership and assume they'll do a good job.
Leadership by example, training, adhering to values all matter. It just so happens that use a tried and true system of actual structure gives you a wealth of knowledge and experience to pull from.
Could a flat org work? Maybe? So far, it seems like every company that tries and gets to scale has serious problems. Maybe it makes sense stick to innovating on your core business, and sticking to business best practices in your processes. (A recent post by the former Cofounder/CEO of Brightroll digs into this: https://medium.com/@todsacerdoti/0-to-640m-non-obvious-lesso...)
Leadership by example, training, adhering to values all matter. It just so happens that use a tried and true system of actual structure gives you a wealth of knowledge and experience to pull from.
Could a flat org work? Maybe? So far, it seems like every company that tries and gets to scale has serious problems. Maybe it makes sense stick to innovating on your core business, and sticking to business best practices in your processes. (A recent post by the former Cofounder/CEO of Brightroll digs into this: https://medium.com/@todsacerdoti/0-to-640m-non-obvious-lesso...)
Has there been any attempt to make a periodically oscilatting structure? One that has a structure and then gives it up and regrows one, and so on..
Sortition is one mechanism that's been used. Among the most fascinating articles I've read in the past 4-5 years was Aeon's article on randomness as a choice option (going beyond just leadership):
Michael Schulson, "How to Choose" https://aeon.co/essays/if-you-can-t-choose-wisely-choose-ran...
Michael Schulson, "How to Choose" https://aeon.co/essays/if-you-can-t-choose-wisely-choose-ran...
I find the idea of a democratic structure oddly appealing. Don't like your boss? Vote them out! Love someone and wish they'd be in charge, because they're basically in charge anyway? Vote them in! If anonymous voting happened at every level, it's possible that the incompetent people hiding away in the company will quickly get revealed and demoted (which might make them leave altogether).
That said, the democratic approach has a lot of other issues in the form of cohorts and cliques. A manager might secure just enough votes to stay in power by having quiet conversations with some employees, using power to give them breaks, etc. I'd love to see a frank discussion or proposal about how to dissuade that.
That said, the democratic approach has a lot of other issues in the form of cohorts and cliques. A manager might secure just enough votes to stay in power by having quiet conversations with some employees, using power to give them breaks, etc. I'd love to see a frank discussion or proposal about how to dissuade that.
Ever lived in a condo with an HOA (Home Owner's Association)? You get the opposite problem. One person, household, or small set of owners wants to be in power so they can make changes that benefit them, and everyone else wants nothing to do with the HOA so they can't be blamed when something goes wrong and because they're too busy with their lives. So a vote is held, most people don't show up, and even if they do, they don't want to do the jobs themselves so they vote for the people who want it, and the result is usually terrible.
This. And really, it's the same problem in elected government too. Often times the people who desire power the most are the last ones that should have it. People who might actually make great leaders (or at least would not be tyrants) often don't want to get involved with politics.
In the work setting I've never seen management determined by vote, but you see the phenomenon just the same. Most people who want to climb the management ladder are normal, sane people, but the power-hungry are the ones who try the hardest to get to the top. In an organization that doesn't properly evaluate people you end up with the brutes in charge, which makes life miserable for everyone else.
In the work setting I've never seen management determined by vote, but you see the phenomenon just the same. Most people who want to climb the management ladder are normal, sane people, but the power-hungry are the ones who try the hardest to get to the top. In an organization that doesn't properly evaluate people you end up with the brutes in charge, which makes life miserable for everyone else.
> Often times the people who desire power the most are the last ones that should have it.
The funny thing is that the first democracy which called itself a democracy was perfectly aware of this problem - and the tyranny of informal leaders - and had a simple and effective solution to both problems: filling chairs by lottery.
The funny thing is that the first democracy which called itself a democracy was perfectly aware of this problem - and the tyranny of informal leaders - and had a simple and effective solution to both problems: filling chairs by lottery.
http://www.jofreeman.com/joreen/tyranny.htm
The full article. Her point seems to really boil down to this:
I really recommend reading the whole thing. It's a pretty interesting article and, I think, gets at the problems (solvable in some or many cases) in any large organization, structureless or not.
EDIT: And do read the article. It's much more than just the snippet I included. That's just her thesis, the rest explains it better and the consequences of insisting on informal organization.
The full article. Her point seems to really boil down to this:
We cannot decide whether to have a structured or
structureless group, only whether or not to have a
formally structured one. Therefore the word will not be
used any longer except to refer to the idea it
represents. Unstructured will refer to those groups
which have not been deliberately structured in a
particular manner. Structured will refer to those which
have. A Structured group always has formal structure,
and may also have an informal, or covert, structure. It
is this informal structure, particularly in
Unstructured groups, which forms the basis for elites.
I really recommend reading the whole thing. It's a pretty interesting article and, I think, gets at the problems (solvable in some or many cases) in any large organization, structureless or not.
EDIT: And do read the article. It's much more than just the snippet I included. That's just her thesis, the rest explains it better and the consequences of insisting on informal organization.
I think you missed the point of the Wikipedia article. Structurelessness (and that is still what you're describing) leads to a tyranny where there are unspoken leaders who basically bully the rest of the organization. You described exactly that and then asked how to avoid it. Short answer: You probably can't. It's a human problem, not an organizational or process one.
Clear lines of ownership and responsibility do wonders for just letting coders code, and let everyone else decide what they code.
Clear lines of ownership and responsibility do wonders for just letting coders code, and let everyone else decide what they code.
Exactly, it's "leaderless" in the same sense that a class of high schoolers is "leaderless."
No, I got that. The article also has the person who demonstrated it advocating for democratic control of leadership, and I was commenting on how that might run into its own troubles.
The problem is that the skills required to win votes generally don't have a lot to do with the skills required to be competent in any field other than electioneering. So elections don't end up quickly revealing and demoting the incompetent people so much as they do raising up people who are competent at electioneering, regardless of their competence or lack thereof in other matters.
An example from history. Elections are actually how volunteer units in the early days of the American Civil War selected their officers. Every soldier got one vote, the whole regiment got together and cast their ballots, and the guy who got the most votes got to be the commanding officer. Very democratic!
With just one problem: in almost all cases, soldiers voted overwhelmingly for officers who promised not to make them do all the tedious army stuff they hated, like drilling in formation and practicing their marksmanship... which it turns out are actually very important things for a unit to do, if it wants to actually perform in combat. So these units had a bad habit of dissolving into mobs of terrified amateurs (and therefore getting slaughtered) the moment they entered battle.
Eventually it was decided that it was more important that army units be able to function in combat than that they be democratic organizations, and the elected "soldier's friend" officers were kicked out and replaced with hardasses. The soldiers hated them, and swore under their breath every time they were called out to drill yet again. But they learned how to fight.
An example from history. Elections are actually how volunteer units in the early days of the American Civil War selected their officers. Every soldier got one vote, the whole regiment got together and cast their ballots, and the guy who got the most votes got to be the commanding officer. Very democratic!
With just one problem: in almost all cases, soldiers voted overwhelmingly for officers who promised not to make them do all the tedious army stuff they hated, like drilling in formation and practicing their marksmanship... which it turns out are actually very important things for a unit to do, if it wants to actually perform in combat. So these units had a bad habit of dissolving into mobs of terrified amateurs (and therefore getting slaughtered) the moment they entered battle.
Eventually it was decided that it was more important that army units be able to function in combat than that they be democratic organizations, and the elected "soldier's friend" officers were kicked out and replaced with hardasses. The soldiers hated them, and swore under their breath every time they were called out to drill yet again. But they learned how to fight.
That's incredibly interesting - do you have a source for it?
There's some good pointers to the election processes of a few different regiments (North and South) here: http://civilwartalk.com/threads/question-about-election-of-o...
[deleted]
I don't want my job to include voting people off the island and MORE office politics and meetings. Please no.
Too late. As soon as you have more than three human beings in the same group, there's politics and meetings. You can either participate, or allow others to dictate to you.
I know. I said I don't want -more- of that.
Every single member of the team having to keep up with every single other person is unnecessary and impossible past a certain number of people. Certain things don't scale well.
Every single member of the team having to keep up with every single other person is unnecessary and impossible past a certain number of people. Certain things don't scale well.
Plato's dictum.
The only thing that works against cliques in democracy as you described is to have sufficient number of people at each level. The large parliaments are there specifically to block too strong unilateral cliques forming. A democracy full of tiny squabbles is a working democracy - a democracy in unilateral ageeement on all matters really is not a democracy anymore.
The biggest problem is that the business owners want management to represent their interests; if they were elected by the workers, they would more naturally represent the interests of the workers. It might work out in a worker's co-op where the workers and owners are the same people.
I'm trying to understand how a "flat org" like this is different from a co-op. Seems like the "flatland" companies give you autonomy without ownership, which seems bad to me. It's only flat so far as the actual owner allows it to be, and you end up with a bunch of people with autonomy with no stake in the outcomes.
Co-ops still have boards and often employees that report to the board (or another employee). There's a structure there, but they also tend to be smaller so the structure has less impact.
I was treasurer of my housing co-op and we had one full-time employee who reported to me and the board. That employee (the coordinator) hired contractors for maintenance, bookkeeping, as well as things like the laundry machines.
Even large co-ops (like clothing stores) have the members vote a board in that sets up the structure.
I was treasurer of my housing co-op and we had one full-time employee who reported to me and the board. That employee (the coordinator) hired contractors for maintenance, bookkeeping, as well as things like the laundry machines.
Even large co-ops (like clothing stores) have the members vote a board in that sets up the structure.
Isn't that what reviews are for? If you have substantive reasons not to like your boss then giving them a lousy review is easy.
A manager who is getting lousy reviews from engineers is going to face difficulties with the higher ups.
A manager who is getting lousy reviews from engineers is going to face difficulties with the higher ups.
A little fascism goes along way.
The opposite of anarchy isn't fascism. Read the author's full paper, it's got a lot of insight into the workings of organizations in general.
Are you talking about the wikipedia article or http://www.jofreeman.com/joreen/tyranny.htm
I have been in those same activist groups. Right now I work for an "engineering run" organization. Maybe my emphasis should have been on _a little_.
Every organization collapses towards high-school. Those that don't are the most successful. Just as the majority of Olympic athletes are freak'n amazing, the contest is rarely not who excels but who doesn't falter.
I have been in those same activist groups. Right now I work for an "engineering run" organization. Maybe my emphasis should have been on _a little_.
Every organization collapses towards high-school. Those that don't are the most successful. Just as the majority of Olympic athletes are freak'n amazing, the contest is rarely not who excels but who doesn't falter.
It'd be cool to see an internal study, at least within the engineering group, of how commit activity/issue resolution changed before and after the new structure. On an aggregate basis, at least.
Could you elaborate on why you think that would be useful?
Ostensibly the decision to change structure is to improve productivity. Does it? And if so, how does it affect/improve it? Commit activity is as granular/quantifiable a data source as we have to analyze it.
Obviously, the analysis shouldn't be limited to the mere quantity of commits. I'm more interested in if the activity becomes more "regular" than sporadic. Or if long-neglected (i.e. boring) issues get more attention than they did before.
Obviously, the analysis shouldn't be limited to the mere quantity of commits. I'm more interested in if the activity becomes more "regular" than sporadic. Or if long-neglected (i.e. boring) issues get more attention than they did before.
It would be interesting, but not immediately scientific when it comes to measuring productivity. A larger structure is going to be less efficient than a small one (under most topologies) but can take on larger tasks. The individuals will have more specialization and decisions will take longer to arrive at.
What I would find interesting is a what is the slope of the line in terms of worker productivity as it varies with org size as the number of workers are added.
Having a bossless architecture is fine when there is lots of interesting engineering work to do. Coordination and direction is just overhead when the organism should just spread in every direction. But after some point it needs to move and find food.
What I would find interesting is a what is the slope of the line in terms of worker productivity as it varies with org size as the number of workers are added.
Having a bossless architecture is fine when there is lots of interesting engineering work to do. Coordination and direction is just overhead when the organism should just spread in every direction. But after some point it needs to move and find food.
" A larger structure is going to be less efficient than a small one (under most topologies) but can take on larger tasks. The individuals will have more specialization and decisions will take longer to arrive at."
This is the best brief simplification of organizational dynamics on scaling I've had the pleasure to read.
This is the best brief simplification of organizational dynamics on scaling I've had the pleasure to read.
I presume as a raw (if somewhat flawed) measure of productivity.
I don't know if I misread it, but I found this article almost entirely devoid of information about this transition. This is the only trace I could find:
> Wanstrath told staff of the switch to bosses the month after his co-founder’s departure, and the software engineering department began assigning managers in the spring.
It doesn't explain how their new management structure works, or how they picked the managers, or what. Half the article is about the Github gender bias controversy, and the other half is about other companies with flat organizations.
Does anyone have any real insight about how Github's new management structure works?
> Wanstrath told staff of the switch to bosses the month after his co-founder’s departure, and the software engineering department began assigning managers in the spring.
It doesn't explain how their new management structure works, or how they picked the managers, or what. Half the article is about the Github gender bias controversy, and the other half is about other companies with flat organizations.
Does anyone have any real insight about how Github's new management structure works?
Yeah I agree with you I didn't find much of anything useful beyond this one other bit that added another, small explanation for moving away from bossless:
> While the old times created a strong sense of camaraderie, employees didn’t know who to direct questions to, either about uncomfortable confrontations with colleagues or about their own performance. “Without even a minimal layer of management, it was difficult to have some of those conversations and to get people feeling like they understood what was expected of them, and that they were getting the support that they needed in order to do the best work,”
No information about what the current structure is, how it's working out compared to the last one nor really any satisfying answers for why the initial bossless failed (I mean I can certainly guess but they went through it, it would be nice to have more data).
> While the old times created a strong sense of camaraderie, employees didn’t know who to direct questions to, either about uncomfortable confrontations with colleagues or about their own performance. “Without even a minimal layer of management, it was difficult to have some of those conversations and to get people feeling like they understood what was expected of them, and that they were getting the support that they needed in order to do the best work,”
No information about what the current structure is, how it's working out compared to the last one nor really any satisfying answers for why the initial bossless failed (I mean I can certainly guess but they went through it, it would be nice to have more data).
My guess?
The company's at an inflection point and management has to choose between a) raising capital or b) exiting. Either way, investors had expressed concern about GitHub's (lack of) hierarchy, and the constraints it imposed on opportunities.
The company's at an inflection point and management has to choose between a) raising capital or b) exiting. Either way, investors had expressed concern about GitHub's (lack of) hierarchy, and the constraints it imposed on opportunities.
This.
Don't read this as a management howto but a "hey look, we're legitimate now!" PR-focused post. They're trying to acknowledge the previous risks and describe how they are now addressed.
We're not the audience for this one, folks. Institutional investors are.
Don't read this as a management howto but a "hey look, we're legitimate now!" PR-focused post. They're trying to acknowledge the previous risks and describe how they are now addressed.
We're not the audience for this one, folks. Institutional investors are.
So, translation is actually:
One could quickly argue that PR articles that skip the details, and make designs to produce the sensation of graphs that "go up and to the right," are a clear indicator that pleasing investors produces a bland gruel of profiteering corporations as ineffective at doing anything useful besides "making money," as is flatlander management, at providing direction to employees (read: millennials) who can't adjust to the sensation of not being subordinate to micro-managing overlords.
blorp blorp!
money money!
blorp blorp!
feed me, seymour!
One could quickly argue that PR articles that skip the details, and make designs to produce the sensation of graphs that "go up and to the right," are a clear indicator that pleasing investors produces a bland gruel of profiteering corporations as ineffective at doing anything useful besides "making money," as is flatlander management, at providing direction to employees (read: millennials) who can't adjust to the sensation of not being subordinate to micro-managing overlords.
I came here to say the same thing, since flat structure companies have always fascinated me and I generally still feel like it would be a good experience to work for one, I wanted to know what exactly led them to this decision. Instead only two things were listed as potential reasons: the gender issue and that employees didn't have a person to talk to about their performance or conflicts. The title is very misleading as I'm sure these couldn't be the only drivers. That's a huge cultural shift.
I don't know what led GitHub to this shift. At GitLab we want to maintain as flat of a structure as possible but we always wanted everyone to have exactly one boss and 4-10 reports per boss. For us the reasons are that:
1. You want someone to evaluate your and your team's performance. Not getting feedback on this is demotivating.
2. You want someone to help you get better and plan your career (all of our managers are skilled in the area of work of their reports).
3. You want someone to go to with problems: individual execution, team execution, collaboration with another team, and (inter)personal ones).
For more information about our reporting structure see https://about.gitlab.com/team/structure/ and our leadership principles see https://about.gitlab.com/handbook/leadership/
1. You want someone to evaluate your and your team's performance. Not getting feedback on this is demotivating.
2. You want someone to help you get better and plan your career (all of our managers are skilled in the area of work of their reports).
3. You want someone to go to with problems: individual execution, team execution, collaboration with another team, and (inter)personal ones).
For more information about our reporting structure see https://about.gitlab.com/team/structure/ and our leadership principles see https://about.gitlab.com/handbook/leadership/
I'm curious if there's a way to accomplish those things without a single designated boss. For example, having coders taking turns every week or two being the person people go to for typical boss purposes. Of course some people just aren't good leaders or have no desire to be, so maybe some people can have a promoted status they get over time, allowing them to be in the "pool" of managers chosen on a biweekly basis.
There can be many factors to play around with. After everyone on a team has had the chance to be manager couple times, the team could vote for who should be the manager for the next month. Etc, etc. The idea is to still give a team the sense of control, rather than feeling that you're imposing a boss on them.
There can be many factors to play around with. After everyone on a team has had the chance to be manager couple times, the team could vote for who should be the manager for the next month. Etc, etc. The idea is to still give a team the sense of control, rather than feeling that you're imposing a boss on them.
Rotating the boss would expose people to more advice. Like switching dance partners during a dance lesson the rate of learning would increase.
However, I think a boss is more like a person you go teach a dance workshop with that a person that participates in it. Maybe the intern can have a new mentor every week. But I see some obstacles doing this do experienced team members.
It is already hard to find people that are both an expert at the work and a great boss. Finding multiple bosses in a team seems hard.
Frequently your boss needs a long term view on your activities. Career planning, performance reviews, and performance improvement plans are multi-month affairs.
Coordinating with other bosses and team also happens via social capital. Having to deal with a new persons for all other teams every month might be hard.
However, I think a boss is more like a person you go teach a dance workshop with that a person that participates in it. Maybe the intern can have a new mentor every week. But I see some obstacles doing this do experienced team members.
It is already hard to find people that are both an expert at the work and a great boss. Finding multiple bosses in a team seems hard.
Frequently your boss needs a long term view on your activities. Career planning, performance reviews, and performance improvement plans are multi-month affairs.
Coordinating with other bosses and team also happens via social capital. Having to deal with a new persons for all other teams every month might be hard.
I know about a dev team that does Holcracy: https://github.com/lab-coop/lab-governance
I can't offer that insight so instead, my analysis of what actually happened at github. May enlighten to why this article exists at all, and is so thin.
http://hintjens.com/blog:111
http://hintjens.com/blog:111
[deleted]
welcome to the brilliant world of Tech Industry journalism, where 2 year old Twitter controversies are what pass for investigation and background.
Can GitHub--a company with 600 people--really be called a "startup" anymore (as termed by the article)?
There's some cred that's given to any company that's a "startup". Which is why successful startups do their best to extend the use of that term-- claiming that their culture stays the same. The same way that job titles are being inflated, I think there's "startup inflation".
In one of my college business classes we tried to define a startup, and we ended up with something like: > A startup is a company that is new company, less than 5 years old, that is also looking for a big payout by trying a risky and novel product or business strategy. A startup is also looking for extremely high growth, which is usually funded by outside investment.
So, github? No longer a startup. A year after you've become successful and paid off the VCs? No longer a startup. If you're a design/development agency? Not ever a startup, because the product/services you're providing are not novel or new territory. If someone made a competitor to Jira, I might also hesitate to call it a startup. At some point these kind of services get commoditized.
Of course, colloquially this definition fails and I don't ever try to push this definition on people. But it helps to conceptually divide the "high-growth new product startups" from the "lifestyle startup" and "traditional business startups".
In one of my college business classes we tried to define a startup, and we ended up with something like: > A startup is a company that is new company, less than 5 years old, that is also looking for a big payout by trying a risky and novel product or business strategy. A startup is also looking for extremely high growth, which is usually funded by outside investment.
So, github? No longer a startup. A year after you've become successful and paid off the VCs? No longer a startup. If you're a design/development agency? Not ever a startup, because the product/services you're providing are not novel or new territory. If someone made a competitor to Jira, I might also hesitate to call it a startup. At some point these kind of services get commoditized.
Of course, colloquially this definition fails and I don't ever try to push this definition on people. But it helps to conceptually divide the "high-growth new product startups" from the "lifestyle startup" and "traditional business startups".
I think the brief description is a company in search of a new scalable business model.
If the business model is not new then the business can be categorized as X (grocery chain, real estate dealer, machine shop, etc).
If the business model is not new then the business can be categorized as X (grocery chain, real estate dealer, machine shop, etc).
600 people
Holy smokes. I didn't know it was already that large. What are they doing with 600 people that they were unable to do with 30? I haven't seen anything novel come out of there for a long time. Maybe Atom?
Holy smokes. I didn't know it was already that large. What are they doing with 600 people that they were unable to do with 30? I haven't seen anything novel come out of there for a long time. Maybe Atom?
Sales, marketing, operations and customer support would all need to add people as the size of your customer base grows, not just as you start adding new functionality.
And you've got the masseur, the person who services the Foosball table, the smoothie chef, ...
;o)
;o)
Seriously though. I toured a startup nearby me and they literally had a massage therapist, barber, therapist, barista, and numerous other service workers employed and working at least 9-5 every day serving the ~50 employees, 30 of which were sales, 10 engineers, and 10 executives.
As far as I could tell nobody used these perks that day. A guy even made his own coffee at his desk.
As far as I could tell nobody used these perks that day. A guy even made his own coffee at his desk.
Unless the company was swimming in cash a la Google or Apple, I would feel weird using services like those. Even if they had the money, I would prefer to just be paid more.
I imagine that due to economies of scale you'd be getting more value out of those services than you would from the equivalent cost to the company in pay. But that's only the case if you actually use the services and you would've paid for them anyways if they weren't provided.
Well, if their primary source of cash is investors rather than actual business...
Are they still seeing exponential growth?
Most of the people I've talked to who "reject management", they really reject "bad management".
to be fair, that is _most_ management. good management is quite rare, unfortunately.
And much of the "good" management I've encountered is actually about protecting your people from the bad management around and above you in the organization.
Many orgs tend to conflate technical leadership with people management and with project management, and they are different things.
Many orgs tend to conflate technical leadership with people management and with project management, and they are different things.
> Many orgs tend to conflate technical leadership with people management and with project management, and they are different things.
The problem is that if you get a professional PM, they typically have seniority on the org chart and call the shots, even when they don't have the technical capacity to do so.
I'd like to experience an in team flat structure, one where management/PM is working for the team, not in charge of them.
The problem is that if you get a professional PM, they typically have seniority on the org chart and call the shots, even when they don't have the technical capacity to do so.
I'd like to experience an in team flat structure, one where management/PM is working for the team, not in charge of them.
All the really excellent PMs at Microsoft that I worked with seemed "flat" to me -- they did coordination, technical documentation and basically "glued together" disparate groups. They were technically deep and would have made fine engineers, except they were better at communication and negotiation than your average engineer. They didn't seem to give a damn what the management structure was like, except to steer around it.
The poorer PMs were the ones stuck in hierarchy, who managed schedules, tracked bug counts and (aside from bug triage maybe) did work that could have been largely automated. These folks tended to circulate through and were generally fungible, even at the nosebleed levels of their management tree.
I would happily have traded 20 or 30 of the "bug counter" PMs for a couple of technical PMs who could write specs that meant something. (I saw many "bug counter" PMs quit, or get fired).
The poorer PMs were the ones stuck in hierarchy, who managed schedules, tracked bug counts and (aside from bug triage maybe) did work that could have been largely automated. These folks tended to circulate through and were generally fungible, even at the nosebleed levels of their management tree.
I would happily have traded 20 or 30 of the "bug counter" PMs for a couple of technical PMs who could write specs that meant something. (I saw many "bug counter" PMs quit, or get fired).
Yeah, one of the trademarks of the managers I enjoy is that they leave me (mostly) alone and clear my path.
Most management (current company excepted) all management does is request new features and down prioritize the previous "urgent" feature requests.
I suspect there is a fair amount of survivorship bias[1] in one's personal analysis of management. For me, the managers I can easily recall are the bad ones. Something about how anger makes a deeper mark in your memory than joy does.
[1] https://en.wikipedia.org/wiki/Survivorship_bias
[1] https://en.wikipedia.org/wiki/Survivorship_bias
> Something about how anger makes a deeper mark in your memory than joy does.
Uh? I thought that for most people, bad memories fade away and only good ones remain. And that's what I observed around me as well (I noted it because I seemed to be the only one in the group to remember bad memories linked to a certain period, while other guys only remembered the good ones and looked at this time through rose-tainted glasses and had totally forgotten about the whole lot of hardships we went through).
Uh? I thought that for most people, bad memories fade away and only good ones remain. And that's what I observed around me as well (I noted it because I seemed to be the only one in the group to remember bad memories linked to a certain period, while other guys only remembered the good ones and looked at this time through rose-tainted glasses and had totally forgotten about the whole lot of hardships we went through).
I know this is the stereotype but is that really so? In my country (Finland) only third of managers were recently estimated to be incompetent in some way or another - a considerable part - but hardly most (this was a fairly reputable study). I would love to have statistics from elsewhere.
Finland is probably an extreme outlier, based on my own readings in any case. I've never worked in Finland, only in the United States. My anecdotal data is that _most_ U.S. management really sucks.
I've heard it said that, compared to some European management styles, the US management style is analogous to starting a bunch of fires and frantically ordering people to urinate on them.
Its just agile/scrum for management. How is that working out for you guys? Do you get things finished?
Between the lines, hierarchy was necessary in order to impose HR-compliant politically-vetted governance.
"the Preston-Warner episode helped demonstrate that some problems couldn’t be solved by the masses. While the old times created a strong sense of camaraderie, employees didn’t know who to direct questions to, either about uncomfortable confrontations with colleagues or about their own performance"
"the Preston-Warner episode helped demonstrate that some problems couldn’t be solved by the masses. While the old times created a strong sense of camaraderie, employees didn’t know who to direct questions to, either about uncomfortable confrontations with colleagues or about their own performance"
"flatland" corporate structures don't really seem to scale. You eventually get to a point where the cost of coordination everyone needs to do is greater than the cost of having a bureaucracy. Also, I'm guessing that these structures are only effective in firms like Valve: a small number of experienced employees, no hard deadlines, and lots of specialists who know how to best allocate their time.
Valve's "flagship" software product Steam is full of bugs and terrible usability. (The ability to change font size went away when they switched to HTML rendering, and has never come back. Font size. A desktop application which is extremely likely to run on high DPI monitors where you can't adjust the font size.)
I've had a customer service request in for about 4 days now. I know that if/when it gets replied to, the person who replies won't read what I typed and I'll have to explain it again and wait another 5-6 days to get any action. (Before you ask, it's about a DLC that isn't part of their refund policy, so I can't simply refund it.)
Based on Steam's example, I'm not a fan of this concept. They're popular because they have a lot of network effect, not because Steam's any good.
I've had a customer service request in for about 4 days now. I know that if/when it gets replied to, the person who replies won't read what I typed and I'll have to explain it again and wait another 5-6 days to get any action. (Before you ask, it's about a DLC that isn't part of their refund policy, so I can't simply refund it.)
Based on Steam's example, I'm not a fan of this concept. They're popular because they have a lot of network effect, not because Steam's any good.
And this has been going on since it's inception, and I am hoping it finally bites them in the butt.
Every single other marketplace even slightly similar to Valve has support that outshines Valve in every single way possible.
EA with their Origin client launch did a fantastic job with customer service and making sure they are keeping as many people that actually use Origin, happy. (yeah we all love to hate them, but they got this one right.) I thought it would go to crap quickly but from my (admittedly limited) experience and what I have heard it is still great.
I am actually scared that should my steam account get hacked I will lose everything. I've used steam for many many years. I've put more money than I should have into it (400+ games) and now I have to be extremely careful that nothing I do screws my account because there is a very good chance that it will go unresolved and I will be out all of that time/money.
Whenever I look to get a game, I buy them any way I possibly can outside of steam before I turn to their platform.
I believe there is time for Valve to turn it around. There are many things they have certainly done right. They've done a great job pushing for Linux, especially since I moved to linux only gaming over a year and a half ago. They've helped Indie developers and modders bring their creations to a unified platform.
Every single other marketplace even slightly similar to Valve has support that outshines Valve in every single way possible.
EA with their Origin client launch did a fantastic job with customer service and making sure they are keeping as many people that actually use Origin, happy. (yeah we all love to hate them, but they got this one right.) I thought it would go to crap quickly but from my (admittedly limited) experience and what I have heard it is still great.
I am actually scared that should my steam account get hacked I will lose everything. I've used steam for many many years. I've put more money than I should have into it (400+ games) and now I have to be extremely careful that nothing I do screws my account because there is a very good chance that it will go unresolved and I will be out all of that time/money.
Whenever I look to get a game, I buy them any way I possibly can outside of steam before I turn to their platform.
I believe there is time for Valve to turn it around. There are many things they have certainly done right. They've done a great job pushing for Linux, especially since I moved to linux only gaming over a year and a half ago. They've helped Indie developers and modders bring their creations to a unified platform.
So why did steam win compared to other online game stores?
And why do they continue to do well with their game offerings?
And why do they continue to do well with their game offerings?
This is all from memory, so I may misidentify some factors as important and fail to identify some factors, and my chronology may be wrong.
Steam won because it had first mover advantage. Valve was historically a developer, and it launched Steam with a highly-anticipated game, so I suppose it didn't have pre-existing relationships with its retailers to negotiate. Other traditionally to-retail large publishers didn't get into the online distribution and online DRM game till quite a bit later. Meanwhile, the indie gaming scene exploded, and many of them chose to distribute via Steam.
As for why it continues to be the most popular platform, I presume that they are mostly due to it's reach as a channel as well as its gamification of its platform to encourage loyalty and spending. I think I should let someone who's seen things from the developer side answer this though.
Steam won because it had first mover advantage. Valve was historically a developer, and it launched Steam with a highly-anticipated game, so I suppose it didn't have pre-existing relationships with its retailers to negotiate. Other traditionally to-retail large publishers didn't get into the online distribution and online DRM game till quite a bit later. Meanwhile, the indie gaming scene exploded, and many of them chose to distribute via Steam.
As for why it continues to be the most popular platform, I presume that they are mostly due to it's reach as a channel as well as its gamification of its platform to encourage loyalty and spending. I think I should let someone who's seen things from the developer side answer this though.
In my limited experience working on teams that were flat what happened every time is a sort of unofficial structure formed. Experts, and senior staff, just sort of became the go-to people. As new folks were hired they'd see that certain people simply had more institutional knowledge or were already friendly with other parts of the org and would drift towards following their lead without being told to. Obviously there are exceptions but I've noticed this on a few teams now.
That reminds me of the story of university walkways:
https://books.google.ca/books?id=JEuYpTC-mQYC&pg=PA242&lpg=P...
In short, students walked over the grass, despite the "keep off the grass" signs. The solution proposed by university president Dwight D Eisenhower was "Why not let the students take whichever route works, and then build the walkways over the bare patches?"
The same could apply here. If the rank & file see person X as being necessary / useful, then give that person an official title and responsibilities.
https://books.google.ca/books?id=JEuYpTC-mQYC&pg=PA242&lpg=P...
In short, students walked over the grass, despite the "keep off the grass" signs. The solution proposed by university president Dwight D Eisenhower was "Why not let the students take whichever route works, and then build the walkways over the bare patches?"
The same could apply here. If the rank & file see person X as being necessary / useful, then give that person an official title and responsibilities.
"Desire paths". Also a form of least-cost, satisficing, problem solving / solution phenomena.
There might be a problem, though. A person can be a go to for a subject because he filled a hole at one point, and then proceeds to kidnap the subject entirely and even obtains new semi-informal-subordinates to work on the kidnapped subject under their orders. Such maintainers are usually not bad, but they can at the same time make tons of dubious discretionary choices and lack random amount of theoretical or practical knowledge. Depending on the culture, the situation can stay like this during years, even decades. Bonus points if such people suffer from the NIH syndrome...
This is fascinating, I guess it really did come from Eisenhower but I've heard many variants. The first time I heard it, it was attributed to Bill Gates deciding where the paths on the MS campus should be (this was during peak Microsoft, sometime in the '90s).
I've also heard a version (or two) in which the campus was specifically one of the top tier US schools for CS (MIT/Stanford/CMU/etc.). The common thread was always that it was supposed to illustrate the visionary status of whoever was in charge, and/or the enlightened status of the company or university. The Eisenhower version would be the oldest one though, perhaps it was the original.
I've also heard a version (or two) in which the campus was specifically one of the top tier US schools for CS (MIT/Stanford/CMU/etc.). The common thread was always that it was supposed to illustrate the visionary status of whoever was in charge, and/or the enlightened status of the company or university. The Eisenhower version would be the oldest one though, perhaps it was the original.
I didn't know it was attributed to someone (or many ones). I always thought it was a common reflection almost everyone develops after seeing a few of those natural paths compared to the officially built paths.
I heard that story but that it was Einstein at the IAS campus.
This is exactly what Wistia found: https://wistia.com/blog/ditching-flat
"We began to realize that by building a company with a flat org structure, we had done the exact opposite of what we had intended. We had centralized all the decision-making, and we were relying on a secret implicit structure to make progress.
Every company has a structure. If you don't explicitly define your structure, then you are left with an implicit one, and that can stifle productivity. We had hoped that being flat would let us move faster and be more creative, but as we grew, we ended up with an unspoken hierarchy that actually slowed down our ability to execute."
"We began to realize that by building a company with a flat org structure, we had done the exact opposite of what we had intended. We had centralized all the decision-making, and we were relying on a secret implicit structure to make progress.
Every company has a structure. If you don't explicitly define your structure, then you are left with an implicit one, and that can stifle productivity. We had hoped that being flat would let us move faster and be more creative, but as we grew, we ended up with an unspoken hierarchy that actually slowed down our ability to execute."
Also discovered by feminist organizations in decades past. A good read:
There is no such thing as a structureless group. Any group of people of whatever nature that comes together for any length of time for any purpose will inevitably structure itself in some fashion. --Jo Freeman, "The Tyranny of Structurelessness"
http://www.jofreeman.com/joreen/tyranny.htm
There is no such thing as a structureless group. Any group of people of whatever nature that comes together for any length of time for any purpose will inevitably structure itself in some fashion. --Jo Freeman, "The Tyranny of Structurelessness"
http://www.jofreeman.com/joreen/tyranny.htm
I was going to recommend that. Whether the accusations of gender discrimination were warranted or not, either way it would be a dead-classic example of power struggles in informal structures.
This organic emergence of an informal structure is what many anti-management advocates use to justify their stance. They say there is no need for formal bureaucracy when people will automatically follow natural leaders and good ideas.
While I appreciate the philosophical sentiment, I think it's both a little naive and a little jaded.
Naive because in practice, there are real disputes, and someone needs to be in a position to resolve those disputes and keep things organized. When the structure is informal, even with great technical people (and often this occurs more often with great technical people), effort will often be spent on duplicate tasks, and the differing implementations will compete for mindshare internally. While that's not always a problem, there are times when the structure needs to be directed so that more important corporate goals can be achieved. If the employees can't operate with unity, they may find the whole company unified with them on the unemployment line in the not-too-distant future.
It's naive because good ideas are not always received well by self-interested actors, especially when you're dealing with people of mixed experienced levels and backgrounds, as any company with more than a few employees is. The manager's role is to make a critical analysis of the proposal and make what is frequently a difficult choice about what will be in the organization's long-term interest.
It's also naive because there needs to be a designated official who represents both you to the company and the company to you. That representation ensures you always have someone to voice your concerns and needs to. It ensures that you understand what the company wants you to be doing instead of having to try to pull it out of the ether, come out with the wrong thing, and find yourself in sudden political turmoil. It ensures that you have an appointee who can advise and represent your cause in sensitive personnel matters, and argue for the value you bring to the company. A good manager serves many very important organizational functions besides just determining technical direction.
Jaded because such a massive majority of managerial structures are so comically broken and useless, that traumatized workers don't understand how they could ever be useful for anything and just want to chuck the whole thing out. Believe me, I beyond sympathize with this, but I don't think it always has to be that way. This is part of why finding a good corporate fit is very important for the job seeker.
Any time you get more than 3-5 people in a room, a political pecking order will naturally arise. That force needs checks and controls to keep everyone safe. Benevolent, mindful leadership from good, fair judges is critical to the success of any group of humans, whether organized into a corporation, nation, tribe, family, or other. We can't discard that principle just because it's hard to find qualified leaders.
While I appreciate the philosophical sentiment, I think it's both a little naive and a little jaded.
Naive because in practice, there are real disputes, and someone needs to be in a position to resolve those disputes and keep things organized. When the structure is informal, even with great technical people (and often this occurs more often with great technical people), effort will often be spent on duplicate tasks, and the differing implementations will compete for mindshare internally. While that's not always a problem, there are times when the structure needs to be directed so that more important corporate goals can be achieved. If the employees can't operate with unity, they may find the whole company unified with them on the unemployment line in the not-too-distant future.
It's naive because good ideas are not always received well by self-interested actors, especially when you're dealing with people of mixed experienced levels and backgrounds, as any company with more than a few employees is. The manager's role is to make a critical analysis of the proposal and make what is frequently a difficult choice about what will be in the organization's long-term interest.
It's also naive because there needs to be a designated official who represents both you to the company and the company to you. That representation ensures you always have someone to voice your concerns and needs to. It ensures that you understand what the company wants you to be doing instead of having to try to pull it out of the ether, come out with the wrong thing, and find yourself in sudden political turmoil. It ensures that you have an appointee who can advise and represent your cause in sensitive personnel matters, and argue for the value you bring to the company. A good manager serves many very important organizational functions besides just determining technical direction.
Jaded because such a massive majority of managerial structures are so comically broken and useless, that traumatized workers don't understand how they could ever be useful for anything and just want to chuck the whole thing out. Believe me, I beyond sympathize with this, but I don't think it always has to be that way. This is part of why finding a good corporate fit is very important for the job seeker.
Any time you get more than 3-5 people in a room, a political pecking order will naturally arise. That force needs checks and controls to keep everyone safe. Benevolent, mindful leadership from good, fair judges is critical to the success of any group of humans, whether organized into a corporation, nation, tribe, family, or other. We can't discard that principle just because it's hard to find qualified leaders.
> Also, I'm guessing that these structures are only effective in firms like Valve: a small number of experienced employees, no hard deadlines, and lots of specialists who know how to best allocate their time
Are they that effective at Valve though? Seems it's not bad enough to cause the company serious damage but are they doing much nowadays? Yes there's the Vive but that's in partnership with HTC who may be providing a lot of the top-level direction.
I get the feeling Valve is coasting along on the Steam cash cow and could be doing a lot more with the people and resources they have available.
Are they that effective at Valve though? Seems it's not bad enough to cause the company serious damage but are they doing much nowadays? Yes there's the Vive but that's in partnership with HTC who may be providing a lot of the top-level direction.
I get the feeling Valve is coasting along on the Steam cash cow and could be doing a lot more with the people and resources they have available.
People forget how hard-fought the battle for Steam really was. Half-Life 2's release on Steam nearly broke them. One word for it could be "coasting", but another might be "reaping" the rewards of choosing to fight that battle long before anyone else believed it was winnable.
And they're not really coasting. They're at the forefront of broadcast gaming, competitive gaming, whatever you want to call it. I've watched Riot grow, and Blizzard falter in that industry, but I'm damn near positive that Valve has the better framework for the long-term.
Edit: I also think that Valve's primary product is "not having to deal with industry standard financing and deadline problems so we can make games that are actually good without burning out like everyone else does."
And they're not really coasting. They're at the forefront of broadcast gaming, competitive gaming, whatever you want to call it. I've watched Riot grow, and Blizzard falter in that industry, but I'm damn near positive that Valve has the better framework for the long-term.
Edit: I also think that Valve's primary product is "not having to deal with industry standard financing and deadline problems so we can make games that are actually good without burning out like everyone else does."
They are maintaining three of the largest free to play games in the world. Revenues from those three games is said to rival that of Steam itself.
An example of a flat structure failure is the complete lack of a new episode of Half Life.
I think not doing HL3 was the right move from the business standpoint. The expectations of the HL fans got so high that anything short of another milestone of PC gaming history would damage them. It is hard to beat yourself, when the last success was so big. Much smarter to put the effort into several other directions.
Doing half life 2, then switching to episodic content so you can get things moving faster, then taking forever to release 2 episodes, then sitting around for a decade with an unresolved cliffhanger is ridiculous.
I don't buy your reasoning either. Right business move because DotA 2 and their Hats! are a cash cow business, sure.
I don't buy your reasoning either. Right business move because DotA 2 and their Hats! are a cash cow business, sure.
They're waiting for VR. Half-Life 2 already spans everything cool you could conceivably do with a 'post-quake 2' shooter. Team Fotress 2, Counter-Strike: Global Offensive, and Dota 2 cover all the neat online matchmaking, micro-transaction, user-created content stuff.
They don't want to make Half-Life 3, the expansion to Half-Life 2. They want to make something new. They created something new with Portal, which required them to hone their ability to introduce players to an entirely new game mechanic, but now they have to wait for VR to put it all together.
They don't want to make Half-Life 3, the expansion to Half-Life 2. They want to make something new. They created something new with Portal, which required them to hone their ability to introduce players to an entirely new game mechanic, but now they have to wait for VR to put it all together.
As a fan of the HL series, I don't need a revolution, I just want to finish the darn story.
We can all appreciate Vulkan
It is rumored not to work well at Valve either. Once you get past Dunbar's number, subgroups form. It's better to make them explicit. Otherwise you tend to get cliques, which are probably worse than hierarchy:
http://www.wired.com/2013/07/wireduk-valve-jeri-ellsworth/
http://www.wired.com/2013/07/wireduk-valve-jeri-ellsworth/
> I'm guessing that these structures are only effective in firms like Valve
Valve seems like the poster child for upsides and downsides of this system.
They release cool games, make lot of money, Hats!
On the other hand, steam is still really clunky and their customer service has historically been horrible.
Valve seems like the poster child for upsides and downsides of this system.
They release cool games, make lot of money, Hats!
On the other hand, steam is still really clunky and their customer service has historically been horrible.
So terrible that I quit using them all together. My account got into a state were I could not buy any games, and after weeks of customer service emails which lead no resolution and only canned responses, I just gave up on the platform enterily.
I've never tried so hard to give a company my money and have them so actively refuse it.
I've never tried so hard to give a company my money and have them so actively refuse it.
Having heard stuff from people who work there I really don't buy the idea that Valve actually has a flat corporate structure. Maybe it looks that way if your name is Gabe Newell, but it sure sounds pretty hierarchical to me (maybe even toxicly so).
So what is the strategy to go to keep as much flatland as possible? Split it up into several small companys and one that is basically managing as a external entity the coordination of those smaller flatlanders?
My personal experience has been that many of the engineers most in favor of flatland management are in fact most in need of good managers themselves.
One of the biggest challenges for flatland-style organizations is getting technical people to focus on business objectives which tend to be non-fun. For software that includes fixing a lot of hard bugs and really delivering on features like complete documentation, monitoring, and good upgrades.
(Disclaimer: I have been a manager about 2/3 of the time in my last few jobs. I'm an engineer currently.)
One of the biggest challenges for flatland-style organizations is getting technical people to focus on business objectives which tend to be non-fun. For software that includes fixing a lot of hard bugs and really delivering on features like complete documentation, monitoring, and good upgrades.
(Disclaimer: I have been a manager about 2/3 of the time in my last few jobs. I'm an engineer currently.)
> For software that includes fixing a lot of hard bugs and really delivering on features like complete documentation, monitoring, and good upgrades.
That's exactly the kinds of things I wish that I could do. In my experience it's mostly managers that want you to push features without any documentation and filled with bugs.
That's exactly the kinds of things I wish that I could do. In my experience it's mostly managers that want you to push features without any documentation and filled with bugs.
I am a junior developer, but my experience so far has been exactly this; arbitrary deadlines, poorly defined or no technical specification and worst of all, no room for testing or documentation, yet still somehow expecting it to happen in the end.
Well look at it this way....if all of those things were to be provided to you, they could probably find someone to do your job for 30% less. There are some upsides to software being a total shitshow.
I would, as an engineer, be okay with that. As you imply, that makes me considerably more valuable. The problem is that I'm never given time for any of it. As soon as "MVP" status is reached, the feature is launched, declared a victory, and then we move on to the next thing, while the users note the half-assedness of the delivered product, and never looked on again. Meaningful work (aside from the occiasional bugfix) never occurs, as it can't ever get prioritized higher than the current MVP of the day.
Sounds like planning economics in a miniature kingdom.. does not matter whether the product sucks, as long as it gives bragging rights to the duke.
The problem is that most of management, contrary to there claims, are totally detached from market forces as long as a company has a cash cow.
a lot of the crucial work in engineering happens only after you learn when to say "no".
I wonder how much more happens only after you say "fuck it I'm doing this thing that we've desperately needed to do regardless of manager approval or sanctioned time."
When the whole dev team is in on it it's actually not too hard to bake in extra time for the unseen things by just everyone taking longer than they would if they were doing purely what the managers wanted. (Though ideally by doing some of the unseen things the total time for future work will become less than it would have because you don't drown yourself in tech debt by trying to do the PM's MVP only every time... It's nice to have a PM who understands that tradeoff.)
When the whole dev team is in on it it's actually not too hard to bake in extra time for the unseen things by just everyone taking longer than they would if they were doing purely what the managers wanted. (Though ideally by doing some of the unseen things the total time for future work will become less than it would have because you don't drown yourself in tech debt by trying to do the PM's MVP only every time... It's nice to have a PM who understands that tradeoff.)
You shouldn't worry about software being late. Work at a good clip with the time you have. This is just the norm for this industry and the only managers who presume otherwise are themselves novices.
Unfortunately, one needs to get a bit of experience (and risk early burnout) before they cotton on to that fact.
My first real junior dev job [1] gave me an ulcer. I only relaxed when I realised what you allude to: people yelled at me and complained about my working pace (and the fact I didn't... smile) but there wasn't anyone else willing to do the job I was paid a pittance to do, especially not with that money. I could just take my time and do my best in the time I thought was appropriate and let middle management go screw themselves. Poor bastards anyway- they were the de facto product testers so they probably had it worse than me in the end.
[1] In other words, working for a company that didn't give a shit about me and just used me in a "human-wave" sort of approach to development. This also came after a stint at a company that treated me fairly and gave me a full "software engineer" title, no "junior"s, so I had the chance to observe the difference between the two models very closely.
My first real junior dev job [1] gave me an ulcer. I only relaxed when I realised what you allude to: people yelled at me and complained about my working pace (and the fact I didn't... smile) but there wasn't anyone else willing to do the job I was paid a pittance to do, especially not with that money. I could just take my time and do my best in the time I thought was appropriate and let middle management go screw themselves. Poor bastards anyway- they were the de facto product testers so they probably had it worse than me in the end.
[1] In other words, working for a company that didn't give a shit about me and just used me in a "human-wave" sort of approach to development. This also came after a stint at a company that treated me fairly and gave me a full "software engineer" title, no "junior"s, so I had the chance to observe the difference between the two models very closely.
Or are cynically using it to crack the whip and aggrandize power with zero regard for whether the deadlines are meaningful.
"Noted Good Developer A thinks it will take at least 3 weeks for you to complete this feature request, but we're being pushed to get it out in 2. I think you could manage that, but what about you? Can you do it or not?"
Yes. I've been getting thrown into the team lead position quite a bit as I've gotten older.
I get tasked with delivering arbitrary deadlines for impossible features and timelines to my team and managing the outcomes.
There really are no other reasons for some of these deadlines other than higher mgmt. competing against each other. There are no business reasons.
Long ago I just started ignoring them and giving my team deadlines that were both reasonable and obtainable. I don't want anybody stressed on a daily basis.
If mgmt thinks they can do better, go for it.
I get tasked with delivering arbitrary deadlines for impossible features and timelines to my team and managing the outcomes.
There really are no other reasons for some of these deadlines other than higher mgmt. competing against each other. There are no business reasons.
Long ago I just started ignoring them and giving my team deadlines that were both reasonable and obtainable. I don't want anybody stressed on a daily basis.
If mgmt thinks they can do better, go for it.
Yes, and the more I work with software, the more my shitshow tolerance goes up (and the more of a hardened old man I become).
I've become especially cynical of highly marketed "shiny" third-party things that are actually completely broken when it comes to technical innards:
MongoDB, Segment analytics, Unity3D game engine, to name a few...
I've become especially cynical of highly marketed "shiny" third-party things that are actually completely broken when it comes to technical innards:
MongoDB, Segment analytics, Unity3D game engine, to name a few...
> "shiny"
Ahhh yes. Fancy website? Grandiose claims? Piece of crap.
Essentially plain text site? "just a tool"? Couldn't live without it
Ahhh yes. Fancy website? Grandiose claims? Piece of crap.
Essentially plain text site? "just a tool"? Couldn't live without it
Case in point: vim's web site looks like ass:
http://www.vim.org/
http://www.vim.org/
>> they could probably find someone to do your job for 30% less.
Aye, and that person would be called a "junior developer".
Aye, and that person would be called a "junior developer".
It isn't a manager's job to provide you with well defined technical specifications. Figuring those out takes an ongoing iterative process involving input from multiple stakeholders.
One thing that can really help in organizations that lack discipline is to define a detailed, rigorous definition of done and institute strict work-in-progress limits for each agile team. That way the team will be less likely to underestimate in the first place and everyone understands that time must be allowed for testing and documentation.
One thing that can really help in organizations that lack discipline is to define a detailed, rigorous definition of done and institute strict work-in-progress limits for each agile team. That way the team will be less likely to underestimate in the first place and everyone understands that time must be allowed for testing and documentation.
Technical specs no, but well defined product requirements definitely yes.
I'm fine with engineers fleshing out the technical specs(who else is gonna do it anyway?), but requirements come by engaging with the stakeholders, as you said, most notably your client(s).
And this is not a job for your engineers.
I'm fine with engineers fleshing out the technical specs(who else is gonna do it anyway?), but requirements come by engaging with the stakeholders, as you said, most notably your client(s).
And this is not a job for your engineers.
Engineers are not black boxes which take well defined product requirements as input and produce code as output. That seldom results in good products in the real world. A competent engineer has to understand the business domain and be intimately involved in the requirements definition process. The product owner (or product manager for higher level stuff) has the final authority on requirements but it's a two way conversation. Otherwise too many things fall through the cracks.
It's silly and counterproductive for engineers to expect managers to be all-knowing seers, and then act disappointed and put upon when those managers inevitably make mistakes. They're human too. Find a way to work with them productively.
It's silly and counterproductive for engineers to expect managers to be all-knowing seers, and then act disappointed and put upon when those managers inevitably make mistakes. They're human too. Find a way to work with them productively.
Yes let's not over-analyze this.
Obviously an engineer is involved in the shaping of the requirements by interacting with the product manager or whoever(never the client). By asking questions, making inquiries and sometimes even poke holes into user stories that ultimately don't make much sense.
No one is all-knowing, no requirements are perfect, etc etc.
What I'm saying is that it's the job of the (Product) manager to understand what the client wants and to relay this into more tangible terms to the engineers.
As for knowing the business domain. Meh, sometimes maybe, but I can think of myriad of situations that it doesn't matter and it may not even make sense.
If you have dozens of engineers and you expect all(or most) of them to be familiar with the business domain, I'd suspect there would be some serious management/organizational problems in that company.
Obviously an engineer is involved in the shaping of the requirements by interacting with the product manager or whoever(never the client). By asking questions, making inquiries and sometimes even poke holes into user stories that ultimately don't make much sense.
No one is all-knowing, no requirements are perfect, etc etc.
What I'm saying is that it's the job of the (Product) manager to understand what the client wants and to relay this into more tangible terms to the engineers.
As for knowing the business domain. Meh, sometimes maybe, but I can think of myriad of situations that it doesn't matter and it may not even make sense.
If you have dozens of engineers and you expect all(or most) of them to be familiar with the business domain, I'd suspect there would be some serious management/organizational problems in that company.
Shaping the specification I would certainly not have a problem with, but because I do not have a direct communication channel with the client, I must rely on my manager to be a good, accurate "translator" between me and the client and the other way around.
Often however, the manager takes a bit too much "artistic liberty" in relying what I said to the client, usually announcing features as done when that's not remotely the case or worse still, selling features as done which I don't even know about yet.
I've also learnt that when a client asks "How long?", the manager seems eager to give an eagerly short date, usually around two weeks, for even complex feature, before consulting the engineers and has the whole "I know what I am talking about here.", attitude.
Often however, the manager takes a bit too much "artistic liberty" in relying what I said to the client, usually announcing features as done when that's not remotely the case or worse still, selling features as done which I don't even know about yet.
I've also learnt that when a client asks "How long?", the manager seems eager to give an eagerly short date, usually around two weeks, for even complex feature, before consulting the engineers and has the whole "I know what I am talking about here.", attitude.
>product requirements definitely yes
No matter where I've worked, most product is basically no one knows what they want until its built and sitting in front of them.
No matter where I've worked, most product is basically no one knows what they want until its built and sitting in front of them.
Yes that is exactly why lean agile development was invented. It should be standard practice in most development organizations by now, but yet people still want to believe that it's possible to reliably anticipate what customers want far in advance. Sometimes you can guess right but that's a risky proposition and seldom repeatable.
So what's the purpose of a product manager in an agile environment?
To keep you iterating, to ensure iterations are productive, to wrangle those disparate stakeholders into evaluating the "now" and to turn criticisms into the "next".
The SAFe definition is a good place to start.
http://scaledagileframework.com/product--and-solution-manage...
Yet another definition of Agile?
I wish they would let me get involved in the process more. I know that doing one feature might take one week or two. However doing it another way I can probably do it in a day and get 95% of the functionality needed.
That is interesting. Which parts of the process would you want to be involved in, and why would it make such a difference in the time needed for the delivery of the feature?
Being involved in the discussions about what features we are going to implement usually.
Right now we have a designer making mock up pages for me and we have a deadline. He is adding a fair bit of stuff that will need to be done with a mix of back end code and JavaScript. If we do things slightly differently I can code most of it in Django. If we do it exactly as he has done, i will need slightly less Django code, but the same amount of code again in JavaScript. Plus I find it better to have as much logic in the back end, rather than jumping between JavaScript and Python to work out where bugs are.
Right now we have a designer making mock up pages for me and we have a deadline. He is adding a fair bit of stuff that will need to be done with a mix of back end code and JavaScript. If we do things slightly differently I can code most of it in Django. If we do it exactly as he has done, i will need slightly less Django code, but the same amount of code again in JavaScript. Plus I find it better to have as much logic in the back end, rather than jumping between JavaScript and Python to work out where bugs are.
Well, yes I agree to everything you said.
The designers must always collaborate with the engineers, if that's not happening it's bad project management :(
I also approve your tech/engineering choices :D
The designers must always collaborate with the engineers, if that's not happening it's bad project management :(
I also approve your tech/engineering choices :D
> And this is not a job for your engineers.
Probably slightly too B&W for the shades of grey of HN.
Practically speaking, engineers wearing both product & engineering hats are effective and sometimes crucial part of the process. Obviously more so in LEANer teams. And less so long-running enterprise projects.
Probably slightly too B&W for the shades of grey of HN.
Practically speaking, engineers wearing both product & engineering hats are effective and sometimes crucial part of the process. Obviously more so in LEANer teams. And less so long-running enterprise projects.
In my experience, the very best value comes from people who are simultaneously technical experts and domain experts. This lets them short circuit the vast majority of communication overheads, because they know both the user requirements and the implementation details simultaneously.
They also might expect documentation and thorough testing when things break. This forces an inverse relationship where the engineer has to manage the manager by documenting interactions and then having the manager acknowledge them. Otherwise the manager will push and blame the engineer when things go sour. Its a sad dynamic that is rather common. You sort of get used and good at it with time. It is not exclusive to software, though. Its everywhere because most people can't manage.
I agree with part of your sentence only. Managers, especially professional ones (as opposed to ones that were promoted from the kind of position they end up managing) do tend to push for client-facing features with little thought to the accumulating technical debt.
It's been my experience, however, that when left to their own devices, developers tend to either learn new things or refactor code that's getting too hard to maintain. And both are important, critical even, but certainly no help in getting up to date documentation, fixing "painful" bugs, or writing good tests. In fact, they can even be counter-productive in that respect: heavily refactored code will invalidate at least part of its documentation and tests.
It's been my experience, however, that when left to their own devices, developers tend to either learn new things or refactor code that's getting too hard to maintain. And both are important, critical even, but certainly no help in getting up to date documentation, fixing "painful" bugs, or writing good tests. In fact, they can even be counter-productive in that respect: heavily refactored code will invalidate at least part of its documentation and tests.
I've had this and I have good managers.
I worked outside of the Bay Area before coming here. I can tell you that the Bay Area tech has the worse managers. They drink the Kool-Aid way to hard out here.
I worked outside of the Bay Area before coming here. I can tell you that the Bay Area tech has the worse managers. They drink the Kool-Aid way to hard out here.
Even if it isn't the managers themselves that personally want to skip those things, their boss wants the next feature.
A major part of the art of the handwavey term "good" management at the technical-line-level-and-middle-management stage is exactly in that area of "selling the rest of the business on why this will take longer than it sounds" and "protecting the team's time to work on what the team needs to work on to continue to be able to deliver stuff fast."
Good management means the team can keep working fast. Bad management means that three-to-five years later, someone has to come in and really put their foot down and say "if you want simple features to stop taking six months we have to take the time now." But to be able to sell that message outside the tech team at that point, you sorta have to be an external "fixer" - IME, it's hard to sell your own ability to clean up the mess if you're seen as part of who created it, sadly.
Figuring out the difference between a place with good management and bad management if you're interviewing there can be tricky - but if they don't have tests, etc, and also can't tell you their plan to add them / why they're adding them now, that's probably a bad sign. Or ask them what they've shipped recently and how long it took - maybe easier to look for the symptoms than for specific process failings, since those could be wildly varied.
EDIT: I love working in flat structures where the total relevant number of people to what I'm working on is under 15. Either a small startup or a truly independent sub-unit. But there are few worse environments than a flat structure where 30+ people feel like they should have a say in a given feature.
Good management means the team can keep working fast. Bad management means that three-to-five years later, someone has to come in and really put their foot down and say "if you want simple features to stop taking six months we have to take the time now." But to be able to sell that message outside the tech team at that point, you sorta have to be an external "fixer" - IME, it's hard to sell your own ability to clean up the mess if you're seen as part of who created it, sadly.
Figuring out the difference between a place with good management and bad management if you're interviewing there can be tricky - but if they don't have tests, etc, and also can't tell you their plan to add them / why they're adding them now, that's probably a bad sign. Or ask them what they've shipped recently and how long it took - maybe easier to look for the symptoms than for specific process failings, since those could be wildly varied.
EDIT: I love working in flat structures where the total relevant number of people to what I'm working on is under 15. Either a small startup or a truly independent sub-unit. But there are few worse environments than a flat structure where 30+ people feel like they should have a say in a given feature.
Then they are useless. Send us the boss directly, will save a layer of communication.
Problem is the boss wants a unique interlocutor, and one who says yes. Then if he is friendly enough, engineers will prefer to do a shitty job (rush "features" and even more bugs) rather than inconvenience their manager who already committed on behalf of the whole team.
Problem is the boss wants a unique interlocutor, and one who says yes. Then if he is friendly enough, engineers will prefer to do a shitty job (rush "features" and even more bugs) rather than inconvenience their manager who already committed on behalf of the whole team.
sounds like you want a flat structure.
Or they just want to cut out unnecessary layers. You don't really want an extra level between the group demanding the features and the group implementing them.
Feedback about technical feasibility, time to implement et cetera really needs to go directly to the group demanding the feature, and their responses need to come directly back to the group implementing it. A competent middle man can help those two groups interact, but generally adding an extra middle layer reduces everybody's ability to function well.
Feedback about technical feasibility, time to implement et cetera really needs to go directly to the group demanding the feature, and their responses need to come directly back to the group implementing it. A competent middle man can help those two groups interact, but generally adding an extra middle layer reduces everybody's ability to function well.
I second this. Well, the pushing features part but hopefully documented and without (many) bugs. But features for the sales team is considered important.
I usually like researching and fixing bugs, especially when they are mine. But compare business value between bugs versus new features and guess which one wins the most.
I usually like researching and fixing bugs, especially when they are mine. But compare business value between bugs versus new features and guess which one wins the most.
Flat orgs are an overreaction to the traditional top heavy big corp structures. Where each staff member is reporting to multiple unsynchronized management chains. Nothing is more frustrating that having to be caught in the middle of three managers who all disagree with what the priorities should be, and refuse to mediate it amongst themselves. Not to mention the infighting once your company is over 1000 people and you start having boss A demand all your time specifically to frustrate boss B's plans.
All of the above is non-fun. I'll do all the boring documentation, monitoring and change control and say thank you. I'm not trying to be harsh on managers (I am one), but I can't blame people for overreacting.
All of the above is non-fun. I'll do all the boring documentation, monitoring and change control and say thank you. I'm not trying to be harsh on managers (I am one), but I can't blame people for overreacting.
Apologies, but it has to be said: in my professional experience, it's the management that stops technical people fixing bugs, completing documentation, fixing infrastructure, providing good upgrade paths, refactoring, etc.
Yes. Similarly, I've also found that people who say "I'm too busy working to bother measuring what I'm doing" are the ones most in need of measurement. (Same with "Too busy to communicate" and "Too busy to meet")
There are reasons for coordination and trust, otherwise 100% of the workforce would be independent contractors.
There are reasons for coordination and trust, otherwise 100% of the workforce would be independent contractors.
Exactly. Hard to make a kid clean and tidy their room (source: parent, also engineering manager for n decades..)
Do you work for one of those companies that hire only 22-year-olds who can answer irrelevant computer science questions on a whiteboard, and then you wonder why it's hard to get engineers excited about business goals rather than endless tinkering with algorithms and languages...?
Age has little to do with it, it's more a combination of maturity, professionalism, intellect and talent. These things are correlated with age, but not as strongly as one might think. I've worked with 22-year old developers who had all of these qualities, and developers with 22 years of professional experience who didn't. It does tend to go the other way though.
Even the best ones probably wouldn't flourish in a flat org though- that's not a knock against the developers, more the unsuitability of most software tasks to such a structure (or lack of it).
On the other hand, I think there's a very strong correlation between people who think they would flourish in a flat org and people who wouldn't do well in one. The only people who might do all right are those who would join a flat org with great skepticism and trepidation, because they would be paranoid enough about things going off the rails that they would obsess over making sure that their own goals are set appropriately as well as the people around them.
If you get rid of managers, essentially everyone becomes a manager of sorts and they need to really embrace the role to make it work.
Even the best ones probably wouldn't flourish in a flat org though- that's not a knock against the developers, more the unsuitability of most software tasks to such a structure (or lack of it).
On the other hand, I think there's a very strong correlation between people who think they would flourish in a flat org and people who wouldn't do well in one. The only people who might do all right are those who would join a flat org with great skepticism and trepidation, because they would be paranoid enough about things going off the rails that they would obsess over making sure that their own goals are set appropriately as well as the people around them.
If you get rid of managers, essentially everyone becomes a manager of sorts and they need to really embrace the role to make it work.
> If you get rid of managers, essentially everyone becomes a manager of sorts and they need to really embrace the role to make it work.
This. In my years of working in Software, I've dealt with managers, both good and bad. The best ones have without a doubt been those who took care that I had to attend as few meetings as possible, that my requirements for work were met, who were open to genuine conversation about my performance.
This. In my years of working in Software, I've dealt with managers, both good and bad. The best ones have without a doubt been those who took care that I had to attend as few meetings as possible, that my requirements for work were met, who were open to genuine conversation about my performance.
In the corporate world, I've worked in both accounting and software development, and what you wrote describes good manager in both fields.
Although I don't have much evidence (yet, but I'm doing some research), I suspect that the qualities that make up good managers (and bad ones) is fairly similar from one field to the next.
Although I don't have much evidence (yet, but I'm doing some research), I suspect that the qualities that make up good managers (and bad ones) is fairly similar from one field to the next.
Actually my current company is pretty large and it's not like that at all. The technical people are by and large extremely good.
And to your first question I have been through a few interviews with those 22-year-olds who asked about irrelevant CS questions. That's a good sign to avoid the company.
And to your first question I have been through a few interviews with those 22-year-olds who asked about irrelevant CS questions. That's a good sign to avoid the company.
I run my own companies so no, but I know what you mean. I however suspect that this runs deeper than just Google's hiring process:
We're all (technical folk) steeped since we were 12 years old in a culture that says that solving tricky problems in the most elegant way is what gets you love. This way of thinking predates computers by thousands of years. I think this is the root of why you see everything slant towards cool trickery rather than solid engineering and working stuff. There is something of an age factor but only insofar as the more experienced people end up having this way of thinking partially beaten out of them by real life experiences and the benefit of a long time observing the "nons" in the world.
We're all (technical folk) steeped since we were 12 years old in a culture that says that solving tricky problems in the most elegant way is what gets you love. This way of thinking predates computers by thousands of years. I think this is the root of why you see everything slant towards cool trickery rather than solid engineering and working stuff. There is something of an age factor but only insofar as the more experienced people end up having this way of thinking partially beaten out of them by real life experiences and the benefit of a long time observing the "nons" in the world.
Hard to believe but most of the engineers I've worked with were actually adults, and didn't need to be treated like children.
Life scales.
On rare occasions it's the opposite, though; I've tried in some places (as a developer) to advocate for deeper business needs, but the development manager is totally focused on the easy and fun stuff. In that case a flat developer group would've had better long term results.
Isn't it true then that:
good manager > no manager > bad manager
?
We desperately need to find new organisational forms - it's crazy in modern western democracies most of us spend our lives in command and control dictatorships
However the transition is hard. Democracy is nice but companies are too close to the daily life of people to allow a vote every four years and let others decide policy
GitHub could have experimented with new ways of deciding policy (voting) - and I would argue that it's likely they would have got things like "write good docs" voted in anyway.
And it would be interesting to see how one handles voting on issues like "gender bias"
But we will all have to have companies like this one day - otherwise where do the big value wins come from. We can't keep inventing technology of the 21 C and hope they overcome the management hierarchies of the Stone Age
However the transition is hard. Democracy is nice but companies are too close to the daily life of people to allow a vote every four years and let others decide policy
GitHub could have experimented with new ways of deciding policy (voting) - and I would argue that it's likely they would have got things like "write good docs" voted in anyway.
And it would be interesting to see how one handles voting on issues like "gender bias"
But we will all have to have companies like this one day - otherwise where do the big value wins come from. We can't keep inventing technology of the 21 C and hope they overcome the management hierarchies of the Stone Age
There are other forms of structural organisation than strict hierarchies.
One interesting one proposed by cyberneticist Stafford Beer was dubbed Syntegrity [1].
It involved relationships between workers structured like a bucky ball, where each person had direct influence over a number of topics, and oversight of a number of others.
The result was (in theory) an arrangement where everyone had some responsiblity, but there was no overall "leadership". In theory
[1] https://en.wikipedia.org/wiki/Syntegrity
One interesting one proposed by cyberneticist Stafford Beer was dubbed Syntegrity [1].
It involved relationships between workers structured like a bucky ball, where each person had direct influence over a number of topics, and oversight of a number of others.
The result was (in theory) an arrangement where everyone had some responsiblity, but there was no overall "leadership". In theory
[1] https://en.wikipedia.org/wiki/Syntegrity
Thank you - but I think that the perhaps less complicated goal of achieving corporate democracy will be hard enough :-)
>the management hierarchies of the Stone Age //
We have the same general primary social structure - certain people have control of a lot more of the resources than others and don't want to cede that control.
Is there any wonder that we have those structures in organisations whose focus is "making a profit", ie ensuring unequal distribution of resources by increasing the control of resources for those who already have the most.
We have the same general primary social structure - certain people have control of a lot more of the resources than others and don't want to cede that control.
Is there any wonder that we have those structures in organisations whose focus is "making a profit", ie ensuring unequal distribution of resources by increasing the control of resources for those who already have the most.
There is a certain logic in capitalism - farmers who are a successful are good at farming. The history of taking farms away from farmers and redistributing the land is usually bad.
So I have very few issues with "making a profit", it's just that "fire is needed in the engine room, to drive the steam engines and turn the wheels. But one does not invite fire up to the cockpit and let it steer". Democracy should choose where to steer. Capitalism can provide the engine room.
So I have very few issues with "making a profit", it's just that "fire is needed in the engine room, to drive the steam engines and turn the wheels. But one does not invite fire up to the cockpit and let it steer". Democracy should choose where to steer. Capitalism can provide the engine room.
Sort of.
The problem arises that the successful capitalist farmer is rich and well fed; those living around the farm might be starving though.
Under other structures to be successful the farm would need to have everyone reasonably well fed.
In the capitalist regime the farmer is rewarded by keeping successful method to himself. Then he gets more farms to control and more wealth.
Under other ideologies the successful farmer shares his ideas and method so that the society can prosper, in turn the well fed populous can work well and improve the farmers life too.
The capitalist farmer wants other to fail, then he gets more. The other farmer needs others to succeed, then he gets more.
[Yes that's simplified and idealised.]
The problem arises that the successful capitalist farmer is rich and well fed; those living around the farm might be starving though.
Under other structures to be successful the farm would need to have everyone reasonably well fed.
In the capitalist regime the farmer is rewarded by keeping successful method to himself. Then he gets more farms to control and more wealth.
Under other ideologies the successful farmer shares his ideas and method so that the society can prosper, in turn the well fed populous can work well and improve the farmers life too.
The capitalist farmer wants other to fail, then he gets more. The other farmer needs others to succeed, then he gets more.
[Yes that's simplified and idealised.]
> modern western democracies
Modern western democracies aren't democracies, they're republics. Part of the reason they aren't direct democracies is actually a thing you mention: in a direct democracy the 51% effectively rule over the 49% and there is no recourse for the minority to have their needs met.
Also, no need to re-invent the wheel. If you want a model where an organisation isn't led by a "self-appointed dictator", just look at cooperatives, or foundations like Mozilla.
Modern western democracies aren't democracies, they're republics. Part of the reason they aren't direct democracies is actually a thing you mention: in a direct democracy the 51% effectively rule over the 49% and there is no recourse for the minority to have their needs met.
Also, no need to re-invent the wheel. If you want a model where an organisation isn't led by a "self-appointed dictator", just look at cooperatives, or foundations like Mozilla.
Republics can also be democracies. "Democracy" includes the many types of representative democracies. https://en.wikipedia.org/wiki/Representative_democracy .
Most of the people I've talked to who make the argument that a republic is not a democracy base point to Federalist #10. But Madison was comparing a "pure democracy" - "by which I mean a society consisting of a small number of citizens, who assemble and administer the government in person" - and a "republic" - "by which I mean a government in which the scheme of representation takes place".
The section at https://en.wikipedia.org/wiki/Republicanism#Democracy_and_re... highlights how "democracy" now is something a bit more broad than was used 225+ years ago:
> In contemporary usage, the term democracy refers to a government chosen by the people, whether it is direct or representative.[32] Today the term republic usually refers to a representative democracy with an elected head of state, such as a president, who serves for a limited term; in contrast to states with a hereditary monarch as a head of state, even if these states also are representative democracies, with an elected or appointed head of government such as a prime minister.[33]
> The Founding Fathers of the United States rarely praised and often criticized democracy, which in their time tended to specifically mean direct democracy;
Most of the people I've talked to who make the argument that a republic is not a democracy base point to Federalist #10. But Madison was comparing a "pure democracy" - "by which I mean a society consisting of a small number of citizens, who assemble and administer the government in person" - and a "republic" - "by which I mean a government in which the scheme of representation takes place".
The section at https://en.wikipedia.org/wiki/Republicanism#Democracy_and_re... highlights how "democracy" now is something a bit more broad than was used 225+ years ago:
> In contemporary usage, the term democracy refers to a government chosen by the people, whether it is direct or representative.[32] Today the term republic usually refers to a representative democracy with an elected head of state, such as a president, who serves for a limited term; in contrast to states with a hereditary monarch as a head of state, even if these states also are representative democracies, with an elected or appointed head of government such as a prime minister.[33]
> The Founding Fathers of the United States rarely praised and often criticized democracy, which in their time tended to specifically mean direct democracy;
"it's crazy in modern western democracies most of us spend our lives in command and control dictatorships"
I think you are confusing structure and culture. I've always worked for the past decade under a boss and retained autonomy and spiritual ownership of my work. Yes, a boss can be a micromanaging asshole but going full anarcho-syndicalism usually just means that politics will happen, structures of influence and fealty will form and the end result is still a tree of authority.
I think you are confusing structure and culture. I've always worked for the past decade under a boss and retained autonomy and spiritual ownership of my work. Yes, a boss can be a micromanaging asshole but going full anarcho-syndicalism usually just means that politics will happen, structures of influence and fealty will form and the end result is still a tree of authority.
The problem is you have no - absolutely no - right to influence policy and business decisions; decisions that vastly overwhelm the impact your good or bad coding will have on the value produced by the company.
I had to look up anarcho-syndicalism and no I don't think that's what I mean. I mean democratic participation of the whole company in the decisions affecting the whole company.
Edit: unfair to say no influence. Fair to say no "right" to an influence.
I had to look up anarcho-syndicalism and no I don't think that's what I mean. I mean democratic participation of the whole company in the decisions affecting the whole company.
Edit: unfair to say no influence. Fair to say no "right" to an influence.
I don't think there is any legislation to stop running a company in an inclusive way.
W.L.Gore and Associates of Gore-Tex fame are renowned for their organizational culture, for example (based on what I've read):
https://en.m.wikipedia.org/wiki/W._L._Gore_and_Associates
There are lots of different types of decisions made at companies. For example, Germany mandates a high level of employee influence at companies https://en.m.wikipedia.org/wiki/Codetermination_in_Germany
while remaining typically authoritarian in day to day activities (I've heard).
Non-democratic governance does not mean people could not be encouraged to participate and be creative. The book "Creativity Inc" by Ed Catmull ponders the problems of leadership and management at Pixar (namely, how they attempt to avoid all the stupid mistakes that are obvious in hindsight).
You might be interested int the "seven day weekend" by Ricardo Semler as well.
Human organizations are complex and difficult. I don't think you can legislate the pathologies away unless they are really obvious. But there are several companies already that include workers way better than not.
W.L.Gore and Associates of Gore-Tex fame are renowned for their organizational culture, for example (based on what I've read):
https://en.m.wikipedia.org/wiki/W._L._Gore_and_Associates
There are lots of different types of decisions made at companies. For example, Germany mandates a high level of employee influence at companies https://en.m.wikipedia.org/wiki/Codetermination_in_Germany
while remaining typically authoritarian in day to day activities (I've heard).
Non-democratic governance does not mean people could not be encouraged to participate and be creative. The book "Creativity Inc" by Ed Catmull ponders the problems of leadership and management at Pixar (namely, how they attempt to avoid all the stupid mistakes that are obvious in hindsight).
You might be interested int the "seven day weekend" by Ricardo Semler as well.
Human organizations are complex and difficult. I don't think you can legislate the pathologies away unless they are really obvious. But there are several companies already that include workers way better than not.
It works for Valve, but that's because there are so many good people who really, really want to make computer games. (This is also why game developers tend to be exploited. See the EA litigation.)
It's surprising that it works for Zappos, which is just an online shoe store. Yes, there are people who are fanatical about shoes, but the business of selling and shipping them is not that exciting.
It's surprising that it works for Zappos, which is just an online shoe store. Yes, there are people who are fanatical about shoes, but the business of selling and shipping them is not that exciting.
Does it really? Valve is extremely profitable because of their particular role in the video games industry. But outside of Steam, is the company really a role model for success?
Is Valve's latest "new" IP DOTA2 successful when compared to the other set of MOBAs that have come out over the past few years?
Have Valve's forays into VR and hardware been successful compared to other companies in the space? e.g. the Vive, Oculus?
Looking at Steam itself, has the service dramatically improved since launch? Certainly there have been a lot of good incremental updates, e.g. two-factor auth. But the Apple App Store has seen a lot more updates in terms of search, discoverability, etc.
I am not an expert, and may have my details wrong about Valve. But I don't think the company has been especially successful outside of being the only game in town for buying AAA video games online.
Is Valve's latest "new" IP DOTA2 successful when compared to the other set of MOBAs that have come out over the past few years?
Have Valve's forays into VR and hardware been successful compared to other companies in the space? e.g. the Vive, Oculus?
Looking at Steam itself, has the service dramatically improved since launch? Certainly there have been a lot of good incremental updates, e.g. two-factor auth. But the Apple App Store has seen a lot more updates in terms of search, discoverability, etc.
I am not an expert, and may have my details wrong about Valve. But I don't think the company has been especially successful outside of being the only game in town for buying AAA video games online.
> Looking at Steam itself, has the service dramatically improved since launch? Certainly there have been a lot of good incremental updates, e.g. two-factor auth. But the Apple App Store has seen a lot more updates in terms of search, discoverability, etc.
This may not be your main point, but have you ever used the Steam store? It's the only app store that I've ever encountered that actually gives me valuable suggestions, and thus the only one into which I've sunk a considerable amount of money. (At least 200€, probably more. In second place is Google Play, where I spent some 7 € or so on apps.)
Just look at the huge percentage of games that are only purchased and never played (or even downloaded) to see that Valve has absolutely nailed the Steam store.
Regarding the actual argument: I agree that for a company this large, the turnout in form of actual products (esp. games) from Valve is surprisingly low. But I'm not sure if that's even a bad thing: For some studios, it works well to release 10 mediocre games within a certain amount of time. For other studios, it works better to release only one extraordinary game in the same timespan.
This may not be your main point, but have you ever used the Steam store? It's the only app store that I've ever encountered that actually gives me valuable suggestions, and thus the only one into which I've sunk a considerable amount of money. (At least 200€, probably more. In second place is Google Play, where I spent some 7 € or so on apps.)
Just look at the huge percentage of games that are only purchased and never played (or even downloaded) to see that Valve has absolutely nailed the Steam store.
Regarding the actual argument: I agree that for a company this large, the turnout in form of actual products (esp. games) from Valve is surprisingly low. But I'm not sure if that's even a bad thing: For some studios, it works well to release 10 mediocre games within a certain amount of time. For other studios, it works better to release only one extraordinary game in the same timespan.
I don't think success outside of Steam needs to be considered. Steam is their core business. The software itself is quite bad, but they're the dominant player by far.
Dota 2 I would estimate is #2 behind League of Legends, and it's too early to tell whether VR is working out, but guess which platform VR games are going to be delivered through?
(Besides Steam, their games are pretty successful: Half Life, Team Fortress, Portal, Counter Strike, Left 4 Dead)
Dota 2 I would estimate is #2 behind League of Legends, and it's too early to tell whether VR is working out, but guess which platform VR games are going to be delivered through?
(Besides Steam, their games are pretty successful: Half Life, Team Fortress, Portal, Counter Strike, Left 4 Dead)
Just for some clarification on the VR side, the Vive is a partnership product between them and HTC. Valve did the R&D, and HTC did the manufacturing, adnd Valve helped Oculus get things off the ground as well. I'm not a gamer, so I can't speak to that world, but they are doing truly innovative things in VR.
Would Steam have happened if they had a different management structure?
Perhaps not, but if it didn't it would be because the rest of the org that didn't want to do Steam would have been more empowered to stand up to Gabe, whereas with Valve's flat org, Gabe is God and everyone has to do what he says.
It's probably best for Valve that Steam did happen, but if it's due to Valve's flatness, I would attribute that to the org's inability to resist Gabe rather than any sort of bonus wisdom that arose from that flatness.
It's probably best for Valve that Steam did happen, but if it's due to Valve's flatness, I would attribute that to the org's inability to resist Gabe rather than any sort of bonus wisdom that arose from that flatness.
> It works for Valve, but that's because there are so many good people who really, really want to make computer games
...but there's no one to do good customer service and other boring but necessary things.
Honestly, I don't know what Valve does any more, or if they have to do anything. They can just all take a year-long vacation, schedule some sales, and let people make them money by buying hats, games, or gun skins.
...but there's no one to do good customer service and other boring but necessary things.
Honestly, I don't know what Valve does any more, or if they have to do anything. They can just all take a year-long vacation, schedule some sales, and let people make them money by buying hats, games, or gun skins.
It turns out, depressingly, that good customer service is not correlated with business success in the games industry.
I've experienced first hand why businesses need bureaucracy, because I resisted building one. Turns out it's the same reason cars have 4 wheels. It just works.
Some workers require oversight to be productive, and for some it just helps. This means you get the most out of your work force, and can also hire workers who can't manage themselves. But managers also abstract trust and responsibility from multiple staff to one staff, help organize workflow, and ensure proper communication across teams. It's a simple matter of fact that some work is more fun, some people communicate better, and people don't organize themselves. Add to this the coaching and mentoring factor of a good manager, and it's a no-brainer.
Granted, what most employees fail to understand is if you have a manager, the company has already deemed you need one, and you're practically paying for your own overhead. Good managers are hard to come by, and are expensive. But businesses desperately need good managers because they solve most staffing issues. In other words, if you stop being complacent and just behave like a manager, chances are you will become one.
Here is how it's done: You start by managing yourself and removing your own overhead. Then you start taking care of other responsibilities because you can't help it. Know what needs to get done, understand the big picture, and just help accomplish it from the side. And when you provide relevant insight about how to improve something, put out a fire, or organize a project, you're already manager material. Your goal is to replace your manager without actually replacing him, without being the boss, without pissing anyone off, and without higher pay. You just made your bosses job easier, increased the value of everyone else, and ensured work got done. If your company doesn't give you a raise, you're at the wrong company.
Here is how it isn't done: You keep relying on your manager to keep you in check. You only accomplish your minimum requirements. You blame training for not being able to do anything else. You feel entitled for a raise just by being there for a long time.
Both of the above are exaggerated to emphasize two opposites, but most people are somewhere in between. Of course, if you're not manager material and you suck at your job, the likelihood is you will get fired, so it's perfectly okay to be complacent and just do good work. But the point is, you have your manager to thank for your straight forward and fairly comfortable job, and at the end of the day, his/her salary is practically coming out of yours.
Some workers require oversight to be productive, and for some it just helps. This means you get the most out of your work force, and can also hire workers who can't manage themselves. But managers also abstract trust and responsibility from multiple staff to one staff, help organize workflow, and ensure proper communication across teams. It's a simple matter of fact that some work is more fun, some people communicate better, and people don't organize themselves. Add to this the coaching and mentoring factor of a good manager, and it's a no-brainer.
Granted, what most employees fail to understand is if you have a manager, the company has already deemed you need one, and you're practically paying for your own overhead. Good managers are hard to come by, and are expensive. But businesses desperately need good managers because they solve most staffing issues. In other words, if you stop being complacent and just behave like a manager, chances are you will become one.
Here is how it's done: You start by managing yourself and removing your own overhead. Then you start taking care of other responsibilities because you can't help it. Know what needs to get done, understand the big picture, and just help accomplish it from the side. And when you provide relevant insight about how to improve something, put out a fire, or organize a project, you're already manager material. Your goal is to replace your manager without actually replacing him, without being the boss, without pissing anyone off, and without higher pay. You just made your bosses job easier, increased the value of everyone else, and ensured work got done. If your company doesn't give you a raise, you're at the wrong company.
Here is how it isn't done: You keep relying on your manager to keep you in check. You only accomplish your minimum requirements. You blame training for not being able to do anything else. You feel entitled for a raise just by being there for a long time.
Both of the above are exaggerated to emphasize two opposites, but most people are somewhere in between. Of course, if you're not manager material and you suck at your job, the likelihood is you will get fired, so it's perfectly okay to be complacent and just do good work. But the point is, you have your manager to thank for your straight forward and fairly comfortable job, and at the end of the day, his/her salary is practically coming out of yours.
What if you're looking for autonomy without becoming a manager?
You're a great worker. If you're autonomous, you're already good at managing yourself and your own work, so you're half way there. You're the person that would be high on the list of potential recruits for managerial positions if there was a shortage in your company. And you'd have to turn them down to maintain your non-managerial status and lower payroll.
If you have a group of people that can manage themselves, you have a group of potential managers. In other words, they're worth more than people who can't manage themselves, and the likelihood of them doing simpler tasks that can be done with someone more cost effective is greater. Meaning, unless you're allergic to non-autonomous people, it becomes a good business decision to just start managing some helpers instead of forcing everyone to help themselves. The quintessential helper is "the intern" (and they may be grooming you for a managerial role if they put you in charge of one).
Also, if you're an entrepreneur you're a manager. If you can't manage people, you have no business trying to build a business.
It's also worth noting public education systems do not produce managers. The teacher-student dynamic is similar to the manager-worker dynamic. They don't teach you in school that you could learn whatever you want on your own and that the teacher is mostly there just to make sure you get your work done. It's pretty much the same with managers.
If you have a group of people that can manage themselves, you have a group of potential managers. In other words, they're worth more than people who can't manage themselves, and the likelihood of them doing simpler tasks that can be done with someone more cost effective is greater. Meaning, unless you're allergic to non-autonomous people, it becomes a good business decision to just start managing some helpers instead of forcing everyone to help themselves. The quintessential helper is "the intern" (and they may be grooming you for a managerial role if they put you in charge of one).
Also, if you're an entrepreneur you're a manager. If you can't manage people, you have no business trying to build a business.
It's also worth noting public education systems do not produce managers. The teacher-student dynamic is similar to the manager-worker dynamic. They don't teach you in school that you could learn whatever you want on your own and that the teacher is mostly there just to make sure you get your work done. It's pretty much the same with managers.
When I worked at Bell-Northern Research (and Nortel) they had two tracks for advancement. One was the managerial track where you were promoted from a technical staff to a manager, the other was the independent technical adviser. If you did the latter, you basically became a manager without any staff and you worked with the managers at your level to direct the products. There weren't many in my division, but there were some. I was unofficially one because my department manager left (after the rest of the members left) so I reported directly to the manager the next level up and sat in on the department managers' meetings.
Thanks for the response -- interesting stuff.
But any thoughts on what to do in the "allergic to non-autonomous people" situation?
But any thoughts on what to do in the "allergic to non-autonomous people" situation?
If you're just describing people who can't or won't think for themselves (or have very poor judgement when they do), your options are (a) work alone or with a small group of people you respect, (b) work for a company with high standards for hiring (no place is perfect, but some are better than others), (c) learn how to constructively work with people you consider lesser mortals while hiding your contempt, or (d) don't put people into made-up buckets and learn how to make the best of whatever situation you find yourself in. (d) is by far the most challenging, and by far the most rewarding, because what you're capable of won't forever be circumscribed by preconceived notions about people, who can be quite surprising in unexpectedly positive and negative ways.
Just to add, regarding (d), buckets will make themselves based on work, and people will make buckets for themselves based on who they are. So you want these buckets to match. Except, as a manager or an employer, you really have little control over either. If marketing needs to get done, that's a predetermined bucket. If someone loves marketing, that's their predestined bucket. But 1 to 1 matches are rare. If your business is growing, work buckets constantly change. And if you're a person, you constantly change. And then there are offices that are still trying to figure out the proper buckets, as well as the people who are still trying to figure out their passion. So it's a clusterfuck and there is always collateral damage. But you want to be working for someone who's at least trying to get it right, and usually if you can talk to that person, they'll appreciate your feedback. The key is for both sides to be flexible enough to get all the work done without making anyone too unhappy. Of course, businesses can't sacrifice work, so people end up sacrificing happiness, but for the most part, a business that fails to keep their employees happy is either a failing business or a bad business (and as an employee you should look elsewhere).
Start your own business?
You describe a consistent viewpoint, but of rather ideal workplace situation. In reality, instances of "your manager" go from "you have your manager to thank for mentoring and advice" to "he is constantly pushing you around and making threats for no justifiable reason, bringing zero value to your work". Unfortunately, there are managers who do not know how to communicate and do not know how to be a good leader.
Yes, of course there are managers that suck. After all it's just another job. There are companies that suck. Some are big enough to not have to care or notice undervalued talent. If you're talented, you don't want to be there.
But I think it's safe to say, if you're good enough to manage people, you have a job in America. Businesses lust for good managers. It's the only way to ensure work gets done with affordable labor, and many businesses can only afford affordable labor.
But I think it's safe to say, if you're good enough to manage people, you have a job in America. Businesses lust for good managers. It's the only way to ensure work gets done with affordable labor, and many businesses can only afford affordable labor.
> Your goal is to replace your manager ... without higher pay.
Sounds like you have the wrong job then.
Sounds like you have the wrong job then.
Exactamundo. And if you're at a decent company, your manager's job entails promoting staff and recruiting managers. Maybe you'll even physically replace your manager so they can move on up.
Managers are in the meetings where they talk about other managers that suck or other departments that need more help. The whole point is to look out of place. And if they don't appreciate you, you need to take your value proposition elsewhere. And if you look out of place by sucking, you'll get fired.
Managers are in the meetings where they talk about other managers that suck or other departments that need more help. The whole point is to look out of place. And if they don't appreciate you, you need to take your value proposition elsewhere. And if you look out of place by sucking, you'll get fired.
> If your company doesn't give you a raise, you're at the wrong company.
Sounds like if you'd managed to keep reading, you'd agree with the poster.
Sounds like if you'd managed to keep reading, you'd agree with the poster.
I struggle to understand how flat org structures work... In my experience, a hierarchy of power is essential. I've seen problems at organizations which lacked clear title differences between engineers with different experience. This meant junior engineers felt just as authoritative as senior engineers, despite those junior engineers often being very wrong.
The end result was unhappiness, and contention between coworkers. The senior engineers felt unappreciated and unrecognized, and the junior engineers felt the brunt of that resentment.
Based on that experience, I tend to believe that organizations should have clear power lines (titles), and respect those titles. Doesn't mean you need to have a dictatorship, but someone needs to be able to make a strong decision that sticks, when the time calls for it.
The end result was unhappiness, and contention between coworkers. The senior engineers felt unappreciated and unrecognized, and the junior engineers felt the brunt of that resentment.
Based on that experience, I tend to believe that organizations should have clear power lines (titles), and respect those titles. Doesn't mean you need to have a dictatorship, but someone needs to be able to make a strong decision that sticks, when the time calls for it.
The case of the crash of United Flight 173[1] is quite an extreme but still a relevant one on why seniority (in terms of title or work experience) shouldn't be the sole driving factor of decision making. Yes, junior engineers can be wrong but shutting them out by defining a hierarchy leads to multiple issues - a) they don't learn and b) senior engineers don't benefit from useful and creative ideas. A hierarchical top-down org usually forces the people at the bottom to just follow the instructions. The better option is not hierarchy but leadership. There should be somebody in charge of the project and they should be able to take the final call when there is a contention. Yes, some wrong decisions would be made but that's what learning is all about.
[1] https://en.wikipedia.org/wiki/United_Airlines_Flight_173
[1] https://en.wikipedia.org/wiki/United_Airlines_Flight_173
Totally agree.
While I believe clear power lines, and titles, are important for business function, they should not come at the cost of respect, or a democratic environment which promotes conversation and compromise. You can definitely have both; Not all rigid org structures are authoritarian.
"Yes, some wrong decisions would be made but that's what learning is all about."
The problem I've seen is that unless an engineer sees his peer as having more experience (visa vi the title), then they often won't even give them the time of day. Even if their peer is 100% right, the junior engineer often believes themself right and is unwilling to budge. While the reverse can definitely happen, its generally less common.
While I believe clear power lines, and titles, are important for business function, they should not come at the cost of respect, or a democratic environment which promotes conversation and compromise. You can definitely have both; Not all rigid org structures are authoritarian.
"Yes, some wrong decisions would be made but that's what learning is all about."
The problem I've seen is that unless an engineer sees his peer as having more experience (visa vi the title), then they often won't even give them the time of day. Even if their peer is 100% right, the junior engineer often believes themself right and is unwilling to budge. While the reverse can definitely happen, its generally less common.
> unwilling to budge
I respect explanations, not assertions, nor titles. Maybe that's why I have trouble with large companies.
I respect explanations, not assertions, nor titles. Maybe that's why I have trouble with large companies.
Explicit hierarchy is useful to break ties. Not all questions have a universally compelling answer. There are often two or more competing "explanations" that are all sensible. Having nobody with the authority to make the final call often leads to uncertainty and endless bikeshedding.
In which case I expect the other person to agree that both options are equally valid and it's appropriate to choose randomly.
I think randomness is often underappreciated in business decisions. It helps create a baseline for performance measurement.
I think randomness is often underappreciated in business decisions. It helps create a baseline for performance measurement.
And I expect to have an experienced person in authority make the decision based on their "intuition", which just means the part of their accumulated experience that is difficult to formulate into an externally compelling argument.
This is actually a pretty good example of the phenomenon - if you and I were on a team and trying to figure out how to make decisions for our team, we would have this strong disagreement about whether it's better to break ties through intuition of randomness. My intuition is that intuition is better, and your intuition is that randomness is better. It's unlikely I can convince you that I'm right, or vice versa, so how should we break that tie?
This is actually a pretty good example of the phenomenon - if you and I were on a team and trying to figure out how to make decisions for our team, we would have this strong disagreement about whether it's better to break ties through intuition of randomness. My intuition is that intuition is better, and your intuition is that randomness is better. It's unlikely I can convince you that I'm right, or vice versa, so how should we break that tie?
One of the problem is when the difference between technical leadership and management is not recognized. While titles can help, without a clear technical leader on top of that they are clearly not enough. And, most importantly, the titles must be in phase with the actual capabilities of people. Otherwise it is far worse than no title. And obviously, a good technical hierarchy can be quite hard to bootstrap in an organization where the culture was officially flat.
Part of the problem is the way you stated it - a hierarchy of 'power'.
If you focus on a hierarchy of 'ownership' instead, it's much better for everyone.
There's a fantastic book (Extreme Ownership) that talks about how this is used within the US Navy Seals, and how it empowers the people doing the job, rather than dictating what they should do.
Decisions do need to be taken with regards to direction - they shouldn't necessarily enforce 'how' that direction should be achieved.
If you focus on a hierarchy of 'ownership' instead, it's much better for everyone.
There's a fantastic book (Extreme Ownership) that talks about how this is used within the US Navy Seals, and how it empowers the people doing the job, rather than dictating what they should do.
Decisions do need to be taken with regards to direction - they shouldn't necessarily enforce 'how' that direction should be achieved.
> GitHub is taking on increasingly ambitious tasks, such as organizing a two-day developer conference on Sept. 14 in San Francisco that’s expected to attract 1,500 attendees.
This can't be serious...
This can't be serious...
What do you mean?
The key is that every task must have EXACTLY ONE BOSS whose say is final when a decision is necessary.
A hierarchy works fine if it really is a hierarchy. It won’t work if the hierarchy has been poisoned with “dotted lines” or lots of unnecessarily-senior-sounding job titles that let senior people share control over project direction. I’ve worked in groups in the past where there were like 5 senior people trying to pull things in completely different directions, no one would tell us whose opinion really mattered, and we kept having to decide for ourselves.
A hierarchy works fine if it really is a hierarchy. It won’t work if the hierarchy has been poisoned with “dotted lines” or lots of unnecessarily-senior-sounding job titles that let senior people share control over project direction. I’ve worked in groups in the past where there were like 5 senior people trying to pull things in completely different directions, no one would tell us whose opinion really mattered, and we kept having to decide for ourselves.
Eh. At every large company I've worked in or with, even if there's officially one boss, the reality is it's a committee. Worse, when in the middle of a big organization, you're never really sure who has authority. Someone lower on the org chart might call their friend who is an SVP from some other branch of the company, they fly in to have their say... it's all politics, no matter what the org chart says.
Yep. A company shouldn't be Congress.
Depending on the business, there is usually a requirement for a coordination role. Whoever that coordinator is needs to have the authority to make a final decision in order to be effective.
If companies want to avoid tyranny in the workplace then perhaps it would be better to have bosses but allow a majority vote of direct reports to fire them. Give 360 reviews some actual teeth.
If companies want to avoid tyranny in the workplace then perhaps it would be better to have bosses but allow a majority vote of direct reports to fire them. Give 360 reviews some actual teeth.
One of the ways I see manager's having a very positive impact on a product is by managing the (sometimes) competing interest of users versus engineers.
As engineers, we can sometimes become obsessed with updates/refactors/optimizations that have zero meaningful impact on the user experience. A user doesn't care about your cobwebs and dirty laundry, but as an engineer it's so hard not to obsess over these optimizations. It's so easy to forget that users don't care about the same things as you.
At the same time it's maddening when you feel like you're working with a house of cards and your manager asks for a third story.
I see a lot of conflict here, and this imho is what separates good technical managers from bad ones. They understand the competing interests and are able to prioritize work in a way that works best for everyone.
As engineers, we can sometimes become obsessed with updates/refactors/optimizations that have zero meaningful impact on the user experience. A user doesn't care about your cobwebs and dirty laundry, but as an engineer it's so hard not to obsess over these optimizations. It's so easy to forget that users don't care about the same things as you.
At the same time it's maddening when you feel like you're working with a house of cards and your manager asks for a third story.
I see a lot of conflict here, and this imho is what separates good technical managers from bad ones. They understand the competing interests and are able to prioritize work in a way that works best for everyone.
> that have zero meaningful impact on the user experience.
The reason I want to refactor is to make the code easier to read and maintain and more likely to be bug free. It doesn't have any meaningful impact on the user experience, but it is making the software a lot better and keeps running costs lower and allows new features to be added more easily.
The reason I want to refactor is to make the code easier to read and maintain and more likely to be bug free. It doesn't have any meaningful impact on the user experience, but it is making the software a lot better and keeps running costs lower and allows new features to be added more easily.
And yet during the flat org structure time period Github was an innovation BEAST. It was one of the most creative technology companies I've ever seen and changed the way we do development. Since more structure has been put in place, innovation seems to have come to a screeching halt. The product feels old, new features are hard to come by, bloat and cruft are everywhere. Maybe they hired too many people for the job at hand?
I think you'll find the slowed pace happened a good deal before the managers came in if you look at the history more closely.
Instead they periodically elect a body of 20 (or so) partner to deal with compensation, bad partners, sets policies, etc, etc.
My buddy says that all the partner are fairly self-driven grown ups, and usually do the right thing. Rarely is there any action needs to be taken by that elected body.
They do have a "CEO" in name to represent the firm to the outside, but with no other powers otherwise. And obviously you need some HR department.
Immediately I wondered whether one could run a software company like that.
Seems that GitHub drove it a little too far on the no-structure route. I wonder if they could have done what this firm does.