It takes a lot more than a job title to be a consultant

Some call themselves consultants because they don’t know what else to call themselves. Others put it on their LinkedIn profiles because they’re in between jobs. Still others work for some big IT contracting company that gave them the title consultant, and now they fly around the country “consulting” with clients, which mostly means they’re writing code under pressure.

Nonetheless, I love to think of myself a consultant. It’s all I’ve ever really wanted to be in life even though I’ve taken roundabout ways of approaching it. But I’m with Peter Block on this. I’m not a consultant just because I say I am. And you’re not a consultant just because that’s what it says on your business card, your LinkedIn, or because you feel like a jetsetter when your client foots the bill for your Southwest A-List Preferred status.

No. Consultant is a title you earn after a lot of nuanced, subtle, and thankless hard work. Consultant is a conclusion, an aspiration, an outcome.

Aspiring to consultant status means, fundamentally, focusing on building and expanding trust with the client. Consultants earn trust moment by moment, day by day. And that trust, when it expands, unlocks many doors. Real consultants have license to challenge and even change the status quo, take their clients to the next level, get their clients to think differently, help clients accomplish things they thought impossible.

Even more challenging, it’s a title you have to earn again and again with each client and with each person you work with at that client. Just because you were a consultant for Jones doesn’t mean Smith will accept you as one. You have to earn consultant status with every person you meet.

Consulting is a misunderstood but wonderful profession. But it’s a hollow job title if you don’t work to earn it every single day.

Is “profit motive” even a thing?

We are told we are in business to maximize profits. The classical economists tell us that’s what our motives as managers are and should be. That is what business is, we are told. Maximizing profits for tranches of faceless shareholders is what’s supposed to get you out of bed — because you’re a manager.

And that creates some anxiety in you because you don’t get out of bed to serve tranche A, B, or C. But you like your job.

You get out of bed in the morning to try new things because you’re a software engineering manager. You look forward to the product your engineers are building. You’re looking forward to expanding the team. You’re looking forward to the six one on ones you’ve got scheduled this week because you want to know what makes your people tick and what’s going to get them out of bed in the morning.

The word “profit” isn’t in your daily vocabulary. You aren’t thinking about maximizing profits while you wait in line at SBUX to order your second venti Americano of the day. Yet, still. You’re a little anxious because you’ve got a lot of “shoulds” floating around in your head all of the time, and “should maximize profit” is one of them (if rarely). And maybe your ideas for increasing the level of craftsmanship on the team actually will cause you to lose a little money this quarter. Does that mean you’ve failed as a manager because you were operating with the wrong rationale?

Of course not. Some will suggest we can resolve the tension by putting qualifications and exceptions on what it means to “maximize profit.” We could think long-term profits, not quarterly profits. Maybe we should redefine “profit.” Maybe we should expand who’s profiting — our engineers, our community, the environment, the next generation.

But what if we didn’t have to qualify what it means to maximize profit? Instead, what if we thought of profit as not a rationale or a motive, but rather a test — a test of whether your theories or tweaks or 1:1s actually work? What if it was a test of whether you should do more of that thing, less of it, or do it in another way? What if profit maximization was simply a factor — an important, limiting factor, of course — influencing what you do as a manager?

You might still have a little stress about whether your ideas will pass the test, but that’s healthy. And of course there will be lawyering about the definition of the test itself, but at least you won’t feel like your motives are in the wrong place anymore. I hope that brightens your day just a little.

(By the way, Drucker is still potent today. I got most of my ideas for this post from The Practice of Management, a book from 1954 and a century ahead of its time.)

The Nolan-Tabb software engineer inspiration chart

What if you were managing a team of superheros instead of a team of programmers?

A recent First Round Review article argues you should be doing just that. You should stop thinking of your engineers as a group of engineers with different functional capabilities (front end, back end, devops, etc.). Instead, software engineering managers should think of their engineers as superheroes with different capabilities, weaknesses, and managerial considerations.

According to Christopher Nolan and Lloyd Tabb, there are four superheros on your team:

  • Aquaman is inspired to dive deep to solve difficult problems.
  • Flash moves quickly and relishes in speed — might write messy code but creates solutions to demonstrate quickly (“exposure speed” on my chart) while everyone is busy handwringing.
  • The Priest is inspired by beauty at the code level, the craftsmanship, or the API.
  • Spielberg is, by contrast, inspired by the beauty and quality of the end product.

But what if you didn’t actually hire a superhero and you only have humans on your team?

I’ve never been a superhero fan. And I don’t even like comic books. So let’s talk about real humans in real life. Homo sapiens are more complex and possess varying levels or combinations of superhero powers, so I took a minute to riff on the article and propose the following (Westin took no part in this analysis, btw). 

You might find the scatter-chart variation easier to spot whether you’ve got over-weighting or under-weighting in a particular capability or even a missing capability.

How do you probe to figure out where your engineers land on the chart? If you don’t already know or you’re interviewing, here’s a question to start the conversation:

“Describe the best day at work you’ve had in the past year.”

What isn’t clear from the article, and might be worthy of its own post, is how you should configure the team. Do you want an equal balance of capabilities? Do you want to overweight in a specific capability? The answer surely turns on what you’re trying to accomplish. Maybe you want a team of Priests. Maybe you want a combination of some Priests and some Flashes… Maybe you need a bunch of Aquamen…

Software Craftsmanship – Letters from the Road #5

Walmart. You cringe every time you go. You went there a while ago because you saved a few bucks on an iPad mini or got a killer price on that toy you wanted to give your niece. Whatever it was, you drove yourself to a Walmart in Duarte (or wherever) feeling clever for the $50 you’re saving. Saving $50 == awesome.

But then you parked your car. You walked in. The greeter was friendly — a little too friendly and a little too young, like he was on day release. You walked to the online pick up counter (’cause you’re just that clever to order online) and spent some quality time with the cashier talking about her loser boyfriend while she got your order.

You walked out thankful you had the opportunities in life you did so you could work in the hottest industry in the world instead of punching a time clock near the baler in the back of the Walmart in Duarte.

Yet, working for that place and that ethic is what Chad Fowler suggests as a paradigm for how we should think of our jobs writing code — at least sometimes. His sub-point is that “When you create software, the purpose is rarely self-expression.” If Fowler were talking about some other industries he might be right.

But he’s wrong about the software industry. The idea of “writing code to spec” died (or is dying) with agile. In our business (in sharp contrast to Walmart’s industry), the best talent wants to work in a place where the craft is respected and where their employers don’t cut corners just because the client asks for it. Also, Fowler overlooks that clients pay for high quality code.

The first point might be the most important when it comes to the war for talent. Craft matters. Personally, I spent far too many years working in shops that cared primarily about hitting deadlines without watching the ballooning balance on the tech debt credit card. It made me cynical, to say the least.

Maybe you did too. You hopped from job to job. Nothing was ever right. The code base. The tools. The managers. The product owners. The other people on the team. Something — lots of things — always sucked. Maybe it’s just that management (and/or the team) didn’t care about the craft.

The second point matters a great deal too. In our world, even in the enterprise, where people are inundated with choices and options for how to use our code to solve problems or use our apps to experience new things, quality is often the key differentiator. And quality doesn’t start with testing; quality starts with the craft.

Fowler suggests that sometimes we need to succumb to commodity because our clients demand it. I think Fowler is proposing a dangerous and unprincipled distinction that will inevitably lead to cynicism for anyone who tries to follow. I know because I’ve been there. I don’t argue that we should always win the battle between quality and shipping product. I only argue that we’ll fall into cynicism in our profession if we don’t engage in that battle, if we don’t advocate for the craft.

Bummed I missed CalibrateSF

I missed CalibrateSF, a software engineering leadership conference, last September. Their thing is “You’re a great engineer. Become a great leader. A conference for new engineering leaders hosted by seasoned engineering leaders.” With those sixteen words, they nailed something I’ve been thinking a lot about this year.

Luckily, CalibrateSF videos are available online so I’m attending on my own terms during the holiday doldrums. Rob Slifka, one of the co-organizers, opened the conference. He’s the Engineering Veep at Sharethrough.

In his talk, Slifka nailed two big anxieties I ran head first into when I first started managing. For example, he explores the sudden transition from engineer to manager. While lots has been said about the difference between management and engineering (see, e.g.Eliot Horwitz, Steven Cerri, kellanMarcus Blankenship, Ship It Good), Slifka drilled a point I haven’t seen put out so clearly anywhere else. That is, on “the Friday before the Monday” when you start as a new software engineering manager you had a backlog of work to do. You knew what was coming next and the expectations were pretty clear.

But on your first Monday as a new engineering manager you discover there’s no backlog, no source of “truth” for your work. Nobody tells you what you need to be working on. Nobody tells you (even if many have opinions) how to solve problems. Indeed, it’s not really clear what the problems are. And feedback for solutions or decisions you implement may not come for weeks, months, even years; put differently, your days of getting that nice little green light that your unit tests passed are over.

Second, he nailed something else I haven’t read much about: the effect of agile on new managers. Theoretically, in agile, managers don’t get to tell people what to do anymore (I say theoretically because on my cynical, tired days I feel like all agile did was create a lot of confusion for everyone, especially me as a manager). By contrast, everyone in my family assumes that managers tell people what to do, but the agile process is supposed to tell people what to do now. So what do I do for a living again?

Slifka hints at it, but I think the answer is quite a lot — and quite a lot more than managers used to do. Stay tuned for my next post on the topic.

Software Craftsmanship – Letters from the Road No. 4

Assembling a Team of Effective Software Craftsmen

There’s a lot written about craftsmanship, but I haven’t come across much from a manager’s point of view. On the one hand, we all agree that deploying quality products rapidly is job one, which is what I mean by effectiveness. But the other hand is more controversial: what is software craftsmanship and, more salient to me, how in the world can one manage for craftsmanship?

The answers to the questions on both hands surely merit their own treatises. So let’s start with a smaller outset concern: how do you assemble a team of craftsmen from the ground up? Assuming you couldn’t hire a complete team of software engineers who obviously embrace craftsmanship ideals, here are a few indicia that I might look for:

A whole person who’s fun to talk to, work with, and generally hang out with. If we’re going to think of ourselves as working together in a workshop and we want our engineers to be communicating (a lot, right?) then we need to have engineers who are fundamentally good people, people who are easy to talk to about all kinds of things and open to changing their points of view on code and anything else. By this, I seriously don’t want the team to be a monoculture; I just want each member to be friendly and good-natured.

Dismiss this point as obvious or “soft” at your own risk. This species of human resource — if you want to express it in inhuman terms — is a seriously scarce resource in our economy of software engineers. Still too squishy for you? Would you agree that a big, unspoken, factor in team communication failures (and therefore, project or business failures) is that some people are exquisitely horrible talk to or work with? Sometimes it’s so bad that other engineers want to work from home all the time. Slack can’t fix an asshole no matter how clever the giphy.

Works (or wants to work) in small increments. These days I’m of the perspective that craftsmanship is not a “thing” so much as a state of mind manifesting itself in the team’s process of crafting code. So in building a team of craftsmen if I can, somehow, surface during an interview that an engineer is focused on building small, shippable increments then it might be evidence that he or she has the habits of a craftsman.

I’ve tried a few different approaches on this point in the past with mixed success. Maybe I’ve been more successful looking for the reverse — the engineer who wants to design everything and every corner case before writing any code, let alone shipping anything. This habit is easy to detect and very difficult to change.

Self-directed, fascinated by great code, and fully engaged. My ideal engineers aren’t waiting around for stories or tasks from a scrum master nor are they seeking to score political points by taking potshots at a befuddled product owner in a grooming session. They’re dedicated to making their mark on the product by actively engaging (and truly educating) product owners and/or bringing in a great new method, technology, or something cool they learned at a coderetreat (or meetup or whatever) last weekend. I know this means that my ideal engineer is putting a lot more than forty hours a week into the job as well as his or her career, but I’m just stating my ideals here.

I could have made this a laundry list with a million ticky tacky points but I think broad strokes are more effective with human “resources” than punch lists. Also, one thing you won’t ever find on my list is any kind of quantitative measure.

My objective for this  list is to help identify a team of software engineers who could grow into solid (or even great) craftsman who ship code. In summary, I think my list might capture the raw material if each individual on the team is (1) a great person to work with, (2) works in small increments, and (3) is self directed and fully engaged.

What do you think?

Software Craftsmanship – Letters from the Road No. 3

Heart, head, and hand

On my flight out of Burbank yesterday morning I finally got a few free cycles to read some more of Why We Make Things and Why It Matters. Korn, the author, wants me to explore craftsmanship from two points of view — the creator’s and the reader’s. It’s a short flight to Phoenix, so I’ve only got time for one chapter and one POV — the creator’s.

Korn argues that “the making of craft calls forth a symphony of human capacities that are intrinsically fulfilling to the craftsman.” Too many software engineers — especially in the enterprise — I know would counter an assertion like that with an all-too-cynical response. What do you think? Do you feel you’re using the “full symphony” of skills when you’re crafting code?

Sure, Korn is talking about crafting with wood, materials, and the physical world, which you could argue is a critical distinction. You and I work with ephemeral code; we work in mental abstractions. But is it really so different? After all, the code ultimately finds its way into the processor, which is just as unforgiving (maybe more so) than a dovetail joint gone wrong.

I think most conscientous software engineers would universally agree with Korn on the point that “[t]o achieve consistent quality in terms of fit and finish, [we have] to marshal qualities of [personal] character such as focus, patience, and perseverance.”

What if our day jobs engaged our whole character — our focus, our patience, our perseverance? Korn goes further to suggest that craftsmanship may give us the “holistic experience many contemporary Americans find lacking in their occupations and personal lives.” Interesting. What if it we weren’t missing this “experience”? What if you could you go into work tomorrow morning and own that belief? Of course, I can’t do that for you. But maybe you can find a bit of it in our little Los Angeles meetup group.

Maybe I’m getting too out there for you; it’s late as I write this.

Maybe this will get down to the actual rivets of the modern software craftsman’s trade: “Craft is a process of continuous feedback in which the craftsman’s working suppositions are subject to constant fact-checking by the real world.” The real world Korn is talking about is how wood reacts to his tools, but maybe he’s starting to sound like what we think of as software craftsmanship; we use tools and methods like devops, TDD, small increments, and etc. these days… maybe as an industry of creators we’re getting closer to craftsmanship — or maybe that’s just the tooling and not the true point of view.

Do you agree? Maybe? No… yes?

Listening

The other day, based on a tweet from Tom Peters, I picked up Peter Drucker’s classic The Practice of Management. It’s intimidating how much pressure it puts on managers. So I decided to step back a bit to first principles: communication.

It seems obvious, but getting lost in all the technical details and distractions of a software project makes me (and probably all managers) forget that a manager’s job one is communication. So I picked up a different classic, Dr. McKay’s Messages: The Communications Skills Book.

Intention

Appropriately, McKay covers listening in the very first chapter. According to McKay, effective listening starts with the right intention, of which there are only four valid options: to (1) understand someone, to (2) enjoy someone, to (3) learn something, or to (4) give someone help or solace.

However, most of us listen with the wrong intention (he calls them pseudo intents) all too often. The wrong listening intention is usually a selfish one: we listen because we’re pretending to be interested, or we’re just patiently waiting for our turn to speak, or we’re just listening for just specific information we want, or whatever. Routinely avoiding these wrong intentions surely takes tremendous discipline.

Effective listening

Only after aligning your intentions should you then consider whether you’re effectively listening. For McKay, there are four steps to effectively listening: (1) active listening, (2) listening with empathy, (3) openness, and (4) awareness.

You’ve probably been admonished to be a more active listener for a long time; I have. McKay’s formulation is practical and actionable: (1) paraphrase, (2) clarify, and (3) offer feedback. It’s easy to employ, but I honestly can’t remember the last time I heard someone employ all three of those in one of my conversations — but then, I work with developers like you during the day and talk to little kids when I get home. Neither are known as sterling conversationalists!

Effective listening requires openness and awareness. Openness is self explanatory — you just need to have an open mind. Awareness in listening implies that you’re careful to listen to the assertions in what someone says as well as checking for congruence between what they say and how they say it (body language, intonation, etc.) Both of openness and awareness in listening seem common sense.

However, listening with empathy is sadly overlooked skill. Being empathetic isn’t something I’d accuse many programmers of, nor would I have any idea how to coach a developer how to be more empathetic, but McKay has a practical definition of “empathy” that I think even my alpha of alpha geeks can use. It means that we only need to remember that everyone is simply trying to survive and feel valued. When others say things that you’re having trouble listening to because it annoys you or upsets you (like a developer wants to some framework you think sucks), remember that they’re doing it for their own self preservation.

Blocks to listening

McKay also has a list of twelve blocks to effective listening. I love the characterization of these habits as blocks because even if you approach listening with the right intentions and even if you diligently work to be an effective listener, you can be “blocked” by the habits he cataloged.

I won’t repeat them here, but a few popped out at me as things I do or that I see other people do. For example, I have a habit of “advising.” This means that I think I only need to listen to a few sentences of what someone says before I’m launching into my ideas about how to fix it. This is especially true with software or project stuff, less so in my personal life (I think). I also witness this many times a day among software engineers. But we can’t effectively listen to people we’re you’re busy formulating a solution before they’re done talking, right?

Another example I see in others all day long (and I think I’m actually pretty good at stopping this myself on this one), is “identifying.” This is where someone will say something like, “I rode the Star Wars ride at Disneyland,” and then someone else just has to interject right away to talk about the line they waited in, and then someone else has to jump in and talk about the Fast Pass thing, and so on… Nobody gets to finish talking because we’re all so busy “identifying” our own experiences with what someone else said.

INITIATIVE – my Thanksgiving weekend project

One thing I’ve found as a manager is that I so many “things” to manage. Usually I can manage on my Trello board. These things could be something small like, “Go work with another team to figure out how we can get access to their API.” Or “Coordinate some agile training for your team.” Sometimes it’s bigger, like “Setup a whole new development environment.”

Managing these initiatives, whether routine or ad hoc, is a requirement that appears on every managers’ job description, but it’s a challenge for me personally to track all the little initiatives I’ve got my teams working on– even on Trello. For me the problem is that it’s very hard to be disciplined about making each team members’ role and expectation clear.

So I whipped up a little Node app over the Thanksgiving day break. I think it will help at least keep me disciplined to think through each mission, each developers’ role and expectation, and whether I’m communicating those things.

The main screen looks like this:

initiative_screenshoot_2015-11-29

If you want an account on it, just drop me an email. But it’s a little rough around the edges. And don’t freak out about the SSL cert error just now. It’s made with node, mongo, express, and jade. Such an easy stack.

initiative.michaelrice.com