Archive of articles classified as' "Leadership"

Back home

A manager’s primary job is to build trust

14/08/2014

While interviewing for my new position at Cozy, I was repeatedly asked what the job of an Engineering Manager is.* By the end of the day, I had decided (for myself, anyway) that the most important job of an Engineering Manager** is building trust.

  • Senior engineers must trust you. They can succeed without you, but you can’t succeed without them. Why does your job exist? It isn’t enough for you to trust them; that’s a prerequisite. If you don’t trust them, that needs to be rectified first. If they do not vehemently trust you, your role is not just worthless, but a net negative.

  • Junior engineers must trust you. They need to have a reason to stick around. They must trust that you are giving them opportunities, and they don’t need to leave to be treated better. They need to trust that they are learning, growing, advancing. Finally, they need to believe that if and when they leave to see what else the world has to offer, they will be welcomed back. If junior engineers do not trust you, they will leave, and take their ideas and passion with them.

  • Design must trust you. They must believe you when you present estimates or assessments from engineers. They must believe that they are getting good information from you, and you aren’t an out of touch middle manager. They must see continuous improvement and engagement from the engineers. They need to trust that you and the engineers are working towards the same goals as they are, with fire and passion. If design does not trust you, you are damaging engineers and company and should just get out of the way.

  • Management must trust you. This is generally an easy one, because if they don’t trust you, they should fix it or remove you.

  • Finally, one that cuts across roles: malcontents and metathinkers must trust you. Many people (especially engineers) just want to avoid politics and are happy to work on on their tasks and not ask questions. As long as you don’t actively screw up, these people will usually trust you. Much more difficult are the critics. They come in all shapes and sizes. It’s not that they need to agree with you, but they do need to trust you. These people often have big ideas and cultural influence. Distrust will drain your organization of talent. As a member of this category, I take this very seriously. When I’ve actively distrusted management, and subsequently left, there’s been a flight of talent afterwards as problems get worse. I’ve written about the importance of the malcontents on this blog before, and as a manager it’s always been a yardstick. If malcontents and metathinkers are leaving, something is going very wrong.

Trust is probably the most important metric for whether you’re doing a good job and your organization is healthy. It is a product of some actions, and a foundation of others. If it’s going up, your organization is getting stronger. If it’s going down, you need to get to work.


* I really enjoy interviews, especially in-person interviews, because it really helps me clarify my beliefs. This can lead to a high bounce-rate, but generally I’m left with culturally compatible companies after that. I consider this a benefit but YMMV.
** Any manager, really.

5 Comments

“Do you expect too much from people?”

11/08/2014

Last year, a coworker asked me if perhaps I expect too much from other people. I thought about it a moment and said:

No. I do not accept the argument that I’m somehow inherently superior to most others. In fact it is because I know I am not superior that I have high expectations of others.

In the intervening year, I’ve come to see that this belief drives a lot of my management philosophy. In general, I assume the best of people I work with. If someone is not performing, I do not blame them; I blame myself (or whoever their manager is) and systematic problems that they are not in control of (but hopefully ones I am).

Of course people have different innate abilities and experiences. Some people have a high aptitude for certain types of work, and some have chosen a path that may not be a good fit. But the realities of business are that these things can quickly change, and an asset one day can be a liability the next. When a company has grown past a dozen people, I believe its time to start favoring nurture over nature. If someone isn’t performing, it is management’s problem.

This is true of not just employees, but other managers, and it was specifically about two other managers that this question was posed. The times were a-changin’, but these individuals were in roles they were ill suited for. They simply did not have the experience or competence to drive through the changes that needed to happen. It was up to their (our) management to take responsibility, but instead I heard apologies that “maybe they aren’t the best suited” and other meaningless explanations. I didn’t expect them to magically change; I expected management to do their job: get involved and well, manage!

If I expect something, it’s that people can both teach and learn. If the ability of people to grow is not an organization’s chief expectation- if management is not set up to grow employees, or management is not prepared to mature itself- I can’t imagine what they think their long-term prospects are. Perhaps they aren’t expecting much.

No Comments

You must manage what you can’t measure

8/08/2014

We all know the quote:

You can’t manage what you can’t measure.

The quote is often incorrectly attributed to W. Edwards Deming. Thank goodness, because that sentiment is absolutely ridiculous, and Deming is one of my heroes. In fact, a more accurate Deming quote is:

The most important figures that one needs for management are unknown or unknowable… but successful management must nevertheless take account of them.

It’s very important to understand how absurd the “can’t manage what you can’t measure” idea is. It leads to articles like this:

It is an old management adage that is accurate today. Unless you measure something you don’t know if it is getting better or worse.

No, it wasn’t accurate when Peter Drucker promoted it, and it isn’t accurate today. This quote is so counter intuitive, I’m not sure it became popular. Are your managers idiots? Are your employees automatons? Do you believe you can measure everything about your business? That the more you measure, the more successful you will be?

If you want to truly engage with employees as empowered and creative individuals, you must manage what you can’t measure. If you want to create a learning organization optimized for long-term health, you must manage what you can’t measure. To forget this is to engage in one of the great sins of management.

An absolutely wonderful book on this topic is Measuring and Managing Performance in Organizations. I really encourage anyone who believes that measurement is a prerequisite for management read it. It explains, with anecdotes, statistics, and logic, how depending on measurement will lead to deep organizational problems.

1 Comment

Everyone should take vacation at the same time

31/07/2014

Throughout my career I’ve always seen people struggle with taking vacation. People are too wrapped up in what they’re doing. Managers can’t allow critical people to go missing. There are weeks of trepidation and handover and “I don’t know how to fix that” emails. To a large extent, this can be fixed with shared code ownership, comprehensive automated testing, and all those types of good development practices. I have a better idea, which I saw in great use at CCP (which for a long time did not have those good development practices):

Everyone vacations at the same time.

In Iceland, this was a cultural thing. From what I understand, employers aren’t allowed to deny you vacation between May and September. Everyone goes on vacation in July. The office is empty. Things just go relatively smoothly as no one expects anything to get done during July (its a great time for side projects). This “July slowdown” wasn’t limited to CCP, as people who need visa renewals in the summer no doubt learn.

In Atlanta, the studio just closed down for two weeks in July.

In both cases, there may be a skeleton crew to keep things running, people on call, etc. Its just that no one expects anything non-immediate to get done. This has many benefits: its easier to plan for, office costs are cheaper, there’s a single silent period rather than months of rolling disruption, everyone takes a refreshing vacation, and much more. It’s pretty much the only vacation policy I’ve seen that was largely resilient to the pressures that keep people from taking vacation. To be sure, some people were screwed over by bad managers, but (in contrast to most other management offenses) this was largely due to particular managers and not underlying cultural causes.

If you see the people around you failing to take the proper vacations everyone needs to keep going, I’d encourage you to try having everyone go on vacation at the same time.

6 Comments

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

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

Results are not the point, followup

19/05/2014

In response to a previous post explaining the phrase “Results are not the point“, commenter RenRen Gabás says:

Both approaches have their own place. It’s easy to see why Toyota/Lean works well with manufacturing and operations. Continuous service and operations needs continual improvements. However, there are times when you need to forget all about process and workflow in order to break new ground. I would place breakthroughs in research and product development right in the Danny category.

Unfortunately, history (and logic) shows that Jess (continuous improvement) is still going to out-innovate Danny (gets drunk and makes stuff) and come up with far more breakthroughs.

  • Exhibit A: The Prius (first successful hybrid car) and Lexus (Toyota’s first luxury line) demonstrate that continuous improvement is not limited to operations. These were successes of product development and marketing.
  • Exhibit B: Google, a company filled with innovation, research, products, and big ideas, is also a world leader in analytics and iteration! Who do you think their process most closely resembles?

Do not confuse the stifling bureaucracy of a large company to embody Jess, and the creative chaos of a startup to embody Danny. This is a fallacy. Large companies are more stifling, and startups are more creative. But this is due to intrinsic properties, not continuous improvement.

Another way of saying “results are not the point” is “do not trust your fortune to randomness.” I don’t know anyone who would disagree with that! Yet when we take the Danny approach, that is exactly what we are doing, no matter the nature of what we are working on.

1 Comment

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