Sunday, 26 January 2020

Are Your Policies Hindering Profit?


Many companies believe that working staff as hard as possible will get them the best result (profit). Nothing can be further from the truth. In fact, the wrong policies can result in habits and processes which are detrimental to people and the organisation.

In this article I will discuss how your policies (or lack there of) might be hindering the profit of your organisation.

Productivity vs Utility

As a manager, my main objective is to maximise the productivity of my staff. Many managers confuse productivity with utility. Let me explain...

Many managers and organisations believe that working staff as hard as possible will get them the best result. This is the idea that utilisation of people's time, at maximum load (& stress levels) will ensure that their output is at peak velocity. This is a fallacy, and actually results in quicker burnout, and reduced productivity over time.

We are all familiar with the idiom "The straw that broke the camel's back". You burned out the camel very early, so it could no longer work. A better approach would have been to only half load the camel so that it can work indefinitely.

Simple process changes can result in reduction of load, while also increasing the team's overall output. So, my advice to all managers is to seek to reduce load (utilisation) of your staff, while maintaining/increasing output.

One easy way to start is to ask your staff: "What can I do to help make your job easier?"

Overworking Hinders Profit

Overworking your staff actually hinders profit in the medium to long term.

When staff are overworked:

  • More mistakes occur
  • Quality of work reduces
  • Velocity (productivity) is reduced
  • More sick days are incurred
  • Morale can be affected (hence wider spread reduced productivity)
These are known facts. Falling quality & productivity result in reduction in your overall profit. Moreover, the more you overwork your staff, the higher the likelihood that they will leave the company.

Logically, it is important to have HR policies which ensure that staff members are not overworked. One way to measure this is by a quick survey where staff rate the work-life balance (eg. 1-5). If your organisation rates lower than 4/5, then it is highly likely that your staff are overworked, and your profit is suffering.

Staff Churn Reduces Quality

It is very difficult to maintain quality when good staff leave. The cost of good staff leaving can be very hard to measure. I will attempt to explain...

When a good staff member leaves a company, they take with them a lot of knowledge and good habits. The remaining staff will often not operate as efficiently without that good example in house. They will often even develop suboptimal habits and processes because they do not have the experience or knowledge. Your quality and productivity are likely to fall. The greater the churn of good staff, the more pronounced this effect will be come.

Often good people leave due to frustrations with processes, being overworked, or even because they don't like their manager. The best thing you can do is look at why these people are leaving, and address the root causes. 

Training New Staff

When staff leave a company, the existing staff need to train the newcomers. This reduces the productivity of the existing staff.

Imagine the following scenario:
Alice is an existing staff member
Bob is a new staff member

Since Alice needs to train & mentor Bob, her productivity will be reduced for at least 3-6 months (depending on many factors). In my experience, assuming Alice is a good mentor, her overall productivity would be reduced by at least 20%.

Since Bob is new, his productivity will initially not be as high as Alice. In my experience you cannot expect more than 50% productivity from Bob for at least 3-6 months.

Staff churn reduces productivity for existing staff for several months, while they help ramp up productivity of the newcomer. This is basically unavoidable. There are ways which you can help make the process smoother, however it is much better to address the root cause of why people are leaving in the first place.

In IT it is common for people to change companies every 2.5 years. If you can modify our processes and policies so that staff are retained for 3.5 years, then the cost of training can be drastically reduced.

Management Concepts

As a manager, your job can be summarised in 2 simple questions:

  1. What can you do to maximise productivity of your department in the medium to long term (without burning them out)?
  2. What can you do to retain staff as long as possible (hence reducing churn & saving money in the long run)?

For me, the answer to these questions is another question...
What can I do to increase happiness in my department?

Increasing happiness is not as simple as free breakfast, and vodka shots on a Friday. I will elaborate further in a future post.


Mental Health In The Workplace

Mental health is an issue which needs much more attention. Managers need to be increasingly aware and diligent in addressing problems. When people are under too much pressure, then all types of behavioural problems can manifest - both at the individual and at the team level. Productivity and quality can suffer.

I recently stumbled across a company called Unmind. This is a startup which seeks to improve mental health in the workplace. I think this is a great initiative, and one of the cofounders is a clinical psychologist. They rate 4.9 on Glassdoor. I hope to hear more about their success stories.



Final Thoughts

I hope I have given you some food for thought when it comes to your organisation's policies. To maximise productivity of teams, Managers really need to take a step back from the ideas of utilisation. The camel can only take so much!

I hope I have convinced you that overworking people really does reduce your company profits, due to reduced quality & productivity, and also the cost of churn.

If you are serious about improving your organisation, please consider staff happiness first. Unmind is a company that can help you do this. Happy staff leads to better outcomes, and hence more profit!





Sunday, 19 January 2020

Are Your Project Budgets Hindering Success?

I have worked in various companies over the years. Small to large, integrated, and pure development houses.

I have seen the transition from print to digital in various organisations, and all the practices which kind of make sense for print, but are disastrous in a digital setting.

In this article I'm going to discuss project budgets, and one undesirable behaviour which can manifest in your organisation.


Project Budgets

It should go without saying that projects should be profitable. That's business!

In a traditional agency, chunks of money are ring-fenced to pay for people, and materials. The revenue needs to be higher than the cost (obviously).

The Budget Statement: 
ALL projects must be profitable

As part of this, common thinking is that the combined wages of workers on the project should be low enough so that the project remains profitable. This might mean using mid-weight or junior workers rather than seniors or contractors. That makes sense right?

In the following examples, I will be talking about contractors as they cost a lot more than internal staff, so the effects on decision making are more pronounced. However, the concepts also apply to internal staff due to wage differences of skill levels.

Project Contractors

It is extremely common to hire contractors for the duration of a project. These may be copywriters, designers, project managers etc. Basically whatever the project needs.

There are cases where the project budget is relatively small, which means contractors are not affordable within the project budget. Therefore internal staff are assigned as they are cheaper. This principal applies also when choosing a mid-weight or a junior over a senior, as the senior has a higher wage. This makes total sense right?

So some projects simply do not have budget for contractors. Refer back to the Budget Statement, that ALL projects must be profitable.

On a side note: There are various problems regarding reliability, quality, and consistency of contractors, but that is a topic for another time.


Budget Thinking That Hinders Success 

Imagine 2 available designers:

  1. Agnes - An in house senior designer, who is top notch
  2. Barry - A contract designer with far less experience than Agnes, who costs the team/organisation more than Agnes because he is a contractor
The team/organisation has 2 projects which will run in parallel:

  1. Project A
    • High profile
    • Requires a top notch senior designer
    • Has a high budget (can afford a contractor). 
  2. Project B 
    • Low profile
    • Can have acceptable results with a someone less experienced
    • Has a low budget (cannot afford a contractor).
In a traditional agency, the organisation will just run the numbers:

  1. Project A 
    • Can afford Barry, even though he is not as good as Agnes
    • Reluctantly assign to Barry
  2. Project B 
    • Unable afford Barry
    • We must assign it to Agnes to stay within budget


Obvious Risk

In the previous example, I hope you have noticed that putting Barry (with less experience) on the high profile Project A is highly risky. You could end up delivering something below par which can result in losing the client entirely.

But you were forced to stay within budget! The budget forced you to deliver low quality for your client. This is very sad and disappointing.

This is an interchangeable resource fallacy. People are not interchangeable due to various reasons. This may be skills, experience, knowledge, velocity. I can't count the times where the wrong people have been put onto projects.

Note: I'm not talking about errors such as wrong event dates. I'm talking about quality of work.

Can you think of any projects/clients who have suffered due to this type of budgeting?


The Optimal Solution Breaks The Rules

In the example (above), we saw that putting the wrong person on a project can lead to poor results for the client. The client may even decide to leave you.

Breaking The Project Budget

If you only consider the success of both projects, then you are probably thinking that the solution is obvious:

  1. Project A
    • Assigned to Agnes
    • Will be a success 
    • Will be profitable
  2. Project B
    • Assigned to Barry 
    • Will be a success
    • Will not be profitable

This solution breaks the rule that "ALL projects must be profitable", however the solution ensures that both projects are a success. If both projects are successful then the net result to the team/organisation is the same!

The Cheeky Solution

It is worth mentioning that there is a solution which gets around the budget constraint. Basically all you need to do is cook the books.

On paper:
  1. Project A
    • Assigned to Barry - However Agnes is REALLY doing the work
    • Will be a success 
    • Will be profitable
  2. Project B
    • Assigned to Agnes - However Barry is REALLY doing the work 
    • Will be a success
    • Will be profitable

Ideally you shouldn't need to do this, but it is a workaround which I'm sure many teams/organisations will do. However this essentially means that you are lying.

Another Solution

If you take a more holistic view of the team/organisation finances, you will see that the cost and revenue (in the above solutions) is exactly the same. Therefore the net profit across both projects is the same.

Consider your staff (mix of fulltime and contracts) as a single pool. Now you have an average wage cost, and you can budget accordingly. Sound simple? That's because it is!

By taking a more holistic view of your organisation (not just projects in isolation), there is higher chance that the you will be more successful and profitable in the long term. This in turn improves profitability.


Project Problems In A Digital World

As we saw above, a poor resourcing decision can lead to poor results, and even loss of clients. When you translate this to digital projects, these problems are amplified, made more frequent, and even more reputation damaging.

Let me explain...

Some print projects can get away with being below par. Often an ugly design can still arguably be used - Yes this is an over simplification, but I hope you get what I'm saying.

A crashing website is of absolutely no value, no matter how many lines of code were used to build it. When a website is made badly, it can be unstable, crash, and even loose money. 



Final Thoughts

I hope I have convinced you that project budgets do not work in the way you hope they do. When constrained by the edict that "ALL projects must be profitable", then the organisation will likely develop habits of making sub-optimal choices, which can be devastating.

Often, it is not just as simple as resourcing according to budget. The right person may cost more. However, if the alternative is the risk of a failed project, then shuffling people around is the only option. This of course can break the rule that "ALL projects must be profitable". You may decide to cook the books to say that a contractor is on the project that can afford it. You won't be the first to actually do this.

You may even decide that it is acceptable "on paper" that some of your projects will be unprofitable, so that all the projects can succeed. Another solution is to consider your staff (a mix of fulltime and contractors) as a pool. This means you have an average cost per head, and you can now budget accordingly.

I hope I have given you food for thought. Take a step back, and start looking at project success across your team/organisation, not just projects in isolation. Take a more wholistic view of profit across the team/organisation, not just individual project profit.





Saturday, 18 January 2020

Happiness and Management

Prelude

In the distant past, I remember having a conversation with one of the people I managed. They were unhappy about various aspects of their job, the company, etc.

I told them that if they were truly unhappy, then they should leave.

Let me explain...

Why Are You Unhappy?

There are various reasons why a person is unhappy in the workplace. Workload, frustrating processes, unenjoyable types of work, and conflict are all common complaints. But those things are relatively easy to fix, so what else is there? It can be very hard for people to open up, and getting to the root of the problem is sometimes not possible.

During the conversation we discussed that there is no perfect job or workplace. All companies have inefficient aspects to varying degrees, and there is always some boring mundane work to do. Everyone has different likes and dislikes, and for many people there are some deal breakers.

Perhaps other people like the company, but it's just not right for you. That's fine. You don't have to like everything that other people like. What you bring to the table is individuality, and ideas. You are allowed to be unhappy even when other people are laughing.

Happiness Is More Important Than Work

Happiness is more important than any job, and I don't want people who work for me to be unhappy. The happiness of my staff is more important to me than the work they do for the company.

I told them:
If you are truly unhappy in your current position, then you should leave. However, before you make that decision, I want you to try to think of ways that we can make things better. If after trying to make things better, you still feel the same, then I support your decision.


Final Thoughts

As a manager, the happiness of your staff outweighs all other priorities.

Stepping into a management role sometimes means that you need to shove your business goals and smart objectives to the side, and just be an unbiased friend.














Wednesday, 9 October 2019

Class Name Suffix Wheel Of Fortune

Hey developer!

Do you find it hard to name your classes?

Perhaps you have a seemingly large number of services, or helpers. Not everything can be a service or a helper right?

If this is a problem you can relate to, then I have the ultimate tool for you!

The Class Name Suffix Wheel Of Fortune

Just spin the wheel, and you'll never need to worry about your class name suffix ever again!




ps. Once you're done having fun, go learn some software architecture to avoid these useless suffixes in your code :)

Tuesday, 10 September 2019

Good Help Is Hard To Find - Tips When Hiring Remote People


Good Help Is Hard To Find.

This is the eighth in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology.

Introduction

Are you hiring remote developers? Your decision to do this might be due to cost (to save money), due to local skills shortage, or when you absolutely must hire a specific person and are willing to let them work remotely.

When hiring remote staff members, you need to keep in mind that it will not be as smooth as you might think. Humans are fascinating when you put them in different scenarios, and some people who were fine to work with in an office might not cope well when isolated.

In this article I will present a few of the challenges I tackled when dealing with remote staff members.

Issues

Isolation

Remote staff members are isolated. They miss out on important information. They are not privy to cross-desk small-talk and banter. They definitely are not able to go for lunch with people. We all need the company of other humans.

You really need to figure out ways which you can help your remote staff feel like they have real human contact.

Limited Communication

In a physical office situation, staff members will interact at some point during the day. When you have remote people, this does not happen. Most of the time you only have the remote people interacting with their current project team, and sometimes just at a daily scrum. This is not much communication, and many people might not get the information they need to do well in their jobs without those extra office side-chats.

Quality & Performance 

When developers help each other then they will come to a consensus with their approach. They come to a solution more quickly, and there will be less bugs. The opposite is often the case when it comes to isolated developers.

In my experience, remote people are far less likely to ask for help. This has a knock-on effect of their quality potentially going down, as well as their speed.

Second Class Citizens

It's very easy to get in a habit of treating remote people 2nd class citizens. I have seen this in various companies, and decided very early that we must replicate in-office communication as closely as possible.

Tips to Improve Communication

Video

Have you ever joined voice-only conference calls. They really suck. They really do!

Being able to see a person's face is very important. It makes the calls quicker and more efficient, while also giving you all a more human interaction. Slack conversations and email have their place, however they can take way too long. So I favour video as much as possible.

Tip: My top tip is to use always use video for all meetings and discussions. There are plenty of tools out there. Zoom is my preferred choice. There are other good options such as Slack video, and Google Hangouts.

Frequent Rituals

My most distributed team consisted of 2 offices and 4 remote developers spread across 3 countries. Very early on, I introduced daily all-dev standup where devs would talk about what they were doing, and would ask for help if required. Arguably, this might not significantly serve the projects in the short term. However, the interactions each morning did facilitate knowledge sharing across all devs. It was a great start to the day, and I personally really enjoyed the feeling of seeing everyone each day.

Tip: Strive for some sort of group interaction which can mimic a physical office environment. Make it frequent, and at least once per week.

Encourage Remote Questions

Remote developers do not have much interaction during the day when compared to developers who were sitting at the same desk.

I encouraged developers to avoid asking questions of people who were physically in the room. I told them to ask the remote developers were possible, as it would encourage them to do the same.

This dramatically increased the amount of communication. While this might sound a little inefficient at first, in the long term the communication tightened up, and video questions became the norm. Quality of work and happiness of remote developers increased as a result.

Travel

When I started to take on remote staff I insisted that they come to the office as often as possible. For people in the UK it was around once per month for a couple days, people in other countries around once a quarter. This is obviously an extra cost to the company, however the improvements in team bonding and efficiency are totally worth it.

Tip: Get your remote staff to visit the office as often as possible.


Final Thoughts

The world is modernising where people can work from anywhere. You need to be extra diligent when it comes to care for these staff members, as you can't actually see their physical conditions, and you have far less contact with them.

Video calls are critical in helping people feel less isolated, and you must develop daily and weekly rituals to keep the remote people engaged and in the loop. Encourage your office staff to engage frequently with the remote staff, and definitely try to have your remote staff travel to physically engage with everyone else.

I hope you found this article helpful.



Posts In This Series

  1. Interview Tips for Technical Leaders
  2. Tips To Ensure Quality Delivery When Outsourcing
  3. Tips When Taking On An Intern
  4. Tips When Hiring Senior Developers
  5. Tips When Hiring Junior Developers
  6. Tips When Offshoring Development Teams
  7. Tips When Hiring Digital Producers
  8. Tips When Hiring Remote People
  9. Tips To Improve Developer Retention (coming soon)
  10. Tips When Hiring Lead Developers (coming soon)











Saturday, 7 September 2019

Billing - A Better Alternative

Introduction

When I was Head Of Development at The Cogworks we originally tried to bill by the 1/4 hour. It was insanely granular and cause many undesirable side effects and habits. Even if we rounded up numbers to meet 7hrs per day, it seemed that projects were just not profitable. It was quite hard to get my head around it, but much of this was because linking estimations to "time spent" to "billing" was causing many assumptions about workflow which were just wrong.

For example, we all should know by now that 1 dev working solidly for 7hrs is more productive than the same dev trying to work on different 1hr tasks. Nothing ever takes an hour. Downloading a code repo & getting it running could easily eat up 1 hour. Super granular estimates were linked to granular timesheets and billing which never accounted for context switching. So on paper we were always going "over budget". Crazy right?! I still find this hard to think about, as it does seem counter intuitive. Basically, when you context switch, there is a significant amount of time you need to waste on gaining speed. Kind of like a car being stopped at every traffic light.

A Simple Elegant Billing Model


  • 0.5 to 1 day billing increments
    • Use this for items which are estimated to be around an hour to several days
    • Even if an item is "estimated" as trivial (perhaps 1-2hrs), just charge 1/2 day
  • 1 - 2 week "project team" billing increments 
    • Use this for chunks of work which is estimated to be weeks to months long
    • A team may consist of 2 devs, Producer, Designer and QA
  • Emergency tickets are pre-sold at 2/3 day billing increments
    • This is essentially prepaying for disruption
    • Gives you the ability to ask the client "do you want to use your pre-bought ticket" or is this ok to just schedule into support & maintenance?
    • Tickets expire after 3 months if not used

This billing model free's up your developers from the shackles of timesheets, and also builds in adequate buffer for all those random project comms and meetings. When I introduced this at the Cogworks, it was as if a burden had been removed from day to day life. Everyone was happier.


Friday, 6 September 2019

Stop Using Timesheets

Introduction

In an organisation which does software development, timesheets can really damage your productivity for what is actually a false economy. As Head of Development at The Cogworks I saw all of these problems and eventually abolished them completely.

In this article I will debunk common reasons for requiring developers to do timesheets. I will give better alternatives which will make your workforce happier and the organisation more profitable.

Comparing Projects For Efficiency

I cant believe I even need to state any of this, but here we go...

No two projects are the same. When I was at The Cogworks, we helped a client launch 100's of websites using a standardised multi-lingual starter-kit, "virtually identical" Information Architecture, and "very similar" designs. Each project was totally unpredictable in delivery due to changed in content, varying client-side interaction times, different developers, different designers, different devops people on the client side, and secret stakeholders who appear at the 11th hour. Keep in mind, this was the same client!!!

Requirements will always differ in some way, and stakeholders and client-side Project Managers change even within the same client & during a project. I have seen a project be totally derailed because a new (not so great) PM appeared on the client-side.

There is no point trying to compare build & deploy time for even small items. No two pages will ever be identical. I commonly hear "It's identical except...".

People on two project teams will have differing skills, experience, knowledge, personalities, and experience working with each other. Imagine taking a team who get along and have created many projects, however they are a bit sloppy. Compare that group to a team who have new members who don't know each other's skills and personalities, however they are all very capable.

I hope I have convinced you to stop trying to compare projects.

There are however other ways to tell if a project was efficient. For example, count the number of calendar weeks that the project took to complete. This is not the same as the number of utilised hours!

Performance Reviews

Using timesheets for performance reviews makes absolutely no sense. As a manager I want to know how many tasks a dev can do, and how often bugs are reported by QA.

I'll give you this (really bad Apples & Oranges) example:

Time logged is not the same as output
Anthony is a great at baking, however he worked on task "Apple Sauce" for 4 days. 
Greg is a great at Apple Sauce, however he worked on task "Orange Meringue" for 3 days. 

These people worked on things which they were not specialised in. How can you compare their time?

An alternative is to track output, not time logged. Track the number of tasks which each developer does. A very simple metric is to count the number of Jira/Trello/Asana/etc. cards which are completed within a timeframe.

Quality
Anthony's Apple Sauce is horribly overcooked with over-caramelised parts.
Greg's Orange Meringue has less perceivable defects than Anthony, however he didn't need to use a stove.

These tasks were totally different. Anthony basically failed at his task. How do you compare them based on timesheets?

An alternative is to track the number defects which are flagged. If you are using a Kanban process, then you can simply count the number of defect cards which are created against the work items.

Other Issues
No one knows if either tasks are complete, or even if they are done to the satisfaction of the client. Did the client report any issues, did QA find issues? 


Accuracy

Timesheets are seldom accurate. Here are some common habits of someone who fills in timesheets. I can absolutely say that these things happen because I personally have done all of these, and will continue with these habits if made to do timesheets.
  • Round up numbers to get 8 hours tracked per day
  • Add a number to a random client which I "think" I worked on
  • Forgetting to do them on Monday, so I do them from memory on Tuesday
  • Forgetting to do them all week, so I do them from memory on Friday
  • Forgetting to do them all month, so I do them from memory on when I am chased
    • Yes I've done this one too!

Even automated tracking will still be wrong...

Think about toilet breaks, coffee breaks, discussion at the water cooler, cigarette breaks, impromptu project chats, emergency meetings, helping another developer, doing a quick code review, phone calls, emails, Slack, calendar, Trello, and finally... short lunch vs long lunch. Trying to account for all these scenarios is a fantasy fallacy of micromanagement.

But I hear you saying "what about mouse tracking software?". Well, stop reading this article. If I cant convince you then perhaps these people can:


Client Billing

Fixed Cost Billing

I have been part of countless projects where I was required to do timesheets because they were apparently used to bill the client. When I found out that the projects were all fixed cost, I asked the question: "If the project is fixed cost, then how are the timesheets used to bill the client?"

The answer was: "The timesheets are used to see if we're losing money".

*face palm*

Tracking project time is different to tracking people time. I'll explain more in a future post.

Billing For Time Spent

If you are using timesheets to do client billing, then you are probably being too granular.

What would you do in this following scenario?
Developers help each other with questions, code reviews, discussions, architecture. Very often the knowledge / skills required may not exist within the same project team, so developer from another team is asked for some quick help. Very often this will be just 5 minutes. Sometimes it is longer.

Also, what about all the project meetings? eg. Standups (3-15mins), sprint planning, sprint review, sprint retrospective, random comms, emails, quick chats with the PM, 2min slack conversation with the client devs. What about when a colleague asks "How was your weekend"?

I know what you're thinking...
1. Dev 2 should enter a number into their timesheet that they spent 5mins helping Dev 1
2. As long as a developer's time is tracked against a client/project then there is no money loss.

Why are you concerned about tracking developer time by the minute? This is classic micromanagement! There is not value to the business to know that a developer asked another developer a question. It is wasteful. People hate and resent this level of micromanagement. Developers help each other and it all evens out anyway. So stop trying to track this!

A better alternative is to take a higher level approach. Bill by the day, week, sprint, month etc. See here for a better alternative.



Final Thoughts

I hope I have given you food for thought when it comes to timesheets and your production team. Comparing timesheets of projects has absolutely no value. Performance reviews should be based on quality and quantity of output, not time logged. Accuracy of timesheets is also generally crappy. If you can change your billing process to be less granular, then you will not need timesheets.

Once you remove timesheets from your business, your staff will be more productive and happy.