26 SEP 2021

Today is my 10 year anniversary at NCDOC. I arrived with no experience of working in government or with the military. I was a stranger to these types of organization having come with a medical and academic background. Nor was I familiar with the roles and responsibilities of the job itself. I reflect on my experiences below. I did have quite a few more observations and lessons learned, but I the others needed more context and I decided to keep this post short and simple. 🙂

Observation#1: How things are packaged may not actually reflect the reality.
What I thought the job was when I applied was completely different once I was actually in the job.
My title was, “Data Analyst”, so presumably I would analyze data, right? Responsibility, “create visualizations reflecting data collected”.
Me: “Okay, got it! I’ve created pie graphs, bar charts, etc. I can do this!”
It became very clear to me what I didn’t fully understand. So…What is this about programming languages and coding? Creating widgets and dashboards??!!
Me: “Whoa! That’s what computers do. I’m a human! I analyze and interpret the data. You know, a data analyst.”
I am fairly sure that skills and training was discussed in the interview process, but there was probably 4-6 months between the interview and my check in, and in my interview I probably said something like, “I may not know how to do that, but I’m willing and able to learn!”

Well, hop on the learning train buddy, because it’s taking off full speed ahead!

Lessons Learned#1:
a) Learn to get comfortable with the uncomfortable.

It may be a cliche, but when you start something new you must be LEARNING mode. You must be willing to put your 100% into the effort. It may not click right away (or at all), but you’ve got to try it especially if it took 9 months to get you in the door! When it comes to programming/coding, I never did get “comfortable” doing it, But I learned enough to get by and be dangerous. I could break things unknowingly.

b) Be honest about your own abilities. KNOW THYSELF.

I was not happy doing code work and, quite honestly, I wasn’t very good at it. I didn’t need my teammates to tell me the dashboard sucked! I wasn’t competent enough to meet my own standards and this made me not confident in my own work. I’m a systems thinker and process oriented. Trying to find out why widgets or dashboards didn’t work properly and searching through hundred lines of code over a forgotten period, a missing semi-colon, or an unclosed parenthesis was painstakingly frustrating for me.

c) Look for ways your strengths can be utilized!

I found that I could apply my systems thinking/process oriented approach to our dividion’s internal processes by developing a product development life cycle to include a peer review and quality control review before production! We didn’t have that in place at the time, which explained several things but, in part, why the customers weren’t using the products we were making for them! We also didn’t have a feedback mechanism between customers and developers, or ongoing customer satisfaction check-ins of the products. So, I started with the internal process first, then took the iterative approach. I pitched my idea to my supervisors and they agreed we should have an internal peer review/QC process, so have at it!

And oh boy, did I find the exact thing that put a target on my back with developers!

Observation #2: A change in process will ALWAYS be met with resistance (even if it’s the right thing to do)!
It was after completing the ITIL Foundations course in my second year of training that I realized the life cycle process management is a foundational BEST PRACTICE in the software development industry! (To me, “best practice” means minimum standard of practices) Therefore, I was amazed that a whole division of developers who’d been doing software development their whole career didn’t know about this or want this kind of process implemented. It can only better ensure we deliver a good/better product before we give it to the customer!

Lessons Learned #2:
a) You need the RIGHT person to execute change AND to do it the RIGHT way.

I was the catalyst to begin the new process development, but I needed help. I knew from grad school studying culture change that I needed advocates on my side. I came up against so much resistance, I thought I just needed one developer and a data integrator to help me develop what the process should look like. Luckily, there were more advocates than I expected! They all knew there were problems and issues; no one wanted to stir the pot! Well, I wasn’t afraid to grab a spoon and start stirring.

b) Change agents needs time, trust, and top cover (T3) from their direct leadership

I was lucky to have the supervisor’s T3 because the discontent from the developers was palpable. It wasn’t personal, or at least I didn’t take it personally. To them, I was disrupting their entire way of doing business and the process was purposefully set to scrutinize their work. Developers do not like their work checked and double checked apparently. I can understand that part of it, but at the same time, the products kinda sucked and the customers weren’t even using them! This may not be the solution to solving customer use and satisfaction, but we can at least improve our products otherwise, we won’t have any customers to use them. At first, the peer review process and QC was painful for all of us. Soon we put the right person in charge of QC and she took ownership of those processes. Once that happened, I took over the front end of process, the customer-facing part, gathering requirements and their feedback once the product was released. Divide and conquer!

c) Time will tell if change has occurred

Over time, product development became seamless, and the product quality increased significantly. Change happened. We changed the process to add in review processes, formal ways to gathering requirements, documenting them as well as getting feedback from customers, and even automating some of these processes! These processes remain and is the the way the team conducts business today. I don’t know what the feedback mechanism is post release (other than email) since I left that division several years ago, but I am confident they get use the various communication mechanisms now.

Currently, my role is Outreach/PAO. Again, roles I knew nothing about. A need was observed (several of them actually), and the CO at the time, put me into this role to address them. He further gave me the time, trust, and top cover needed so I could learn and execute the intiatives needed to address the issues. Since then, I again embraced my new roles, established relationships with higher HQs for guidance and mentorship, and I continue to extend my reach across the command as new needs and issues emerge to see how I may support in my current roles. The CO’s continue to provide T3 – some more or some less, and in their own way – I’ve adjusted according to their leadership style. I know that HOW I do things are different than most traditional Outreach and PAOs across the Navy. I am glad and proud of it.

My time at NCDOC always been more than a job, more than a paycheck. I’ve embraced every role I’ve played – data analyst, project management office, outreach/PAO – and have done it and continue to do it to the best of my ability. I take pride in not having the mindset of (1) “Let me just come in, do my job, and leave”; 2) “That’s not my job”; or 3) the one who has the “retirement countdown” ticker on their desk/whiteboard. I’m not saying any of these are necessarily bad, they aren’t. Everyone needs work-life balance; others need to be held accountable for not doing their job; and it’s always good to have goals post career. But these phrases and others similar to it reflect a particular kind of mindset – one that is less empowered, less enabled, or quite simply, a meaningless or disconnected job that has no fulfillment. We’ve all seen and heard all too often from our teammates. I’ve also heard the explanation: “I simply don’t want or feel the need to be empowered, enabled, or fulfilled at work. I am happy doing what I get paid to do. I get fulfillment doing stuff outside of work.” To be clear, I’m not judging this mindset, but I personally cannot understand nor want to operate this way.

Side Note: I just found out today when and what kind of retirement pay I would get simply because I was searching to see what 10 years in government service meant. I thought it was something significant, but since I don’t meet the minimum required age with this many years of service to retire, I get a bronze lapel pin! 🙂

I wish I could say this decade-long adventure was all wonderful and fun. It wasn’t, but it has been meaningful and definitely fulfilling! I know that I have been very fortunate to have been on the teams I was on, to work with the teammates I worked with, and to have had the leadership who gave me the time, trust, and top cover needed. As everything continues to evolve – the command, the command’s mission, and even my current role – just like most meaningful adventures, it is a roller coaster full of ups, downs, zigs, zags, and loopty-loops, and perhaps several of each! The reality is, I can’t ride roller coasters for long (if at all anymore). I vomit and then I have to find something cool to lay on – the ground, the floor or whatever – until I’m grounded again (this isn’t to say, I’m not ready for a new adventure).

So, cheers to being grounded! Happy 10-year anniversary to me!

I am sure a new adventure awaits.

(to be continued)