json-feed-0.0.0: feeds/allenpike.com.json
{
"version": "https://jsonfeed.org/version/1",
"title": "Allen Pike",
"home_page_url": "https://www.allenpike.com/",
"feed_url": "http://www.allenpike.com/feed.json",
"author": {
"name": "Allen Pike"
},
"items": [
{
"id": "/2017/steve-stories",
"url": "http://www.allenpike.com/2017/steve-stories",
"title": "Steve Stories",
"date_published": "2017-04-30T20:00:00-07:00",
"content_html": "<p>Earlier this month I was lucky enough to be invited to speak at the <a href=\"http://2017.ull.ie/\">Úll</a> conference in Ireland. One of the many bonus features there was Steve Stories, a project that invited some of the presenters to record our favourite stories about Steve Jobs.</p>\n\n<p>Naturally, when I think of Steve stories, my mind first goes to Andy Hertzfeld’s classic site about the creation of the Mac, <a href=\"http://www.folklore.org/\">folklore.org</a>, and the accompanying book, <a href=\"https://www.amazon.ca/Revolution-Valley-Paperback-Insanely-Great-ebook/dp/B006BAW3N0/ref=tmm_kin_swatch_0\">Revolution in the Valley</a>. My favourite stories from those early days are about Steve’s infamous Reality Distortion Field.</p>\n\n<div class=\"getty embed image\" style=\"background-color:#fff;display:inline-block;font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;color:#a7a7a7;font-size:11px;width:100%\"><div style=\"overflow:hidden;position:relative;height:0;padding:67.508418% 0 0 0;width:100%;\"><iframe src=\"http://www.allenpike.com//embed.gettyimages.com/embed/80823324?et=dnftxZfaQ7VUZLL6N4l0BQ&tld=ca&viewMoreLink=off&sig=xgGsT73DtRP0lTLV90TA2nyvflsB9QmfUV7FUCnwXyU=&caption=true\" width=\"100%\" scrolling=\"no\" frameborder=\"0\" style=\"display:inline-block;position:absolute;top:0;left:0;width:100%;height:100%;margin:0;\"></iframe></div><p style=\"margin:0;\"></p></div>\n\n<p>You see, in the early 80s when they were building the Macintosh, Steve was infamous for working the engineers <a href=\"http://www.folklore.org/StoryView.py?story=90_Hours_A_Week_And_Loving_It.txt\">disgustingly long hours</a> and putting them under extreme pressure to ship. Folks often threatened to leave, but if Steve wanted somebody to stay, they tended to stay.</p>\n\n<p>No matter how much a key engineer wanted to quit, if they went into Steve’s office to resign, he would always go into Reality Distortion mode and persuade them to feel like they wanted to stay. By the end of the conversation, the engineer would leave Steve’s office pumped and motivated. “Yeah, we <em>are</em> going to change the world! Wait… wasn’t I going in there to quit?”</p>\n\n<p>After some failed attempts at quitting, Burrell Smith, one of the key engineers behind the Mac, finally devised a way around Steve.</p>\n\n<p>“I’ve got it!” said Burrell. “I know the perfect way to quit that will nullify the Reality Distortion Field. I’ll just walk into Steve’s office, pull down my pants, and urinate on his desk. What could he say to that? It’s guaranteed to work.” The logic was sound.</p>\n\n<p>So he spends some time working up the courage to do this, and eventually makes his way to Steve’s office at the end of the day. He walks in, and Steve just asks, “Are you gonna do it?” Word had gotten around. “Are you really gonna do it?”</p>\n\n<p>Burrell looked Steve in the eye. “Do I have to? If I have to, I’ll do it.” He could tell by Steve’s expression that he didn’t have to. Burrell was free at last.</p>\n\n<h2 id=\"tales-tall-and-true\">Tales tall and true</h2>\n\n<p>Though most modern-era Apple employees were never lucky – or unlucky – enough to meet Steve Jobs, colourful stories about Steve were often shared between team members. While folks often enjoyed pumping up the <a href=\"https://www.theatlantic.com/technology/archive/2011/10/in-praise-of-bad-steve/246242/\">legends around Bad Steve</a>, I always liked the stories that humanized him.</p>\n\n<p>It’s been long said that when Steve Jobs would get into an elevator and see a rank and file employee, he would ask, simply, “What do you do?” An innocent enough question, on its face. However, given his years of accosting employees about their department’s shortcomings and the occasional summary firing, employees feared that you would be fired by the end of that elevator ride if Steve didn’t like your answer to “What do you do?”</p>\n\n<p>Reportedly a young designer at Apple had heard of this danger, and she was terrified of losing her job from such a chance encounter. She was newly pregnant and loved her job deeply, leading her to often rehearse in her head her answer – what if Steve Jobs ever asks “What do you do?”</p>\n\n<p>After one long day, she got in the elevator, and who else gets in, but Steve Jobs. Sure enough, he asks The Question and she’s off. She frantically launches into her elevator pitch, explaining her job, why her team is great, and she’s talking a mile a minute when Steve interrupts:</p>\n\n<blockquote>\n <p>Whoa, whoa, uh… I said, <em>“When are you due?”</em></p>\n</blockquote>\n\n<p>They had a good laugh. I always liked these kinds of stories, the ones that push back on the idea that Steve was an unequivocal jerk, or worse that he succeeded <em>because</em> he was a jerk. While that makes for an interesting tale, it conflates the key skill – a critical eye – with one man’s intermittent hold on his temper.</p>\n\n<h2 id=\"the-stories-that-matter\">The stories that matter</h2>\n\n<p>The stories we choose to tell about our leaders matter greatly. At a large company, employees’ mental model of their CEO can be even more important than the CEO’s actual behaviour. As Apple grew to tens of thousands of employees, Steve could never oversee every decision, or even a significant fraction of those decisions. Yet he was always there, in every meeting or argument, as <em>our idea of Steve</em>.</p>\n\n<p>When debating a UI approach or feature decision, the ultimate appeal to authority was, “What would Steve say?” “Would Steve ever let us ship this?” “Is this really good enough?” Through his famously demanding product reviews, he pushed down into the organization an understanding of what kind of work was acceptable at Apple, and how far it’s worth going to get something right.</p>\n\n<p>When Steve passed away in 2011, there was fevered speculation that Apple was doomed. “How could a company built by such an exceptional leader ever survive without him?” I was never really worried about that. He is truly missed, but his methods were not some secret recipe, held under lock and key. Apple employees had already spent years thinking like Steve.</p>\n\n<p>—</p>\n\n<p><em><a href=\"https://twitter.com/agammell\">Adam Gammell</a>’s <a href=\"https://itunes.apple.com/il/app/steve-stories-%C3%BAll/id1215821983?mt=8\">Úll Steve Stories app</a> from the conference is now available on the App Store. It features the above stories, and more importantly additional stories from people much more interesting than I.</em></p>\n"
},{
"id": "/2017/principle-of-least-surprise",
"url": "http://www.allenpike.com/2017/principle-of-least-surprise",
"title": "The Principle of Least Surprise",
"date_published": "2017-03-31T20:00:00-07:00",
"content_html": "<p>The status meeting is going well. Your demo was well received, the new feature is looking great, and you’ve been nailing your estimates.</p>\n\n<p>The product manager glances at her notes, and remembers one last thing. “Oh also, a lot of customers are asking for offline editing support on this screen.” Your eyes narrow, as they always do when you hear <em>offline</em> and <em>editing</em> in the same sentence. “The CEO’s asked us to prioritize it, so we’re going to go ahead and add it to 1.0.”</p>\n\n<p><em>Bwoooooosh…</em> time slows. The product manager has just lobbed a Scope Bomb. A threat to any project, the Scope Bomb is capable of causing great disruption and despair.</p>\n\n<p>“Uh…” You try to think quickly. “It does seem like a good addition, but…” You stare down the bomb as it sails across the boardroom table. “I’m not sure if two weeks is enough time though.” There, you said it. Your defense is mounted: they have been warned.</p>\n\n<p>“Oh, I’m sure you can do it,” the project manager smiles. <em>“I have faith in you.”</em> Aw, that’s a nice thing to say.</p>\n\n<p>“Thanks,” you hear yourself respond – and just like that, the bomb is armed. Unless somebody disarms it, in two weeks it will go off. Everybody except you will be surprised. This is bad.</p>\n\n<p><img src=\"http://www.allenpike.com/images/2017/surprise.jpg\" /></p>\n\n<p>In project management, surprise is the enemy. All surprises are suspect, but bad surprises are the actual worst. They are, bar none, the most common cause of conflict and stress on projects. Whether you’re a project manager or a junior team member, everybody benefits if you work to avoid surprises.</p>\n\n<p>Yet, on most teams, people instead optimize for keeping up appearances. They give out optimistic estimates, assume that questionable approaches are being taken for good reasons, and <a href=\"http://calleam.com/WTPF/?p=1205\">green shift</a> status by under-reporting danger. They think, “Why worry them about the budget if we might still pull it off?” Shortcuts like these may make this week’s status meeting more pleasant, but they turn next month’s launch into a crunchy hell.</p>\n\n<p>You see, when potential problems lurk under the surface, decision-makers and managers <em>can’t do anything about them</em>. A team that’s off track early on can always be corrected. On the other hand, when the navigator is surprised by an iceberg, you’re gonna hit that iceberg.</p>\n\n<p>And so, in software, people are hitting icebergs all the damn time. Teams unexpectedly miss deadlines, architecture problems come to light at the last second, and Steve suddenly announces that his month-long vacation to Bora Bora starts tomorrow. God damnit Steve! Where even <em>is</em> Bora Bora? What the hell are we going to do now?</p>\n\n<p>Well, what we’re going to do is teach our team how to minimize surprises. Yes, the whole team. Having a skilled project manager on any team is valuable, but as with quality, surprise minimization starts with you.</p>\n\n<h2 id=\"ice-report-42-to-412n\">Ice report, 42 to 41.2N</h2>\n\n<p>The key to surprise minimization is – big shock here – communication. If there’s a problem in software development that isn’t somehow helped by better communication, I don’t know what it is. Perhaps cache invalidation.</p>\n\n<p>In any case, managers and other decision-makers get a lot of information thrown at them. They’re seeing status from everybody, they’re getting pressure from all sides, and just aren’t focused full-time on how your project is going. While it <em>is</em> their job to cut through this noise and focus on what matters, it’s <em>your</em> job to nominate potential problems and dangers for consideration.</p>\n\n<p>Now, these messages may not be fun to hear. An optimistic or distracted client may not absorb an early warning. Maybe you mention that Steve has vacation in April, but your CEO is “sure it will be fine.” It’s easy then, to lean back and feel absolved of your responsibility – whether or not anybody actually plans for Steve’s absence.</p>\n\n<p>The thing is though, your job isn’t to <em>say</em> something, it’s to <em>communicate</em> something. If, as April approaches, it’s clear that nobody is taking into account this huge hole in the development plan, the fact you mentioned it once a few weeks ago doesn’t save anybody from hitting that iceberg, taking on 7 tons of water per second, and inspiring a profitable but tragic blockbuster film starring Leonardo DiCaprio.</p>\n\n<p>So leaders tend to miss potential dangers. Whether brought on by optimism or distraction, it’s a thing. That’s why the name of the game is – repeat after me – <a href=\"https://www.youtube.com/watch?v=nt9c0UeYhFc\">repeat stuff</a>. If things are going to go wrong and nobody is doing anything about it, bring it up until they do something about it.</p>\n\n<p>Admittedly, repeating potentially unwelcome warnings can be uncomfortable or annoying, and a lot of us in software are conflict-adverse. Nobody wants to pick a fight or be antagonistic, so it helps to have an approach for this. Here’s one simple technique: <strong>raise the issue in the form of a question that points to a potential fix</strong>.</p>\n\n<p>While saying “This deadline still looks questionable” is easy enough to brush off or get generically defensive about, the question “What’s our plan if we miss this deadline?” requires the recipient to actually absorb and process the idea of maybe missing the deadline. Next time it seems like a warning isn’t being heeded, give it a try:</p>\n\n<ul>\n <li>Since we probably won’t get all these features in, what are the lowest priority items in this list?</li>\n <li>Have we announced this target release date to anybody, or is it just our internal goal?</li>\n <li>How much time do you want us to spend attempting to hack around this limitation before it’s worth just building our own component for it?</li>\n <li>Do you think you’ll have that budget authorization in by Friday, or should we be planning to pause development while we’re waiting for it?</li>\n <li>Given how problematic these APIs have been in the past, can we put an extra week in the timeline for downtime and API regressions?</li>\n <li>Do I get to run this place while Steve’s in Bora Bora?</li>\n</ul>\n\n<p>Of course, you have to keep question-oriented pushback from devolving into passive-aggressive “would you rather us ship a good product, or add your stupid hamburger menu that everybody hates” needling. You can call out issues without being a jerk.</p>\n\n<p>In fact, these kinds of early warning questions often motivate positive conversations about icebergs before things are tense and options are limited. Ask them early, and ask them often. Otherwise, chances are, your project is in for a titanic surprise.</p>\n\n"
},{
"id": "/2017/feedback-mountain",
"url": "http://www.allenpike.com/2017/feedback-mountain",
"title": "Feedback Mountain",
"date_published": "2017-02-28T22:00:00-08:00",
"content_html": "<p>“Hire great people, and trust them to do good work”. I’ve always liked that idea. It feels right. Hiring great people is critical, and nobody likes to be micromanaged or criticized. So it seems simple – hire great people, and trust them to do good work. Try to stay out of their way.</p>\n\n<p>As a naturally trusting person, warm ideas like these always stuck with me as fledgling manager. Meanwhile, it’s always seemed to me that bold maxims about <em>driving people to achieve results</em> serve more to enable assholes than to actually inspire a great work culture.</p>\n\n<p>That said, as I’ve gotten a little older I’ve realized that there’s another reason that I naturally gravitate to the idea of trust: I’m adverse to conflict.</p>\n\n<p>It’s a longstanding Canadian tradition to dislike conflict. At our best, Canadians are polite, diplomatic, and give our peers the benefit of the doubt. At our worst, we avoid rocking the boat so long that it sinks.</p>\n\n<p><img src=\"http://www.allenpike.com/images/2017/kanye-meyers.jpg\" /></p>\n\n<p>To be clear, when somebody earnestly solicits feedback, I love providing it. So far this year, I’ve enjoyed critiquing an app’s UX flow, providing technical and copyediting feedback to an upcoming JSON specification, and even filled out an unreasonably long city zoning policy survey. (If you want a torrential rant, ask me about Vancouver zoning after a couple pale ales.)</p>\n\n<p>When unsolicited criticism come to mind though, the benefit of the doubt weighs heavily on me. They’re surely trying their best! They must already know. Do they really need me demotivating them?</p>\n\n<p>Combined with my tendency to launch into free-flowing criticism when asked for it, I can give people the awful impression that I’m secretly harbouring resentment, or that my people are doing a bad job and not even hearing about it. This is the actual worst.</p>\n\n<p>While I’d long known more frequent feedback was a good idea in theory, the turning point didn’t happen until a year ago. At that time, I’d noted that somebody deserved a raise – a happy occasion. I promptly confirmed that we could afford to give them a raise, cleared it with my co-founder, and asked our office manager to make the change on the upcoming payroll.</p>\n\n<p>Then, I stalled. I found myself being a total awkward penguin about telling them. <em>What the hell was wrong with me?!</em> What could be an easier conversation than “You’re doing great, here’s more money”? This was the flashing red light in my brain that made me realize I had a problem. I needed a habit and process for giving feedback if I wanted to be an actual leader rather than just a boss.</p>\n\n<p><img src=\"http://www.allenpike.com/images/2017/penguin-hole.jpg\" /></p>\n\n<p>Luckily for me, there is already a well-known and well-documented approach for managers to give and receive feedback, and that’s the One on One. When we were two people working in a basement, formally scheduling repeating 1:1 meetings seemed ludicrous. When we were four people, my hatred for recurring meetings overruled common wisdom. By the time we were ten people, we were way overdue.</p>\n\n<p>A lot has been written about 1:1s, <a href=\"http://a16z.com/2012/08/18/a-good-place-to-work/\">why they’re important</a>, and <a href=\"http://randsinrepose.com/archives/the-update-the-vent-and-the-disaster/\">what can happen in them</a>. The core idea, though, is to have a regularly scheduled time with each person that reports to you to talk about something <em>other than the status of their projects</em>. This can be positive feedback, office issues, long-term growth ideas, ideas for improvement, feedback for you, personal triumphs or struggles – anything but the code.</p>\n\n<h2 id=\"so-hows-it-going\">So, how’s it going?</h2>\n\n<p>A year ago this week, I scheduled recurring 1:1s with everybody in the company. At the time, I sent one of my very rare team-wide emails to describe what and why.</p>\n\n<blockquote>\n <p>The theory is that the agendas are led by you. The goal is to discuss new ideas, express concerns, and talk about what’s coming up. It’s not intended to be a project status meeting, but more of a people planning meeting. While they’re not performance reviews, part of the goal is to get us thinking about and talking about feedback and happiness more frequently.</p>\n</blockquote>\n\n<p>While our 1:1s are continuing to evolve and improve, and still have a way to go before I think we’re at optimal feedback bandwidth, they have greatly improved my comfort and skill at giving and receiving feedback. Folks have been a lot more motivated to think about learning and growth, and most importantly long-term problems now come up <em>way</em> faster than when we waited for people to bring them up in the course of work.</p>\n\n<p>Before 1:1s, people would often wait until they were deeply frustrated with something before bringing it up in a larger meeting. Now, I’m hearing about frustrations, hopes, and dreams while they’re still young and a lot can be done about them.</p>\n\n<p>Motivated by this success, we’ve recently become more enthusiastic about experimenting with our culture and how we communicate. Great work happens when you bring up the hard questions, debate different options, re-visit assumptions, and give constructive criticism in both directions. If you’re not sold on that, <a href=\"https://www.amazon.ca/dp/B00GL3HU4Y/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1\">you have a book to read</a>.</p>\n\n<p>I’m still adverse to micromanaging, and I still have great trust in my team, but I now know better than to attempt to fuel a team on trust alone. Teams are much better fed with clarity, support, and feedback – a diet low in calories, but high in power.</p>\n"
}
]
}