Engineers: Four ways to increase your communication skills

Engineers are generally pretty good at communicating technical details of their work to other engineers, but things start to fall apart pretty quick when an engineer needs to talk to non-engineers about their work.

Over my career, I've learned how important it is to be able to communicate to non-technical people.  You have to be able to talk to product managers, sales staff, CEOs, CFOs and the like, in a way which clearly explains issues, features, and technology without loosing them in detail.  It's an important skill which takes time to develop.

Here is the key: great engineers know how to articulate technology vision, issues and details clearly.

If you want to take lead technical roles, you will need to know how to communicate to people.

So with that in mind, here are my suggestions for improving your communication skills.

(1) On a regular basis, explain to your significant other why what you do is important.  

Don't explain what you do, but explain why what you are doing is important.  The difference here is subtle, but crucial - you need to be able to explain to non-engineers what value you are adding to the product you are developing.   Do this on a regular basis.  If you are not used to this it can be really hard at first, but it is worth it.

Besides developing a better relationship with your significant other, you will learn to talk business value  about the technology you develop - a great skill to have.

(2) Give presentations.

Is there a need to update sales staff,  demo to a customer, or present a trade show?  Volunteer to do it.  At first it may be hard, but you get better at it with practice.  Talk to your manager and let him/her know that you want to present.  Solicit feedback on how you did.  Does your company offer classes or courses on presentation? Take one.  Another great place to present - user groups.  You can even look for non-technival venues to teach or present like your church or local non-profits.  The more you get used to being in-front of people the easier it becomes and the better you become at communicating.

(3) Listen.

That's right: to become a better communicator become a better listener.  When someone comes to see you at your desk, take your hands off the keyboard, and eyes off the screen.  Turn towards the person who is speaking to you and look at them.  Listen to what they are telling you - don't be raising ahead thinking about your response.  Don't interrupt.  

Again, for many people this is really hard to do and it takes practice.  In order to communicate to people you need to be able to listen, process, and understand what they are telling you even if you disagree with them. 

(4) Read the classics.  

I know, I know -  all you guys hated English and Chaucer.   That's not what I am talking about.  There is some really good stuff out there, so put aside your collection of Battlestar Galactica fan novels for a while.  The classics will not only help you see the world differently, but will dramatically increase your English skills.

I love science fiction and have probably read more of it than most people, but I also have grown to love the classics.  I have read almost everything by Dickens and have read all of Les Miserables by Victor Hugo (unabridged!)   I read them because I thoroughly enjoyed them, but I realized in the process of reading the classics that my command of the English language increased and I got a deeper appreciation of my fellow human beings.  I believe all this helped me become a better communicator and I believe it can help you too.

Adventure?  The Count of Monte Cristo by Dumas.
A cool story about over coming the odds against you? David Cooperfield by Dickens.
A story about pride, greed and good guys overcoming them? Daniel Deronda by George Elliot.

Give it a try.

-----

What about you, do you have any suggestions on how to increase communication skills?

Shine a light on software errors to increase quality

My team develops, tests and operates a fairly complex SaaS product.  We have customers who run their business on our product.  They pay us money and they expect it to work.

I am proud of my team - they deliver a high quality product.  We have a release every 10 weeks with minor point releases in between.  For a complex SaaS, we do a lot of releases.

I believe that the quality of the product you deliver goes up by not hiding errors.  In our application, every time user action generates an error, whether it is visible to the user or not, our application generates an email that goes to the DevOps team and myself.  Every time.  Very few of the errors block or affect user activity and almost all are recoverable, but we know they happening and then we look for patterns, we investigate and we prioritize fixing them.  If we believe a user is blocked or having trouble we reach out them and ask if we can help.

I am a big believer in exposing errors and bugs in a software application.  If your code is silently logging to some log file then you never know they are there, you may ignore them as "expected" and no one ever gets around to fixing them.

Here is a cool side affect of exposing errors - everyone becomes more focused and aware of them.  The QA team makes sure that we test thoroughly and known errors are captured.  The software developers want to make sure their code works - the quality of the entire applications goes up.

If you want to quality of your product to go up, put in mechanisms that expose errors that users are seeing to your technology team and make it clear that minimizing them is a high priority.

Jelled Software Teams

A truly jelled software development team is a beautiful thing to see in action. They talk to each other, not around each other.  They hold each other accountable.  They push towards a goal together.  They deliver very cool product that they are passionate about getting right.  They take pride in their work. They occasionally goof-off together. They have one goal, and they all know what that goal is.

If the team is functioning right, they care more about getting the product right for the customer than what an internal stake holder (like the CTO) thinks. They are willing to fight and standup for what they believe the right thing is to do. Like I said, it really is cool to watch these people in action.

But, here is the thing: not everyone recognizes that software development is a team sport, and as a result teams are often mismanaged.  Computer Science and Engineering degrees teach the discipline as a solo effort.  In college, you work on projects by yourself and rarely collaborate - and then when you get into private industry, you are thrown into a team to work on a product. Stake holders and senior management in many companies come from sales backgrounds, where they rise through the ranks competing against other people in their own teams, and generally struggle with what it means to build a well-functioning team.  People with accounting and liberal arts backgrounds might not get it get it either. Heck, a lot of technology leadership struggles with this too.

I could write a book on what it takes to build great software development teams (and some day I might), but if I could give someone some quick advise there two things: form small teams and lose the command-and-control leadership style.

Any software team with more than 3-5 people on it makes it difficult to jell. Meetings take forever, you loose track on who is working on what, and use loose some of the closeness that comes from working with a small group of people.  This small team is not a "chief surgeon model", where one person is the principle and everyone else is there to help him or her.  This is a team of peers where everyone has an equal voice at the table.

The right sized team is about 5 people and consists of 2-3 developers, 1 QA person and a product person.  A technology group may consist of many of these kind of small teams all working on different tracks during a release cycle to get something out the door.

To have strong jelled teams, you really have allow them function as peers to technology leadership.  In the 21st century, especially when dealing with knowledge workers like technology people, it isn't unusual for an someone to know more than their boss about something.  And, that is OK.  It shouldn't come as a challenge to authority, but should be encouraged. Mistakes will happen, but a good team will recover quickly and learn from them.

Some great benefits from jelled teams: they are happier, enjoy working together and deliver better product. Turn over and discontent also go down. People stop complaining to their manager and start talking to each other to solve problems.

It is worth the effort focus on teams.  Like I mentioned in a previous post, most teams have people problems not technology problems, and having jelled teams goes a long way to solving them.

Yes, Software Architecture really does matter

Software Architecture really does matter and, apparently, this is not a commonly held belief.

All too often, software developers are hired to "program" an app and get it out the door.  Bad patterns from previous gigs are carried over and perpetuated. Whatever technology leadership is in place just reacts to business pressures, and puts pressure on the team to deliver while trusting the developers to get the architecture right.

At some point architecture decay sets in, the code gets brittle, new features take forever to add, new hires can't really figure out the code,  the software gets bloated and runs slow, management gets frustrated and demands to know who is responsible, someone gets fired or quits, and new leadership is brought into "fix" the problem.  I've observed this pattern several times.

Here are my general guidelines for software architecture:

Don't be special!

Software architectures get into trouble when a couple of developers think they have a special set of problems and decide to be special in the way they apply well known patterns or technologies.  I've seen this many times, and have had to pay the price to fix it.  There is a reason why patterns develop over time, and why the community of developers apply something in a particular way.  Use the technology the way it was intended to be used. Otherwise, the next group of people won't understand your "special" techniques and you won't be able to upgrade or evolve properly and then someone will have to undo what you did. Don't be special.

Listen, pause, think, code, repeat.

Before you write the fist line of code, pause and think.  A one hour or one-half day discussion about where everything fits and what the proper architecture should be pays very large dividends.  Find an architect or senior developer, sit with them and bounce around ideas.  Look at what others have done.  Read articles, blog entries or books.  Avoid inventing something new, use something that already works.

Don't go dark

One of the worst things you can do when coding is go dark to the rest of your team.  You need to share and they need to know what you are doing (daily stand ups really help here).  Review your architecture and code with your team often.  Tell them what you are doing often. Keep running your ideas past them.  Doing all of this will minimize the chance that you will do something dumb.

Technology leadership should really lead

Software architecture should be a top-level item for technology leads and managers.  Talk about it, espouse it and be familiar with the architecture that the coders are developing.  Too often, technology leadership has no idea about the software architecture.  Some managers manage by Gantt charts and feature lists -  that's not leadership, that project management.  Lead and get in front of architecture issues. Make sure senior management is aware that this is important.  Add time to the project for it.  Schedule meetings to discuss it.  Give senior and lead developers time to address it.  

Seriously, architecture is important stuff.  Don't just hope it happens right.