Four stages of competence

4 April 2014

The learning model that has been the most use to me has been the Four stages of competence. I think part of the reason I like it is I find a bit of humour in calling myself incompetent. I am a bit of a Highlander fan and when I hear the word incompetent I remember this scene from the movie:

Tony the Hotdog Vendor: [as Tony reads a newspaper headlined: Headhunter-3, Cops-Zero] Hey Moran! Have you read what it says in here?

Lieutenant Frank Moran: You kiddin’ Tony? You know cops can’t read.

Tony the Hotdog Vendor: [Teasingly to Moran] What does ‘INCOMPETENT’ mean?

Movie trivia aside.

To learn you have to acknowledge that you don’t know something. At this point you are moving from Unconsciously Incompetent to Consciously Incompetent. This can be the hardest step for some people but is critical to start the learning process off. As a mentor this is one of my big challenges. Thankfully I often draw the Four stages of competence matrix and call out there is a long list of things in the unconsciously incompetent quadrant that they just don’t know about.

Four Stages of Competence

and so starts the learning process from there.

I hope you find it as useful as I do.

Are we there yet?

24 December 2013

For those parents out there they will be familiar with the cry from the backseat of the car on a big journey, “Are we there yet?” Much like children Project managers have a need to know how far we have to go and more importantly are we there yet i.e. can I mark your task as complete.

Setting out on a journey from Melbourne to Sydney it is pretty easy to know how long the journey will take and more importantly how you are progressing and a fair idea of your estimated time of arrival.

Let’s say you were one of the early explorers and didn’t have a specific destination in mind nor an idea of the terrain between you and where you were heading. Pretty hard to know how long your journey will take or how you are progressing.

Solution Architecture can sometimes be like the early explorer scenario. It usually comes down to how many unknowns there are in the problem space you are working in. Stop and think about that for a tick the length of your journey is proportional to the number of unknowns. So if I can identify all the unknowns there are I will know how big the problem is and a rough idea how long it will take to solve.

Image

This introduces one of my favourite concepts which are known unknowns. Now the first step isn’t to turn the unknowns into knowns but just to identify there is something you don’t know the answer to. A good way to track this is to group these unknowns. You can group them into problem spaces or along functional lines depending on the type of solution you are developing.

This grouping of the solution provides a good way to communicate progress of the design activity. This can be expressed as two components:

  1. Unknowns that I have discovered (Known Unknowns)
  2. A gauge of how many unknowns you think you have discovered i.e. a percentage or traffic lights (red, amber, green)

Just be aware that the role of the Solution Architect isn’t to identify every unknown and it isn’t to turn every unknown into a known.

Known Unknows well these are the points where you do your best work. If you deem the unknown to be architecturally significant you need to get down and turn the unknown into a known and find a solution. If the unknown isn’t architecturally significant at this level of design then you just capture it but don’t need to solve it.

Unknown Unknowns well you don’t know. Looking at your solution there is a cloud of unknowns surrounding it, it is just there. You need to assess all the areas of your solution and look for weak spots, areas that the unknowns can penetrate and invalidate your solution. At these points you can do one of two things

  1. You either do some more investigating and identify the unknown
  2. Or you put a risk or assumption that underpins your design decision. Kind of like an unknown force-field.

So how does that sound as a way of venturing where no Solution Architect has ever ventured before? Pretty simple really isn’t it. Identify the unknowns that will impact you solution. Turn the important unknowns into knowns and find solutions for them. How easy could it be? Now try and get a Project Manager to put those tasks into a project schedule.

Good Luck!

On “Geek” Versus “Nerd”

30 July 2013

Originally posted on Slackpropagation:

To many people, “geek” and “nerd” are synonyms, but in fact they are a little different. Consider the phrase “sports geek” — an occasional substitute for “jock” and perhaps the arch-rival of a “nerd” in high-school folklore. If “geek” and “nerd” are synonyms, then “sports geek” might be an oxymoron. (Furthermore, “sports nerd” either doesn’t compute or means something else.)

In my mind, “geek” and “nerd” are related, but capture different dimensions of an intense dedication to a subject:

  • geek - An enthusiast of a particular topic or field. Geeks are “collection” oriented, gathering facts and mementos related to their subject of interest. They are obsessed with the newest, coolest, trendiest things that their subject has to offer.
  • nerd -A studious intellectual, although again of a particular topic or field. Nerds are “achievement” oriented, and focus their efforts on acquiring knowledge and skill over trivia and memorabilia.

Or, to…

View original 1,308 more words

Mentoring

30 July 2013

I hope I haven’t had this impact on the people I have mentored?

 

Mentoring

Project Management Triangle

30 July 2013

The Project Management Triangle is one of my favourite models that I find myself drawing on many occasions. As an architect you are constantly having scope discussions and while at an architecture level it may be OK it impacts time and/or budget which may not be satisfactory. This is a simple and effective way to explain why:

Project Management Triangle

Collecting Questions

18 February 2013

I posted previously about the benefit of an Architecture On A Page and the benefit that it provides as an architect. Being able to socialise an architecture is an important part of the job of an Architect. You socialise your architecture so that you can understand that different people’s wants of the final design are. A tester will have a different perspective to the asset manager who will need to support the application.
These conversations and the resulting requirements, constraints etc are what my maths teacher used to refer to as my working out. Much like I needed to show my working out to a maths question it is important to show your working out to an architecture. This working out presents to people the different ways you have looked at your design and takes them down the journey you have been on to discount options and refine the architecture.
Unfortunately there is never a “perfect” architecture; it is always a set of tradeoffs that need to be made. Your ability as an Architect to make your design as good as you can and also your ability to communicate this design is driven by the completeness and accuracy of the considerations you have made with regards to the architecture.
To build this picture I refer to the technique of “collecting questions”. By this I mean that we often socialise our design with the intent of getting questions answered. The other way to look at this is to as you socialise the architecture is to listen to the questions stakeholders ask and make note of these. These questions are what form your working out. If the asset manager asks if the technology fits the skill set of his team of .Net developers and you present a java solution he isn’t going to be happy.
The Architecture on a Page is the answer to the question but you need to show your working out and to make sure you have considered everything in your architecture. To do this make sure you go collecting questions.

Architecture Debt

14 December 2012

I have had the idea of Architecture Debt on my mind of late, most designs have something in there that you could class as Architecture Debt. Mmmmmmmm

We are different

26 May 2011

A great post on how people being different can make simple tasks complex if not impossible.

http://www.avioconsulting.com/blog/bdean/2011/03/24/jury-duty-facilitation

Good enough for Einstein

18 March 2011

One of Einstein’s colleagues asked him for his telephone number one day. Einstein reached for a telephone directory and looked it up. “You don’t remember your own number?” the man asked, startled.” No,” Einstein answered. “Why should I memorize something I can so easily get from a book?”

In this day of Google do you need to memorise anything?

Sorry Server

19 January 2011

What else would you call the Server that manages your 404 and other HTTP errors but the Sorry Server


Follow

Get every new post delivered to your Inbox.