I’ve had several screencast tasks hanging around in my todo list.
So I just spent an hour and scripted 3 of them. They will be much easier to make now that I know what I want to say. Each are written “out by the numbers.”
Sam Carpenter of CentraTel pounds repeatedly on the notion of linearizing your systems. This is a great notion. It works because it’s true, processes proceed one step at a time.
Which leads to the following observation: there is a cognitive difference between creating a process and following a process.
This is a no-brainer, really.
What’s more important is how these activities are monetized.
- Creating processes is a high dollar skill. It takes time, effort, and experience to create working processes.
- Following a procedure takes much less time, effort and experience.
By “monetizing,” I mean how these activities get invoiced.
Figuring stuff out should be invoiced at a high rate, provided the activity is novel (that is, you can’t outsource it). In other words, figuring out what to build is high dollar.
Actually building it is low dollar.
Whether the high dollar person needs to know all the details of the low dollar activity is a different discussion, and there are strong cases to be made on either. Ultimately, it depends on the nature of the work involved, and the expectations of who is doing the work and who is paying for it.
Think about your current blocker, that task you need to get done, but for some reason it’s not happening. Can you take a lateral approach?
Write down the very first thing that you need to do, even if it’s as simple as opening your web browser to log in to your project management system.
What’s your second step?
{ 4 comments… read them below or add one }
I tend to agree here. Linearizing is very powerful, I have started to employ this as a way to order my broken down tasks – most things have an intrinsic order if you think about them, task A must be done to do task B, or even, it would be nice if task A was done before task B.
I can relate to your invoicing comment as well, in software design, if you’re tasked with designing a new system then learning the system is the hard part (the high dollar part), and actually implementing it is the mind numbing bit (going through the motions). I like a little of both, but it’s always fun learning something new :)
Josh Kohlbach´s last [type] ..Brainstorming 101 with bubblus 20 beta
This article is partly in response to an interview I had recently. As a result of that, I’ve started into an intensive round of very low level web development, bringing database applications up from scratch in Ruby on Rails.
It’s a bit of conundrum for me: people seem to want “specialists in everything.”
Did some studying on tree recursion in Abel and Sussman as well, just to refresh.
Dave Doolin´s last [type] ..Give Yourself Time to Write Better
“Specialists in everything” is something I’ve tried hard to accomplish pretty much all my life. I like having a working knowledge of a lot of topics, but it really is a fools errand (as I’m discovering), even if people are expecting it.
What I’ve started doing is cherry picking the areas I want to get really into and boost my knowledge above that 80% mark. Everything else I’m happy to just have 80% of the picture and find out the rest as I need it.
Makes me sound like an idiot sometimes when I reckon I know what I’m talking about and I find out later that I don’t ;)
Josh Kohlbach´s last [type] ..Blogging With Zemanta – Content Linking and Tagging Made Easy
I think there is value in going super deep into something. Probably anything will do. Deep enough to really force new mental connections.
The reason I believe this is two reasons:
1. Going deep into a second, related field will be much easier. You will see many of the same connections faster.
2. When you are regarded as an expert in one thing, people tend to regard you as an expert in everything. The “celebrity effect.”
Dave Doolin´s last [type] ..Backlink Kickstart – Don’t wait- create your own