Follow Me!


Michael Chiviendacz, CD CISSP ISSPCS

April 2007

Summary: A leadership approach that is based on principles is flexible and widely applicable to many situations. You should make an attempt to understand and apply the 10 principles of leadership that are presented in this article. (9 printed pages)

"The captain of a ship is not chosen from those of the passengers who come from the best family."
–Blaise Pascal


Ten General Principles
Task Appreciation
Final Thoughts
Critical-Thinking Questions
Further Study


Situation: You have been a solid technical contributor to your organization for a few years. You have been given opportunities to learn new technical skills, and are relied upon to know new technologies and how they affect the business. In short, you are a successful software architect, and you have been noticed for your technical acumen. Your boss's boss calls you in and tells you that your boss has decided to pursue opportunities outside the team and is leaving. Would you like the job? Your gut tells you this is the opportunity you have been waiting for, but you are nervous. You have never led a team before, never had to make hard decisions or been responsible for more than your own performance. As the team lead, you will be responsible to make sure your whole team performs well. You have to keep them motivated, interested, and on course. You need a crash course in leadership to understand the best way to do it.


This happened to me—twice. The first time, I was asked to switch from being a team member to being the team's manager. The second time, I was given the opportunity to take over my current position of Chief Architect (Professional Services) from the incumbent, who was leaving the organization. Both jobs required me to be a leader, but both required very different leadership skills. As a team manager, I had to monitor and manage the performance of the team members and keep them motivated. I also had to care for their careers and ensure that they had the right mix of interesting work, training, and opportunities to push the edges of their personal comfort zones. As the Chief Architect, I sometimes have to play the devil's advocate when my former team (and their new manager) works on projects for which I am the architect. I find myself having to question their approach and estimates and ask for justification. I now have to advocate for the client more and influence multiple teams across very different disciplines (software development, marketing, support, professional services, and so forth). All of this requires leadership.

Leadership Wears Many Hats

Successful software or system development requires many different disciplines: requirements gathering, analysis, design, programming, test case design, test execution, technical writing, lab setup and maintenance, installer development, risk analysis, progress monitoring, and many other skills. Above all though, it requires leadership. An orchestra is full of highly skilled and valuable individuals, but it takes a conductor to make it an orchestra. Somebody has to lead. To make a long and successful career of being a software architect, most of us will eventually have to develop some level of leadership skills even if we do not directly manage a team.

Consider that an architect must:

  • Provide technical leadership.
  • Be a thought leader.
  • Be a champion for the architecture.
  • Be an advocate for the client.
  • Manage a team.

An architect's role might change from company to company or project to project but, sooner or later, the answer turns out to be "All of the above."

Consider the following situations:

Providing technical leadershipThe architect might be looked to for a decision in terms of choosing one technology over another, to deliver a project or implement a corporate system or service. The architect must be able to answer the question: What are the relative strengths and weaknesses of each solution?
Being a thought leaderThe architect might propose a new process that changes the way a business unit looks at the way they deliver services to their clients. The architect must be able to identify deficiencies in the current process and convince their audience of the benefits of the new process. The architect might be required to mentor team members as they get used to the new process.
Championing the architectureThe architect might have to influence the team to follow a particular architecture, even though they might not see the wisdom in it ,or they have competing objectives.
Advocating for the clientThe architect needs to influence and, sometimes, cajole different (sometimes competing) parts of their own organization to achieve the right solution for a client.
Managing a teamThe architect might lead the implementation effort and manage the day-to-day execution of a project.

Table 1: Examples of various roles played by architects

So, an architect is looked to for leadership in a number different ways. If you boil it down, however, there is a common thread that runs though this: influencing people and, sometimes, acting as a trusted advisor. No matter how you look at it, you can't lead without followers.

Ten General Principles

Let's start by defining leadership.

Leadership is the art of influencing human behavior, so as to accomplish a mission in a manner that is desired by the leader.

Great, but how? This article will present a simple framework of principles and tools to help architects navigate the sometimes difficult task of being leaders in their organizations.

An approach that is based on general principles seems like a good place to start. Principles provide a framework for decision-making that is not constrained by being too specific to a particular situation. The resulting framework is, therefore, widely applicable and flexible enough to provide a useful tool in the many roles that architects might undertake in their organizations.

Let's consider some principles that apply equally well to any leader, any organization, and any situation [CFP, 1973].

Lead by Example

From time-to-time, late nights and early mornings are required on any software project. Do not expect more of your team then you would give yourself. This means sharing in their hardships. This also means being a mentor and example of leadership to your team.

Seek and Accept Responsibility

Look for areas where your influence and experience can help in your organization, and offer to help. Do not over-extend yourself by volunteering for every project or requiring an 18-hour day of yourself as a matter of routine; but, from time to time, look for ways to prove your worth to your organization by volunteering your guidance and expertise. The flip side of seeking responsibility is accepting it. This means two things:

  • Do not be afraid to accept an assignment that might push your own boundaries a bit, you will grow and learn.
  • When you mess up, admit it, and be prepared for the consequences. Hey, nobody said that leadership was easy!

Appreciate Your Own Strengths and Limitations, and Pursue Self-Improvement

Nobody can know it all. As a leader with technical, human resources ,and organizational responsibilities, it is important that you perform a critical self-assessment from time to time and reach outside of your comfort zone to work on those areas in which you must improve or build experience. In fact, the reason that I accepted my current position is that the job description included duties and responsibilities that were outside of my own comfort zone.

Know Your Team, and Promote Its Welfare

The days of the autocratic boss who barely knows the employees' names are, for the most part, over. As a rule, employees in our industry are highly educated and highly skilled, and they expect more than a paycheck out of their jobs. They want challenging work, they want opportunities to learn and advance, and they expect (and deserve) respect from their boss. Some ways of accomplishing this are the following:

  • Get to know your team members' lives outside of work, so that you can discuss things with them. What are their hobbies? Do they have kids? Do they play sports?
  • Get to know and understand your team members' non-verbal communication styles, so that you can understand when they are upset or under stress, and so that you can offer assistance, if appropriate.
  • Do not volunteer your team for extra work just to try to impress your own bosses. Your team members will quickly understand what you are doing, and you will lose their respect.
  • Do not accept credit for the fantastic ideas of your team. If one of your team members comes up with a great idea for a better mousetrap, make sure that everybody knows that it was their idea.

Employ Your Team to Its Capabilities

Like the leader, each team member will have their own strengths and areas that require improvement. It is up to the leader to understand these and to ensure that the proper mix of skills is applied to any given project. Employees must be pushed to the edge of their comfort zone from time to time to help them develop.

Make Sound and Timely Decisions

Sooner or later, you will be asked to make a decision when you do not have all of the information that you would like to make that decision. It will happen, so you must be prepared for it. Understand and communicate the risks, but do not get paralyzed by the fear that you do not have all of the facts. Above all, make a decision, and move forward.

Achieve Professional Competence

This is all about Technical Leadership. You must keep abreast of recent developments and the state of the art to make the best architectural decisions on behalf of your organization or client. Subscribe to trade magazines and participate in professional associations. Another good way to ensure professional competence is to set up your own lab (it's easy with virtualization these days) and experiment with the technology.

Communicate with the Team

Ensure that your team knows your meaning and intent, and lead them to accomplish the mission—three words: communicate, communicate, communicate! Make sure to explain the architecture, design, or project execution to your team (and sometimes the client) from a couple of angles. The easiest way to ensure that your team knows what you expect from them is to ask. For example, after outlining the assigned project tasks to the team, ask each of them specific questions about the task you have assigned to them. Their answers will help ensure you've made your meaning and intent clear. Once your team is clear on what is expected of them, monitor their progress and ensure that they follow through with their assigned duties.

Keep your team informed of the mission, the changing situation, and the overall picture. Get out of your cube or office and speak to your team members face-to-face instead of just using impersonal e-mail or telephone calls. You can not read non-verbal cues unless you can see the person you are speaking with. practice management by walking around (MBWA).

Develop the Leadership Potential in Your Team

Your team members are not mindless drones, so do not expect them to be. You should find a way to discuss the principles of leadership with them and help to put these into practice. Delegate some tasks to team members who are ready and guide them to succeed. Would you rather have a team of mindless drones or a team of go-getters who take responsibility, can make decisions, and have individual initiative?

Accept the Ramifications of Your Role

Keep in mind that sometimes, leadership is a lonely business. The leader's job is not to be popular. From time to time, you will need to make decisions and communicate information that will be unpopular. Your effectiveness as a leader is gauged on how you act in these situations, not how you act when all is going well. I was leading a development team once where two of the key players (each responsible for developing a key piece of the software solution) were not working effectively together. When asked why their pieces of the project were not developing as per the schedule, each would reply that it was the fault of the other. A little more discussion led me to believe that these two guys just disagreed on how the other guy should be doing his bit and did not get along particularly well, anyway; so, they allowed problems to grow, instead of talking them through.

Knowing that people, when faced with a problem, generally accept a solution of their own making rather than one imposed by another, I offered the two a choice: work together like adults and respect each other's respective roles or; adjust their schedules and work the same hours as me and allow me to arbitrate any differences. I should preface my suggested solutions with the knowledge that I am normally in the office shortly after 6:00 in the morning, and the two team members in question usually rolled in at around 9:00 or 10:00. They both chose the first option and, with the threat of early mornings hanging over them, managed to grit their teeth and work together to deliver the solution on time.

You also must understand that, above all, good leaders are good followers. By setting the example of how to follow your own boss, you show your team how you expect to be followed. If you are constantly speaking ill of your boss and your boss's decisions, you can expect the same kind of behavior from your own team. However, if you display a positive attitude towards your boss (and the organization), you set an example of expected behavior for your team. When leaders (including yours) make decisions, they generally have more information available than their followers. Without all of this additional information to provide context, some decisions do not look like they make sense. It is vital to understand this and avoid the urge to be publicly critical of such decisions, prior to having a chance to get the appropriate information. It is important that leaders display downward loyalty to their teams, but it is equally important that they display upward loyalty to the organization as an example to their team.

Task Appreciation

OK, now you understand the 10 principles of leadership, and you also know that you might have to make your team unhappy from time to time (and you can live with that). But what about some more specific tips on how to execute tasks? It's called a task appreciation and it's easy and always effective. I was taught this on a combat-leadership course in 1989.

During the course, candidates were evaluated on how they led various tasks. We were assessed on how we planned the task and assigned duties to our team, as well as on the ultimate success or failure of our plan. Immediately after the course, I was put in charge of a small team, and things did not go as planned. Tasks were not getting done, and it was affecting the larger mission. At first, I did not understand how things could have gone so well during the course and so poorly afterwards. When I really thought about it, I realized that the course was an artificial environment in which the "followers" were other leadership candidates, and we were sort of helping each other out by "going the extra mile" and making up for shortcomings in the planning process applied by the other candidates. What I was failing to do, in the real world, was consistently perform a task appreciation for every task that my team was given. As soon as I started applying the task appreciation to every task, the team started to succeed. I was startled at how effective it was. But there was no denying it: It worked!

So, what is this magic formula? Whenever you are given a task, consider the following four aspects:


What is the aim and criteria for success?


What factors affect achieving the aim? These can be many and as varied as time, technical constraints, equipment availability, and team availability.


What are the realistic courses to achieving the aim considering the factors? It's easy to think that there is only one course; but you should always try to consider at least two, so that you have a backup plan.


The best course becomes the plan, and the next best is the backup plan. As soon as you have decided on a plan, go back to the principles of leadership:

  • Ensure that your team knows your meaning and intent, and lead them to accomplish the mission.
  • Keep your team informed of the mission, the changing situation, and the overall picture.

So, there you have it. Understand and exemplify the 10 principles of leadership, and use task appreciations to help plan how your team will approach projects.

Final Thoughts

There are really only two other "pearls of wisdom" that I have to offer:

  • Be a practitioner of MBWA Get out of your office and see your team face-to-face.
  • Find a mentor, and be a mentor. Find somebody whom you respect and who is willing to be honest with you and help you develop yourself professionally. Your mentor should be somebody who is comfortable pointing out areas that require improvement, and not just a mirror to validate your own opinions. This is often (but not always) a boss. A good employee is hard to find, and a good boss is even harder. Appreciate it when you've found a good boss, and try to be a good boss/leader to your team.


A leadership approach that is based on principles is flexible and widely applicable to many situations. You should make an attempt to understand and apply the 10 principles of leadership that are presented in this article.

In addition to a set of leadership principles, a few simple tools can be used to assist with everyday leadership duties:

  • Do a task appreciation for every leadership task. It should not take too long and will always pay off.
  • Perform Management By Walking Around (MBWA). Interact with your team through more than e-mail and telephone calls. Understand and read their non-verbal cues.
  • Find (and be) a mentor. Seek honest feedback on your performance, and be an exemplar of leadership to your team.

The principles and tools mentioned in this article are not new. They have stood the test of time and have been proven, over and over, to be effective. They will not fail when applied consistently and are not subject to change from company to company or project to project.

Critical-Thinking Questions

I would suggest that critical thinking can be applied in a number of different areas, as it pertains to leadership: team processes and procedures, decision-making, and leadership development.

Team Processes and Procedures

Sometimes, teams involved in software development tend to become slaves to process. Process should make a positive contribution to our ability to complete our projects, not be a hindrance. This is a natural result of people doing things a certain way, because "that's how we have always done it"—that is, taking the path of least resistance. Given this, I would suggest that you ask the following questions:

  • Why do we do things the way we do? If something in the way that your team approaches projects does not make sense, it should be examined. Either you do not fully understand the contribution being made by the part of the process in question or it really is a hold over from days gone by and should be discarded. Either way, it needs to be addressed. As a leader, you should be constantly asking this type of question about the processes and approaches that are taken to meet project goals.
  • Does every part of the process or management approach meet a business need? In the same way that system requirements should all trace back to an underlying business need, process and operating procedures should map to business needs, too. If procedures and process cannot be mapped to a business need, they should be examined for elimination or modification.


Sometimes, leaders are called upon to make hard decisions. These decisions can involve prioritization of project tasks, decisions to grow (or shrink) the team, decisions on how to frame a new company policy to the team, decisions on how to approach a particular project or problem, and many other kinds of hard decisions. It is, of course, impossible to enumerate all of the possible hard decisions. You will know when you have got one on your hands, because the answer will not be obvious. In these situations, you really must rely on a framework to help you make your decisions. Try asking questions such as:

  • Is this or that approach supported by the principles of leadership (or whatever your chosen framework is)? If the answer is "yes," it's a good bet that the decision is the right one—or, at least, not the wrong one.
  • Does this or that approach support an underlying enabling objective of the company's business goals? Teams grow or shrink and projects are executed for a reason. If that reason cannot be tied to the underlying objectives of the organization, the decision has to be reexamined.

Leadership Development

Lastly, leaders should constantly pursue self-improvement. One of the hardest things to do is be objectively self-critical. Often, we are either too hard or too easy on ourselves. The following questions are best asked of your mentor or a trusted peer, if possible:

  • What are the most effective decisions I made or things I did that contributed to the project in a positive manner? This question could be just as easily reframed as a semiannual or quarterly inventory of how you are doing; just replace the word "project" with "quarter" or some other appropriate frame of reference.
  • What are the least effective decisions I made or things I did that contributed in either a neutral or a negative way to either the project or the timeframe?
  • On what—one technical and one non-technical—area should I focus, for improvement this timeframe?


  • [CFP, 1973] Canadian Forces Publication A-PD-131-001/PT-001 Leadership Volume 1: Junior Leaders Manual, Chapter 4, Article 405. July 31, 1973.
  • Canadian Forces Publication A-PD-131-002/PT-001 Leadership Volume 2: The Professional Officer, Chapter 2, Article 206. July 31, 1973.

Further Study

  • Peters, Thomas J., and Robert H. Waterman. In Search of Excellence: Lessons from America's Best-Run Companies. New York, NY: Harper & Row, 1982.
  • Pendry, J.D. The Three Meter Zone: Common Sense Leadership for NCOs. Novato, CA: Presidio Press, 1999.


About the author

Michael Chiviendacz is the Chief Architect, Professional Services, for Entrust's Canadian Professional Services Team. Michael has several patents pending in the U.S. and Europe related to user authentication and identification. With over 15 years of experience, he has worked in every role related to software development, from architect to instructor. Michael was a member of the Canadian Forces Primary Reserve for almost 18 years, serving as an instructor and a leader in various appointments.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit