Chapter 5. Management

“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.”

Steve Jobs

“Be willing to make decisions. That’s the most important quality in a good leader. Don’t fall victim to what I call the ‘ready—aim—aim—aim—aim syndrome.’ You must be willing to fire.”

T. Boone Pickens

“Boundary setting is really a huge part of time management.”

Jim Loehr

“People who don’t take risks generally make about two big mistakes a year. People who do take risks generally make about two big mistakes a year.”

Peter F. Drucker

“Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it.”

Steve Jobs

Have you ever asked an architect if he or she aspires to be a “manager”? Management is not a word that inspires most architects, nor is it something that most architects aspire to.

In most organizations, the exact role of an architect is usually not well defined. It is a position that clearly owns the technical responsibility for projects, but it is also partially responsible for nearly all other aspects of projects. The challenge is that the depth to which an architect needs to step in on the other areas of a project is dependent on who the other members of the team are. This is why architects many times are referred to as glue: they fill in where they need to.

This chapter unveils one of the essential skills needed by a software architect: the ability to manage the wide diversity of responsibilities that are placed upon them.

Architecture Management Defined

First, the bad news: architects are usually considered part of “management.”

Management is the active oversight of the areas for which you are directly responsible and the areas for which others perceive you to be responsible, basically, the things you are going to get called into the office of a VP to explain when something doesn’t work as expected.

The role of architect has a broad and diverse range of responsibilities within the organization (see Figure 5.1).

Figure 5.1. Key areas of architectural responsibility

Areas of Architectural Responsibility

Management from an architecture perspective is about

• Striving toward technology excellence

• Delivering projects

• Resolving issues

• Partnering with executives

• Managing your time

• Grooming technical talent

• Enhancing your skill set

These areas of management for architects are always in contention with one another. Change is a constant within these areas; the key is to learn to balance and prioritize these conflicting forces.

Striving toward Technology Excellence

Architects are the gatekeepers of technology for a business. Striving toward technology excellence can enable the technology organization to deliver new capabilities quicker, deliver them at a lower cost, enable scale as the business grows, and keep down maintenance costs. From a political standpoint, this may be more easily approached as technology sustainability when interacting with executives.

Establishing a Vision

Early on in a project or ideally before a project begins, work toward establishing an architectural vision of where you are trying to go. Even if it’s wrong, it can help guide projects and give a sense of coherence to the direction that is being pursued.

Being able to articulate this vision will help to guide not only this project, but potentially an entire suite of projects. Each project on its own may not be able to deliver the entire vision, but each may be able to help move the overall product or product suite toward an ideal end state.

Raising Awareness of Technical Debt and Funding the Right Solution

Architecture is an active responsibility within a project. You don’t just set the direction and stand back. Architects need to be actively engaged to help balance the immediate needs of the business (usually, getting it done quickly) with the long-term awareness of the investments being made (doing it right) (see Figure 5.2).

Figure 5.2. Balance the needs of technology and the needs of business.

Most projects start out with strategic intentions but, due to deadlines and budgetary constraints, consider less strategic options as the project moves closer to delivery. This pragmatic balancing of what options are to be seriously considered is crucial not only for delivering projects on time and on budget, but also for the ability of the projects to create leverageable assets for the next set of projects. As a project progresses, the key is to avoid design decisions that will unnecessarily limit known or likely next phases for a project or product.

The goal should nearly always be enabling technical excellence.

You need to be aware that the more broken windows you allow in the architectural neighborhood, the more it will set a precedent that broken windows are acceptable.

If there are valid reasons for not taking the right technical approach, the decision needs to be made transparently. It enables key stakeholders to buy into the direction being taken and level-set expectations for everyone involved about the work and the funding that will be required to do both a short-term and a long-term solution. Do your best to avoid leaving technical debt with an unfunded path to fix it.

Keeping the Technical Environment Interesting

Keeping the technical staff engaged and learning is one of the best ways to help with retention. Although they most likely do not report to you, finding ways to incorporate new technologies and approaches in a nondisruptive fashion will naturally keep up the level of engagement for most technologists.

The challenge in most of this is timing. There are natural spots within most projects to incorporate new things (usually near the beginning of the project or the start of a new release). The key is to ensure that you have a sufficient amount of time to recover from any unexpected issues and to limit the number of changes that are introduced at one time. If too many things are changing, it can be very challenging to figure out the root causes of issues that are surfacing.

As always, being transparent about what you are doing will help keep everyone on the same page and help to avoid future conflicts.

Finding Potential Patents

Have you engaged the legal department about any interesting ideas that you are pursuing for your design? Are there patents that should be filed? Are there provisional patents that should be applied for?

Protecting your business’s key technology assets can create a strategic advantage over your competitors. As new projects come into your portfolio of architecture work, meet quarterly to semiannually with the patent attorneys to review new ideas and approaches. They will usually have a sense of whether your novel design approach is patentable and if the idea is in an area where the company wants to invest in patent protection.

The best approach I have found is to simply sit down on a regular basis with the patent attorneys and describe the projects I am working on. They usually are familiar with the overall patent portfolio and have a sense of what is interesting and unique. If they show interest in a particular area, we will dive into more detail. If they run into something truly interesting, they will usually go off for a few weeks and return if they want to consider filing a patent for it. The key is to have these conversations before the details of the technology approach are broadly known. Once the attorneys have decided to move forward, I usually spend many hours reviewing the documents and all of the details to ensure that the appropriate scope, language, and diagrams are in place for the patent. It’s always interesting to see how lawyers describe the work you are doing or have done.

Seeking Data Center and Operations Support for Your Direction

As you seek to inject new technologies and capabilities into the organization, you need to ensure that the end product is operationally ready. Taking the time to work with data center and operations teams early on and letting them know the direction you are taking can establish a partnership for finding the right solution and for ensuring that the right tools and training are in place for them to do their work.

For instance, does the new database technology you are looking to introduce support the multisite, multimaster replication that your architectural style is dependent on? Do the new tools and technologies have the appropriate logging, monitoring, and alerting features to enable the operations team to quickly diagnose where there are issues in the middle of the night (or do you want to get that call and be on a pager)?

This partnership with operations can help identify issues that may help drive vendor decisions, vendor support, vendor product changes, and configuration standards before you are rushing toward a release. Partnering early on with the operations team can help vet issues that may ultimately determine if your project is successful.

Generalizing the Solution

There is often a more general form of a solution that can be created. If this is possible and there are other likely scenarios that leverage the more generalized solution, strongly consider this as the implementation path. Generalized solutions can help save the company money in the long term by reducing the amount of software that needs to be created and subsequently maintained.

Making It Strategic

If there is a clear strategic solution, you should work hard to put that solution in place. It is rare that the dates that are being bandied about for delivery are as real as they are portrayed. Sometimes just taking that extra time and putting in the right solution can save you from a massive refactor later on and let you be done with the capability instead of adding technical debt.

If it simply is not possible to put the strategic solution in place, take the time to think through the approach you would take for the strategic solution and try to avoid putting in unnecessary roadblocks to implementing it in the future.

Leveraging Solutions

It is rare in the software community that something hasn’t been done before. Take the time to investigate what existing solutions are available. Is the business willing to adjust its requirements to match an existing solution if there is an opportunity to save money?

Leveraging solutions may not always be the cool or fun thing to do, but it will raise the business’s level of trust in you and enable the business to invest the money saved in other ways.

Delivering Projects

Projects are the lifeblood of any technology organization. The organization’s ability to deliver projects in a timely and cost-effective manner is essential for its success.

Partnering with the Project Manager

One of the best ways to successfully drive projects is to partner with the project manager. Project managers are usually in charge of delivering the official communications with respect to the project, coordinating resources across multiple areas, and overseeing the schedule of the work that needs to be accomplished.

By partnering with the project manager, you can join forces to ensure that

• The messages that are being delivered to the stakeholders are consistent with your communication, especially when issues arise

• The work on the project is prioritized according to key dependencies

• The right people are working on your projects at the right time

Eliminating Dependencies Ruthlessly

One of the hardest things to manage on any project is dependencies. As you encounter dependencies in your architecture, your projects, and your code, learn to attack them ruthlessly. The fewer dependencies you have, the better shot you have at being in control of your own destiny (see Figure 5.3).

Figure 5.3. Be ruthless about eliminating dependencies; they often constrain your ability to deliver projects.

However, there are times when dependencies make sense, for instance, when

• The investment to eliminate the dependency is much higher than incurring the time, budget, or resource hit necessary to keep it

• The functionality or capability that the dependency brings is essential to the project, and no reasonable alternatives exist

Managing Expectations

From a technology perspective, it is easy to get caught up in all of the great qualities that surround new technologies and new approaches. The challenge is that it is easy to overhype and overpromise what adding these things to a project will accomplish.

As an architect, you need to manage expectations and ensure that as you sell certain technology solutions you have left room in the project for things to go wrong. In addition, you need to ensure that you will have enough time and resources to work through and deliver all of the great value that you promised.

Mastering the Development Process

Although architects may not be developing code every day on a project, there is an expectation of mastery of the overall development process. (For the development process cycle, see Figure 5.4.)

Figure 5.4. Scrum: find a process that is effective for both technology and the business.

Architects should be involved with determining

• What methodology will be used—agile, Lean, Kanban, something else

• What development tools will be used

• How the system will be built, deployed, and tested

• What development teams will be involved during estimating, build, and testing

• What the core use cases (epics) of the system should be

Architects should be actively involved in determining the overall software development life cycle, its associated tools, and its execution. By being actively involved, technology will be able to be better aligned with the needs of the business and better aligned for overall success.

Being Where the Problems Are

Generally speaking, as an architect, if things are going well in a certain area of the project, you are usually not as critical to that area. In contrast, the areas of the project that are struggling or having significant issues can benefit from your leadership and problem-solving skills. By jumping in and working in the areas that have the most problems, you can help remove roadblocks, provide alternative approaches, and connect the team with others who are experts in the areas where they are having issues.

If truly project-threatening issues are being encountered, you will have firsthand knowledge of the situation when the executives want to dive in and learn more about what is going wrong.

Being Aware of Nontransparency on Your Projects

As an architect, you can’t be everywhere at once. At some point, you have no choice but to trust what others are doing. The challenge is that decisions are being made all the time that are directly or indirectly your responsibility, and even if you are not there, you will be held responsible.

As these decisions are being made, it is usually not an issue if you learn about them in a reasonably timely manner. You at least have an opportunity to correct course or have enough wiggle room to adjust course if things go south. However, some people really want to make the decisions and won’t like the decision you are likely to make. They may choose to make a decision without your involvement and include you only when they get in over their heads. This may or may not become an issue, but if you have to routinely correct or jump in and rescue certain tech leads’ decisions, you need to address this first with the individuals. If that is not effective, you need to engage their management. If you let these situations slide, your reputation is potentially at stake.

Limiting the Number of Contractors in Leadership Positions

Contractors are great resources to help staff projects with skills that are missing, to help fill a bubble in the amount of work needed on a project, and to help get a project moving quickly. The challenge is that contractors eventually leave and move on. If you have contractors in key leadership positions, when they leave, you may have a void in your long-term knowledge of that area, may encounter a lack of understanding as to why certain decisions were made, and may be left with a system that is unnecessarily biased toward the latest and greatest technologies due to the contractors’ needing to prep for their next gig.

Most contractors do an excellent job, but having employees in leadership positions on a project helps

• Train the employees on why certain design decisions were made

• Balance business domain needs with technology decisions

• Maintain the long-term continuity of the project as the number of contractors ebbs and flows

I have seen projects (fortunately not mine) with over 75% contractors, including many in leadership positions. Those projects didn’t turn out well. I usually like to have 10% to 20% of the staff on a project be contractors. They typically bring in a different perspective on technology approaches, have a broader set of experiences, may have skill sets that you don’t have, and generally have a lack of fear of jumping into unknown areas.

Providing Technical Management (Areas of Responsibility)

Architects are responsible for the technical aspects of projects and platforms. Some of the chief areas of responsibility for architects are

• Managing and communicating technical direction and architectural approach

• Managing and communicating system boundaries

• Managing technical intergroup dependencies

• Working with the data center on hardware acquisition and configuration

• Working with procurement and sourcing on licensing and other vending needs

• Reviewing and helping develop business case estimates

• Helping identify and manage project risks and issues

• Establishing the big architectural rules/principles

• Overseeing contractors and possibly other architects

• Communicating architecture-related items to executives and other management

• Working closely with both the business and technology

• Working closely with development teams

• Ensuring proper project governance and oversight, including standards, guidelines, reviews, design principles, and design qualities

• Ensuring the privacy and security of user data

• Ensuring that system “-ilities” (nonfunctional requirements) are properly addressed

• Ensuring proper development life-cycle adherence

• Leading spikes and other technical investigations

• Working with project management to work through budgets, schedules, timelines, and resource needs

• Leading software and hardware selection for projects

• Working closely with the testing organization for various testing needs

The goal of architects is to provide technical management for projects and ensure that the software aligns with business goals and an appropriate level of technical excellence.

Managing by Walking Around

One of the best ways to successfully deliver projects is to manage by walking around. This simple act of meeting people and dealing with items in the moment not only keeps things moving quickly within the project, but it gives you a better sense of the real items that need to be addressed immediately within a project.

In a one-on-one setting, nearly everyone feels comfortable expressing concerns or asking questions, whereas they may not feel comfortable within a group. This short-circuiting of information needs helps keep both you and your team highly effective.

Managing by walking around includes stopping by and talking to everyone related to the project, including executives, on a regular basis. For me, just stopping by without an appointment and talking helps build good relationships and gives a much better sense of the heartbeat of the project than nearly anything else I can do.

Managing by walking around is a great way to fill in some of the time between meetings or when I just need to get away from my desk for a while. This movement helps me get past roadblocks that I may be encountering or helps me quickly track down answers that could take hours or days if they were dealt with through e-mail.

Resolving Issues

One of the chief responsibilities of an architect on a daily basis is to resolve issues on projects.

Asking the Tough Questions

On every project, there are always areas that everyone wants to shy away from due to either the political environment or a desire for conflict avoidance. As an architect, you are responsible for asking the tough questions and raising the issues so that they can be dealt with.

As you address issues, avoid making statements; instead, craft what you are seeking as a series of questions. This approach allows you to avoid presuming information to be factual and allows for a discussion to begin. Take time to qualify the questions with the context of why you are asking them. It can help defuse some of the political tensions. The questions can also lead the people who are involved with the discussion to open up to other alternatives that they may not have considered in the past.

The goal is to clear a path so that obstacles can be removed and transparency can exist throughout the project. This won’t always make everyone comfortable, but it will enable people to do excellent work and level-set expectations for everyone on the project.

Dealing with Problems in the Moment

Architects need to jump in and address the elephant in the room when no one else is willing to. You either get to deal with it now or it will surface later; and later on, it will likely be more painful to deal with.

Architects are expected to get down into the details.

Learning to deal with problems in the moment helps in two key ways. One, the backlog of things to deal with stays short. Two, no one will take inaction as your indirect approval for the direction or course that things are on. It also sends a clear message that issues will get dealt with promptly.

Dealing with conflicts in the moment will force you to have thick skin.

Saying No, but with Options

No one likes to hear no in answer to a request. A better approach, if possible, is to say, “Here are the acceptable alternatives” (see Figure 5.5). This allows the other party to have some control over and say in the direction that is chosen. It also naturally helps with buy-in. The person may not get his or her first choice but at least was able to participate.

Figure 5.5. Don’t just say no; give options.

This puts more work on you, but it also forces you to work through the real issues with a request and determine what other alternatives are plausible that can achieve the same or similar objectives. If alternatives are not possible, it at least makes for a more in-depth conversation as to the rationale behind the decision and allows you to explain what alternatives were considered and why they won’t work.

The options may also be a way to introduce a better overall option. It may take some convincing, but it is best to keep the door open to some dialogue as opposed to alienating someone you are likely to need to work with in the future.

Most people are willing to accept detailed and conscientious thought behind a response. If not and you are challenged, you should have a defensible position.

Striving to Be Consistent in Your Decisions

The decisions you make as an architect affect many people. It usually takes time to ensure that everyone understands what the architectural approach is for a project, what the assumptions are, and what the risks and dependencies are.

Invariably as the project progresses, you learn new information about the project, information that if you knew it at the outset would have caused you to pick a slightly different path.

The challenge as an architect is to weigh a change in direction very carefully. If the current direction meets the business needs and changing direction will be costly in real terms or in terms of communication and alteration of existing plans, it is usually best to keep the current course.

Think about what you could have done to learn this information earlier. No matter what you do and no matter what process you follow, there is only so much information available at any given time, and you need to make the best decision you can and execute.

If you do have to change direction, ensure that the executives and those in leadership who are affected by the change are on board.

Using executive validation as a decision gate will help keep you from waffling on your decisions.

Learning to Deal with Things Head-on, Cards Faceup on the Table

Architects usually have very limited amounts of time. When it comes to dealing with issues, negotiating, selling, or general problem solving, the best approach is normally to be straightforward.

Putting your cards on the table faceup gives you a lot of flexibility. The person you are interacting with knows what is going on, knows that you are acting in good faith, and knows you mean business.

When you learn to work in this manner, you don’t have to worry about having told different people different stories; your story is always the same. This gives you a distinct advantage: others can see your cards and there are only so many ways to play the hand. They also know that you know there are only so many ways they can play their hand.

Since you have acted in good faith to begin with, they are more likely to operate in a similar manner.

Act with integrity, and you will earn the respect of others.

Knowing What You Are Willing to Cave On When Negotiating

Architects have to learn to negotiate early on; it is essential to success to be able to give and take on a project. The key is to know what is critically important to you and what is less important. As you negotiate with the business or with other business units, you have to know what areas are nonnegotiable. On the other hand, if you absolutely have to give on one item, you need to know in advance what you are willing to give up to reach consensus on a decision.

Being Willing to Challenge Areas You Don’t Agree with (Respectfully)

During meetings when you are working toward a solution in a particular area, you need to be willing to challenge decisions that are about to be made when you don’t agree with them. You may be surprised that many others share your concerns but are being cautious about voicing dissent. You owe it to the business to make your concerns known—not to derail the conversation, but to make sure that the right decisions are made.

You are almost always better off asking the tough questions within your group first because when the solution is reviewed by executives, you can be assured that they will ask the same questions. If you don’t have a solid answer as to why some option wasn’t considered, you will have some very unhappy executives on your hands. This lack of thoroughness will erode the trust executives have in you and your team.

Being Willing to Stand Your Ground

As an architect, if you truly believe that something is the wrong direction or the right direction, you need to stand your ground and fight for what you believe in, even if it’s just a gut feeling. Others need to be able to adequately argue their positions well enough to convince you to change. If you need to raise the issue up to management to get a tie-breaking vote, that is an acceptable path, although in my experience, you are better off resolving it among yourselves. You will rarely be happy with the executive’s decision.

Knowing What Is Not Your Problem

There are times when the fight that is being fought is not your fight. Although you may have an opinion on the matter, if it is truly not your issue and the others have not invited you into the debate, letting them work it out themselves is usually the right path. If they want your opinion, they will ask for it.

Partnering with Executives

Executives play a critical role within any organization. They thrive on trust and have a strong need to have a finger on the pulse of the organization. One of the best ways for you to ensure success for both you and the executives is to become partners.

Managing Risk through Transparency

One of the best ways to manage risk on a project is to approach the risks with complete transparency to executives. Before a project begins and throughout its life cycle, keeping executives up to speed on risks is critical to your success.

As soon as you know about a major new risk or a change to a known risk, you need to bring it to the attention of the executives. This will give them the maximum amount of time to react and “help” if they think it is necessary.

Giving executives late notice of a risk when there is little or no chance of changing the outcome will not be dealt with positively and will reduce their trust in you.

Reviewing Estimates

Before estimates for a project are widely distributed to the organization, make sure that the executives over your area have had a chance to weigh in on them. They may know of other factors, assumptions, and risks that need to be considered for the project that is being proposed.

By reviewing the estimates with the executives in advance, you give them a chance to ensure that the project is aligned with the organization’s goals and any recent developments that you may be unaware of. Projects are a commitment of resources by the organization, and they need to be aligned with the executives’ thought processes.

As always, the last thing you want to do is publicly surprise executives with information (i.e., the details of the estimate) that they were unaware of, especially when they begin to get questions about the estimate for clarification.

Limiting the Number of Boxes on Diagrams

When presenting architectures to executives, you are usually better off leaving out the details of architectural diagrams and giving an extremely high-level view of the architecture, ideally keeping it to four or five boxes on the diagram. A simplified diagram will give them a sense of the key components. If they want more detail, they can always ask for it.

Think of this diagram as an architectural elevator speech—something that can be explained in less than two minutes.

Raising Technology Awareness

Part of your job as an architect is to keep executives and management briefed on technology. This is more about where the industry is going, what key trends are occurring, and how you are using technology that relates to key trends that would be mentioned in the CIO Hype Cycles or trade magazines.

You also want to keep the management staff up to speed on what other groups are doing with respect to technology advancement. Once another group introduces new technologies, the odds of being able to introduce the same technologies in your area can increase significantly because the operational aspects of the technology have already been addressed.

Having Your Boss’s Back

In nearly every situation, you should work toward advocating for your boss’s positions in terms of direction and boundaries. If someone is challenging your boss’s choices, you need to come to your boss’s defense. You may not always agree 100% with your boss, but when he or she is not present, you need to maintain your mutual trust. If you have issues with your boss’s positions, you should take them up with your boss directly. If you fail to change his or her mind, you need to suck it up and be an advocate for the boss’s position. Doing so will also let others know that you act with integrity with respect to your organization’s wishes.

Avoiding Interrupting Executives When They Are Talking

Most executives are highly sensitive to being interrupted when they are talking. Wait a little past their normal pauses when they are speaking. It will make for a smoother conversation if they feel they have been listened to and have had the chance to fully express their thoughts.

Being Confident

Most executives have a sixth sense about areas in which you lack confidence and are likely to delve into those areas. They are likely to perceive your lack of confidence during a conversation as an area that contains an abundance of risk and will want to focus on that area, when in reality, you may just be nervous about interacting with an executive. Learn to sit up straight, keep your shoulders back, keep your feet directly under you when you are sitting, and look at the executive directly when you are talking. If there are areas of risk, bring those up early on in the conversation. It will make them more confident in you and help establish trust.

Managing Your Time

For most architects, there are more projects, more estimating, more consulting to work on than there is time in which to do the work. Fortunately and unfortunately, there are only 24 hours in the day. The limited amount of time you have forces you to be highly effective in your time management.

Limiting the Number of Projects to Which You Commit

There always seem to be more projects than there are architects to oversee the work. As an architect, you need to be selective about the projects to which you commit. You need to ensure that, first and foremost, you have enough time to commit to truly owning a project before you take it on.

If you already have several projects that are consuming the majority of your time, you are not doing anyone a favor by taking on yet another project.

If the business has committed to doing a project, it needs to ensure that there is enough technical staff to execute the project; the business may simply be looking to you as an architect to be an insurance policy if things go wrong.

Your reputation is on the line for every project to which you commit. Make sure that you are willing and able to commit for the long haul and have the time to ensure that the project is delivered and delivered right.

Defining Your Role and Bounding It

Architects have wide and varying roles within an organization depending on the needs of a particular project. Given this fluidity, architects need to clearly define their role and their responsibilities. Limiting your responsibilities can help ensure that you have sufficient capacity to deal with the many demands of multiple concurrent projects.

Prioritizing Where to Engage Your Time

Deciding where to engage and not engage among multiple conflicting projects can be challenging. When it comes to conflicting meetings, consider:

• Who is attending the meetings? Generally speaking, if people from outside your company are attending and you are expected to be an active participant, attending should be one of your top priorities. Next, are members from outside your business unit attending the meeting? After this, consider which meeting includes the highest-ranking executive. The goal is to be in the right place at the right time (it’s not always clear). Ensuring that you are delivering a positive image and brand to external entities and to executives is critical.

• Can the meeting be rescheduled? If so, ask people in your own business unit to reschedule first. You likely work with them on a regular basis and can more easy work through scheduling conflicts with them.

• Is this a regularly scheduled meeting? If this is not a regularly scheduled meeting, and there are key issues or decisions that need to be made, this meeting generally should be considered a higher priority.

• Do these regularly scheduled meetings have conflicts? If so, consider alternating between them or even attending the first half of one meeting and the last half of the other meeting.

• Do you really need to attend? If there are people with whom you feel comfortable making decisions for you at the meeting, you may not need to attend. Be cautious with letting others represent your views. Make sure you interact with any individuals to whom you are delegating responsibility. In the end, you are still responsible.

Above all, make sure you are communicating clearly to the organizers of the meetings whether or not you will attend and if not, who will represent you. If you cannot attend a meeting, ask for a summary of key meeting items, key decisions, and any action items. This information will allow you to follow up with others as needed and allow you to know the context of the next meeting if there is one.

One of your most effective tools in time management is simply to say no. If you do not have the time to deal with something and you cannot easily adjust your current commitments, simply letting others know that you cannot take on additional work is very effective.

You need to be careful about saying no. Sometimes the additional work could be an opportunity to do something that you really want to do. The key is to avoid spreading yourself too thin and having all of the balls you have up in the air come crashing down.

Although architecture is a very important aspect of the lives of architects, there are many other important areas of life as well, including family time. Being engaged in other activities outside work helps keep you more interesting and helps put into perspective some of the daily decisions that need to be made.

As a general rule of thumb, try to pick a reasonable time to leave every day. It is okay to work on things later in the evening, but try to have a consistent off time (there may be exceptions to this such as when an important release is coming up). If you don’t get away, you have a real chance of burning out.

Learning to Make Decisions on Limited Data and with Limited Time

As an architect, you rarely get a chance to get all of the information you would like for a decision. The best you can normally do is to time-box the research or investigation. If possible, consult with others who have encountered similar situations.

When the time is up, you need to make a decision.

Sometimes, making a decision simply comes down to trusting your gut feeling. It doesn’t necessarily give you a great amount of comfort, but in most situations, making a decision in a timely manner is more important than trying to make the perfect decision.

Long decision cycles are often met with false expectations and can also make management feel as if the project is dragging on.

Attending Meetings Only If You Are an Active Participant

For nearly any meeting, unless you are going to be an active participant and take the time to engage in the conversation, it is not worth your time to attend. Learn to either speak up or leave.

Getting a Deadline

When I get a request to do something, before I agree to do it, one of the first things I consider is when it is due, and if I have the time available to actually deliver what is being requested of me. If I don’t feel I have sufficient time to deal with what is being requested, I will say no or request a date that enables me to ensure that I can deliver it.

Delegating to Those You Trust

To help manage the many demands on your time during the course of a day, try to find members of the team in whom you have a high level of trust and who can represent your views if you are not present. These are the individuals to whom you can delegate responsibility on a project and let them grow in the amount of responsibility they have. It will give them an opportunity to build their skills, and it will give you some additional time in your busy schedule.

Meeting in Person

One of the best ways to quickly resolve issues and gain consensus on a direction is to simply meet in person. If you can’t meet in person, try to meet by some form of virtual means so that you can see each other face-to-face. The ability to see how a person is reacting to what you are saying can enable you to quickly adjust the direction of the conversation and avoid any misunderstandings.

If possible, avoid e-mail except for communicating the decisions and consensus agreed upon.

Meeting in person can save you a significant amount of time in the long run even though it may be a bigger commitment up front.

Grooming Technical Talent

Part of the responsibility of an architect is to help groom the technical staff for moving up in the organization and to help maintain a solid base of technologists within an organization to enable great software to be created.

Having an Architecture Mentorship Program

At Thomson Reuters, I help run an architecture mentorship program. This program includes architects, technical leads, and others who have an interest in the area of architecture. The program focuses on three core areas:

• Broadening business knowledge. In this area, we focus on bringing in speakers from different areas of the business (finance, marketing, strategy, and other areas). The goal is to give the technical staff a sense of the broad range of what is going on within the business outside of technology.

• Introducing emerging and core technologies. In this area, we focus on bringing in new or core technology experts who can broaden the solution tool set and help make new technology connections for emerging technologists. This can include bringing in people from the data center, research and development, and other areas.

• Architecture panel discussions. In this area, we focus on discussing common or current architectural issues in a panel setting. This allows for an open conversation about how different architects are thinking about and approaching different issues.

The goal with the architecture mentorship program is to develop a sense of architectural community that invites up-and-coming technologists to learn and develop the skills to move into an architecture role. It also helps other architects to see different ways of thinking about projects and to share their experiences.

For me, mentoring is a great way to give back to the organization and help build up the next generation of talent. I usually end up learning at least as much as if not more than the mentee, and helping out others tends to be a highly rewarding experience.

Having a Technology Forum

At Thomson Reuters, I also run a tech forum series. This program is a place to help raise technical awareness in the organization. It serves multiple purposes:

• To let up-and-coming technical talent get up in front of a large group and show off cool technologies

• To give everyone in the business unit a chance to see live coding and help raise awareness of what technologies are currently in use and how they are being used

• To promote your area as a cool place to work and attract others within the larger organization to want to work in your area

• To expose up-and-coming technical talent to the executives and senior management

Encouraging Members of Your Technical Team to Attend Local Conferences and User Groups

You want to encourage the technical members of the teams you work with to be active in the local technical community. It will allow them to keep their skills current and help them grow the network of technical people they know. It will also help establish your company as an active development community and should help attract others to be interested in considering your company as a place to work.

Hiring the Best People: Don’t Just Fill a Position

Hiring the right people is critical for your current projects and more importantly for your future projects. When interviewing, take the time to look for

• Candidates who can whiteboard. You want people who can get up to the whiteboard and coherently draw a solution they have previously helped create. They should be able to answer detailed questions as to why it is structured the way it is and what other alternatives were considered. You want to get a sense of how they solve problems and how well they can describe the solution. You also want to get a sense of whether they can think on their feet. How well did they sell their solution? Does it seem believable?

• Candidates who can articulate why and when to use technologies. This includes being able to explain the pros and cons of the technologies they use, when to consider using them, and when to avoid them. People in technology should have very distinct opinions about technologies. They should know the current versions of the software they use and the key features that have recently been added. You want to know that they know more than just the keywords that were in the job posting.

• Candidates who are sociable. Interacting with others is a daily activity for every developer. If candidates cannot reasonably socialize with you, you have to question how well they will be able to rise within the organization (building relationships quickly and easily is essential).

• Candidates who can explain how they go about solving problems. They should be able to describe what some of their worst problems in technology have been and explain in detail how they worked their way out of them. Listen closely for the language they use and the depth of detail provided.

• Candidates who can describe what your business does and how it makes money. You want someone who can do at least basic research.

• Candidates who can describe how they interact with management. They should be able to describe what their thoughts are about being questioned about the approach they took to a particular problem (architects get questioned about their approach all the time). Are they defensive or do they shoot straight and get to the point quickly? Getting defensive is definitely a warning sign.

• Candidates who can describe how they stay current with technology. Ideally, the answer is they like to play around with technology in their spare time and have evidence of that.

Your ability to hire and attract developers who are passionate about software development is critical for keeping your business technologically current and the workplace a fun place.

Enhancing Your Skill Set

As an architect, it is easy to get caught up in the endless demands of others on your time. If you are not careful, they will consume every last second of every day and leave you no time to maintain and enhance your own skill set.

Sitting with Other Architects

Regardless of the size of your organization, you may want to consider locating your cube near other architects. Having the opportunity to overhear and become involved in architecturally related conversations during the course of the day can help you to keep current with what other areas of the business are encountering. This will help enable you to hear common problems, and to start formulating new capabilities that may be shareable across different projects or products. It will also enable you to hear about technologies that are being contemplated in other areas.

Sitting with other architects is a cheap and efficient way to help you stay current with the business and with technology.

Doing Something Technical Every Day

Take some time every day to do something technical. Usually early in the morning or later in the afternoon when the core of meetings, stand-ups, and impromptu questions end is a great time to dive in and do some research or try out some new technology that you are not familiar with. If worse comes to worst, take some time later in the evening to play around with something new.

Go to a conference; watch a webinar; read a blog; read an online magazine. All of these things will help keep you up to speed with what is going on in the industry and keep your technical skills sharp.

Staying up on technology is one of the best ways to ensure that you do not become obsolete.

Focusing on What Scares You

During the course of projects, some areas rise up that create a certain level of uncertainty for you. Take the time to investigate and play around in these areas enough that you are comfortable and have a base level of knowledge about them.

Becoming an Expert in an Area

As an architect, you will develop a brand for what you are good at and for areas where you are weak. Consider what brand you want to project within your business and within the industry where you work. Once you have a sense of how you want to be branded, work toward crafting this brand by becoming an expert in that area.

Consider writing a blog or giving presentations at conferences in this area as a way to help reinforce the brand you are trying to promote.

Looking for Projects Where You Can Grow Your Skills

Architects need to be constantly honing their skill sets. As you see projects that are coming down the pipeline at work, have a sense of what projects will enable you to grow, and actively lobby to be on those projects. If the projects at work are not able to provide you with the growth you are looking for, there are almost always projects outside of work that can use your passion and expertise.

There are often open-source projects or volunteer opportunities where people and organizations will be thrilled to have you dive in and help them solve their technology problems. You will get a chance to learn, and they will get some help on much-needed technology challenges.

Summary

The road to management begins with

• Striving toward technology excellence

• Delivering projects

• Resolving issues

• Partnering with executives

• Managing your time

• Grooming technical talent

• Enhancing your skill set

In the end, management may not be an aspirational word in your vocabulary, but it is an essential function for you to deliver on the responsibilities with which you are entrusted.

References

Anderson, David J. 2010. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.

Appelo, Jurgen. 2011. Management 3.0: Leading Agile Developers, Developing Agile Leaders. Addison-Wesley.

Berkun, Scott. 2008. Making Things Happen: Mastering Project Management. O’Reilly Media.

Duvall, Paul M., Steve Matyas, and Andrew Glover. 2007. Continuous Integration: Improving Software Quality and Reducing Risk. Addison-Wesley.

Humble, Jez, and David Farley. 2010. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley.

Hunt, Andrew, and David Thomas. 2007. The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley.

Nygard, Michael T. 2007. Release It!: Design and Deploy Production-Ready Software. Pragmatic Bookshelf.

Leffingwell, Dean. 2007. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley.

Rasmusson, Jonathan. 2010. The Agile Samurai: How Agile Masters Deliver Great Software. Pragmatic Bookshelf.

Rothman, Johanna. 2007. Manage It!: Your Guide to Modern, Pragmatic Project Management. Pragmatic Bookshelf.

Rothman, Johanna, and Esther Derby. 2005. Behind Closed Doors: Secrets of Great Management. Pragmatic Bookshelf.

Rubin, Kenneth S. 2012. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Addison-Wesley.