Solomon was wrong

You get this often when managing people. Somebody, often outside of your chain of command, comes to complain about your subordinate. “He’s stubborn.” “She’s doing this wrong.” “He exceeded his competencies.” and anything else you can think of. What do you do?

There are two natural reactions to this situation:

  1. you go to talk to your subordinate, get her version, decide who’s opinion is correct and persuade the other side to comply.
  2. (with time) you get both interested parties in a meeting, have them discuss the situation and either mediate to find a solution or come up with a Solomon-like compromise that should fit everyone.

Which one is right? Probably neither. The right thing to do is nothing.

When you do react in any of the above ways, you give others permission to shortcut resolving conflicts, by relying on command & control structures to force compliance. Consequently the people you manage will always feel as if you’re not on their side, but are instead giving in to external pressures and opinions. You lose their trust.

What you should do instead is to explain to the complaining party that your subordinate has good reasons to react the way he or she does, and both of you are working their best for the organization. Whoever is coming with complaints should continue to work directly with the other person in question until they reach understanding and a solution.

There are obviously cases of valid complaints, where your subordinate is guilty of misconduct. But 99% of the time you’re working with competent, committed people, who get into conflicts because both sides are devoted to doing a good job. They might simply have different ways of getting there, different definitions of what a “good job” means, or might be placed in an organizational system that naturally sets them against each other.

Once in place, your behavior creates a system and culture where everybody is responsible for keeping good relationships with others whom they cooperate with. It’s the equivalent of what Collin Powell named “mommy’s not here, son, broadly present in the military.

I remember once watching a documentary on Navy Seals training. Whenever a team of them got into conflict they were ordered to walk rounds in the sand, carrying a long, heavy wooden log with a huge inscription “MOTIVATOR”, to understand that they must work together. None of them could carry the log alone.

There are no logs to carry in white collar companies, but there are just as many conflicts. And people need to learn to handle them as grown-ups. It’s a powerful lesson I learned from Tribal Leadership and still often fail to implement in my daily work.

Developers are from Mars, QA are from Venus

Designed, developed, handed over to QA for testing. Then all hell breaks loose. “How do I test it?” “Where’s the documentation?” “This is broken; not it’s not, it’s not our component.” “I’m not signing this off!” Or my personal favorite: “I’ve other priorities to test now. I’ll get to your stuff tomorrow.” for three days in a row. Keeping QA separate from development teams is a recipe for trouble, friction and lots of missed opportunities. It has to stop.

Once you put a QA Engineer in the same team with developers, sharing the same manager, several things happen:

  • QA shares the same goal with developers – to deliver an excellent product on schedule & budget. No more bouncing tickets back and forth “this isn’t working!“, “it’s not a bug, it’s a feature!” “this isn’t a blocker!” Shared goal, shared ownership, shared responsibility.
  • QA knows product first-hand by spending time with developers as they work, talking over each feature and scenario. Ever tried asking a developer to write a test script for QA? Good luck with that. Sit the QA next to a developer and they can write the scripts perfectly themselves.
  • Testing gets done early and often because QA doesn’t have any other priorities or anyone else shouting louder at them to get their work done faster. User story finished? Alright, let’s see how it works. Right now. And iron out all the bugs right there, on the spot.
  • Testing gets automated when QA sets up Selenium (or any other) scripts together with developers, that they can later re-run as frequently as needed to check whether they’ve not broken something.
  • Developers spend more time coding because they don’t need to setup their own testing data and other environment pieces. QA can do it in parallel and whenever needed.

Sounds obvious if you’re an Agile zealot, right? Notice how I never used the “A” word? I didn’t have to, because the above ideas have nothing to do with the movement. Even Microsoft knew the value [PDF] of pairing developers and testers way before Agile was even manifested.

Testing is not separate from developing. It never has been, but today, when software requirements and markets change all the time, and so does source code, it’s more expensive than ever to keep a QA team separated from development. For the sake of your company’s success, stop doing that now.

Evolving towards Kanban

Kanban is the last stage of software delivery evolution. Right now, at least, as evolution never really stops. The path is usually the same, starting with a disorderly “let’s just code”, moving gradually towards a waterfall system, then painfully stumbling towards a formal Agile framework, say Scrum, and once a Scrum team truly matures, they realize they’re really doing Kanban with a bit of unnecessary paperwork.

The jump from chaos to waterfall is rather obvious. So is usually the next step to go Scrum (or any other framework you like). We love all the Agile principles, user stories help focus on business outcomes, expecting changes makes Product Owners happy and programmers less stressed. Estimates made in story points help the management see when things will be done and ready, and make decisions based on that.

In Scrum for a new project you define a whole bag of user stories, estimate them, order by business value and call it a “Release”. That Release gets split into Iterations, each of 1 or 2 weeks in length. When you’re done with all the Iterations, you’re done with the Release and ready to unleash your product onto the general audience.

We’re often working, however, with software that’s relatively inexpensive to release. Like web applications, where you upload code to a server and all your users instantly get the latest version. There’s obviously the question of stability, quality and testing, but Scrum says strictly that the definition of “done” is “designed, developed and tested.” So, by that definition, you should have a release-quality product after every Iteration.

Add the two things together and you soon have a Product Owner asking you whether it’s possible to do an interim-release, before the whole scope is done. Sure, it is. It takes a while to work out discipline and processes right, so that the quality really is good, but once you’re there, you can release right after the Iteration summary meeting. And the Product Owner has a point: why do we wait another X weeks for the whole Release to be ready, when we can have something live now? Competition never sleeps and some of these things could make users seriously happy.

Here’s where Kanban comes in: once you’re ready to release after every Iteration, then the answer to “when will this be ready?” becomes “right after the Iteration you put it in.” Long-term estimations become irrelevant, as they always were anyway. Just because you have a user story planned for 3 Iterations from now doesn’t mean it’ll really be done there and then. Things shift all the time.

Why bother with the “Release” planning then anyway? Switch to a higher-level roadmap of changes, so that the team continues to follow a vision for the product, but plan actual work only for the next Iteration. Then release it immediately. Now you’re doing Kanban.

An army of sheep led by a lion

I’ve yet to see a company that, having sound leadership, failed. I’ve also never seen one to succeed with bad leaders. And the surprise is that being a “good” or “bad” leader has nothing to do with how you treat people around you. You can be a tyrant (Steve Jobs), a bully (Bill Gates), a corsair (Larry Ellisson) or a friendly, passionate geek (Larry Page, Sergey Brin) and succeed nonetheless. But if you lead in the wrong direction, then boy, you’ll hit an iceberg sooner than you can spell “Titanic”.

This isn’t to say that you should immediately burn your copy of How to Win Friends and Influence People and start screaming around at your team like a drill instructor. But it does mean that if you’re not naturally a social, likeable person, trying to change yourself is probably a misallocated effort. You may rather want to spend time getting to know your market and learning as much as you can about your domain. Put a lot of work into becoming the best expert in your field.

Being a great leader may motivate people to row faster, but it won’t help anyone if you’re all heading for a cliff.

A person is not a ‘resource’

Human resources they call them. The drones that keep typing on their keyboards producing lines of text that make monitors light up in different colors, depending on what other drones type. They’re characterized by output, productivity, typing speed, number of bugs introduced to code, days taken off for holidays or sick leave, availability as percentage of time. Those pesky employees.

People are not machines. A machine is something built in a cumulative output of human knowledge. An expression of human potential. For any machine there is a constructor, who

  • knows how it was built,

  • understands how it works,

  • can construct it anew.

Can someone construct a person? Does anyone understand how each and every part of the human body works?

We are creative, surprising, non-deterministic, self-repairing and irreplaceable. If we were easy to replace, why would we have cemeteries?

Do you really think you can move your employees around, from desk to desk, from office to office, from city to city, from project to project, from task to task, without taking their opinion into account and without any loss of their creativity, productivity, devotion and thus quality of results they deliver to the company?