An IT BA on a Cross-Functional Technology Team

If you, like me, have spent most of your BA life sitting amongst other BAs or inside a cluster of business partners, you can appreciate the “shock and awe” I experienced moving into a workspace filled with engineers and QAs.

Half of our IT team re-orged into system-specific cross-functional teams. The business analysts combined with the QAs, system engineers and even a database engineer (DBE) or two to form a cohesive group of support, brainstorming and execution. I went through this transformation last year and can say the experience has been nothing less than eye-opening.
Keeping the engineering side of your business in focus is important for any BA, but when our business wants to turn left and our engineers – developer, programmers, DBEs, etc. – are diligently working on how to use the latest technology to turn right, we find out how painful it can be!

The engineers (I lovingly refer to them as my Geeks) are as committed to driving our business as I am and are always looking for the inches of improvement around us. Suddenly, the total commitment to our business partners involves some tough choices for me, the BA.

One day I’m in a devoted business partnership, the next day I’m in a devoted partnership of driving the business during system upgrades and failovers!

The first thing that shocked me on the Geek-filled team was finding out I was actually skating on thin ice all those years as I was driving our business forward on top of new technology. Yes, I understood how the system worked and what some of the possibilities were, but all that time the engineers were looking for better ways and innovating like crazy. Suddenly, I understand why the engineering response to my change requests was often “WHAT?”, “WHEN?”, “WHY?” and sometimes “Wait!” I was driving the business on top of a system or systems the Geeks were constantly improving. Understand, our company culture is deeply ingrained in all team members, but sometimes during those days as a business BA I wondered if the Geeks and I worked at the same place. Getting on the same page, or not colliding on the same page, was the source for a LOT of discussions, but, the real challenge had been making the business better on top of the ice and how to make the system better below.

---

{module ad 300×100 Large mobile}

---

The second “wake up” moment was when I spent the first month with my Geek team and realized we had been meeting and making decisions over the years while saying the same words and meaning completely different things. For example, I have used the term Doc Type for about 14 years and never knew the engineers supporting my system have been mentally translating it to Doc Type Number. Only when I physically joined their world did I hear the comment from one to another “She means the number.” A simple difference, but really got me thinking. Geeks talk differently. In my part of the world, they speak English, but a different kind of English. There I was, thinking I was an expert at translating technical changes into business-speak, and I found myself needing to come up to speed on translating geek-speak to technical changes to business-speak.

Thankfully, I landed on a team with patient engineers and QAs. I think this patient Geek may be few and far between, but if you find one – listen and learn! My experience with Geeks is that they run fast and when they get an idea – watch out! A discussion can go from clear and orderly to “Wait, what if we do ….” and “No, I heard about something that ….” REAL fast. Your BA skills are needed like no time before. Remember how you led that meeting with business big shots and their conflicting agendas? Child’s play. Now you need your special skills, as I like to say, to herd cats. You are dealing with super-smart, ready-to-execute, get-it-done individuals and what we don’t EVER want to do is stop that innovation and passion for execution.

You just want to figure out how to do what our business needs us to do and make it to your next meeting (or lunch) on time. Remember how I mentioned I work with patient engineers? Well, even their patience is limited when it comes to asking them to remind me (again) what a thread is. You will want to decide what questions you need to ask during a meeting like this and what questions can wait.

My suggestions, if you find yourself gifted with an opportunity to work on a cross-functional technology team:

1. Concentrate on just listening during your first few team meetings. Ask an engineer or QA afterwards to translate what you didn’t quite “get”.
2. Slowly start asking questions to find out if anything on the agenda will affect your business partners. This is a way to bring the business closer to your engineers, QAs and DBEs.
3. Add something to the agenda that is pure BA, pure business. Get ready for odd looks, questions and maybe even some chuckles. This is where you find out how wide the chasm is between what your Geeks think the company does, and what you know it does.
4. Make an effort to educate your team members as you get educated yourself. Share your current business meeting challenge, your thoughts on acceptance criteria for a task or other things in your typical BA day. Pretty soon you find the discussions become mutually informative, and the action items have you all on the same page.
5. “BA” for your engineers! Give them the support and input they probably didn’t know they could ask for. Do the analysis, contact the subject matter experts for any clarifications, and learn to test something from the very bowels of the code. Show your cross-functional team what they have been missing all this time and why they need you in their lives!
6. Lastly, enjoy the most exciting team experience you have ever experienced. Dive deep, sweat a little and celebrate the big wins as a cross-functional team.