Archive of articles classified as' "Leadership"

Back home

We’re not so different, you and I

21/12/2014

Ben Sandofsky wrote a post about why QA departments are still necessary, specifically with regards to mobile app development. He makes a good point: mobile apps create a distribution bottleneck that makes very rapid iteration impossible. I agree, and this is a good angle to think about. I would have been happy with an article focused on this.

Ben is clearly a talented guy but this post was insane. In a literal sense. It is a rant for anti-Agile curmudgeons at best, and would leave me questioning the experiences of anyone that thinks this way at worst.

Websites ship embarrassing bugs all the time. They get away with it because they didn’t ship it to all users. You roll-out everything out to 1% of users, and watch your graphs. If things look good, slowly roll out to 100%.

The idea that this is this sort of incremental rollout is ubiquitous amongst web developers is crazy. It requires infrastructure, code designed to support split testing, experienced operations engineers, robust monitoring, a disciplined process, and more. The institutions with this sort of sophistication all have strong automated testing environments. Which brings me to my next issue:

I think automated testing accelerates development, but I haven’t seen a direct correlation between testing and quality. On projects with massive, high quality test coverage, I’ve seen just as many bugs slip through as projects with zero coverage.

This is the software equivalent to climate change denial. Where does this experience come from? I am not sure I’d be able to find a single developer who would corroborate this. Oh, right:

Tell a game developer you don’t need [QA], they’ll tell you you’re nuts.

The game industry is full of these folks who believe what they are doing is such an untestable snowflake. Unsurprisingly, games have historically been the buggiest software around. Never, ever look at game development as an example of how to do QA right. Not just automated testing, but manual QA too.

…a great QA team is far from a bunch of monkeys clicking buttons all day.

Game development has a hallmark technique of hiring masses of QA people and have massive layoffs at the end of projects. There is an entire website dedicated to tales of horror from QA people. It makes The Daily WTF look like paradise.

Take the unicorn of “two week release cycles.” As you build infrastructure for faster releases, simple code becomes unwieldy. Tasks that should take hours take weeks.

What does this even mean? There are endless apps on two week release cycles. I am confused how building infrastructure for faster iterations ends up adding complexity to simple code or tasks.

Disciplined development is a lost art.

You could make this argument when we moved away from punch cards. But the idea that success in mobile apps is achieved through discipline, but success on the web can be achieved by recklessness, is beyond baseless. It’s downright insulting.

I consider it a tragedy that, when faced with the reality of App Store distribution bottlenecks, Ben’s answer is to go back to the process of yesteryear and throw out the lessons we’ve learned. Why not invent new ways of building in quality? New ways of iterating on apps faster? There are so many interesting problems to solve.

Finally, Ben cautions:

Today, any web developer who wants to stay employed has learned to build apps. If web companies want to remain relevant, they’ll have to do the same.

I have a better warning. Don’t throw away the incredible advances we’ve made over the last decade. Don’t downplay the success and rate of innovation in web development as something that doesn’t apply. Don’t throw away the universal “good idea-edness” of automated testing. Don’t rely on a separate department to enforce quality. Don’t stop looking for ways to make development better.

1 Comment

The QA Department Mindset

8/12/2014

From this post by Rands, titled “The QA Mindset”:

At the current gig, there’s no QA department. […]

My concern is that the absence of QA is the absence of a champion for aspects of software development that everyone agrees are important, but often no one is willing to own. Unit tests, automation, test plans, bug tracking, and quality metrics. The results of which give QA a unique perspective. Traditionally, they are known as the folks who break things, who find bugs, but QA’s role is far more important. It’s not that QA can discover what is wrong, they intimately understand what is right and they unfailingly strive to push the product in that direction.

I believe these are humans you want in the building.

At my current job, we don’t have a QA department either. And like Rands, I wasn’t comfortable at first. I’ve worked on teams without QA, but an entire company without a QA Department? I’ve certainly had questions about the use of a QA department, but does that mean they are a bad idea?

Yes, and this line in Rands’ defense is why:

Unit tests, automation, test plans, bug tracking, and quality metrics. The results of which give QA a unique perspective.

I am a staunch believer of “building quality in.” Every bug that slips out is a failure of your development process. The way to higher quality is not to find, or fix, more bugs. It’s to avoid them in the first place.

If you rely on QA to champion unit testing, automation, bug tracking, and quality metrics, your development process is lacking its most important tools and measures to improving quality. Quality can’t be imposed by QA, it must grow out of enabled and engaged development teams.

I have a saying: “Don’t hire to fix a problem.” If you have a quality problem, hiring a QA department isn’t going to fix it. You instead hide the systematic problems that cause quality issues in the first place.

This is not to say “the QA mindset” isn’t valuable. It is. One of my best hires was Bjorgvin Reynisson, who was a Test Engineer at Nokia and I hired as a QA Engineer at CCP. He was embedded with the graphics engine team and he helped them develop extensive automated correctness and performance testing systems. He worked with them to recognized holes in their process and test coverage. He helped with tracking issues and increasing quality. This is the “QA Mindset” I treasure, and this type of person is invaluable to development teams. Bjorgvin unlocked a latent “culture of quality” in the team he was a part of.

I contrast this “QA Mindset” with the “QA Department Mindset“. The QA Department Mindset has two damning characteristics. First, it is innately adversarial, as Rands notes.

Yes, there is often professional conflict between the teams. Yes, I often had to gather conflicting parties together and explain[…]

Second, it is by definition a separate department, which creates obstacles to better integrating engineering and QA.

Bjorgvin should be spending time with his teammates and the rest of the developers figuring out how to improve the entire development process. He should not be spending time with other QA personnel focused on QA functions. When I was Technical Director for EVE Online, I made sure there were minimal discussions gated by job title. Talk of a trade went on in Communities of Practice, which were open to all. Sometimes this didn’t happen, and those times were mistakes.

Like Rands says:

Yes, we actually have the same goal: rigorously confirming whether or not the product is great.

If that’s the case, QA should not be broken out into a separate department. QA should be working side by side, reporting into the same people, measured by the same success metrics, contributing to the holistic success of an entire product.

I love the QA Mindset. It’s tragic that having a QA Mindset gets confused with having a QA Department.

2 Comments

Long live Slack, down with egotistical email

17/11/2014

We use Slack for team communication at Cozy. I struggled with the transition. When I reflected on my struggles, it made me better understand what a destructive format email is for workplace communication.

A quick disclaimer. This is only about work communication and not personal communication. I love email. I think email will be around for a long time and I will lament if and when it goes away. I just don’t think we should be using email for work.

Oration is the highest form of feeding an ego. You craft your message carefully. You research, write, and rehearse. Finally, you take the stage. You command everyone’s attention. And once you’re done, an important topic has been thoroughly addressed and everyone can go on with their lives, better off after hearing what you said.

Email is oratory without the speaking* (or skill). My problems with email stem from when it is used for one-way communication. I suspect that most emails I’ve ever received from anyone in management have been one-way. Generally these emails are meant to, first and foremost, communicate the sender/manager’s self-importance. Often the email contains a nugget of actual information which should be hosted elsewhere. Sometimes the email is an announcement no one understands. And as a rule, you can’t rely on people reading the email you send anyway.

When you craft a long email, like an orator crafts a speech, it is an ego boost. Each one is a masterpiece. You are proud of your fine writing. When you craft a long chat message, on the other hand, you look like a dramatic asshole. It puts in stark perspective how awful the written format is for important or high-bandwidth communication. I’ve never seen someone post a 300-word message to chat. How many 300-word emails do you have in your inbox?

Removing email also levels the playing field for communication. You don’t need to be a manager or orator. Everything you write has a visibility you can’t change. You choose your audience based on topic. Is there a question about a product’s design? Well, it goes into the product or design channel, whether you are Executive Emperor or QA Associate II. Also, no one really wants to read your dramatic flair so please keep it short and to the point.

I used to get frustrated when I’d write an excellent email, send it out, and within a few minutes someone would reply with a message like “Yeah, just to build on what Rob said, it’d be a good idea to do X.” You idiot! You are an Ice Cream Truck driving through the State of the Union. But of course, the problem was mine, playing a manipulative game, focusing too much on this amazing message I’d created. Sometimes these emails would be about the manipulative games people were playing and how we weren’t focused on the employees and customers and things that were actually important.

Email in the workplace is a systematic problem. We take it for granted. We use it constantly. We don’t question it. But email has a cost. It feeds into the already inflated ego of managers. It encourages one-way communication. It is wonderful for grandstanding. We spend a lot of time crafting museum-quality correspondence no one wants to read. And in the end, there are better ways to accomplish what we use it for.


* One of the greatest “speeches” of all time, Pro Milone by Cicero, was written, not spoken. We know great orators by their writing, not their speaking.

No Comments

If you hear “perception is reality” you’re probably being screwed

27/10/2014

I was once told in a performance review that “perception is reality.” I was infuriated, and the words stuck in my mind as the most toxic thing a manager could say to an employee. I have avoided writing about it, but the “This American Life” episode about Carmen Segarra’s recordings at the Fed has inspired me to change my mind. Here’s the relevant section, emphasis mine:

Jake Bernstein: Carmen says this wasn’t an isolated incident. In December– not even two months into her job– a business line specialist came to Carmen and told her that her minutes from a key meeting with Goldman executives were wrong, that people didn’t say some of the things Carmen noted in the minutes. The business line specialists wanted her to change them. Carmen didn’t.

That same day, Carmen was called into the office of a guy named Mike Silva. Silva had worked at the Fed for almost 20 years. He was now the senior Fed official stationed inside Goldman. What Mike Silva said to Carmen made her very uncomfortable. She scribbled notes as he talked to her.

Carmen Segarra: I mean, even looking at my own meeting minutes, I see that the handwriting is like nervous handwriting. It’s like you can tell. He started off by talking about he wanted to give me some mentoring feedback. And then he started talking about the importance of credibility. And he said, you know, credibility at the Fed is about subtleties and about perceptions as opposed to reality.

Well shit, if that doesn’t sound familiar. Here I was, doing work that was by all measures extremely successful, yet pulled into a feedback meeting to be told “perception is reality.”

Let me tell you what “perception is reality” means, and why you should plan on leaving your job the moment you hear it:

The arbitrary opinions of your manager’s manager defines your situation. And they don’t like what you’re doing.

Your manager may be well-meaning (mine was, as was Mike Silva), but at the point you get this “perception is reality” bullshit, you can be sure there’s nothing that they are going to do to help you. Someone above them has taken notice, your manager has probably heard hours of complaints, and you can either shut up or get out. Perception isn’t reality everywhere; it is only the mantra in sick organizations totally removed from reality.

1 Comment

Technical debt takes many forms

23/10/2014

Most people are familiar with “technical debt” in terms of code or architectural problems that slow down development. There are other forms of technical debt, though, that can be overlooked.

Dead Code: There are endless “dead code as debt” scenarios. You have a “live” function that is only used from dead code, hiding the fact that this function is also dead (this situation is cancerous). Every time you grep, you have to wade through code that is dead. Every time someone stumbles across the dead code, they need to figure out if it’s dead or alive. There’s no reason for any of this (especially not “keep it around as reference”). Dead code is a debt, but it’s also easy to pay back. Remove your dead code.

Unused Repos or Branches: Every time a new person starts, they will ponder what code is dead and what is alive. This pondering includes code, issues, and documentation. It is sloppy and unnecessary. Put unused repositories in cold storage. Delete stale branches.

Large Backlog: The larger the backlog, the worse the experience of using it. It’s harder to find, reclassify, and prioritize. Some developers will not even bother. A backlog is not a place for everyone to list anything they think should ever be done. Close stale and low-priority tickets. Close “symptom” tickets that you know won’t be addressed until a system is rewritten. Close everything except 3 months of work (and manage further out work on your roadmap, which should not be in your backlog).

Dirty Wikis/Documentation: Why out of date documentation is harmful should be pretty self-explanatory. Don’t let it get that way (or just delete the documentation). Make documentation someone’s responsibility, or make it part of the “definition of done.”

Every organization has these things. By recognizing them as debt, and thus detrimental to development, it can perhaps simplify any argument about what to do.

3 Comments

High performance, poor morale, and the Niko-niko calendar

2/10/2014

I was introduced to Niko-niko calendars by Max Webster at Niko Niko. Basically, they are a way of tracking a team’s mood over time. At the end of the day, team members put in a smile/frown/whatever face indicating their mood. You can see when people were happy or sad and coordinate that with other events (what tasks they were working on, what happened at work, etc.).

Initially, I thought this was a pretty useless metric. What good leader or manager wouldn’t always know this information? I can tell if things are going well because I speak to the team regularly as I make changes. But it can be useful to track mood for when things get lost in the cracks or regress. It’s also useful as an outside-facing metric, to show people how their decisions impact the team. The more I thought about it, the more I wished I had known about Niko-niko calendars earlier!

I would only consider Niko-niko effective on an already well-performing and generally happy team. It is a pretty high-level metric, so if people are unhappy for many reasons, I doubt you’ll get much useful data. So, with that, how about some scenarios that I would have used a Niko-niko calendar for, had I known about them?

  • Process tweaks like shortening sprints or requiring more code reviews. People are resistant at first but usually accept it. Is this because they get happier over time? Or because they do not feel empowered to change things back?
  • Changing the branching/integration strategy. At previous jobs we seemed to have a new one every six months. At my current job there are fans and detractors of git flow. Does morale go down or stay the same when integrations happen more often? Is this better or worse depending on the branching/integration strategy?
  • How much do people actually hate planning days, and what can we do to improve them?
  • How painful are releases? People should be happiest, not unhappy, before and after a release!
  • Does a team hate what it’s doing? How much does dumping work on a team impact morale? Do they not believe in the product or are expectations out of whack? What can be done to help the team “own” the project rather than resent it?
  • How does changing team composition cause morale to be affected?

I’m sure there are more, but I thought the idea of using a Niko-niko chart could be interesting. I won’t have a chance to try one out for a while, but will post a followup after I do.


I wrote this draft a couple months ago and finished it recently. Since then I’ve seen a few other apps in a similar space, such as Know Your Company and Know My Team, that focus on tracking morale. I think it’s a good trend. And it’s a reminder that what may appear as a management fad can often have deep, established roots.

No Comments

Keeping talented employees

18/09/2014

I saw a tweet the other day about the eight things that keep talented employees:

I’m normally not a fan of reducing human behavior to a list like this, but it seems pretty complete, and the words resonated.

As a technical leader I am a fan of metrics and dashboards: tests passing, code coverage, static analysis and metrics, velocity, bugs, takt time, and other indicators that you wouldn’t focus on individually, but are very useful collectively.

I wonder if, as a manager, assuming trust is in place, is it worthwhile to go over these things explicitly? To make a “private dashboard” to cover in 1-on-1s, and see where the problems are?

  • If everyone is not feeling challenged, why is that? Is it because the work is boring? If so, why? Is it temporary grunt work that can be augmented with some side projects? Or is the product becoming less exciting to work on?
  • Who doesn’t feel like they’re on a mission? Is it because they are disillusioned, or is the mission bullshit. Are more people disillusioned each month?
  • Which individuals are trending up and down? Is the organization as a whole trending up or down? Which attributes are trending up and down? For all these questions, you must answer “why“!

I’m not sure this is something I will start using immediately, since I am just getting to know my team and I don’t want overly formal process to get in the way of a human connection. But it’s certainly something I would have done at CCP. It’s very convenient for bad managers to rationalize poor ratings, but perhaps some tracking on these eight points can be a start towards providing quantitative evidence of employee satisfaction.

1 Comment

Japanese vs. Western models of decision making

11/09/2014

I was reading a book about The Toyota Way last year (sorry, can’t remember which) and something that stuck with me was a section on Japanese versus Western decision making*. The diagram was something like this:

japanese-vs-western-decisionmaking

The crux of it is, Japanese companies like Toyota spend more time preparing for a decision, and less time executing. Western companies reach a decision earlier, and then execution has all sorts of problems. It’s also important to note that Japanese companies often reach the “end goal” sooner.

Preparation involves building consensus, but that doesn’t mean it’s all talk. Japanese companies pioneered set based design and prototyping, which allows them to try out a huge number of ideas cheaply. By the time a decision is made, they’ve “thrown out” about 90% of the work they’ve done!** However, once the decision is made the execution goes smoothly.

It is easy to see how Japanese decision making maps to businesses with a clear distinction between preparation/pre-production and execution/production, such as traditional manufacturing. It can be difficult to map to pure product development. Keep a few things in mind.

  • Consensus isn’t just discussion and design. Big-Design-Up-Front is not preparing for execution. BDUF is a woefully incomplete form of execution. Building consensus means actually implementing things in order to rapidly learn.

  • Consensus isn’t a democracy. Toyota has a very hierarchical structure and people have very clear responsibilities. The goal of consensus-based decisions is to make better decisions, not to achieve some Platonic ideal. Difficult decisions are still made, but the role of the executive is to manage the consensus-building process, rather than “just hurry up and making a decision.”

The Japanese model is built in to cross-functional teams. Consensus isn’t achieved by the heads of Engineering and QA signing some agreement in blood. If that agreement ends up not being a good idea- and it almost never is!- you end up with the Western execution experience. On the other hand, cross-functional teams have much more interactivity and iteration going on, and overall execution is much faster.

People will get upset. Take responsibility for your decisions, and acknowledge some people will get upset by them. However by making sure their concerns are thoroughly heard and discussed before execution, you will make sure they don’t keep pulling things off-track.

Anyway, there’s lots of good writing on this topic, and I highly suggest checking some of it out if it interests you. This is just my software development-centric take.


* I’m just calling these the Western and Japanese models of decision making. They are clearly not the way all decisions are reached in the respective countries. In fact these generalizations may not even be true anymore. Whether Japanese or American companies behave this way is irrelevant. The names are just proxies for different types of decision making.

** Obviously the work isn’t thrown out, since they’ve learned so much from it. But if the effort were raw materials, I suspect 90% of it would end up in the trash, depending on how a set is developed and culled.

5 Comments

Can you quantify trust?

4/09/2014

In a previous article, commenter Robert Kist asked:

How are you going to judge if people trust you – what would your indicators be, if you decide to treat it as a metric?

This is tricky. I don’t think there’s a good answer. Bad managers, who are by definition less trusted, can easily rationalize away any attempt at quantification. One quantifiable measure would be employee turnover. However turnover tends to be ignored in the aggregate, since the sample size is necessarily small. Individual departures are blamed on “incompatibility” or “burnout,” when it is without exception due to mismanagement.

Another potentially useful metric is the employee survey. This is an unequivocal disaster, because there are just endless ways to explain away poor ratings. I’ve heard bad ratings blamed on bad weather!

What about the venerable “360 review”, where your direct reports and peers give feedback? This would require some sort of survey, and we know how that goes.

In the end, bad managers will be able to rationalize away poor trust metrics. Unfortunately they are also universally unable to qualitatively identify a lack of trust. Good managers, on the other hand, intuitively know whether trust is getting better or worse. They should make sure there are many avenues of feedback to inform this intuition, but I’m not sure any are worth quantifying, if they are quantifiable in the first place.

Someone please tell me when I start to become a bad manager, please.

No Comments

Hire talented people and get out of their way?

28/08/2014

Whenever I need inspiration for a blog post, I check my LinkedIn feed. I am bound to find a stupid inspirational quote. Today’s is:

In most cases being a good boss means hiring talented people and then getting out of their way.

This advice (hire smart, don’t micromanage) is so simplistic, it’s hardly worth saying. The profound stupidity is equating this with “being a good boss“.

No, hiring smart people and not micromanaging them is the absolute, bare minimum you should be doing as a boss. Basically, if you call it a day there, you are a worthless, paper pushing, pointed headed body in a seat. If not today, then soon.

What are you doing once you get out of the way? Meetings? And how can you be sure you’re hiring good people, if you’re not closely engaged with the work? Should you offload that to your team? And then what is left to do as a “good boss“, by your definition?

In reality, where being a good boss is incredibly difficult and rare, being a good boss means:

  • Earning trust, and learning to trust others.
  • Improving how decisions are made.
  • Making sure people are learning, challenged, and growing.
  • Mediating business pressures with craftsmanship.
  • Creating a greater context for the work of employees.
  • Fighting fires and doing drudgery without becoming a bottleneck.
  • A thousand other things that don’t make good motivational posters.

You work on these things every day. It’s slow and painful. There’s no secret algorithm or technique. You could take all of these cute little quotes about how to be a good boss, and it’d cover maybe 1% of what actually goes into being a good boss.

5 Comments