Archive of articles classified as' "Culture"

Back home

Hiring your cake and eating it too

6/06/2014

When evaluating candidates, I have always been a believer that cultural fit and potential to improve is more important than technical ability. Of course I like to review real code samples and give a programming test, but I rarely ask for whiteboard programming. I am not a master of algorithms or math and don’t have a CS background, so I don’t require that of most candidates*. As Five Thirty Eight explains and shows, people just want to date themselves.

This policy is amazingly ego-centric. But it’s also worked pretty well. Without exception, I’m proud of the hires I’ve had a primary stake in. But it is the best policy, at least for the type of work I’m doing?

I think I am a pretty darn good hire. Why would I want to exclude people like me? Well, the fact is that I’m not special. There are way more gifted people around than me. There are plenty of people who are a great fit, and are great leaders, managers, developers, and coaches, and are awesome at math and algorithms. Should I overlook myself to try and get someone better?

Clearly companies like Google can do this. There are anecdotes about people who they hired the second or third time around. People like Steve Yegge. On the other hand, there are plenty of managers that hire “to fill a seat.” Can every company interview like Google, and reject otherwise promising candidates that do not ace a challenging technical interview?

Who you choose to hire does not define what your company is, it defines what your company will become. If you give in and make unenthusiastic hires, your amazing company will be dragged into mediocrity. If you hold the line and hire only the best, you’ll continue to excel, if you can find people. In reality, most companies are somewhere in the middle.

The “best” policy is the one that fits your situation. In an isolated job market, you may choose to value fit and culture. A tight-knit culture may help retention, and make it easier for the inevitable low performers to improve. At a startup, you may have limited headcount, short timelines, and immediate technical needs. Cultural fit would be trumped by technical expertise and experience. On the other hand, cultural fit may be most important at an established company. The biggest risk is a dilution of the culture, and there are plenty of senior people around to do mentoring.

Recognizing what you should select for is much more important than simply always trying to be as selective as possible.


* Obviously there are exceptions. If you need expertise, you need expertise. My thoughts apply to the 80% case.

1 Comment

Should a team be able to abort a sprint?

2/06/2014

After my second retrospective on a new project, I unloaded some pretty harsh criticism about what we were building. I felt it was a “solution in search of a problem” and “not high value.” After proposing an alternative and convincing everyone to change direction, our sort-of Product Owner blasted me for not bringing my issues up sooner and basically wasting two weeks of work. I said I had voiced my concerns, but not strongly or formally, because I was focused on getting the sprint work done. My feeling was that it wasn’t constructive to second-guess things in the middle of a sprint, and that I trusted the people who made the decisions. Especially as the new guy on the team, I leaned towards agreement.

We both had a point. As a senior person, I had a responsibility to speak up. As a team members, I had a responsibility to get our work done. I don’t know if I made the right choice in this instance. Perhaps if I argued too loud too early, I wouldn’t have had enough credence for people to believe me, and would have been in a worse spot at the end. Or perhaps I would have saved two weeks or work.

This is one more reason I prefer one-week iterations. A week is too small to break up, so you just go heads down. But you don’t work on the wrong thing for too long. You get two or three times the chances to learn and improve.

1 Comment

There is no essence of Agile

30/05/2014

real agile is: talk to the users directly, know their pain point, address it, repeat. -someone on Twitter who I disagree with

In many conversations about Agile, especially as of late, I read something like the above tweet. I don’t know where the idea that Agile can be distilled down into one or two practices or principles comes from. Thinking this way is extremely harmful. If you think like this, I’d love to hear your explanation.

Agile methodologies come out of Lean thinking which comes out of the Toyota Production System (TPS). The TPS is incredible. It mixes explicit practices such as 5S, ideals such as JIT, and principles such as “respect for people” into a unified, harmonious way. TPS is often represented using a house metaphor as in the following image:

house-of-lean1

The house is an apt metaphor because every single component is structurally vital. “Talking to users” and “addressing pain points” corresponds pretty closely to “customer satisfaction,” which is the roof of the TPS house. The roof is elevated by the walls, which are secured by the foundation. The roof is integral to the function of a house, but no more so than any other component. Customers can only help inform what you produce. If you are unable to produce those things at high quality, speed, and efficiency, and improve over time, then it doesn’t matter how much you talk to customers.

Adding an Andon cord to an assembly line does not make a manufacturer Lean. Being Lean requires a whole set of practices, ideals, and principles working in unison. It can be TPS, or your adaptation, but it requires incredible rigor, skill, and learning, and it’s not simple. Likewise, no single practice, from TDD to iterations to talking to users, creates a well-performing Agile organization.

There are plenty of pseudo-Lean companies, just like there are plenty of pseudo-Agile shops. On the plus side, the damage from Six Sigma Black Belts is far more severe than the Certified Scrum Master racket.

Companies that are Lean are rare, and have been at it for a while. It’s silly that every JIRA jockey thinks they have learned the essence of Agile. Being Agile is difficult, complicated, and takes a while. Let’s not try and distill it down so much that we totally dilute it.

5 Comments

Adjustable standing desks should be mandatory

26/05/2014

At CCP’s Iceland office, everyone’s desk is able to adjust into a sitting or standing position. I don’t know who decided this perk. It must have been a huge expense. Adjustable sit/stand desks are already expensive in the USA, and in Iceland I’m sure they were three to five times more expensive. Until recently I thought it was required by law! This is quite an investment for each worker, but in my opinion, well worth it for a wide variety of reasons, from health to programming. Why?

  • Lots of people want to try a standing desk but don’t want to be “that guy” who asks for an expensive piece of equipment but doesn’t use it. Having an adjustable desk by default removes barriers to entry.
  • Seeing people stand (and talk about how much better it is) becomes viral. I watched it catch on at work over a few years to where everyone in certain areas is doing it. This wouldn’t have been possible without everyone already having adjustable desks.
  • Standing for part of the day completely fixed my sciatica (lower back/hip/butt pain). It also apparently has lots of other health benefits.

Okay, but “health of your workers” is a pretty nebulous concept, and in America, a business’ job is to make money for shareholders, not, like, improve society! Why would Donald Sterling want to buy black employees adjustable desks in addition to cars and houses?

  • It helped me concentrate. I was able to work faster while standing. Standing is time for working. I don’t know if this is universal, but I certainly didn’t see many people playing games or getting lost in a “YouTube hole” (as a friend puts it) while standing.
  • Pair programming and over-the-shoulder reviews were incredibly more effective while standing, even with people of different heights. Standing, I could pair easily with pretty much anyone, from a good friend to an interviewee. I was able to mentor far more effectively since standing felt like such a more natural way to collaborate.
  • Even if you don’t like pair programming (have you tried pairing while standing?), being able to program and edit code collaboratively during a code review is, IMO, a requirement. Standing code reviews were more effective than sitting. More issues got uncovered and more knowledge was transferred.

How do I know all these things? Well, when I transferred to the Atlanta office, I no longer had an adjustable desk (or a sensible healthcare system, but that’s another matter). Suddenly, reviews with people I was very comfortable with and worked with previously felt rushed and unpleasant. They were done while leaning over (“when can I get my crotch out of this other person’s face“), or sitting together (“oh god we keep brushing knees“).

Pair programming, which is the foundation of the way I mentor (and learn), was basically ineffective. No one programs well at an angle to the monitor, and people mistype constantly if the keyboard is not in a natural spot. It’s difficult to share knowledge or equipment in such an awkward situation.

If you want a vibrant and dynamic engineering culture, standing desks are a must. I view them as fundamental to a programming team as decent workstations and SSDs.


Real studies about adjustable desks are difficult to find. This 538 analysis is promising: http://fivethirtyeight.com/features/i-stand-corrected-about-the-best-kind-of-desk/. Otherwise, it is very easy to find endless anecdotes about the usefulness of adjustable desks. Start with the 538 article’s comments if you don’t know anyone!

5 Comments

The myth of the brilliant jerk

21/05/2014

Do not tolerate brilliant jerks. The cost to teamwork is too high. – Reed Hastings, Netflix CEO

So I was all prepared to write about how much I hate this quote, but Freddy Nager already did. It is thorough and insightful and explains how out of context this quote is. Thanks to Freddy for doing a far better job ripping this apart than I did. (It also reminds me the difference between real writers/bloggers and people who just have a blog, like me…) Here’s his conclusion, but I suggest you read the whole thing:

In short, Netflix wants only stars who are passionate and courageous and innovative and always do A-level work while abhorring process and questioning assumptions yet working as a team — otherwise they get fired. Sounds brilliant. And jerky.

Why is the Hastings quote so popular? The Netflix presentation is a really excellent one and full of interesting advice and strong statements. I’d even say the brilliant jerk of corporate culture presentations! Why does this quip about “brilliant jerks” resonate with people so much? Probably because we’ve all run into the “brilliant jerk” and the idea of just firing him or her is so pleasing. It also remains cowardly.

This hits particularly close to home for me because I have seen the mistreatment of far too many brilliant jerks. Brilliant jerks are necessary to grow and innovate. The difficult part is to figure out how they can be brilliant but be less jerky.

Firing brilliant jerks is the absolute worst thing to do for teamwork, or indeed the health of the company as a whole. I could spend more time convincing you, or you could view the Netflix slideshow that spawned the quote!

2 Comments

An Unfoolish Consistency: Introducing PEP8 to a legacy codebase

25/04/2014

Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

The EVE source code, being initially developed before PEP8 existed, was based on Microsoft’s C++ style. Mostly this is manifested in UpperCamelCase function and method names, mixedCase parameter and variable names, and file headers and class/method delimiters. There was also a style guide that was probably larger than PEP8 (though included a bit more than basic style).

Today, most new code is PEP8 compliant. “What!?” I hear you say. “A foolish consistency is the hobgoblin of little minds!” I agree, and I’ll get back to that at the end. But first, what was involved in introducing PEP8?

The move started when I asked my team if anyone wanted to keep using the headers and delimiters. No one did. So we took out the headers and delimiters before we did any modifications to a file.

A while later, I asked all the programmers on the project if anyone felt strongly about keeping the existing style. No one did. So we started writing new packages with PEP8. The rationale was that our code was already calling code using lowercase_underscore in the stdlib, so it’d be no different for that same code to call a relatively independent, though still project-related, library.

Yet a while later, I started slipping some PEP8 code into modules or packages that weren’t PEP8. I was worried people would get upset. No one did.

And finally, in preparing some basic utility libraries for usage on other projects, I converted the function and method names to PEP8. This involved find-and-replace or CamelCase aliases. I bet you can guess who cared about these “superfluous” edits, or objected to the fact that parameter and variable names remained mixedCase? No one did.

Emerson’s quote “a foolish consistency is the hobgoblin of little minds” is often used as a reason to not change existing code to PEP8, or introduce it into a non-PEP8 codebase. But the quote means the opposite. Foolish consistency” is being unable to change your mind because it would contradict something you’ve believed or said. So PEP8 has it so right but so wrong: the foolish consistency is to keep things the way they are, even though we know what the right thing to do is.*


* I would recommend introducing PEP8 incrementally. I also suggest keeping things backwards compatible when it is more prudent, such as if the changes are expansive, or you do not control all the code. I also don’t suggest being a stylistic nitpicker when it comes to non-functional aspects such as line length. There may also be times to break the rules (a class that behaves like a function, or function that behaves like a class def). As always, good sense should be applied when considering any viewpoints on this blog.

No Comments

Results are not the point?

15/04/2014

The phrase “results are not the point” often confuses people new to Lean thinking. It confused the shit out of me, not having really understood it even after my first few books. This is a shame, because it’s such a simple thing.

On Friday night, Danny got really drunk, coded a game, and the game was a hit. Danny did this again the following Friday, with the same results. And once more that third Friday.
Jess codes on sober Saturday nights instead (still drinks on Friday). Jess programs a game, and it runs poorly, crashes often, and isn’t fun. The following Saturday, Jess makes a new game, which runs fast but still isn’t fun and crashes often. That third Saturday, Jess creates a new well-performing, fun game, though it still crashes.
Would you bet on the long-term success of Danny or Jess?

Clearly, the better bet here is Jess. Jess has discovered a process which can be continuously improved. There is good reason to believe Jess will eventually create reliable success. The fact that Danny has been successful three times is basically irrelevant, since Danny’s process is totally haphazard.

This is the idea behind results are not the point. Focusing on the results, and not how those results were achieved, doesn’t improve anything in the long term. The point is to create a repeatable, empirical, continuously improving process. If we can create a reliable, successful process (which here includes culture and practices), we can get reliable, successful results.

9 Comments

Why Agile became meaningless

6/04/2014

Uncle Bob recently wrote a post about The True Corruption of Agile. I think it will be a defining post for me because, as I’ll explain in my next post, I’m ready to give up on Agile. It has become meaningless due to the corruption Uncle Bob describes, and trying to reclaim Agile isn’t possible.

Imagine the Lean movement without Toyota. Toyota is the guiding force in Lean because it grew out the The Toyota Way.* When Lean goes awry, Toyota- the company and its principles, practices, and culture- is there to set things straight.

Toyota can guide Lean because the company has been successful for decades and Toyota attributes its success to the principles and practices known as The Toyota Way. But for many years, Toyota’s success was explained away by anything except the Toyota principles. Finally, all that was left was The Toyota Way. Toyota is the Lean reference implementation.

Agile has no such entity. Instead, we have hundreds of “Agile” shops who attribute success to some (non-)Agile practices. Then, once they’ve evangelized their (non-)Agile stories, reality catches up with them and the success disappears.** But no one hears anything about that failure. The corruption and perversion here is inevitable.

Without a company like Toyota giving birth to Agile and showing others how to do it right, Agile was destined to become what it is now: meaningless and corrupt.


*: The Toyota Way started out as the Toyota Production System. They aren’t technically the same but for the purposes of this post there’s no reason to distinguish.

**: For example, maybe InnoTech decides to use Scrum on a global scale to ship an ambitious product, and talks a lot about how they pulled this off and what benefits it yielded. Years later, velocity is in the toilet because the endless mountains of technical debt created, and maybe the company has had layoffs. The Scrum transformation will be in a book or on a stage. The layoffs or technical debt will not.

1 Comment

What if Carl Sagan were a hack?

31/03/2014

I was watching the first episode of Cosmos, and Neil deGrasse Tyson talked some about how stellar of a scientists Carl Sagan was and what an impact Carl had on Neil personally. Carl’s abilities were important for his advocacy, because a) it lent him credibility, and b) it allowed him to engage. He practiced while he advocated. I can’t imagine Carl Sagan achieving the impact and legacy he did by abandoning the lab for the lecture circuit.

What a powerful lesson for those of us that manage people doing work we’ve never done. How can we deeply connect with them?

What a reminder for those of us that have moved into managing and left behind creating. Should our dues, once paid, last forever?

What a feeling for those of us who have moved into management out of expectation. Is it right to tell people what to do, while we have lost enough passion to do it ourselves?

2 Comments

“What did you learn?”

25/03/2014

When something bad happens to someone (firing, demotion, bad review, big failure), it’s natural for managers to ask that person “what did you learn?*

Unfortunately the answer is rarely what a manager wants to hear, and it’s also largely useless.**

Asking the question phrases it as the employee’s problem, while theory and experience both tell us that it’s far more often the management that is at primary fault (work environment, culture, all sorts of common cause variation. It is not at all useful to ask the employee “what did you learn?” unless the goal of the question is a) pure personal curiousity, as when family/friends/coworkers ask, or b) to get the employee’s take on how to improve the system so these things don’t happen.

Are we masters of our own destiny? I find thinking so is a useful way to behave personally, but a naive or dishonest way to lead and manage. If you believe that an employee is the primary driver of their behavior, rather than the system he or she works in, then you’re probably relying on destiny to create a successful company. Good luck! You may also consider playing the lottery.***

Unless you can reliably improve and grow the system and culture, you are relying on luck, timing, and personal attributes to create a successful organization. That’s fine, but very few managers would admit to wanting such a company. An event that disrupts or upsets an employee is a great opportunity to learn, so here are some better questions to ask your employee when it happens. (for clarity, I will use “we” for management and “you” for employee)

Better questions to ask your employee

What can we learn from this? I assume we think highly of our employee (we hired them****, or at least haven’t fired them before this). They probably have the best view of what went right and wrong. And if not the best view, then at least a unique one worth hearing. We have as much to learn as they do. After all, we- the manager, employee, and probably many other connected people- failed.

What do you think caused this? Your employee fell victim to the system. The difficult part is figuring out what parts of the system were the aggressors. Remember, even if this were truly their fault, our organization can’t grow from finding the employee at fault, so it behooves us to find something we can learn from.

Were you surprised? When people take risks, they expect to lose part of the time. The employee’s failure may not be due to a mistake, but a calculated risk that didn’t work out. This fundamentally changes what the “learning” is about. Let’s not presume bad outcomes were due to a lack of understanding or miscalculation on the part of the employee, but rather assume bad outcomes are due to a shortcoming in our management and the system.

Why were we surprised at the outcome? Why didn’t we see this coming? If we did see it coming, why didn’t we act earlier? Maybe your employee can help you learn to see this happening earlier next time, so you can do something about it. Or maybe you were warned about it, but saw what you wanted to see, and your employee can help you realize that.

What would “success” have looked like? Some situations are “unwinnable.” There war is lost, but the employee still believes there is hope. Find out what they were fighting for. You can make sure others that are fighting for the same cause don’t meet the same fate, either because you fix the issue, or do a better job explaining it.

There are many other good questions that should be asked. Big “failures” are great opportunities to learn, so let the discussion flow. You won’t learn and grow as an organization if your default response is to blame the employee. Every time someone gets a bad review, is fired, quits, or royally messes up, we must use that opportunity to improve as an organization.


*: I will state so there’s no confusion: I’m not talking about the words themselves. I’m talking about the idea that you are asking the employee what they learned as the primary way to involve them in the retrospection of “their” significant failure.

**: Usually what the employee probably thinks is you’re an asshole, the culture is broken, and the organization is fucked. So I spend this article focusing on why the question is useless.

***: I don’t worry about offending people here, because no one ever thinks they’re a bad manager. And you certainly aren’t!

****: I use ‘they’ or ‘their’ instead of “he or she” or “s/he” or whatever. I’m not sure what is in vogue today.

10 Comments