The other day, I was telling someone that I really love to be a “hands on” kind of manager or leader.
The next question was, “well, that’s great but how do you know if you’re crossing the line from ‘hands on’ to micromanaging?”
That’s an insightful question. And I’m working up an email post for my subscribers on the topic this weekend, but here are some broad strokes.
First, check your intention before having a conversation that might cross that fine line from being really “hands on” to being really annoying. If you’re walking into a conversation from a mental place where you need something from someone or have an insecure need to control what a person is doing, this should be a red flag for you. The person receiving the communication will almost surely pick up on your subconscious feelings.
Second, you need to have done the hard work of really hearing and seeing the people on your team. That way you’ll know the subtle cues and the way that people like to be engaged. For example, understandably, a lot of software engineers don’t like being engaged when they’re deep in the code. Others are able to context switch more easily. So knowing them means you’ll know the right time to engage.
Everything you will ever do as a leader is based on one audacious assumption. It’s the assumption that you matter. Before you can lead others, you have to lead yourself and believe that you can have a positive impact on others. You have to believe that your words can inspire and your actions can move others. You have to believe that what you do counts for something. If you don’t, you won’t even try. Leadership begins with you.
Wikipedia defines herding cats as an “idiom denoting a futile attempt to control or organize a class of entities which are uncontrollable or chaotic.” That’s about right when applied to software engineers.
Despite cat herding, managing is (relatively) straightforward
For all the high minded conversations about agile, sometimes I honestly think it came when the folks in Snowbird finally said in exasperation, “Guys,* can’t we just agree to build one, small, useful thing… and then go from there?!?!” And agile was born.
With agile now mainstream and mature, it’s a relatively straightforward task to keep track of software engineers, to fix blocks when they come up, improve effectiveness, happiness, and etc. — at least relative to what it was like back in the 90s and early 2000s. It’s a lot of work, but it’s pretty well-known.
I’m down to two major problems these days: inexperienced engineers and inexperienced senior managers. There are still far too many software engineers who don’t embrace the agile mindset. They claim to know the ceremonies and come with years of “agile” on their resume, but they learned bad examples or are resistant to the mentality. In either case, my job isn’t about managing, it’s coaching and evangelizing, which is fun when it works.
The second problem is a harder to solve. To grossly overgeneralize, I find many senior managers are warming (or just resigned, possibly) to the idea of delivering incremental value on the West Coast where technology is so dominant. On the East Coast, the big, traditional firms still have a way to go — and that makes the manager’s job tough.
Now, let’s increase the difficulty level; let’s talk about leading traveling consultants
I’m not a software engineering manager working in one environment with a fixed number of engineers day after day. There’s a lot of great stuff written about that role and even conferences now. Instead, I manage consultants who might show up on a client site for just a few hours. There’s almost nothing written about how to be successful doing this.
In both roles, the job is to optimize the value the software engineers produce. Roughly, there are three parts: make sure the project management process it working, help the individual contributors be effective, and setting expectations up and down.
How managing consultants is different
That’s about where similarities end. First, the pressures feel higher. Unlike an existing, in house development team, bringing in consultants hits budgets in a different way, appearing expensive, so the demand for value goes up. It doesn’t help that clients don’t always need to develop long-term relationships with you, so they sometimes feel free to squeeze.
Second, I work with many different consultants, many of whom I’ve never met and don’t deeply know their temperaments or capabilities, which is something I would care about if I were managing a high stakes internal project. Third, I run too many projects to be onsite enough to coach or manage all the little, but important, things that engineers need to do all day to be effective, let alone the deep details of their project backlogs or the code. My direct reports are only occasionally on projects I manage.
Ways to deal with it
I’ve noticed that people in my role seem to react to it in two (overgeneralized) ways. One reaction is to switch into an administrator type role. This is a natural reaction when you’ve got a lot of engagements with diverse technologies all at once. The second is to stay tightly involved in one technology and/or one industry, which is something I saw a lot at Accenture.
Instead, I’m trying to figure out how a consulting manager can produce highly effective results no matter what technology and across many, diverse projects simultaneously — in other words, how to scale.
I think it comes down to the fact that, at scale, the most you can do is a rough kind of high level, tracking-style management. To be effective, you have no choice but to scale up by focusing on your own leadership skills. You can’t manage consultants to where the team needs to go like you can when you’re in house.
Between agile and holacracy, both the demands on management and the role of management are evolving rapidly. And as you know, innovation in software isn’t limited to technology. Software engineering management seems to be leading the path into this new, uncharted, and promising territory.
Even a decade ago, most software development managers (that’s what we were called back then, right?) were heavily focused on task management, project management, and process generally. Agile encroached on management’s turf, handing a big part of our jobs to specialized scrum masters. Holacracy is more oblique; it simply exiled managers. Our work has fundamentally changed — maybe for the better, maybe for the worse, time will tell.
Given all this, you probably don’t know enough about what other software engineering managers or engineering directors are doing out there right now. Oh sure, you know what other managers at your company are doing – but how does your work compare to the rest of the industry? I’ll speak first: I don’t know.
So let’s figure this out together. I finally got around to putting together a survey I’ve been thinking about for months now — a survey for engineering directors, software engineering managers, or anyone whose job description includes a requirement to herd nerds. I think it will help establish a baseline, without diving into anything proprietary or sensitive to your company.
I know you’re busy, but can you share five to ten minutes to respond to it? Maybe while you’re waiting in line at Philz? Thanks in advance!
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.)
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…
I missedCalibrateSF, 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.
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, kellan, Marcus 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.
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.
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.
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.
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:
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.
You’ve heard of “design smells” when talking about design patterns and software architecture. If you’ve got the nose for them, it’s a way to detect antipatterns or just bad practices that might be latent or nascent in your code base. Yet I’m loathe to use the team “team smells” in what I want to discuss in this post because this implicates real humans (not just their code), and I’ve been in too many conference rooms that smell like locker rooms by the end of the day. . . But maybe you see (or smell) where I’m going . . .
One of the things (“smells”) you might want to be watching for in your team is a heavy use of the word “they.” They are another team or another group in your company exposing some API, database, security service, or whatever. “They didn’t give us the API early enough.” “They changed the spec on us.” “They did it again.” “Their service crashes all the time.” “They don’t know what they’re doing.”
Steven Covey explored the circle of concern versus the circle of influence. The circle of concern contains the things you or your team are worried or fretting about. Maybe it’s the shitty documentation they produced. Maybe it’s their buggy code. Maybe they don’t know what they’re doing.
By contrast, Covey’s circle of influence is usually smaller. It’s what we, as a team, can do. The defensive code we can write. The ways we can help them solve the problem. They ways we can code around it.
Too often, the developers I’ve managed (and coded with) stray outside their circle of influence into their circle of concern and much too often. It’s usually disastrous. In a worst case, it paralyzes the team. In a best case, it plants the seeds of cynicism and distress. As a team lead, it’s tempting to drop into that war mentality, but when the team ventures outside their center of influence into their circle of concern, their effectiveness and their agile velocity plummets — and it’s insidious.