Posted in Leadership, Software, Architecture by AST on Sunday, March 19th, 2006
If you ask 10 people what a software architect is, you’re likely to get between 5-10 different answers. Some people will say “they design software systems”, and some people will attempt to enumerate all of the particular tasks they may perform. After giving this quite a bit of thought lately, I think that neither of these types of answers truly captures the essence of what it means to be a software architect. Rather, I believe that the essence is defined by Robert Greenleaf’s concept of servant leadership.
While it first may seem a contradiction in terms, servant leadership is the type of leadership earned by someone once they have demonstrated their commitment to something larger than themselves. What motivates this person is not the success or recognition they may receive; it is the feeling that they will get from knowing they were part of something great. It is earned because leadership is something someone has for a time, but since it is not an essential part of them, it can also be lost. The desire to serve a cause which benefits more than yourself is either part of who you are, or it is not. It can’t be assigned to you, and if you have it, you generally can’t lose it.
This characteristic is an essential part of of the successful software architect because the architect must not be working for themselves. Instead, they must put the desires, needs and goals of their organization or their client ahead of their own personal agenda. They must commit themselves to delivering the best possible system to meet the stated (and often unstated) requirements driving the project. They must shoulder the risks and take ownership and responsibility of their own decisions. If the project is successful, they are successful; if the project fails, they fail–not because they were at fault, but because something to which they were deeply committed was not successful.
Naturally, an architect cannot be successful without having the constant drive to learn and expand their skills. They must know the details of design patterns, development environments, application servers, operating systems, networks and databases and how these all work together to provide a successful system. However, these things are all skills that are learned rather than an inherent part of the person practicing architecture. Knowing these things does not make one an architect any more than a title or a general election makes one a leader. What differentiates the actual architect from the named architect comes down to the character of the individual.
Why is this true?
Think about all of the different things an architect–perhaps yourself–does on a daily basis. Then step back from the detail of what these things are and look at the essence; find the commonalities. What’s left? Leadership. The architect is the person who must take the various requirements and forge them into a consistent and coherent vision for a complete system. In this respect, they are defining the way things will be. They are the ones that take ownership of the goals of the system, internalize it and know what the system is supposed to be; understand what it is and how to make it happen. These things are the root from which all of the daily tasks grow–sometimes like weeds.
The architect creates the vision, articulates it, and can continue to articulate it, consistently and accurately, when anyone is unsure or unconvinced. From their experience, they gain the insights to have the intuition to come up with potential solutions and the judgment to know which of these do or do not fit into the system. However, with all of this experience and confidence, they still must no lose sight of why they are doing it. If the system does not ultimately support the business requirements, it is not a successful system. The architect also knows that, at best, their intuition is only a guide, and that they will undoubtedly make mistakes. They must accept these things as a natural part of working towards the grand goal. It must not be about egos or who is right, but about what the total net benefits of the system will be to its owners.
Being able to successfully do these things is ultimately less about system architecture than it is about being a leader. If you cannot establish a vision and set the direction, you are not an architect. If you cannot listen to your team, your clients or your peers, you are not an architect. If you cannot rely on your intuition to make effective decisions in light of not having all the facts, you are not an architect. If you do not have the humility to accept you do not have all the answers, you are not an architect. If you do not have the foresight to be proactive instead of reactive, you are not an architect. Finally, if you cannot build a community around your vision, you are not an architect.
If you can combine these things with continual personal development and solid, demonstrable architectural skills, you will be able to gain the trust of your organization, your team, your clients and your peers. You will gain their support; you will benefit from their success, and you will be an architect.
References
- Greenleaf, R. K. (1977), Servant Leadership. New Jersey, Paulist Press.
Permalink
Posted in Leadership by AST on Friday, December 24th, 2004
I just finished an absolutely brilliant book called “First, Break all the Rules” by Marcus Buckingham & Curt Coffman. OK, so the book isn’t new, but it was something I picked up recently in my quest to learn more about leadership and management–two things I’ve been actively interested in since I read “Rogue Warrior” by Richard Marcinko many years ago.
I’m sure those of you who know who Richard Marcinko is would find it a bit strange to put a reference to these two books in the same paragraph. The reality is, that to me, they’re related because Mr. Marcinko is the author who really struck a chord with me about leadership as I was reading it when I was first trying to extend my capabilities in that area. A number of things illustrated by the book really spoke to me about how things could be done to achieve a strong team environment and loyalty from those who report to you. Anyway, that’s where it started for me back in 2000.
So, today, I finally finished the book I remembered hearing about in the news and seeing on the bookshelf around that time. In retrospect, I don’t think I was ready for the book 4 years ago. I would have gotten a lot out of it, but I think that it actually speaks to you more if you have been in a leadership or managerial role for a while. If you haven’t and you read the book, you won’t really appreciate it when it expounds that there are differences between skills, knowledge and talent and that “everyone has talent” in one way or another.
What I find extremely fascinating about this book (in addition to it’s reference value for future personal assessment) is that it actually shows you what you can do to increase your productivity as an employee as well as a manager. If you step back (which the book suggests a couple of times) and look at yourself using the same criteria your manager should be applying to you, it will give you great insight into yourself and your own personal talents. Once you know these, your chances for personal satisfaction and therefore success in your career will be greatly improved. In another, more tangential way, it provides advice that you can apply to all aspects of your interactions with other people.
Take the supposition from the book that great managers should define the right outcomes and then let each person figure out how best they may be achieved. If you think about this, it makes perfect sense.
Still, it is very easy to be overbearing and try to tell someone exactly how to do something–especially if you think you’re right or you’ve done something similar in the past. This was a particularly hard lesson for me to learn, but one which I had to deal with in nearly my very first team at Informix. However, think about the statement more broadly in terms of your personal interactions. If you’ve read anything about negotiation skills, you’ll probably instantly see that there’s a connection here as well:
When you want someone to do something for you, articulate what you want to happen and then accept that they will be able to achieve it.
In negotiation (what we do with people every day if you think about it), you generally establish what you want to happen, and then negotiate about how you get there. The “what you want to happen” is the big-ticket outcome of the interaction. Maybe this is you want to buy a car for 10K less than the asking price, or maybe you are in labor negotiations and you want to get the factory operating again as soon as possible with the smallest negative future impact to the business. Once you have defined your “right outcome”, then you can discuss or negotiate the best way that it can be done. In a lot of cases, it is similar to the managerial context: you don’t necessarily care the how, you just want something to happen. Of course, it goes without saying that the how must be ethical and not violate any laws. I’m not trying to say the ends justify the means. Sometimes, like the labor dispute, the how does matter.
Even in a more relevant setting (to the blog, at least) like software development, the architect should define the outcomes (the what should be built) and give the individual developers enough freedom in the how this is met so that they can successfully answer some of the key 12 questions in the book. In this specific case, the following ones are most important:
- Do I know what is expected of me at work?
- Do I have the materials and equipment I need to do my work correctly?
- Do I have the opportunity to do what I do best every day?
These three questions–in particular the first two, define the foundations on which tangible business performance can be based. The happier your developers are, the more pride they will take in the work they do and therefore the better it will be. As mentioned in a number of sources, the cheapest place to find problems in the software is during development. If you have appropriately talented and motivated employees, the defects are less likely to be introduced in the first place.
If the organization, the manager, or the architect attempts to put too many controls on how the person does their job, they begin to wonder why they are even here. People want to be valued as individual contributers to a greater whole. If they have defined outcomes and an understanding how that fits into the bigger picture, you will generally have productive developers. This does not mean things like coding standards are a bad thing. Basic foundations must be laid for order and safety. You can’t just drive on whichever side of the road you like, for example, but it doesn’t mean you must drive a VW Beetle or a Ferrari. It just means that everyone’s following the same fundamental rules. What you do within those rules is up to you.
I realize I’m drifting off track a little here, but the point I’m trying to make is that anyone who absorbs what is said in “First, Break all the Rules” instead of just reading the words will come away with wisdom which can be applied in all directions: up, side to side and down. If you’re responsible for people, it will help you be a better manager, but if you aren’t, you’ll still learn how you can be a better employee and find a place where your talents can excel and you can be happy. If you don’t get these things from the book, come back to it in a couple of years. It will still be as relevant and valid when you do.
Permalink
