Learning from Other People

One way to learn is by making mistakes. Another way is to learn from others. In Software Architect Bootcamp, Raphael Malveau and Thomas J. Mowbray, Ph.D. write about two skills you need to learn from other people.

Two Skills to Learn from Other People
Malveau and Mowbray write the following:

"There is another way to learn (rather than making mistakes), and that is by learning from other people. To do that effectively, two skills that most people lack are required: how to read between the lines and how to take advice. "

Taking Advice

"It is also true that very few people readily accept the advice of others. Everyone should try harder to accomplish these basic techniques more effectively. While this advice is relatively simple, few people regularly utilize these basic skills in much depth; therefore, they waste a great deal of time and energy by not benefiting from the knowledge of others."

Reading Between the Lines

"The phrase "reading between the lines" is only a figure of speech. People do not literally read anything between lines of text. Rather, they analyze what the author is saying at a level of detail somewhat beyond the surface discussion. This requires the use of knowledge, experience, and imaginiation.

To read between the lines, first visualize the situation of reading a story around human experiences. Try to imagine how those people were feeling and acting that motivated what they did. Were they lazy, angry, ignorant, misinformed, or biased? Now read an article by a vendor or consultant. Is the writer competent to speak and act on this subject? Does the writer have an agenda, perhaps product or standards-centric, and is he or she trying too hard to be persuasive? How does what he or she is saying compare to personal experience and knowledge? is the writer right or wrong or somewhere in between? When did he or she write this, and what was the historical context of these comments?"

Know What to Accept or Reject

"These are impressions that one should be able to pick up naturally while reading. The ability to read between the lines gives people the ability to discriminiate and consciously decide what they did will add to their knowledge and what they will reject. Every piece has some good and some bad information. To win the psychological war, one needs to know the difference instinctively."

Key Take Aways
I think there's a few complimentary concepts along these lines:

• Know what you want to accomplish. If you don't have a purpose, you'll be randomized by information overload.
• Build trusted sources of information. Find the people, sites, blogs, and authors that you can rely on.
• Measure against what works. Measure against what works, how actionable the information is, and how you improve your effectiveness.
• Continuously collect reference examples to draw from. There's stories of successful people in just about any situation you end up in. Find those stories and find the patterns of what works and model from the success.
• Turn insights into action. Chunk what you learn down into the simplest thing you could do to improve results. Always start with something simple. Simple builds momentum. Part of why I do this blog, is it's a simple way to act on what I learn. Posts are a right-sized way to share nuggets of insight.

The Management Trap

If you chose a software career because you enjoy technical work, then you need to protect your technical edge. If your administrative tasks increase, your time to perform technical work can decrease dramatically. Because less time is spent on technical tasks and on maintaining technical skills, you could lose your technical edge. In Software Architect Bootcamp, Raphael Malveau and Thomas J. Mowbray, Ph.D. write about how to avoid the management trap.

The Management Trap
Malveau and Mowbray write the following:

"Being a software architect is quite different from being a manager. A software architect is a direct technical contributor, whereas a manager contributes indirectly by coordinating the actions of other people. Together, managers and architects make highly effective leadership teams. In our experience, combining the two roles can work only temporarily.

As architects evolve into managers, eventually a superior will tell them to stop touching the keyboard (i.e. programming).

Software architects can avoid becoming managers by establishing a personal professional policy. Those architects who don't want management duties must learn how to say so. For many architects, one of the most difficult transitions is learning to say "No." For example, lateral promotions that lead to management and administrative roles must be avoided.

Some organizations trap architects in a management role, because the company does not have a technical ladder. At a certain level of seniority (typical of software architects), many architects are surprised to find themselves assigned responsibilities on the management organization chart. Once this is decided, it is very hard to reverse. The best approach is for architects to declare their expectations (e.g., for technical assignments) when first hired and to repeat that policy often."

Key Take Aways
In my case, Microsoft has a technical ladder, so it's less of an issue. I actually chose Microsoft because of the possibilities of both technical impact and people impact. At Microsoft, architects can be very hands on, which is a sharp contrast for some folks. In my group, we tend to distinguish between "white collar" architects, that serve more of a business function, and "blue collar" architects that are hands on.

• Own your path. I think the most important point here is that you have to own your path and own your choices. If you don't have a map of what you want, you won't know when you're off track.
• Set boundaries around time spent on administration. If you don't specifically carve out time for technical and put boundaries around your administration time, then it's very easy to lose all your time to administration. At the end of the day, the more deliberate you are with your time, the more effective you will be.
• Know whether you want to be a thought leader, people leader or both. You can be a great people leader without being a thought leader. You can also be a great thought leader, without being a great people leader, but you'll dramtically amplify your results if you can lead people. It ultimately comes down to what you want to accomplish, while playing to your strengths and passions, and reducing your liabilities.
• Ask yourself questions to figure out what you want. I think one distinguishing question that can help you get clarity on what you want is to ask -- "do you want to pave the paths for others, or do you want to enable others to pave the paths? " Another clarifying question is to ask yourself, "what do you want to spend more time on each day?"

My Related Posts

• How To Figure Out What You Really Want

Seven Habits of Highly Successful Software Architects

Do you practice the habits of highly successful software architects? Can you deliver a solution while acting as a technical mentor, empowering others, improving the process, and developing a focused, high-performance team along the way? In Software Architect Bootcamp, Raphael Malveau and Thomas J. Mowbray, Ph.D. write about the habits of successful software architects.

The 7 Habits of Highly Successful Software Architects
Malveau and Mowbray write the following:

1. Keep it simple. When communicating various architetural concepts or software mechanisms to team members, resist the temptation to provide a complete and detailed explanation of how things work or a detailed comparison against all the alternatives in front of a group. Instead, the software architect should say enough to communicate the idea at level that is high enough to be generalizable but just low enough to be understood in principle, so that the individual team members can do their own homework or meet separately with the architect to address their specific concerns.


2. Let others defend the architecture. It is always peferable to have someone else respond to a technical concern rather than have the software architect appear to be the sole source of knowledge. It reinforces teamwork, provides the architect with insights from people who agree as well as disagree, and is a key aspect in mentoring others, among other benefits.


3. Act, don't argue. Arguing technical points in a meeting wastes time, hurts feelings, and seldom, if ever fully resolves any technical issues. When such an argument starts, the software architect must act - by assigning people to get or verify the relevant information, setting up a meeting specifically for resolving the debated topic, or, if time requires, an immediate course of action, laying down the law by explaining why the time constraints force an end to the matter.


4. Keep an eye on the prize. Software architects must always be aware of the end goal. It is easy to be distracted by tasks and smaller technical issues, and frequently other team members will succumb to one form of tunnel vision or the other. However, it is vital that the architect always be focused on the overall vision of the system and relate every task or technology to how it contributes to the end goal.


5. Be willing to change, but never too much at once. After the initial bootstrapping of a software development effort, the architect should be wary of implementing too many process improvements all at once because there is a risk of compromising the effective parts of the process.


6. Learn where to stop. Software architects must resist the temptation to go into too many details and to micromanage design decisions. For example, it would typically be enough to specify that caching is required in client applications and that the caching code should be reused throughout the application. However, detailing the specific caching algorithm used or writing the caching pseudocode is probably overkill. Learning to trust other team members to provide design and implementation details and letting them ask for help is essential.


7. Know how to follow. No matter who is in charge, software architects should avoid publicly confronting others on major design issues. This can be accomplished by knowing ahead of time what is going to be discussed and the reasons for the various decisions. This is a key aspect to developing a focused, high-performance team.

Key Take Aways
Being in the software building business, I can easily relate to this. I think there's a couple of themes that underly the habits:

• Balance connection-focus with task-focus. Building software is a team sport. It often means building rapport and getting others to buy into ideas over time. While knowing your stuff is a good thing, you should use it to lift others up and produce a great results. Winning technical battles at the expense of the human relations war, will cause unecessary friction and reduce your results and drain your energy.
• Focus on value delivered over the shiny object. If you're passionate about the technology, it's easy to fall into the trap of focusing on the technology or the shiny objects. At the end of the day, your credibility and perception will be about the solution you deliver and the team impact.
• Be a mentor and a coach. It's true that knowledge is power. The trick is to grow yourself, by growing others. What you share comes back to you tenfold.