Internal Branding is Important Too
As I spend more time in the QA world, I’m noticing that quality is a thread that weaves throughout a company.
It’s more than just providing good software and a great user experience. It’s also about providing a great employee experience too.
“Quality is Everyone’s Business” is a phrase I hear used often. It’s usually directed at outgoing software–it should be good before it hits the customer.
But one way this is overlooked is the internal branding of a company.
What Is Internal Branding?
If external branding is how customers perceive a company, then internal branding is how the people within a company perceive the company and themselves.
A company’s workforce and success are guided, changed or even derailed based on how the company values and treats their people.
Obviously if people are jerks, or have bad attitudes, that’s a problem. But there are more subtle ways the internal brand of a company can be tarnished, from the inside.
Sometimes it’s a passive thing. Sometimes people aren’t even aware of it.
But, anything that gets in the way of people being as productive as they want to be affects the internal brand.
Specifically for QA members, two big things that affect the internal brand are onboarding and internal tools.
They Say First Impressions are the Most Important
The onboarding process is the first real, working contact a person will have with your company. That’s literally when they can start getting stuff done.
The game Super Mario Bros. was gracious enough to give you a short grace period after touching an enemy, so that you wouldn’t immediately get hit again. For that short amount of time you were invincible. You could literally run through any enemy any not take any more damage.
The first part of a new job is kind of like that. People usually aren’t expected to be at 100% capacity since there’s a lot of domain knowledge to soak up.
And there’s also the, “Just [got hit/changed jobs]! I’m invincible!!” element. New people almost always want to impress from the outset, and hit the ground running. And they almost always never know what they’re not “supposed” to be able to do! It’s great!!
So it’s critically important to get the onboarding process right.
It’s really not difficult–just a couple things to change if you’re not doing it already:
- Make it easy for a person to get started and be productive, and
- Give them something substantial (not tiny, not trivial, not worthless) to prove themselves on and ramp up
Here are a couple examples:
On my first day, after filling out some short paperwork, I was shown to my desk. The laptop and monitor were already there. I had an email waiting from my manager, saying how to set up the environment to start writing automation. That didn’t take long to do. Previously we’d discussed what the first challenge might be, and he had something in mind. That challenge took a week to complete, and delivered some serious street cred for the QA team.
The day I started, after a brief intro to the manager and a crash course on the complex systems, the onboarding got started. Upon being shown to my desk, there were a series of systems that I incrementally found that I didn’t have access to. The procedure to get access was to call the helpdesk, but I had to provide a certain code that I didn’t know, because the email containing that code was never sent to me. Ok. There were separate logins for SVN, ticketing, and a host of different applications (in each of 4 environments). It took 2-3 days to get the SVN password, to pull code, to even start testing and automating. Most of my time spent waiting on logins was spent looking over other peoples’ shoulders to learn what I could about the environment. I’d wanted to deliver value within a short time of starting, but after all that waiting, I’d lost a lot of steam.
If we’re looking at the first week of work, that’s a small sliver of the total time spent at your company. And it’s a sliver of time that sets the tone for the entire time that person works for you. How do you want your company perceived by the new person?
The Tools You Use
It can be difficult to do the job with a complex toolset. If done wrong, more time is spent thinking about the tools rather than thinking about providing customer value.
I bet a lot of people don’t consider that a complex toolset is actually a form of technical debt.
There are some good tools out there that allow someone to get work done quickly, without a huge learning curve.
But there are also some that end up causing problems.
Particularly, I’m thinking of ones that are either off-the-shelf and modified a bunch, or home-rolled ones that have a ton of features, or a clunky UI.
What often happens is, features are extended or added on quickly, and it makes things more complex.
First, It costs time to train people on how the tools work. It takes time for one person to stop what they’re doing, and train someone else to do a new thing. The longer it takes, the more it costs, both in terms of context switching and time spent not working on revenue-generating stuff.
Second, if a person thinks they’ve found a bug, but it turns out it’s expected behavior, simply because the employee wasn’t told about that behavior (or even simply forgot because their brains are so stuffed with info) then it becomes a waste of time and money, chasing something that’s not really a problem.
Instead–tools should be:
- Intuitive, and
Simple tools are preferable to complex ones. Usually, complex ones have many features that not everybody uses, or multiple ways to do the same thing. Not really good for simplicity. There are exceptions, but one tool that tries to fix everybody’s problem is likely not a simple tool, and requires a learning curve.
Intuitive tools don’t have to be thought about much in order to use. Think about the last time someone had to show you how to use a hammer. Do you still know how to use one now? Probably. Do you have to think about it much? Probably not.
Decisive tools solve a particular problem. They don’t try to be all things to all people. It’s the difference between a toolbox and a Swiss Army knife–it’s possible to do a lot with one, but it’s much easier to use a single tool for a job if available.
How To Diagnose Internal Branding Problems
It’s not limited to just onboarding and toolsets, but an easy way to diagnose this type of problem is to just get your listening face on, and tune in to what people are saying:
- What are people complaining about around the coffee pot?
- What are people spending most of their time doing?
- What projects or systems use the most in terms of people, time and resources?
- How productive are new people on their first week?
- How much “tribal knowledge” is there?
- How many invalid defects are logged?
- Can people move as fast as they want, or are “things” slowing them down? If so, what are they?
Answers to these questions will help isolate and identify things causing a problem with internal branding.
Particuarly with QA, getting the right tools to get a strong internal brand is important. If new QA members can’t get ramped up quickly, that will hurt you after awhile. Assessing this type of problem with QA teams is one of the services offered by Arch DevOps. If you’re struggling with this problem, schedule a free 15-minute discovery call and let’s talk about it.