Friday, October 21, 2016

He Said Captain

A few months ago, as I was walking my two daughters to school, one of their classmates gave me the thumbs up and shouted "heeeyyy, Captain!"

Young as the lad was, I congratulated myself that someone had clearly recognised my innate leadership capabilities and felt compelled to verbalise his respect for them, and me. Chest puffed out I strutted across the playground, until one of my daughters pointed out that the t-shirt I was wearing had a Captain America star on the front of it. Doh!

Today, as I was getting dressed, my eldest daughter asked to choose a t-shirt for me to wear, and picked the Captain America one. "Do you remember the time ..." she said, and burst out laughing at my recalled vain stupidity.

Young as my daughter is, her laughter is well-founded and a useful lesson for me. I wear a virtual t-shirt at work, one with Manager written on it. People no doubt afford me respect, or at least deference, because of it. I hope they also afford me respect because of my actions. But from my side it can be hard to tell the difference. So I'll do well to keep any strutting in check.

Friday, October 14, 2016

And Now Repeat

As we were triaging that day's bug reports, the Dev Manager and me, we reached one that I'd filed. After skimming it to remind himself of the contents, the Dev Manager commented "ah yes, here's one of your favourite M.O.s ..."

In this case I'd created a particular flavour of an object by a specific action and then found that I could reapply the action to cause the object to become corrupted. Fortunately for our product, this kind of object is created only rarely and there's little occasion - although valid reasons - to do what I did with one.

The Dev Manager carried on "... if you can find a way to connect something that links out back to itself, or to make something that takes input read its own output, or to make something and then try to remake it, or stuff it back into itself ... you will."

Fascinating. It should come as no surprise to find that those with a different perspective to us see different things in us. And, in fact, I was not surprised to find that I use this kind of approach. But once I was aware that others see it as a thing and observe value in it, I could feed that back into our testing consciously.

Connecting my output to my input to my output ...

Saturday, October 8, 2016

Rands in Review

Do you work with people? Are you a person? Can you read?

Yes. Yes. Yes? Read on.

Are you reading a book?

Yes? Go and find that book and put it away now. Go on, and then come back. No? Good news, I am about to help you out.

Ready? OK: you should immediately read Managing Humans by Michael Lopp because it contains something of value to you. I can't tell you what it is, because I don't know you and your interests and your circumstances and your experiences and your co-workers and the other myriad things that make up who you are with your working head on.

But what I can tell you is that there is something - at least one thing, and probably more - in here that will have you nodding along in agreement, or gawping at the perspective that challenges your own, or shaking your head at the unwarranted certainty of a curt categorisation of colleagues and then shortly afterwards finding yourself mentally fitting your company's staff to it, and adding the archetypes that you need that Lopp doesn't describe.

Lopp - or Rands on his blog, Rands in Repose - writes from vast experience across a bunch of companies you have heard of. Slack, for now, but also Pinterest, Apple, Netscape and Borland amongst others. His prose has the patina of a practitioner and, as with Managing the Unmanageable by Mantle and Lichty that I reviewed recently, if you have any experience of working in a tech company you'll find episodes or characters or atmospheres that you can use as touch points to satisfy yourself that Lopp is a reliable witness, a plausible primary source, even if some of his stories and their participants are composites.

For me, interested at the moment specifically in resources that a new manager might appreciate, the message isn't so different from Mantle and Lichty's either. You can read my summary of that but Lopp characterises his take on it succinctly in the first words of the book:
Don't be a prick.
The 50 or so stylish essays that follow (in the third edition; I haven't read earlier ones) cover management and leadership of others, interpersonal relationships at any level, and self-management, all intertwined with the challenges of having to operate in a corporate environment, the structure and logic of which you'll have a better grasp of at some times than others.

Lopp offers short shrift the to the oft-discussed distinction between management and leadership and a sharp pin to the balloon that is the management ego in the book's glossary (which is also online):
  • Leader — A better title than "manager."
  • Manager — The person who signs your review.

The same glossary defines some terms that you've probably come across but would have preferred not to:
  • Human Capital — HR term that refers to the people you work with. You should never ever say this.
  • Individual Contributor — HR term that describes a single employee who has no direct reports. Don’t say this either.

Yet page 1 of Part 1 says (my emphasis)
We all have managers, and whether you’re the director of engineering or an individual contributor, one of your jobs is to figure your manager out.
A case of do what I say, not what I do, perhaps? I'm not so sure. More likely just one of those things. This book describes how Lopp goes about making sense of, and dealing with the world. He explains at length how and where and why he gathers his data, how he analyses it, what conclusions he draws from it, and the actions he takes as a result.

But that can't prepare him for all eventualities, can't account for all the googlies, can't prevent or catch all errors, can't predict all the points at which the rails and the wheels lose contact. All day long, we're in the real world, dealing with real humans in real time. And one of the key messages in the book, and laid out very early in it, is this:
Every single person with whom you work has a vastly different set of needs. They are chaotic beautiful snowflakes. 
So when a usually courteous colleague does something outlandishly rude it ... could be malicious. Could be a mishap. Could mean they hate you, and they've always hated you but manage to hide it. Could mean their marriage is breaking up. Could mean their project failed and they feel responsible. Could mean they've got indigestion. Could mean they have a new job and can't find a way to tell you. Could mean they just got a text telling them their mum won the lottery. Could mean nothing at all, it just happened. And now you have to deal with it, and with something else from the next person and a third thing with the one after that.
 ... that means great managers have to work terribly hard to see the subtle differences in each of the people working with them.
See. See the people who work with you. They say repetition improves long-term memory, so let’s say it once more. You must see the people who work with you.
As I reflect on the book while I'm writing this - and the writing is key for me to understand my reflections - I begin to see it as a guide for making a manual: a manual for becoming a better manager (big and small "m") of people. Lopp's descriptions are of his way of making his manual. And though his manual changes over time his guidance on constructing it do not or, at least, not as much.

You might feel that there's a little too much cop out, places where he says that he can't tell you what the best course of action is because your mileage will vary. But, for me, that's a self-evident truth. Any book that purports to tell me the right way to act in a situation devoid of the context of that particular instance of that kind of situation with those actors at that time is going to need some other extremely redeeming feature to get a place on my shelves. What you get from Lopp is the justification, the method or analysis (or both) and his result, with an implicit or explicit invitation to find your own.

For example, when he breaks meeting attendees down into personalities such as The Snake, Curveball Kurt, Sally Synthesizer, Chatty Patty, The Anchor and others he's not telling you that your meetings must have the same cast (although doubtless some recognition will exist). He is saying that if you were to observe with the same diligence that he has and does, you could find your own heuristics for navigating the tedium and politics, and heading off those ridiculous outcomes.

Lopp was a tester earlier in his career and one of my favourite blogs of his is The QA Mindset which ends like this:
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.
This book is the QA mindset applied to interaction with other people in the face of their, and your, idiosyncrasies and the final chapter, titled Chaotic, Beautiful Snowflakes, reminds us of that:
The hard work of great leadership isn’t just managing the expected tasks that we can predict—it’s the art of successfully traversing the unexpected.
Yes. Yes. Yes.
Image: Google Books 

Wednesday, October 5, 2016

Glory Be

Aware that I'm looking at resources for new managers at the moment, one of my team came across an article and pinged me a quick IM:
Do you agree with this article?
The article in question was Are You a Leader or a Glorified Individual Contributor? by Joe Contrera.

I looked at the article. It's in two parts. The first is a series of statements - mostly absolutes - about being a leader or an individual contributor, neither of which terms are defined except implicitly in the statements. The second is a sequence of "questions" (actually also statements) which permit only true/false answers, with responses being tallied at the end to determine whether the reader is closer to being an effective leader or an individual contributor.

The article pushes some of my buttons and you don't have to look very hard to see a couple of pieces of evidence for that peeking out of the previous paragraph. Here's some more, for the button I label unjustifed absolutes.
After awhile your frustration builds and so you either you start trying to micro-manage your peoples' behaviors or you throw your hands up and jump in and do the work yourself because it's easier and faster.
I guess I'd want to say that frustration might build, the responses given are possible responses, ...
After all it was your ability to get results that got you promoted in the first place. 
Well, yes, perhaps that was the reason. But perhaps there was no-one else, or perhaps those kinds of results aren't the key thing in this team at this time, or perhaps I stepped into the breach when there was a catastrophe and now management don't feel able to take the position away from me, or ...
What becomes so frustrating is that for the life of you ... you can't understand why folks won't or don't see things the same way you do.
That could be the case. Or there are any number of other things that I might be frustrated about. For instance that no-one in my team is prepared to put an opposing point of view when I need people to bounce ideas off.

It's not much different in the second half, although the game changes to one of answering true or false to statements such as this one:
When you get frustrated with the progress others are making ... you step in by having accountability conversations with your people to get them back on track.
I might do that for that reason. Or I might do that for another reason. Or I might do something else for the same reason. Or I might ask what the problem is directly. Or I might poke around in the bug tickets, or commit record to see if I can understand the issue before I do more. I might speak to their project leads. I might speak to consumers of the output of my people to see whether they're getting what they need, ...

Which isn't to say that that there's nothing of relevance about the piece: in my experience, and in the experience of other managers I speak to, there is frequently compromise in your ability to directly contribute to the team's output (in the sense that you have less capacity to do the same kinds of work as someone who reports to you) when you become a leader.

But - and this perspective isn't covered in the article I don't think - that lack can be compensated for by your ability to indirectly contribute. (And this is something you do as an individual.) You naturally have a different perspective from outside of the work. You can be looking wider, deeper, further into the future for icebergs, longer into the past for precedent. You can be looking for patterns across projects, across team members, across teams.

Your contribution can then be in, say, guiding the work in a direction that you hope will avoid problems of the kind you've seen before, or that you think will come from dependency on, or integration with, some other project. You can take action with your team, or in other teams. You can inform your people, or not, ...

I've been critical here, and  Joe is welcome to pick apart one of my pieces and how it fails to align with his personal beliefs, experiences, prejudices, preferences and biases in return if he cares to. But, really, I do it only to give some context into which to place my main interest: the original question. Here it is again:
Do you agree with this article?
When I spoke to the person who asked, I found that it was a throwaway question, tagged onto a link in quick message, tossed in my direction in passing. But it was still a question. And - until we spoke - it was a question I could take at face value, and for my initial reconnoitre, I did.

And, having skimmed the article, and before forming any deep conclusions, I found I had my own questions about the question. Here's a few:
  • Do I agree with everything stated in the first half of this article? 
  • Do I agree with the apparent precepts of this article? (There's some kind of spectrum between leader and individual contributor.)
  • Do I agree with the concept of this article? (That it is possible to place someone on a leader/contributor spectrum on the basis of accepting/rejecting 10 statements.)
  • Do I agree with this implementation of the concept? (That these 10 questions enable that evaluation.)
  • Do I agree with the evaluation criteria in this article? (That the scoring mechanism implemented tells us what it purports to?)
  • Do I agree with the evaluation I recieved when I provided true/false answers? (That I'm not much of a leader.)
  • Is a one-word answer sufficient? (Perhaps just "yes" or "no" will satisfy the questioner.)
  • Should I try to summarise my positive and negative responses?
  • Should I give a thorough review of the article?
  • Should I justify my response or is a statement of it sufficient?
  • Is this a rhetorical question? (It just means "Here's something I found that I thought you might like.")
  •  ...

I could go on. The original question leaves me with a lot of scope for answering because it's both very specific ("agree or not") but at the same time very open ("with unspecified factors of this article"). In this case, the article itself has so many things it's possible to agree or disagree with (including a section designed to force me to agree or disagree with things) that finding a particular angle to take in a response is even more problematic. That is, if I care to attempt to answer the question honestly, assuming good intent on behalf of the questioner, and in a way that I think will satisfy the questioner's needs.

And often that's the way it is at work, and particularly in vocations concerned with building novel things, and particularly for testers whose stock-in-trade is exploring the unknown.

To pick just three motivations for such questions: we might simply ask questions carelessly, or perhaps we have insufficient knowledge about the area to ask questions sensibly even if we take care, or we might deliberately ask very open questions so as not to constrain the thought processes of the person we're requesting information or opinion from.

However these questions are asked, they put a burden on the person responding to not only find data that could form the basis of a response, but to understand the range of possible questions being asked, and then to formulate an answer which includes sufficient of those possibilities in a sufficiently consumable fashion that there's a reasonable chance of the answer being useful in some respect.

I feel like I am on both ends of this problem all day every day. My default when requesting is to try to be as specific as I can (or as I think is necessary given the context and the people involved) about what I'm asking for, or open about the fact that I'm unsure what I know or want. As a leader I will sometimes deliberately go against this in order to illustrate some point to the person I'm asking, or perhaps as a training exercise. My default when answering is to be prepared to ask for clarification. When I can't get it, I try to be clear about which aspect of the question I'm covering at any point in my response, particularly if the answers are meta-answers.

And that's just common sense, don't you agree?

Friday, September 30, 2016

I Can Manage

For work reasons, I've recently become interested in resources for those new to line management. I put out an appeal for suggestions on Twitter and Managing The Unmanageable was recommended by Thomas Ponnet, with a little cautious reservation:
This quote from the book's preface sets up the authors' intent nicely:
There is no methodology for the newly anointed development manager charged with managing, leading, guiding, and reviewing the performance of a team of programmers — often, the team he was on just days before. There are no off-the-shelf approaches. Unlike project managers, who devote hours and hours of study toward certifcation in their chosen career path, development managers often win their management roles primarily from having been stellar coders while displaying a modicum of people skills.
The book is long - over-long for my taste - and, rather than try to rehash the whole thing, I'll take the liberty of making an exceedingly crude precis:
  • people are all different
  • ... but there are broad classes of characteristics that it can useful to acknowledge and look for
  • people are motivated by a relatively small set of important things
  • .. and, after a certain level is reached, salary is not usually the most important thing
  • hiring well is crucial, and can be extremely difficult
  • ... and a manager should be thinking about it even when they are not actively hiring
  • to do well, a manager  needs to be organised
  • ... even more organised than you probably think
  • to command respect from a team, a manager should be able to demonstrate relevant skills
  • ... and need to know when is a good time to do that and when to step back
  • to enjoy the support of a team, a manager needs to show empathy and give protection
  • ... and that sometimes means letting them fail; but shouldn't mean setting them up to fail
  • to function well within a company a manager needs to establish relationships and communicate well
  • ... in all directions: down, up, and across, and in different media
  • a good manager will reflect on their own actions
  • ... and look to improve themselves
  • the source of a team culture is the manager
  • ... and, once established, it requires nurturing

Perhaps these things seem self-evident. Perhaps some of them are self-evident. Broadly speaking I think I'd agree with them, based on my own experience. And, in my own experience I find that I learned many of them only incrementally and some of them the hard way.

Which is where a book like this can help - it's a brain dump of wisdom from the two authors mostly, but also from a bunch of others who offer nugget-sized bites of experience such as
Managers must manage - Andy Grove
with associated commentary:
I’ve used Andy Grove’s phrase innumerable times to coach my managers and directors of programming teams. When confronted with a problem, they can’t just "raise a red flag." I’m always available when needed, but good software managers find ways to solve problems without my involvement or executive management direction.
And here's handful of others that chimed with me:
Don’t let the day-to-day eat you up - David Dibble 
David made this statement to make the point to his management team that managers have "real" work to do; that the seemingly urgent—e-mail, meetings, the routine—could easily fill a day. Only by being intentional about how we use our days can managers overcome letting that happen 
If you’re a people manager, your people are far more important than anything else you're working on - Tim Swihart 
Tim notes, "If a team member drops by at an awkward time and wants to chat, set aside what you’re doing and pay attention. They may be building up the courage to tell you something big. I’ve noticed this to be especially true when the sudden chatter isn’t somebody who normally drops by for idle conversation." 
Managers who use one-on-one meetings consistently fnd them one of the most effective and productive uses of their management time - Johanna Rothman and Esther Derby 
The statement is a match for our own experience.

We have two ears and one mouth. Use them in this ratio - Kimberly Wiefling 
While I love theory and can happily spend time in talking shops, dissecting semantics and splitting hairs, as my recent MEWT experience showed ...
... I also recognise the value of activity to explore, inform, test, and back up the theory. I like to think of myself, still, as a practitioner, and Managing the Unmanageable is a book written by practitioners and grounded in their practice, with examples drawn liberally from it.

It's unlikely, as Thomas Ponnet suggested, and I'd agree, to fit exactly with everything that you're doing right now with the team you have in the place you're working - especially as some of it is very specific to managing software developers. Parts of it will probably jar too. For instance, I found the suggested  approach to levels of seniority too simplistic.

But what it can do is give you another perspective, or inspiration, or perhaps fire warning shots across your bow from some position not too dissimilar to yours, and rooted in the real world of managing people in technical disciplines.

Tuesday, September 27, 2016

It's Complicated

In a recent episode of Rationally SpeakingSamuel Arbesman, a complexity scientist, talks about complexity in technology. Here's a few quotes I particularly enjoyed.

On levels of understanding of systems:
Technology very broadly is becoming more and more complicated ... actually so complex that no one, whether you're an expert or otherwise, fully understands these things ... They have enormous number of parts that are all interacting in highly nonlinear ways that are subject to emerging phenomena.
We're going to have bugs and glitches and failures. And if we think we understand these things well and we don’t, there's going to be tons of gap between how we think we understand the system and how it actually does behave.
On modelling reality with a system and then creating a model of that system:
... the world is messy and complex. Therefore, often, in order to capture all that messiness and complexity, you need a system that effectively is often of equal level of messiness and complexity ... whether or not it's explicitly including all the rules and exceptions and kind of the edge cases, or a system that learns these kinds of things in some sort of probabilistic, counterintuitive manner.
It might be hard to understand all the logic in [a] machine learning system, but it still captures a lot of that messiness. I think you can see the situation where in machine learning, the learning algorithm might be fairly understandable. But then the end result ... You might be able to say, theoretically, I can step through the mathematical logic in each individual piece of the resulting system, but effectively there's no way to really understand what's going on.
On "physics" and "biological" thinking:
[Physics:] A simple set of equations explains a whole host of phenomena. So you write some equations to explain gravity, and it can explain everything from the orbits, the planets, the nature of the tides ...  It has this incredibly explanatory power. It might not explain every detail, but it maybe it could explain the vast majority of what's going on within a system. That's the physics. The physics thinking approach, abstracting away details, deals with some very powerful insights.
[Biology:] Which is the recognition that oftentimes ... the details not only are fun and enjoyable to focus on, but they're also extremely important. They might even actually make up the majority of the kinds of behavior that the system can exhibit. Therefore, if you sweep away the details and you try to create this abstracted notion of the system, you're actually missing the majority of what is going on.
Oftentimes I think people in their haste to understand technology ... because technologies are engineered things ... think of them as perhaps being more the physics thinking side of the spectrum.
On robustness:
There's this idea within complexity science ... "robust yet fragile," and the idea behind this is that a lot of these very complex systems are highly robust. They've been tested thoroughly. They had a lot of edge cases and exceptions built in and baked into the system. They're robust to an enormously large set of things but oftentimes, they're only the set of things that have been anticipated by the engineers. However, they're actually quite fragile to the unanticipated situations.
Side note: I don't think there's an attempt in this discussion to draw a distinction between complex and complicated, which some do.

Wednesday, September 21, 2016

Giving 'Back

The Test team book club at Linguamatics is currently reading What Did You Say? The Art of Giving and Receiving Feedback. Here's a couple of quotes that I picked out for our last session:
  • If you’re really interested in helping people, you’ll do well to start your feedback by opening your own motives to inspection.
  • Even when it’s given at the receiver’s request, feedback describes the giver more than the receiver.
  • When the data and their model don’t match, most people discard the data.

I recall an instance when, engaged in discussion with a colleague I'll call Russell, about the data analysis he was presenting, I spotted an opportunity to offer feedback. It was about something that I knew Russell wanted to change. It was about something that I knew was open to me to give feedback on, because we had talked about it. It was about something that I thought would be beneficial for Russell in multiple ways and, I hoped, would provide some insight into a particular behaviour pattern that he had.

However, it was also the first time that I had seen this particular thing. A data set of size one. I had no evidence, yet, that it would lead to the end point that Russell desired to alter. A data set of size zero.

Against this: my instinct, my gut, and my experience. And a sense of goodwill, built up over time, over repeated interactions, over sometimes difficult sessions where I had tried to demonstrate that I do care to assist and support and advise because I want to help Russell to be the best he can be, in the respects that matter to him and for his work.

But I was still cautious. I have unwittingly burned and been burned enough times over the years to know that each of these conversations carries with it risks. Risks of misreading the context, risks of misreading the agreements, risks of misreading the mood, risks, risks, risks, ...

But I went ahead anyway. The potential benefit and the goodwill in the bank outweighed the risks, I calculated, on this occasion. And I gave my feedback. And Russell agreed with me. And I breathed a deep internal sigh of relief.

Comparing this anecdote to the quotes I pulled from the book:
  • My motives, I think, were good: I wanted to help Russell achieve a personal goal.
  • But the feedback does reflect something about me: an interest in reducing unnecessary complexity, an interest in making presentation clear, the ego that is required to believe that my colleagues will want to listen to any advice from me, ...
  • In this case, it turned out my suggestion didn't contradict Russell's model but exposed it, and in any case I had little concrete data to present.

I use this episode as an example not because it ended well, particularly, but because it's an illustration for me of how much I have been influenced by What Did You Say? in the couple of years since I first read it. I consciously I go about my day-to-day business, doing my best to be careful about when I choose to offer feedback, about when I deliberately choose not to, and about picking up and picking up on any feedback that's coming my way in return.

I try to treat this as a testing task where I can, in the sense that I try hard to observe my own actions and the responses they generate, and I think about ways in which they might be related and how I might approach things differently in the next exchange, or at another time, with this person, or someone else.

Easier said than done, of course, so I'll finish with another quote from the book, another quote that I've taken to heart and act on, that regularly helps guide me with pretty much everything that I've said above:
Don’t concentrate on giving feedback; concentrate on being congruent–responding to the other person, to yourself, and to the here-and-now situation. Don’t go around hunting for opportunities to give feedback, because feedback is effective only when the need arises naturally out of congruent interactions.
Some details have been changed.
Image: Leanpub