Leadership
Lessons Learned About Presenting by Being a Presenter
Jan 15th
Public speaking was a skill I consider important and continue to struggle with as I do more presenting. During my mid-twenties working full-time and going to school helped shape how I viewed classroom learned concepts and skills and applying them in the “real-world”. Throughout my career I have been fortunate enough to present to various audience sizes from internal meetings to national conferences.
Sometimes it is easier for me to learn a better way to do something by talking about how I have it done wrong. Here’s a few ways I turn “anti-patterns” of presenting on their head.
Target your audience; focus on the masses. Last year I presented the WCF Quickstart at DODN 2009. I know a lot about WCF but my weakness is that the context I used WCF in was different than what most people will see. I was in a SOA/Event-Driven/Data Sharing world. Most people need web services because someone told them using a web service for data access was more secure. The SOA people in the audience connected, but I lost others. Target the masses and call out the smaller communities to ask questions or point out where they might benefit.
Favor simple examples to illustrate concepts over full-blown systems. When you think about presenting it’s a dream to think you could design a full-functioning app to illustrate concepts. But it’s just a dream. The problem with using full-functioning apps is that the concepts can be lost in the details of how the app is constructed. My biggest gripe about presentations is that the examples aren’t enough, but there’s a reason. To be really effective the example and your presentation should help people take the concept to a higher level.
Build a portfolio of presentations and tweak them as technology changes. My favorite speakers all have a portfolio of presentations they deliver. As tech changes these speakers update their content/examples. This helps speakers to really own the material and keep it fresh. It also makes it really easy to submit speaker applications because everything is ready to go.
Don’t be afraid to improvise and engage the audience. At the NIEM NTE I was scheduled for two back-to-back sessions. The first was a split presentation on .NET & NIEM. The second was on NIEM, SOA, and EDA. By the time I got out of the .NET presentation and to the SOA presentation my adrenaline was up and I rushed through the SOA presentation. There were about 30 minutes left so I hit the floor for questions. The discussion that ensued was much more interesting than my presentation. That is not what I planned for but it worked. Audiences don’t always want to be talked to; sometimes they want a little conversation.
Be you. When you stand in front of yourself you open yourself up. People know when your heart is not with it. Talk about stuff you’re passionate about and let that passion come out.
Fortune Cookie Says…Volume 3
Dec 13th
For Volume 3 of “Fortune Cookie Says…” I have saved one of my favorite fortunes that I uncovered while celebrating with a fortune cookie after a few helpings of some of my favorite Chinese-American cuisine.
A leader is a person you will follow to a place you wouldn’t go by yourself.
If you know me or you’ve read my blog for sometime you know how close to my heart the topic of leadership is. I have worked for some great leaders and am always striving to be the kind of leader this fortune describes so eloquently.
Feedback: Key to a better you
Nov 19th
Last week at lunch one of my colleagues and I were talking and she gave me some much needed feedback about something I need to keep in mind. But I didn’t receive the feedback well because I wasn’t expecting it at that point in the conversation. After lunch I asked her to E-mail me with more detail because I needed to hear it. I’ve known this individual for a while now and I value her feedback, but this one caught me a little off guard.
During my career I’ve received various kinds of leadership training. Through the Leadership Legacy Forum I learned the most about how important feedback is for leaders; especially those who want to improve and change those things about themselves that they can. Feedback is critical and its important to be able to receive and to give it. Often times receiving it is much more difficult than giving it.
A few lessons I wrote down over the years:
- Be ready for feedback at anytime. Sometimes its very direct and surprising, other times its subtle and you have to be aware of it.
- Since I’ve become more active in speaking and writing I have had to open up to receiving feedback almost constantly. In a recent presentation I gave I was receiving feedback during the presentation by an individual that disagreed with what I was presenting. During the presentation I could clearly see and hear them shaking their head and telling their colleague why they disagreed. The individual didn’t speak up during the Q&A. Unfortunately I never had the chance to follow-up to see what they disagreed with.
- Resist the urge to argue. Sometimes feedback contains things you don’t want to hear. Resist the urge to argue and sleep on it if you have to.
- Ask for clarification if you need to – without being argumentative. Occasionally statements come out in the wrong context or can be misinterpreted.
- Act on feedback. People give you feedback so you can make changes to a behavior or situation.
- Ask the person giving you the feedback for some ideas on how you can act on what they are telling you.
- Change happens slowly and yourself and others may not notice the changes immediately.
- Use lead-ins to prep someone if you are going to give direct feedback. There are times to be direct and times to be subtle. If you’re going to be direct, lead the person into it so that they are ready to receive the feedback.
- Lead-ins do not have to be some elegant work of prose, just something simple like “Hey, I noticed this the other day and wanted to talk to you about it”; anything to help the person prepare to receive feedback.
- Subtle hints like “yeah, I see your point but I would look at that situation from other angles” can be useful to help point someone to other perspectives. You don’t have to be explicit about what other angles; just plant the seed.
- Context is key. You may provide feedback in the wrong context or at the wrong time.
- Be ready to provide the feedback multiple times; especially if it will really help the individual out.
People, Process, Policy: You Are Here
Nov 16th
For anyone working in IT you have doubtless encountered the non-technology forces that impact your IT implementations and deployments. In my experience those forces are comprised of three main entities People, Process, and Policy.
At the center of our concentric circles, which are both collaborating and competing forces, are your information systems. The realizations of the business processes, policies and people are provided by the abstractions of the systems that comprise the overall technical architecture. These systems are constantly being pushed, pulled, and shaped by the interactions of our three forces.
People
Business are made up of people, each of whom are there for different reasons. Some people want a paycheck, others like the work, and others are so aligned with the organization that is hard to see where the separation is. People work to implement and execute the processes of the business within the guidelines of the policies to fulfill the companies mission.
Process
Processes represent the series of business events which are accounted for, ordered, and reacted to in order to execute the businesses function. An order is received by the order system, inventory is checked, products are packaged and shipped to the customer. The process can be viewed through the lens of ordered steps or events, depending on how you want to model it. Either way, process is the stuff of business. It’s how things happen and what gets done when something unexpected happens.
Policy
Policy governs what is allowed to happen, what the acceptable responses are in a given situation and the general rules an IT system will implement. Rules as simple as “customer first and last name are required on orders” or decision structures as complicated as “if the customer is a preferred customer and they cancel their order then no re-stock fee is charged, unless the item was custom ordered. But if the order was over $2000 then a 10% restock fee is always applied.” Policy can often be the biggest pain point because people forget policies, do not understand them, or misinterpret them.
Competing Forces
At times, each of these elements will act as a hero or villain. The friction this causes can impact IT at all levels. People change, someone quits or gets promoted, processes might change or policies may be altered or dropped all together.
Collaborating Forces
Then sometimes, all three elements began to work in harmony. People are able to change policies and processes in a way that opens up new opportunities for IT solutions. People are able to embrace change for the promise it holds – optimizing processes, minimizing policies and driving business value through an optimized fulfilling of the businesses mission.
Which leads to the last element, not accounted for by this simple illustration.
Change
Change is that external force which pushes and pulls each of the three elements and causes them to collide or work together. Change is the constant in our equation; the market changes, technology changes, perspectives change. People, process, and policy – all change. Sometimes with each other, sometimes not.
This is where IT is and where we must be. Our job is to learn to roll with the changes and provide an architecture that meets the one constant – change. Our systems must be able to change and evolve as the people, process, and policies all change. Within those concentric circles lies that sweet spot and when we get even a glimpse of it, we know that we are right where we need to be.
Navigating the Map
What can you do now that you understand you are stuck in the middle? The answer is what separates the IT Pros from the rest. IT is not the solution to every problem because it is not sustainable for IT to be in the middle of everything. IT won’t always solve people problems, can’t always fix process problems, and often IT cannot change policies.
The key to be an effective member of an IT organization is to talk to the business about their problems, in their language. Leave the techno-babble at the door. Unless you are meeting with other IT teams, tone the language to your audience. The three forces of People, Process, and Policy are already affecting the business and introducing IT jargon in the middle isn’t going to solve those problems.
Listen. Talk to the business in their language. Suggest IT solutions when appropriate. Keep in mind that IT is not a hammer and there are some problems IT cannot solve alone.
Fortune Cookie Says…Volume 2
Nov 4th
Following Fortune Cookie Says…Volume 1, this fortune is also very timeless as I can think back to many times in my life when I’ve had to live with some discomfort.
Be willing to be uncomfortable. Be comfortable being uncomfortable. It may get tough.
I know many people that have had some level of discomfort during 2008/2009. The last two years have been “tough all over” as it said. But these are not the only years that we’ve all had to live with some discomfort. Looking back across history we can see many periods in time full of discomfort or talk to relatives who can relate their experiences during those uncomfortable times. For me, the time that taught me the most to be comfortable being uncomfortable was during my struggles with cancer in my early 20’s. There were never any certain answers and everything was based on statistical analysis of survivors and cure rates.
Growing up with a complete Star Wars education, Han Solo tells us best “…never tell me the odds!”
Fortune Cookie Says…Volume 1
Oct 25th
While cleaning out old files I found several fortunes that I kept around because the fortunes seemed very timeless, as fortunes often are.
Past Experience: He who never makes mistakes never did anything that’s worthy.
A very simple statement that reminds us all that mistakes are part of the effort when striving for greatness. If you’re making mistakes, you’re probably doing some things wrong while on your way to doing something right. Learn from the mistakes and keep at it. Bruce Lee reminds us “Don’t fear failure. Not failure, but low aim, is the crime. In great attempts it is glorious even to fail.”
I have quite a few of these lying around and I will post them from time to time. Enjoy!
“Lessons Learned from Bruce Lee” – An Architect’s Perspective
Jul 27th
Clint Edmonson tweeted about this awesome post from Sources of Insight – "Lessons Learned from Bruce Lee". This post really resonated with me so I thought I would add some of my thoughts to the original author’s work, giving it a software architect’s perspective.
- "Be YOUR Best" – Self-explanatory. The only person you should try to top is yourself.
- "Absorb what is useful" – "It’s not about blindly adopting patterns and practices. It’s about taking the best of the best and tailoring it." The author’s original words are almost straight out of the mouth of a modern architect or software developer. There are a lot of technologies, patterns, and options but not all of them are proven, take what is and add your own experience to the mix. ("Mash-it-up" if you want to be Web 2.0 about it
- "Keep an Open Mind" – Sometimes you will learn something in a specific context and attempt to always apply in that context. Throw away the context and look at it differently. You may then see that to apply SOA does not mean it has to be implemented with web services.
- "Stay Flexible" – If you read the Architect’s Creed then you know I am a big proponent of flexibility in software systems. That flexibility starts with the architect.
- "Focus on Growth" – Growth is key for an architect and software developer. You have to keep pushing yourself to the next level.
- "Know Thyself" – Every leadership manual or class has a section on this. You are your greatest strength and weakness and your knowledge of those factors will affect your designs and your team.
- "Make Things Happen" – Don’t stop after a big success, keep going.
Be sure to check out the original post on Sources of Insight to catch all of the authors favorite points and perspective. It’s a great read and there is something for everyone.
Should You Fix Working Software? Part 2: An Answer
Jul 14th
In part 1 I posed the question, which undoubtedly seems like an odd one. How would you fix working software, because by nature it isn’t broken?
The fix I’m talking about is rewriting the software with updated syntax or techniques. Why would you do this? A few of my fellow LLF grads were snagged up by Google while we were all going through the LLF program. We were talking about the culture and one of the things they told me is that Google coders regularly go through the code base and update code with new syntax, remove dead code, or refactor code to be more efficient or understandable. I loved this concept, not because I think redoing work is fun, but because it pushes developers to keep learning and to make code better as they improve their selves.
Often as developers mature they understand the business better and that helps them understand the code better, which gives them an opportunity to leverage refactoring to make the code easier to maintain. But this type of growth only happens in a culture that supports it and there are far too many cultures where it is taught to leave code alone because it "works". I would argue that working code does not mean maintainable code, and when code is hard to maintain it is even harder to change. Change is the number one requirement of IT.
An answer is what I proposed, so I will provide an answer that should be both practical and achievable. Create a culture of growth and learning among your developers. Grow yourself and encourage them to. Raise the bar for them and set high standards. There will be failures; learn from them and grow together. Once you have a culture of self-improvement, perspectives will change and it will improve your teams skills and your software.
This answer is not a technical one because the problem isn’t a technical one. The problem is a people one because, software development is about the people. The people who use it and the people who write and the depths we push our minds to when writing it.
I once served under an executive director who, after a major IT success, told me to enjoy it but not to stop. She said "ride this wave, but be sure to find another one".
—–
Resources to help you and your team grow:
MSDN – http://msdn.microsoft.com/en-us/default.aspx
Code Complete 2nd Edition – http://cc2e.com/
Refactoring Resources – http://en.wikipedia.org/wiki/Refactoring
Object-Oriented Resources – http://en.wikipedia.org/wiki/Object-oriented_programming
Find a local .NET User Group – http://ineta.org/
Find your local Microsoft Evangelists – http://msdn.microsoft.com/en-us/events/bb905078.aspx
Problems Are Not Always Bad
Jun 7th
Lately problems have been on my mind. At home we’ve had some fun with torrential rain and the kids; at work we’ve been having some growing pains as we move to more services and service agents (or clients). Having problems is not a bad thing. Having new problems can be a sign that you are doing something right.
A few years back I read an article in Men’s Health that I like to quote from time to time. "Doing old things in new ways, new things in new ways, or new things in old ways. The only thing they hate are the old ways of doing old things." The context for the article was what a manager was looking for in people who can make changes in an organization. In this context it’s safe to apply by realizing that as long as you continue doing old things in old ways you will have the same problems and they will never change.
It is only when you transition to the new ways that you will encounter new problems. It does not mean the new ways are bad so long as you don’t have new problems and the same old problems. If you have both then you’re doing something wrong.
A Journey Ends; A Journey Begins
Mar 19th
Tonight I commenced from the TDG Leadership Legacy Forum (LLF). This process has been a year long process that involved a lot of my time and effort (reading, presentation prep), travel/time away from the family, and some real reflection into who I am and what impact I can have as a leader. For me it was a very personal process that I went through with a great group of attendees from companies large and small. The commencement was a small ceremony in our hotel attended by the graduates, their sponsors, and some of the new attendees who are now entering the process. All the graduates had a chance to make their comments and look ahead to the future we will each spend as leaders at all levels working to make a difference in our work lives and our personal lives.
The commitment of my employer and the others during these tough financial times demonstrates the importance of the effect leadership can have on a businesses success or failure. Tonight I am grateful to my boss, my sponsor, and my organization for investing the time and money which helped me to grow and learn and will ultimately help me bring back new perspectives and experiences to benefit our organization.
This is the end of one journey, the first in a series that has still unknown twists and turns. I am looking forward to the years ahead and the challenges they bring, optimistic that the things I have learned and how I have grown will help me to provide valuable leadership to stay above zero and get the real work done.
To the other forum graduates I salute you and look forward to seeing where your journey takes you. To Dick Dooley, our facilitator, I thank you for your mentoring and opening up your network to us and letting us learn from your and your peers experiences; lessons I will take with me throughout life.
I’ll close this post with two quotes that I think tie to my experience with the LLF:
"Nothing ventured, something lost"
"No sacrifice, no victory"
