Tag Archives: management

Your dogma is already obsolete
1

Your dogma is already obsolete

| By | One comment

Last week’s New York Times included a book review of defense reporter Fred Kaplan’s book “The Insurgents,” which covers General David Petraeus, counterinsurgency doctrine, and the wars in Iraq and Afghanistan. It explains well how falling in love with your ideas can get in the way of success.

Kaplan writes about how proponents of counterinsurgency doctrine in the military worked the media, defense scholars, and the defense establishment to replace the existing Cold War doctrine with their own ideas. Here’s how the reviewer, Thanassis Cambanis, describes their better days:

President Bush had promoted the COINdinistas because they were flexible, pragmatic problem solvers and because he had a nagging problem on his hands: how to get out of Iraq without looking defeated. Counterinsurgency was just one part of the fortuitous mix that yielded a just-good-enough resolution for Iraq. Petraeus and the officers and experts had been right about how to fight in Iraq and reached plum positions in the Pentagon.

And here’s the conclusion:

The COIN brigade forced the Army to adapt, to become what one officer called “a learning organization,” but the Pentagon failed to grasp the most important lesson of the decade: that the military does best when it can learn new types of missions quickly, whether delivering aid after a tsunami, stabilizing a failed state or running covert missions against international terrorist rings. Instead, it exchanged an old dogma for a new one. Once persuaded that the military could do counterinsurgency, few in Washington stopped to think about when it should do it.

This story reminded me a lot of the tech industry. Last year, GitHub’s Ryan Tomayko wrote a “here’s what works for me” blog post about his management style, which was fantastic. Here’s the crux of it:

It’s often cited that GitHub doesn’t have managers. In my opinion, a better way to describe the phenomenon would be to say that everyone at GitHub is a manager. Instead of assigning 100% management duties to individuals, the basic role of management is spread between 1.) every single employee, and 2.) a set of custom in-house tools that serve to keep everyone in the know with regards to other projects.

I think this is a pretty brilliant philosophy, and my impression is that it works very well for them. That article changed the way I think about my work as a manager.

This weekend I listened to a presentation from a developer at GitHub about their “no managers” corporate structure. This presentation essentially argued that the GitHub approach is indisputably the best way to run a company, and that all other corporate structures are broken.

This is exactly the trap that the military officers Fred Kaplan wrote about fell into. It’s a form of lazy thinking. Every problem and situation is unique. Nearly all people are naturally inclined to cling to heuristics rather than thinking deeply about problems and adapting to solve them.

This is one of the great penalties of success. People try something, meet with success, and then attempt to apply that formula over and over again, failing to recognize that new problems require new solutions. Often the real reasons for success go completely unexamined, because people are so eager to embrace it as proof of their own brilliance.

To the proponents of counterinsurgency doctrine, every war looks like an opportunity to apply counterinsurgency doctrine. To the GitHubber, every corporation should work like GitHub.

When people propose that all problems look the same, or even worse, that problems look different but that old solutions are still ideal, it’s a strong sign that they’re operating from within their dogma rather than starting with the problem and working their way out. There’s nothing that invites disaster more than falling in love with your own good ideas.

What does it mean to be a senior engineer?
0

What does it mean to be a senior engineer?

| By | No comments yet

You should read John Alspaw’s essay, On Being A Senior Engineer, even if you don’t aspire to be a senior engineer. Maybe you already think of yourself as a senior engineer. Maybe you work in some completely unrelated field. What it’s really about is becoming a mature professional and not only mastering the skills of your field but passing them on to other colleagues in useful ways as well.

I recently read a post about the value provided by managers. I was not surprised to read that managers do add value, but I was a bit surprised at the means by which that value is added. I would have assumed that it was by keeping people happier, removing distractions that sap productivity, or helping to prioritize work. As it turns out, the actual value is in teaching people how to do their jobs better.

So as a manager, the best way to add value is to help people along their path to becoming senior engineers (if the people who report to you are engineers). As an engineer, you should be looking for opportunities to work for a manager who can teach you to be a better engineer. And perhaps most importantly, you don’t have to be a manager to help other people get better at their jobs, so you should helping other people get better as a key aspect of you’re job. This is one of the key points of John’s essay.

Anyway, you should be reading his post and not mine. It’s a road map to making the most of the incredible opportunity we have to work as engineers.

Why are firms command economies?
0

Why are firms command economies?

| By | No comments yet

Interestingly, however, there is one last bastion of economic activity that proved remarkably resistant to the triumph of the market: firms, companies and, later, corporations. Think about it: market-societies, or capitalism, are synonymous with firms, companies, corporations. And yet, quite paradoxically, firms can be thought of as market-free zones. Within their realm, firms (like societies) allocate scarce resources (between different productive activities and processes). Nevertheless they do so by means of some non-price, more often than not hierarchical, mechanism!

An observation by Yanis Varoufakis that has often struck me as well.

What’s the difference between a manager and a team leader?
3

What’s the difference between a manager and a team leader?

| By | 3 comments

Today I was sort of idly thinking about the difference between a manager and a team leader. I suppose these terms mean different things in different organizations, but I think it makes sense to propose general definitions that clarify a somewhat hazy topic. We’ll assume that in both cases, the members of the team report to the manager or team leader, at least for the duration of the project that they’re working on. (If you work at a place where people have a manager and a team leader and the responsibilities are divided, all bets are off.)

Both are accountable for the overall performance of the team. If the team fails to meet its goals or is dysfunctional, that’s on the person who’s running the team, regardless of their title. I strongly prefer to think about these responsibilities in terms of accountability rather than authority for the reasons I talked about in my post about judgement and influence. I think that teams function most effectively when the members buy into the team goals individually because they see the value in them, rather than because somebody told them to do something.

So the difference is that a team leader should be thought of as the senior practitioner on the team whereas for a manager that may not be the case. If you’re the team leader of a team of developers, you should probably be the best developer on the team, and the other members of the team should respect your technical capabilities. If you’re the manager of a team of programmers, that’s not necessarily the case. A manager may be a fine programmer, but their core responsibility is management and coordination, not necessarily bringing an authoritative voice when it comes to making technical decisions.

The difference matters in terms of setting the expectations of the members of the team. It’s a dangerous thing when the members of a team think of the person running the team as a manager but they think of themselves as a team leader. Or if the team members have a manager they expect to be a team leader but who isn’t equipped to function in that role.

I’d be curious to know what other people think about these definitions. I haven’t heard of the two titles being defined this way before, but they match with my expectations based on my experience. I think that as an industry, it might pay off to formalize them.

Applying judgement and influence
3

Applying judgement and influence

| By | 3 comments

I’m just going to keep posting stuff about Valve until I get tired of it.

Did you read the Valve employee handbook? If not, you should. To catch you up, at Valve, the corporate structure is completely flat. They have no managers, and everyone decides what to work on for themselves. The handbook explains what is expected of Valve employees and how people should adapt to that corporate structure.I’m sure some people find it intriguing and others terrifying.

Succeeding at Valve depends on two things, the application of one’s judgement and influence. Employees use their judgement to decide where they can add the most value for Valve. They use their influence to recruit other people to help them build the things that they have decided are valuable. Find a problem to work on, convince other people to help you solve it. Nobody is empowered to order anybody to do anything.

What occurred to me after reading the Valve handbook is that you or I can work in the Valve style regardless of where we work. If you work anywhere but Valve, you probably have a manager and you may have people who you manage as well. Within the constraints of your job, though, you should be relying on judgement and influence rather than hierarchy in your work, just like a Valve employee does.

If, in your judgement, there’s something more valuable you could be working on, you should be convincing people (like your boss) that your time could be better spent working on that other thing. Just be sure that you’re open-minded enough to accept that your judgement could be mistaken. If you’re right, though, it ought to be easy to convince people that your time could be better spent on a more valuable project.

At the same time, rely on influence rather than authority to get the help you need to get your work done. People generally do better work if they believe in the project they’re working on, and the ability to recruit volunteers is a good sign that whatever you’re working on is worth doing. People sometimes mistake interesting for valuable, but it’s always better to work with enthusiastic volunteers than with people who are doing something just because someone told them to do it.

Obviously if you work on an oil rig or at Burger King, this approach may not work. However, the field I understand best is software development, and if you’re working on software, you should the Valve philosophy to heart. Use your judgement and influence to make sure you’re adding as much value as possible at your job. If that gets you into trouble, maybe it’s time to use your judgement and influence to land a job more suited to your talents.

The benefits of transparency in engineering
2

The benefits of transparency in engineering

| By | 2 comments

For a long time, I was shocked by blogs like Etsy’s engineering blog, Code as Craft. I had a sort of old-school “information is power” mentality that led me to believe that letting competitors know about your technology stack would put a company at a disadvantage. Building scalable systems is hard, and I thought it was foolish to give away your secrets. I also prided myself on being able to sleuth the details of a company’s technology stack using URLs, HTTP headers, and page source.

I have long since come around to the opposite point of view, but general attitudes about this stuff hasn’t changed much once you get past the most progressive organizations. Stephen O’Grady explains to the recalcitrant why hiding your technology stack is a bad idea.

The other day I said on Twitter that all problems are user experience problems, except for scaling. And the solutions to those problems are generally so complex and so specific to a company’s product, staff, customers, and existing code base that slavishly copying one’s competitors at meaningful levels isn’t really possible. At most, what you usually get is an idea of what to try next, or issues you may run into down the road.

The advantages of sharing are real, and the disadvantages are an illusion. Go forth and start an engineering blog.

Don’t order your team to work more hours
6

Don’t order your team to work more hours

| By | 6 comments

Today I was talking to a friend about his job. He said his company had just had a meeting where the management told his team that they were not satisfied with the overall sense of urgency and that the team needs to be getting things done more quickly. Reading between the lines, it was clear that what the manager meant was that the team needed to be putting in more hours.

Working more than forty hours a week is hardly outside the norm in software development, but directly demanding more hours from people is a bad idea for a number of reasons. I won’t get into basic issues of justice and decency and instead focus only on effectiveness. Even if your only goal is to get things done as quickly as possible, demanding that your team work more as a group is still a bad idea.

The first issue is morale. Members of the team will not readily accept “work more hours” as a possible solution to any problem if other solutions that don’t require them to work more hours are apparent. If there are process changes that would make the team more productive, they’ll wonder why those aren’t being made instead. If there are underperforming members of the team, others will wonder why those team members aren’t being specifically urged to do a better job or being replaced.

And, of course, some team members will start asking themselves why they’re working at a place where the management tries to solve problems using the blunt instrument of “work more hours.” In the end, you wind up with an unhappy team that starts losing its strongest contributors to other jobs. If you do plan to go this route, understand that the team will hold you accountable for every second of their time you appear to waste, so you’d better have your ducks in a row.

The second issue is quality. This is an issue I touched on when I talked about the problem with all-nighters. When someone is working and they know they could be doing something else, whether it’s having dinner with the family, going to their kid’s soccer practice, or sleeping on the couch, chances are their focus is going to be on doing whatever it takes to finish as quickly as possible. Corners will be cut. The longer the team is working extra hours, the more technical debt you build up, which in turn makes it harder for developers to get things done, requiring even more work to maintain the same level of production. It’s a losing proposition.

The third reason not to fall back on “make them work more hours” as a strategy for increasing productivity is that it reduces the organization’s capacity to manage a crisis. For one thing, there are fewer hours to throw at unexpected problems. If your lead developer is already working on Sundays, those Sundays aren’t available when you get a surprising feature request from a big customer. If the team is already burnt out from previous death marches, they’re going to be pretty cynical when their confronted with an actual crisis. And finally, when the crisis arises, that crappy code people were writing at night when they were trying to watch Glee at the same time is going to be an impediment to solving whatever problem is at hand.

The funny thing is that on a good team, you never need to ask people to work more hours at all. If you have good people and they understand and have bought into the team’s goals, then they will do what needs to be done to ship, even when it means putting in extra hours. One way to make sure that never happens is to coerce them into working more hours.

Every time you’re tempted to do so, sit down with members of the team and ask them how many hours a week they spend dealing with stuff not related to shipping and work to make those things go away instead.