Short projects are hard

Short projects are much harder than long ones. I’m talking about super short development projects, like four weeks plus or minus a few. First, software engineering is almost always harder than everyone thinks, but in a small project everyone assumes that it’s going to be easy. It never is, is it?

Second, the amount of time you have to establish credibility compresses so tightly that it’s easy to completely blow it in just a few days. Trust and credibility usually take time to develop, but if the project only lasts four weeks and you have a bad demo on Tuesday of week two, you may never recover your credibility before the project ends.

Third, nobody takes the time to analyze everything. Realistically, few will invest much more than a few hours to scope out a project that’s only going to last a few weeks, so they build in a lot of assumptions to short cut the process.

Sure, big projects have a lot more on the line, more eyes, and more pressure. But in a long project, there’s time to absorb some of the inherent risk in all software engineering projects and time to build credibility or restore it from a few missteps and the stakeholders usually invest a lot more analysis into it. Short projects are white knuckled with none of these luxuries.

What to do about it

Only use senior engineers who have demonstrated tech leadership abilities. Don’t even try this with a junior engineer who’s still learning — even if it costs a lot more. You’re probably doing short project because you’re hoping to get follow on work, so don’t blow it by trying to turn a profit on this one; make it up on the backside (hopefully).

Raise the risk before you agree to do it. This is hard because clients are likely to be dismissive and you’re struggling to build credibility. They might tell you it’s just going to take a week. But if you remind them that software development is hard, they usually agree to add some buffer. This is software engineering, and one week can turn into eight. Bigly. Mature clients know it.

Ditch the traditional agile processes and two sprint timelines. Be truly agile in your delivery not your processes. Invest more into management and project oversight time than you would on a short project. One or two day sprints if you must follow the process.

Build credibility with the client by demoing as often as possible but at least a few times per week. Daily if you can. Nothing to demo? Demo code. Lots of demos gives you the ability to course correct and build credibility quickly when the inevitable issue comes up.

Offset some of the risk by increasing stakeholder involvement. Stakeholders might be tempted to be dismissive of of their need to be involved in a short-term project. Make them show up to demos or suspend your work if they claim they’re too busy.

What to do if you get off track

Communicate, but do it at a detailed, code level. Remember, even when you’re off track, you’re still trying to use every minute to build credibility and trust with the client — and you need them to support you for more time.

What do you think? How do manage short projects? Did I miss anything? Leave me a comment or hit me up on Twitter @michaelrice.

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…

Want to be a Leader? Remember This: Insight < Outsight

“Most of the good things that ever happened to me – both professionally and personally – happened after I finally took myself out of my comfort zone,” I found myself saying more than once in Silicon Valley last week. Sounds inspirational, but I’m a lousy Tony Robbins imitation.

I lack Tony Robbin’s fire but the getting-out-of-your-comfort-zone-to-grow is one of the few principles I know to be absolutely true. We can discuss other things, but this is not open to debate. If you stay in your comfort zone, your world and your opportunities will shrink. Period. Full stop. End of discussion.

So let’s talk about comfort zones. My world, my social network is limited to software engineers and front-line engineering managers; so if you’re reading this post you’re almost certainly smart. You’re smart, and you’re surviving or thriving in the tech business. Your comfort zone is being as smart as you can be.

Smart people usually think before they act. This is the trait that got us where we are, so we think a lot. A L-O-T. Then we act a little. Then shoegaze, navel gaze, talk to some other engineers, think some more, then act a little more. Then reflect on the experience. This is where we’re comfortable. But it’s not an evil pattern. Many of my most effective, thoughtful, and conscientious consultants do this today too. In fact, I believe that thoughtfulness is absolutely key to developing high quality code and reliable systems. And it’s comfortable for us.

rsz_10953_500Here’s the problem for your career, however: you can’t think your way into leadership. Only stretching to do leadership work will turn you into a leader, which obliterates your comfort zone. For a software engineer who wants to be a manager or lead architect it might mean speaking up even when you don’t have all the facts, setting up code reviews and embracing the difficulties of those conversations, demoing a prototype despite the ambiguity and political issues, reaching out to authority figures, and/or a million other uncomfortable possibilities.

Put simply, you have to take a position that takes you outside your comfort zone. Notice how the loudmouths on the team tend to progress faster than the quieter, more thoughtful folks (up to a point)? Painful (and it is very uncomfortable, bordering on painful sometimes) as it is, humans only truly evolve from the outside in, not the inside out.

It’s this very “outsight” as INSEAD professor Herminia Ibarra calls it, the outside-in, that makes the difference. It molds leaders. So take yourself out of your comfort zone. For more on this, read Ibarra’s book, Act Like a Leader, Think Like a Leader.

Act first. Think later.

It takes a lot more than a job title to be a consultant

Some call themselves consultants because they don’t know what else to call themselves. Others put it on their LinkedIn profiles because they’re in between jobs. Still others work for some big IT contracting company that gave them the title consultant, and now they fly around the country “consulting” with clients, which mostly means they’re writing code under pressure.

Nonetheless, I love to think of myself a consultant. It’s all I’ve ever really wanted to be in life even though I’ve taken roundabout ways of approaching it. But I’m with Peter Block on this. I’m not a consultant just because I say I am. And you’re not a consultant just because that’s what it says on your business card, your LinkedIn, or because you feel like a jetsetter when your client foots the bill for your Southwest A-List Preferred status.

No. Consultant is a title you earn after a lot of nuanced, subtle, and thankless hard work. Consultant is a conclusion, an aspiration, an outcome.

Aspiring to consultant status means, fundamentally, focusing on building and expanding trust with the client. Consultants earn trust moment by moment, day by day. And that trust, when it expands, unlocks many doors. Real consultants have license to challenge and even change the status quo, take their clients to the next level, get their clients to think differently, help clients accomplish things they thought impossible.

Even more challenging, it’s a title you have to earn again and again with each client and with each person you work with at that client. Just because you were a consultant for Jones doesn’t mean Smith will accept you as one. You have to earn consultant status with every person you meet.

Consulting is a misunderstood but wonderful profession. But it’s a hollow job title if you don’t work to earn it every single day.

“They”

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.

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.

Sometimes (often) the best I’ve got isn’t good enough

I read Don Yeager’s recent You Don’t Get Participation Awards For Showing Up At Work at least three times last night. He explains how Steeler’s James Harrison recently returned some trophies his kids got for simply participating in some school event.

I’m not sure I could do that, let alone make a public spectacle of it, but his words make a lot of sense:

“I’m not sorry for believing that everything in life should be earned and I’m not about to raise two boys to be men by making them believe that they are entitled to something just because they tried their best,” said Harrison on his Instagram page. “Sometimes your best is not enough, and that should drive you to want to do better.”

It’s definitely how I feel about work these days. I’ve got a lot going on, and no matter how hard I work, I still feel like I come up short. Sometimes it’s just a personal let down, sometimes it’s something I wish I had done better after the fact, and sometimes the client spots a shortcoming before I do. Sometimes I do a great job, but nobody notices. I’ve got a lot of practice to start earning any awards or accolades.

When the work is rewarding — and it is more often than not — it definitely doesn’t come from some recognition for just showing up and trying my best. Where would we be if our collective progress depended on that kind of external motivation?

Average managers play checkers; great managers play chess

If you click it quickly today, you can get Buckingham’s What Great Managers Do from the Harvard Business Review into your Pocket. Buckingham argues that you can be a great manager and a great leader, but being a great manager means focusing on your team’s distinctions whereas being a great leader means focusing on your team’s commonalities.

Buckingham says too many managers try to treat everyone on their team as if they had the same capabilities — like checkers pieces. In contrast, great managers treat them like chess pieces with different capabilities that work together — if arranged correctly. (“Fine shadings of personality, though they may be invisible to some and frustrating to others, are crystal clear to and highly valued by great managers.”)

On the flip side, “Great leaders discover what is universal and capitalize on it. Their job is to rally people toward a better future.” Unfortunately, Buckingham doesn’t go much farther on the leadership discussion — but I do love the contrast.

This is great and all. But what about running a short-lived consulting team for a client (or even for people who find themselves running short-lived project teams)? How can a delivery manager figure out people’s strengths and weaknesses really quickly to make sure the team can fully execute and then disband? Buckingham has some ideas about probing for someone’s strengths pretty quickly. Ask: “What was the best day at work you’ve had in the past three months?” To find their weaknesses, invert the question: “What was the worst day you’ve had at work in the past three months?”

Interestingly, I think all this could be really useful for managing accounts generally. By that I mean that most serious consulting engagements with large clients are multi-year, multi-team types of engagement, which brings its own kind of management with it.

Scrum in a consulting fishbowl

I guess all agile ceremonies like stand ups, backlog grooming, sprint planning, etc. are held in a kind of fishbowl: you’ve got the pigs figuring out what to do and the chickens and hens fussing around the edges. (Yes, I know this is no longer the right vernacular.)

But when you’re leading a consultant team with a client’s agile process the stakes are a little higher, and the temptation to appear competent threatens to corrupt the agile process. I’ve seen it a lot lately: the scrum teams on other teams appear magically coordinated, the burn down rates too perfect. Yet, they fail to land stories. That blows their trust and credibility.

My bottom line is trust: put simply, the basis of all relationships is making promises and delivering on those promises — large or miniscule. And I’m pretty sure my clients almost always know I’m sweating before I notice it. So (within limits), I think it’s usually a good idea to go ahead and expose your clients to the nitty gritty inner workings of your team by inviting them to your standups, grooming sessions, sprint plannings, etc.

I’m not afraid of exposing my clients to my team’s weaknesses, as long as I can show them the team’s strengths in the process. Put differently, I think most sophisticated enterprise clients know nothing is perfect, they want a sense of the weaknesses, and they deeply appreciate the transparency.

Of course, if the strengths can’t offset the weaknesses, then it’s just a matter of time before your client uncovers it. It probably just means your team is out of its league. And the longer it takes for the client to discover that fact, the bigger the hit on your professional credibility, not to mention your employer’s.

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