Posts tagged 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.
Complexity, Simplicity, and Elegance
Sep 7th
A friend and I were recently talking shop (over Xbox Live of course) and began discussing patterns we see when people get comfortable with what they know. There are a lot of programmers who are good and reach a certain point where they are continually writing what is, essentially, the same program for every problem they are solving. While this may seem to be an optimal solution, what it leads to is a loss of creative thinking and solutions that don’t quite fit the problem.
During the conversation I likened this to people from the 80s or 90s who never wanted to update their style and the analogy kind of stuck. This friend is updating his style in a big way; by taking a leap to a job where I have no doubt he will be successful. He said one key thing that stays with me every day. Even when you reach a place where you are comfortable with your style, if you are not constantly questioning your style or trying to figure what it is that you don’t know, there will be no true growth and you may never find the next level of solution to your problem.
A recent link that came across one of my RSS feeds pointed to this article, part five of a five piece interview with Ward Cunningham that took place in 2003. The article is titled “The Simplest Thing that Could Possibly Work” and explores simplicity in software design drawing from Einstein’s quote “As simple as possible, but no simpler.” This quote is very easy for people to use against you, especially when it is in the context of a solution they do not fully understand. The key is that the complexity of the solution is relative to the problem it is solving.
If you take your average web developer who is performing front-end work on an E-commerce site and stick them on the back-end of an enterprise service bus that is using an event-driven architecture, that developer will most likely think it is complicated. That perceived complexity is misplaced because a service bus is an elegant solution that was crafted by breaking through the complexity of messaging, loosely coupling back-end systems, and orchestrating it all in a way that meets the business process needs and solves the problem.
In his book “Pursuit of Elegance: Why the Best Ideas Have Something Missing”, author Matthew May broaches the search for elegance by defining it as the simplicity that comes after you break through the complexity. In order to reach that solution, you must understand the complexity, get tangled in it, and ultimately break through it.
By no means does this imply it impossible to build an overly complex solution. If you are trying to build a blog you may not have a strong case for using multiple services and a service bus. There are simpler solutions for blogs out there. However, if you are trying to connect autonomous services in a scalable way that allows those services to operate independent of the state of other services, then a service bus is probably a good choice. The complexity of the solution is relative to the complexity of the problem. When both the complexity of the problem and relative complexity of the solution are understood, the solution can then be held to the standard of “Simple as possible, but no simpler.”
This is where staying current, questioning yourself, and “updating your style” come into play. If you are not constantly seeking a better way to do something, trying solutions, questioning the solution, and trying it a different way, you will ultimately get stuck writing the same program to solve every problem. In some cases the solution may fit, but when it does not the solution becomes more complicated and does not fit the mantra: “Simple as possible. No simpler.”
An Implementer’s View on the State of Information Sharing
Aug 10th
Firstly, the following represents my perspective from my experience working on various information sharing projects during my career as well as discussing these projects with other implementers and decision makers. The views do not represent any organization’s views, employers past or present, this is just Chris speaking.
The technological barriers to sharing information have been broken down. Technologies like Web Services and Xml, and standards such as NIEM provide us with structured ways to describe and map our data into other formats and to communicate about that data at the technology and business level. Since I started working in IT I have seen enormous capacity for reducing duplicate work and passing information across department and organizational boundaries to help people do their jobs. No where has this been more evident than my time spent in the criminal justice community.
Three distinct forces present themselves for every information sharing project: People, Process, and Policy.
The Perils of People, Process, and Policy
People have both legitimate and selfish reasons for not wanting to share information. With the state of our legal system and the rampant liabilities that come into play many people who will be directly affected by information sharing have real concerns about how the information will be used. On the counterpoint, the territorial issues come into play as well. Some people just don’t want to share their information with out you asking in person. The idea that computer systems will be quietly passing information under their control is unsettling and can elicit very strong objections.
Process affects how we perform our daily tasks. Where this is no process, there is no tool that will make it better. Simply introducing information sharing does not fix the process; that fix requires the effort of people to examine that process and make real changes in how their duties are performed. When information sharing is driven by an external entity and people are forced to look at their own processes this can be difficult. It takes a very skilled team of project leaders at a higher level to make these things less threatening and more open.
Policy affects what we are allowed to do (and often how we do it). When policy isn’t ready, some information that would be useful to send, isn’t sent because a policy was set up to prevent it. Sometimes the policy is based on statutes or laws in place to protect privacy concerns, other times the policy was just based on a decision made years before that was never revisited as technology, and people, changed. Just as process must be examined, so too must policy.
The Potential of People, Process, and Policy
Web 2.0 taught us a lot about information sharing. What if you provided a public API and provided structured access to your data? What could become possible? Because ultimately information sharing is about possibilities.
Before the web APIs were opened we did not have maps that could display myriads of information from disparate sources using the Internet. We weren’t able to take data that was uniquely ours and mash it up with data that we didn’t own. The business had a hard time seeing what was possible because, quite simply, IT made things seem impossible.
The tides have changed because now IT is no longer a barrier. As new IT professionals come into the world they see the possibilities because they have experienced them; they have mashed things up, linked Twitter to Facebook and LinkedIn. They have seen the revolutions blogging, RSS, and ATOM have inspired. There is nothing holding the information back except those who aren’t ready for the information to flow: The processes, policies, and people who are still standing in the way, afraid to give up a little control and embrace the possibilities that are there.
A fellow blogger from my work in the library world maintains a blog with the tagline “Information Wants to Be Free”. The phrase can be traced back to 1984, when Stewart Brand is quoted in the following context “On the one hand information wants to be expensive, because it’s so valuable. The right information in the right place just changes your life. On the other hand, information wants to be free, because the cost of getting it out is getting lower and lower all the time. So you have these two fighting against each other."
25 years later truer words have not been spoken. The technical barriers have been broken down. It’s time to unleash the potential of People, Process, and Policy in connection with the IT capabilities we have in the Web 2.0 world.
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
Should You Fix Working Software? Part 1: The Question
Jul 10th
A few weeks ago I did my first code review on work that I had no involvement with other than some initial brainstorming and high-level architecture. As I was looking at the code I only saw one or two things that concerned me but even those were not critical. When I typed up the review I realized that first and foremost I need to clarify that the software was working and frankly, it’s hard to argue with working software.
In this case the component was designed with good object-oriented principles and there was really only one place where I thought a particular class had too many responsibilities. The developer, who is pretty new to REJIS, was extremely open to the feedback and all in all it was a good experience.
This had me thinking, what if you were reviewing software which wasn’t designed using good object-oriented principles? If the software was working, what angle would you take to suggest changing the design without offending the author? This is a tough question because there are many organizations where the development teams have a mix of procedural minded and object-oriented coders.
My friend and colleague David Risko wrote about this in his post "The Elusiveness of Object-Oriented Thinking". His post highlights some of the challenges of bringing developers into the OO space. Fundamentally OO breaks many of the traditions of traditional procedural thinking. It is a mind-shift that can be difficult to make and in a mixed environment where you have those in an OO mindset and those who are not, the differences begin to surface more often.
So what about that 1,000 line class with 3 methods and if statements nested 5 deep? It works and it’s consistent. How do you show that developer ways they could improve it’s readability or flow?
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"
