Be a Better Manager in 10 Minutes or Less

managing-your-employees

Many would like to believe that people quit jobs because of greener pastures such as better pay and greater benefits. In reality, employees leave because of their managers.

Not convinced? Survey results by the market research firm Gallup released last April revealed that half of the 7,200 respondents left jobs “to get away from their manager.”

As a manager, you may have failed to realize that your small yet talented team of employees are walking out the door not to pursue fatter paychecks, but because of management.

Put simply, it has to do with you.

Such sobering statistic should be treated as an opportunity for small business managers to build a team culture of supporting one another. Like most relationship issues, there is no one-size-fits-all formula to becoming an excellent manager.

The following tiny, yet meaningful gestures can certainly make a difference though. The best part is you can do them in 10 minutes or less!

Call everyone by their first name.

In this book How to Win Friends and Influence People, Dale Carnegie wrote:

Remember that a person’s name is, to that person, the sweetest and most important sound in any language.

Likewise, social experiments proved that calling people by their first name makes it more likely for them to comply to your requests.

Make an effort to get to know everyone in your team. Your employees are humans too. They have lives outside of work — they have a family that they deeply care about or hobbies and interests that keep them busy outside the office. Take the time to figure these things out and greet them by their first name the next time you are in the office. By doing so, you build rapport that will eventually lead to trust in the long run.

Dig deeper into each employee’s resentment.

Most employees have their own version of what they are currently bitter about in their jobs. For some, it’s working extra hours and not being able to spend dinner with their family. Or missing a few drinks with friends every Friday night. Perhaps, it’s the lack of flexible hours within the workweek.

It varies for everyone but the takeaway here is to check on these resentments regularly. Subsequently, ask your employees about an activity outside of work that they consider important and pry them for possible solutions (they can extend work hours the next day, shorten lunch breaks for a couple of days, or ask someone to cover for them temporarily).

Doing this quick exercise will prevent resentments from evolving into a full-blown mess of hatred and bitterness.

Ask your employees for advice.

Ha! Why would a manager do that? Isn’t it supposed to be the other way around?

Social psychologist and author of Influence: The Psychology of Persuasion Robert Cialdini offers one seemingly counterintuitive yet effective suggestion to making your employees like you: Ask them for advice. This could range from personal advice like book recommendations to professional advice such as asking their opinion about social media platforms that they deem are ideal for your digital marketing campaign.

By and large, this gives the impression that you, as a manager, value their opinions. Bonus points if you follow their advice and update them that you’ve done one of their suggestions!

Provide specific compliments and insert a negative comment in between.

The keyword here is specific. Sure, it’s easy to give out praise. “You’ve done a great job” or “Keep up the good work” are nothing but empty words of encouragement. Go out of your way to specifically determine the things that each employee has done well. Sincere forms of recognition are always appreciated.

Additionally, don’t be afraid to give out constructive feedback when an employee is obviously off track. In this Harvard Business Review article, the authors talk about the ideal praise-to-criticism ratio:

The average ratio for the highest-performing teams was 5.6 (that is, nearly six positive comments for every negative one). The medium-performance teams averaged 1.9 (almost twice as many positive comments than negative ones.) But the average for the low-performing teams, at 0.36 to 1, was almost three negative comments for every positive one.

The key point is to keep your negative comment as objective and rational as possible. Furthermore, consistently giving compliments ensures that you are within the ideal 5.6 to 1 praise-criticism ratio.

Offer one thing (no matter how small) to help an employee achieve a personal long-term goal.

Everyone has their own set of side-projects, long-term goals, and bucket lists. Say one of your web developers has been thinking about learning Python. Or someone from your sales team is keen about filling in one of the graphic designer posts.

Every so often, employees are interested in upgrading their arsenal of skills or learning things outside of their expertise. Why not do one thing to help them achieve these goals?

Offer to shoulder half of the paid online Python course to the web developer. Or ask the sales rep if he would like to shadow one of the designers for an hour each week? These little things will keep your employees motivated. The more they’re excited about their work, the greater the chance that they’ll work hard for you.

Final Thoughts

Tiny acts of appreciation and kindness are often overlooked, yet they have the biggest impact to becoming a better manager. Put them into action today and see what happens next.

Tell us about the results in the comments or join the conversation on Twitter!

Faster CI – Our Journey To Halving Our Test Runtimes

Warning, this post is a bit technical.  🙂

[Editors Notes] From time to time our engineers take a moment to write a post for our blog. From Adam our product manager writing about Scrum and Kaizen to Piotr writing about our Engineering Best Practices there is lots to read.  Vince has written on the blog before, his last post was about Adventure Engineering in Da Nang, Vietnam. Today, Vince thought that what he has learned about reducing our test runtimes might be helpful to startup community. Enjoy.

One of my biggest challenges for the past few weeks was to get our tests to complete within 10 minutes.

That doesn’t sound so bad, does it? There’s just one tiny detail which would make this journey all the more exciting: Our code takes 25 minutes on average to complete on 25 parallel build servers and It takes about 4 hours if you run it in one.

I made a quick survey with our engineers and we lose roughly around 3 hours per day waiting for CI to finish.

The plan was to selectively run tests and have cucumbers run only on specific branches — epic, develop and master. This means that every time something gets merged to those branches, cucumbers will run after rspecs. And of course, all this will run in parallel on 25 build servers.

How our code tree looks like:

|- master
|- develop
   |- epic/adding-a-thing-with-stuff
      |- feature/with-things  
      |- feature/with-stuff
   |- epic/the-thing-you-do
      |- feature/bla-bla-bla

We didn’t have a way to execute this plan with our current CI solution at that time so we had to find alternatives. We tried quite a few but most of them were either had limited features or were just simply too hard to get started.

Enter Codeship. It took me no more than 3 minutes to get my first build up and running…and of course, failing. Getting started with their ParallelCI wasn’t that hard either. How you configure your builds opened up a ton of possibilities including selective test runs.

To make our tests parallelize (is that even a word?) I had to use this neat little gem called parallel_tests.

Getting started with the gem is simple. You can execute a group of rspecs like so:

bundle exec parallel_test spec/ —verbose -n $TEST_GROUPS —only-group $TEST_GROUP —group-by $TEST_GROUP_BY —type rspec

$TEST_GROUP is an ENV variable that I set on each pipeline. Basically just the number of the pipeline. $TEST_GROUPS is the total number of parallel pipelines. This is 25 for us. $TEST_GROUP_BY is how we group our tests and that would beruntime for us.

That is one other thing you can do with parallel_tests is group by runtime information. Using this grouping took 2 minutes off of our test runtimes. Getting logs from parallel pipelines was a little bit tricky so I had to do a little scripting magic to gather logs from multiple pipelines and concatenating them back together.

It’s simple really, in the setup section I have two scripts: one to upload each log slice to S3 and the other to download the logs and put them together.

Links for reference, apologies for the terrible naming: – ConcatenateUpload

Now that the runtime logs are covered, it’s time to make the tests work. I have this bash script in our code:

#!/bin/bash

bundle exec parallel_test spec/ —verbose -n $TEST_GROUPS —only-group $TEST_GROUP —group-by $TEST_GROUP_BY —type rspec

if [[ “$CI_BRANCH” =~ .*”$BRANCH_FOR_CUKES”.* ]] || [[ “$CI_BRANCH” =~ .*”master”.* ]] || [[ “$CI_BRANCH” =~ .*”develop”.* ]]
then
  echo “Running Cucumber…”
  bundle exec parallel_cucumber features/ —verbose -n $TEST_GROUPS —only-group $TEST_GROUP —group-by $TEST_GROUP_BY —type cucumber || true
else
  echo “Not running Cucumber”
fi

Conveniently, Codeship has a bunch of ENV variables set inside test instances and one of those is $CI_BRANCH. I just simply check if the current branch running in CI matches either master, develop or what I configured in the settings, it will run Cucumbers after RSpecs.

Finally, this is what our setup and pipeline configuration looks like:

codeship vince paca

This entire approach got our RSpec builds down to an average of 6 minutes and our entire suite to 13 minutes from 25 minutes.

Huge props to the Codeship team for helping out with the transition and thanks for the swag! 🙂

Editors note: This post was originally published here.