Elon Musk on corporate communication

Check out this email from Elon Musk to employees at Tesla on communication within the company:

Subject: Communication Within Tesla

There are two schools of thought about how information should flow within companies. By far the most common way is chain of command, which means that you always flow communication through your manager. The problem with this approach is that, while it serves to enhance the power of the manager, it fails to serve the company.

Instead of a problem getting solved quickly, where a person in one dept talks to a person in another dept and makes the right thing happen, people are forced to talk to their manager who talks to their manager who talks to the manager in the other dept who talks to someone on his team. Then the info has to flow back the other way again. This is incredibly dumb. Any manager who allows this to happen, let alone encourages it, will soon find themselves working at another company. No kidding.

Anyone at Tesla can and should email/talk to anyone else according to what they think is the fastest way to solve a problem for the benefit of the whole company. You can talk to your manager’s manager without his permission, you can talk directly to a VP in another dept, you can talk to me, you can talk to anyone without anyone else’s permission. Moreover, you should consider yourself obligated to do so until the right thing happens. The point here is not random chitchat, but rather ensuring that we execute ultra-fast and well. We obviously cannot compete with the big car companies in size, so we must do so with intelligence and agility.

One final point is that managers should work hard to ensure that they are not creating silos within the company that create an us vs. them mentality or impede communication in any way. This is unfortunately a natural tendency and needs to be actively fought. How can it possibly help Tesla for depts to erect barriers between themselves or see their success as relative within the company instead of collective? We are all in the same boat. Always view yourself as working for the good of the company and never your dept.

Thanks,
Elon

(taken from Inc article here:  https://www.inc.com/justin-bariso/this-email-from-elon-musk-to-tesla-employees-descr.html)

 

As a manager I try to encourage this type of action with my team.  I don’t need to be ‘in the know’ of everything that is going on.  I don’t need to be spoken with first.  I’d much rather the employee to take direct action and ‘get things done’, vs. following a chain of command.

What are your thoughts?

Steve Jobs put on the spot, returning an insult

Check out this awesome video of Steve Jobs responding to an insult.  Well worth your 5 minutes.

I found this video to be fascinating and think it has several takeaways that all leaders should note:

  1. As a leader, you need to handle being put on the spot.
  2. Resist the initial emotional reaction.  Breath.  It’s OK to pause to collect your thoughts.
  3. Admit they are right.  Point out where you agree with the accuser.
  4. Steer the conversation to the bigger picture.  Why are we here in the first place?
  5. Acknowledge the hard work of the team.
  6. Admit you may be wrong, but that’s OK because decisions are being made, and course corrections will occur.

What I loved about this strategy is that it’s really hard to disagree with any of the points above.  You end up nodding your head and agreeing with him by the end, regardless of the original point being made by the accuser.  He ignores the personal attack and does tie his response periodically back to the original question.

Not bad for being put on the spot.

How to fire a Software Engineer

By far the hardest thing you will do as a manager is fire someone.  But you will need to do it.  There is no way around it.  If you want to be a manager, this is just part of the job.

I’ve discovered there are right and wrong ways to execute this.  I’m hoping some of the tips below help make the best of this difficult situation.

Continue reading “How to fire a Software Engineer”

10 Ways to use Confluence for Improved Communication

 

In Part 1 of this series, titled “How I converted my entire company over to Confluence, and lived happily ever after”, I described how I converted my entire company over to using Confluence, and saw huge gains in communication.  This was meant to be more of a general how-to article on migrating your company over to a new tool, rather than provide any info on the tool itself.

In this article, I’d like to go into more depth on how we’re actually using Confluence in my company.  I’ll also list the plugins that we are currently using.

Continue reading “10 Ways to use Confluence for Improved Communication”

Top 5 New Years Resolution’s for Software Managers

Funny-new-year-resolution-cartoon-500x318One thing I’ve noticed about being a software manager is that it’s a practice, not just a skill that is learned, like a new language or framework.  One of the challenges with the position is that you rarely receive any feedback on your performance.  I’ve reported to various CTO, CEO, and VP of Engineering roles over the years and have definitely noticed the lack of feedback.  It’s up to you to be self aware, recognize your blindspots and weak areas, and constantly work to improve them.  This requires a good deal of emotional intelligence.

The new year provides a chance for reflection, to think about how we can improve as people.  I’m always trying to think of how I can deliver more value in the office, what more can I do to help the team succeed?  I’ve boiled it down to my top 5 areas where I need to improve on in 2016.  Feel free to share yours in the comment section!

1. Be a Better Listener

This one sounds cliche, but being a good listener is probably the most important skill a good manager can have.  I always have to remind myself to be in the present moment when listening to a coworker.  Occasionally my mind will jump into problem solving mode, and I’ll start to zone out of the conversation.  Or sometimes I’ll just get bored with what I’m hearing and start thinking about something more interesting.

This year I want to get better at listening.  What is the other person really trying to say to me?  I’ll try to remember to repeat back what I’m hearing, to make sure the other person is being understood, and to force myself to stay engaged.  Also, I’ll try to see if there is any way I can help with whatever the other person’s problems are.

2. Give more feedback

I just got a new boss and noticed a technique he uses that has made a positive impression on me and I plan on using it more in the coming year.  He gives LOTS of positive feedback, I mean a ton.  He’ll quickly reply to an email with a quick ‘Thank You!’ or ‘Nice job!’.  It only takes him 2 seconds, but I’ve noticed myself now craving to get that positive response.  After receiving these for a couple weeks it finally hit me, I’m not giving my own team enough positive feedback!

As a manager you tend to see everything that is wrong and want to fix it.  There is usually so much bad stuff happening, it’s easy to forget to acknowledge all the good things that are happening as well!  I’ve already started to make a conscious effort to provide the team with more positive feedback, via email, 1×1, or in a group setting.  I’ve noticed that I need to make a conscious effort to do this.

In addition to all the attaboy’s, it’s important to give corrective feedback as well.  Also, it’s good to give this feedback immediately, don’t wait for your next 1×1.   I think it’s fine to give this feedback via email/chat as well as in person.  If your team knows they can get both good and bad feedback from their manager, they will trust you, and will feel more at ease knowing where they stand.

3. Clarify Team Goals

People want to know what the group goals are.  What are the near and long term milestones?  Luckily I work at a company where the founders clearly articulate the vision of the company, but how is my group helping to achieve that company vision?

Also, I will work to ensure everyone on my team knows what their priorities are.  I will have them tell me what their priorities are, so I can hear it coming out of their own mouths.  As they knock items off their list, I’ll work to give them feedback (see #2) on how they are doing.




4. Don’t get stressed

I tend to sweat the little things.  I tend to over analyze and dwell on what my boss or a peer said in a meeting.  I tend to get over competitive with my peers.

As a manager, you have visibility into so many things that are going wrong, it can be very easy to get stressed out.  This year I’ll work to live in the present moment and not waste time thinking about the past.  When things get overwhelming, I’ll work to prioritize, communicate them out, then execute.

5. Improve my technical skills

It’s so easy to get wrapped up in the day to day, meetings, email, etc.  Before you know it, months or years have gone by and you haven’t written any code or learned any new technical skills.

I try to mitigate this by first taking on jobs that are in new technical areas.  This forces me to learn some new technologies so I can at least be conversant.  However, once I have just enough knowledge, I tend to put it on the backburner and just focus on getting work done.

This year I’m going to work to be more hands on.  I’ll try to tackle a low priority coding project at work, something that has been bothering the team, but is off the critical path.

 

Honorable mention, #6, work on this blog some more.  🙂  These are my top 5 areas that I need to work on, what are yours?  Feel free to shoot me an email with feedback and also please join the mailing list to receive updates.

 

Promote Yourself

PromoteLike most, I first started in the software industry as an engineer.  I was taught growing up that hard work in the end will be rewarded.  My strong work ethic as an engineer resulted in me quickly being promoted up from individual contributor to team lead, manager, and then eventually director.

Then I noticed a big change.

When you are an individual contributor, you are often recognized by your peers and management for your contributions.  You are asked to complete a specific task or project, and the results are usually demonstrable and easily recognizable.

As you move up into management everything changes.

When you move into management, there are fewer people above you to recognize your contributions.  Oftentimes, your manager doesn’t understand the technical contributions you are making to the team, because they are non-technical.

Also, the role of a manager is much fuzzier.  How can you quantify if you were successful at motivating or mentoring your team?

When I first moved into a management position, I thought it was most important to focus on managing down.  My primary responsibility is to get my team to execute, right?

Well, that is only PART of the role.  The other part of the manager’s job is to clearly communicate up (your boss) and across (your peers) your personal accomplishments as well as those of your team.

You have to become a salesman!  This is not easy to do, especially for those of us introverted engineers.

You need to get out of your comfort zone!  Instead of spending your whole day with the team, force yourself to walk around the office and meet one new person a week.  Tell them what you do and what your team is working on.  What your challenges are.  See if there is any way you can help these people that you run into.  Are any of the projects or initiatives that your team is involved in relevant to this person?

When your team hits a big milestone, be sure to communicate it out to the organization.  Are the other dev teams aware?  How about the rest of the product group?  Promote your team to the organization.  Be proud of their accomplishments.  This is not slimy or devious.  This is basic business communication.

You need to do this, there is no choice.  If you don’t do it, no one else will.  The reputation of your team will suffer for it.  Your reputation as a leader will suffer.

And you can’t just promote your team, you need to promote yourself as well.  No one else will be an advocate for you, except you!

Some people do the above naturally.  I’d bet that most engineering managers don’t.  I know I don’t.  I’m still not good at doing the above.  However, I’ve seen other managers excel at this and reap the benefits.

Check out a book on this entire topic here:

How to have a successful 1-on-1 with your boss

1on1Ah, the dreaded weekly 1-on-1!  Do you get nervous leading up to your 1-on-1 with your boss?  Are you sometimes caught off guard or feel unprepared during the discussion?  Do you ever feel like the time isn’t valuable?

Here are some tips I’ve picked up over the years to ensure a successful 1-on-1 with your boss:

Before the meeting

  • Be prepared.  This meeting is regularly scheduled, and it’s important.  You have it every week so you know what it’s going to be like.  There is no reason to not be prepared for this meeting.
  • Give them a heads up.  If there is a specific topic you want to cover, give your boss a heads up a day or so beforehand.  This will give them time to think about it, rather than catching them off guard in the meeting.
  • Review the past week.  Spend 10 minutes reviewing what happened in your group over the past week.  I typically write down a bulleted list because my memory is bad.  Were there any production issues?  Be prepared to answer questions regarding any event that may have made its way to your boss via other channels.
  • No surprises.  Don’t wait for your 1-on-1 to let your boss know of any big or urgent news.  See this post for tips on managing production issues.

During the meeting

  • Be on time.  Your boss’s time is valuable, don’t disrespect them by being late.
  • Let them lead.  Even though you’ve come prepared with a list of topics and questions, let your boss lead the discussion.  Remember, people have their own agendas and interests.  If your boss doesn’t have any topics to cover then you can move on to your agenda.
  • Raise Issues.  It’s important that your boss hears about issues going on within your team from you first.  It demonstrates that you are the leader of your team and have things under control.  However, as mentioned above, you should be constantly in communication with your boss of any news on your team.  Use the 1-on-1 time to raise up project risks or other concerns, vs. news.
  • Listen.  Pay close attention to the body language and questions that your boss asks.  What is he/she really interested in?  Do they want a status update, or just brainstorm and bounce ideas off of you?  Let them lead and run with it, but find ways to weave in the questions you need answered.  If that doesn’t work, try to move onto your questions/issues after half way through.
  • Take Notes.  I find that I need to take notes in my 1-on-1 to ensure I don’t drop anything.  I usually bring a notebook to take notes vs a computer, as it demonstrates that you are focused on the meeting, and not distracted by email/chat/etc.
  • Learn their style.  You can learn so much from a person by observing their behavior in these 1-on-1 settings.  You should start to see a pattern emerge over a few weeks on what your boss likes to cover in these meetings.  If they are a seasoned manager they will be effective, but that won’t always be the case.  Use the ‘heads up’ before the meeting to ensure the topics you want addressed are covered.  Don’t wait for your boss to discuss your career goals, or potential growth opportunities, bring it up here.

After the meeting

  • Take Notes.  If you didn’t do so in the meeting, immediately afterwards jot down some notes from the meeting.  Pay attention to the topics that they raised.
  • Take Action.  Were there action items?  If so, make sure there is some progress on them by next week’s meeting!

Hopefully you find some of the tips above to be useful.  I’d love to hear other tactics that people employ to ensure they have a successful 1-on-1!

 

Firedrill! What to do when your production system goes down

There’s no worse feeling than when your production system goes down.  The business relies on your system’s availability.  Something happened, a bug, bad code push, a customer inserted crazy data, or whatever.

Now everyone is looking at you to fix it.  You are completely dependent upon your team, operations and engineering to come together, diagnose, address root cause, and deploy a fix ASAP.

Your ass is on the line and you are pretty much helpless.

What can you do to help?

Here are my tips:

  • Make sure you have the right people on the scene.  Have at least 1 engineer and ops person on the issue together.  Open a dedicated skype room or google hangout where information can flow freely.
  • Quickly assess the severity of the service degradation.
  • Notify your management chain, product team, and various other relevant internal stakeholders ASAP.  Be honest.
  • Provide cover for the team diagnosing the issue.  Limit distractions.
  • Get out of the way.  Your job is to ensure the right people are on the issue, and the org is up to date on the status.
  • Once the issue is identified and a patch is deployed, communicate out to the org what happened.
  • Afterwards, gather the team together and hold a quick post mortem to find out what went wrong.  Some key questions:
    • What services were affected?
    • What actually happened?
    • What is the root cause?
    • How can this be prevented in the future?  Is additional logging, instrumentation needed to diagnose the issue more quickly in the future?
  • Thanks the team for their teamwork, and quick resolve.
  • Send out a service incident report to the company that is transparent.  Describe the information gathered from the post mortem and explain it in simple terms.  Remember, the rest of the company wants to know that you have things under control, and you are taking the necessary steps to ensure it won’t happen again.  Most people understand that things go wrong and people make mistakes.

What other steps do you take?