Mondays can be a little overwhelming, tech leads, especially when it’s also April 15, tax day, in America! I know. I get it. It’s Monday for me too.
Let’s spend a moment with the fact that it is tax day. You know what they say, the only things certain in life are death and taxes. Let’s drop in on that and consider: it doesn’t matter what you do to change the situation right now. You can call your Congressperson. You can campaign. You can lobby. You can call some talk show radio and run your mouth. But you cannot change how much money you have to cough up today. For those of you in high tax states like California, man…
Now let’s talk about your job and the fact that it’s Monday. As a tech lead, you’ve got a whole bunch of things happening, right? Maybe your sprint ends at the end of the week and your team is behind on story points. Maybe you’ve got an annoying meeting coming up with a product manager, and you’ve been dreading it. Maybe there are some budget cuts going on and you’re not sure what what’s going to happen to your project, team, or yourself.
Don’t sweat it!
You already know this: there’s no point at all in complaining about taxes, or complaining about your company, or complaining about your team, or really, even thinking about the fact that it’s Monday.
What is useful to think about right now is what you can control. One thing I like to do on Mondays, or really any day that I start feeling overwhelmed, is to start using my tracking and adjusting behaviors and start pinging the team. Get clarity on where things actually are. What can we do to fix it? Drill in and focus and look for details where you can make a change.
You can’t change the fact that your ops team won’t fix the flaky servers, for example. But you can talk to your team about how to code around it, at least for now. There is almost always a way, and if you focus on that instead of the problem, you can make this a great week.
“To put away aimlessness and weakness, and to begin to think with purpose, is to enter the ranks of those strong ones who only recognize failure as one of the pathways to attainment; who make all conditions serve them, and who think strongly, attempt fearlessly, and accomplish masterfully.”
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.
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.
Even though I was working through most of it (i.e., listening in on conference calls and on multiple IM chats all day), I was able to spend some quality time at Software Craftsmanship North America 2015, which was here in Los Angeles for the first time this year.
The following are some of my initial notes from the speakers. The keynote opened with Uncle Bob’s thoughts. Compared to almost every other software developer, he’s a bold and entertaining speaker. Today, he seems concerned about the VW scandal and the risk that software may be regulated by the heavy hand of government. He advocates a self-regulated model somewhat like lawyers, but I know a few things about lawyers (see my LinkedIn profile) so I’m highly skeptical. But his heart’s in the right place. Software isn’t a profession in the classic sense — maybe it should be.
Next up was an energetic session from Iris Classon. She was a great choice to follow Bob Martin. I’ve digested more than my share of navel gazing, but when she went through her talk I knew I was in the right room. One of her quips was something like, “code is not a permanent imprint of your intelligence; it’s the place you were in at the time, a measure of your caffeine level, the pressures you were under, your mood at the time . . .” It’s fixable (or should be), and it’s a process.
We then had a talk from Enrique Comba Riepenhausen. I missed most of his talk (thanks, client), but he started with an interesting analogy to coffee. He said he loves coffee made with love. However, he’s a student of coffee and so he knows coffee takes more than love; coffee is hard. Good coffee is nothing more than precision and discipline. Hmm… those are powerful words, but they bring a mechanistic quality that seems uncomfortable (if necessary) with craftsmanship. Sorry I missed most of his talk.
Sarah Mei’s talk had me locked in. She complained that the factory model of software (one that I’m currently struggling with) is inapposite to the way developers work; few in the trenches would disagree, especially me. She then walked through some of the benefits of the workshop model (many in the room were likely with her on this), but cautioned that it’s incomplete. Then she proposed something I’ve never heard of — the stage model. I won’t attempt to discuss it in detail here because it deserves its own post, but I was riveted to her talk.
Justin Searls’s talk on testing was rapid fire and left few brain cycles to dispute or even digest, but it was a show of force to witness.
Christin Gorman’s talk was possibly the most controversial, but I bet she’d be surprised to hear me characterize it so. Again, this one deserves its own post post because her frustrations were part of what caused me to quit the business for a minute back in the last decade. Finally Gary Bernhardt’s talk was also fascinating but I have to concede that it was either a (1) long week or his talk (2) went over my head. My key takeaway is that strongly typed languages > untyped languages. And impostor syndrome sucks.
Whatever happened to teaching students to analyse the complex social systems in which they will live and work? Or teaching them how they can intervene to change them — which some might define as the privileged role of leadership?
And this, which I think is particularly important these days:
Making a leap from a lifetime of expert contributions and hands- on control to the more subtle processes of thinking strategically, working through networks, and leading more authentically is not a one- shot deal, and it does not happen overnight. The transition is built from small changes, is less than linear, and is distinctly uncomfortable.
I’ve been doing tech leadership (typically architectural-style leadership up until recently) for quite a while in a variety of different roles over the past fifteen years or so, and it’s usually — but not always — been for some kind of middleware project.
And recently I’ve been reading a lot of management / leadership books. So far the consensus is that effective leaders focus on the outside environment as much or more than their internal team.
Given what I’m reading and the demands of my current role, it crossed my mind that technical projects focused on middleware put strong demands on project leads to reach far beyond their teams. Indeed, the technology these days is pretty well known and understood. It’s the leadership that’s the missing ingredient in many of these engagements.
Last week I was complaining that I was looking for some silver bullet to that split second moment . . . that moment where you need a team of software engineers to do something and often the response is nothing but key clicks . . . digital crickets.
After wall to wall, double booked meetings all week with software engineers and a challenging trip to lower Manhattan this week, I think I confidently say I was wrong in my focus on that elusive split second. As you can probably predict, it’s not any one split second but all those series of seemingly inconsequential split seconds leading up to the big one that matters.
Put differently, this week proved to me that I can’t crack open my secret can of persuasive whoop ass into any single moment — it’s the cumulative weight of the moments leading up to the critical one that matters.
I’m from Los Angeles — the land of “fake” — and even I quickly recognized some “technique” is going to fall short. The ancient Greeks lived in the same Mediterranean climate that breeds posers that Los Angeles does, and they knew it too: you can’t bullshit your way through authenticity (Covey would chide you for taking the “skill-based” approach). Either you care about the people on your team or don’t. Or you care about the result over the people or you don’t. Your team will know.