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!

An Introduction to Domain Driven Design

The PayrollHero offices are buzzing with new energy. This week, the entire team flew in from Manila and Whistler to Singapore and worked through two days of intense training on Domain Driven Design with Kiro Harada. After the rigorous learning retreat, the team emerged with renewed perspective and restless enthusiasm. In an endeavour to contribute to our community, we want to share with you what Kiro taught us.

The learning retreat was conducted by lean and kaizen expert Mr. Kiro Harada. Kiro flew in from Japan and spent time with us both as part of the workshop and to guide us after it.

Domain Driven Design is all about communication. The gap between what developers want to create and what stakeholders in the company understand can be massive, potentially detrimental to the company. Even between developers, it is hard to maintain a common language as domains grow larger. This makes it tougher to model a problem which leads to further miscommunication.

Blind men and the elephant

For you and me, miscommunication sounds like an obvious problem. But what does it mean in a tech company for people who are not familiar with domains and modelling? To give us an idea of what he meant, Kiro told us about the 5 Blind Men and the Elephant. Each blind man gets a part of the elephant: like the leg, the trunk or the tail. Individually, the blind men know everything about their allotted parts. But when they regroup, one man calls his part a tree, the other man calls his part a snake, and so on.

Different perspectives colour reality and computer programmes cannot distinguish between the two. So what can you do to ensure that everyone is on the same page? The solution to the Blind Men and the Elephant problem is for each blind man to observe his part, regroup, model (or draw) what they observed, go back, make observations and repeat the process till they finally put it all together. You collect information and switch positions to ensure that everyone’s perspectives are clearly understood. The idea is to move from a state of –

Not knowing what you don’t know (or alternatively, knowing what you know)

to

Knowing what you don’t know

DDD is intended to take you back to the drawing board, where you design incrementally. The model must constantly evolve – from building a scenario that describes a model which is written into code that creates new scenarios, and the loop regenerates itself. Exploring models with creative collaboration while consciously focusing on the core domain is what DDD helps you do.

ddd_graphic.001

DDD in Practice: Modelling a Vending Machine

The concept of DDD can be vague unless you put it into action. Kiro chose to do just that by splitting us into teams and giving us a problem to model. The only instructions were to code for a vending machine.

Round 1: True to PayrollHero’s style, my team decided to code for a machine that vends beer. We got down to writing all components involved in the machine: beer, a tray to hold the beer, a coin collection box, refrigeration involved (liquid nitrogen, of course), landing tray, the works. We then wrote down all the actions involved, inserting the coin, choosing a brand, waiting for the beer. Then we wrote down all possible scenarios: what if too many coins were inserted, what if the power ran out, what if the machine go stuck while vending the beer, what if the beer wasn’t cold, what if… and we went on and on.

Till Kiro came up to us and said our time was up.

We got no coding done. We barely opened a laptop screen. There was no product, just a bunch of ideas. Round one was an epic failure. We had a brief discussion on what to do. Kiro told us we needed to start small. Create a scenario, build a model, implement it and then go back to the drawing board to create another scenario.

Round 2: We needed a fresh perspective. We started from scratch, this time making sure that the developer in the room coded while we built the model. The process seemed slow but was far more efficient. Every non-developer would review the code to make sure everyone understood what was going on. When time was up we had our minimum viable product. By making our core domain small, we had a flexible model that we could work around. It was evident that Domain Driven Design helped us create our MVP within 45 minutes.

Timeboxing: The Bomb

In theory, DDD now seems like a simple idea. Even when you are modelling a vending machine, applying DDD to one problem is easy. What if you are dealing with 20 different problems at a time? Kiro showed us how multi-tasking can wreak havoc on a team. We were made to stand in a circle and pass around a “bomb” in alphabetical order. We were just getting good at it, when Kiro threw in another bomb that we were supposed to pass around in height order. A few seconds later another bomb was introduced that was to work its way around the group in order of birthdays. As you would imagine, we took ages figuring out how to pass three bombs around simultaneously. It was inefficient, messy and absolutely hilarious.

The idea of multi-tasking is just not sustainable. It wastes time and does not capture anyone’s complete focus. Timeboxing is far more effective. Getting work done one at a time allows you to apply DDD, keep everyone involved on the same task and thereby get everyone to focus their energies on a single plan.

Day 1 ended on a high note. Kiro threw ideas on modelling different problems at us and the developers enthusiastically practiced on them. The team was exhausted but an idea was borne out of a full day’s worth of training. We had big plans for the future, with new features in the pipeline.

Day 2 picked off from the previous day’s final tip – timeboxing. When you do tasks one at a time, it’s important to prioritize which feature from your backlog should be worked on. At PayrollHero, developers choose a bunch of issues and then vote on them. After ranking the issues, Kiro suggested we vet through what the problem really is before we go deeper into solving it.

Fact vs Opinion

Once you have identified a problem, it’s worth evaluating whether the problem is relevant or even real. Differentiating fact from opinion is another one of those obvious steps but everyone often misses out on it when you are deep into the process of solving a problem. It’s worth hitting the brakes and breaking down the problem and solution.

Problem Solution
Fact The problem should be based on solid data, maybe customer feedback or some other data analytics A solution that arises from analysing the facts of the problem. A quantifiable improvement is preferable
Opinion What the developers believe the problem is An opinion about the solution may be a source of new problems or ideas

Moving from the problem to a solution is what Kiro calls a Hero’s Journey. Using the facts of the problem, developers need to use their imagination to model the solution. The next step is to design the model and then implement the solution. Often the implementation brings up new problems and the cycle begins again. (If you were wondering, the name comes from the Star Wars protagonist, Luke Skywalker, who was faced with the problem of saving the galaxy, then he met Yoda, and finally used the Force to save Princess Leia and bring freedom and peace to the galaxy. Kiro is quite the sci/fi fan).

heros_journey_web_1024

This marked the end of the learning material that Kiro taught us. After this, we talked about models specific to PayrollHero and practised tackling them. An interesting exercise was to build a simple model, say a delivery system, and throw scenarios at it to see where the model breaks. The entire team enjoyed the brain teasers but more importantly, it helped us look at our product with fresh eyes and a different angle to approach our pipeline ideas.

The next few days are all about using DDD for some rigorous introspection and using the new learning as a foundation for future ideas. We also got the entire team to spend some time together with each other and our new interns. We went out for lunch, dinner and drinks. It was a great experience for both developers and non-technical members of the team. Overall, we learned that modeling can and should be used to make decisions, both for R&D and sales and marketing. It was not just about app development, it was a new way of thinking and building on ideas and executing them. While we are constantly improving our methods and changing our approach, we want the PayrollHero team to stay on their feet and continue being awesome consistently.


PayrollHero Team at Domain Driven Design Workshop Singapore

PayrollHero Singapore Payroll Team

Continue reading

Domain Driven Design Workshop by Mr. Kiro Harada

[Update] Here is the full recap from the event.

Next week is an eventful one for PayrollHero. All of our team is flying in from Whistler and Manila to learn more about Domain Driven Design (DDD). The workshop will be conducted by Agile expert Mr Kiro Harada.

What is DDD, you say? Well, let me have a go at it. DDD is an approach to software development where domain experts collaborate in order to place their primary focus on the core domain. Often, keeping up a unified, single model becomes progressively harder, leading to subtle differences between different groups of people. In simple terms: we’re trying to get everyone on the team to speak the same language.

If that sounds cryptic, that’s because I haven’t been to the workshop yet! (not for lack of trying to scour through Wikipedia pages to figure this out, I promise)

The workshop will be held on Tuesday and Wednesday (16th and 17th June). Mr. Harada will be flying in from Japan. After helping us Improving Scrum with Kaizen back in April, we decided to go a step further and do a 2 day workshop on DDD.

Stay tuned with our blog because we will be giving you a post-event breakdown soon!

Kiro Harada Workshop on Improving Scrum with Kaizen

Editors Note: Introducing Adam Baechler, Product Manager at PayrollHero. He will be contributing to the PayrollHero blog from time to time.

singapore kaizen workshop

(L – R) Michael Stephenson, Kiro Harada, Adam Baechler, Stephen Jagger, Piotr Banasik, Nico Suria and Vince Paca)

On April 14th I was fortunate enough to attend Kiro Harada workshop on Improving Scrum with Kaizen in Singapore. Kiro is an Agile coach and is super knowledgeable of agile principles and methodologies including Scrum, Kanban, Lean, and Kaizen. Kiro was also kind enough to stop by our office and give us a brief introduction into how he use Domain Driven Design (DDD) within his teams. You can find Kiro on Facebook or LinkedIn. (Kiro was gracious enough to visit the Singapore PayrollHero office the next day to do a private session with our team)

I been practicing scrum for about 3 years now so I found the discussions about Kaizen and Domain Driven Design from the last couple of days the most interesting. So I thought I would share quick summary.

Disclaimer: I’m new to this and I have yet to implement any of these teachings. So please do seek out the advice of experts like Kiro.

Kaizen

For those who have not heard of Kaizen, it is a methodology for continuous improvement. Surprisingly the Kaizen didn’t originate in Japan but in the United States during WW2.

The core principle is to make your work easier and safer.

When applying Kaizen to a process you can think of it in 3 phase; Fix the leaks, Make it flow and finally Create a new process.

Fix the leaks first. When you are working and you notice a process is not producing the desired results. Slow down or even stop so you can inspect the process. Focus on effectiveness not on efficiency. The goal here is to creating constant value from your process.

Make it flow. Now that your process is creating value constantly we want to make it flow by increasing efficiency without sacrificing the quality of your output. A great way to do this is through E.C.R.S. First try to Eliminate steps from your process. Next try to Combine some steps together. Next try to Rearrange steps in the process. Lastly, try to Simplify individual steps in your process. Never try to go faster in this process by following E.C.R.S you should accelerate naturally.

Once your process is flowing smoothly you should feel your work is easier and safer. Now is the time to dream up a new process that will deliver better quality and value.

As a scrum team we follow similar actions of inspect and improve through our retrospectives. however this is only done at the end of our sprints. I hope that our team can adopt the principles of Kaizen to apply continuous improvement throughout our sprints.

Domain Driven Design (DDD)

We only had a short introduction here but in that short time we saw the huge value of Domain Modeling. Domain Modeling is a great way to visualize your products domains, decide how they should interact and test out your logic before you build it out extensively.

At PayrollHero we are going to try to use the Domain Modeling technique to identify the Domains of our applications to create a better system architecture.

Thanks for reading. Drop any questions you have in the comments below.

(Some photos from the day with Kiro)

Kiro Harada payroll hero Kiro Harada payrollhero singapore

kiro kaizen singapore walking with Baechler kiro in singapore