Let's have no managers, instead of managers with no engineering experience - <AUTHOR> https://medium.com/@posttweetism/lets-have-no-managers-instead-of-managers-with-no-engineering-experience-e8b7cd29d398 <comment><USER5> > Business types with none to little engineering experience should never, > under any circumstances, manage engineers

In my experience as a developer at a bunch of different companies, the worst managers have actually been the opposite -- they were ex-engineers who knew nothing about management and decided to become managers for the wrong reasons (small raise, more power, etc), and had no passion for management. The longer one's career, the more one comes to respect managers, I think, and understand what a skill it is unto itself. Many young engineers have times when they feel hostile towards management or even the idea of having a "boss" at all, but that just makes the situation worse. One needs to have a more collaborative attitude to succeed. Again, it's the ex-engineers who think managements is just "common sense" are the ones you need to steer clear of.

<comment><USER6> I would like to get a bit of HN feedback on the matter. I am exactly the person mentioned here - an engineer who knows nothing about the management, but because company is growing and we're hiring new people I'm slowly transitioning towards a management position. Just like you've stated I know nothing about the management and all I have is a common sense to guide me which I'm afraid is not enough on multiple occasions.

I'm especially afraid of too much micromanagement, but I don't really know how to handle the process better. Here is my style of management, briefly summarized:

I have a very deep and detailed knowledge of all of our codebase, which is in it's entirety shared by noone else at the company. I've written half of it myself and the other half has been written by other people. Most of our hires have been hired between a year and few months ago (company is very young by itself).

What is the usual process for me is that I discuss the general direction and required features with top-level management, who is entirely nontechnical and make a roadmap in my head with plans for the "subprojects" which are more or less self-contained units of work, their time estimates and relative priorities with respect to company-wide deadlines.

Based on the last two, I dispatch the tasks to relevant people, waiting when they finish previous tasks. I try not to stress people with too many tasks at once, but treat "tasks" more like a priority queue, where when a person becomes available a current highest-priority task is taken out from a queue and assigned to a person, taking into account personal technical strengths and weaknesses as well.

Most of the time, when giving a task to a person, I already have solution implemented "in my head" and the process mostly revolves around me explaining the relevant part of the codebase to a person and detailing the solution I've envisioned with special emphasis on the parts where a mistake is more likely to be made. After the implementation is done, I take part in testing and perform a code review before merging the code in the production branch.

Sometimes I wish I would give people more freedom, but on the other hand maintaining project coherency and keeping a single direction for the whole team I feel requires for me to make final decisions quite often. I plan to hand off ownership of certain "modules" in some time in the future, but first I'm waiting for deeper understanding of the codebase to develop in the reports.

On the outside, to me, it seems that the process works. People are not complaining, team makes progress, features are done on time and seem to be of satisfactory quality. But like you can read above, I'm base strongly on detailed technical knowledge and basically "planning the work ahead" for the people.

I would really appreciate if anyone could share their experience with making that transition.

<comment><USER7> I would suggest to you that perhaps a good place to go from where you are is to start getting input into your solution from your new team mates. This allows you space to guage their quality, and make them feel like their input is important, as time moves on, you will then be able to understand where the good people lie, and hopefully allow you to give them more control.

This is the kind of thing that will probably lead to your team being able to grow and feel empowered, and hopefully mean that you can take more time to carry out more managerial responsibility, and give you trust in your team. A secondary advantage is that you let go of being the some holder of all knowledge, which could burn you out in the long term.

Also, perhaps allow code reviews in both directions, as it means that you can see how your input had made them look at other people's code and choices, hopefully giving your business the ability to self manage and to ensure that practises are followed consistently, even if your eye is not on the ball at all times.

This kind of thing had helped me make the transition, although I have to admit that taking my eye of the ball sometimes for too long has led to bad code in our projects and codebase. But that's where you go back and share that with your team, and those that may need greater support. Just remember you are one person, so don't expect to carry out all the work by yourself, empower those around you and give them greater fulfillment over time.

<comment><USER6> Thank you very much for sharing. I can see quite a few very valuable suggestions here. I'll try incorporating that in my way.

</comment></comment></comment></comment><comment><USER8> This sounds like the rantings of someone who has had some pretty bad managers and has never managed anyone else.

My schooling was Computer Engineering, my career started as a Software Engineer and has wound all the way up to Director level. I've been on both sides of this equation for a long time.

Your typical "just a manager" has to spin so many plates and babysit so many people that most real "engineer types" would loathe the job and frankly, not be very good at it. I struggled mightily as a team manager where there were a lot of competing priorities, personal issues, and directions that I needed to follow. As I got higher up the chain of command the job got easier, I had less direction I had to conform to, I was thinking architecturally and in longer terms– and I didn't have daily interpersonal drama to deal with.

Management isn't for everyone, engineer or not. It's a lot like parenting: Most people are just making it up as they go, trying their best, and the best ones generally put others before themselves.

Put the idea that Engineers should be these lone wolf rockstars that just to get to do what they want, regardless of corporate objectives or market positioning is ludicrous.

As an engineer, I can confirm that we're just as short sighted and dismissive of other people's work as they are to us.

</comment><comment><USER9> I tend to agree that managers of engineers should have engineering experience. I think my reasons would differ from those of the author and many other engineers: it's much less charitable toward engineers. One of the best reasons to select managers who have been engineers, in my opinion, is because they know how much bullshit engineers engage in with respect to fad chasing, bikeshedding and other negative practices. It's important to know what the work of an engineer really entails: that includes the aspects of it that negatively impact the business and how as much as it does the aspects that contribute value and how.

<comment><USER10> > I tend to agree that managers of engineers should have engineering > experience.

What about managers who have had experience like a decade ago and don't do much tech experience anymore.

I am stuck in such management chain at work where some guy up top thinks he is technical enough to dictate solutions based on couple conference youtube videos that he watches.

Half knowledge and false sense of technical prowess is more dangerous imo.

<comment><USER11> A manager should not be dictating architecture unless it's some really small operation, and even then, it's dicey. Rather, anyone who is capable of writing up a white paper that describes the problem, solution and rational for the choices should be able to propose a solution, and then have a meeting to discuss and decide whether to move forward.

A manager should have the big picture and communicate it to the team. Then you could avoid a team member wasting time on something that's not in the greater objectives or roadmap.

</comment></comment></comment><comment><USER12> It depends.

I've worked along-side and led multiple managers and have experienced various types of managers.

The good ones usually stood out. A good manager is usually the ones that shield their teams from the onslaught of clients' un-managed demands. She is the one that liaises effectively between a looming deadline and the sanity of the team. She is the one making sure the clients are making their timely payments when the work is delivered/deployed or milestones met. She is the one who knows the right way to calm down an angry client when something is not happening the way it should - missed deadline, bug regression. A good manager knows her limitations, and also her power.

A bad manager is usually the one that instigates one against the other. Takes credit and sweet talks with the upper management. She blames the team when things go wrong. A manager, who reports to me, once told me, "why should I be the one to say anything now, the client is pissed and we missed the deliverables. I'm not responsible." (btw, he was fired the following month.)

I believe I'm technically sound, know a thing or two about design and I've led multiple projects with multiple project/product managers. I love the ones that are ready to go with me frontal assault on problems and challenges.

Engineering managers are a good fit for an all-out engineering team. But at the end of the day, I believe managers need to be better human characters, have empathy and have more of people skill than technical or design skills. Design/Engineering — that is what the team is for.

Edit: Plural/Singular Gender normalization.

<comment><USER13> >have empathy and have more of people skill than technical or design skills

The problematic ones i've seen had some people skills, or they were thinking they had. The problem was when they did not understand engineering problems, and were thinking that everything was a people problem/issue. So they either assume that the developers are lazy, or they simply can't accept that the engineer can have some real objective concerns. So its either they don't understand however hard you try to explain or they try to understand it is a people/personal problem, when it is not.

<comment><USER12> Experienced managers do have an idea of engineering problems because they have seen it before - seen it happen, seen it solved, et al. A manager that does not appreciate engineering problems either just graduated from a management course or is someone who never got involved deeply with a team.

A manager has to answer to multiple people — clients, upper management, stakeholders, Jira. Unfortunately, she is totally dependent on this teams to get things done. She is utterly handicapped when it comes to doing anything useful, read, "engineering". Which is when most managers break and shows their character — they either break, blames people, do not listen, do not understand or they figure out who can help, seek help and find the right person to get things done.

Well, engineers, sometimes get it easy — they just have to solve a problem and make 2+2 = 4. They answer to one person; perhaps the manager. Think of the manager and to whom she is reporting and taking the fall. If the team does not get things done, they're the ones usually blamed.

In the early days of my career, I used to think that managers, middle managers are pretty useless. Now, I believe everyone has their roles to play a part in the whole machinery of 'the cogwheel'.

</comment></comment></comment><comment><USER14> I wrote 1000 words on this subject and prior spectacular failures of the "no management" style in Silicon Valley. I deleted it. No good can come of talking about it here.

Instead of an essay, I'll use a modern writing format: the pithy list.

1\. This article gravely underestimates the difficulty of engineering management. One must simultaneously handle HR functions, he roadmap of their team and other teams, and their reportee's opportunities for growth and success. It's a very complex juggling act that most people are thrown into with no training, because training for the technical aspects is so bad.

2\. This article's author forgets or is simply too lazy to look up previous examples of failure. Further, they're ignoring other attempts to systematize an "unmanaged" environment and what challenges people face there. It's unfortunate that they chose to pen such a long and effort-laden essay without doing sufficient research first.

3\. The author of this article also seems to totally ignore the coordination and management functions required of microservice organizations. Presumably because as an engineer who specializes in delivering one single single-purpose executable on top of everyone else's microservice architectures, they may not have a ton of experience with it. Who is doing this if not engineering managers? Product managers can have some mechanical sympathy, but it's seldom their job to deeply roadmap out features.

4\. This article ends suggesting that you don't need engineering managers to deeply understand the larger technical roadmap for your company and translate it to your team, but might find room for process custodians like scrum masters fix this problem? What? What even? This isn't even wrong. This is tantamount to suggesting the engineering itself doesn't even matter! It contradicts at least half of what the prior argument said.

<comment><USER15> > I wrote 1000 words on this subject and prior spectacular failures of the "no > management" style in Silicon Valley. I deleted it. No good can come of > talking about it here.

Well, put it this way: I've worked in more- and less management-oriented companies, and have found that those that were less heavily managed were both better working experiences for me and more effective as businesses.

> 1\. This article gravely underestimates the difficulty of engineering > management. One must simultaneously handle HR functions, he roadmap of their > team and other teams, and their reportee's opportunities for growth and > success.

If managers fail because the role is too hard for them, we can't expect to get better people, we need to make the role easier. Some of those activities can be separated (e.g. having distinct "team tech lead" and "team line manager" positions), line employees can be empowered to do some of them themselves (personal development), and some simply don't deliver enough value to be worth doing at all (maintaining technical roadmaps).

> 2\. This article's author forgets or is simply too lazy to look up previous > examples of failure. Further, they're ignoring other attempts to systematize > an "unmanaged" environment and what challenges people face there. It's > unfortunate that they chose to pen such a long and effort-laden essay > without doing sufficient research first.

I think it's entirely reasonable for them to write from their own experience rather than mixing first- and second-hand information in the same essay. Their essay makes a positive contribution to the conversation; concrete experiences of failure of alternative approaches would also be a positive contribution (far more so than low-content "they didn't research" complaints).

> 3\. The author of this article also seems to totally ignore the coordination > and management functions required of microservice organizations. Presumably > because as an engineer who specializes in delivering one single single- > purpose executable on top of everyone else's microservice architectures, > they may not have a ton of experience with it. Who is doing this if not > engineering managers?

You're putting the cart before the horse there; in my experience a vertically- layered "microservice organization" like you describe is the product of overmanagement (Conway's law in action). Better to give teams responsibility for delivery of client-facing functionality and have shared ownership of any common code; you write the functionality you need for the features you need. If you have a layer that really creates enough value to be worth other teams using it as a product, treat it as an actual product (ideally make it an actual product that you sell), and have a client-vendor-like relationship. Otherwise, a certain level of duplication of effort ends up being much less of a cost than constant between-team coordination would be.

> Product managers can have some mechanical sympathy, but it's seldom their > job to deeply roadmap out features.

You don't need a deep technical roadmap, only a product roadmap, because you integrate with other teams at the product level, not the deep technical level. Even in the presence of relatively good management I've found that that's what works best. Think Amazon's famous "platform memo".

(Of course occasionally a specific feature will require deep technical coordination with another team. But that coordination is best done by the person with the responsibility for delivering that individual feature - <USER2> line worker.)

> 4\. This article ends suggesting that you don't need engineering managers to > deeply understand the larger technical roadmap for your company and > translate it to your team, but might find room for process custodians like > scrum masters fix this problem? What? What even? This isn't even wrong. This > is tantamount to suggesting the engineering itself doesn't even matter!

Engineering matters, but _planning_ of engineering has been a counterproductive activity every time I've seen it attempted. Planning and management should be done at the feature level; when it comes to the technical "architecture", trust your technical professionals to figure it out themselves - they're the people who will have the information they need to make those decisions. Software architecture is a lot more flexible than people tend to think; even on a large codebase delivering complex functionality, it's surprisingly easy to make radical architectural changes, and often the biggest impediment to those is well-meaning "architectural design" that exists solely due to management imposition rather than being driven by any actual functional requirements.

<comment><USER14> > If managers fail because the role is too hard for them, we can't expect to > get better people, we need to make the role easier

Or maybe we need to start recognizing that engineering management is a thing that has value, requires training, and is distinct from being an engineer with a strong personality.

It's telling to me that rather than elevate the role you're more inclined to destroy it.

> Their essay makes a positive contribution to the conversation

If this weren't a post-Zappos, post-Github, post-Uber world it might. As such it reads like a stale take from 2009, to me. But sure, we can just ignore the cycle of failure in the industry and keep writing the same stale think pieces. Hey check out my fresh new monad tutorial while you're at it, Monads are like burrito aquaducts where the black beans and delicious salsa flow from computation to computation across the continent.

> You're putting the cart before the horse there; in my experience a > vertically-layered "microservice organization" like you describe is the > product of overmanagement (Conway's law in action).

I've described, with the most pessimistic lens, 2 layers of management to the top of your company, with a focus on team collaboration. Having managers with strong engineering experience and technical sympathy _decreases_ the depth of your organization, it doesn't increase it.

Please don't misrepresent my argument in your rush to dump on the idea of management.

> You don't need a deep technical roadmap, only a product roadmap, because you > integrate with other teams at the product level, not the deep technical > level. Even in the presence of relatively good management I've found that > that's what works best. Think Amazon's famous "platform memo".

Funny then how Amazon has technical management. But as an example of planning, imagine a platform team runs a flight of APIs. There are multiple clients to these APIs all shipping products. Each has their own feature needs. If those teams collaborate on dependencies and optimize around what they need, everyone gets what they need faster. Not coordinating or planning provides a random outcome in a space dominated by sub-optimal outcomes.

> Engineering matters, but planning of engineering has been a > counterproductive activity every time I've seen it attempted. Planning and > management should be done at the feature level; when it comes to the > technical "architecture", trust your technical professionals to figure it > out themselves

This entire discussion is predicated on the notion that your managers are technical professionals facilitating this. It's weird how many people refuse to accept the idea that people can exist, while in the same forum glorifying hybrid roles like startup CTOs in the same forum who are obligated to do a lot of management functions AND be the basis of a strong technical department.

P.S., I apologise for the brevity and potential grammar errors. I wrote this on mobile, figuring a prompt response was more useful than an expansive response.

<comment><USER15> > Or maybe we need to start recognizing that engineering management is a thing > that has value, requires training, and is distinct from being an engineer > with a strong personality.

I'd say that's the real "just ignore the cycle of failure in the industry and keep writing the same stale think pieces" approach. We've had decades of talking about how vital good management is and how better training for management is a great idea, and to what avail?

> It's telling to me that rather than elevate the role you're more inclined to > destroy it.

What it should tell you is that in my experience, steps in the direction of destroying the role have resulted in better outcomes, whereas steps in the direction of elevating the role haven't.

> I've described, with the most pessimistic lens, 2 layers of management to > the top of your company, with a focus on team collaboration. Having managers > with strong engineering experience and technical sympathy decreases the > depth of your organization, it doesn't increase it.

I was thinking about technically-vertical rather than organizationally- vertical. Cases where the implementation of a single customer-facing feature - the response to a single customer request - is handled by components that are the responsibilities of several different teams with their own management. That's how you'd end up needing to coordinate roadmaps between different teams, and I see that as indicating poor structuring of responsibilities, usually a result of a team taking exclusive control of an area that should be shared, which is usually a management phenomenon. You want to be in a position where whichever team needs a piece of functionality for a given feature that's their responsibility can simply implement it, whichever layer of the technical stack it resides in - where the only responsibilities that could belong to other teams are product-feature level responsibilities, not technical-area responsibilities.

> But as an example of planning, imagine a platform team runs a flight of > APIs. There are multiple clients to these APIs all shipping products. Each > has their own feature needs. If those teams collaborate on dependencies and > optimize around what they need, everyone gets what they need faster. Not > coordinating or planning provides a random outcome in a space dominated by > sub-optimal outcomes.

It's an appealing thought, but it just doesn't match my experience of how it works out in practice. The best outcome is often one that isn't imagined - <USER3> barely imaginable - until it emerges from the technical constraints (a la [http://wiki.c2.com/?WhatIsAnAdvancer](http://wiki.c2.com/?WhatIsAnAdvancer) ). Letting API feature implementation happen just in time under the person who has a direct use case for that feature raises both the ceiling and the floor on the implementation quality: they're working under the best conditions for inspired insight to happen, and the fact that they're using the feature means their implementation will at least work and fulfil at least one use case, and then the second user of the feature can expand it to suit their use case while keeping the existing use case working (people say that you'll get stuck in a local optimum that fits the first use case but can't possibly be adapted to the second, but I just haven't seen that happen in practice; code that was written for a single use case inherently tends to be simple and malleable). The absolute worst case is that the API ends up with two parallel but different implementations of the same feature to fit two different use cases, which is non-ideal but not actually all that bad in the grand scheme of things.

Whereas planning and coordinating via management as I've seen it practiced just goes wrong too badly, too often. You agree on an approach that everyone who comes to actually use the API agrees is wrong, but no-one wants to revisit the decisionmaking process. Or one manager brings a particular API under their control to expand their own importance, and prioritizes their own needs - <USER4> worse, deprioritizes work on it because they're not actually using that API for anything important but won't allow others to improve it. Or it emerges that what was initially assumed to be a single common feature actually has use cases that are so different that they should be implemented separately, but any team that proposed to fork off their own variant would be assumed to be empire-building (or, equally and oppositely, would be given insufficient support in their work), so everyone keeps muddling through with an awkward compromise.

> This entire discussion is predicated on the notion that your managers are > technical professionals facilitating this. It's weird how many people refuse > to accept the idea that people can exist

I don't think good technical architects/technical planners exist - I've just never encountered anyone who was able to produce better results by making technical decisions ahead of time (across a wide variety of management styles and techniques) than leaving them to implementation. Even if they did exist, I haven't ever seen an organization that was able to systematically identify, recruit, or train that skillset, and I do think they've been trying quite hard in various ways.

> while in the same forum glorifying hybrid roles like startup CTOs in the > same forum who are obligated to do a lot of management functions AND be the > basis of a strong technical department

I don't think I've ever been one of those people, but for what it's worth: most startups fail, and that those that succeed often do so by doing things that don't scale; in any case a startup CTO is rarely doing all the activities you listed earlier. Often startups simply don't do conventional line management at all, which works until it suddenly doesn't. Often startups don't have multiple distinct technical teams, which makes the whole notion of coordinating roadmaps between them moot.

<comment><USER14> _TL;WR: We could go back and forth on this for a long time. I doubt we 'll see eye to eye. But I won't back down on one thing:_ Ignoring the massive lawsuits and public scandal that "unmanaged" organizations have incurred and how easy it was for them to go wrong is a bad plan. Ignoring the systemic flop that holocracy has turned out to be is a bad plan. Pretending that medium and large software organizations can "run themselves" ignores what organizations with unprecedented success are actually doing, today.

But of course, what says "Sunday Night" like a good fisking?

> I'd say that's the real "just ignore the cycle of failure in the industry > and keep writing the same stale think pieces" approach. We've had decades of > talking about how vital good management is and how better training for > management is a great idea, and to what avail?

Well it wasn't terribly actionable advice before, say, 2008, now was it? The number of people who could get a strong foundational education with industry focus in CS was quite low until the early 2000's, and most folks want at least 5 years experience.

So really, the only supply of technically proficient managers was folks who were unusually talented AND escaped the orbit of organizations that provided quality experience. So like, Apple? Sun maybe. NeXT? Early Intel was boss, and I knew some amazing folks from SGI.

I had a very negative experience of tech managers too, until I met Bruce Horn from Apple. My earlier experiences were a complete train wreck. I met him in 2006.

We've actually seen a really great wave of folks tackling the idea. Folks like Camille Fournier or Dave Smith producing really great material for consumption. I'm grateful to both.

> I was thinking about technically-vertical rather than organizationally- > vertical. Cases where the implementation of a single customer-facing feature > - the response to a single customer request - is handled by components that > are the responsibilities of several different teams with their own > management... That's how you'd end up needing to coordinate roadmaps between > different teams, and I see that as indicating poor structuring of > responsibilities, usually a result of a team taking exclusive control of an > area that should be shared, which is usually a management phenomenon.

Pardon me, so you're suggesting you hire folks who can both implement the API and the distributed systems AND build the mobile client apps, and also the website?

That's how you get mediocre outputs.

> It's an appealing thought, but it just doesn't match my experience of how it > works out in practice.

That much is clear.

> Or one manager brings a particular API under their control to expand their > own importance, and prioritizes their own needs - or worse, deprioritizes > work on it because they're not actually using that API for anything > important but won't allow others to improve it. Or it emerges that what was > initially assumed to be a single common feature actually has use cases that > are so different that they should be implemented separately, but any team > that proposed to fork off their own variant would be assumed to be empire- > building (or, equally and oppositely, would be given insufficient support in > their work), so everyone keeps muddling through with an awkward compromise.

I'm not sure if you fully understand the nuance of this conversation though. I'm not objecting to the notion that bad non-technical management exists. Or even that bad technical management has existed. I cannot deny you've experienced this nor am I interested in doing so.

I'm saying: we need to do better. It's important to do better. And it's worth noting that the really amazing companies we see out there that do huge, good work? Netflix, Google, Mozilla, even Amazon (who I don't think very highly of) etc? They don't do that holocracy thing or that flat organizational structure. Heck, they've even gone so far is to _separate site reliability from product engineering entirely_. And most folks who I respect as engineer say this separation is the right call.

Our industry has a history of improvement. Not just in terms of technical accomplishment, but in terms of organizational success. Once even small software projects were complete nightmares, now most things ship and we're used to seeing a slew of somewhat functional software products that are lacking not for features but for product-market fit! Now, a previously unimaginably complex baggage checking system that was a famous failure is actually a 1 semester college product for upper-division software engineering and DAMN if they don't do a credible job of it (even though Kids These Days(tm) still don't learn enough about how SLAs are met in industry).

Engineering management and planning has had a similar curve of improvement.

> (people say that you'll get stuck in a local optimum that fits the first use > case but can't possibly be adapted to the second, but I just haven't seen > that happen in practice; code that was written for a single use case > inherently tends to be simple and malleable)

Aside: I've certainly had that happen! At Level we originally based the system around a primary spending account and secondary asset accounts because the staff and everyone who we interviewed had that configuration. We quickly learned that we had a biased sample and many people have multiple spending accounts. It took a very clever engineer to unkink our system to solve for that problem. Wish I had listened to our advisor, it would have saved us 3 months!

> I don't think good technical architects/technical planners exist - I've just > never encountered anyone who was able to produce better results by making > technical decisions ahead of time (across a wide variety of management > styles and techniques) than leaving them to implementation.

I think you have a curiously warped view of architecture. That it spans quarters or even months into the future. It doesn't. Often times, it's as much about auditing the existing babel of engineer rodeo projects to find out what's closest to meeting the requirements and helping those engineers sketch out how to take it the remaining agonizing 20%.

> and that those that succeed often do so by doing things that don't scale; in > any case a startup CTO is rarely doing all the activities you listed > earlier.

I know several post-exit CTOs because we hang out and we all have similar stories about doing this. I also know a lot of would-have-beens who said they didn't care about things like hiring and "just wanted to code" or functioned more like VPs of engineering (which are a pure management function).

> Often startups don't have multiple distinct technical teams

Usually it's "teams" of 1. You have the mobile specialist, the API owner (often the CTO), the website specialist. This is a very simple version of the larger exercise, but it's often even more important to keep track of how things are progressing because you have so little tolerance of wasted time.

<comment><USER15> > Pardon me, so you're suggesting you hire folks who can both implement the > API and the distributed systems AND build the mobile client apps, and also > the website?

Not necessarily the same individual, but the same team. If a particular product needs an API and a distributed system and a mobile client app and a website, it should be the responsibility of a group of people that has that skillset between them who sit together, have daily standups together, and all of that. I would expect the distributed systems specialist to be willing and able to add a line to the website or vice versa; different team members have different specialities but everyone owns the product and anyone picking up a feature takes responsibility for delivery of that feature. If a feature requires two people's skillsets they can pair on it and collaborate directly; if it requires more than that, find a way to break it down into smaller features that can be implemented individually but will still constitute customer-facing product features. (This is something people often assume will be impossible, but it almost always turns out to be easy once you try, IME).

If there's a function that's sufficiently universal and valuable that you want to share it (e.g. server administration), you have to stop doing deep integration across that feature boundary and pare it down to a more product- like interface (e.g. your server administrators offer a way for your application deployment to specify which libraries it depends on, rather than managing directly which libraries are installed on which server) where a product-like roadmap is sufficient. If there's a one-off feature that requires deep integration with another team, that feature should be done by a pair with one individual from each team, who can coordinate directly with each other.

> I'm saying: we need to do better. It's important to do better. And it's > worth noting that the really amazing companies we see out there that do > huge, good work? Netflix, Google, Mozilla, even Amazon (who I don't think > very highly of) etc? They don't do that holocracy thing or that flat > organizational structure. Heck, they've even gone so far is to separate site > reliability from product engineering entirely. And most folks who I respect > as engineer say this separation is the right call.

I don't see the giants as the ones doing the amazing work - their big innovations happened when they were smaller - and within the class of giants I would loosely guess that the more effective ones follow a lower-management, more-segregated-teams style. (FWIW I think Facebook - conspicuously absent from your list - have been more effective among the giants, both in terms of making a better product and in terms of producing high-quality technical libraries). But we're getting beyond the level where I can really have an informed opinion; I haven't worked for enough large companies to have a statistically valid sample, and while in the absence of proper studies I'm inclined to trust to my own experience, I could've just been lucky at the less-heavily managed ones and unlucky at the more-heavily managed ones.

> I think you have a curiously warped view of architecture. That it spans > quarters or even months into the future. It doesn't. Often times, it's as > much about auditing the existing babel of engineer rodeo projects to find > out what's closest to meeting the requirements and helping those engineers > sketch out how to take it the remaining agonizing 20%.

My view is based on what I've seen people in "architect" positions do; I'd certainly say there's a lot of variation in what it means between different companies, but it's always been some form of making technical decisions earlier than during coding (even if just at the start of the week after scoping out a particular feature) and as such I've always found it counterproductive.

Pair-programming with a developer on the same team who knows the codebase well can be extremely positive if that's what you meant, and I suppose you could consider that person an "architect". But I find it's vital that that person not be any kind of formal manager: the easiest way for it to go wrong is when the junior partner gets intimidated and stops contributing.

<comment><USER14> All I can say is: good luck with GDPR compliance, my dude.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Sometimes we engineers do a poor job of communicating complexity: we have un- communicated assumptions that we think the listening party shares. Which sometimes lead to this:

 _" You could prepend the words "it's just" to anything, it's not going to change the fact that you sound completely ignorant and will ignore any challenges that your team communicates to you."_

I have often found it effective to counter "just-justifications" with the right representation of complexity. E.g.

"Yes, it's just an API change, but it requires 50 new test cases and impacts 120 existing test cases",

OR

"Yes, it's just a library change, but there are 450 sites in our code that use the library and out of those, 50 involve financial calculations"

Almost always, the manager appreciates this because you would have brought to his attention a problem that would otherwise gone under his radar.

<comment><USER17> > "Yes, it's just an API change, but it requires 50 new test cases and impacts > 120 existing test cases",

"See, that's exactly why we shouldn't write any/so many tests!" \- A product owner I know...

<comment><USER18> He might have a point if a simple API-change impacts 170 test cases. This sounds suspiciously like "no functional tests but let's go for 100% coverage with unit tests" \- not necessarily the efficient thing to do, from a management perspective.

</comment></comment></comment><comment><USER19> Something I have wanted to ask the HN community, that this article brings up: what exactly does a scrum master do?

From what I have observed at one business, there is one scrum master on every team. Many of them know nothing about the business that business does, and have no technical background. I have seen developers spend sometimes an hour or more a day explaining to scrum masters what they just built, so that they can then go "communicate that up" to upper management or project management in opaque meetings developers aren't allowed to attend.

But what I can't figure out, is what they are actually supposed to do. At best, I see two points: 1\. They do the traditional work of a project manager but on a team level, and communicate status up. 2\. They are supposed to be some kind of "thought leader" on agile methodologies.

Can HN help shed some light on what this role should do? Perhaps my background has just been a bad experience in this regard. I suppose where I get stuck is, this seems to be the work that a dev lead used to do. Why make a full time job for a non-technical person to lead a technical team, below the management level?

<comment><USER20> In my company, each team has a scrum master (a SM being part of 2/3 teams). They have near-zero technical knowledge, and this is what they do (no particular order):

\- Give an organisation to the team, and make sure that this organisation does not decay with time \- Help the devs work faster by helping them with the methodology \- Help identifying & solving problems (a problem goes from "a dev spent one hour more than expected on this ticket" to "the client has no vision on what the product should be"). This is probably the most important task \- Help the client to lead his project. This is a huge part too, the client does not know how to lead a project (they just came to us with a business problem they want to solve): there's no way the project will succeed if the client doesn't manage to have a clear vision for his product, prioritise tasks, build indicators, get user feedback...

Minor tasks: \- Organise meetings/demos \- Lead the meetings, make sure they're productive

We're a service company without management, "communicating status up" is a concept that doesn't exist.

<comment><USER19> > This is probably the most important task - Help the client to lead his > project

For someone to do this, they would have to have client communication skills, at least somewhat thorough understanding of software development or the process, and an understanding of the client's business. I see this as a good thing. However, your example sounds to be a company that has external clients that you write software for. Do you not have account managers/principle types who interact with the clients, or is that more or less what a scrum master does there? Just curious, if you were an internal only dev shop that just develops software for stakeholders at your own company, would you see the role of a scrum master as significantly different?

</comment></comment></comment><comment><USER21> While I agree that it _helps_ for a manager to have experience doing what they are managing, I would frame it differently. I've experienced poor engineering managers with engineering experience and good engineering managers with none, to the point that I've developed a more nuanced opinion about what makes a good (engineering) manager.

Great managers can manage things they don't understand and probably never will -- their role does not require domain expertise. I would argue that the hallmark of a poor manager is that they can't manage _unless_ they are a domain expert, which they often use as a crutch to overcome lack of basic management skill. One of the greatest failure modes for software engineering managers with engineering backgrounds is the assumption that they can or will understand every part of the design they are managing. Not only is this unlikely in many cases but this delusion encourages them to dictate elements of engineering design that they are not intimately familiar with, invariably to the annoyance of the engineers that are tasked with doing the work and may have far more technical skill than the manager on the task at hand. For mundane software projects, an engineering manager with an engineering background may legitimately have the domain expertise, which is why it still gets things done despite being suboptimal for everyone.

This is really brought to light when doing complex, high-end software system engineering. In these cases my experience is that _most_ experienced engineering managers with engineering backgrounds fail; because it is impossible to understand what your team does at a technical level, you can't lean on that. It is often difficult for very experienced engineers, now managers, to come to terms with the idea that someone working on "their" project has technical skills that they can't master or at least understand with a 15 minute explanation and a couple hours of research. Engineering managers, especially ones that were previously great engineers, must resist the instinct to technically master everything under their purview -- it doesn't scale. The advantage of non-engineering managers in these environments is that their management style doesn't rely on the assumption that they can technically master any part of the project, so they don't even try.

A big part of being a good engineering manager is letting go of what made you a great engineer. It isn't an easy thing to do.

</comment><comment><USER22> It's just management, after all.

I don't mean to be too flippant, but isn't this whole article an instance of exactly what the author is complaining about? Let's have good managers rather than bad ones. Good managers trust their reports to tell them the constraints of the work and factor that into the team's strategy. Being conversant in the underlying task helps a lot with that, but there are plenty of managers who come from an engineering background who make the same mistakes the author laments.

<comment><USER23> That's what I was thinking. Really, the problem with most managers is that they are not empathetic with both the business side _and_ the tech side at the same time. Good managers know how to set expectations and communicate with correct language when talking to either cohort.

</comment></comment><comment><USER24> I was recently a lead developer and asked to manage the team by the team. I noticed running the team can't be generalized in one size fits all, some people just want clear descriptions of projects to work and and some people want to over engineer and make a 1 day thing a 2 month job no matter how you say it should be done. Problem is how do you handle a engineer that says something can't be done in 2 hours? Well so far I have sat down with them and showed them it can be done in 2 hours, beyond that argue with me enough and I may be forced to rethink your employment. It hasn't come to that yet. most of the room follows my instructions and we are kicking butt, there's a small part of the room that wants to be dramatic about everything, their computer isn't good enough "needs 64 gigs of ram for their command line", the tools aren't good enough etc etc - basically they have management envy and that's my only struggle right now.

<comment><USER25> >most of the room follows my instructions

Be aware that this works only because you were technical lead of the project and recently active in a hands on capacity. It will likely fail you once you are on a new project that you don't know technically and your skills are years out of date. So learn to find, trust and nurture the experts on your team instead.

<comment><USER24> We're no google but I have lead the software department on techical decisions and scaling for the past 3 years as the company/startup tripled in growth. We are a tiny power rangers sized team, I probably just have angst in my comment as there is one particular employee who was recently hired before me stepping on that goes left when I "and everyone else on the team" says go right.

</comment></comment></comment><comment><USER26> I often institute a "just" $1 jar. Anytime "why don't we just" or "it's just" is uttered you have to put a dollar into the jar. This applies to engineers, managers, myself, everyone. The idea is breaking the habit of trivializing work that isn't. Something like a dollar jar is fairly effective as a notifier but doesn't necessarily replace the habit with a better one. Nevertheless the game itself seems to help even if dollars aren't transferred into the jar.

<comment> the-pigeon Hmm isn't that just like a swear jar? You don't get rid of the swears or the trivializing but rather you just replace the particular words being used for the trivializing.

So what's the benefit?

<comment><USER27> Swear jar is a great analogy. Also, that'll be $2.

It's a game mechanic that encourages people to be more thoughtful about how they think about a problem. Not perfect, like the swear jar, but it has some value in changing behavior.

</comment></comment></comment><comment><USER28> My own experience in this department has been managers with engineering experience but no management training or experience. Sometimes it's orgs that promote bad engineers into middle management to get them out of engineering. Sometimes it's orgs promoting their best engineers into management roles for which they are a bad fit, or just ill prepared.

A number of the examples in the article are just bad management, and things I've heard from managers with years of engineering experience.

YMMV

</comment><comment><USER29> You need experienced managers as the size of an organization grows. For development teams you need an engineering manager to work with product to design stories, orchestrate work with other teams, and to provide technical mentorship.

The author conflates "all managers" with "project managers." and implies this is some artifact of the hegemony. My experience with project managers is that they are largely an artifact of waterfall-style software development and are not as necessary today in agile environments. But they can be helpful in the orchestration of large-scale projects.

I've personally never been in a situation (I've worked in software development for over 25 years) where we were hiring an engineering manager, and hired a "business type" instead. I'm hiring a development manager now, and the first step in that process is a coding interview. They cannot go further unless they pass that.

This whole article reads more like an us-vs-them rant than anything else.

<comment><USER30> Yea, I picked up on this too. I was pretty confused reading through the rant. Is his beef with his engineering managers or with his project manager(s)? It looks like he's frustrated with project managers.

My rule of thumb for "how you know you need a project manager": As a manager of engineers, if you find you have more E-mails than you can possibly respond to, or more meetings than you can possibly attend, or more people "pinging" you than you can possibly satisfy, then you need a project manager.

If you're an individual contributor engineer, you probably are not in the position to even know if you need a PM or not, especially if _your_ manager is doing a good job.

<comment><USER29> Agree!

</comment></comment></comment><comment><USER31> This guy has clearly been bitten by one type of bad manager. But let me assure you, there are many other types, and they often come from engineering backgrounds. You'll get all matter of micromanagement and communication issues that come from someone who is used to knowing all the intimate nuance of every issue. Also, even if you think they are a great manager because you have a great individual rapport, they may end up getting steam-rolled from above because they are bad at cross-functional communication or managing up, and guess who pays the price for that?

The fact of the matter is that management is its own skill, very contextual and difficult to master, and engineering experience is no silver bullet. Of all the best engineering managers I've worked with (both up, down, and lateral), only half had an engineering background. It depends on the project of course, but in general there are more important attributes than hard tech skills.

</comment><comment><USER32> Sounds like someone that hasn't ever had a good manager. A leader that can provide good air cover is a serious benefit in a large company. That ability has little to do with whether they have engineering experience or not.

<comment><USER33> There is value in keeping negative attention away. There is also value in attracting attention to technical needs. If you need someone in another part of the org to do something technical to make your life easier (or even unblock the project), it's difficult to get the job done without a technical manager. You can usually get the job done with a non-technical manager who can listen and delegate well to a good technical leader, though. The problem is that a non-technical manager won't necessarily know who is a good technical leader and who is just a loud engineer.

<comment><USER32> My experience is that a good non-technical manager will develop a relationship with a member of their team that fills that gap. Most of the "good" manangers I've worked for were good because of their soft skills.

<comment><USER33> I mentioned that approach, yes. But it can backfire if the team member is makes big mistakes. The non-technical manager will have a hard time identifying bad decisions before they blow up.

<comment><USER25> >I mentioned that approach, yes. But it can backfire if the team member is makes big mistakes. The non-technical manager will have a hard time identifying bad decisions before they blow up.

Why do you assume an out of date and no longer practicing manager will have a better chance of catching errors than causing them? There is a reason you hire experts and that reason is not so you can ignore them. If you're afraid of a single point of failure then you foster a collaborative blame-free culture where the engineers cross check each other.

I've had managers who would agree with you and generally they were bad managers who hadn't realized they were no longer Senior ICs.

<comment><USER33> I think people who make and collaborate on strategic technical decisions need up close and personal perspectives on in the trenches technical work. I think non-technical managers have a very hard time detecting when someone is blowing smoke. I think former engineers can turn into non-technical managers fairly easily if they aren't proactively contributing actual patches and reviews to their projects.

Collaborative, blame free technical culture is ideal, yes, but it requires technical leadership and some amount of technical strategy. _Someone_ (or some committee I guess) has to be able to decide when a project costs more than it makes. Only someone technical can actually estimate the projects. You can collaborate in and delegate that estimation, but there still needs to be a decision somewhere.

</comment></comment></comment></comment></comment></comment><comment><USER34> This is just a rant.

The author apologizes for speaking in unqualified absolutes, but does so constantly.

Even if the author is right, this article reads as pretty childish.

</comment><comment><USER35> There's a balance. A group run by clueless managers is bad. Equally through a group run entirely by engineers that don't think about or consider anything other than their engineering concerns is bad too.

A good manager knows how to find the balance between "what engineering wants" and "what everyone else wants" and gets the best outcome. The best managers don't need to be expert engineers themselves but they know enough to have a good BS detector and enough to make decent decisions.

</comment><comment><USER36> I find a good manager who facilitates the bureaucratic nonsense I don't want to deal with to be worth their weight in gold. They don't have to understand the details of what I do and build, so long as they support my work, are willing to shop it out, and give solid feedback.

I've worked with managers who thought they were somehow superior to the people they manage. This seems to be a common issue. They tend to experience a high attrition rate.

</comment><comment><USER37> My experience is the opposite: I find that managers who are not from a software engineering background are generally better.

In my experience managers from a software engineering background are usually lower skilled engineers who tend to overrate their own skill level and make bad technical decisions where a non-engineer manager would defer to the expert opinion of the people they manage.

<comment><USER25> My experience agrees although proper management training/mentoring can alleviate some of the issues.

However the timeline I've experienced is different:

* You have a great engineer or lead who knows the project inside and out

* They are promoted to management.

* They still know the project inside and out plus were recently coding so they dictate how things are done technically. It works great.

* They get put on a new project which they don't know inside and out.

* They dictate how things should be done technically because it worked for them in the past successfully. It works horribly.

</comment></comment><comment><USER38> > It's better to have no management than unqualified management.

If you've ever been on a project with more than 1 or 2 people without a manager—or where the manager doesn't do their job—you would know how insane this sounds. It does not work. Once you're coordinating groups of people you need a manager to keep them working together towards a common goal.

<comment><USER39> That's not true in general, I've been in environments where a team of 10+ very motivated individuals worked together without a manager. It's not common though.

<comment> the-pigeon But you still have people doing the job of a manager.

Someone has to set meetings, someone has to call out issues, someone has to communicate with upper management and other teams.

No-manager really means distributed management or an informal manager. Because the essential work a manager does has to be done by someone.

<comment><USER40> Sure, that work still has to be done. But if you start off by thinking of it as "the job of a manager" then you're assuming your conclusion.

</comment></comment></comment></comment><comment><USER41> Communicating complexity difficult.

I recognize the feeling when tasked with bringing a new developer up-to-speed. They don't know anything about our environment and the brilliant decisions that led us to our utopian way of working. They ask an honest question and I, having forgotten the ingredients, brush off the question because I don't have time to explain. Welcome to the team noob.

I also recognize the challenge when speaking with practically every CEO, COO, EVP, VP, and Director in a mid-sized organization. And the challenge can grow exponentially when the business involved views technology as an expense. Somewhere in the building there are a number of idiots who think a pointer is a device used for whiteboard presentations. How is this company profitable?

But solace comes when I realize the issue is my own.

Technical expertise is not the only expertise required by a company. It is highly likely that your organization has executives that don't need to understand the productivity differences between vim and emacs. Imagine how frustrating it would be when attempting to ensure the company has enough funding for the next four quarters and you can't get a single developer in the world to provide a reasonable estimate that doesn't have a sixty-percent margin of error. I dare you to argue the benefits of a scrum master.

Your manager is just as anxious about having to talk to you. Give them a break and help them do their job. They'll appreciate it and may care to understand your concerns moving forward. Who knows, they may be willing to help you do your job better (as if that's possible). Communication will be less frustrating when you stop viewing others as inferior. They feel the hostility.

The most successful amongst us are those that communicate by simplifying complex subjects down to an intelligible analogy. They sell. The world rewards those who sell. Just find another way sell your complexity, patiently, and with a touch of empathy. The rewards will follow.

</comment><comment><USER42> I worked for a lot of different managers in my career, both good and bad. At one point I was team lead, but didn't like it too much.

It always comes down to this (in technology): A good manager serves his team, a bad manager thinks his team serves him.

A good manager realises that his team members know more about the tech than he does (even if he is technical). To get estimates, he asks the people who know.

A good manager makes sure each team member can stay focussed on their job.

I didn't like being team lead too much, because I don't like administration, and I don't like to handle shit that you don't want to distract your team. At the end of the day, I was always happy when I could write code. Therefore I leave the 'shit' job for someone who likes it, but I'm glad some people prefer the other.

</comment><comment><USER43> A. Engineering Management shouldn't micromanage, but a manager can be invaluable in helping resolve interpersonal conflicts and escalate issues. They can be the "bad guy" when dealing with someone the team reports is consistently underperforming or engaging in poor behavior.

B. Are you an engineer or a technician. An engineer "just" creates fixes. A technician will implement it. Lines blur in programming more than other fields, but some "engineers" make a big deal out of just figuring out solutions that have been solved many times before, like making a backend call.

This is my perspective as an engineer.

</comment><comment><USER44> Historically for me, any time I've worked with managers who either managed my team or projects I've worked on, whether they helped or harmed things depended pretty much solely on "does this person have management training/experience, and a desire to be a manager".

I've worked with both engineers-turned-manager and "business" managers, and both have had ups and downs. But the tech industry's love of taking individual contributors and pushing them into management roles without any management training or even interest in managing people seems to be the failed experiment.

</comment><comment><USER45> Author seems to lose the distinction between project managers and engineering managers. The tricky thing is that some engineering managers do perform project management functions, but that will make for one overworked manager. In mainstream FAANG-type companies what you will see is:

Project management - manage scheduling, deadlines, track progress, day-to-day or low-level interteam collaboration, resolve blocking issues. They'll usually use a bug tracking system and ensure that it's state reflects reality. They may also need to build out or modify various processes such as new releases or deployments, work with QA on a validation process, or when should code be considered good-to-merge into the repo. (Has there been code review done, CI testing, validation, etc).

Engineering management - HR functions (promotion, performance management), assignment of tasks or larger projects, working with project management on realistic schedule, working with product / business on requirements, interfacing with other teams on high-level matters, strategic work related to the team, and most importantly work that no one ever wants to or has any time to do. (This includes technical work.)

IMO you can have a small org without these two functions if everyone is a has extensive experience/willingness to managing themselves, but if it grows past that things will break very quickly. Modern large organizations deal with unfathomable levels of non-technical complexity.

</comment><comment><USER46> _Example? I've experienced too many instances of just-justification, where a manager has said something like, "it's just JSON", or "it's just UI", or "it's just talking to the backend". This not only unravels their credibility in knowing anything about software, but it also devalues the work that a software developer needs to do to build a working product._

Well, I've had engineer colleagues use that kind of language at me. It's a type of bullying really, and it doesn't necessarily correlate with technical cluelessness.

</comment><comment><USER47> Didn't Google try this? It didn't work out for them.

[https://www.forbes.com/sites/meghancasserly/2013/07/17/googl...](https://www.forbes.com/sites/meghancasserly/2013/07/17/google- management-is-evil-harvard-study-startups/)

[https://hbr.org/2013/12/how-google-sold-its-engineers-on- man...](https://hbr.org/2013/12/how-google-sold-its-engineers-on-management)

</comment><comment><USER48> >But where they single handedly derail a project due to micro-managing and over simplifying developers' implementation concerns.

All my managers have been engineers in the past. And over half of them fit this description.

I don't want to downplay the benefit of having some domain knowledge, but the problems described are not a symptom of not having engineering experience. Management requires a good amount of nontechnical skills, and too often a high performing engineer is picked for becoming a manager, with no training whatsoever.

</comment><comment><USER49> This might be interesting in this context: [https://rework.withgoogle.com/guides/managers-identify- what-...](https://rework.withgoogle.com/guides/managers-identify-what-makes-a- great-manager/steps/learn-about-googles-manager-research/)

"... teams with great managers were happier and more productive..."

In my opinion, it's not about having no managers---it's about having managers with the right mindset, qualities, and behaviors.

</comment><comment><USER50> On a related note, I just quit one of my contracts, but in this case a fellow developer was asked to become a SCRUM master a few months ago. The word "master" must have gotten to her head because that's what she thought she was. It turned into a micromanaging nightmare and she started trying to track my whereabouts and hours, even going so far as to tell me who I can and cannot talk to, as if she were a manager (but not even our CEO would treat me like that). I finally had to tell her she wasn't my manager and that we're equals. Well she didn't like that and told me "I'm the SCRUM master!" and that I don't understand the agile process. I had even talked to my actual manager about this the week before, who confirmed that yes, a SCRUM master is nobody's manager and cannot tell anyone one what to do. Things came to a head and now I'm outta there and all their objectives will now go red, all because someone who had some perceived power thought that they could skip years of training, experience, and wisdom, and go straight to "manager" (and a bad one at that).

</comment><comment><USER51> I think we can all agree that bad managers suck and managers who pretend to be technical particularly suck. However it feels the me though like we greatly underestimate the difficulty of being a technical manager and grievously under train them. Google has gone past the one-off personal experiences and studied across lots of teams and projects[1] and being a technical expert wasn't even close to the most important trait. I'd like to see us spend less time proposing "no managers" as current ones aren't good and more time on figuring out how to make them good and give them training and support they need. Most of the ones I know want to be successful and are trying in their own imperfect way. If you think the most important thing is technical prowess just take a look at any academic CS department, run only by super technical professors it is often a case study in anti-patterns.

From Google's study on managers reported in nytimes[2]

      "In the Google context, we'd always believed that to be a   manager,
      particularly on the engineering side, you need to be as deep or deeper
      a technical expert than the people who work for you," Mr. Bock says.
      "It turns out that that's absolutely the least important thing.
      It's important, but pales in comparison. Much more important is just making
      that connection and being accessible."

[1] [https://rework.withgoogle.com/subjects/managers/](https://rework.withgoogle.com/subjects/managers/)

[2] [http://www.nytimes.com/2011/03/13/business/13hire.html?smid=...](http://www.nytimes.com/2011/03/13/business/13hire.html?smid=pl- share)

edit for formatting

</comment><comment><USER52> Gets me thinking of one episode of the original Connections series.

There Burke talked about automation (keep in mind this was recorded back in 1978), and how it would make management simply sit around waiting while the mainframe in the basement churned out the action plan for the next week (or some such) and then implement it.

Effectively he envisioned that computation could eliminate the managerial class.

</comment><comment><USER53> I think there is a slight correlation between having some expertise in the team that you're managing and your overall performance as the manager. Some points along this argument include empathy for engineers' work, and I totally agree with you.

However, and especially at scale, there is a humanistic factor in management that having technical background alone can't fix. How do you manage deadlines? How do you deal with engineers who over-engineer a feature and go down that deep technical rabbit hole, with no "done date" in sight? How do you deal with people having to take a sabbatical but having an important project deadline around the corner? Heck, I'd argue engineers like myself are pretty bad at this and still constantly learning. Don't forget that expectation vs reality distortion is real. Great managers are essentially brokers to keep expectation and reality in check.

</comment><comment><USER54> I'm thinking about starting a tech cooperative where the members work on startup ideas [1]. Every member will have complete control to work on whatever they want, and there will be no managers or deadlines. I want to work with people who have enough motivation to fix broken tests and bugs by themselves. It's much easier when it's your own product.

This might not be the most effective way to run a company, but the members will all be self-sufficient, and we'll support ourselves with part-time contract work. Or some might have a full-time job and work on side-projects in their spare time. Eventually we might make enough money to pay for our living expenses.

The projects could be anything, and at the beginning we would focus on revenue. SaaS services, mobile apps, games, open source projects with some paid features (e.g. Sidekiq), or buying some websites from flippa.com.

Once we start making a bit of money, we can shift focus to non-profit work, and fun projects that are purely creative. I have a big list of things that I'd love to work on, and some of them are just fun ideas that won't make any money. But who knows, maybe those experiences will shine light on some new product ideas.

I want to find people who love learning and building things in their spare time. And I want to start a company where all the time is spare time. That's not to say that spare time is always fun. Responsible people use their spare time to do chores and fix stuff around the house. You wouldn't want to live with a roommate who always leaves dishes in the sink and leaves their clothes all over the floor. I want to work with independent people who don't need that kind of management, and build a lot of interesting things together.

[1] [https://docs.google.com/forms/d/e/1FAIpQLScfFzyzCWPresTMPSb4...](https://docs.google.com/forms/d/e/1FAIpQLScfFzyzCWPresTMPSb4c13oUbcAZfeyit7muj5cCMvMu56Z2g/viewform)

</comment><comment><USER30> Maybe I've just gotten extremely lucky, but in the 15+ years I was doing software development, with one exception (a CEO where I was employee #1), I never had a "non-technical" manager to whom I reported. Where are these companies that hire someone who literally knows nothing about engineering to lead a group of engineers? I'm not saying it doesn't exist but I've never seen it.

I've seen my share of non technical _product_ managers, _project_ managers, etc. but not engineering team managers. In all cases my engineering leadership were technical all the way up to at least the SVP level.

EDIT: So, I got to the end of OP's rant and it looks like he's shifted his target from "managers" in general to project managers. He might even be confusing the two.

</comment><comment><USER55> I've thought about that a lot and my conclusions weren't what I expected as a programmer.

The issue is that, someone has to talk to the internal customer [0].

Now if a programmer do the talking with the internal customer, then I believe, he will naturally become some sort of a surgeon ala Mythical Man-Month [1].

 _Mills proposes that each segment of a large job be tackled a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity._

Problem is, I believe the surgeon method cant work in practice for 2 reasons, 1) programmers dont want someone who tell them how to code, 2) even if people would want a surgeon, since the surgeon both need to be a great programmer and a great politician because he will naturally speak to the internal customer (because eh, hes the surgeon), hiring for that position becomes difficult - and you'll end up generally with a great politician that sucks at programming, which makes (1) even more pronounced.

The only way you can get rid of the project manager is to make the team the internal customer. That's the case at Valve [2] I believe.

In the mean time, the best thing to do is to work with project managers who were engineers before.

[0] I know what you think: a project manager isn't only talking to the internal customers. Yes, that's correct but the rest of his job is similar the one of a secretary. Nothing that would put guy on top.

[1] [https://ia801903.us.archive.org/19/items/mythicalmanmonth00f...](https://ia801903.us.archive.org/19/items/mythicalmanmonth00fred/mythicalmanmonth00fred.pdf#page=41)

[2] [http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...](http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf)

</comment><comment><USER56> If there is one thing I learned it's that "no managers" === "everyone is responsible". That ends up as "no one is responsible". Then chaos ensues due to no clear decision making and infighting because everyone is suddenly "boss". As always YMMV.

</comment><comment><USER57> This is indeed an important discussion. I was looking for some similar experience in the top few comments but couldn't find it, so I thought about writing my own. From my experience its about the person in the role, not the role itself. Two of the best managers I had were non-technical but they could read people. They kept their distance from the technical work but would step in when required to control. Ofcourse this also means that they hired good engineers to begin with. A good engineering team can run by itself when it comes to technical work.

</comment><comment><USER58> No. Just no. I have been there to clean up the mess that results from this methodology.

A certain recipe for disaster in any development project is having no one who thoroughly understands the business and no one who can make a decision as to what gets developed and what does not. What this article is describing is just such a recipe.

Any significant development project which is attempting to address the needs of the enterprise needs an enterprise architect, and a project owner who can say no. If these can be the same person, all the better.

</comment><comment><USER59> In my experience management was either good an bad. I think that culture was the most important thing at the end of the day. Engineering is not everything when productivity is important as well as environment.

In some cases/team there is the need of an extra effort in order to balance resources AND people.

If I could pick a manager from a pool I will probably take someone with experience in people first and docker later...

At the end manager that are open to listen to the team and the customers will probably take the right choice in term of technology.

</comment><comment><USER60> The author's example provide the counterpoint and the way forward with a non- technical manager.

In fact sports and arts organizations have non-technical "managers". In theater and film, they are called producers.

If a non-technical manager keeps to the "producing" stuff, that is, HR, resource acquisition, inter-company communication, I've seen it go well.

As soon as the non-technical manager starts making "creative", ie technical, decisions, that's when things go poorly.

</comment><comment><USER61> Stop calling it engineering...engineering is a degree that requires an incredibly rigorous formal training and education. Call it what it really is, there's no shame in the word developer or programmer, wear it with pride, but don't just appropriate words, it is beneath you.

<comment><USER45> What does formal training or education give you that many years of diverse and relevant experience coupled with professional mentorship and self-learning doesn't?

</comment></comment><comment><USER62> I think there is value of management in all cases wrt processing corporate beurocratic paperwork and even for resource allocation of staff to initiatives.

You get into trouble with non-SME managers that start directing the way people solve a problem or prioritize what work gets done.

</comment><comment><USER63> How about no managers with no management experience. I've seen countless senior devs promoted to eng/dev management roles who were either clearly not ready for the role or were simply not the personality to "lead".

</comment><comment><USER64> I don't think 'no managers' is a good idea. There _are_ managerial 'things to be done' in every project.

As a thought experiment, if management were 'just a role' and people could switch into for a period of time and then go back to their 'real jobs' with no loss of pay or prestige, that might lead to some interesting effects.

(warning, anecdata:I've worked on teams where the 'manager' role was cycled among engineers/testers/designers etc throughout the project lifetime, and it worked well. I've also seen managers come back to being full time developers, and their perspective from the time of being managers really helped with their effectiveness as developers)

</comment><comment><USER65> I have been saying this for years, but most consulting companies insist on managers who have no clue what they are talking about.

</comment><comment><USER66> This also reminds me of MBA CEOs that delegate everything, and that also reminds me of Jack Dorsey that is CEO of two companies.

</comment><comment><USER67> Or just have managers with engineering experience. Just saying. Cause it seems pretty straightforward to me.

</comment><comment><USER68> Obligatory xkcd: [https://xkcd.com/1425/](https://xkcd.com/1425/)

Also, I feel like this (we don't need no stinking managers!) is a perennial meme that pretty much doesn't work in practice? Queue the Valve Employee Handbook: [http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...](http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf)

Some more articles:

\- Valve [https://www.inc.com/david-burkus/how-this-company-runs- witho...](https://www.inc.com/david-burkus/how-this-company-runs-without- managers.html)

\- Zappos [https://qz.com/161210/zappos-is-going-holacratic-no-job- titl...](https://qz.com/161210/zappos-is-going-holacratic-no-job-titles-no- managers-no-hierarchy/)

\- [https://www.fastcompany.com/3045509/myths-of-companies- with-...](https://www.fastcompany.com/3045509/myths-of-companies-with-no- management)

\- ? [https://www.fastcompany.com/3045509/myths-of-companies- with-...](https://www.fastcompany.com/3045509/myths-of-companies-with-no- management)

PS: From my own experience, managers are invaluable at removing distractions, communicating with stakeholders, setting high level priorities, and assisting with career growth. But it's not hard to see the place of frustration where OP's point of view comes from.

</comment><comment><USER69> The article's argument is founded on the idea that non-engineers should not manage engineers. Since this idea reduces to nonsense at the limit, it seems worth being skeptical about it throughout its domain.

Limit: CEO -- it is not possible and no one would seriously suggest that a CEO must be expert in all disciplines they manage. Therefore at some extreme we must admit that functions can be managed by non-experts.

Taken a step down, does the most engineering leader reporting to the CEO need to have been a practicing engineer? If we examine this carefully, this is also a kind of nonsense. Such a person is usually managing a wide array of engineers working across multiple disciplines. We cannot expect them to be an expert in all areas that they manage, given that these will likely include some element of infrastructure, quality, security, performance, front-end, back-end, mobile, and potentially other disciplines. Even if you had a mobile- only team, it's not likely to find a leader who is an expert in both iOS and Android.

Ok, let's go down another level, to a director that manages a given domain of engineering, for instance an iOS engineering team. First of all, at scale most companies I've worked with do not even organize in this way -- they find it most efficient to build high-functioning teams that have most if not all of the disciplines needed to ship product in a given business problem domain. Since this is simply a repeat of the above issue, I won't cover it again, in favor of focusing on the specific issue of someone managing a discipline that isn't matrixed out like this, perhaps a backend infrastructure team. In a reasonably-sized team (50+ engineers), such a person has no time to be actively involved in the development process, and likely has not had time for this in several years at a minimum. Even if they do maintain side projects that use the technologies of the team their efforts are at best dabbling and cannot be compared to someone who is full-time engaged with those technologies. I would not trust such a person to make a reasonable estimate for degree of effort when it comes to any given specific project -- they are simply too far from the current state of the codebase and technology, despite their having been an implementor in the past.

Now we get down to the case of a manager of a team. If they competently manage more than 6-8 or so people they likely have no time free to be actively involved in development and effectively are in the same situation as a director, hopefully with more recent context. If they actively involved in development, then they are probably operating in a role that is best described as "tech-lead / manager". I would trust and expect someone in a role like this to be able to judge level of effort for work their team is doing provided they are actively working in that discipline (cross-discipline teams as described above will include a solid percentage of work that they are likely not expert in).

Hopefully it goes without saying that this is a minority of engineering managers, even correcting for the tree-like structure of most engineering teams.

Finally, as other commenters have pointed out, managers are required to spend a great deal of time (often 100%) in meetings and dealing with personnel issues. These require skills that are not specific to engineering, and as managers grow in their career, they will get stronger in these areas (and weaker in terms of their ability to engage directly with the work that "line" engineers do).

You should work with the grain of a manager's natural skillset trajectory, not against it.</comment>


Today, A '60s Skyscraper Inspired by Frank Lloyd Wright Falls in Texas - <AUTHOR> https://www.citylab.com/design/2019/07/pasadena-skyscraper-demolition-texas-modernist-architecture/594328/ <comment><USER2> It's still possible to visit and even to stay overnight in Frank Lloyd Wright's only skyscraper which is located in Bartlesville, Oklahoma [0].

[0] [http://www.pricetower.org/visit/](http://www.pricetower.org/visit/)

<comment><USER3> Yes, which unlike the building that was demolished, is actually a beautiful and significant piece of architecture.</comment></comment>


[Ask YC - Help]How to build streaming video applications - <AUTHOR>

I have an idea for an application which needs streaming videos, and I am loss where to start readning about it.<p>What are the technologies which I should read up on to build this? <comment><USER2> Adobe's Flash Media Server (expensive licenses, good support), Wowza's Media Server (less expensive licenses, mediocre support), and Red5 (open sourced Java, poor support) are pretty much your main options. FMS has a free version that supports up to 10 simultaneous connections.

IIRC Justin.tv built their own custom RTMP server for their site.

</comment><comment><USER3> Get those videos converted in to .flv format, put up on a webserver somewhere and point a flash video player to it, check this <http://www.jeroenwijering.com/?item=JW_FLV_Player> (when it's up)

like fooblahblah said, if you want want true proper streaming you'll need flash communication server or open sourced red5.

There are many more steps involved but that is the general idea.

</comment><comment><USER4> Streaming video as in user streaming a video file from your server, or streaming live video like on Ustream?

<comment><USER5> Check out Red5. It's an open source Java Flash Media Server replacement.

<comment><USER6> Or Wowza; I've used it and it's great, though it's a pity it's closed source.</comment></comment></comment>


Onswipe Partners With Automattic To Power iPad Traffic  - <AUTHOR> http://blog.onswipe.com/news/onswipe-partners-with-automattic-to-power-ipad-traffic-on-18-6-million-wordpress-com-blogs

<comment><USER2> Jason is the man. He will run through walls and jump over canyons. (HN: he is also #14 on the leaders page: <http://news.ycombinator.com/leaders>)

Last year I met with Jason to discuss the project. When he described it to me, I immediately understood the vision and his goals and plan to get there. When he passed me the iPad with the demo, I was sold. Within 24 hours, I committed to be the first investor. I wrote a quick blurb here: [http://waynechang.com/2011/01/13/proud-to-be-a-part-of- onswi...](http://waynechang.com/2011/01/13/proud-to-be-a-part-of-onswipe/) \- Crazy that post was only two months ago.

<comment><USER3> Wayne, seriously thank you for the faith and being an awesome friend all these years. Everyone here would be lucky to have him as an angel.

</comment></comment><comment><USER4> Jason, this is awesome. So very awesome. I do have two minor complaints/requests:

1\. Custom fonts support. I use two imported fonts from Google Web Fonts on the normal version of my site, and it'd be nice to have them on the mobile version too.

2\. Disqus support. It's a little disheartening to tap View Comments and see "Comments are closed" on every entry, especially when they're not. I'm pretty sure Disqus has a mobile view- I've gotten it when using WPtouch.

Regardless, this is basically the slickest web app interface I've seen on my iPad. (Possibly a bit slow on my iPad 1, but that might just be my server to be honest.) Congrats!

<comment><USER3> 1\. We have all the native iOs fonts. We're working on something cool with typekit :)

2\. is it??? I think it only counts as closed IF the comment count is zero. I use disqus too as does a lot of the world+loves it.

Thank you for the kind words. Wait until you see the newer stuff. We'll be showing it off soon and it's mindblowingly fast/slick.

</comment></comment><comment><USER5> Great news for a very ballsy startup. They haven't been afraid of telling people how swipes are going to replace clicks in most terms. At first I was skeptical, but the move by Wordpress just confirms that they truly have something.

</comment><comment><USER6> Sweet, finally a good wordpress theme for iPad (I know is not just a theme)

<comment><USER3> wait until you see what is coming, it's breathtaking. thank you for the kind words.

</comment></comment><comment><USER7> Awesome progress. Very happy to see this announcement.

Congrats.

</comment><comment><USER8> Just fyi, it seems to be overloaded right now. Cannot load plug.onswipe.com. Kills my site in a normal browser too, not just on the iPad. Is that the expected behavior?

<comment><USER9> Hi, this was unexpected. Everything should be working ok now... thanks! :)

<comment><USER8> Glad you got it sorted out. I just get a blank white screen for my site, but it sounds like it's working fine for others. I reckon I'll try it out again in a bit once some kinks are worked out.

Any reason why visiting a site from a normal browser would still necessitate loading something from plug.onswipe.com? Can't that be excluded, and only loaded when visiting on an iPad?

<comment><USER9> Hi, that behavior doesn't seem related to the plugin. Would you like to share your link anyhow?

</comment></comment></comment></comment><comment><USER10> I don't own any Apple devices to test this but I am curious if they are enabling WYSIWYG post composing on iphone/ipad using native interface somehow?

For some unknown reason Apple does not enable contentEditable (designMode) in mobile Safari for easy WYSIWYG. This is holding back the web to pre-2003 status (IE 5.5 and Firefox 2.0 had contenteditable).

<comment><USER11> we don't do that, but sounds like a good idea for the future :)

</comment></comment><comment><USER12> Looks great, but the default install didn't work on my blog for some reason. I'll have to look into exactly why. I'm on WP 3.1 with a WooThemes theme. (<http://marcusvorwaller.com/blog>)

In any case, I'm excited to use it once I get the kinks worked out, nice work.

<comment><USER13> send me an e-mail to firstname.lastname@example.com

</comment></comment><comment><USER14> Congrats, Jason!

</comment><comment><USER15> It looks great in portrait, but the big empty stripe on the right in landscape is a bit distracting - any reason why you're not using the full width of the screen?

<comment><USER11> Very wide text columns are not very pleasant to read.

relevant: [http://ui.stackexchange.com/questions/3618/ideal-column- widt...](http://ui.stackexchange.com/questions/3618/ideal-column-width-for- paragraphs-online)

</comment></comment><comment><USER16> This is very impressive, but it removes some of the unique personality of individual blogs. As a reader, is there any way to disable it systemwide?

</comment><comment><USER17> Looks nice, but it consistently crashes Safari on my iPad 1 on every blog I tried.

</comment><comment><USER18> Congrats Jason and Andres!

</comment><comment><USER19> How does this plugin handle shortcodes?

<comment><USER13> Should work on the articles, do you have any that don't work?</comment></comment>


In Case You Needed Proof of the Demise of Skeuomorphism - <AUTHOR> http://andysparks.co/post/48803481973/in-case-you-needed-proof-of-the-demise-of-skeuomorphism

<comment><USER2> Lies, damned lies, and, in this case, not even statistics.

To me, the recent drop doesn't look much different from the one around July 2012. It may show some plateau after the initial drop where the July 2012 already started edging upwards, but I doubt any statistical test would support the claim that there is a definite drop recently. But convince me.

</comment><comment><USER3> Subtlepatterns.com is hardly a bastion of skeumorphism. Sure, there are some "realistic" textures there, but they account for probably less than half the textures, and, more importantly, they're not used for UX. The problems with skeumorphism have more to do with confining UX to realistic actions than making things look realistic, and subtlepatterns only barely qualifies for even the second case.</comment>


Google Ranking Factors: 260+ Facts and Myths - <AUTHOR> https://northcutt.com/wr/google-ranking-factors/

<comment><USER2> Bear in mind that though the sources are extremely credible, people in the likes of Matt Cutts and Larry Page are not going to give it all out to you. The key of cracking SEO in my opinion is to play by these rules but also be able find the point where you can slip through the cracks and push it just enough. You need to be able to judge the "probably" and "likely" your own way and make educated guess about the outcome of your strategy. In a way, this makes the game more interesting because there is no longer a blue print that everybody can just follow to rank.</comment>


Pandemic shows demand for autonomous vehicles could be larger than expected - <AUTHOR> https://www.axios.com/self-driving-cars-after-coronavirus-698803d9-94e5-4b8b-8bd0-c4b4a9b250c3.html <comment><USER2> In the future of land transportation, there will be walking, self driving cars, and high speed rail. And nothing else.</comment>