Harnessing Situational Awareness

Situational Awareness

by: Dr. Gaiye Zhou

You interviewed for a “software architect” job. You survived the scrutiny. You joined a great company. Congratulations, you are a software architect!

Although the pace is slow for a week or two, you seem to be assigned to an exciting project. After meeting your team and various stakeholders, your new position has been described to you by different people as: (1) Sr. Developer, (2) Architect, and (3) Technical Lead. To help you get started on your project assignment, you are given “high level requirements.” They are disparate materials that state business problems vaguely, but urgencies clearly. If the problems are not solved, the company will lose market share, revenue, and be beaten by its competitors. You assess all the project information. Nothing is clear except the following: (1) a fixed budget, (2) a fixed timeline, and (3) a partial project team of three full-time people, two more to be recruited, and a few others who are here part time for your project. In addition, you have some offshore developers that you can pull in.

As you talk with various stakeholders and members of the project team, you begin to get a picture of the personalities you will be working with throughout the project lifecycle. Your first impressions are: Sandy, full time, a project manager, excels at having a complete project plan, organizing status meetings, and getting issues resolved. She seems to be capable of managing the most complex projects. Maria, full time, a young developer, is always on the technology forefront. Once she masters the technology, she is eager to teach others. Her work is superior quality, judged by concept, design, implementation, and documentation. However, once she finishes a project, which means that the bulk of work is done, she likes to move on.

Bob, transitional to be full time (50%-to-100%), is an experienced developer and operational support person who calls himself a “utility guy.” He likes to use mature technologies and lets others “bleed” on new and emerging technologies, be it a framework, a new programming language, or a packaged software system. In fact, he enjoys maintaining existing applications and learns “tricks” from digging through old code. He seems to enjoy his work, even tasks that others might perceive as repetitive or boring. Karen, part time (75%), is an experienced business analyst with a strong technology background. In fact, she was once a developer. She is a well-respected expert for multiple lines of business. In addition, she can communicate with different groups using their own jargon. She is normally the “go to” person for knowledge and clarifications on any confusing issues.

Gary, part time (25%), a quality assurance (QA) lead, has a reputation of being tough and thorough. The company is very grateful for him, as he is the “tough gate” to the production environment. His test plan is comprehensive and his test cases cover not only functional requirements, but also stringent operational requirements. He is an expert in test automation. By the way, his graphical test reports are the executives’ favorites! Gary has a pool of testers that he can pull from for different projects. He manages resources very efficiently and has access to a group of testers in India.

Patrick, part time (25%), a production release and support engineer, has been with the company for a long time and knows most of the applications and systems in the test and production environments. Not only does he know the operational and network environment, he has intimate knowledge of many applications. He will not let anything go to production without a thorough checklist complying with his high standards. Patrick’s time is shared among multiple applications. You will work with him based upon his availability. Other specialty resources, such as DBA or Data architects, are allocated to your project on an “as needed” basis.

Wow, what a team! Despite the nebulous status of the project charter and requirements, you are excited and confident. You are in high gear and ready to accelerate. You work extra hours to get to know the people around you, both inside and outside your project. You think positively about them, and the same comes back to you. You have a great start. Everything is moving in the right direction. You are getting some requirements defined and details negotiated through your PM with your project sponsors. By now, you have learned that there are multiple sponsors with differing, conflicting expectations from the team. Sandy, your project manager, tells you that she will do her job and count on you for the implementation.

You and your team have great rapport. After several days of give and take, you and the team have made the final decision on the architecture. You are not sure that it is the optimal solution, but you know it’s good, and at least everyone is in agreement. You take the responsibility to document the detailed design. You require a number of supporting documents (data models, etc.), and Sandy makes sure they get into the project plan as dependencies.

Just when you think you are in the clear, you notice that the development task list is getting longer and longer. You see more issues and risks emerging, and problems arising from the tools and the packages purchased. The schedule is slipping before you are really started, and meanwhile you are still ramping up your offshore capability. You are working evenings to get some phone time with them. With significant effort, you are able to delegate a portion of well-defined and documented tasks to the Indian developers.

In the meantime, you have received resumes from the HR department. You perform phone interviews during evenings and weekends and make recommendations. You are told that it will take weeks for any new developers to come onboard. Work is picking up and the schedule is falling further behind. Your manager and other executives drop by and ask about the progress. You feel pressured. You must fill in the gaps and speed up the project. You have become the developer, architect and technical lead predicted by your stakeholders in the original meetings, working off-hours and weekends to get things done. You begin to feel resentment, burned out, and your smile disappears.

Besides working with your project team, you are constantly juggling communications, clarifications, reviews, getting endorsements from sponsors, and resolving vendor package defects. In addition, anything not in the project plan is your responsibility. Back-to-back meetings are everywhere on your calendar. You have snacks for lunches. You are tired. You wish that you had stayed in your previous job, which now seems much simpler. The extra pay you are getting has become insignificant. If you calculated your hourly rate, it would be very low, because you are working so many hours a day plus many hours of your precious weekends. Even more disconcerting, you begin to hear negative buzz. Your developers are getting over-worked and everyone else seems to be staying later and becoming gloomier each day. Some evenings, you order pizza delivery to feed the team.

You hear the complaints. You have first-hand experience working with these people now. Here is your new picture, or reality:

Sandy seems to be working from home a lot and sending too many emails. You wish she were in the office more. You also notice that she likes to talk about her artwork or children at the beginning of meetings or conference calls, wasting valuable time.

Bob, who comes to work at regular hours, is always ready to assist. However, he does not seem to have the needed technical training to use the software yet. Therefore, you assign him more environmental set up work. He is learning and wants to help you. You rely on him to get the right information about the legacy systems that your systems interface with.

Maria comes to work at irregular hours, working very long or short days. However, you refrain from being upset because she is very dependable and gets lots of work done. Now you understand why she pays no attention to company politics but always gets to do advanced work. You feel grateful that you can also count on her to get a great deal of documentation done.

Karen, who is well rounded and congenial, seems to be pulled away frequently. However, you have learned a lot from her. You are impressed with her business knowledge, but you still need to work with her to get requirements documented, reviewed and understood by the team. You know that requirements are the driving force of the system and must be defined correctly. There are multiple iterations, each producing more and better results.

Gary seems to spend a lot of time in the break room and drinks coffee all day. When you ask him about the test plan and test cases, he always says that he is still working on it but not able to make greater progress because of the unstable requirements. Test cases must match the requirements, which are being updated daily, he complains.

Patrick, who has a great temperament, seems indifferent. You would like to get to know him better and talk with him about your project’s operational plan. However, he is usually either very busy or taking his smoking breaks which seem to be too numerous. You hate to go to the smoke area because (1) you do not like the smoke, and (2) you do not want to be intrusive. You have the impression that Patrick is tough and a control freak and the great temperament is just a cover.

Who are these people? What happened to your great team? How will you be successful under these conditions with these issues? You recognize that your outlook—your context—has changed. It is not possible for you to be successful under these circumstances, so you need to change your mode of operation to turn the project around and get the team behind the vision. Your design is dependent on the understanding and implementation of the team, so you must find a way to get through to them.

Karen needs to nail down the requirements. She seems to have a good attitude, but she has competing priorities. What can you do to make it easier for her to dedicate time to your project? Is it reasonable to expect an architect to address prioritization outside of a project assignment? Of course it is. Find out what other projects are competing for her time and help her understand the relative importance of your project.

If you find that her other commitments are in fact a higher priority than your project, it will be up to you to adapt. For example, you may be able to enlist Gary (the test plan author) to help you drive through the requirements in Karen’s absence in the form of use cases. These should translate directly into his functional test plans. In return, you may be able to help him with some of the non-functional test requirements.

What other opportunities do you see in this case? Now imagine six weeks have passed, and you finally have your new developers on board, trained and assigned. Your global resources will have picked up speed and started to make good contributions. Your risks will have diminished, but your work would not have. Understanding your context—your situation—and adapting appropriately will allow you to deal with the expected and the unexpected.

The next time you engage in a project, you will have even more situational awareness (as you become more familiar with the company culture and operational model). You can ask to work on a project that uses different technologies. You may ask to be a program-level architect, responsible for multiple related projects. You may gain more managerial responsibility, or less—depending on your career goals. You will also have more insight into the way your senior management runs their business.

For leaders and architects in the technology field, knowing the technology is not enough. You must understand the business you are in. You must have good relationships with the people you work with, the people you work for, and the people you supervise. It is not enough to know what they do and when they must get things done. You must understand why they do things their way instead of your way, and you must see the beauty and wisdom of making compromises.

You review your system and the architecture you drove and put into production. You want to be connected with other architects and developers in the company. You begin to pay more attention to people around you and envision your professional development plan. You want to be a better communicator and improve your writing and public speaking skills. You make a decision to listen better and give people your full attention when they speak with you.

At the end of your first project with the company, you reflect on lessons learned and think more about the personalities you encountered—your coworkers. You understand now what motivates them and demotivates them, how they like to be engaged, their level of technical understanding, and how you will optimize their engagement in future efforts. Here is what you now observe and believe:

Sandy is a mother of three and a great artist. She has worked for 25 years in the same company and is going to retire soon. She seems to be too young to speak about retirement, you think. She is not really retiring. She is going to France to get an MBA, and at the same time, work more on her artwork. You admire her and you are glad to have worked with her to complete this project.

Bob is a “handyman” who can fix almost anything. His hobby is to restore classic and antique cars. He even hosted a team party in his home and proudly presented the “Black Beauty,” a 1928 Packard Six, model 526. He is now everyone’s friend.

Maria has been a high achiever. On the shorter days she spent at work, she drove to the bookstore to review new technology books. You want to know her career aspirations. You think she is almost ready to be an architect herself.

Karen sees things beyond her domain and enjoys the big picture. After work, she is involved in many community service organizations. She feels more blessed when she helps others.

Gary is all about the optimization and efficiency he can achieve. His mind is still working on the automation while sipping coffee. He is the sole breadwinner for his wife and four children. He has a part-time weekend job working for a local construction company that, he says, keeps him fit and trim.

Now that your first project with the company has been successfully delivered, you have been assigned as a program-level architect responsible for multiple related projects. This program consists of multiple teams who work on different systems. Five vendor packages are utilized to develop new capabilities and transform legacy systems. The legacy systems were developed 30+ years ago and have been enhanced over time. No accurate documentation exists. However, the business is dependant upon the successful operations of these systems. Many of the business rules were hard-coded using old programming languages and vendor systems. The structures can be classified as “spaghetti.” Some of the business rules are outdated.

Your program manager, Peter, is directly reporting to the company’s CIO, Chuck. You will lead multiple technical teams and are responsible for the overall architecture and technical direction of the program. Your number one challenge is that the ”stove-piped” systems do not interoperate, and these teams work mostly in silos, focusing on local optimization and efficiency. The same situation exists in other programs, resulting in functional and technical duplications and inconsistencies in the enterprise.

In addition, you face other challenges: (1) the program’s high visibility, (2) tight schedule, (3) multiple “problematic” vendor products, (4) high turnover and lack of skilled personnel, (5) too many decision makers and conflicting viewpoints that slow down progress.

You feel puzzled and pressured and cannot envision a good approach. You know you must work harder and smarter. As you scan vendor sites, analyst reports and other resources for information on new technology and vendor products, you are meanwhile expanding your circle of friends and colleagues, gaining trust and learning as much as you can. You find mentors and seek advice. You are gaining from your professional and personal network.

Throughout this engagement, if you understand what motivates the teams implementing your architectural vision, the sponsors of your effort, and your senior management, you will stay on the right track and deliver the optimal architectural solution.

Critical Thinking Questions
What are your differentiators in the work place? What are your career aspirations?
Do you have mentors?
Can you describe your company’s culture and assess how you are fitting in? Are you the change agent? What do you bring to the table that others would value?
What are your company’s business challenges?