Agile Accounting: Congratulations, you’re probably Green/Blue

In a world that is changing so fast, it often feels like everyone is beating up on the Accounting department, and other departments are just frolicking about in the sunshine and always getting what they want. Why does it feel that way? The answer lies in how accountants process and communicate information, in the very core of how they view the world around them – accountants are most often Green/Blue (DISC). What can help Accountants keep their sanity in the face of constant change and increasing demands? You guessed it, Agile Accounting.

Disclaimer: I am NOT a phycologist or physiatrist, NOR am I an expert on the DISC system. I am simply using the knowledge I’ve accumulated via books and my own real-life observations to craft my theories.

In a world that is changing so fast, why does it feel like things are always so hard for the Accounting and Finance departments but not for other departments? Accounting seems to be constantly under pressure: the regulatory pressure, the pressure to execute faster, the pressure to implement new technology and deliver data to other departments, and many, MANY others…

The truth is that things are just as hard for the other departments, and they have many pressures of their own; however, the types of people that tend to gravitate to those departments tend to thrive under pressure and can keep a much faster pace. Nonetheless, to us accountants, it feels like everyone is beating up on the Accounting department.

The best method I found to make sense of this is the DISC system. I like it so much because it’s a system that can be easily applied in our daily lives. I understand that this is an oversimplification of how humans operate, but the simplicity of this system is the key to its applicability in real life. 

So, to better understand ourselves, why change is more difficult for us, and ways to navigate change by capitalizing on our strengths, let’s unpack the DISC system and its “colors”. I want to make it VERY clear, the DISC system is NOT a personality test. Instead, this is about communication – how you and others receive and convey information. Because communication happens on the LISTENER’S terms, when I discovered this system, it made a HUGE difference in my emotional intelligence and how I approach and handle different situations at home and work.

A brief introduction to the DISC system 

The DISC system consists of 4 colors: Red (D), Yellow (I), Green (S), and Blue (C). I often refer to these and simply “colors” and say things like “my colors are green and blue” when talking about my DISC profile. 

Each color has inherent strengths and weaknesses, but neither color is simply good or bad. Being able to capitalize on the strengths and increasing awareness of the weaknesses is critical to improving and growing within the business world. 

Here is a summary of the traits of each color. Pay attention to which of these resonate with you. Most people have 2 dominant colors, and it is rare to have only 1 or 3 dominant colors. Interaction between your colors and the amount of each will shape how you perceive the world around you and what information you will pick up (or not pick up) from others when they speak to you.

Red – task-oriented, fast-paced, extravert, decisive, dominant, result-oriented, hot-tempered, rash, thrive in conflict, risk takers, greatest strength – bulldozing others and getting their way, greatest weakness – not paying attention to details, biggest pet peeve is being ineffective. These are the people that want your bottom line up front and will easily butt heads with you in the middle of a large meeting. They want results, and they want them NOW. They often put pressure on the folks around them and quickly lose their temper. However, these are the best folks to follow into battle because they can make quick decisions in the heat of the moment and will do everything for their team to come out on top. 

Yellow – relationship-oriented, fast-paced, extravert, charming, optimistic, flexible, creative, loves and thrives in change situations, greatest strength – constantly generating new ideas and trying to move their team to the next level, greatest weakness – no follow through, biggest pet peeve is having to do routine tasks. These are the people that can talk to a wall and never run out of things to say. They are the life of the party and know everyone in every department of the company. They are fantastic at speaking off the cuff but will need help creating a formal structured speech. These are the folks that can appear like they have ADHD because they jump from one idea to the next faster than anyone in the room can follow. This appearance is often created because they tend to think out loud and change their mind right as they are talking a concept through.

Green – relationship-oriented, slow-paced, introvert, great listener, stable, avoids conflict, resistant to change, greatest strength – keeping peace and having a calming influence on others, greatest weakness – avoiding conflict, biggest pet peeve is too much change too fast. These are the folks that will go above and beyond to ensure that your needs are taken care of, even if it puts them out of their way to accomplish this. They tend to go with the flow and not make waves because conflict is very stressful for them, even if it’s as simple as arguing about where to go for lunch. They also do not like change and will resist it if they can help it. However, they are the most balanced when connecting emotions and logic and can always be relied upon to do exactly what they promised to would do.

Blue – task-oriented, slow-paced, introvert, perfectionist, detail-oriented, things must be done right, and before we do them, we need to know EVERY detail about it, greatest strength – detail orientation and follow through, greatest weakness – inability to make quick decisions, biggest pet peeve is uncertainty and having to make decisions with very little information. These folks are the Knights of Excel Spreadsheets who know every detail of their work and will always dominate any technical conversation. They want everything buttoned up and flawless at all times, and woe to you if you came unprepared for your presentation because they will pepper you with questions on every fine detail of the actions you’re proposing to take. They tend to be able to start a project ONLY once they’ve worked out every detail, answered every question, and removed all uncertainty.

As you can see, the colors divide into groups along 2 key dimensions: pace and task/relationship orientation. Red and Yellow are fast-paced colors; they handle pressure well and can perform tasks faster. Green and Blue are slow-paced colors; they tend to work slower because they pay attention to detail and experience more stress under pressure. The problem for Red and Yellow folks arises because their lack of attention to detail causes the outcomes to be delivered fast…but wrong. The Green and Blue folks take the opposite side of this coin, where the outcomes are delivered correctly and with great attention to detail, but often by the time they are delivered, the ship has already sailed. 

On the other hand, Red and Blue are task-oriented colors. For people with these colors dominating their profiles, completing the tasks trumps preserving relationships in the wake of task completion. Folks with these colors tend to be very direct, sometimes to the point of being curt. Conversely, Yellow and Green are relationship-oriented colors where it is more important to ensure that relationships are preserved even if that hurts completing the task. These folks take care of the people first and then of the tasks.

Can you guess which colors dominate the Accounting departments and which dominate, say, Sales departments? 

You guessed it! Accounting tends to be populated by Green/Blue individuals, and Sales tends to be populated by Red/Yellow folks. (I’m using Sales here because it is the best example of a department with the communication styles (or colors) directly opposite to the Accounting departments’ as I’ve observed throughout my career). So I’m gonna venture on a limb here and guess that if you’re in Accounting, you’re probably Green/Blue.

[If you would like to read more about the DISC system, read Surrounded by Idiots and Surrounded by Bad Bosses by Thomas Erikson]

So, where does Agile Accounting come in?

Now that we’ve had a brief introduction to how different colors operate, it becomes clearer why change is so hard for the Accounting folks. 

The truth of the matter is your colors are permanent. They make up how you react to the world around you, and it takes an incredible amount of energy to go against your own grain. I am Green/Blue with a sprinkle of Yellow, and change is just hard for us Greens. It is stressful, especially if your profile is a combination of Green and Blue, because, in a change situation, we cannot know every detail of the change as it is being made…but us Blues need to know it to be able to make sense of it. Thus, to capitalize on our Green/Blue strengths AND still thrive in the world of change: enter Agile methodology!

As I mentioned in my article Agile Accounting: Why nothing ever works and how to fix it, when I say Agile methodology, I mean iterative, small changes that can be tested and implemented quickly and without much disruption to someone’s work/day. I intentionally leave all the “baggage” (epics, stories, etc.) that make Agile complex outside this term adaptation. 

So how does this Agile rubber meet the road? And how does it help us keep our sanity in the meantime? Let’s work through a more complex example than I used in my previous article (Agile Accounting: Why nothing ever works and how to fix it). 

Let’s say we need to implement an electronic form of processing vendor invoices, and it is complex with matching to POs and partial vendor invoicing. We have 3 departments involved in the process Accounting, Purchasing, and the folks placing the orders with the vendors and approving them within our process. The additional wrinkle is that we’re under pressure to implement this relatively quickly because our current turnaround of the AP invoices is slow, hurting our relationships with vendors. This is a beast, so where do we start?

We will do this in phases:

  • Map out the current process.
  • Create a first draft of the new process.
  • Test the new process in the new system.
  • Finetune the process.
  • Implement it.

We start by capitalizing on our Blue strengths and map out our current process to get all of our current steps and department interactions on paper to ensure that everything gets incorporated into our new process. We already know how it works, so we can do this quickly and have a completed deliverable early in our journey. 

Next, we discuss our process with our new software provider and ask them how their software handles specific workflows and aspects of the process we’re trying to build. At this point, we will likely have more questions than answers, but the key is that we have SOME answers. Also, at this point, we can group our workflows into general categories such as invoice intake, working problem invoices at the intake stage, matching invoices with POs, routing the invoices that match POs (no issues), and routing the invoices that don’t match POs (issues) for approval, and finally, payment of the invoice. 

The next question is for which chunks do we have enough information to begin crafting the new process and for which we don’t? We should have enough for all but the payment process because it will depend on how we do all the other groups of tasks since they are all direct inputs to the payment process. So, let’s map out the new process based on our current knowledge of how the new software will handle these things and what is possible to do within it. The thought of doing this without perfect information might make us cringe as Blues. Yes, there are still gaps and unanswered questions here. BUT as a Blues, one of our strengths is in asking deep questions and analyzing fine details, so we will capitalize on that by making a comprehensive list of these questions, but we won’t let the lack of answers to these questions prevent us from moving the project forward. Instead, we will document these to answer them in the testing phase. We will also leave the payment processing out in the new process map for now because we will keep it the same upon implementation and will come back to working on it once we’ve had the new process in place for a couple of months and we’ve had a chance to understand what we will need to do to change the payment process. The payment process will be considered round 2 improvements to our AP process. 

Now we’re entering the testing phase. At this point, we need to be aware of the weakness of Blue in needing to know every detail of the process before we implement it. In the testing phase, this runs the danger of testing the process to death and losing forward momentum. We don’t need to run a test for every possible scenario to be confident that the process works. We will only focus on the most common scenarios and ensure that our new process can handle them (this is basically an application of the 80/20 rule that Blues often struggle with). To test the process, we will create a testing team that consists of a few folks on our Accounting team, a few folks on the Purchasing team, and a few folks from the teams that approve our AP invoices. We are bringing all the groups together in the testing phase because we’re not just going to test the steps but also the communication that will need to be happening between these teams and our ability to effectively pass information between all teams that will be involved in the process. Also, expect conflict in this phase. Here we have to remember that healthy conflict is good. It provides for better solutions at the end of the day and makes us think more critically about the process draft and its ability to accommodate the needs of every team involved. As Greens, our instinct is to avoid conflict, so this may be challenging and make us cringe at the thought. If you are Green/Blue, your Blue will help you with this. Focus on the logical side of each argument and implement the best possible solution for all teams involved. Don’t avoid heated discussions, but document the ideas and walk the teams through the pros and cons to come up with the best solutions together.

Ok, now we’ve tested for a month or two, answered most questions on the list we created when we were drafting the new process, and fine-tuned our new process map based on the answers. Next, we bring in and train all the teams affected by the implementation of the new process. Training will be critical to the project’s success. Do several training sessions focusing on the steps that the team you’re training will need to take in the new process and identify how the new process will make day-to-day easier for all the teams affected by the change. 

Now it’s time to implement. This will be iterative as well. We will implement the new process this just ONE vendor first and add others as we get comfortable with the process and work out all the kinks. Choose your biggest or most cooperative vendor for this step to make sure you can have productive conversations with them if/when there are hiccups in the process. In the meantime, create a plan to add all the other vendors to the processes with a reasonable deadline of when the new process will be 100% in place. This will appease your internal stakeholders and allow you to tell vendors that you are working on improvements with a timeline for when these will be completed.

That’s it! We’ve done it! The process is in place. How do you feel? Exhausted? Take a break; that’s ok. Because next, we can work to expand on it, such as working on the payment process in the same manner.

Applying this adaptation of the Agile methodology helped us capitalize on our strengths as Green/Blues and void the traps of our weaknesses. It allowed us to go faster without sacrificing the integrity of the process or having to operate in ambiguity because we’ve worked through the parts of the process in iterations and were able to answer questions as we went. Most importantly, change felt much more comfortable this way

Agile Accounting: Why nothing ever works and how to fix it.

The word has gone crazy…COVID, a million accounting regulation changes, constant bombardment of “new” ways to approach work, constant emergence of “new” tools to automate accounting processes, everyone trying to convince you that their way is better, and in the meantime, crisis after crisis after crisis….So this is a no-win scenario. Nothing ever EVER changes and the struggle continues. What are we to do? Answer: Agile Accounting.

The word has gone crazy…COVID, a million accounting regulation changes, constant bombardment of “new” ways to approach work, constant emergence of “new” tools to automate accounting processes, everyone trying to convince you that their way is better, and in the meantime, crisis after crisis after crisis…. AAAAAAAAAHHHH!

So to keep up, you pick one of these new tools or new frameworks and try it…and it never works — seriously, like NEVER. Because when the rubber actually meets the road, it is not what you bought (or thought you bought), you ran out of time to implement properly, or it has weird quirks that the sales guy didn’t tell you about, etc. In short, lots of PAIN.

As for you, here’s a pile of newly added administrative overhead inherent in your new tool or framework — OMG! More?

The cookie crumbles this way because these tools and frameworks are complex. So complex that there are people specializing in their setup and implementation as a CAREER.

If you are lucky and have the budget to hire one of these experts, you still end up frustrated and the new tool gets abandoned while you go back to your manual Excel and paper process. Why’s that? Because it is faster. Not easier, but FASTER. You can type something in or print something faster than you can click 20 buttons in the newly added tool.

In the meantime, you’ve now run through your implementation budget, so you have to solve anything that goes wrong yourself….you don’t have time for this.

The truth of the matter is, big bold changes never stick because the learning curve is too steep. It is too hard to stop what you’ve been doing for 5–10–15 years and utilize a brand new tool that you have to LEARN from scratch. You don’t have time for this either.

So this is a no-win scenario. Nothing ever EVER changes and the struggle continues. What are we to do? 

Answer: Agile Accounting.

Whaaaaaaaat!?

Yes.

Let’s get away from the term “Agile” for a minute and talk about the spirit of the framework. The key concept of this framework is iterative, small changes that can be tested and implemented quickly and without much disruption to someone’s work/day — let’s call it “100 small steps” (wink to Thom Ewen) to avoid getting hung up on the term “Agile” and all the “baggage” (epics, stories, etc.) that comes with it and makes it complex.

Ok, fine. But how does that actually apply to accounting? Accounting is historically a repetitive field of work where you close the month every month and do the same tasks over and over again. What can we possibly do with the “100 steps”? Reconcile GLs? Nope!

You are right. It seems like what accounting does is repetitive and routine and “Agile” — as it has been used until now — only works for the teams that are creating new things, like software developers and other designers. The truth of the matter is, there is so much change that is happening in the world right now that we, accountants, no longer only do the routine tasks — we are forced to innovate, implement things, collaborate with other departments to get the information we need, and help ourselves by improving our own work processes to be able to meet all these increasing demands — that’s A LOT. In other words, we now have to both do our repetitive tasks AND continuously create something new. Also, notice how our repetitive tasks are being more and more automated by the myriads of new software that comes out every day with their AI? What’s going to be left for us at the end of the day? Yup, the “creating something new” bits!

I know you know that this is what our reality looks like, and that’s why you lobbied for and implemented that new tool or new structure. But implementation was rushed by the executive management, or you ran out of time to fully implement and the tool is now more work than it’s worth in its half-finished state. Or maybe a structure was pushed on you by the executive management altogether and it simply does not work when the rubber meets the road.

In either case, following a modified, adapted form of Agile methodology will help. Why? Because it will not be a drastic change, but a series of SMALL changes that move you toward a better [insert what you want to improve here].

Let me give a quick example. Let’s say you’ve implemented Oracle as your ERP and you just ran out of time and money to figure out the Fixed Assets module, so now you’re still keeping track of your assets and depreciation in Excel and doing Journal Entries for this manually on monthly basis. Worse yet, you know that you will never get a chance to get around to setting it up and turning it on since you have to also close the month and do your daily tasks.

The Agile process can make this happen:

How can we break up this project into small chunks? First, we need to learn how the module works and find out what it will take to get it set up. Then, you have to do the setup, create the worksheets to upload, or manually start entering your assets into the module. So, let’s say that this month, we will find 3 hours to learn about the module. Yes, that’s ALL we’re going to do this month for this project. Ok, now we found out what we need to do, what data to gather, and what worksheet to fill out. Let’s say we have 100 assets to set up. That’s a lot of work. Yes, but what if we set up 5? 10? at a time. Let’s say we set a goal to create and load 5 assets per week and it will take us 2 hours to do this. So, every week we set up 5 assets for 20 weeks. In 5 months, you have all of the assets in the module and you are NO LONGER making the manual entry for depreciation and simply verifying that the process ran correctly.

Slow? Yup! But we are still further along than never doing the project altogether because it’s too big to take on end-to-end. Now imagine everyone on your team takes on one project like this and follows this simple framework. How much better off can your team be in 6 months? In 12 months?

Of course, this is an oversimplified example and more complex projects will require a heavier lift, planning, and coordination, but it does illustrate this way of thinking. A way to improve your situation without adding a huge amount to your plate. And the BEST part? You can stop at any time in the middle of a project — go ahead and attend to that fire that fell into your lap, or take care of that audit — WITHOUT losing momentum or having to start from scratch. This is because the work you have done to this point is stand-alone, fully functional, and finished.