34 ms·

Things I have learnt as the software engineering lead of a multinational

442 points by kuahyeow 9y ago

scarface74 9y ago
Fire people whenever you can. There’s often someone to fire, but not many opportunities to do so. When you are given a lot of opportunities to fire people I like this. Put another way "we are a team not a family." https://www.slideshare.net/reed2001/culture-1798664 https://www.slideshare.net/reed2001/culture-1798664
- Xeoncross 9y ago
  I'm not sure what to do with advice from someone named scarface
  - yoyar 9y ago
    It is a username and not relevant at all.
  - EpicEng 9y ago
    Ok xeoncross
- junkscience2017 9y ago
  You have to be careful. I am currently in an org that has embraced this philosophy. Instead of making the survivors feel valued, it has motivated most of them to move into more stable environments. These employees have dependents and don't like the idea of having their health insurance in play on a daily basis. People read Glassdoor. If your company earns a rep for rapidly and casually dismissing people, you will see good resumes dry up. In our case, the quality of candidates has nosedived. It's not clear why a strong candidate would join a company that opts to fire people so casually.
  - troels 9y ago
    Surely. (Too many) firings have a negative impact on morale. Especially if not done once. I think the point being made though is that it is very uncomfortable to fire people, so managers tend to avoid it, even if it's the right thing to do.
    - scarface74 9y ago
      That was the problem at Yahoo. It's better to have one mass layoff and be done with it instead of having multiple small layoffs.
      - ralfd 9y ago
        Yahoo had a hundred other problems.
        MBCook 9y ago
        Ive been at a company with multiple rounds of small layoffs. Each time they didn’t want to cut too deep or thought ‘maybe this will be enough’. It wasn’t. It was a total moral DISASTER. If you need to cut, cut. But multiple layoffs will kill you.
  - scarface74 9y ago
    On the other hand, if you feel you are a top performer and want to work with other top performers, you wouldn't want to work at a place with mediocre developers. A good developer is not necessarily one that knows everything but has competence and can learn fast. I've worked with smart junior developers and developers with years worth of experience that couldn't cut it when given a novel to them problem.
    - AFNobody 9y ago
      > On the other hand, if you feel you are a top performer and want to work with other top performers, you wouldn't want to work at a place with mediocre developers. This could just be because I'm a mediocre developer (1X) but: 1) Mediocre developers have the ability to consistently produce all the basic non-architectural grunt work in a reasonable amount of time with a reasonable level of quality. Frankly, the "top performers" tend to want to work on high impact/high visibility projects and tend to shirk any grunt work they are given. (i.e. Even something as simple as a combo box that handles shipping I've seen "top performers" repeatedly f up despite me warning them and having to completely scrap their implementations. It isn't that the developer isn't a top performer, they just are not willing to do boring CRUD work and literally every "top performer" I've worked with does that. Management doesn't care because they deliver high quality results on other "new" things but basic maintenance work is simply beneath them both in attitude and the time they commit to the task.) 2) Places that tend to focus on "just hiring top performers" tend to have trouble holding on to top performers as they are usually bribed into leaving if they bother to look around. Mediocre performers might take 12-18 months to get bribed away when interviewing while working. Top performers tend to land a better offer in less than 3 months of interviewing. Places that hire mediocre developers can frequently throw $40k/year + a week of PTO to get them to stay. (i.e A top performer at my last job that I'm friends with got a $40k/year raise in cash, a week of PTO to guarantee they'd stay indefinitely.) 3) Top performers are very good at being an architect, breaking new ground, and/or working on novel problems. They also tend to naturally prioritize high impact/high visibility projects. However, that often comes at the expense of doing routine work correctly and the long term maintainability/stability (as they frequently move on). I've found "Top Performer" is really code for "Person who focuses on getting involved on the highest impact project they can at any given time." And then end up resenting grunt work when such projects are not available to them.
- pizzetta 9y ago
  Companies like Netflix have the cachet and can retain people despite an anti-worker culture. It's also a self selecting group of over-achievers who may like the environment. I'd argue most above average but not stellar workers would not put up with Netflix's implicit demands.
  - scarface74 9y ago
    I would gladly work for a place like Netflix for a year or two, bust my butt, put it on my resume and move on. My market value would make it well worth it.
    - bpchaps 9y ago
      Word of caution from doing exactly that: you're signalling to future employers that that's who you are now, and forever. It's a pathway to burnout if you're not careful.
      - scarface74 9y ago
        If companies don't want good developers to jump ship, it's simple. Pay them market value and keep paying them market value not 2-3% wages when they know if the employee leaves, they are going to have to pay market value and they are going to lose the person with institutional knowledge.
      - sulam 9y ago
        As a long time employee and employer in this industry all it signals to me and people like me is that you managed to survive that environment for two years. The name brand on the resume -is- worth something. Maybe more than it ‘should’ be, but that’s reality. Work at Google for two years and I mostly know you got through a Google interview and you can probably code. Work at Yahoo for 10 years and I know you’re good at politics. Etc. ;)
        bpchaps 9y ago
        There's something depressing about your comment that screams dystopic to me. You're effectively reducing someone's hard work down to notches on a belt. I realize why you do it, but it still rubs me the wrong way. What a boring future we live in. :)
- cpeterso 9y ago
  Company talk about "we are a family" is a red flag for a work environment where people may be pressured to work overtime ("it's more than a job; we're family.") or overlook inappropriate behavior ("that's just how Bob is; we can't fire him because family has got to stick together."). People on a team don't need to be "family" to be respectful and supportive of each other.
- didymospl 9y ago
  This is where I stopped reading. Maybe if you work for Netflix-tier company which swims in the new candidates this makes sense but otherwise it's a great way to get a bad fame and make remaining employees focus only on KPIs to avoid getting fired(Goodbye good code quality, mentoring etc.; Hello "please create a ticket before asking any questions"). Besides, a good organization hires mostly right candidates. Firing should be really exceptional.
- analog31 9y ago
  Unfortunately, "fire fast" is now known widely enough to become a business fad / cargo cult. Which means, people are going to do it because it's the thing to do, and not because there's a good business reason to do it. As a consequence, a company could strategically use "fire fast" by claiming it as a policy but not doing it. This would attract the people who perceive themselves as high performers, with minimal impact on employee morale.
  - kemiller2002 9y ago
    This is true. Sometimes you have to let go of problem employees, but this should really be a last resort. Fire fast doesn't take into multiple considerations, such as the amount domain knowledge does this person possesses. If the person you want to get rid of has been there for 5 years, and knows certain systems in and out it may not be so easy to replace them. Constant firing can also negatively affect your personal reputation. As a manager your job is to get people to succeed. Firing someone means that ultimately you failed in that. Sometimes this is unavoidable; there are times when people just aren't redeemable. Sometimes it's not. Good managers know the difference, but you have to remember that every time you let someone go for cause, that person probably didn't see it that way. That person has friends who work other places and all of them have a long memory. If word gets out that you quickly remove people who you can't seem to handle, people will want to stop working for you.
    - scarface74 9y ago
      If the person you want to get rid of has been there for 5 years, and knows certain systems in and out it may not be so easy to replace them. One of the biggest mistakes a company can make is keeping a toxic employee around because of their domain knowledge. The company I mentioned that I worked for for 9 years made that mistake. The employee had plenty of domain knowledge but was toxic, insubordinate, and displayed a poor work ethic. I know they had to be glad when that employee left on his own accord. That employee was me. I look back on those days in horror.
    - analog31 9y ago
      I've only had a couple of longer term jobs, but at both employers, I noticed that the lowest level workers had a comprehensive oral history of every firing and interesting HR incident that had ever occurred, like an Icelandic saga. And of course it was told from their point of view. So you have to be aware that every firing will be remembered, you will never handle it perfectly, and you don't control the story. A firing has to be worth that price. That's a high bar.
- ken47 9y ago
  That may sound nice to some people on paper, but the reality is that it creates a negative feedback loop. Consider the following review of the company from a senior software engineer. This review is not unique in its opinion: I worked at Netflix full-time (More than 3 years) Pros They pay a ridiculous amount of money. Cons Horrible culture, everyone is afraid they will get fired any second. People hire their own friends/groups or people with less skills/experience so they can defend themselves against weaker employees and throw them under the bus. Lord help you if you don't know anyone when you get hired to form a posse' with. Advice to Management Stop with all your nonsense pitch deck, it's dated, old and you aren't hired the best talent away from Google, FB, Amazon....the sooner you realize you are just a content company, and maybe pay reasonable salaries with reasonable fostering environment the better. Just ask yourself: how many employees would leave if you cut their salary. Probably every one.
  - graycat 9y ago
    Above I mentioned "goal subordination" and claimed that there were good examples suggested in the OP. Well here > Horrible culture, everyone is afraid they will get fired any second. People hire their own friends/groups or people with less skills/experience so they can defend themselves against weaker employees and throw them under the bus. Lord help you if you don't know anyone when you get hired to form a posse' with. Classic goal subordination.
- fahayekwasright 9y ago
  Actually that’s called “bad culture.” Don’t hire people you’ll need to fire.
- starsinspace 9y ago
  If a company has to constantly fire a lot of people - supposedly for not performing well enough - then the company might want to investigate why it's so bad at making people reach their potential. Note: a constantly looming threat of being fired might be involved in it too.
KKKKkkkk1 9y ago
There are some very rare cases where delivery date is more important than what you are delivering, but modern management seems to delight in generalizing this unusual occurrence to every situation. People do get promoted for having been able to deliver completely broken, useless and damaging solutions on time. If that’s the measure of project success you can expect dates to rule (even when they continuously slide). After all, if you are not a trained surgeon, and the only thing you are told is that a given surgery should last no more than X hours, guess what will be the one criterium for all your actions during the operation. I love that metaphor.
- crocal 9y ago
  Yeah but not all things are like surgery. Often, « A good violent attack now is better than a perfect one next week » (George S. Patton)
  - qq66 9y ago
    And, plenty of surgeries are done in situations where speed matters more than the quality of the surgery (emergency tracheotomy, amputation, etc.)
    - dvt 9y ago
      Speed never matters more than the quality of the surgery. You're conflating constraints and criteria. Speed is sometimes a constraint, but never a criteria.
      - brucephillips 9y ago
        Constraints are criteria.
        zbentley 9y ago
        No, they're not. If you violate a constraint, delivery fails. If you pass it, delivery does not necessarily succeed. If you fail to meet a criterion, delivery might fail. If you successfully meet all criteria, this is the definition of successful delivery. Different places may assign different meanings to those terms in project-management speak, but those are the ones I've heard the most.
crocal 9y ago
I have to disagree slightly on the paragraph about dates (#32). Engineers leaders cannot dismiss dates as one of the metric of their performances. The metric is not the goal nor the means in itself, though. In my view, entropic organization and management make this mistake constantly of confusing the metric with the job, like driving a car looking at the speed meter and not at the road (sounds absurd, I know, but is really what happens).
- marcosdumay 9y ago
  I have to completely agree with that paragraph. As long as we are talking about metrics, impact is the one to measure. Ok, if you already are measuring impact and has a correct prioritization of it above anything else, adding delivery date and time spent won't hurt. But if you don't prioritize it above anything else, you are simply begging for a huge failure.
- yoyar 9y ago
  For a competent team, arbitrary dates, generally leaving not enough time, only serve to limit scope. A competent team will produce as fast as is possible, given a specified scope.
  - imiric 9y ago
    Right. I wish more managers/coaches/masters understood this. Features are done when they're done (for a given definition of "done"). Once we're satisfied with what we have, we release it. Otherwise we keep working, or we scope down. Strict deadlines are seemingly based on financial period expectations, rather than on what actually produces better software, and thus, ironically, more revenue for the same stockholders who were demanding a date. It seems more of a short-term strategy than long-term. Anyway, that's my pessimistic, armchair interpretation of it.
  - GordonS 9y ago
    I seem to recall a quote about "works expands to full available time". I know you specifically say "for a competent team", but I just wanted to mention that for a lot of teams, the quote above is absolutely true.
busterarm 9y ago
All of the comments about entropic organizations ring true and hit close to home. Way too close to home.
- marcosdumay 9y ago
  The idea that entropy works on the direction of "hard work -> easy work", instead of "complex work -> simple work" or even "more work -> less work" is a great insight.
  - tenkabuto 9y ago
    Could you please elaborate on this?
    - marcosdumay 9y ago
      The articles has some examples on the difficult -> easy propagation. Like discovering what a company does well and creating a vision that uses it is difficult; joining all current projects and creating a slogan that fits them all to use as a vision is easy. Measuring impact is difficult; setting and measuring deadlines is easy. There is more there. I leads to an "I know it when I see it" understanding. If I tried to compress it into a definition I would certainly miss lots of relevant details, at least without refining it for some time, so I won't.
cbcoutinho 9y ago
I'm a bit confused by the authors use of the words entropy and entropic, starting specifically with this point: > Don’t let entropy get at your daily routine. Avoid entropy-driven work In a physical sense, my understanding of entropy is that it's a degenerative phenomenon, a lowest common denominator - it doesn't create anything. This point means avoiding distracting or sporadic work, which is a test of discipline. But the rest of this point and others further down using words like 'entropy-driven' work are meaningless. I'm sure there's a good point to be made here about valuable work in large corporations, but the (over)use of the word entropy has lost me.
- foobarchu 9y ago
  Entropy is the measure of disorder in a system, so my interpretation here was that you shouldn't take on work that was generated by organizational disorder. An example I have in mind is when someone on the product side asks for a new feature that you know wouldn't take much time at all. Even though you could knock it out quickly, the correct action is to have them go through proper feature request channels.
  - therealdrag0 9y ago
    I get a lot of fulfillment out of knocking out quick features/bugs. Usually I just consider it my "10% time". Is that really a problem as long as I'm not chasing geese all the time?
  - mmcnl 9y ago
    Your example is right on the money. I used to be consumed by organizational disorder, and even worse, wasn't aware that it was happening. Agile is no magic solution but it can be a vehicle to creating organizational order if you need it, especially if it's a hot buzz word in your company.
    - lowbloodsugar 9y ago
      Scrum, if you do it right, is precisely the solution. Scrum specifically rejects the idea of "just doing something on the side". Unfortunately, most organizations believe in cults and magic, and believe (and act) that Scrum is a cargo cult where you say the magic words and hold the magic rituals and get the results.
riffraff 9y ago
OT, but: funny, I felt the name was familiar, and turns out I commented on a post on this blog 12 years ago[0]. A reading lost due to the death of google reader, I presume. [0] How time flies! https://minnenratta.wordpress.com/2005/12/23/le-proporzioni-del-mondo/ https://minnenratta.wordpress.com/2005/12/23/le-proporzioni-...
Bahamut 9y ago
> Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles. I disagree - if you have overworked people, that is usually a red flag that you need more personnel and planning failed. It doesn’t necessarily mean you should be hiring right at the moment, but it is a significant alarm bell that you should seriously consider starting to hire or you’re going to chase away engineers.
- nottorp 9y ago
  That's about where I stopped reading.
- junkscience2017 9y ago
  "18. Don’t shy away from leading without doing, it is unavoidable, so just do it. Then do some work to stay pertinent. 19. If you are not able to hire and fire people, leave. Or stay for the retirement fund if you can stomach it." the way the author discusses people and pretty much everything in the "Yourself" category makes me think this unnamed multinational is a sweatshop overseas. I've worked (temporarily) with people who try to bring this thinking to Silicon Valley
  - sidlls 9y ago
    I got the same sense as you, but without the "overseas" bit. We have sweatshop software shops in the US (look in just about any AAA game company, for example).
  - MBCook 9y ago
    I took #18 as ‘don’t be afraid to delegate, you don’t have to have your finger in everything. #19 makes sense me to too. If you can’t hire/fire then you’re not really in charge. How can you manage your team if other people have the ultimate veto on your strongest management options?
- AnimalMuppet 9y ago
  You either need more people or less work. And having too much work may be because the organization has lost focus on what really matters, and is trying to do everything. You cannot hire enough people to solve that problem, because as you add people, management says "great, now we can do even more..."
cjcenizal 9y ago
Point 1 resonated with me (and its value outweighs that of the others by an order of magnitude IMO): > When the plan is foggy, that’s the moment to communicate as broadly as possible. In fact you should not frame it as a plan, you frame it as the situation and the final state you want to achieve. When you have a detailed plan, that’s when you DON’T need to communicate broadly. So, clearly state the situation and clearly state the foggy goal to everyone who will listen. This is a great way to clarify a complex problem, draw out and resolve disagreements in understanding, enlist others’ help, and methodically arrive at the optimal solution. It also works well for all kinds of problems, whether they be engineering-related, organizational, or interpersonal.
- abraae 9y ago
  This really is an exceptionally good article, written by a pragmatic and insightful student of working life. I have often experienced the following but could never have described it as elegantly: > Incompetence is fiercely gregarious while knowledge is often fractious; the reason for this is that raw ideas transfer more easily through untrained minds than refined ideas transfer through trained minds. There’s a reason why large organisations focus so much on simple messages, pity that difficult problems often have simple solutions that don’t work.
- deleted 9y ago
  [deleted]
AnimalMuppet 9y ago
Teams don’t self-organize unless you organize them to do so. Interesting. I wish there was a bit more detail on how you organize them to do so...
- com2kid 9y ago
  Seating arrangements. Be it putting people who work well together in adjacent offices, or on adjacent tables. Giving people freedom and allowance for failure, not having a strict "I am the boss" micromanaging hierarchy on the team. Reward people for taking initiative. Find work that people want to do, and give them time to do it on their own but only if they self organize all of it, this builds necessary skills. Taking someone who looks like they may have leadership potential aside and asking them to take on a small feature. Combine all these together and you'll come in one day and find your team in a huddle tackling tasks together. Requirements: Not being an insecure manager. Knowing that your value to the team and org is not in telling people what to do, but rather in helping them do what needs to be done. Sometimes this means communicating directives from on high, other times it means getting the team the resources that they've determined they need.
- kuahyeow 9y ago
  Have you read Peopleware ? There's some good gems there
hkarthik 9y ago
> Incompetence is fiercely gregarious while knowledge is often fractious; the reason for this is that raw ideas transfer more easily through untrained minds than refined ideas transfer through trained minds. This resonated with me and definitely gave me food for thought. Raw ideas with uninformed opinions can easily percolate throughout organizations and even across the industry. Feels like something we as a society need to more actively guard against.
- dboreham 9y ago
  I think this explains a great deal and was a concept I had been mulling over myself recently: basically there's an asymmetry in clueffulness that works to propagate cap around much more widely than you'd expect.
BeetleB 9y ago
>Mass emails and top-down communication are not taboo: just because most such communications are irrelevant it doesn’t mean yours will be perceived as such. Mine are always perceived as such :-(
- tinymollusk 9y ago
  Have you considered studying how you communicate? There was something on HN recently titled How to write emails like a CEO (or similar). I studied my old CEO's communication style, holding it up against how many of my peers communicated. I noticed that he got right to the point, expecting other people to assume he considered multiple ancillary points. My (lower status) peers' emails would meander, and read like they wanted to show their superiors how good/smart they were at their job, and that they thought of every last thing. The high status person didn't feel the need to pre-emptively brain dump. My larger point is if your emails are perceived in such a way, it's worth improving.
  - asafira 9y ago
    Along similar lines: I often write an e-mail with all of the information I want to include, and read it over and edit it several times to cut down on things that aren't necessary. The unnecessary things can be as simple as an awkward prepositional phrase, but often they are a technicality that is hogging too much space in the e-mail. I personally think this really improves my communication. In a workplace where people are expected to read through dozens of emails each day, it makes a difference in the information that's finally conveyed to my colleagues, which is often what matters the most to me.
    - tinymollusk 9y ago
      Great point. I wonder how often people shoot emails out without serious editing.
  - BeetleB 9y ago
    >My (lower status) peers' emails would meander, and read like they wanted to show their superiors how good/smart they were at their job, and that they thought of every last thing. The last part is key. If I don't list the things I've thought off, and write a briefer email, I guarantee I will get any of the following: 1. Followup emails with questions because they don't understand. 2. Emails of the type "Did you consider...?". This is the primary reason my emails can be lengthy, so that I can list all the things I considered so that I don't get questions asking about them. 3. Even worse, people not emailing me, but with them misunderstanding and doing the wrong thing, and then saying "Well I thought you meant..." leading me to ask "Where in my email did you get the idea that...?" Do note that I'm not in a "superior" position. These are mostly emails to peers.
scrame 9y ago
"When the plan is foggy, that’s the moment to communicate as broadly as possible." Here's a good rule of thumb: Ask them to explain what has to be done, and then count the number of times they say "it should be pretty straightforward". Consider those multipliers of complexity.
- dudul 9y ago
  I apply a similar algorithm, except I use the word "just" as variable. As in "we could just stick this in a DB", or "isn't it just about adding a checkbox to the page?"
  - zitterbewegung 9y ago
    Using Just and extremely easy should be where you make a milestone for each statement(s) after that .
  - sopooneo 9y ago
    Absolutely agree. I had come to the same conclusion about the same term. I had thought to call it "just-ifying", but then I remember that is already a real word.
- jschwartzi 9y ago
  Or measure how annoyed they are when you ask them to go into specifics about what they expect.
- TheAceOfHearts 9y ago
  Relevant XKCD [0]. Lots of topics vary wildly in complexity, depending on what's actually expected of the developer. For example, I could see how implementing an authentication system might take as little as a few hours to as much as a few months. I think developers sometimes get overconfident when they can just reach for a library to do anything they need, so they underestimate the complexity of having to implement everything themselves. I've seen tons of great examples of this while doing frontend work. Need a typeahead component? Just pull in some plugin or library and wire it up, frontend development is so easy! But if you actually go implement your own you quickly realize there's lots of details to consider in order to make it accessible and user-friendly. Working with local data? Might want to go brush up on search algorithms. Throw in a bit of extra fun if you need to support multiple languages. [0] https://xkcd.com/1425/ https://xkcd.com/1425/
sam0x17 9y ago
Thing one: use "learnt" instead of "learned" to sound multinational. ;)
- programmer_dude 9y ago
  So it is true Americans don't use past participles?
  - sam0x17 9y ago
    At least in this case yes. For us the past participle would simply be "learned"
zbentley 9y ago
> Teams don’t self-organize unless you organize them to do so. ...or, teams self-organize unless you have organized them not to, in which case, if you want them to self-organize, you have to hire an Agile coach and start putting up posters telling people what it means to be "self directed" and fire everyone who is insufficiently short-term in their thinking. /s
rasta78 9y ago
Looking at things related to Entropy I can can clearly see the company I'm working for(which is sad).Considering that I'm not at leadership position, my next action is to quit and find a better one.
- MBCook 9y ago
  It really resonates with me and a job I used to have too.
knieveltech 9y ago
"Being overworked is not a good reason to hire." Because the world certainly needs more sociopathic management advice.
- claudiulodro 9y ago
  Theoretically, it might not be a good reason to hire. Maybe the problem is bad planning or project management. Hiring more people won't really solve that. But, in general, I agree with you.
- jayd16 9y ago
  Rereading the advice, I think he means hire before you get to overworked. I agree it's phrased poorly.
  - ckip 9y ago
    I agree with his advice and not yours. Good candidates are a good reason to hire. Overworked is a good reason to reexamine priorities.
- egor598 9y ago
  The way I understood this: "If you are overworked, first look at your team, is everyone at their place and pulling their weight, evaluate your deadlines and promises, check your planning and management and your relationship with stakeholders. Because most of the times it's one of those things that's broken and probably affects the rest".
- mmcnl 9y ago
  That's your (negative) take on it. You can do something about being overworked without hiring (evaluate deadlines and scope, learn to say no). There's a good chance that hiring people without establishing the underlying cause of "being overworked" will only lead to more people being overworked. If you're hiring because of "being overworked", you're hiring too late.
egor598 9y ago
>>Construction work is not a good metaphor for software/product development. Factory work neither. I like this, really fed up with everyone comparing software development with construction work and/or building a house. Don't compare those, apples to oranges. Sure, borrow the best, most appropriate things, techniques, methodologies, approaches and not just from construction. Just don't compare.
- mmcnl 9y ago
  Avoid metaphors in general. In my experience, metaphors lead to discussion about the correctness of the metaphor instead of the subject the metaphor was referring to. This is a waste of time.
asafira 9y ago
Most people are commenting on what bullet points they agreed or disagreed most with. I am sure, however, that there are other software engineering leads on HN --- what other lessons have you learned, and/or what were the best resources to learn them (if not just experience).
lifeisstillgood 9y ago
Interestingly he (she?) seems confused and rage driven (!) over entropic organisations - i think the main issue with entropic organisations is simply size - there is no organisational approach that can ever make hundreds of thousands of people co-ordinate in a positive manner. we don't lack the technology, just that there is no good strategy at that level.
tempodox 9y ago
This list made me realize I have only ever seen Entropic Organizations. Is there even any other kind?
OJFord 9y ago
Title whinge: a multinational what? (That's not intended as a pedant's review of the article, just a note on the title presented on HN, which was praised in a recent thread for making even small changes to improve the grammar and quality of the site.)
- dragonwriter 9y ago
  “Multinational” is in regular use (reflected in most current dictionaries) as a standalone noun with an equivalent meaning to the noun phrase “multinational corporation”.
deleted 9y ago
[deleted]
mikeokner 9y ago
> If you feel like you don’t know what you are doing it’s probably because you don’t know what you are doing and that’s bad. I think this one depends on one's personality. I know people who have been relatively successful in their role for years who still regularly express impostor syndrome.
- deleted 9y ago
  [deleted]
misterbowfinger 9y ago
Favorite quote: > Delivery dates have often irrelevant but very simple to understand impacts. Good and bad solutions have dramatic but very difficult to understand impacts.
0xFFFE 9y ago
Nitpicking. > 20. The Sith are right, rage propels. But the Jedi are right, you must not let it control yourself. What nobody tells you is that the rage game is intrinsically tiring and rage will take control as soon as you get too tired, so stop well before. 37. Don't assume everyone reading your article gets the Star Wars reference.
- tsomctl 9y ago
  Speaking as someone that has never seen Star Wars, I still get his point.
nickthemagicman 9y ago
I'm not sure if this is brilliant advice or really bad advice.
programmer_dude 9y ago
The article is too abstract for me. I don't have enough leadership experience to relate to what is being said. I'd be grateful if someone could rewrite this article with some concrete examples. I am sure there are many others in the same boat as I am. They will find this useful too.
- reilly3000 9y ago
  Getting lots of people together to work on a large problem is an engineering problem in itself. It has its own language and constructs. Doing it wrong means millions or billions are wasted, and enterprises lose ground on the world stage. Some of these ideals don’t translate well to smaller scale. A 5 person team doesn’t have to work out much except the work. How do you get 1000 people to agree on a plan, an IDE, a language, and to row in the same direction? Not magic. Study and practice.
- graycat 9y ago
  Sadly, you are correct. You need some experience. "Experience is the great teacher, and some will learn from no other." In my career, I've seen shocking, astounding, career, organization, and company threatening examples of nearly everything he mentions, and to me his reactions are terrific and make a lot of sense. But, likely as you mentioned, need lots of real world examples from which he has extracted general, "abstract" lessons. He has terrific stuff. He is an excellent observer and, then, analyst of what the heck he saw. I put the text in my collection of management essays and regard it as by a wide margin the best management advice I've found for my startup: Currently I'm a sole, solo founder, so far have done it all, including all the important work and a lot of grunt work, but if my startup is successful then I'll have to hire and manage, all of it. Sure, eventually I'll get a COO and delegate a lot to them, but, still I'll have to know what's going on. And there will have to be more software development; I'll have to manage that either directly or through, say, a CTO or CIO, and that essay is the best advice I've seen so far. Other good advice is in Brooks, The Mythical Man-Month. Brooks is deeper in technical issues; the OP is better in the human and management issues which, IMHO, is where the real problems really are. Oh, by the way, I still believe that nearly all the best ideas in software management I've heard about are old (although I do have along list of questions where the old stuff doesn't give good answers and where I haven't seen good answers either old or new). So, e.g., I have essentially no faith in "agile" or "object-oriented". And I believe that (A) code without good documentation is essentially worthless, (B) the documentation is more work than the code, and (C) between the code and the documentation, if I had to save just one, it would be the documentation. So, in particular, for the work, the most important part of it is writing documentation; writing the code is the lesser part. And (D) my view of writing code is that it's simple: Start with a good description of (i) the programming language to be used and (ii) good descriptions of the functions, classes, APIs, etc. to be used, and between these two by far the more difficult is (ii). [No, right, usually it's not automatically simple, not at all; instead, in the end it should look and be simple, and that can take a lot of hard work.] Then from the documentation get the really crucial stuff -- what the heck the code is to do. It is the documentation that makes clear the issues of threading, locking, roll back, exceptional condition handling from small scale to large, the UI/UX, etc. Those issues are to be clear in appropriate parts of the documentation and not to be worked out only during the coding. So, e.g., try to get most of the coding down to (a) allocate storage, (b) the usual control structures if-then-else, do-while, select-when, (c) call-return, (d) clear architecture on exceptional condition handling, logging, etc., and (e) the functions, classes, APIs, etc. From what I learned from before the OP, although the OP has it better but maybe not as explicit, here are two lessons: First Lesson. "Why should I"? If you see a person in an organization and some work they might do, ideas they might have, etc. you have to ask the question, how will that person answer the question "Why should I". What's important here for a manager is not how YOU would answer this question but how you would anticipate that subordinate, other person, would answer the question. To be cynical, just because some area A is in the person's area of work, for some work X, will they actually do X and do it well? First way to know is, how would that person answer "Why should I do X"? To be cynical and likely often realistic, without a good answer, the person may simply neglect to do X. E.g., there is the old Ross Perot joke: Most organizations, when they see a snake, form a committee on snakes. In a good organization, when someone sees a snake, they kill it. Well, then, the answer to "Why should I kill the snake" is that Perot had a good organization. Second Lesson. There is a field, with courses, in public administration, business schools, and parts of sociology called organizational behavior. There one of the better ideas is goal subordination. Well, the OP is awash in cases of goal subordination. The idea of goal subordination, and common for middle managers, is to "subordinate" the "goals" of the organization to the "goals" of that middle manager. So, the manager does what he believes is good for his career even if it is bad for the organization. So, an exercise is to read the OP essay and list and explain the places where the author is suggesting goal subordination. There's much more to say, but, trust me, the OP is talking about stuff that is darned real. For me, I want my startup to work. A big, huge advantage of being founder and 100% owner is that I don't have to explain stuff to some BoD that, as in the OP, has no chance of understanding reality. So, I'd constantly have to create "company theater" for the BoD, and that would be so wasteful it could kill my company. My point here generalizes and is generalized in the OP: The crucial details of a serious real problem and its best solution are typically too difficult for communicating up a management chain or even just from a CEO to a BoD. The OP is correct. So, as sole founder and 100% owner, I don't have to try to communicate to a BoD that has no hope of understanding or waste effort on company theater. Instead, I just concentrate on making my company successful. If I am successful, then the main evidence visible externally will be just the financial, brand, etc. success, a lot of which the news media will likely heavily distort; the real reason the company was successful will be known just to me and maybe a COO or CTO if I get really good ones.
koonsolo 9y ago
Nice list, although I was horrified by one (sorry to need to pick on the one thing that was bad): >Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles. That's why we as programmers should say no to overwork, because only then will they see the need to hire. I only do overwork when some unexpected disaster happens, or when there is a sudden huge opportunity. In the other cases, they should plan better or hire more people, simple as that.
- mmcnl 9y ago
  > 24. Don’t let entropy get at your daily routine. Avoid entropy-driven work. Your anecdote is rule 24 in practice. Good job.
tboyd47 9y ago
> People appreciate when you fire the right people, so don’t worry about morale. When you select for sociopaths, you get sociopaths.
xamde 9y ago
A great article mostly nailing problem descriptions. This is usually represented too briefly. I believe “The Entropic Organization” (Teo) would be a highly cited book, cited by all kinds of management books emphasizing the solutions. Please, write TEO.

442 points by kuahyeow 9y ago

Fire people whenever you can. There’s often someone to fire, but not many opportunities to do so. When you are given a lot of opportunities to fire people I like this. Put another way "we are a team not a family." https://www.slideshare.net/reed2001/culture-1798664 https://www.slideshare.net/reed2001/culture-1798664

Xeoncross 9y ago
I'm not sure what to do with advice from someone named scarface
- yoyar 9y ago
  It is a username and not relevant at all.
- EpicEng 9y ago
  Ok xeoncross
junkscience2017 9y ago
You have to be careful. I am currently in an org that has embraced this philosophy. Instead of making the survivors feel valued, it has motivated most of them to move into more stable environments. These employees have dependents and don't like the idea of having their health insurance in play on a daily basis. People read Glassdoor. If your company earns a rep for rapidly and casually dismissing people, you will see good resumes dry up. In our case, the quality of candidates has nosedived. It's not clear why a strong candidate would join a company that opts to fire people so casually.
- troels 9y ago
  Surely. (Too many) firings have a negative impact on morale. Especially if not done once. I think the point being made though is that it is very uncomfortable to fire people, so managers tend to avoid it, even if it's the right thing to do.
  - scarface74 9y ago
    That was the problem at Yahoo. It's better to have one mass layoff and be done with it instead of having multiple small layoffs.
    - ralfd 9y ago
      Yahoo had a hundred other problems.
      - MBCook 9y ago
        Ive been at a company with multiple rounds of small layoffs. Each time they didn’t want to cut too deep or thought ‘maybe this will be enough’. It wasn’t. It was a total moral DISASTER. If you need to cut, cut. But multiple layoffs will kill you.
- scarface74 9y ago
  On the other hand, if you feel you are a top performer and want to work with other top performers, you wouldn't want to work at a place with mediocre developers. A good developer is not necessarily one that knows everything but has competence and can learn fast. I've worked with smart junior developers and developers with years worth of experience that couldn't cut it when given a novel to them problem.
  - AFNobody 9y ago
    > On the other hand, if you feel you are a top performer and want to work with other top performers, you wouldn't want to work at a place with mediocre developers. This could just be because I'm a mediocre developer (1X) but: 1) Mediocre developers have the ability to consistently produce all the basic non-architectural grunt work in a reasonable amount of time with a reasonable level of quality. Frankly, the "top performers" tend to want to work on high impact/high visibility projects and tend to shirk any grunt work they are given. (i.e. Even something as simple as a combo box that handles shipping I've seen "top performers" repeatedly f up despite me warning them and having to completely scrap their implementations. It isn't that the developer isn't a top performer, they just are not willing to do boring CRUD work and literally every "top performer" I've worked with does that. Management doesn't care because they deliver high quality results on other "new" things but basic maintenance work is simply beneath them both in attitude and the time they commit to the task.) 2) Places that tend to focus on "just hiring top performers" tend to have trouble holding on to top performers as they are usually bribed into leaving if they bother to look around. Mediocre performers might take 12-18 months to get bribed away when interviewing while working. Top performers tend to land a better offer in less than 3 months of interviewing. Places that hire mediocre developers can frequently throw $40k/year + a week of PTO to get them to stay. (i.e A top performer at my last job that I'm friends with got a $40k/year raise in cash, a week of PTO to guarantee they'd stay indefinitely.) 3) Top performers are very good at being an architect, breaking new ground, and/or working on novel problems. They also tend to naturally prioritize high impact/high visibility projects. However, that often comes at the expense of doing routine work correctly and the long term maintainability/stability (as they frequently move on). I've found "Top Performer" is really code for "Person who focuses on getting involved on the highest impact project they can at any given time." And then end up resenting grunt work when such projects are not available to them.
pizzetta 9y ago
Companies like Netflix have the cachet and can retain people despite an anti-worker culture. It's also a self selecting group of over-achievers who may like the environment. I'd argue most above average but not stellar workers would not put up with Netflix's implicit demands.
- scarface74 9y ago
  I would gladly work for a place like Netflix for a year or two, bust my butt, put it on my resume and move on. My market value would make it well worth it.
  - bpchaps 9y ago
    Word of caution from doing exactly that: you're signalling to future employers that that's who you are now, and forever. It's a pathway to burnout if you're not careful.
    - scarface74 9y ago
      If companies don't want good developers to jump ship, it's simple. Pay them market value and keep paying them market value not 2-3% wages when they know if the employee leaves, they are going to have to pay market value and they are going to lose the person with institutional knowledge.
    - sulam 9y ago
      As a long time employee and employer in this industry all it signals to me and people like me is that you managed to survive that environment for two years. The name brand on the resume -is- worth something. Maybe more than it ‘should’ be, but that’s reality. Work at Google for two years and I mostly know you got through a Google interview and you can probably code. Work at Yahoo for 10 years and I know you’re good at politics. Etc. ;)
      - bpchaps 9y ago
        There's something depressing about your comment that screams dystopic to me. You're effectively reducing someone's hard work down to notches on a belt. I realize why you do it, but it still rubs me the wrong way. What a boring future we live in. :)
cpeterso 9y ago
Company talk about "we are a family" is a red flag for a work environment where people may be pressured to work overtime ("it's more than a job; we're family.") or overlook inappropriate behavior ("that's just how Bob is; we can't fire him because family has got to stick together."). People on a team don't need to be "family" to be respectful and supportive of each other.
didymospl 9y ago
This is where I stopped reading. Maybe if you work for Netflix-tier company which swims in the new candidates this makes sense but otherwise it's a great way to get a bad fame and make remaining employees focus only on KPIs to avoid getting fired(Goodbye good code quality, mentoring etc.; Hello "please create a ticket before asking any questions"). Besides, a good organization hires mostly right candidates. Firing should be really exceptional.
analog31 9y ago
Unfortunately, "fire fast" is now known widely enough to become a business fad / cargo cult. Which means, people are going to do it because it's the thing to do, and not because there's a good business reason to do it. As a consequence, a company could strategically use "fire fast" by claiming it as a policy but not doing it. This would attract the people who perceive themselves as high performers, with minimal impact on employee morale.
- kemiller2002 9y ago
  This is true. Sometimes you have to let go of problem employees, but this should really be a last resort. Fire fast doesn't take into multiple considerations, such as the amount domain knowledge does this person possesses. If the person you want to get rid of has been there for 5 years, and knows certain systems in and out it may not be so easy to replace them. Constant firing can also negatively affect your personal reputation. As a manager your job is to get people to succeed. Firing someone means that ultimately you failed in that. Sometimes this is unavoidable; there are times when people just aren't redeemable. Sometimes it's not. Good managers know the difference, but you have to remember that every time you let someone go for cause, that person probably didn't see it that way. That person has friends who work other places and all of them have a long memory. If word gets out that you quickly remove people who you can't seem to handle, people will want to stop working for you.
  - scarface74 9y ago
    If the person you want to get rid of has been there for 5 years, and knows certain systems in and out it may not be so easy to replace them. One of the biggest mistakes a company can make is keeping a toxic employee around because of their domain knowledge. The company I mentioned that I worked for for 9 years made that mistake. The employee had plenty of domain knowledge but was toxic, insubordinate, and displayed a poor work ethic. I know they had to be glad when that employee left on his own accord. That employee was me. I look back on those days in horror.
  - analog31 9y ago
    I've only had a couple of longer term jobs, but at both employers, I noticed that the lowest level workers had a comprehensive oral history of every firing and interesting HR incident that had ever occurred, like an Icelandic saga. And of course it was told from their point of view. So you have to be aware that every firing will be remembered, you will never handle it perfectly, and you don't control the story. A firing has to be worth that price. That's a high bar.
ken47 9y ago
That may sound nice to some people on paper, but the reality is that it creates a negative feedback loop. Consider the following review of the company from a senior software engineer. This review is not unique in its opinion: I worked at Netflix full-time (More than 3 years) Pros They pay a ridiculous amount of money. Cons Horrible culture, everyone is afraid they will get fired any second. People hire their own friends/groups or people with less skills/experience so they can defend themselves against weaker employees and throw them under the bus. Lord help you if you don't know anyone when you get hired to form a posse' with. Advice to Management Stop with all your nonsense pitch deck, it's dated, old and you aren't hired the best talent away from Google, FB, Amazon....the sooner you realize you are just a content company, and maybe pay reasonable salaries with reasonable fostering environment the better. Just ask yourself: how many employees would leave if you cut their salary. Probably every one.
- graycat 9y ago
  Above I mentioned "goal subordination" and claimed that there were good examples suggested in the OP. Well here > Horrible culture, everyone is afraid they will get fired any second. People hire their own friends/groups or people with less skills/experience so they can defend themselves against weaker employees and throw them under the bus. Lord help you if you don't know anyone when you get hired to form a posse' with. Classic goal subordination.
fahayekwasright 9y ago
Actually that’s called “bad culture.” Don’t hire people you’ll need to fire.
starsinspace 9y ago
If a company has to constantly fire a lot of people - supposedly for not performing well enough - then the company might want to investigate why it's so bad at making people reach their potential. Note: a constantly looming threat of being fired might be involved in it too.

KKKKkkkk1 9y ago

There are some very rare cases where delivery date is more important than what you are delivering, but modern management seems to delight in generalizing this unusual occurrence to every situation. People do get promoted for having been able to deliver completely broken, useless and damaging solutions on time. If that’s the measure of project success you can expect dates to rule (even when they continuously slide). After all, if you are not a trained surgeon, and the only thing you are told is that a given surgery should last no more than X hours, guess what will be the one criterium for all your actions during the operation. I love that metaphor.

crocal 9y ago
Yeah but not all things are like surgery. Often, « A good violent attack now is better than a perfect one next week » (George S. Patton)
- qq66 9y ago
  And, plenty of surgeries are done in situations where speed matters more than the quality of the surgery (emergency tracheotomy, amputation, etc.)
  - dvt 9y ago
    Speed never matters more than the quality of the surgery. You're conflating constraints and criteria. Speed is sometimes a constraint, but never a criteria.
    - brucephillips 9y ago
      Constraints are criteria.
      - zbentley 9y ago
        No, they're not. If you violate a constraint, delivery fails. If you pass it, delivery does not necessarily succeed. If you fail to meet a criterion, delivery might fail. If you successfully meet all criteria, this is the definition of successful delivery. Different places may assign different meanings to those terms in project-management speak, but those are the ones I've heard the most.

crocal 9y ago

I have to disagree slightly on the paragraph about dates (#32). Engineers leaders cannot dismiss dates as one of the metric of their performances. The metric is not the goal nor the means in itself, though. In my view, entropic organization and management make this mistake constantly of confusing the metric with the job, like driving a car looking at the speed meter and not at the road (sounds absurd, I know, but is really what happens).

marcosdumay 9y ago
I have to completely agree with that paragraph. As long as we are talking about metrics, impact is the one to measure. Ok, if you already are measuring impact and has a correct prioritization of it above anything else, adding delivery date and time spent won't hurt. But if you don't prioritize it above anything else, you are simply begging for a huge failure.
yoyar 9y ago
For a competent team, arbitrary dates, generally leaving not enough time, only serve to limit scope. A competent team will produce as fast as is possible, given a specified scope.
- imiric 9y ago
  Right. I wish more managers/coaches/masters understood this. Features are done when they're done (for a given definition of "done"). Once we're satisfied with what we have, we release it. Otherwise we keep working, or we scope down. Strict deadlines are seemingly based on financial period expectations, rather than on what actually produces better software, and thus, ironically, more revenue for the same stockholders who were demanding a date. It seems more of a short-term strategy than long-term. Anyway, that's my pessimistic, armchair interpretation of it.
- GordonS 9y ago
  I seem to recall a quote about "works expands to full available time". I know you specifically say "for a competent team", but I just wanted to mention that for a lot of teams, the quote above is absolutely true.

busterarm 9y ago

All of the comments about entropic organizations ring true and hit close to home. Way too close to home.

marcosdumay 9y ago
The idea that entropy works on the direction of "hard work -> easy work", instead of "complex work -> simple work" or even "more work -> less work" is a great insight.
- tenkabuto 9y ago
  Could you please elaborate on this?
  - marcosdumay 9y ago
    The articles has some examples on the difficult -> easy propagation. Like discovering what a company does well and creating a vision that uses it is difficult; joining all current projects and creating a slogan that fits them all to use as a vision is easy. Measuring impact is difficult; setting and measuring deadlines is easy. There is more there. I leads to an "I know it when I see it" understanding. If I tried to compress it into a definition I would certainly miss lots of relevant details, at least without refining it for some time, so I won't.

cbcoutinho 9y ago

I'm a bit confused by the authors use of the words entropy and entropic, starting specifically with this point: > Don’t let entropy get at your daily routine. Avoid entropy-driven work In a physical sense, my understanding of entropy is that it's a degenerative phenomenon, a lowest common denominator - it doesn't create anything. This point means avoiding distracting or sporadic work, which is a test of discipline. But the rest of this point and others further down using words like 'entropy-driven' work are meaningless. I'm sure there's a good point to be made here about valuable work in large corporations, but the (over)use of the word entropy has lost me.

foobarchu 9y ago
Entropy is the measure of disorder in a system, so my interpretation here was that you shouldn't take on work that was generated by organizational disorder. An example I have in mind is when someone on the product side asks for a new feature that you know wouldn't take much time at all. Even though you could knock it out quickly, the correct action is to have them go through proper feature request channels.
- therealdrag0 9y ago
  I get a lot of fulfillment out of knocking out quick features/bugs. Usually I just consider it my "10% time". Is that really a problem as long as I'm not chasing geese all the time?
- mmcnl 9y ago
  Your example is right on the money. I used to be consumed by organizational disorder, and even worse, wasn't aware that it was happening. Agile is no magic solution but it can be a vehicle to creating organizational order if you need it, especially if it's a hot buzz word in your company.
  - lowbloodsugar 9y ago
    Scrum, if you do it right, is precisely the solution. Scrum specifically rejects the idea of "just doing something on the side". Unfortunately, most organizations believe in cults and magic, and believe (and act) that Scrum is a cargo cult where you say the magic words and hold the magic rituals and get the results.

riffraff 9y ago

OT, but: funny, I felt the name was familiar, and turns out I commented on a post on this blog 12 years ago[0]. A reading lost due to the death of google reader, I presume. [0] How time flies! https://minnenratta.wordpress.com/2005/12/23/le-proporzioni-del-mondo/ https://minnenratta.wordpress.com/2005/12/23/le-proporzioni-...

Bahamut 9y ago

> Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles. I disagree - if you have overworked people, that is usually a red flag that you need more personnel and planning failed. It doesn’t necessarily mean you should be hiring right at the moment, but it is a significant alarm bell that you should seriously consider starting to hire or you’re going to chase away engineers.

nottorp 9y ago
That's about where I stopped reading.
junkscience2017 9y ago
"18. Don’t shy away from leading without doing, it is unavoidable, so just do it. Then do some work to stay pertinent. 19. If you are not able to hire and fire people, leave. Or stay for the retirement fund if you can stomach it." the way the author discusses people and pretty much everything in the "Yourself" category makes me think this unnamed multinational is a sweatshop overseas. I've worked (temporarily) with people who try to bring this thinking to Silicon Valley
- sidlls 9y ago
  I got the same sense as you, but without the "overseas" bit. We have sweatshop software shops in the US (look in just about any AAA game company, for example).
- MBCook 9y ago
  I took #18 as ‘don’t be afraid to delegate, you don’t have to have your finger in everything. #19 makes sense me to too. If you can’t hire/fire then you’re not really in charge. How can you manage your team if other people have the ultimate veto on your strongest management options?
AnimalMuppet 9y ago
You either need more people or less work. And having too much work may be because the organization has lost focus on what really matters, and is trying to do everything. You cannot hire enough people to solve that problem, because as you add people, management says "great, now we can do even more..."

cjcenizal 9y ago

Point 1 resonated with me (and its value outweighs that of the others by an order of magnitude IMO): > When the plan is foggy, that’s the moment to communicate as broadly as possible. In fact you should not frame it as a plan, you frame it as the situation and the final state you want to achieve. When you have a detailed plan, that’s when you DON’T need to communicate broadly. So, clearly state the situation and clearly state the foggy goal to everyone who will listen. This is a great way to clarify a complex problem, draw out and resolve disagreements in understanding, enlist others’ help, and methodically arrive at the optimal solution. It also works well for all kinds of problems, whether they be engineering-related, organizational, or interpersonal.

abraae 9y ago
This really is an exceptionally good article, written by a pragmatic and insightful student of working life. I have often experienced the following but could never have described it as elegantly: > Incompetence is fiercely gregarious while knowledge is often fractious; the reason for this is that raw ideas transfer more easily through untrained minds than refined ideas transfer through trained minds. There’s a reason why large organisations focus so much on simple messages, pity that difficult problems often have simple solutions that don’t work.
deleted 9y ago
[deleted]

AnimalMuppet 9y ago

Teams don’t self-organize unless you organize them to do so. Interesting. I wish there was a bit more detail on how you organize them to do so...

com2kid 9y ago
Seating arrangements. Be it putting people who work well together in adjacent offices, or on adjacent tables. Giving people freedom and allowance for failure, not having a strict "I am the boss" micromanaging hierarchy on the team. Reward people for taking initiative. Find work that people want to do, and give them time to do it on their own but only if they self organize all of it, this builds necessary skills. Taking someone who looks like they may have leadership potential aside and asking them to take on a small feature. Combine all these together and you'll come in one day and find your team in a huddle tackling tasks together. Requirements: Not being an insecure manager. Knowing that your value to the team and org is not in telling people what to do, but rather in helping them do what needs to be done. Sometimes this means communicating directives from on high, other times it means getting the team the resources that they've determined they need.
kuahyeow 9y ago
Have you read Peopleware ? There's some good gems there

hkarthik 9y ago

> Incompetence is fiercely gregarious while knowledge is often fractious; the reason for this is that raw ideas transfer more easily through untrained minds than refined ideas transfer through trained minds. This resonated with me and definitely gave me food for thought. Raw ideas with uninformed opinions can easily percolate throughout organizations and even across the industry. Feels like something we as a society need to more actively guard against.

dboreham 9y ago
I think this explains a great deal and was a concept I had been mulling over myself recently: basically there's an asymmetry in clueffulness that works to propagate cap around much more widely than you'd expect.

BeetleB 9y ago

>Mass emails and top-down communication are not taboo: just because most such communications are irrelevant it doesn’t mean yours will be perceived as such. Mine are always perceived as such :-(

tinymollusk 9y ago
Have you considered studying how you communicate? There was something on HN recently titled How to write emails like a CEO (or similar). I studied my old CEO's communication style, holding it up against how many of my peers communicated. I noticed that he got right to the point, expecting other people to assume he considered multiple ancillary points. My (lower status) peers' emails would meander, and read like they wanted to show their superiors how good/smart they were at their job, and that they thought of every last thing. The high status person didn't feel the need to pre-emptively brain dump. My larger point is if your emails are perceived in such a way, it's worth improving.
- asafira 9y ago
  Along similar lines: I often write an e-mail with all of the information I want to include, and read it over and edit it several times to cut down on things that aren't necessary. The unnecessary things can be as simple as an awkward prepositional phrase, but often they are a technicality that is hogging too much space in the e-mail. I personally think this really improves my communication. In a workplace where people are expected to read through dozens of emails each day, it makes a difference in the information that's finally conveyed to my colleagues, which is often what matters the most to me.
  - tinymollusk 9y ago
    Great point. I wonder how often people shoot emails out without serious editing.
- BeetleB 9y ago
  >My (lower status) peers' emails would meander, and read like they wanted to show their superiors how good/smart they were at their job, and that they thought of every last thing. The last part is key. If I don't list the things I've thought off, and write a briefer email, I guarantee I will get any of the following: 1. Followup emails with questions because they don't understand. 2. Emails of the type "Did you consider...?". This is the primary reason my emails can be lengthy, so that I can list all the things I considered so that I don't get questions asking about them. 3. Even worse, people not emailing me, but with them misunderstanding and doing the wrong thing, and then saying "Well I thought you meant..." leading me to ask "Where in my email did you get the idea that...?" Do note that I'm not in a "superior" position. These are mostly emails to peers.

scrame 9y ago

"When the plan is foggy, that’s the moment to communicate as broadly as possible." Here's a good rule of thumb: Ask them to explain what has to be done, and then count the number of times they say "it should be pretty straightforward". Consider those multipliers of complexity.

dudul 9y ago
I apply a similar algorithm, except I use the word "just" as variable. As in "we could just stick this in a DB", or "isn't it just about adding a checkbox to the page?"
- zitterbewegung 9y ago
  Using Just and extremely easy should be where you make a milestone for each statement(s) after that .
- sopooneo 9y ago
  Absolutely agree. I had come to the same conclusion about the same term. I had thought to call it "just-ifying", but then I remember that is already a real word.
jschwartzi 9y ago
Or measure how annoyed they are when you ask them to go into specifics about what they expect.
TheAceOfHearts 9y ago
Relevant XKCD [0]. Lots of topics vary wildly in complexity, depending on what's actually expected of the developer. For example, I could see how implementing an authentication system might take as little as a few hours to as much as a few months. I think developers sometimes get overconfident when they can just reach for a library to do anything they need, so they underestimate the complexity of having to implement everything themselves. I've seen tons of great examples of this while doing frontend work. Need a typeahead component? Just pull in some plugin or library and wire it up, frontend development is so easy! But if you actually go implement your own you quickly realize there's lots of details to consider in order to make it accessible and user-friendly. Working with local data? Might want to go brush up on search algorithms. Throw in a bit of extra fun if you need to support multiple languages. [0] https://xkcd.com/1425/ https://xkcd.com/1425/

sam0x17 9y ago

Thing one: use "learnt" instead of "learned" to sound multinational. ;)

programmer_dude 9y ago
So it is true Americans don't use past participles?
- sam0x17 9y ago
  At least in this case yes. For us the past participle would simply be "learned"

zbentley 9y ago

> Teams don’t self-organize unless you organize them to do so. ...or, teams self-organize unless you have organized them not to, in which case, if you want them to self-organize, you have to hire an Agile coach and start putting up posters telling people what it means to be "self directed" and fire everyone who is insufficiently short-term in their thinking. /s

rasta78 9y ago

Looking at things related to Entropy I can can clearly see the company I'm working for(which is sad).Considering that I'm not at leadership position, my next action is to quit and find a better one.

MBCook 9y ago
It really resonates with me and a job I used to have too.

knieveltech 9y ago

"Being overworked is not a good reason to hire." Because the world certainly needs more sociopathic management advice.

claudiulodro 9y ago
Theoretically, it might not be a good reason to hire. Maybe the problem is bad planning or project management. Hiring more people won't really solve that. But, in general, I agree with you.
jayd16 9y ago
Rereading the advice, I think he means hire before you get to overworked. I agree it's phrased poorly.
- ckip 9y ago
  I agree with his advice and not yours. Good candidates are a good reason to hire. Overworked is a good reason to reexamine priorities.
egor598 9y ago
The way I understood this: "If you are overworked, first look at your team, is everyone at their place and pulling their weight, evaluate your deadlines and promises, check your planning and management and your relationship with stakeholders. Because most of the times it's one of those things that's broken and probably affects the rest".
mmcnl 9y ago
That's your (negative) take on it. You can do something about being overworked without hiring (evaluate deadlines and scope, learn to say no). There's a good chance that hiring people without establishing the underlying cause of "being overworked" will only lead to more people being overworked. If you're hiring because of "being overworked", you're hiring too late.

egor598 9y ago

>>Construction work is not a good metaphor for software/product development. Factory work neither. I like this, really fed up with everyone comparing software development with construction work and/or building a house. Don't compare those, apples to oranges. Sure, borrow the best, most appropriate things, techniques, methodologies, approaches and not just from construction. Just don't compare.

mmcnl 9y ago
Avoid metaphors in general. In my experience, metaphors lead to discussion about the correctness of the metaphor instead of the subject the metaphor was referring to. This is a waste of time.

asafira 9y ago

Most people are commenting on what bullet points they agreed or disagreed most with. I am sure, however, that there are other software engineering leads on HN --- what other lessons have you learned, and/or what were the best resources to learn them (if not just experience).

lifeisstillgood 9y ago

Interestingly he (she?) seems confused and rage driven (!) over entropic organisations - i think the main issue with entropic organisations is simply size - there is no organisational approach that can ever make hundreds of thousands of people co-ordinate in a positive manner. we don't lack the technology, just that there is no good strategy at that level.

tempodox 9y ago

This list made me realize I have only ever seen Entropic Organizations. Is there even any other kind?

OJFord 9y ago

Title whinge: a multinational what? (That's not intended as a pedant's review of the article, just a note on the title presented on HN, which was praised in a recent thread for making even small changes to improve the grammar and quality of the site.)

dragonwriter 9y ago
“Multinational” is in regular use (reflected in most current dictionaries) as a standalone noun with an equivalent meaning to the noun phrase “multinational corporation”.

deleted 9y ago

[deleted]

mikeokner 9y ago

> If you feel like you don’t know what you are doing it’s probably because you don’t know what you are doing and that’s bad. I think this one depends on one's personality. I know people who have been relatively successful in their role for years who still regularly express impostor syndrome.

deleted 9y ago
[deleted]

misterbowfinger 9y ago

Favorite quote: > Delivery dates have often irrelevant but very simple to understand impacts. Good and bad solutions have dramatic but very difficult to understand impacts.

0xFFFE 9y ago

Nitpicking. > 20. The Sith are right, rage propels. But the Jedi are right, you must not let it control yourself. What nobody tells you is that the rage game is intrinsically tiring and rage will take control as soon as you get too tired, so stop well before. 37. Don't assume everyone reading your article gets the Star Wars reference.

tsomctl 9y ago
Speaking as someone that has never seen Star Wars, I still get his point.

nickthemagicman 9y ago

I'm not sure if this is brilliant advice or really bad advice.

programmer_dude 9y ago

The article is too abstract for me. I don't have enough leadership experience to relate to what is being said. I'd be grateful if someone could rewrite this article with some concrete examples. I am sure there are many others in the same boat as I am. They will find this useful too.

reilly3000 9y ago
Getting lots of people together to work on a large problem is an engineering problem in itself. It has its own language and constructs. Doing it wrong means millions or billions are wasted, and enterprises lose ground on the world stage. Some of these ideals don’t translate well to smaller scale. A 5 person team doesn’t have to work out much except the work. How do you get 1000 people to agree on a plan, an IDE, a language, and to row in the same direction? Not magic. Study and practice.
graycat 9y ago
Sadly, you are correct. You need some experience. "Experience is the great teacher, and some will learn from no other." In my career, I've seen shocking, astounding, career, organization, and company threatening examples of nearly everything he mentions, and to me his reactions are terrific and make a lot of sense. But, likely as you mentioned, need lots of real world examples from which he has extracted general, "abstract" lessons. He has terrific stuff. He is an excellent observer and, then, analyst of what the heck he saw. I put the text in my collection of management essays and regard it as by a wide margin the best management advice I've found for my startup: Currently I'm a sole, solo founder, so far have done it all, including all the important work and a lot of grunt work, but if my startup is successful then I'll have to hire and manage, all of it. Sure, eventually I'll get a COO and delegate a lot to them, but, still I'll have to know what's going on. And there will have to be more software development; I'll have to manage that either directly or through, say, a CTO or CIO, and that essay is the best advice I've seen so far. Other good advice is in Brooks, The Mythical Man-Month. Brooks is deeper in technical issues; the OP is better in the human and management issues which, IMHO, is where the real problems really are. Oh, by the way, I still believe that nearly all the best ideas in software management I've heard about are old (although I do have along list of questions where the old stuff doesn't give good answers and where I haven't seen good answers either old or new). So, e.g., I have essentially no faith in "agile" or "object-oriented". And I believe that (A) code without good documentation is essentially worthless, (B) the documentation is more work than the code, and (C) between the code and the documentation, if I had to save just one, it would be the documentation. So, in particular, for the work, the most important part of it is writing documentation; writing the code is the lesser part. And (D) my view of writing code is that it's simple: Start with a good description of (i) the programming language to be used and (ii) good descriptions of the functions, classes, APIs, etc. to be used, and between these two by far the more difficult is (ii). [No, right, usually it's not automatically simple, not at all; instead, in the end it should look and be simple, and that can take a lot of hard work.] Then from the documentation get the really crucial stuff -- what the heck the code is to do. It is the documentation that makes clear the issues of threading, locking, roll back, exceptional condition handling from small scale to large, the UI/UX, etc. Those issues are to be clear in appropriate parts of the documentation and not to be worked out only during the coding. So, e.g., try to get most of the coding down to (a) allocate storage, (b) the usual control structures if-then-else, do-while, select-when, (c) call-return, (d) clear architecture on exceptional condition handling, logging, etc., and (e) the functions, classes, APIs, etc. From what I learned from before the OP, although the OP has it better but maybe not as explicit, here are two lessons: First Lesson. "Why should I"? If you see a person in an organization and some work they might do, ideas they might have, etc. you have to ask the question, how will that person answer the question "Why should I". What's important here for a manager is not how YOU would answer this question but how you would anticipate that subordinate, other person, would answer the question. To be cynical, just because some area A is in the person's area of work, for some work X, will they actually do X and do it well? First way to know is, how would that person answer "Why should I do X"? To be cynical and likely often realistic, without a good answer, the person may simply neglect to do X. E.g., there is the old Ross Perot joke: Most organizations, when they see a snake, form a committee on snakes. In a good organization, when someone sees a snake, they kill it. Well, then, the answer to "Why should I kill the snake" is that Perot had a good organization. Second Lesson. There is a field, with courses, in public administration, business schools, and parts of sociology called organizational behavior. There one of the better ideas is goal subordination. Well, the OP is awash in cases of goal subordination. The idea of goal subordination, and common for middle managers, is to "subordinate" the "goals" of the organization to the "goals" of that middle manager. So, the manager does what he believes is good for his career even if it is bad for the organization. So, an exercise is to read the OP essay and list and explain the places where the author is suggesting goal subordination. There's much more to say, but, trust me, the OP is talking about stuff that is darned real. For me, I want my startup to work. A big, huge advantage of being founder and 100% owner is that I don't have to explain stuff to some BoD that, as in the OP, has no chance of understanding reality. So, I'd constantly have to create "company theater" for the BoD, and that would be so wasteful it could kill my company. My point here generalizes and is generalized in the OP: The crucial details of a serious real problem and its best solution are typically too difficult for communicating up a management chain or even just from a CEO to a BoD. The OP is correct. So, as sole founder and 100% owner, I don't have to try to communicate to a BoD that has no hope of understanding or waste effort on company theater. Instead, I just concentrate on making my company successful. If I am successful, then the main evidence visible externally will be just the financial, brand, etc. success, a lot of which the news media will likely heavily distort; the real reason the company was successful will be known just to me and maybe a COO or CTO if I get really good ones.

koonsolo 9y ago

Nice list, although I was horrified by one (sorry to need to pick on the one thing that was bad): >Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles. That's why we as programmers should say no to overwork, because only then will they see the need to hire. I only do overwork when some unexpected disaster happens, or when there is a sudden huge opportunity. In the other cases, they should plan better or hire more people, simple as that.

mmcnl 9y ago
> 24. Don’t let entropy get at your daily routine. Avoid entropy-driven work. Your anecdote is rule 24 in practice. Good job.

tboyd47 9y ago

> People appreciate when you fire the right people, so don’t worry about morale. When you select for sociopaths, you get sociopaths.

xamde 9y ago

A great article mostly nailing problem descriptions. This is usually represented too briefly. I believe “The Entropic Organization” (Teo) would be a highly cited book, cited by all kinds of management books emphasizing the solutions. Please, write TEO.