Tag Archives: management

Blog

The Art of Leadership

Before you ask, yes, it is weird that I’m reading a bunch of “management” books.

You can watch Michael Lopp’s career by following his various books. Start with “Being Geek,” the software developer’s career handbook. The move into management resulted in “Managing Humans.” And his promotion from manager to director and executive gets you “The Art of Leadership,” which is the book I recently finished.

My career has not followed the same trajectory. I continue to be an “individual contributor,” so why would I read this book?

Two basic reasons. First, Lopp is a great writer. He wraps the lessons around relatable stories, even if they don’t exactly mirror my experience. Secondly, to use a cliché, leadership comes from everywhere. I may not manage people, but I do have to lead. As a consultant, my whole job involves influence, persuasion and strategy.

In short, I don’t think you have to be a manager to get something out of this book, but if you like to sit in the corner and code all day, it’s unlikely to be your thing.

The book is structured into three sections, manager, director and then executive. Within each section, there are a bunch of small things that, done well, will result in great results (hence the sub-title). There are so many great parts that it would be easy to quote the whole book. I’ll refrain, but here are a few highlights and observations.

There are parallels with other books I’ve read recently. Chapter 15 “Saying the hard thing,” covers a lot of the same ground as “Radical Candor,” with many of the same positives.

The “faux zone” is very relatable. There are certainly times when I feel incredibly busy, but at the end of the day, I don’t feel like I got anything done. There are insights here that make me feel better about it.

A “Precious Hour” reminds us that being busy is not the same as being productive.

And, finally, this is so me: “I love to start new things, but I often lose interest when I can mentally see how the thing is going to finish, which might be weeks or months before the thing is actually done. Sorry. I’m getting better at this.” I remember I did one of those “type indicator” tests a long time ago, and one of the categories was “completer-finisher.” I immediately knew that I was the opposite of that.

As with all books like this, some of the suggestions I already do while others are not relevant; however, taken as a whole, there’s plenty of good advice.

Opinion

Ops is undervalued

I made the mistake of suggesting that there was a blog to be made from this tweet. This is that post.

People still underestimate the value in (Developer|Operator) Experience when building platforms and honestly it’s kinda shocking to me.

If you want to win mindshare you need to make your tools actually usable. If you don’t want to lose it you need the same.

First: I agree with the sentiment. Maybe not to the same extent as Danielle, but I fight the same battles in my day job. I wanted to say this now because, on reading the rest, you may think the opposite. What follows is an explanation of why this is a common situation. I don’t mean it as a justification.

In summary, making software work for ops teams is not a focus either for software companies or internal development teams because of at least three reasons:

  • It’s not a business driver
  • Ops are not the buyer
  • Engineering is run by developers

Naturally there are exceptions to these rules. Every company is different. These are observations, not rules.

Working at the “coal face” it’s easy to forget, but people don’t buy software. They buy a solution to a business problem1. These days, that solution is often software but you don’t buy a new product because it’s cool2.

A driver might be to get a report generated more quickly, or to provide a new service to paying customers, or to reduce the costs of some infrastructure3.

But, you argue, the ops team are the people who keep the system up and running. How can this new system generate reports or deliver a service if it’s not running reliably or has not been provisioned correctly?

You’d be right. Sadly, organisations are often not structured to recognise that fact. The IT teams tasked with making everything run smoothly are frequently in a completely different reporting hierarchy from “the business.” I put “the business” in quotes as I hear it described that way all the time, but it’s this us-versus-them philosophy that brings many issues, including how ops get sidelined4.

With “the business” and “ops” being in separate reporting structures, one or the other has to sign off on the purchase of new software (unless it goes way up the organisation) and that’s always going to be “the business.”

The buyers normally consult the ops team, but ultimately they’re going to put their own needs first. Objections that the ops team have will end up in the business case, but likely in an appendix that no one will ever read.

This makes no sense because, as we all know, most of the expense of a system occurs after go-live. But monitoring, management and deployment are not things at the top of mind of developers and business users.

But even in the IT organisation, the ops team frequently don’t get the attention they deserve either. Anecdotally, this is because IT leadership come from the development team. Their outlook on IT is therefore skewed towards making things rather than keeping them running. I see the same challenges for testing teams. Or, indeed, the lack of testing teams.

This lack of buy-in from the ops team is endemic. I see it in companies buying and using software. I see it in companies that make and sell software5.

At this point, what I would like to be able to do is say, “And the solution to this terrible problem is…” Sadly there is no easy answer. Saying “You should listen to your ops team” is both obvious and unhelpful. Making tools useful for the ops team to get mindshare is a good way to get your software on a shortlist but maybe not enough to clinch that sale.

  1. I’m talking here about software used in a business of course, but the difference between this and personal use isn’t as great as you might initially imagine. You buy a game to solve the “problem” of boredom. Very few people buy software because it’s software. ↩︎
  2. You might buy it because this, specific solution is cooler than the other options. ↩︎
  3. That is, even in the case where it’s the infrastructure that is being improved, the business case is not “make the ops team more efficient” but “make the cost of operations lower.” ↩︎
  4. There’s another blog in how toxic “the business” as a concept is. This isn’t that blog. ↩︎
  5. This is a chicken and egg problem. Do software companies fall into this trap because they’re run by developers? Or is it because they’re selling to companies who have already fallen into the trap? ↩︎
Opinion

Your most important customers

Seth Godin has had a couple of posts recently about how to treat your best customers. One of the thing that he observes is that the way you define “best” is not necessarily the most obvious. Is a customer that pays full price always better than one that recommends your service to five of their friends?

In defining the best customers, my mind wandered to the opposite extreme, the worst customers. This reminds me of something that happened a few years ago. It’s only fair to note that I heard this “through the grape-vine.” It could be completely true or mostly made up, but where-ever it falls I think it’s an interesting anecdote.

As a reaction to, potentially, being taken for granted, customers often remind suppliers how important they are and how much money they allow the supplier to make. Undoubtedly this is a standard negotiation tactic. But where it goes wrong is where the clients self-image doesn’t match reality.

This anecdote starts with a client demanding extra resources, more commercial concessions and some impossible deadlines. Their argument: we’re you’re most important customer. We, therefore, get what we want.

Discussions had not resulted in any change in their stance. This is what we want (a lot). This is how much we will pay (not much, or at least enough to offset the pain).

The anecdote ends with a meeting. In the meeting are senior figures from both organisations. The supplier is presenting and the Powerpoint effectively has a single slide. The slide shows a simple bar chart. The bars are ordered with the largest on the left, the smallest on the right. The axis are unlabelled.

After pleasantries, the presentation starts with a statement followed by a simple question.

“This chart represents our top ten customers by revenue for the last year. Which bar are you?”

The client quickly points to the bar on the far left, the largest.

“I can’t name them, but that bar represents around £x.”

The figure was left to hang in the air. It was nearly double what this client had spent in the last year and they knew it.

The relationship had deteriorated to the point where the client was asked to make two more guesses before it was revealed that they were, in fact, the second bar from the right. It was still, I should add, a reasonable chunk of change but it quickly became clear that their “most important customer” argument would need some refining.

Anyone who has worked with difficult clients will probably be smiling at this, though of course the fact that it got to the point where this strategy was even thinkable shows a failure for both parties. While it worked, for a short time, this is a strategy that you’d only try if walking away was a reasonable option.

I guess what I’m saying is that relationships work both ways, and the best ones are made out of mutual respect. Not everyone is out to screw you. You might think that taking your supplier or client for a ride makes them your best customer or your best supplier but in the end it will likely come back to haunt you.

Links

My delicious.com bookmarks for July 17th through July 23rd

  • Senior City-zens: The World's 10 Oldest Still-Inhabited Cities – "I grew up in Europe, where the history comes from." Maybe Eddie Izzard should have gone with "I was born in the middle east, where the really old history comes from."
  • Maker's Schedule, Manager's Schedule – If you can't actually avoid meetings, then at least try to schedule them so you can maximise your productivity. Rings true…
  • There’s a pretty significant problem in the new… – I'm starting to expect Graham Chapman to burst in at any second and announce that this is getting far too silly. Apparently any iPhone app that allows "unfiltered internet access," everything from web browsers to Twitter clients to, presumably, delicious.com clients, now requires a 17+ rating.
Opinion

Professionalism

4 Comments

A few years ago I was subcontracted to one of the large consultancies. I was taking over from someone who was, supposedly, quite senior and the task at hand, I was told, was very hard. I should take copious notes as she wouldn’t necessarily be around afterwards to help me. Making a mistake or missing out any one step could be disastrous to the whole process. If I did everything properly each new installation would take about a week.

This turned out not to be entirely correct.

After sitting through over a week of her spelling out each and every step in excruciating detail — much of which I don’t think she really understood — I spent three days writing a shell script to automate over ninety percent of the process. I don’t mean a quick, shoddy hack either. I spent the time to gold-plate it. It was a work of art. I set it up so that you only needed to copy the one file and allowed for the user forgetting to switch FTP into binary mode ((I basically appended a tar’d and uuencoded file to the end of the shell script which it knew how to extract and decode.)).

In the end, my three days of work reduced the week long process to about an hour, and most of that was waiting for the file to transfer over the network.

I say all this not to show off. I think any engineer would have thought to do this. I note the extra refinements so you realise that it could have been done in much less than three days had I not wanted to practice my Unix-fu.

Result: I was heavily criticised for not following the proscribed process. I pointed out that my new scheme was quicker, easier and less error-prone. They countered that I had been unprofessional to begin a “development project without authorisation.”

What does “professionalism” mean to you?

Sometimes, I think, it’s used as an excuse to do or not do something in a particular way. “That’s not professional” is kind of a cop-out. In this case I can only assume that the real reason was that they wanted to bill a week of my time to the client for each installation. Of course they couldn’t say that.

Since then, every time I hear the phrase “that’s not professional” I try to drill down and find the real, underlying reason. I’m hoping that one of these days I won’t be disappointed with what I find. It hasn’t happened yet.

Links

My del.icio.us bookmarks for January 12th through January 16th

  • Apple introduces new Apple TV software, lowers hardware pricing – Now potentially more useful with the movie rentals. But where is the price drop in the UK?!
  • Dell tells customer ‘Mac is good option’ – “Now, it’s possible that the techie was referring to a 1970s rock band, or to an item of waterproof clothing. But we can’t help concluding that he was indeed talking about Apple’s operating system.”
  • Steve Jobs gets cohesive – Some cool stuff from Apple at the MacExpo. I think the Time Capsule is going to be on my shopping list when it ships next month. The movie rentals (when they get to the UK) look interesting but they really need to build their catalogue!
  • How to recognise a good programmer – Great discussion on recognising great developers. The problem would seem to be finding them! Most recruiters just pattern match on CVs which tends to favour the “career” developer.