Dailies Tech Leadership Uncategorized

It’s Monday, Tech Leads. Ugh. Focus on what you can control, not what you can’t

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.

Onward, tech leads!


What to do with the Swift REPL “NameError: name ‘run_one_line’ is not defined” error

I was playing around with Swift this weekend. Every time I started the REPL (whether version 3x or 4x of Swift) I got a whole bunch of errors that look like this:

The REPL would work fine, but you know…. it was really, really, really, really annoying having to look at that error. All 100+ times it got repeated.

Turns out that the Swift REPL depends on a Python library called six. You may be able to quickly install it using this command:

Problem solved……?

Good luck out there!



Monday Motivation

“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.”

Agile Consulting Management Uncategorized

Managing software engineers is straightforward, leading consultants is not

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

If you ask a team of three software engineers to write some Javascript to say “hello, world” after a user clicks a browser button, you’ll get at least six solutions. The first will copy and paste some crap from the internet and promptly return to Hacker News. The second will agonize over the naming of her function and put some exotic js dependency in the project. The third proposes three different — half completed — options, one based on Elixir/Elm, with an abstracted object model for transporting messages like “hello, world” across the wire and complete with a specialized Jenkins plugins to Dockerize the whole thing and deploy it to Kubernetes.

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.

More on this to come when I find the time…


Happy Holidays from Los Angeles

Even if it is warmer in Boston in this year, I still don’t think they decorate their Palm trees, if any.   

Software Craftsmanship Uncategorized

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?


Notes from Software Craftsmanship North American 2015

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.

scnaThe 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.

Consulting Uncategorized

“The privileged role of leadership” – some quotes from Herminia Ibarra

On the dangers of the navel-gazing leader:

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.


Middleware project management requires a strong leadership skillset

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.


Maybe that split second isn’t so elusive

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.

And that’s what will govern the split second.