Archive of articles classified as' "career"

Back home

Hiring your cake and eating it too


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

Adjustable standing desks should be mandatory


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: 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!


Book done, back to blogging


This morning, I send in my final-est drafts for my book, Practical Maya Programming with Python. This is actually the second time it’s gone to production. The editing process has been, uh, challenging, which resulted in several months of delays.

I’ll post with more information when it’s for sale, but you can pre-order it now!

Anyway, now that the book is out of the way, I can get back to blogging more regularly.


The manager’s responsibility to review code


I believe any technical leader has a responsibility to review all the code that goes into a codebase.* I am certainly not the only person to feel this way (Joe Duffy as MSFT and Aras Pranckevičius as Unity have said the same).

Furthermore, I don’t believe the responsibility to review code ends at a certain level. Everyone from an Engineering Manager to the CTO should be reviewing code as well. In my experience, I’m able to do thorough reviews for 5 to 8 people, and more cursory reviews for another 15 to 20.

Code review above a team lead level** is not about micro-management. A manager should never, ever be saying “we do not use lambdas here, use a named function instead.” Instead, try “do you think this would be more readable with a named function instead of a lambda?” Or maybe you say nothing, and observe what happens, and inspect what other code looks like. If lambdas are common in the codebase, either your opinions need more information, or you have done a poor job educating.

Code reviews by managers should be about getting enough information to manage and lead effectively.*** It keeps you up to speed about what is going on, not just in terms of tasks, but in terms of culture. Are people writing spaghetti? Are bad choices challenged? Are hacks put in? Is code documented? Are standard libraries being used? Are the other technical leads reviewing and leading their teams effectively? You can learn an incredible amount through code review, and you need this information to do your job of leadership and management effectively.

*: I believe all programming managers and leaders must be able to program. I find it shameful this needs to be said.

**: It should go without saying, but team leads should be reviewing every checkin on that team.

**: Code reviews are the genchi genbutsu, or the go and see part of Lean management.


What if Carl Sagan were a hack?


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?


“What did you learn?”


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.


Removing external hiring as a tool (Part 3 of 3)


In this post I hope to explain how hiring externally as a tool for fixing problems ultimately leads to a weaker organization.

When I began writing this post, I was having a hard time. Whereas the post talking about what a bad idea firing is was easy, the situation is considerably better for hiring. For starters, there are more organizations that do a good job. Very rigorous hiring practices, even during growth. It’s also easier to talk about how a company hires people than how it fires people, as its generally a positive experience (which is why this article probably seems a lot weaker than the previous). Of course sometimes you need to hire specialists for very specific areas (I’m talking something like ‘hardware emulation’ or ‘low-level rendering engines’, not ‘databases’ or ‘UI programming’), where it is prohibitive to train or grow people in a year. And sometimes there are amazing individuals you just need to have (take Ward Cunningham being hired into New Relic or John Carmack becoming CTO of Occulus as examples). Then there are organizations in periods of rapid growth. While rapid growth is always risky, it’s often necessary to bring enough force to bear in innovative companies. I’d much rather see stable growth but it’s not always an option. So I needed a clear demonstration of the problems.

Then, like manna from an ironic heaven, I saw this article about Abercrombie’s CEO. After investor calls for his resignation, Abercrombie renewed his contract and stated their plan to hire in three executives to manage each of their brands. The idea is that one of them will replace the current CEO, and the CEO has done a bad job managing things, and of course did not groom internal candidates, so it seems they are due to come from the outside.

I don’t understand how anyone expects this to end well. Each Brand President will come in, make changes (including, probably, layoffs!) that benefit the short term (because their goal is to be CEO), and then: 1) The one that becomes CEO will stay a few years. The average tenure of a CEO in America is about 4.5 years. 2) The two that do not will likely leave, meaning new executives will be hired in and there will be more instability.

This is the sort of hiring- not just at the CEO level but all leadership levels down to team lead- that I think can be misguided. Why?

Mostly, because it disguises a problem. Most organizations buy into the idea that internal candidates should be preferred to external ones (another Lean principle!), yet still need to look outside for senior talent and managers. I would compare the situation and solution to DevOps: if deployments are an issue, the worst thing to do is isolate their handling to a small group and deploy less frequently. The DevOps movement has shown us the power of the mantra of “if it hurts, do it more often.”

I believe the inability of an organization to groom internal candidates indicates severe management problems, and because the feedback cycle is so slow for personnel changes, trying to defer it and “fix it for the next time” will never actually fix the issues. Internal hiring will force an organization to confront its issues, which can include:

  • Stifling managers that do not or cannot groom their reports for seniority and leadership.
  • A dysfunctional project that people do not want to work on and would be under-staffed if people were allowed to transfer.
  • Projects that depend on a couple of people, making them unable to transfer.
  • A general lack of learning and growth, perhaps because everyone is 100% allocated, with no slack time.
  • Work that is not challenging or evolving, causing the same experience over and over.
  • Valuing efficiency and specialties of individuals over utility and value.

All of these issues (and more) cause issues with internal hiring, but also are bad for the organization overall. Wouldn’t it be great if you could both fill a key role and address issues?

Is the risk too great of promoting a bad candidate? I don’t know: is the risk too great of hiring in an unknown quantity into a leadership position? Is the risk too great of having a candidate who wants a job change but your organization can’t give it to him or her?

If you are looking to do anything but shrink, you should always have ‘junior’ positions open and take the cream of the crop. This is especially true if you are outside a major tech hub.

There’s also another type of problematic hiring: adding resources to failing projects (whether outside or inside hires). We all know Brookes’ Law, that “adding people to a late project makes it later” but I can’t count how many times people do it anyway. If there are problems with a project, adding people is the worst way to address issues. “We need more resources” is a tantalizingly simple explanation for why something isn’t getting done, but I’ve never seen it be the actual reason. It is, like hiring leadership, a great way to disguise and distract from the real problems. This topic requires a separate post, though.

I also want to point out a perversion of ‘internal hiring’: creating an excess of managers and handing out seniority titles as candy. What I’m advocating here is when you need a manager, look internally, not to turn someone into a manager because they want it. Likewise, I’m not saying you should give someone a more senior title because otherwise you’d open up a senior developer spot, I’m suggesting you give them the responsibilities (say, team leadership) and see how they handle it.

It is much easier to hide the lack of internal hiring in technology companies because it is growing so quickly (there’s a need for external hires, and people can get jobs elsewhere if they become frustrated). But ultimately I see a dependence on external hires on the other side of the ‘firing as a tool’ coin. I don’t think you can do one without the other. They are inseparable from not just a cultural level but a practical one as well. It is about investing in your employees over looking for easy answers.

No Comments

“Delighting customers” is Lean’s secret handshake


Whenever I see the words “delighting customers” (which is, let’s face it, an awkward phrase) in a non-Lean context like a job description, I can feel the author winking at me. It tells me “we try to be Lean and if you get our drift you probably want to join us.” It instantly gives said company plenty of extra points.

I just wonder how long until “delighting customers” becomes a played out catchphrase (if it’s not already)?

No Comments

Removing firing as a management tool (Pt 2 of 3)


So in my last post, I wrote about the possibility of taking hiring and firing off the table as a management tool. In this post, I will focus on the firing. Firing itself has two halves: individual dismissal as a way to fix performance problems, or layoffs as a way to fix organizational problems.

Lifetime employment has been a staple practice in Japan for decades. You can read more about it here, but it is as it sounds. Employees are only removed in extreme circumstances. Layoffs are almost unheard of. Tied up in this talk of firings is the modern management malpractice known as performance reviews. Enough has been written about how they are the greatest scourge ever inflicted on modern industry so I won’t go into it.

Using firing as a way to manage performance problems cannot work. The “10x Programmer” myth speculates that the difference between best and worst programmers is 10 times productivity. This sounds a lot but it puts every programmer within a single order of magnitude. That’s not that huge. Most of us are going to be clustered in the middle. So, all other things being equal, if you could make sure you are only hiring better people than you’re firing, you’re looking at a still small boost to productivity. And I want to be clear, the idea that you can hire a “better” person is unlikely- have you figured out how to systematically make your hiring better and proved it?

More likely, you are firing someone because their skillset or attitude is not so useful or relevant anymore. The QA person who won’t script. The programmer who won’t write unit tests. The designer who wants to work on something else. Firing an employee to fix this is ridiculous. A poorly performing employee is a management failure, not an employee failure. If the employee could have done better, she would have. By pushing the responsibility onto the employee, you are missing the opportunity to fix a problem. When you have someone in this situation, you sit down with other management and figure out why this situation exists and what can be done about it. And you sit down with the employee and engage with them about what’s expected and you come up with a plan. And if the plan isn’t met, you revisit it and see why it failed. You don’t fire the person. If they are truly unwilling to change, they will quit. Don’t worry so much about the “lost time.” You are already pulling along years of dead weight in your “high performing organization.”

There’s also the issue of incompetent management. Performance problems aren’t unique to individual contributors (ICs). Managers must be able to be “demoted” or reassigned. It should not be suicide to one’s career to move into another role that is a better fit (due to other circumstances or do to the manager’s abilities). A good idea is to not pay managers more. Title changes would hurt a lot less if they didn’t involve salary, and it wasn’t seen as the company punishing a manager but seeking to make a long term investment instead. It takes absolutely forever to fire an incompetent manager, and oftentimes it never happens. And clearly a poorly performing manager is probably an even bigger risk than a poorly performing IC. There need to be effective mechanisms to improve performance of managers even more than ICs!

Removing firing as a tool requires you to deal with performance problems in a way that teaches you something. It takes a coward to fire someone. It takes a leader to accept responsibility for a bad situation and work with involved parties to make it better. Odds are your employees want to make things better. If they really hate you and don’t give a shit, you are probably not the type of person to read this blog.

And then there are layoffs. Ugh. The inevitable outcome of some new executive, or a merger, or strategic change, or restructuring, or whatever. A layoff should be the absolute last option. It should come after executive pay cuts. It should come after a vote on temporary across the board salary cuts. It should come after stopping the acquisition of new companies. It should come after cutting back on spend-heavy areas like marketing. It should come with a mea culpa from executives, not a “we are rightsizing.” It should come with a deep and transparent retrospective of how things got out of hand (more than just “global financial crisis” please!). It should come with a plan on how to make sure this doesn’t happen again (and a commitment to never do it again). It should come with an understanding of how god awful and unnecessary layoffs are (Japanese companies are the obvious example but there are plenty of long-lived companies in Western industry that have never had layoffs). Of all the management cancers the technology industry has been able to avoid, layoffs are not among them.

Layoffs are the most blunt tool to ‘fix’ a problem, no matter what that problem is. They cause an untold amount of harm. The blunt trauma is almost impossible to learn from- you don’t get to keep the limb you’re chopping off to figure out what went wrong and what to do better (other parts of the body may come up with explanations but they’re probably wrong).

The executive that has layoffs is being as lazy as the manager that fires. Just because both of these things are emotionally difficult all around does not make them the correct thing to do. Avoid them not because they’re hard, avoid them because there are better ways of doing things. Fix your problems by actually fixing your problems. Take firings as a tool off the table completely.

Next up is hiring senior people from the outside.


Python Enrichment and PitP


When I was starting my job at CCP, I posted about some things I wanted to do as a lead. I’ve been through two releases with the Tech Art Group in Iceland (and for the past 6 months or so been the Tech Art Director here) and figured I’d measure my performance against my expectations.

Training sessions: I’m proud to say this is a definite success. I was the initial Coordinator for our Reykjavik Python Community of Practice (studio-wide volunteer group that discusses python in general and its use at CCP), where I started two initiatives I’m very proud of. One is the weekly ‘enrichment session’ where we watch a PyCon video, go through a demonstration or tutorial, etc. These have gone over great, the trick is to do them even if only 4 people show up :) The other is Python in the Pisser, a python version of Google’s Testing in the Toilet. I hope we can open source the newsletters and maybe share content with the outside world. More information on that coming in the future.

Collective vision/tasking: We run an XP-style team on tech art so I like to think my TAs feel ownership of what they are working on. In reality, that ownership and vision increases with seniority. We are actively improving this by doing more pairing and having more code reviews- the team is at a level now where they can review each other’s work and it isn’t all up to me to mentor/train them.

Evolving standards and practices: We started in Hansoft, moved to Outlook Tasks, and settled on Trello. We’ve discovered our own comfortable conventions and can discuss and evolve them without getting into arguments or ‘pulling rank’.

Community engagement: The CoP and mentoring has definitely done some work here. I try and give everyone 10%/10% time, where 10% is for ‘mandatory’ training or non-sprint tasks, and 10% is for their personal enrichment.

Move people around: We haven’t had much of an opportunity for this but we did change desk positions recently :) The art team is too small to have many opportunities and all graphics development is on one scrum team.

Code katas: We had one and it was mildly successful. We plan to do more but scheduling has been difficult- we do two releases a year, and DUST introduces complications in the middle of those releases, but we’ll be doing more things like it for sure.

I’ve also been doing very regular 1-on-1′s and, I hope, been getting honest feedback. Overall I am happy with my performance but can improve in all areas, even if that means doing more of the same (and becoming a better XP team).

Anyone want to share what successful cultural practices they have on their team/at their studio?