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…

Detail-oriented without micromanaging, scrumfall, and it’s been a long week

So much fail. It’s at the end of the project that you really feel the mistakes you made at the beginning of the project, isn’t it? It’s been a tough week.

One of the projects I’m managing is a classic enterprise middleware type project — it’s all about The Integration. While it’s ostensibly about building a next generation microservices platform, really it’s just straight up integration work. But it’s very chaotic integration work. The microservices endpoints are the easy part.

Tracking the details without micromanaging

There are at least two big mistakes I made at the beginning of the project, which have come to visit me now. First, the project was unique for me in that I didn’t have much technical leadership in it. I always had a heavy tech leadership role in the past. This time I adopted a pure project manager posture, and I didn’t track the technical details like I used to.

Looking back on the past few months, I think a lot of my anxiety was related to the fact that I didn’t fully understand what was going on at the level of detail I’m used to. I’m a technical guy, so I need those details. Since I’m still managing multiple projects and will continue to do so in the near future, I think there’s a way for me to alleviate some of that anxiety. It might look something like this, at least for a middleware-style project:

project-map

Scrumfall

Second, it’s been a while since I’ve been in a waterfall-style project so I didn’t track the work that actually mattered the way you would in an old school project. My most recent big application development project was in the media and entertainment industry using a purer agile methodology. We delivered builds in increments and features were ready when they were ready.

This project caught me off guard because it pretends to follow agile, so I was tracking work on stories, trying to get acceptance, etc. But I was fooled because it’s not an agile project; it’s a waterfall project. Instead of going through shippable iterations, we’re doing the classic death march phases: development, SIT, integration, UAT, release cycle. Now that I know this client better, I won’t be fooled again.

It is what it is, so the question now is what to do about it in the future. It’s probably been over five years since I’ve done waterfall, and I completely forgot how completely lame it is. Here are some things I’m thinking for the future:

Do agile anyway. I wish I had actually been shipping our work on regular increments even though the client didn’t fully understand. We could have led by example, and the whole project would be in better shape. I really don’t want to follow “water-scrum-fall” and besides, it’s usually just scrumfall anyway.

Micromanage the work. Ugh. I never really made waterfall work, so I’m not sure what else to do but micromanage the team, the work product, and my dependencies. This is an option when I just have one or two projects, but I don’t think I ever want to take it.

I was dialed into an East Coast standup early this morning (one of my many). The scrum lead (I still don’t like scrum master, and I especially hate ScrumMaster) opted to throw Rally up on a board and simply walk through the open tasks to see what’s done and what’s not sequentially –story by story, task by task. It’s not the first time I’ve seen it, but this is the first time I’ve really thought hard about why I don’t like it.

First, it seems to break agile. At best, it’s basically just a micro managed version of waterfall. At worse, depending on the lead’s personality and communication style, it’s a daily opportunity for the lead to hang himself or herself by undermining trust between the lead and the developers and erode the sense of community among the developers.

Second, maybe more importantly, I think it disrupts a developer’s sense of ownership and craftsmanship in his or her work. At least, that’s the way I used to feel. I feel like I own the work and I own the task, but now the scrum lead takes it away from me and uses it as a tool to interrogate me.

Third, because it removes the developer’s sense of ownership it gives them a good reason not to be honest or detailed about the tasks.

So in sum, I think I much prefer to leave it to the team do the usual three things and then we can do some kind of “ok, do we need to make adjustments to Rally, Taiga, the physical board, whatever…?” step to the standup.