Showing posts with label Communication. Show all posts
Showing posts with label Communication. Show all posts

Tuesday, April 29, 2014

All of It - It's All Been About Communication

Last night, my son was struggling with his homework.  He was really upset about it.  He kept lamenting, begging me to answer, "Why, why do I have to do this over and over again?"

What he was working on was a punctuation worksheet.  I think he was putting semicolons with conjunctive adverbs (e.g. however, therefore) and commas with coordinate conjunctions (e.g., and, but) and working to avoid the dreaded run-on sentences and comma splices.  He said they'd been working on them for weeks, and that he got them, but was sick of typing or rewriting the sentences because they're boring and repetitive.

He was lamenting rhetorically, of course, but an answer came to me so clearly that it shames me that it never dawned on me before.

The point of grammar...

The point of punctuation...

The point of handwriting and typing...

The point of spelling...

The point of literature and reading and interpretation...

It's all about communication.  That's all it is.  Boiled down to its basic, it's all about communication.  And you will, of course, look and me and say, "Well, duh, Batman... Of course, it's about communication."

But I never made the connection.

See, everything I learned about clearly communicating in my life came from self-help books.  "Getting to Yes", "How to Win Friends and Influence People", "Crucial Conversations", and "Year to Success" are a handful that come to mind.

None of them had anything to do with spelling and grammar.  None of them had anything to do with interpreting the works of Shakespeare.  None of them had anything to do with comma splices and conjunctive adverbs or future perfect tense.  Not one word was offered on how spelling well helps you communicate in the business world.

Yet that's what we teach.  Why?  All these rote rules and reading of "classic" literature all point me in the direction of one thing: we teach that way because it's easy. Now don't get your underpants in a twisty bunch.  I'm not bagging on teachers.  Well, not all of them.

They teach a discipline.  They teach what they're taught to teach.  They teach what they see.  They're not teaching the why.  Teachers may eventually (maybe) get around to teaching Critical Thinking.  For me, that class wasn't available until college.  But in my university, critical thinking was a separate course.  For Honors Students.  As if that's not the most basic course everyone should take before all others.

Why didn't we see that before?  How could this simple truth be so opaque to me?

Because so many teachers can't communicate.

Monday, March 31, 2014

Reporting Structure Matters

People don’t leave companies.  They leave managers.

I’d put that in quotes, but I can’t find an attribution.  It’s become such common knowledge, and it’s been written about so often, that I think everyone who is interested in employee morale and the benefits of keeping your good employees happy already knows this.

This statement really rings true for me.  But I don’t think it rings true the way that it’s often meant.  I think that when most people hear that, they picture an overbearing, boorish, emotional, or abusive boss, pointy-haired or not.  They maybe think of the condescending boss that uses this type of conversational antipattern.

Really, though, I’m thinking more about management structures today.  I think people are just as likely to leave management philosophies as they are to leave individual managers.  Sure, having a terrible supervisor has the potential to make every moment of your working life terrible, but the way organizations shift and rotate these days, having to report to a duff manager for a while isn’t really that big a deal.  Kinda like the old saw “If you don’t like the weather in <remarkable number of regions/cities>, wait 5 minutes and it’ll change.”

Bad management philosophy can break a company, one spirit at a time. 

And yes, in the past couple decades, we have seen the old command and control style of management from the industrialization era falter.  We have seen the rise of agile project management and lean software development.  We have watched with curiosity at the mounting evidence that waterfall-style management of software projects and programs does not take into account the pragmatic reality under which software is routinely delivered.

There are still lots of companies out there whose leadership hasn't received the memo on this, yet; mainly those whom were educated under the philosophies and by the leaders of the industrial era.  There are a lot of mid to large companies whose leadership hasn’t picked up a management book in twenty years, to hear people describe their environments.

I want to discuss a few things that I think would be massively beneficial to any company currently stuck in the old, rigid, empire-building, command and control management style.

Resource rotation

One of the big antipatterns I’ve seen in organization is resource-hugging.  That is, there are five developers on Team A and three on Team B.  Team B gets an organizational-critical project, which would really benefit from having another developer.  Let's say that no one disputes that Team B’s project is more important that Team A’s.  And let’s say that no one disputes that it would be a better use of company resources, even Team A.  What are the odds that Team A will lend Team B a resource?  Factoring in not only willingness, but also organizational red tape?  I’m guessing it’s close to zero.  Managers might like to think of themselves as working for the good of the organization, but silos and affinity can run deep.

Old-school organizations have a really difficult time with letting developers switch products and project managers, despite the positive benefits that come from such rotation.  Some inhibitors to this type of rotation include siloed teams not having similar enough processes, teams having completely different coding styles, needing visibility for annual performance reviews, and so on. 

More modern management philosophy suggests that rotation through projects, products, and managers engenders similarities of codebases, commonality of processes, and dissemination of knowledge.  It reduces the number of junk drawers in the organization, and limits loss of knowledge due to lossy transition plans.

Also, while this may be a post for a different day, I think there’s a huge case to be made for rotating your most senior IT leaders.  Especially in small shops where there are folks that have been there a long time, and have very deep relationships with the business.  Sure those relationships are optimized in a way, but they’re not optimized for global company benefit, and let’s face it, the whole company is what’s got to survive and thrive.  It does no individual silo any good to succeed if performance problems in another silo drag down the organization. 

Flat hierarchies

Another big no-no in modern organizations is the steeply peaked org chart.  While there’s some evidence that extremely wide spans of control (1 manager to 20-30 people) can get out of control, there’s also evidence suggesting that a company loses a lot of communicative efficiency when there are a lot of levels between the lowest-level leaf-node worker and the CEO. 

Having steeply peaked hierarchies leads to another big issue, and that’s one of throughput.  If an organization has a high management to staff ratio, it’s going to have a bottleneck.  Especially if there are non-people-managing project managers in the mix.  Each manager in the organization is given at least one project that is their top priority.  They may need a couple FTEs on the project and other ancillary folks.  With a steeply peaked hierarchy, there are not enough leaf-node workers to get everyone’s project done.  The managers then have the ability to say, “Well, I asked for some work to get done, but another manager’s project came first.”  In the worst case of this, the work is not prioritized actively and the whims of what the developers want to work on, or the manager that barks the loudest drives what the organization accomplishes.

It seems to me that huge efficiency that would accrue to any organization that would recognize the preceding and deal with their jelly layer (mainly by having a lower jelly to producer ratio).  Most organizations need more driven, informed individuals doing work, and fewer people arguing about why the work isn't getting done.  Scott Berkun suggests a great way to deal with the "too many chiefs" syndrome: innovation by firing people.  Seriously, if your organization is so top heavy that you've got more projects than people, start there.

I also am really fascinated with the holocratic experiment that Zappos is conducting right now.  I’m far from declaring that hierarchy should completely dodo, but I think current data suggests that flatter is better.  

On a side note, steeply peaked organizations with deep siloed hierarchies also really suffer when coupled with ineffective delegation.  Every level of the organization should maintain at least some spending limit that, below which, they have absolute authority to make a call.  A $30 software tool to improve developer productivity should not have to go all the way to a CEO or even the head of technology for a decision. Before you've even described the problem, you've already spent more of the company's money in wages discussing it.  When you don't have large enough spending approval limits low enough on the org chart, you can run into the longest delays for the simplest things, because validation has to make it through so many more layers of jelly.

A parting thought: one of the reasons that I've often heard for narrow spans of control is that the annual review becomes too hard to manage for one person.  This is a really bassackwards reason for having a peaked hierarchy, as it gutpunches you twice!  Peaked structures have awful consequences, especially coupled with inefficient delegation, and every time an organization narrows spans of control solely to participate in one of the worst business practices, an angel gets cancer. 

Differentiation between managers and team members

A manager cannot be held to perform the same tasks as their employees.  While managers may have come from the ranks of the individuals that report to them, and are invaluable in terms of providing overall direction, having a manager that currently performs the same tasks as their team members is a roadblock to innovation and prevents productive dissent.

Here's how.  Let's say two people are doing the same job, only one is manager of the group, and one is a team member.  If the team member has a difference of opinion with the manager, that team member has a limited set of choices: disagree with the manager publicly and risk getting reviewed poorly or being disciplined (in public or private), or play along and let a potentially bad decision for the organization play out for purely political reasons.  Bad things happen when team members are set up by organizational structure to compete.  You either end up with no innovation or people refuse to continue playing along and depart.

If two people are fulfilling the same role in the organization, they are team members.  If there's not enough management work for full time management duties within the group, consider making a team member a team lead for administrative purposes, but don't change that reporting structure.  That's poison in the morale well.  Pursuant to the previous point about flatter = better, be very sparse about where you decide to install organizational jelly layers.

Make sure the org change will be welcome

If you’re going to ask people to report to someone new, you should check with them to find out if there are any objections.  There’s nothing more impactful to productivity than an employee not respecting the person they suddenly need to report to.  This doesn't have to be a big formal ordeal; even something like, "I'm thinking about restructuring the organization so that you'd be reporting to <whomever>.  How do you feel about that?"  

Springing a restructuring on people is disrespectful and does not engender trust.  It makes it look as if the organization has something to hide, as if discussing it with employees beforehand would somehow queer the deal.  If it's such a great idea, it will be embraced.  If there's going to be a problem, you want to know that up front as an organization. Also, if you're going to lose people as a result (because people do leave managers), make sure they're people you want to lose.

This holds true for new hires, by the way.  I can't articulate how important it is for an incoming manager to meet the team they'll be working with, even if as a final "sniff test".  Too many organizations only have interviewees interview up.  In many modern business organizations, if they do reviews, HR requires 360 reviews.  It only makes sense to offer the team that you're hiring a manager for to meet the interviewee in kind of a 360 interview.  

R-E-S-P-E-C-T

The reporting line in the organization should form an unbroken chain of respect.  That is, anyone asked to support a manager must respect that manager.  If they don't, the entire organization suffers.  You can ask someone to report to someone else, but if they don't respect that person or their abilities, there's going to be trouble.   Lack of respect for someone the organization trusts to manage leads to lack of respect for the judgment of the organization.

The worst place that this lack of respect can show up is in promotions.  Everywhere I've ever worked, I've seen people promoted - not beyond their abilities, because sometimes you have to trust people to stretch and grow - but beyond their personal charisma and respect level.  Promoting someone who does not engender respect or trust forms a weak link in the leadership level. 

And respect is one of those things like trust that cannot be demanded - only earned.

Conclusions

Ultimately, a strong and confident organization puts leaders in place that engender respect, not through level or title, but through good decisions and good people skills.  Given that you can have leadership at all levels, consider policies that empower them to use their judgment for the good of the company.  And remember, because management != leadership, you don't have to have a million managers in your company to get a lot of great work done.

Sunday, March 9, 2014

You Should Leave Your Job

Here we are again.  I'm talking to you.  It's just us here, and no one is listening.  Clear your mind.  Take all your preconceived notions about what you were going to do today and toss them out the window.  What I'm going to say may shock you.

You should leave your job.  Soon.  I mean it.  Start looking today.

Look, you know and I know that life is too short to hate your workday.  Let's make a huge assumption: 8 hrs of work a day + 30 minutes lunch + 30 minutes * 2 for commute = 9.5 hrs of your 16 hour day.  That is 60% of your useful day.  If you eat or work longer or are further away from work, the numbers get worse. The numbers get better if you're willing to skimp on sleep for a longer useful day.

You know that every keystroke you give someone is a gift, right?  In this great presentation, Scott Hanselman suggests you check this out.  Are you giving the gift of your limited keystrokes to the right people?  For the right reasons?  Do those keystrokes match up with your values?  Are you giving gifts that others want and only you can provide or are you buying generic gifts that the recipient will ooze with "meh" over.

I've seen your situation before.  You're dark matter.  You're a 5:01 developer.  When you got to the organization you're in, you loved the first project you were put on.  You were hired specifically for that project, so it met your idea of what you'd be doing when you signed on.  You put in lots of time learning, showing people you were excited, showing you could be counted on to deliver.

You were enthusiastic.

But that was years ago.  That was a couple CTOs ago.  That was a couple technology strategy direction changes ago.  The organization has moved on and you've adapted to provide it value, but maybe your day-to-day is not what you wanted to do.  Shoot, it's a convenient commute.  The compensation's right.  Family health matters made it inconvenient to take on a change at that time.

You like what you did at the organization in the past, but now there's very little to do.  You're in maintenance mode for the product you were hired to build.  Management appetite for new development is nil because of cost cutting.  You've been told to keep the lights on.  Leadership doesn't want to spend time adding new features because they would rather buy a replacement system, but never seem to actually complete the research to buy that replacement, resulting in continued use of subpar tools, and missing opportunities to sharpen developer chops.

You're a developer, but because of "budgetary constraints", the organization is not allowed to staff a team that develops software appropriately.  So you are doing business analysis or QA, because there's no one in those roles.  In agile teams that's something that's expected of everyone, but your projects aren't agile.  You spend a lot of time writing up documentation that never gets used or read.

The excellent team you signed on with?  Excellent teams are an unstable equilibrium.  If you were on a tiger team of development that does everything right, did your organization split it up to "seed" the talent in multiple places, not realizing that it's the team that did things right, not the individuals?  Great people working on excellent teams get recruited to join other excellent teams.  So maybe your team fell victim to entropy.

So that team is no longer.  Maybe that was many reorganizations ago, before many different sets of leadership came in and tried to optimize output of a fixed group of resources.

Maybe your organization favors butt-in-seat over other productivity metrics.  For that reason, you can't work from home, contributing to that feeling of wasted commute time.  Collaborative technology is discussed, and maybe even experimented with, but because not enough people are using it, it's never optimized.  Time-shifting is not allowed to enable you to work at your most productive times.

Maybe you're on a support rotation.  That wasn't in the original sign-on agreement, but "You know... We all have to be team players", and you don't really mind since it's not all that often.  Although when it does, even though comp time should be an expectation, it's never discussed.

Yeah, maybe this describes your situation.  Maybe only some of it does.  If it does, however, you should leave your job.

But maybe you're not convinced to move.  You're too complacent.  You're comfy.  This job thing is a solved problem and you don't think you'll ever really need to look for another one.  You can coast out your career on your current skill set.

Maybe, but I've put together a few signs that it might be time to consider moving on.

Signs
  • Don't like working on what you're working on
  • Don't like who you're working with 
  • Don't like your immediate manager
  • Don't feel as if the discourse is civil or nonconfrontational 
  • Don't believe in management's vision or goals
  • Don't believe in your management's ability to make good decisions
  • Don't feel valued for your contributions 
  • Don't feel the tasks in front of you are very exciting
  • Don't feel focused enough on any one thing
  • Don't have clear reporting structures; have overmatrixed teams
  • Don't feel like your organization can prioritize
  • Don't feel like productivity is as important as appearance
  • Don't feel like the organization is moving forward quickly
  • Don't feel like the organization makes data-based decisions 
I read the following as symptoms of organizational dysfunction.  To change any one of these is like moving a cultural mountain and require clarity of vision and charismatic leadership from the very top.  I don't think that mid-level management in any organization can change these effectively.  If you recognize a lot of these, it may not be just your position in jeopardy; the whole company may be in trouble long-term.

Symptoms
  • Very peaked/deep org structures indicate a problem with reporting.  Need a low ratio of managers/doers.
  • Lack of information flow
  • Lack of recognition
  • Lack of celebration for hires or promotions
  • Lack of visible employee enthusiasm
  • Lack of unity of processes across divisions
  • Too many junk drawers 
  • Too much reliance on transition plans (which don't work) 
  • Lots of Not Invented Here silos of experience 
  • Headcount is kept flat regardless of technical investment or debt reduction 
So if any of this resonates with you, consider leaving your current gig.  Fast.  There is too much demand in the development industry to spend time in an organization where you're not happy.  Some organizations just don't get it, but there are plenty that do.  Find one and let the ones that do hire unenthusiastic, unmotivated shlubs to barely work until they go out of business or get sold to a competitor.

If all of this resonates with you, call a recruiter today.  Shoot, call me.  I know enough recruiters and folks at good places to be a good resource, and I'm happy to help you find your passion.  If you just want to talk, I'm here too. You'd do well to find yourself a mentor, too.

And if you're happy with your gig, good on you.  Come on out and be part of the community.

I just want you to be happy.  Yes you.

Tuesday, February 18, 2014

Something to Think About - More Communication Antipatterns

A while ago I wrote about a phrase that offends me deeply, the single word "just".  You can read about it there, but I came upon another phrase that really bothers me.  I've heard this type of conversation killer categorized into something called communication antipatterns.  That means, a pattern of speech people get into by habit, but are otherwise destructive.

"Think about that" or just "think about" are two versions of the same thing. I hear it all the time when discussing things with folks at work.  I've worked with people who would not only say this out loud without realizing it, but one former colleague would use it repetitively.  It was almost assuredly a nervous tic.  After almost any point he made, he'd hold out his hands and repeat, "Think about that!  Think about that!"

Insisting that someone "think about it" indicates to a listener that you believe that you have figured out some answer, that it is relatively obvious and requires few leaps of logic, and that if they simply pause and reflect on what you've said you will come to the same conclusion they did.  It implies to them that you've given it much more thought than they have, and that if they don't agree with you, thinking about the problem will bring them to your brilliant conclusion.

Here's a few problems I see with this phrasing:
  • The listener could feel as if they've thought about it a great deal, and they may have credible, serious counterarguments that you've just demonstrated you're not willing to hear by telling him that you've thought through all the angles.  Maybe it's you who haven't "thought about it".
  • You're being lazy in your argument.  If you say "think about it," you're trying to convince someone of something.  Don't take the shortcut.  That's how you get miscommunication.  If you have a good argument, spell it out.  It gives the listener a chance to disagree with your premises one at a time, without insulting them, and also may lay out something the listener hadn't thought of, possibly because of a legitimately unknown item.
  • You might be implying that the listener, even after having laid out all the facts, is incapable of putting things together.  That may be true, or you may not know what they know, but it is insulting either way.
"Again..."  Oooh, this is one I'm guilty of saying all the time, and I'm trying to break this habit.  If you call me on it, I might swear bitterly under my breath, but I'd be grateful for the help stamping out this offensive speech pattern.

This one implies that the recipient of the phrase is no smarter than a toddler who didn't hear you the first time.  It's not as offensive as some of these other ones, because it's often an acknowledgement that you know you're repeating yourself, but there's an implication that goes with it that's no fun.

Sometimes I use this even if I’m not reiterating a point.  That’s a horrible mistake to make because it makes the listener feel as if they have missed something, even if they haven’t.  Worse, it might imply that there’s a significant issue

"The smart thing to do would be...” – Oh my, I just heard this one last week.  If I had to specify one phrase that I think tore down more work relationships than any other and that contributed to significant team siloing, it would be this one.  There is no more directly backhanded way to deliver the message that the recipient is not smart.  This boils down to nothing more than “I’m talking to you and trying to present a solution.  It differs from yours, but if you were smart, you’d do this.”

No kidding, I’ve seen this one conversational antipattern delay and ultimately torpedo a multi-million dollar, multi-year effort because one key architect continually said this to one key IT project lead.  In talking to the lead, he said something to the effect of, “If that guy calls me stupid one more time…”

We’re all knowledge workers here, so our intrinsic value is in at least part derived from out intelligence and the solutions it generates.  These conversational antipatterns really tweak the heart of that.  It’s name-calling.  Subtle, but still name-calling.

And when was the last time you heard “Well, you’re a doodie-head!” in a meeting?  Good, then stop saying these things, too.

Again, the smart thing to do would be to think about that.

Dammit.

Tuesday, April 2, 2013

The Boredom Factor

I mess around on my cell phone.  A lot.  I’ve never been diagnosed with any kind of concentration disorder (ADD, ADHD or the like), but I always feel at least a bit distracted, and as a result, I often fidget by checking something on my phone.

So it’s not a bit surprising that when I’m in a meeting that has become tedious, or when I’m not directly involved, I mess around with my phone.  Sometimes I check the weather, or search for something that has just come into my mind tangentially related to the discussion.  And I don’t necessarily think this is a bad thing.

Other people have their own meeting coping mechanisms for dealing with tedium.  They daydream, twirl their pens, doodle, think about going home, think about next tasks or a meeting they have to prepare for themselves.  I think before I had something so easy to distract me, I did all things during meetings.

I actually used to get so bored in meetings I defined a metric that I call The Boredom Factor.  It’s defined as 
Where t = time elapsed before checking the clock for the first time and T is the total scheduled meeting time.

The closer the number is to 100, the more boring the meeting.  Say, for example, I look at my watch 10 minutes into an hour-long meeting (1-10/60)*100 = 83.  Pretty boring.  Contrast to looking at my watch 25 minutes into a half hour meeting (1-25/30)*100 = 17.  Not really that boring.

That’s right, I was so bored I invented a boredom metric.

So first things first.  I actually think I pay more attention with my phone out and on than if I were daydreaming.  With the phone taking up the “bored” part of my mind, it’s keeping me acutely there and in the room.  I’m not devoting 100% of my attention to the meeting topic, but I’m no longer ignoring it outright by daydreaming.  50% there is still better than 0%.  But still not the same as involving me and getting 100% of my time.  Oftentimes the distraction makes me feel more energetic and willing to contribute.

Realistically and practically, however, if I’m not 100% engaged in the discussion, then I’m being pulled out of it.

That is, if I’m in a meeting you’re running, and I’m on my phone, you can criticize me for being rude all you want, but the truth is that you are not engaging everyone in the room fully.  Consider turning the critical eye inward to see what might be keeping people from being engaged.  One of the following be the problem:
  • The meeting may not be focused enough – too many topics that not everyone is interested in. Are you just filling time?
  • The meeting has too many people – you may not need my participation the whole time. Could this meeting have been several quick short hallway conversations?
  • The meeting time slot is too long – you may be just filling up time when you could have made the whole process tighter. Are people showing up late? Are you prolonging the meeting because you have another stacked up afterwards and don't want to go back to your desk.
  • You didn't come with an agenda or a set of goals – I may not know where you’re trying to get to, so I’m biding my time until I hear that you’re finally on a track. Can you prepare better next time? 
  • People may be exhausted from too many meetings – meeting fatigue is real, and eventually people need a break. Too many mid-level managers do nothing but go to meetings all day every day. Are you contributing or creating that kind of culture?
Finally, I will leave you with the idea that respect is similar to attention, in that you need to earn it from folks.  If you are not getting mine, you should consider the possibility that you are not earning it.