“We empower our employees” — How many times have you heard that?

“We empower our employees” – How many times have you heard that?

It’s a favorite phrase in the world. You hear it at every presentation and see it on every careers page.

If we empower our employees so much, why do we make it so difficult for them to do their jobs?


Thanks to start-ups, new technologies, and industry disruptions, large companies now see the value in an Agile mindset, creating MVPs that provide value to clients. They have worked to create cross-functional teams of super engineers, product managers and user experience experts to help quickly deliver features that provide value to customers and are a joy to use.

However many large corporations have -facing teams as well as external facing. Typically internal teams are creating for HR, accounting, tech support and so on.

Internal software development teams are typically smaller, for example: one project manager and four engineers. They tend to have a smaller budget than client-facing teams because they are not directly seen to be contributing to the bottom line. The engineer on the team will often wear many hats – one day they are sketching designs, the next coding and then releasing the software.

These teams don’t deliberately want to create bad applications. They are often charged with working on a legacy system or designing an application which will interact with a legacy system. Most internal software in a large company is in some way going to have to interact with or be involved with a monolithic system. This means complex architectural challenges and potential backward compatibility implementations. These challenges often end up posing the question, do we improve or start from scratch? Projects get bigger and bigger and more and more stakeholders are involved.


As mentioned above, the teams don’t want to build bad software. They are actually always looking to improve. They hire top talent, they stay up to date on trends. They spend money on conferences, trainings, new infrastructure.

Sometimes this works, sometimes it doesn’t.

There are many key components in creating a great software product:

  • Technology – Using and investing the correct technology to create scalable solutions.
  • Business buy-in – You need to have a great partnership with the business so they provide the information and testing necessary to create a great product.
  • Operations/Support – You need to have a streamlined process which allows you to release software iteratively. Releasing features and fixing problems quickly help create a great experience for your customers and help you innovate.

Most internal software teams are already doing these things or at least working towards it. So what’s missing?

User experience.

Why do we value creating the optimum pain-free experience for customers but not our employees? We are great at understanding every detail of how our customer uses an app – So why are we not doing this for employees?

Internal software is often built on vague requirements and wireframes. The dev team and PM then often fill out this information with assumptions as they build out the system.

For example:

As a developer if you asked me to build a ride-hailing app – I could probably create the app with a fairly decent user experience because I understand the process of calling for a cab, I understand what people value and what frustrates them. I have a real-world mapping to the problem you are asking me to solve and therefore my assumptions should be fairly close to help create an MVP. Of course in the real world we would (should) have a team to help work on this problem. They would help design and build out a solution that works for everyone, not just one person. They would look at how different demographics use the app, the accessibility etc and together we could create a well-rounded app that is easy to use.


As a developer designing internal software, if you asked me to build an app which helped onboard new technology graduates on to the company-wide graduate scheme. I would have no idea. I have no real world mapping to this situation. I have never worked in HR.

This is where the PM comes in – the dev team and PM have a couple of meetings with the business where they discuss a high-level requirement and then break it down into smaller chunks like what kind of access will they need, what users will use the system?

From this, we design a couple of rough wireframes which solves this problem and agree on the MVP. We deliver the MVP for testing in a few weeks time.

The end result software is fine. It does solve the problem, the business can’t argue with that, so they sign it off and it gets released. Then we build more on top of it and it gets clunky. Fine will eventually turn to bad.


The problem is no one in life wants anything to be just fine. You want things to be fantastic and you should aim for fantastic.

We failed in creating the software because we didn’t understand what the business do day-to-day. Unless we work directly with the users to see how they onboard graduates, we can’t understand intricacies in the process and make sure our system is ready to handle these use cases.

Fantastic software is designing for the exceptional use cases and as well as the generic “ideal” customer flow.

If we don’t design for exceptional situations, then our system won’t be flexible enough to handle it. Eventually a user will request for this use case to be handled in the system and because it wasn’t built into the original flow it either involves a lot of rework, starting from scratch, a hacky fix that doesn’t work in the flow or even worse – the users come up with a workaround using emails that doesn’t even involve your system.

The easiest option and the one that often gets picked is the hacky fix which makes no sense in the existing flow and so it becomes cumbersome to use. Have this situation happen a few times and viola you have a below par internal piece of software that your employees need to use.

Internal software development teams need UX or CX experts. You need someone who really understands in depth the user group and can allocate all their time into understanding what the user is trying to do and how we can make the process as pain-free as possible.

If you don’t have the budget for this then you need to allocate time in delivery estimates, so members of the dev or project management team can really spend time with the users understanding their frustrations, the current systems they use and what would be their dream new tool.


  • Stop using meetings with 8–10 participants for 1–2 hours as the main way to gather all your requirements for features. It is information overload and it’s always the voice that shouts loudest who gets what they want. Do you think features in Uber or Spotify are designed this way? No, so why is your company software designed that way?
  • Spend time understanding UX & CX. User experience is not only about being able to create pretty high fidelity mock ups that you can show to the business. We start to solve the problem when people stop confusing UX with UI design.
  • Approach creating and designing internal software as if you are trying to create someones new favourite application. Sure it might sound impossible to make the new accounting software someones favourite app however if you approach with that mindset then you can create something really innovative and make someones job easier. Try to disrupt the process.
  • Improving Internal Software = Happy Employees = Lower Recruiting Costs Through Higher Retention Rates & Better Company Culture

Source link


Please enter your comment!
Please enter your name here