<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://newsletter.pragmaticengineer.com/p/why-is-meta-destroying-its-engineering"/>
	<rdf:li rdf:resource="https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo/edit#gid=0"/>
	<rdf:li rdf:resource="https://cutle.fish/blog/12-signs-youre-working-in-a-feature-factory"/>
	<rdf:li rdf:resource="https://augustl.com/blog/2019/best_bug_predictor_is_organizational_complexity/"/>
	<rdf:li rdf:resource="https://apenwarr.ca/log/20171213"/>
	<rdf:li rdf:resource="https://newrepublic.com/article/154944/boeing-737-max-investigation-indonesia-lion-air-ethiopian-airlines-managerial-revolution"/>
	<rdf:li rdf:resource="https://chelseatroy.com/2018/03/29/why-do-remote-meetings-suck-so-much/"/>
	<rdf:li rdf:resource="https://qz.com/1039957/the-ultimate-case-against-using-shame-as-a-management-tactic/"/>
	<rdf:li rdf:resource="https://medium.com/swills-tech-leadership-essentials"/>
	<rdf:li rdf:resource="https://en.wikipedia.org/wiki/Law_of_triviality"/>
	<rdf:li rdf:resource="http://larahogan.me/blog/manager-levels/"/>
	<rdf:li rdf:resource="http://www.airfixers.com/"/>
	<rdf:li rdf:resource="https://mfbt.ca/how-fucked-up-is-your-management-8a1086eeb4a9#.gt7wsrxbs"/>
	<rdf:li rdf:resource="https://www.ft.com/content/88fdc58e-754f-11e6-b60a-de4532d5ea35"/>
	<rdf:li rdf:resource="https://www.oreilly.com/ideas/ask-the-cto-how-do-i-hire-managers"/>
	<rdf:li rdf:resource="https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/"/>
	<rdf:li rdf:resource="http://www.bloomberg.com/news/articles/2015-10-21/how-could-volkswagen-s-top-engineers-not-have-known-"/>
	<rdf:li rdf:resource="http://dresscode.renttherunway.com/blog/ladder"/>
	<rdf:li rdf:resource="http://whilefalse.blogspot.ie/2015/10/notes-on-startup-engineering-management.html"/>
	<rdf:li rdf:resource="http://www.gigamonkeys.com/flowers/"/>
	<rdf:li rdf:resource="http://techcrunch.com/2015/03/21/the-terrible-technical-interview/"/>
	<rdf:li rdf:resource="http://silverwraith.com/blog/2014/12/the-case-for-distributed-teams/"/>
	<rdf:li rdf:resource="http://mcfunley.com/thoughts-on-the-technical-track"/>
	<rdf:li rdf:resource="https://stripe.com/blog/scaling-email-transparency"/>
	<rdf:li rdf:resource="http://zachholman.com/talk/move-fast-break-nothing/"/>
	<rdf:li rdf:resource="http://www.cultofmac.com/298485/ex-apple-managers-reveal-cupertinos-killer-workload/"/>
	<rdf:li rdf:resource="http://jliszka.github.io/2013/11/07/effective-peer-reviews.html"/>
	<rdf:li rdf:resource="http://www.slideshare.net/danmil30/how-to-run-a-5-whys-with-humans-not-robots"/>
	<rdf:li rdf:resource="http://lwn.net/SubscriberLink/529522/854aed3fb6398b79/"/>
	<rdf:li rdf:resource="http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3"/>
	<rdf:li rdf:resource="http://slacy.com/blog/2011/03/what-larry-page-really-needs-to-do-to-return-google-to-its-startup-roots/"/>
	<rdf:li rdf:resource="http://www.pivotaltracker.com/learnmore"/>
	<rdf:li rdf:resource="http://www.nytimes.com/2010/02/04/opinion/04brass.html?pagewanted=all"/>
	<rdf:li rdf:resource="http://www.indiangeek.net/programmer-competency-matrix/"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://newsletter.pragmaticengineer.com/p/why-is-meta-destroying-its-engineering">
    <title>Why is Meta destroying its engineering organization?</title>
    <dc:date>2026-06-17T12:19:26+00:00</dc:date>
    <link>https://newsletter.pragmaticengineer.com/p/why-is-meta-destroying-its-engineering</link>
    <dc:creator>jm</dc:creator><description><![CDATA["For two decades, Meta had a unique, high-performance engineering org; right up until around April of this year. For the first 20 years of the company’s existence, it had a “move-fast-and-break-things” culture, and in the early 2020s this shifted to a “move-fast-with-stable-infra” one. Engineers I know at the company were empowered to do good work, focus on impact, and to balance business interests with solid engineering.

But in the past few weeks, all that has changed, as if the leadership has been following detailed blueprints on how to demolish a proven, successful engineering culture in the most ruthlessly efficient way possible."

This is absolutely crazy stuff. It's amazing how badly-run this sounds!
30-50% of engineers on core engineering teams have been forcefully reassigned to data labeling! AI slop code creating zero-auth password reset security holes!  The CISO jumping ship!  No wonder everyone's leaving, and pointing fingers at Zuck and Wang.

<blockquote>
“It’s literally the gulag,” one of the employees claims. “You have zero purpose in life all of a sudden, you barely interact with anyone, you just have these tasks every week.”
</blockquote>]]></description>
<dc:subject>meta fuckedcompany instagram facebook ai management how-we-work zuck engineering fail</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9bd39beed497/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:meta"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fuckedcompany"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instagram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:how-we-work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zuck"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo/edit#gid=0">
    <title>CircleCI Engineering Competency Matrix</title>
    <dc:date>2023-06-19T16:32:57+00:00</dc:date>
    <link>https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo/edit#gid=0</link>
    <dc:creator>jm</dc:creator><description><![CDATA[CircleCI have done a good bit of work on defining competency levels in an engineering organization here
]]></description>
<dc:subject>career circleci engineering growth management competencies work</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7a6797f3039e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:career"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:circleci"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:growth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:competencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://cutle.fish/blog/12-signs-youre-working-in-a-feature-factory">
    <title>12 Signs You’re Working in a Feature Factory</title>
    <dc:date>2020-02-17T13:00:29+00:00</dc:date>
    <link>https://cutle.fish/blog/12-signs-youre-working-in-a-feature-factory</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>I’ve used the term *Feature Factory *at a couple conference talks over the past two years. I started using the term when a software developer friend complained that he was “just sitting in the factory, cranking out features, and sending them down the line.”</blockquote>

heh, this rings a bell....]]></description>
<dc:subject>features product-management agile teams work management product companies prioritization planning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c4f2ce936374/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:features"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:product-management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:agile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:teams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:product"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:companies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prioritization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:planning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://augustl.com/blog/2019/best_bug_predictor_is_organizational_complexity/">
    <title>The #1 bug predictor is not technical, it's organizational complexity (August Lilleaas' blog)</title>
    <dc:date>2019-12-19T12:06:35+00:00</dc:date>
    <link>https://augustl.com/blog/2019/best_bug_predictor_is_organizational_complexity/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Organizational Complexity. Measures number of developers working on the module, number of ex-developers that used to work on the module but no longer does, how big a fraction of the organization as a whole that works or has worked on the module, the distance in the organization between the developer and the decision maker, etc.</blockquote>

]]></description>
<dc:subject>culture management programming organisations bureaucracy bugs quality</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a2b0fa7101a6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:organisations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bureaucracy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quality"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://apenwarr.ca/log/20171213">
    <title>An epic treatise on scheduling, bug tracking, and triage</title>
    <dc:date>2019-10-25T11:41:00+00:00</dc:date>
    <link>https://apenwarr.ca/log/20171213</link>
    <dc:creator>jm</dc:creator><description><![CDATA[by apenwarr.  Excellent stuff -- most of what we do in Swrve for scheduling is included here]]></description>
<dc:subject>agile management software programming scheduling triage bugs backlogs jira</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:24ba57f7dcef/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:agile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scheduling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:triage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backlogs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jira"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://newrepublic.com/article/154944/boeing-737-max-investigation-indonesia-lion-air-ethiopian-airlines-managerial-revolution">
    <title>Crash Course | The New Republic</title>
    <dc:date>2019-09-23T11:50:52+00:00</dc:date>
    <link>https://newrepublic.com/article/154944/boeing-737-max-investigation-indonesia-lion-air-ethiopian-airlines-managerial-revolution</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Boeing's MCAS disaster as a parable of late-stage capitalism:

<blockquote>[Boeing] engineers devised a software fix called MCAS, which pushed the nose down in response to an obscure set of circumstances in conjunction with the “speed trim system,” which Boeing had devised in the 1980s to smooth takeoffs. Once the 737 MAX materialized as a real-life plane about four years later, however, test pilots discovered new realms in which the plane was more stall-prone than its predecessors. So Boeing modified MCAS to turn down the nose of the plane whenever an angle-of-attack (AOA) sensor detected a stall, regardless of the speed. That involved giving the system more power and removing a safeguard, but not, in any formal or genuine way, running its modifications by the FAA, which might have had reservations with two critical traits of the revamped system: Firstly, that there are two AOA sensors on a 737, but only one, fatefully, was programmed to trigger MCAS. The former Boeing engineer Ludtke and an anonymous whistle-blower interviewed by 60 Minutes Australia both have a simple explanation for this: Any program coded to take data from both sensors would have had to account for the possibility the sensors might disagree with each other and devise a contingency for reconciling the mixed signals. Whatever that contingency, it would have involved some kind of cockpit alert, which would in turn have required additional training—probably not level-D training, but no one wanted to risk that. So the system was programmed to turn the nose down at the feedback of a single (and somewhat flimsy) sensor. And, for still unknown and truly mysterious reasons, it was programmed to nosedive again five seconds later, and again five seconds after that, over and over ad literal nauseam. 

And then, just for good measure, a Boeing technical pilot emailed the FAA and casually asked that the reference to the software be deleted from the pilot manual. 

So no more than a handful of people in the world knew MCAS even existed before it became infamous. Here, a generation after Boeing’s initial lurch into financialization, was the entirely predictable outcome of the byzantine process by which investment capital becomes completely abstracted from basic protocols of production and oversight: a flight-correction system that was essentially jerry-built to crash a plane. “If you’re looking for an example of late stage capitalism or whatever you want to call it,” said longtime aerospace consultant Richard Aboulafia, “it’s a pretty good one.” </blockquote>

]]></description>
<dc:subject>boeing business capitalism engineering management fail disasters automation cost-control stock-market fly-by-wire</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:147b64ad3d93/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:boeing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:business"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capitalism"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disasters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:automation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cost-control"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stock-market"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fly-by-wire"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://chelseatroy.com/2018/03/29/why-do-remote-meetings-suck-so-much/">
    <title>Why do remote meetings suck so much?</title>
    <dc:date>2019-03-06T21:46:42+00:00</dc:date>
    <link>https://chelseatroy.com/2018/03/29/why-do-remote-meetings-suck-so-much/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Unstructured, "caucus"-style meetings suck particularly badly for remote workers.

<blockquote>When audio/visual delays exacerbate the caucus problem for people who always get the floor in meetings, it looks to them like a new problem. It’s not new; it’s just normally experienced by people in meetings with lower caucus scores. Leadership doesn’t notice because people in leadership positions tend to have higher caucus scores, and being in a position of leadership also tends to boost your caucus score (basically because people interrupt you less). But that’s a weakness of the way we identify decision-makers: good ideas come from everywhere, and especially from people who do a lot of thinking and observing before they say anything.

Making meetings more accessible to remote employees doesn’t just make meetings more accessible to remote employees; it makes meetings more accessible to everyone. </blockquote>

]]></description>
<dc:subject>team meetings remote communication management caucus-score remote-work</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:950e2f460bdf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:team"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:meetings"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:remote"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:communication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caucus-score"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:remote-work"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://qz.com/1039957/the-ultimate-case-against-using-shame-as-a-management-tactic/">
    <title>Air Canada near-miss: Air traffic controllers make split-second decisions in a culture of &quot;psychological safety&quot; — Quartz</title>
    <dc:date>2017-08-01T10:32:24+00:00</dc:date>
    <link>https://qz.com/1039957/the-ultimate-case-against-using-shame-as-a-management-tactic/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>“’Just culture’ as a term emerged from air traffic control in the late 1990s, as concern was mounting that air traffic controllers were unfairly cited or prosecuted for incidents that happened to them while they were on the job,” Sidney Dekker, a professor, writer, and director of the Safety Science Innovation Lab at Griffith University in Australia, explains to Quartz in an email. Eurocontrol, the intergovernmental organization that focuses on the safety of airspace across Europe, has “adopted a harmonized ‘just culture’ that it encourages all member countries and others to apply to their air traffic control organizations.”

[...] One tragic example of what can happen when companies don’t create a culture where employees feel empowered to raise questions or admit mistakes came to light in 2014, when an investigation into a faulty ignition switch that caused more than 100 deaths at GM Motors revealed a toxic culture of denying errors and deflecting blame within the firm. The problem was later attributed to one engineer who had not disclosed an obvious issue with the flawed switch, but many employees spoke of extreme pressure to put costs and delivery times before all other considerations, and to hide large and small concerns.</blockquote>

(via JG)]]></description>
<dc:subject>just-culture atc air-traffic-control management post-mortems outages reliability air-canada disasters accidents learning psychological-safety work</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:924ff2dfec5f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:just-culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:atc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:air-traffic-control"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:post-mortems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:air-canada"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disasters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:accidents"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:learning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:psychological-safety"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/swills-tech-leadership-essentials">
    <title>swill’s tech leadership essentials – Medium</title>
    <dc:date>2017-07-03T15:29:35+00:00</dc:date>
    <link>https://medium.com/swills-tech-leadership-essentials</link>
    <dc:creator>jm</dc:creator><description><![CDATA[very useful tips and advice from Stephanie Williams (nee Dean), who was instrumental in setting up the ops teams in Amazon Dublin, by all accounts]]></description>
<dc:subject>management stephanie-dean stephanie-williams managing teams work hiring</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:44b70916b82a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stephanie-dean"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stephanie-williams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:managing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:teams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hiring"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://en.wikipedia.org/wiki/Law_of_triviality">
    <title>the origins of bike-shedding</title>
    <dc:date>2016-11-18T16:15:38+00:00</dc:date>
    <link>https://en.wikipedia.org/wiki/Law_of_triviality</link>
    <dc:creator>jm</dc:creator><description><![CDATA['bike-shedding', or needless arguing about trivial issues, actually dates back to 1957 as C. Northcote Parkinson's 'law of triviality']]></description>
<dc:subject>triviality bikeshed bikeshedding management arguments decisions history</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e0669ccb65d1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:triviality"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bikeshed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bikeshedding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:arguments"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:decisions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://larahogan.me/blog/manager-levels/">
    <title>Management levels</title>
    <dc:date>2016-10-24T10:21:16+00:00</dc:date>
    <link>http://larahogan.me/blog/manager-levels/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>I’ve had the privilege of experiencing a few different management levels (responsibilities? jobs?) at Etsy since I’ve joined. At each stage, I felt like the job of being a manager totally changed. What I did day-to-day changed, what was hard about it changed, how I measured my own success changed, and though I feel like the experiences built on one another, it continues to be an enormous shift in brainpower each time the gig changes a bit.  Given how intangible (and often hidden) management work can be, I’ve outlined some highlights of what my work has been like as a manager over the last four years. (Obvious, major caveat: this is just my experience, and there’s lots in here that is unique to this particular work environment, hierarchy, requirements, and challenges!)</blockquote>

]]></description>
<dc:subject>business engineering management career lara-hogan managing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1ce83855bd8c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:business"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:career"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lara-hogan"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:managing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.airfixers.com/">
    <title>Airfixers - Hosting without the hassle</title>
    <dc:date>2016-10-12T13:23:54+00:00</dc:date>
    <link>http://www.airfixers.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Full AirBnB property management service in Dublin]]></description>
<dc:subject>dublin airbnb management rental services</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e6a3abae80e6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dublin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:airbnb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rental"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mfbt.ca/how-fucked-up-is-your-management-8a1086eeb4a9#.gt7wsrxbs">
    <title>How Fucked Up is Your Management?</title>
    <dc:date>2016-10-07T12:48:42+00:00</dc:date>
    <link>https://mfbt.ca/how-fucked-up-is-your-management-8a1086eeb4a9#.gt7wsrxbs</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Oh dear.

<blockquote>Score 1 “My management culture is fucked up” point for each of the following:

We have an unlimited vacation policy;

We don’t do regular 1:1s, but we have open office hours/are super available if anyone wants to chat;

We don’t have a process for interviewing, we just hire awesome people when we meet them;

We super care about diversity, but we don’t want to lower the bar so we just hire the best person for the job even if it means diversity suffers;

We don’t have defined levels and career paths for our employees, we’re a really flat org;

We don’t have formal managers for every staff member, everyone just gets their work done;

We don’t have, like, HR HR, but our recruiter/office manager/only female employee is super good if you want someone to talk to;

We don’t do performance improvement plans for employees that are struggling. We just have a super honest conversation about how they aren’t a good fit and fire them;

We would have some hard explaining to do if our salary list accidentally became public.</blockquote>

]]></description>
<dc:subject>startups management culture work vacation hiring office-hours managers diversity careers hr</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:846dc226ee4b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:startups"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vacation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hiring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:office-hours"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:managers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:diversity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:careers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hr"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.ft.com/content/88fdc58e-754f-11e6-b60a-de4532d5ea35">
    <title>Algorithmic management as the new Taylorism</title>
    <dc:date>2016-09-13T11:12:25+00:00</dc:date>
    <link>https://www.ft.com/content/88fdc58e-754f-11e6-b60a-de4532d5ea35</link>
    <dc:creator>jm</dc:creator><description><![CDATA['its legacy can be seen in factories, call centres and warehouses today, although new technology has taken the place of Taylor’s instruction cards and stopwatches. Many warehouse workers for companies such as Amazon use handheld devices that give them step-by-step instructions on where to walk and what to pick from the shelves when they get there, all the while measuring their “pick rate” in real time. For Jeremias Prassl, a law professor at Oxford university, the algorithmic management techniques of Uber and Deliveroo are Taylorism 2.0. “Algorithms are providing a degree of control and oversight that even the most hardened Taylorists could never have dreamt of,” he says.']]></description>
<dc:subject>algorithms labour work labor taylorism management silicon-valley tech deliveroo uber piece-work</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e0e5ffae9927/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:labour"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:labor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:taylorism"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:silicon-valley"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tech"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deliveroo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:piece-work"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.oreilly.com/ideas/ask-the-cto-how-do-i-hire-managers">
    <title>Ask the CTO: How do I hire managers?</title>
    <dc:date>2016-04-28T16:43:48+00:00</dc:date>
    <link>https://www.oreilly.com/ideas/ask-the-cto-how-do-i-hire-managers</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good tips from Camille Fournier]]></description>
<dc:subject>camille-fournier tips advice hiring managers management hr</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d05bd4cadd77/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:camille-fournier"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:advice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hiring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:managers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hr"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/">
    <title>re:Work - The five keys to a successful Google team</title>
    <dc:date>2015-11-26T12:09:33+00:00</dc:date>
    <link>https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>We learned that there are five key dynamics that set successful teams apart from other teams at Google:
Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
Dependability: Can we count on each other to do high quality work on time?
Structure & clarity: Are goals, roles, and execution plans on our team clear?
Meaning of work: Are we working on something that is personally important for each of us?
Impact of work: Do we fundamentally believe that the work we’re doing matters?</blockquote>

]]></description>
<dc:subject>teams google culture work management productivity hr</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3ac2508c267d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:teams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:productivity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hr"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.bloomberg.com/news/articles/2015-10-21/how-could-volkswagen-s-top-engineers-not-have-known-">
    <title>Volkswagen emissions cheating was technical debt</title>
    <dc:date>2015-11-05T11:07:23+00:00</dc:date>
    <link>http://www.bloomberg.com/news/articles/2015-10-21/how-could-volkswagen-s-top-engineers-not-have-known-</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Is this the first case of tech debt costing $18 billion?

<blockquote>"Perhaps the engineers told themselves that the cheat was a stopgap, and they’d address it later. If so, they didn’t."</blockquote>

]]></description>
<dc:subject>tech-debt vw volkswagen management prioritisation planning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6cfb94f3e80e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tech-debt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vw"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:volkswagen"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prioritisation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:planning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://dresscode.renttherunway.com/blog/ladder">
    <title>RentTheRunway's Engineering Ladder</title>
    <dc:date>2015-10-22T16:03:38+00:00</dc:date>
    <link>http://dresscode.renttherunway.com/blog/ladder</link>
    <dc:creator>jm</dc:creator><description><![CDATA[One of the best things about working at Amazon was having a clear, well-defined career progression, and it's something that's always been absent in startups.  Career growth, levelling, and tech management is important, and also helps in hiring by providing clear levels.  This is the RentTheRunway engineering ladder, Camille Fournier's team, which they open sourced back in March 2015]]></description>
<dc:subject>engineering hiring management career renttherunway camille-fournier amazon startups career-growth levelling ladder</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a46c3199e3f7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hiring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:career"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:renttherunway"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:camille-fournier"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:startups"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:career-growth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:levelling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ladder"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://whilefalse.blogspot.ie/2015/10/notes-on-startup-engineering-management.html">
    <title>Notes on Startup Engineering Management for Young Bloods</title>
    <dc:date>2015-10-02T16:57:57+00:00</dc:date>
    <link>http://whilefalse.blogspot.ie/2015/10/notes-on-startup-engineering-management.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Below is a list of some lessons I’ve learned as an startup engineering manager that are worth being told to a new manager. Some are subtle, and some are surprising, and this being human beings, some are inevitably controversial. This list is for the new head of engineering to guide their thinking about the job they are taking on. It’s not comprehensive, but it’s a good beginning.
The best characteristic of this list is that it focuses on social problems with little discussion of technical problems a manager may run into. The social stuff is usually the hardest part of any software developer’s job, and of course this goes triply for engineering managers.</blockquote>

]]></description>
<dc:subject>engineering management camille-fournier teams dev</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d7d423568664/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:camille-fournier"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:teams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dev"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.gigamonkeys.com/flowers/">
    <title>Let a 1,000 flowers bloom. Then rip 999 of them out by the roots</title>
    <dc:date>2015-09-29T15:28:39+00:00</dc:date>
    <link>http://www.gigamonkeys.com/flowers/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[The Twitter tech-debt story.

<blockquote>Somewhere along the way someone decided that it would be easier to convert the Birdcage to use Pants which had since learned how to build Scala and to deal with a maven-style layout. However at some point prior Pants been open sourced in throw it over the wall fashion and picked up by a few engineers at other companies, such as Square and Foursquare and moved forward. In the meantime, again because there weren’t enough people who’s job it was to take care of these things, Science was still on the original internally developed version and had in fact evolved independently of the open source version. However by the time we wanted to move Birdcage onto Pants, the open source version had moved ahead so that’s the one the Birdcage folks chose.</blockquote>

(cries)]]></description>
<dc:subject>tech-debt management twitter productivity engineering monorepo build-systems war-stories dev</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2f1762f93715/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tech-debt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:productivity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monorepo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:build-systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:war-stories"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dev"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://techcrunch.com/2015/03/21/the-terrible-technical-interview/">
    <title>The Terrible Technical Interview</title>
    <dc:date>2015-03-22T21:20:29+00:00</dc:date>
    <link>http://techcrunch.com/2015/03/21/the-terrible-technical-interview/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[TechCrunch, very down on the traditional big-O-and-whiteboard tech interview.  See also https://news.ycombinator.com/item?id=9243169 for some good comments at HN.  To be honest I think a good comprehension of data structures and big-O is pretty vital though....]]></description>
<dc:subject>interviewing jobs management hr hiring techcrunch</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a7a46e305e40/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interviewing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jobs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hiring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:techcrunch"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://silverwraith.com/blog/2014/12/the-case-for-distributed-teams/">
    <title>Avleen Vig on distributed engineering teams</title>
    <dc:date>2015-01-05T11:05:39+00:00</dc:date>
    <link>http://silverwraith.com/blog/2014/12/the-case-for-distributed-teams/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a really excellent post on the topic, rebutting Paul Graham's Bay-Area-centric thoughts on the topic very effectively.   I've worked in both distributed and non-distributed, as well as effective and ineffective teams ;), and Avleen's thoughts are very much on target.

<blockquote>I've been involved in the New York start up scene since I joined Etsy in 2010. Since that time, I've seen more and more companies there embrace having distributed teams. Two companies I know which have risen to the top while doing this have been Etsy and DigitalOcean. Both have exceptional engineering teams working on high profile products used by many, many people around the world. There are certainly others outside New York, including Automattic, GitHub, Chef Inc, Puppet... the list goes on.

So how did this happen? And why do people continue to insist that distributed teams lower performance, and are a bad idea?

Partly because we've done a poor job of showing our industry how to be successful at it, and partly because it's hard. Having successful distributed teams requires special skills from management, which arent't easily learned until you have to manage a distributed team. Catch 22.</blockquote>

]]></description>
<dc:subject>business culture management communication work distributed-teams avleen-vig engineering</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:63a4aa8ccc65/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:business"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:communication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed-teams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:avleen-vig"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engineering"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://mcfunley.com/thoughts-on-the-technical-track">
    <title>Dan McKinley :: Thoughts on the Technical Track</title>
    <dc:date>2014-12-09T22:35:24+00:00</dc:date>
    <link>http://mcfunley.com/thoughts-on-the-technical-track</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Ouch.  I think Amazon did a better job of the Technical Track concept than this, at least]]></description>
<dc:subject>engineering management technical-track principal-engineer career work</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c4f00b6d2e0d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:technical-track"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:principal-engineer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:career"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://stripe.com/blog/scaling-email-transparency">
    <title>Scaling email transparency</title>
    <dc:date>2014-12-09T17:40:07+00:00</dc:date>
    <link>https://stripe.com/blog/scaling-email-transparency</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is quite interesting/weird -- Stripe's protocol for mass-CCing email as they scale up the company, based around http://en.wikipedia.org/wiki/Civil_inattention]]></description>
<dc:subject>communication culture email management stripe cc transparency civil-inattention</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6ec7214e73f1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:communication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:email"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stripe"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:transparency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:civil-inattention"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://zachholman.com/talk/move-fast-break-nothing/">
    <title>Move Fast and Break Nothing</title>
    <dc:date>2014-10-09T15:56:46+00:00</dc:date>
    <link>http://zachholman.com/talk/move-fast-break-nothing/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Great presentation about Github dev culture and building software without breakage,  but still with real progress.]]></description>
<dc:subject>github programming communication process coding teams management dev-culture breakage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:30418378b79d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:github"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:communication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:process"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:teams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dev-culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:breakage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.cultofmac.com/298485/ex-apple-managers-reveal-cupertinos-killer-workload/">
    <title>Ex-Apple managers reveal Cupertino’s killer workload</title>
    <dc:date>2014-10-02T10:33:21+00:00</dc:date>
    <link>http://www.cultofmac.com/298485/ex-apple-managers-reveal-cupertinos-killer-workload/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a “firehose of emails that are just going out at 2:45 in the morning” and “if you forwarded something to one of your people at 1 o’clock in the morning and they didn’t reply promptly, you got a little annoyed at them.”</blockquote>

Fuck. That.]]></description>
<dc:subject>apple workplaces work time-life-balance downtime insane sick 1am management corporate-culture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:de8ea38433de/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:workplaces"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-life-balance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:downtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:insane"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sick"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:1am"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:corporate-culture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://jliszka.github.io/2013/11/07/effective-peer-reviews.html">
    <title>Painless, effective peer reviews</title>
    <dc:date>2014-08-05T10:09:32+00:00</dc:date>
    <link>http://jliszka.github.io/2013/11/07/effective-peer-reviews.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This sounds like a nice way to do effective peer-driven team reviews without herculean effort, which were one of the most effective reviewing techniques (along with upwards reviewing of management) I encountered at Amazon.  (Yes, the Amazon approach was very time-consuming and universally loathed.)

The potential downside I can see is that it doesn't give the reviewer enough time to revise any review comments they have second thoughts about, whereas written reviews do, but that would be an easy fix at the end of the process.  Also, it's worth noting that in most cases, a good review requires a bit of time to marshal thoughts and come up with a coherent review of a peer, so this doesn't completely avoid the impact on effort.  Still, a definite improvement I would say.]]></description>
<dc:subject>hr management reviews performance peer-driven-review 360-reviews staff peers work teams amazon</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:dfa5cd16e279/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reviews"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:peer-driven-review"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:360-reviews"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:staff"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:peers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:teams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/danmil30/how-to-run-a-5-whys-with-humans-not-robots">
    <title>How To Run a 5 Whys (With Humans, Not Robots)</title>
    <dc:date>2013-11-20T14:52:13+00:00</dc:date>
    <link>http://www.slideshare.net/danmil30/how-to-run-a-5-whys-with-humans-not-robots</link>
    <dc:creator>jm</dc:creator><description><![CDATA['remember, there is no axe murderer. probably']]></description>
<dc:subject>process management howto post-mortems five-whys 5-whys investigation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2232371fd563/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:process"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:howto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:post-mortems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:five-whys"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:5-whys"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:investigation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://lwn.net/SubscriberLink/529522/854aed3fb6398b79/">
    <title>GNUTLS project is leaving/attempting to leave the GNU project/FSF</title>
    <dc:date>2012-12-23T08:23:03+00:00</dc:date>
    <link>http://lwn.net/SubscriberLink/529522/854aed3fb6398b79/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[seems there's trouble around governance and rights of the project's developers.  GNU sed and grep's maintainer, too: http://article.gmane.org/gmane.comp.lang.smalltalk.gnu.general/7873]]></description>
<dc:subject>gnu software free free-software governance copyright management richard-stallman</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:debc53b405eb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gnu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:free"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:free-software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:governance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:copyright"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:richard-stallman"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3">
    <title>The best &quot;why estimation is hard&quot; parable I've read this week</title>
    <dc:date>2012-02-02T10:02:02+00:00</dc:date>
    <link>http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3</link>
    <dc:creator>jm</dc:creator><description><![CDATA['A tense silence falls between us. The phone call goes unmade. I'll call tomorrow once my comrade regains his senses and is willing to commit to something reasonable.']]></description>
<dc:subject>agile development management programming teams estimation tasks software</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c04b6424baf4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:agile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:teams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:estimation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tasks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://slacy.com/blog/2011/03/what-larry-page-really-needs-to-do-to-return-google-to-its-startup-roots/">
    <title>What Larry Page really needs to do to return Google to its startup roots</title>
    <dc:date>2011-03-30T20:48:49+00:00</dc:date>
    <link>http://slacy.com/blog/2011/03/what-larry-page-really-needs-to-do-to-return-google-to-its-startup-roots/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[massively detailed critique of Google's corporate culture -- lots of internals exposed]]></description>
<dc:subject>google management culture aws corporate-culture gossip</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:1614ea427117/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:corporate-culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gossip"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.pivotaltracker.com/learnmore">
    <title>Pivotal Tracker</title>
    <dc:date>2010-03-26T12:17:37+00:00</dc:date>
    <link>http://www.pivotaltracker.com/learnmore</link>
    <dc:creator>jm</dc:creator><description><![CDATA[hmm, nice-looking Scrum tool]]></description>
<dc:subject>scrum collaboration dev management project-management tools agile</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:3ecfaea9fd7f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scrum"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:collaboration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dev"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:project-management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:agile"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.nytimes.com/2010/02/04/opinion/04brass.html?pagewanted=all">
    <title>Op-Ed Contributor - Microsoft’s Creative Destruction - NYTimes.com</title>
    <dc:date>2010-02-05T10:41:42+00:00</dc:date>
    <link>http://www.nytimes.com/2010/02/04/opinion/04brass.html?pagewanted=all</link>
    <dc:creator>jm</dc:creator><description><![CDATA[MS internal politics routinely torpedoed cool new projects.  surprise, surprise.  'Engineers in the Windows group falsely claimed [ClearType] made the display go haywire when certain colors were used. The head of Office products said it was fuzzy and gave him headaches. The VP for pocket devices was blunter: he’d support ClearType and use it, but only if I transferred the program and the programmers to his control.']]></description>
<dc:subject>cleartype microsoft software bureaucracy politics culture management corporate nytimes</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:90930a59d76c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cleartype"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microsoft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bureaucracy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:politics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:corporate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nytimes"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.indiangeek.net/programmer-competency-matrix/">
    <title>Programmer Competency Matrix</title>
    <dc:date>2009-07-31T09:18:50+00:00</dc:date>
    <link>http://www.indiangeek.net/programmer-competency-matrix/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[actually quite a good breakdown of software eng skill progression]]></description>
<dc:subject>software coding programming management hiring engineering matrix skills</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:3adb6439f7b5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hiring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:matrix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:skills"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>