Do you lead by influence or position?

By ChrisEdwards | Published: June 24, 2011

I was listening to the Manager Tools Podcast and learned there are two leadership styles: leading by influence or leading by position.

Leading by Position

Leading by position is when others follow you only because you are in a position of authority. “Do this…because I am your boss!” While people should follow those in a position of leadership, if a leader is relying solely on the authority of their position to lead others, it is far from ideal.

Leading by Influence

Leading by influence is the ideal form of leadership. This is where others follow because you have earned their trust and you are able to exert influence over them. This form of leadership does not require any authority or position. A person can lead their peers solely by influence.

Have you ever heard the saying, “He’s a natural born leader?” It is likely because of influential leadership. Those who naturally appear as leaders in a team of peers are those who lead in this way. The team trusts them and they begin to “naturally” lead even when they haven’t been officially given the title of leader.

An Example

The Bible gives us a great example of this type of leader in Jesus. He was God, yet the bible says, “[Jesus], being in very nature God, did not consider equality with God something to be used to his own advantage; rather, he made himself nothing by taking the very nature of a servant, being made in human likeness.” (Philippians 2:6-7) Jesus gave up his “title” and led by example. He didn’t say “Obey me because I am God!” Instead he said “If you love me, obey my commandments.” (John 14:15)

So, how do you lead?

Posted in Leading, Soft Skills | Tagged , , | Leave a comment

Catching vs. Bubbling Errors

By ChrisEdwards | Published: June 13, 2011

When should you catch an error? When should you just bubble up an error? I was asked this question a while back and came to a rather simple answer. There are two cases when you should catch an error. In all other cases, bubble it.

When the error needs to be displayed or logged, catch it

When you need to do something with the error, you should catch it. For instance, in the UI, you need to display errors to the user. Bubbling it up would mean that it would become an unhandled error, so it needs to be handled. Catch it here so you can do something graceful rather than crash the app.

When you can add additional information about the error, catch it

When a method can add some value to the error message that will help the end user or developer understand what is going on, do so. A good example would be if a sql statement failed, it would be useful to catch the error and add the sql that failed to the error message along with any parameters that may have caused the failure. Then throw a a new error with this message and set its InnerException property to the original error.

Let the error bubble up in other cases

I can’t think of any other reason to catch the error, so just let it on through and bubble up in any other instance.

-Chris

Posted in .NET, Error Handling | Tagged , | Leave a comment

Questions To Ask In Retrospectives

By ChrisEdwards | Published: May 9, 2011

If you ask poor questions in your retrospectives, you will get equally poor results. To uncover the problem areas that you need to focus on, you need to ask the right questions. Here are a list of questions I have compiled over many years of retrospectives.

Most of the questions here are very developer-centric, but some also apply to the broader picture.

The Three General Questions

These three questions cover most of what you want in a retrospective, but are too broad to be useful by themselves.

  • What worked well?
  • What didn’t work so well?
  • How can we do better?

Specific Questions

Here are some specific questions I have found useful. Pick the ones that are most relevant to your situation.

General

  • What is keeping us from delivering more value?
  • Is the path blocked by unresolved obstacles?
  • Are we getting to done?
  • Are we uncovering new things every retrospective?
  • Are we managing risk effectively? (tackling high risk tasks, or avoiding?)
  • What were the biggest pain points? What was difficult?
  • What low-hanging annoyances can we remove?

Team

  • Are the team members happy? Tired? Grumpy?
  • Are team members really collaborating? Learning? (in general, and from one another)
  • Are we effectively utilizing the strengths of the team members?
  • Are team members taking initiative?
  • Are we respecting the team norms?

Communication

  • How effectively are we communicating?
  • How much time does the Product Owner spend with the team?

Environment

  • What in our physical space is hampering our effectiveness?

Planning/Execution

  • Are we faithfully tracking and discussing effort remaining?
  • Are our tasks clearly defined?
  • Were our estimates accurate? Why/Why Not? How can we do better next time?
  • Were our requirements sufficient?
  • Are the user stories too granular? too nebulous?
  • Was the workload too much or too little? (Are developers over- or under-worked? Are they energized?)
  • Are team members able to do focused work or are they pulled in too many directions?
  • Was there an appropriate amount of slack time for cleanup and improvement?

Processes & Practices

  • Is our iteration length appropriate?
  • Should we pair program more? or less?
  • Do we have sufficient test coverage?
  • Is the quality of our code sufficient?
  • Is our code base improving or degrading? Why?
  • Are we adhering to development principles?
  • Are we appropriately utilizing automation? (If you do something more than once, try to automate)
  • Are we handling the unexpected well or reverting to our old ways?
  • Are we utilizing the tools we have effectively?
  • Are there any tools that would help us be more effective?

Resources

Some of the questions and concepts were taken from the following cheatsheets by Berteig Consulting.

Posted in Agile | Tagged | Leave a comment

Paper.li – Read twitter/facebook like a daily newspaper

By ChrisEdwards | Published: March 30, 2011

Paper.li example imageIt takes a long time to catch up when I fall behind on twitter. Not anymore.

I started using Paper.li to gather all the urls that are tweeted in a day into one consolidated view that looks like a newspaper. See image.

I simply navigated to http://paper.li to sign up, and entered my twitter id (no password needed) and it generated a daily summary for me! Very nice. Plus, it emails me a link to the summary for each day.

It has really saved me a lot of time trying to catch up on the latest links posted on my twitter feed. I highly recommend it.

-Chris

Posted in Productivity, Tools | Tagged , , | Leave a comment

Intro to MongoDb slides and audio from CTXDNUG, March 2011

By ChrisEdwards | Published: March 25, 2011

I presented an updated version of my Introduction to MongoDb talk at the Central Texas .NET User Group back in March. I incorporated a lot of what I leaned from the MongoAustin conference.

The target audience is technical people (developers) who have experience with relational databases, but have never looked at MongoDb before. It covers all the basics but also several advanced topics like sharding and replication. I didn’t modify my slides much from the last presentation, but I did cover a lot of material not on the slides.

The talk lasted 2 hours. There are times in the audio where I am walking through the demo of the mongo shell, or the c# code that it may not be too easy to follow with only the audio. I apologize for that.

The most interesting part of the talk (in my opinion) was the replication and sharding, which is at the end (starting at about the 1h 20m mark), so if you are interested in that, you can fast forward there.

MP3 Audio File
Keynote Presentation File

Updated Introduction to MongoDB

Enjoy.

-Chris

Posted in .NET, C#, MongoDB, NoSQL | Tagged , , , | 1 Response