Communication problems in engineering teams

An engineering manager asks Stackexchange for help with his “socially awkward” team and gets skewered by the community. It goes to the heart of managing and leading engineering teams, so let’s dig in.

This lack of social skill creates a few problems from the manager’s point of view:

  • won’t participate in company social events,
  • won’t communicate with other teams,
  • rely too much on tools like Slack to communicate, and
  • not reaching out for details on bug reports.

It seemed like a reasonable point of view and like a set of problems I have lots of personal experience with, especially in an agile world where communication skills are super valuable. The community largely disagreed.

First, they disagreed with the premise that the team lacks social skill. They have good advice for you as a tech lead: before you make a judgment that a team or person “lacks social skill,” consider whether they just have a different communication skillsets or techniques than you do. People who become managers often do so because their communication techniques more closely match traditional business norms, so you might have a blind spot.

Second, always remember that you probably preferred lots of time to concentrate and work when you were in their spot. As a tech lead, you’re starting to move into the world of humans that coordinate and progress by randomly bumping into each other in meetings. As you get used to this, you’re going to forget how important focus time is and why asychronous techniques like Slack and email are highly valued.

Third, remember that, as a leader of an engineering team, your product is that now the team’s effectiveness. They’re there to solve problems creatively, which takes focus, concentration, and a unique kind of coordination — forcing them to socialize in ways that match the company’s techniques but not the team’s preferred methods will undermine the quality of your product.

As one poster pointedly said:

Just because your boss [declared the team ineffective because they’re socially awkward] doesn’t mean the criticisms are valid. You now have an opportunity to back up your team and support their best interests, advocating for them and the way in which they work best. As their manager, that is your job, not parroting whatever your boss (who is even more removed from the developer world) has come up with next.

I know you know all these things, but I thought the thread (which is very long and raises a lot more good points than I did above) was an awesome illustration of how engineering teams need to be protected and nurtured, especially in companies that don’t understand the culture.

That said, I think the posters focused too much on criticizing the premise of the question and didn’t do enough to acknowledge how critical good communication techniques are. But still, it was a valuable discussion!

So I went to the California DMV today

I defy you to get yourself juiced up on motivation. Buy a Toxin Flush from Nekter, put your noise cancelling headphones on, and listen to Tony Robbins or Les Brown or Zig Ziglar at full volume for three hours straight. Now spend 45 minutes in a California Department of Motor Vehicles office near South Central LA where I was today and just try to maintain your Robbins’ attitude. Just try.

You simply cannot do it. I’m not one to set limits, but you cannot maintain a positive attitude in that environment. Full stop. Period.

As you’re already exquisitively aware, the DMV is a beaurocratic machine finely tuned to suck every last bit of essence from your humanity. Sure the workers are pleasant and patient as they can be, but that just makes them more effective at their soul crushing task. You will walk out compliant and defeated.

Before I left for the DMV this morning, interestingly, I was reading a transcript from an internal interview on software engineering effectiveness and happiness. They cited last year’s paper On the Unhappiness of Software Developers.

One possible summary of that paper is that developers are unhappy in their jobs because of other people. They feel burdened by other peoples’ code, processes, meetings, personalities, etc., etc. They feel they lack the persuasive capability to influence other people and be the creative force that crafting code promises.

In my current role, I get to drop in on dozens of engineering and IT environments throughout the year, and I can feel it. It’s palpable almost everywhere.

The DMV is an extreme example, but it’s a useful bedrock baseline. At the DMV, you have zero power to influence anyone or anything. Less than that maybe. The rules are written in stone and interpreted by someone behind the one way mirror in the “Control Room.” Their SEIU employees have forgotten more excuses than you could possibly stammer to produce on the spot, and you are simply required to comply with all these other people’s requirements.

Your team’s culture is an order of magnitude better than the DMV — surely. But how many orders of magnitude? More pointedly, to what extent, as a tech lead, are you leaning toward or away from the a DMV-like environment?

I’m honestly not sure if I made my point very well here (especially since it’s a subtle one), so please hit me up in the comments and we can continue the conversation!

Strong Captains Created the Best Team Dynasties in Sports

What blogger worth his or her salt would pass up an opportunity to get a Super Bowl tie in? And I found a great one: surprisingly, it turns out having a great captain in a team is the most important factor in creating amazing sports teams — more important than star players or even coaches.

The captain on a sports team is kind of like a tech lead in an engineering team:

Not only must captains be competent in their playing, they need to inspire confidence in their players, evaluate the game plan and change it if circumstances dictate. They need to handle pressure well, make tactical decisions and communicate effectively with the referee as well as the team.

the-captain-class-sam-walker-3d-cover1-721x1024In last year’s The Captain Class, Sam Walker (sports editor at the Wall Street Journal) identified a list of 16 hugely successful teams across different sports. What he found was that it was usually due to the strength of the team captain, even as star players came and went.

He further broke down common traits into seven and drew some counter-intuitive conclusions:

  1. They took care of tough, unglamorous tasks
  2. Broke the rules — for a purpose
  3. They communicated practically, not in grand speeches
  4. They knew how to use deeds to motivate
  5. They were independent thinkers, unafraid to dissent
  6. Relentless
  7. Possessed remarkable emotional self-control

Engineering leadership is a bit different than sports, so personally I would emphasize numbers 1, 3, 5, and 6 as follows:

  1. Stay in the grind: effectiveness comes first from nailing all the little details, mastering the basics, the 5:00 a.m. runs when nobody is watching
  2. Stay tighly in touch: the most effective communication comes from staying very close to people, listening closely to their whole person (not just the facts). This is why Slack sucks.
  3. Be purpose driven. Sure you work in a team in a broader structure and context but if you don’t have a purpose or vision, what is there for anyone to follow?
  4. Grind it out. Seize every opportunity to do the best — every story, every feature, every bug, every, every, every.

Enjoy the game!!

Photo by JC Gellidon on Unsplash

Sorry for the radio silence

If you read, like I do, a lot of stuff about leadership, most authors seem to suggest that it will be “up and to the right” on the charts if you just apply yourself.

They seem to suggest that “leadership” is an inevitable outcome of following whatever advice the blog, article, book, podcast, seminar, conference, or Ted talk the speaker propounds.

My personal experience at trying to lead has been far, far more complex, frustrating, and difficult. I expect your experience has been as well. Yet, the reward is always out there and always seems worth the struggle.

If you were to chart my own personal attempts at leadership, I think they’d chart more like the Dow Jones Industrials over the past 150 years — lots of ups and lots of downs, sometimes big, sometimes small, but generally trending in the right direction.

Unlike the Dow in the past few years, however, the past few months for me have been some of the most challenging — so I haven’t had much time or energy for this blog.

I promise I’ll try to get back to it soon.

 

Tech leads today (Nov. 8, 2017)

Hey Tech Leads,

Thought I’d share some of the tech lead happenings out there on the web today. This morning, Kent Beck started with an interesting question:

What companies are doing the most interesting, innovative, visionary experiments in software engineering at scale—tools, process, organization, culture, growth?

It was an awfully broad question, so he didn’t really get much directly on point. In case you’re curious, some of the top responses include Google’s CRE role, any place that does Haskell, Menlo Innovations (the consultancy behind Joy, Inc.), the Medium engineering team, and Cognitect.

Another awesome tidbit crossing my radar was Eryn O’reilly’s intro talk on the tech lead role from last week. Good timing because I’m working on my own point of view on succeeding in the tech lead role. Her advice is pretty different from mine in its approach, but it’s definitely valuable.

Kind of directly on point to Eryn’s talk, if you listen to it, is a question that drew attention on the Stackexchange today. The poster is a tech lead and he’s concerned about an overbearing project manager….

In theory I think we should collaborate to get the best possible results by conversing our (potentially different) points of view. In practice he adopted a hard stance and wants to see some changes made without taking any input from me.

It’s a super interesting thread so I hope you’ll read it.

Finally, there was a thread I came across on Twitter:

Our Twitterer’s profound point was born out of something really mundane. There was something about an architectural choice in a Python project and she was arguing for human clarity over technical cleverness. I don’t really know the technical merits of the discussion, but the essence of her tweet is indisputable.

If more tech leads adopted @erstejahre’s point of view, we’d have happier programming environments to be sure. Debate me on this if you want, but I’m going to win 🙂