Hacker News new | comments | ask | show | jobs | submit login
Engineering management is dying (deathrayresearch.tumblr.com)
111 points by ljw1001 on July 8, 2012 | hide | past | web | favorite | 53 comments

My best managers couldn't do the engineering work I do. Likewise, I can't do their work (I've tried management, it sucked for me, I won't try it again).

My current boss [and one of the best I've had, btw] puts it thusly: "You solve problems with designs and lines of code. I solve problems by putting the right people in the right places." It's an over-simplification of both sides, but it contains a lot of the truth.

Trouble starts when managers (who should be doing people-level stuff) get their mitts into technical stuff, especially when they start "laying down the law" without proper background. That's when they grow pointy hair on their heads, that's when the "send me weekly status report email" requests start, these days it's usually when the "Agile" drums start beating, and it's when I start looking for a new position.

In a software company with under 50 employees you can get away with almost anything.

With over 50 employees the only model that ever worked is the one described by http://manager-tools.com/ :

- Between 8 to 12 direct reports/manager, never more than 12.

- Weekly 1-on-1 with EVERY direct report, never missed.

There's a way to flatten the structure somewhat with Team Leads managing up to 6 people: part development, part people management. Even then the Engineering Manager has to be hands-on.

This is how people work and it will not change anytime soon. Everybody needs weekly check-in with the company (represented by the manager) to stay in course. And everybody needs to know "who's the boss", even it it's not an official title or formal authority (think about Linus).

Citing Google as a good example is not too inspired. With all the billion $s they can't come up with one more product - it's still a single trick pony. There's Search/AdWords, everything else is pretty much failure in comparison. Maps is somewhat profitable, but it was bought from somebody else and it's pocket change next to Search. Everybody profits from Android, except Google. And then there's Google+, Wave, Health, Video, Buzz, Catalog, Froogle, Orkut, ...

So before trying out a Google-style manager-less chaos, make sure you have a couple billion $ in your bank account first.

And yes, when somebody is not calling the shots on who gets hired in his/her team, that's not a manager. They get the task (deliver the results) without getting the tools (pick your team). How that would ever work?

    This is how people work and it will not change anytime soon. Everybody needs weekly check-in with the company (represented by the manager) to stay in course.
I call bullshit. I have over a decade of experience in this industry and have only had regular 1-on-1s with my managers over the last year. Despite this, I've always been a highly valued contributor to the companies I've worked for. If anything, the last year has been the worst / most-dysfunctional of my career (although, this is probably not related to having 1-on-1s, but rather unrelated organization chaos). I have always talked regularly (i.e. daily) with my manager, but formal 1-on-1s were never part of the equation.

"We see each other every day" does not qualify.

1-on-1 is a very specific, regular and dedicated meeting. This is where you check-in, coach, encourage new ideas, listen to pain points.

It's number 1 requirement even at Google: http://solutionfocusedchange.blogspot.com/2011/03/googles-pr...

I suggest listening a couple Manager-Tools.com podcasts about 1-on-1. You need more than one person's experience, even if it's for a decade.

At Google managers don't decide who gets hired, but they do (more or less) get to choose which of the hired people end up on their team. I think it works pretty well actually.

And they deliver viable products... more or less. :)

I'm genuinely surprised that the word accountant or the world lawyer haven't been mentioned in this discussion. From my perspective the issue isn't that engineering management has issues, it's just that mostly the management that is done is done by people with MBA's and law degrees rather than Ph.D's and Engineering degrees.

The structures of modern companies arise from this - lawyers and accountants have no interest in the groups they manage, because they see them as generic interchangeable machines, rather than levers that they are developing to create and make things. They seek to optimize them, rather than nurture them, and then they seek to leave and do it again. A true engineer would want to build something of value and then use it and use it again.

Most engineers opt out, the good fight is not fought, so - management is as it is.

Good riddance. There is nothing essential to the role managers fill that couldn't be done by someone without authority over you. That doesn't necessarily mean removing all managers, it just means not making them your boss.

Valve is proof that a flat structure can not just work, but lead to massive financial, critical, and popular success. It's also probably one of the only companies that I would be fulfilled working at that wasn't my own. There's no one to hold you back. I think the startup-minded hackers on this site can relate to that.

> There is nothing essential to the role managers fill that couldn't be done by someone without authority over you.

Bosses can break ties without anybody being too pissed off that their pet idea lost the contest. Bosses can see the approaching ravine and order peolle to build a bridge before the rest of the team gets there.

Valve is a poor example. Mr. Market only cares that their products are fun or interesting. Valve products don't have to conform to MIL-STD-2341 section 243 subsection 12, and be validated according to ANSI 228.3.

Why is there a contest? If someone has an idea let them branch the code and implement it. The company can then decide which of the two branches to use and the developers will work harder to win. The real problem is this system is not compatible with the jobs of non-engineering managers. What are they supposed to do in a free market system where developers are making decisions? For their jobs to be viable, an authoritarian system has to be set up. One developer has to be told 'don't do that, we're going with Bob's way.' That's not an environment for innovation. All this accomplishes is now a highly paid developer has no reason to work hard at all, and they sure as hell don't give a shit about Bob's stupid ideas.

As for bosses building a bridge, its ALWAYS going to be "why the hell didn't you engineers know about or implement MIL-STD-2341" not "here's your MIL-STD-2341 reference books and a few contacts for you to get started."

> If someone has an idea let them branch the code and implement it.

Branch the code and implement it? What if idea #1 is to add CRM and idea #2 is add interactive business scenario projection?

Many ideas are too big to implement just for the hell of it. And voting for it is no good, because most of the voters have no idea what the hell they are voting for. Somebody has to take responsibility for doing the deep analysis and making the decision. That's called management.

Unfortunately, my experience is more that the upper level bosses tell people to build a bridge and by the time it gets down to the floor the orders are quite different.

If Valve is a poor example, what about WL Gore with their 9000 employees and $3 billion in annual revenue?

Valve products have to meet all kinds of legal requirements and pass console certification. And Steam has to not lose your payment info.

and they've been successful thus far compared to Sony who probably have boatloads of traditional managers

Engineering managment fall into 10 differnt types of managment. Those that know binary and those that do not.

Sadly it is extremly rare to find a manager who cant do 1/10th of your job and is actualy any good.

If you advanced up the ranks then you know what to expect, when to expect it and how to deal with your staff, you learn how to deal with HR and the other boring stuff. If you are a manager and have never done the job of the people who you are managing then you know HR and the boring stuff realy well, but can so easily fail to support your staff fully. It's not realy even a fine balance, understanding what your staff do is extreemly important and at least to some degree a manager should know how to at least do aspects of there staffs job, to not know is a situation were you let your staff down or alows them to abuse you by saying it will take longer than it actualy does take. You then have those staff who are good at doing there work on email as apposed to actualy doing the work.

So is Engineering managment dieing - has been for many years now but not for the reasons you outlined. I suspect that during the late 80's some marketing types migrated to IT managment and the rest is history.

I think there's something else interesting here in the relationship between engineering managers and project managers. The author writes: "It's been undone by a continuing erosion of responsibility accorded to managers."

We have introduced specialists of various sorts, with varying titles: project manager, program manager, product manager, technical project manager. The introduction of non-managerial technical-track engineering leadership roles for those smart engineers who either can't or won't be good managers has further splintered off the value-add of the engineering manager.

In between team leads and C-staff there are N levels of people who's job has been highly eroded and who struggle hard to add value to their teams.

I am really interested to see where this is going.

I don't think those roles are diminishing the value of engineering managers, although I think they are useless as engineering leaders. I think engineering managers are diminishing the role of engineering managers.

Many, many engineering managers are the people who got into technology with the goal of being a manager. As such, they did the minimum amount of actual engineering they could get away with, say 1-2 years. They are motivated only by the fact that engineering management is one of the highest paid professions out there. Linkedin shows some extraordinary insight into this phenomenon as anyone with a few connections can review thousands of resumes. There are managers, directors, VPs, and CTOs who have almost zero actual experience in the technical field they are supposed to be managing. For whatever extremely messed up reason, the tech industry actually supports this.

So you get a whole industry of engineering managers who are not and never were engineers. It's no surprise that their role is the same as a project manager. That's all they can do. They can't steer the technical focus of the group, lead the team towards innovative ideas, or anything that even requires basic technical knowledge. If there's anything eroding the responsibilities of engineering management its the constant dumbing down of the job by the non-technical money chasers trying to get into the job.

Thanks, author, for the drip of your contribution to the ocean of everything-has-to-die-for-linkbait.


Not sure how many people here have managed people before, or at least have first hand experience in a company that has 1) too many managers, 2) too few managers.

I have experience of both. I ran a Microsoft practice at EDS, where there were too many managers. The highlight of that one was losing a multi-million £ contract because another project manager felt my approach didn't produce enough paper work, stopped the project and started gathering requirements, again, formally.

After that I worked for a smaller software house I'd better not name, where I was responsible for 70 developers. I had no idea who was working on what because no one ever did what the status reports suggested. I resigned.

The frustration in both cases was that engineering management has been solved. It's been solved in the 80's. Any attempt these days to introduce principles I learnt from books like Wicked Problems, Righteous Solutions, Peopleware or Mythical Man Month got rejected, because most organisations these days have a chosen way of doing things that some manager thinks of as a personal fiefdom. Any attempt to stray from the defined approach is squashed, like, immediately.

How about the companies that have too many "managers" and not enough managers. I've experienced that as well.

I guess those are usually called 'stakeholders' instead of 'managers'. Yes, they will try to assert their own little asses over you to show they are somebody. Painful, but it is part of work life. [shrug]

The salient point is flatter organizations along with the feedback loops that surround developers has changed the role an engineering manager plays. Drucker was correct (as usual) about the knowledge worker's primacy in the modern organization.

Besides working with engineers to define the technical direction of our products, my job as an software development manager includes things like: sourcing/hiring, long range planning (including owning P&L for my team), customer engagement, and helping to grow the careers of my engineers (among a million other things). I'm not really clear on how agile or outsourcing make any of these things irrelevant. If the point of the article is that "non technical engineering management is dying" then I think I mostly agree, but the title is misleading.

Someone made an excellent point on the blog site that one of the key drivers for a trend towards fewer engineering managers is that engineering management is getting simpler with, in his words:

"the rapid the maturation of "infrastructure as code" tools and methodologies, all the *aaS magic that's out in the world right now, the "App Store" ecosystems, etc. With a small team, you can do seriously global-scale things. "

You can get lot more done now with fewer people and less complexity, which means less management needed.

> the widespread acceptance of Agile

somewhere in a parallel universe.

I think the author understands the depth of this acceptance of Agile when he writes:

'Today they’re surrounded a vast army of scrum-masters and evangelists, recycling (competently, mostly) the same insights, and an even larger crowd performing half-assed renditions of steps learned by rote: “Yeah, we do agile. We have a standup every day.” Many of these renditions have the professionalism, but not the passion, of a small-town talent show.'

Which may be my favorite bit in the article.

"200-person projects headed by an Engineer"

If you have 200-person projects and still call them projects, you're doing it wrong.

I disagree that it's "dying". People management is important, and although bad managers deserve all the scorn heaped upon them, we actually would do better if there were more managers.

The "flat" organizational model seems like a good thing, until you realize that what it actually means is that there's a high managerial branching factor-- sometimes 25 or higher-- which spreads managers way too thin. The problem is that this is unstable. Any manager with 25 reports is not going to be able to be fair. A subset of these reports (let's say 4-5) is going to win the boss's favor. They become de facto bosses off the other 20, but are also direct competitors with them. Now you have all the disadvantages of a 5-tree (instead of 25) but none of the advantages.

Most "flat" organizations aren't egalitarian-- just lazy when it comes to figuring out a structure. Instead, they've traded official organizational hierarchy for unofficial, unstable arrangements that are actually more problematic. In a stable arrangement, your boss is your boss and you are not his competition. In an unstable and informal environment, these "de facto" bosses are also direct competition. That never works well.

People management is still necessary, and good people management is extremely valuable (and, sadly, somewhat rare in many organizations). At one time, I thought otherwise, and that it was the engineers only who actually mattered to the health of an organization, but I was wrong.

What has proven ineffective and wrong is the world in which people managers were given prima facie higher status, creating organizations in which the only way to progress is to move into a management role. That proved not to work, and it does seem to be on its way out.

Intersting. I'd like to see how you'd contrast it with Github's Ryan Tomayko's style: http://tomayko.com/writings/management-style

> People management is still necessary, and good people management is extremely valuable

People management is necessary to mitigate the corrosive affects of the one or two bad people in the group. Valve's idea is to recruit only good people.

People management is necessary to mitigate the corrosive affects of the one or two bad people in the group.

Communication problems don't require "bad people", though. Sometimes you have good people who just don't work well together, or who could be assets to the company but aren't communicating well. These things become common at scale. I actually find "performance" rhetoric to be insulting and imbecilic, so I think it's better to discuss impact... but if you have 100 good people, at least a couple are going to fall below an acceptable level of impact, even if they're capable people working hard and in good faith.

This is one of the problems with typical HR mediation practices. In most companies, HR is worthless. That comes from the implicit assumption that one party or the other is "bad people" and that they have to assign fault: if an employee gets a bad review, for example, they have to conclude either (a) that the manager gave an unfair review, making him look bad at this job, or (b) that the employee actually sucks. There's no alternative. This rarely works well, because unless there is a legal reason (e.g. a sexual harassment complication) that impels them to side with the employee, they'll side with the manager every time.

This is one of the biggest problems with performance reviews. They force the manager to take a definitive stance on each employee, and because to disagree with a review is openly to call that manager incompetent, people are afraid to do so even when, by rights, they should.

> Sometimes you have good people who just don't work well together,

I get the strong impression from Valve's handbook that being a good person is defined as working well together. The idea that social incompetence is okay as long as a person can do good work may actually be harmful to company productivity, in their view. Of course, this could just be a conspiracy to put all the Aspergers out of work.

First my business is looking at a flat model. We have a very specific approach in mind.

>The "flat" organizational model seems like a good thing, until you realize that what it actually means is that there's a high managerial branching factor-- sometimes 25 or higher-- which spreads managers way too thin.

In most cases the goal is to get rid of management altogether, and distribute management functions to the teams themselves. You are assuming a direct command and control structure, a flat organization that works is something a little different. I will talk about this below.

>Most "flat" organizations aren't egalitarian-- just lazy when it comes to figuring out a structure.

100% correct there, but wrong when you say:

>Instead, they've traded official organizational hierarchy for unofficial, unstable arrangements that are actually more problematic. In a stable arrangement, your boss is your boss and you are not his competition. In an unstable and informal environment, these "de facto" bosses are also direct competition. That never works well.

Again, this entirely suggests an idea of command and control rather than something else.....

> People management is still necessary, and good people management is extremely valuable (and, sadly, somewhat rare in many organizations). At one time, I thought otherwise, and that it was the engineers only who actually mattered to the health of an organization, but I was wrong.

The problem is though that managers inherently filter communication and this leads to high costs as well. Again, if you want to make sure that specific things get done with appropriate accountability then you want to have this structure, but it isn't the only option.

You are probably wondering by now what the alternative is. The alternative is to have a company based on openness, collaboration, communication, collegiality, and entrepreneurship. This sort of culture is very hard to build and maintain. It means that the executives have to cultivate a well-earned reputation of listening to the folks on the job floor, mentoring them, and only taking action when necessary.

We aren't talking egalitarian here. Rather leadership is distributed and people can lead --- or follow --- based on their ability to convince other people that given approaches are good for the company.

The way we run the LedgerSMB (http://www.ledgersmb.org) development community is as follows:

1) There is a core committee of three of us, though one is pretty in-active and may not last so much longer. we have the power to ban people, but mostly we just help out folks, do development, and so forth. We are the primary developers in addition to managing the community.

2) Everyone else can contribute but is expected to collaborate on their contributions with the rest of the community. Then they can find a committer to commit. Committers are expected to mentor non-committers.

I think this can work as a business management structure. You can have executives who handle planning, organizational goals, etc. But they do this in collaboration with others in the company in whatever position want to be involved.

The big limiting factor though is this. If the executives can't get a well-earned reputation for openness, the whole thing falls apart and you have to go to a de facto or official command and control structure.

Like michaelochurch, I think this is interesting and hope it works out. That said, my immediate thought is "what does it take to become one of those core committee members?"

Read into that what you will ;-)

The other part I think worth a cautionary mention is that you appear to use the words management and leadership as though they are the same. They are not. It's a cliché, but it describes the difference well -

If there's a team of people clearing a path through the jungle with machetes, the manager's job is to make sure the machetes are sharp, the workers have enough water, and generally that they keep clearing a path.

The leader however, climbs a tree and looks around to make sure the jungle is being cleared in the right place.

Lastly, you speak of accountability. And yet you do not mention authority. The one cannot exist without the other. I've had accountability in every single management role I've had and never the authority to run the team or project as I saw fit. There's an imbalance there that has always spelt epic fail.

Well, in the community basically it is weighted towards early contributions (duh) but typically it is people who countribute well to the project in all levels. The core committee has never had more than six people in it, and currently is down to three. There have been some political issues that have come up with some nominees unfortunately so I won't say the process works perfectly.

However those who contribute well tend to get commit privileges and those who contribute to strategy beyond code have tended to become core members most of the time.

Also regarding management and leadership.... Management is typically a command and control structure for the leaders. If you have a flat model, leadership becomes something different because you lack that command and control structure, and so does management. Someone gets to make sure the machetes are sharp. Maybe someone else is in charge of water....

But yeah good thoughts.

BTW, I don't think flat orgs work everywhere. The companies that seem to be successful are those with a very narrow focus, like Github (building things around Git) and WL Gore, which builds things out of one, very specialized, form of plastic. Flat orgs scale up to any number of employees, but they don't scale up to large numbers of goals. I can't imagine how you'd have a flat org structure at Microsoft. Well I can, but it wouldn't be all that flat and it certainly wouldn't be a single org....

I like the clear distinctions you've set between a manager and leader (very well written).

I'd like to push this further and claim that a manager in a company has two roles: one that fulfills the business needs of the company (keeping the machetes sharp), and the other to have vision and lead the people (climbing the tree). A good manager has to also be a good leader. The converse isn't always true, and I've seen many "good" managers (from a business sense) get resented by the people by the people they're supposed to manage.

The problem with a structure like that--or rather, a lack of structure like that--is the risk of it degrading into politics. It's just like in society--a more democratic system increases the amount of political friction in the system, but a more authoritarian structure increases risk (but potentially reward as well) by betting more heavily on the judgment of the authority figures.

Certainly there are politics. That's always a problem in any organization. The question is how you manage that and a lot of it has to do with cultivating the company in certain directions.

The larger issue though I think has to do with goals. It is one thing to be a 9000 employee business making things out of one kind of plastic (WL Gore) without management per se. It would be a very different thing to be a general IT development firm with 200 employees, fingers in 20 different markets and no management. People aren't coming together to do one thing. The field for problems is much increased.

The second point I would make is that of support.

The goal of a bossless organization is to have an organic organization where employees are well supported. The alternative is to have a command and control organization where employees are well ordered. Employee support is crucial.

Not to say there aren't problems. The primary ones that I have seen over and over in looking into this is:

1) How do you know if you need to hire? (We have an answer for this btw)

2) Keeping goals focused and the organization focused on the goals.

3) Ensuring quality and timely communication.

The third can be greatly assisted with technology, the other two need to be handled by real leadership.

Every organization has politics. The question is how you cultivate good vs bad politics.

This is really interesting. I hope it works out well for you.

I think the challenge that most human organizations fail to overcome is how to prevent necessary conceptual and operational hierarchies from becoming a(n often counterproductive) social hierarchy. It's social hierarchy (and the abuses thereof) that make most companies such bad places to work.

One thing we have going for us is we will probably be hiring older programmers who have been self-employed. Our area is not really suitable for young hot-shot developers and so we can pick up a bit of a non-traditional advantage here.

Very flat structures work better in some places than others, and no approach is perfect for every situation. I've seen situations where engineers take the lead very successfully and some situations where more management has helped, but overall I think the long-term trend is toward fewer managers.

you say you disagree, but then confirm what the original post said.

it wasn't arguing that managers were not useful. it was saying they are decreasing in number.

Good point. I guess I agree with the OP. I disagree that it deserves to die, or that it's a good thing that it's dying.

For an example, Google has a supposedly "lightweight" system that, in practice, works quite poorly. A more traditional management structure, at a place like Google, would be an improvement. (I have no idea how Github and Valve work. Their structures might work extremely well.)

On Github, here's an article by Ryan Tomayko, the director of engineering: http://tomayko.com/writings/management-style


I don't believe Google's system works poorly. Any organization of that size will have some successes and some failures, but there is a hell of a lot of great software produced there.

One of Google's great strengths is that it was founded by engineers, and the engineering DNA is strong in the company. Google has cultural problems as any large company will, but they're fundamentally different (and less damaging to a technical firm) than the kind that MBA-culture creates. You could take 10 random Googlers and ask them to do a startup and they'd probably build something awesome. That's not true of the companies where MBA culture dominates.

I think one of Google's weaknesses is that there's an unspoken mentality that engineering is for smart people and everything else is for people who couldn't cut it. That might be why Google has excellent engineers but incompetent PMs and middle managers. If you think that engineering is what smart people do and PM work is for idiots, guess who ends up making product decisions?

Another of Google's weaknesses is that there are places where the engineering mentality doesn't apply, and Google doesn't seem to get that. Example 1: the Perf system has those nonsense calibration scores. They don't add anything; they just add another SPOF. It's data collection for the sake of data collection. But it turns out, in the real world, that data can be harmful. It can be used in ways that are really disgusting. (That's why Real Names is such an issue.) Google never got that. Example 2: the 3-word mission statements were a really bad idea. Same with downslotting. Engineers are supposed to fly with crazy ideas and give demos when things are still scrappy and rough. But in management, you really can't deploy an idea until you know whether it's good or not, because it's going to affect peoples' careers, and if you deploy a shitty idea it's hard to backtrack and take it all back. Downslotting never should have gotten through the door.

Google has some excellent engineers and many of them are people I'd love to work with again, but the place is losing its culture. Google+ and the executive attitude exhibited on Real Names established that.

I was really trying not to respond to you here but I can't let this statement stand uncontested:

    I think one of Google's weaknesses is that there's an 
    unspoken mentality that engineering is for smart people 
    and everything else is for people who couldn't cut it. 
    That might be why Google has excellent engineers but 
    incompetent PMs and middle managers.
This is false. Nowhere in the company have I seen this "mentality" you speak of. Either you imagined it or you're making it up. The PMs and Managers I've worked with and encountered have been, without exception, very smart and very well informed and very concerned with helping me do my job as an engineer. Some of them were former engineers who were both very knowledgeable and very good at their jobs who decided they would like a change.

Google is a multibillion dollar company and arguably the best software engineering shop on the planet.

You spout theory. They work in practice. You were fired from Google within months of being hired, and continue to trash them in every single thread on even marginally related topics. They go from strength to strength, shipping extraordinarily complicated products like Google Drive and pushing the future with Google Glass and self-driving cars.

Start your own company and try your management strategies there. Until then, stop attacking a company and organization that is far greater than anything most people (including yourself) will ever build.

Actually, I was never fired from Google, and I'll readily admit that they do a lot of things right. I agree that self-driving cars are great. Their search engine is also pretty nifty. This is not to say they do everything right. That's been proven false.

FWIW, I'm in Search Quality and I find that the "lightweight" system works quite well for myself and for many of my peers. YMMV.

Google's a huge company and some sectors of it work very well, and it's a great place to work if you land in the right place.

I think where Google screwed up is that it instituted a bicameral performance review system without understanding how to implement one. You can have a peer-review system or a manager-driven system. If you're doing things right, you have both and an OR-gate between them. People whose peers think they're doing great but whose managers don't recommend them can still advance, and vice versa. Conversely, to be demoted or fired, people have to fail both. The OR-gate system removes the career SPOFs that lead to degenerate behavior: managers can't exploit their position because people with strong peer support can still succeed at the company, and people don't avoid or shirk low-visibility but important projects

The problem with Google's system is that it has an AND-gate for promotions and an OR-game for demotions and firings, and that's a disaster. At Google, you need strong peer reviews (which largely comes down to visibility) to get promoted, but you also need to do well on a "calibration score" stack-ranking system (i.e. Jack Welch vomited, someone put a candle in it and called it a birthday cake) that is strictly manager-driven, extremely opaque, and often deeply unfair. (Google has historically had a problem of managers who abuse the calibration score opacity, giving low ratings to make it impossible for their reports to transfer.)

The downside of a manager-driven system is that managers can exploit the power, being career SPOFs. The downside of a peer review system is that people jockey for visibility and work that is important but not visible or "sexy" gets neglected. Google's AND-gate system delivers the negatives of both, but none of the advantages.

Google has some really great people, and in many ways, it's a really good company, but their abortion of a "Perf" (look, even the name is imbecilic) system is not one of their strong points.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact