May 072013
 
Me presenting at KCDC 2013

Me presenting at KCDC 2013

Thirty-six hours before the first KCDC precompiler session began, I got a call from Kansas City’s premiere Lean/Agile expert asking if I could fill in for him at the Agile and Lean Workshop precompiler due to an emergency.  Twelve hours before the session began, the United States’ premiere Lean/Agile expert was delayed by snow and told me he couldn’t make it to the session until lunch.  That left me and this guy, or in other words, George and Ringo, and Ringo had a conference to run.

And it went great!  We had a really good group who gave us good questions to work with.  We played some games.  We talked about Scrum.  We talked about Kanban.  We talked about all the hot button Agile topics like estimation, bidding, and ongoing maintenance.  It was a good, energizing talk that reminded me how much I enjoy that sort of thing.

P.S. If you were at that workshop, please take a second and leave a rating for me at SpeakerRate.  Much appreciated.

Friday morning, Dan “Kan-Man” Vacanti gave a terrific keynote about how we serve our customers better with pull systems for doing our software development as opposed to push systems.  He also gave my own session a quick shout-out for which I am grateful, because without context, most people don’t get too fired up about a talk called “Lean Metrics.”

Next, I gave a talk called “Lean Metrics.”  Standing-room only with some people sitting in the aisles.  It was a huge fire hazard and OSHA violation, but it charged me up.

We talked about why estimation fails us and how keeping metrics can overcome some of the weaknesses of estimation, providing a better foundation for our planning and projections.  Then, I demonstrated control charts and cumulative flow diagrams, explaining how each one can help us in not only estimating, but also continuous improvement as well as challenging elements in the organizational culture that dampen agility.

Here are the slides for that presentation, and if you were there, it’d be cool if you left me a rating for that talk at SpeakerRate.

After this was over and I was carried out on the shoulders of screaming fans, I spent a little bit of time catching up with contacts from KCDC’s various sponsors.  This was an especially good KCDC for sponsors.  We had 850ish people there, which meant that, even between sessions, there was a continuous flow of activity to the various booths, unlike previous years where booth visits were pretty bursty in between sessions.

I attended an eye-opening talk on UX from John Alexander, a talk on the enterprise use of HTML5 and various JavaScript libraries from the Keyhole team, and a truly thought-provoking talk on what other languages have to teach us about object-oriented programming by Jessica Kerr.

That night, dinner and drinks with a huge crowd of people I usually only see once a year.  Also, Sugar Ray gave a concert nearby.  Nobody noticed.

I did not get to attend on Saturday, but I hear good things.

I think the venue worked out great, the crowd was numerous and diverse, and the variety of speakers and topics made sure there was at least something for everyone.  It may have been our most valuable KCDC yet in terms of investment.  If you didn’t go this year, dude, go next year.

Enhanced by Zemanta
Apr 182013
 
A look down Downtown Kansas City streets today.

A look down Downtown Kansas City streets today. (Photo credit: Wikipedia)

This is more general than Kansas City, really, but I’m finding that putting “in Kansas City” in the title of my posts tends to create a lot more discussion (and anger, but I’m a big boy).  I’m thinking of it being the new phrase I add to the end of fortune cookie fortunes.  “The dragon of opportunity also breathes fire… in Kansas City.”

I was thinking about this, because I see a lot of effort being expended in Kansas City, but I’m not sure I see all that effort producing many helpful results.  This could possibly be a side effect of startup culture - the assumption that doing something is the same as improving or getting good results.  It doesn’t matter if your business idea is sustainable or marketable, it only matters that you start it.

And I understand to a point.  It’s a necessary corrective in an economy where people are afraid to start, disrupt, do, or finish.  You have to get people past the initial hurdle before you can even talk about anything else, and that initial hurdle is usually starting.  Doing something.

Unfortunately, this is where the conversation usually stops.  If someone is doing something, we laud them for it.  Well, ok, fair enough, but success isn’t defined by expending effort; success is defined by results.  If I bust my butt trying to help developers get jobs, and I don’t get any of them a single job, that might mark me as having an altruistic heart, but it doesn’t mean I’ve been good for Kansas City (or whatever community you happen to be in).  Nobody says, “The Chiefs are such an awesome team; look at how much training they do!”  They want points on the scoreboard.

So, I’ve made a checklist for myself.  It’s not comprehensive, but it does help me continually measure whether I’m actually making an impact in my community or just generating a lot of activity:

  1. Did I help someone get a job or create a job for someone to fill?
  2. Did I help a company increase their profits, lower their expenses, or protect assets that would otherwise have been at risk?
  3. Did I help people, in any line of work, deliver more value?
  4. Did I help a person or an organization who stumbled get back into the race?

That’s my personal scorecard in the Game o’ Improving Kansas City.  This is not my scorecard for all aspects of life, but for measuring my impact in Kansas City’s economy, it’s a decent one.  I put numbers to each of those and, most months or quarters, I can.  And I’m just one person who is a relative nobody.  Just think of what groups with actual money and clout could do.

As Eli Goldratt once said, “Tell me how you measure me, and I’ll tell you how I behave.”  As you can see, a scorecard like mine drives certain behaviors, or at the very least, puts those behaviors in context.  It allows me to identify low value and high value activities.  It allows me to measure success.

So, in terms of impact, here are examples of the things that matter most:

  • Hooking people up with job openings that are good fits or, secondarily, referring people to the extremely small number of recruiters that I trust.
  • Helping an organization identify where their biggest gains would come from in terms of hiring new people.
  • Teaching people skills that make them more marketable and/or enable them to perform better and deliver more value to their organizations.
  • Turning around a struggling business.

Here are examples of the things that don’t have much impact at all:

  • Blogging
  • Creating or hosting “events”
  • Tweeting
  • Meeting with like-minded people so I can continue to agree with myself

Obviously, I enjoy some the things on that second list and get value out of them, and they generate some value in their way, but in terms of measuring actual points on the scoreboard that impact Kansas City economically, they mean almost nothing.

Interestingly, when you look at the various entities trying to do this or that for Kansas City, we tend to be very good at that second group of examples, but not so demonstrably good at the first group.  We’re very good at creating entities and generating interest and energy (and occasionally funding), but we’re not so good at actually delivering valuable contributions.

And lest I be misunderstood on perhaps the most potentially ire-generating point in this post: creating and hosting an event in and of itself is a very low value activity that helps nobody, except maybe the venue you paid to host it, and we create TONS of events.

Did your event create new jobs?  Did it put people in jobs?  Did it save any company any money?  Did it help them make more money?  Did it get capital to someone who needs it?  Did it revive a failing business?  Did it enhance anyone’s job security, marketability, or ability to deliver more value than they had before?  If the answer to one or more of those questions is yes, then your event made a positive impact in the community!  Otherwise, it might have been a fun event, but the net effect of it was nothing.  Lots of effort, no points on the scoreboard.

Like I said, our strength as a city seems to be talking, getting things going, building up buzz, generating motivation… we have a hard time delivering anything that actually changes anything.

So, my challenge to you, whether you are an individual or an organization that is trying to improve business in Kansas City, is this:

Don’t just start things; start the right things.  You don’t need to plan all the details of your endeavor before you begin, but you do need to know what success looks like and how you’ll measure it.  Spend your time on the activities that will generate actual impact as opposed to perceived impact.  Change lives.  Improve the economy.

I’m definitely on your side.

Enhanced by Zemanta
Apr 152013
 
Illustration of the event horizon (Schwarzschi...

Illustration of the event horizon (Schwarzschild radius) (Photo credit: Wikipedia)

The idea of an event horizon comes from general relativity, but if you’ve ever heard of an event horizon, you probably know it either from black holes or from that weird Laurence Fishburne movie.  With black holes, the event horizon is that boundary around a black hole that marks the transition from “you could conceivably still get away with enough force” to “you’d better tell your friends you’ll be late to the bar.”  Black holes are always pulling at the things around them, but the event horizon defines the difference between having to deal with a black hole and actually being inside one.  Interestingly, from the outside, objects that pass the event horizon seem to disappear completely.

Event horizons are the ultimate black box.  They are the universe’s embodiment of that fight or flight moment.  You can get in, or you can stay out, but you can’t stay there.  In fact, the force required to stay in an event horizon increases to infinity.  The longer you try to remain neutral, the harder it becomes until it’s impossible.

When an organization decides to increase their agility, this effort also has an event horizon.  Generally, these efforts either originate in management and spread out, or they originate in an implementation team and spread out.  The latter is far more common.  Management might mandate the agile effort, but the actual transformation begins in an implementation team.

Regardless of where it starts, this effort has a boundary that attempts to suck in everything else around it.  Agile transformation efforts are not static.  You can’t just take, say, a team of software developers, get them all agiled up, and expect this to have no ramifications for the rest of your organization.  What you have done is created a singularity that, given enough time, will draw in the entire organization.

This is actually what you want.  This is one of the benefits of truly agile efforts; they can’t stay in their little box.  That event horizon is defined by the boundaries of contact between your “agile teams” and the rest of the organization.

Does your project management have distinct, Waterfallish phases?  The event horizon will eventually touch that.  Do you budget your projects on a cost-based approach where you have to allocate all the money up front?  The event horizon will touch that.  Are you constantly changing priorities at the top?  The event horizon will touch that.  Do you have tons of processes solely designed to protect the company from itself?  The event horizon will touch that.

In ways you never even intended, the singularity will try to draw all aspects of your company into it, and the event horizon marks that boundary of change.  Objects pass into it, and that’s where you have the critical moment of decision: do you allow accounting, management, project management, the executive team, and sales to pass through the event horizon, or do you expend force to keep them outside of it?

The answer to that question says a lot about the ultimate success or failure of an organization trying to be agile.

Enhanced by Zemanta
Mar 292013
 
Justin Bieber at the 2010 White House Easter E...

Justin Bieber at the 2010 White House Easter Egg roll. (Photo credit: Wikipedia)

So you’ve discovered that the community attention and critique of being a thought leader isn’t for you.  You’d like to get out of the game, or you want to avoid becoming a thought leader in the first place.  I, Phil, noted Thought Leadership Avoidance Expert (TLAE), am here to help with some tips to get you started on the road to recovery.

1. Tell People You’re a Thought Leader

This might seem counterintuitive.  If you don’t want people to think of you as a thought leader, why would you tell everyone that’s what you are?

Well, telling people you’re a thought leader is like telling them that you’re cool, funny, or handsome.  If you have to tell people that’s what you are, it probably means you aren’t.  Justin Bieber’s LinkedIn profile doesn’t say “Pop Culture Phenomenon.”  At least, I assume it doesn’t.  I don’t actually network with Justin Bieber for business purposes.

Thought Leadership is something that people recognize about you, not something you declare about yourself, so labeling yourself this way is a good signal that you aren’t a real thought leader.

Put it on your LinkedIn and Twitter profiles.  Use other synonyms like “(Your Industry Here) Disruptor.”  Make sure every opportunity you have to present yourself to the world, you put up a big, neon sign that says, “You’d never think I was this unless I specifically told you.”

2. Claim Your Employees’ Expertise for Your Own

Business owners hire employees who are better at them than something.  The person at the top of a business typically doesn’t know the most about every aspect of their business.  You can be the successful owner or CEO of a cat food company without having in-depth knowledge of every aspect about how cat food is made.  Your focus is on the successful operations of your business, not being a subject matter expert in every facet of your industry.

Because of this, it’s very common to have business owners who have a basic understanding of their field at a high level, but their employees are actually the ones with very deep knowledge of the area in which that employee works.

If you want to avoid being a real thought leader, pretend that your employees’ expertise is actually your own.  Repeat things in conversation you’ve heard them say.  Write blogs that are nonsensical combinations of terms and concepts you’ve gotten from them.  Have a two hour meeting with all of them to educate you on a particular topic, then write a blog about it pretending like you came up with it all yourself.

Sort of like telling everyone you’re a thought leader, this might initially make you look like one, but in the long run, you’re doing irreparable damage to your credibility.  For every one person who doesn’t know any better who says, “Wow, you’re so insightful,” there will be a dozen people who actually understand your field going, “This makes no $&%@# sense.”  People will be laughing about you behind your back in no time, and your status as a No Thought Non-Leader will be secure.

3. Read a Book and Pretend to Be an Expert

You know that friend of yours who watched celebrity poker tournaments for a week and now considers themselves a professional-grade Texas Hold ‘Em shark?  Everyone knows they’re full of it, because on what planet does a small injection of knowledge make you an expert at anything?

You can do the same thing to torpedo your reputation as a thought leader!  It’s easy!  Just read a book and start talking as if you could have written it, yourself.

Having trouble picking the right book?  Here’s a good starter list for software development:

  • Tribal Leadership by Dave Logan et al
  • Agile Project Management with Scrum by Ken Schwaber
  • Anything by Mike Cohn

These are ok books, but we don’t care about that for our purposes.  We’re looking for books we can read and then fake being an industry expert.  These books and others are ideally suited for that, and people have become industry pariahs overnight by reading books like this and then pontificating about the issues discussed in them.  Everyone will know you aren’t a real expert, and this will drop your Thought Leadership Index (TLI) rapidly.

4. Don’t Have Thoughts

The most effective way to get out of or stay away from the whole thought leader thing is to avoid having any actual innovative or useful thoughts.  If you are already using techniques 1-3, you are probably already doing this step by default.

One time-honored way to practice not having thoughts is becoming a Zen Buddhist.  But the next best thing is to highlight problems or issues without having better ideas.

  • “Most companies approach software development all wrong,” but damned if you can show them how to do it right.
  • “Companies need to change their culture,” but you have no idea how to actually change a company’s culture.
  • “We need to disrupt our industry,” but don’t disrupt your industry.

Constantly highlighting problems without offering any solutions is a Grade A path to not being a thought leader.  You aren’t actually thinking of anything or leading anyone.  It’s perfect.  It’s like giving a big middle finger to the concept that leaders, innovators, and disruptive thinkers actually have to come up with anything.

Finally, to sum up and give you a set of principles to live by (because let’s face it, there’s no way you’re coming up with any), I offer the Anti-Thought Leadership Manifesto:

We are uncovering better ways of making fools of ourselves in our fields by doing it and helping others do it.  Through this lack of actual work, we have come to value:

  • Style over substance
  • Rhetoric over content
  • Criticism over solutions
  • Books and blogs over experience

That is, while there is value in the items on the right, we value the items on the left more.

Enhanced by Zemanta
Mar 282013
 

If you use jQuery dialogs and create the buttons in the JavaScript, you need to be aware of a few things:

  1. The button text is inside a span tag within a button tag, so you can’t find the Button object directly by text.  Finding the span and clicking the span work just fine.
  2. The button lives inside a DOM generated div with a class of “ui-dialog-buttonset” and not directly in your dialog div.

So, the quickest and dirtiest way to click the button would be something like:

Browser.Document.Span(Find.ByText("Save")).Click();

But you’ll probably want a selector chain much more specific than that, especially if you have more than one dialog form on the page.

I couldn’t find anywhere on the Internet that spelled this out for me, so I hope this saves somebody somewhere a little time.

Enhanced by Zemanta
Mar 272013
 
English: Picture taken from the Liberty Memori...

English: Picture taken from the Liberty Memorial in Kansas City, MO. High Resolution. (Photo credit: Wikipedia)

The flip side of the education coin are the employers.

Regardless of the causes or who thinks what about how we got here, the fact is that employers in Kansas City are having a hard time finding and retaining talented IT people.

It’s very easy to say that there aren’t that many talented developers out there or look to some cause external to yourself.  Obviously, per yesterday’s blog, I think there are things that training institutions could be thinking about differently to try to address this shortfall.

However, like I tell my teams, spending your time complaining about external causes has very low value.  Whether you’re right or wrong is irrelevant – you can’t control external causes.  The economy is what it is.  The market is what it is.  Kansas City is what it is.  You’ve been dealt a deck of cards, and that’s the cards you have to play.

The high value activity is looking at yourself – doing the hard, painful work of being self-critical.

Why should I come work for you?

There is no New Economy.  It’s now officially just The Economy.  You probably don’t have the funds to golden handcuff a squad of dream employees to your organization.  You may want Brett Favre, but you have the money for Matt Cassel.

If you do have those funds, then don’t hold back.  Don’t be “competitive” with your salary.  Blow everyone else out of the water.  Be disruptive with your compensation.  You compete in every other area; why not compete in this one?  But, honestly, it’s not usually about vast differences in salary.

It’s usually about what life will be like for your employees.  Do you put your developers in fabric-lined jail cells and saddle them with meaningless deadlines, tedious processes, and a culture that is basically designed around the idea that your employees are lazy and can’t be trusted?  Do you have unclear priorities?  Do you align your development projects and your developers with your company’s objectives?  Are they a part of something bigger than themselves?  Or are they a machine where requests come in and product comes out?  What are employees getting into?

If you have a scenario where no one would want to live in it for more than a year, don’t expect to attract and retain top talent.  Don’t dehumanize your developers and then complain about how hard it is to find people.  Kansas City has lots of exciting things happening, but in terms of its ecosystem, it has a small town dynamic to it.  Everyone knows everyone else.  Every developer has six degrees of separation from Kevin Bacon and someone who left your company.  What stories do they have to tell?

But here’s the other big one.

Are you giving new folks a chance?

Just for the sake of argument (I’m not necessarily granting this point), let’s say that Kansas City’s available hiring pool is light on the experienced hotshots who have mastered a wide array of technologies, and let’s say it’s heavy on recent grads, career-changers, and junior level devs.  Let’s say the perception is reality.  Let’s say, for every twenty resumes you get, only one or two seem really shiny.

What are you going to do about it?  These are your cards.  You can’t change them.  What’s your play?

Well, you can poach heavily, and while you might attract some high-end talent that way, why would you think those same people couldn’t be poached by someone else offering a 10% increase in salary?

Or you can deal with reality.  Instead of trying to fight the trend, why aren’t you harnessing the trend?

  • Do you have an actual plan to turn junior developers into senior developers over time?
  • Do you pair up your superstars with your newbies on projects so they can work on each other’s code and have a true mentoring / apprenticeship relationship?  Or do you silo your developers and just give the junior levels the “easy stuff” or maintenance tasks?
  • Why aren’t you giving new devs a chance, knowing that, sure, it won’t work out for some of them, but some of them will be gold?  Some of them will be the backbone of your efforts for years to come.
  • Why isn’t hiring new grads or career changers part of your strategy to get ahead of your competition instead of something you are trying to avoid at all costs?
  • Why don’t you give recruiters a list of personal characteristics that you want to shape your teams and your culture and draw your line in the sand there instead of pre-packaged technical knowledge or an arbitrary number of years of experience?
  • Why aren’t you open to hiring someone who works outside of your technology stack to see if they can bring innovative ideas or problem solving abilities that your current stack might not foster?  I’d hire a passionate, thoughtful Java developer for a .NET shop over a “this is just my job and I’ve coded the same way for ten years” C# developer any day of the week.
  • When you hire a senior level developer, are you asking about their mentoring abilities?  Are they someone who can help the more junior level developers grow?  Will they build your team into a high performance nightmare for your competition, or will they just crank out your code and take their paycheck?

Now, I’m not suggesting you just randomly hire a pack of people with no experience and no knowledge of your development base, but what I’m saying is this: instead of whining about the lack of experienced developers, why not proactively work with the reality on the ground?  Why not intentionally plan to hire junior level people with a very deliberate plan to grow them into your future team leaders?  Can you imagine how attractive that would be to job seekers?

As a long time developer myself, I’m going to let you in on a little secret.  Being a good or a bad developer has virtually nothing to do with experience, education, or anything else you’d find on a typical resume.  It has everything to do with passion, drive, and a self-generated commitment to learning and continuous improvement.  Isn’t that what you want your company to look like?  Wouldn’t you love a team of people spurring each other on to greater and greater performance?  Hire for that.

If you can plan for that – if you can design your hiring process that way – you might find that it’s not as hard to hire good developers as you thought, and you’ll find yourself looking at a crop of eager new hires ready to show you what they can do and having a vested loyalty in the companies that believed in them.  While your competitors are still behind looking for the next superstar or trying to steal her, you’ll be getting your projects done and growing your own superstars.

Enhanced by Zemanta
Mar 262013
 
The Careers Day poster they rejected

The Careers Day poster they rejected (Photo credit: Alun Salt)

DISCLAIMER: I will use specific examples throughout this post without naming any names.  I want to make it clear that this is not picking on any one particular institution or form of IT training.  I have been a trainer for one of Kansas City’s largest IT training firms.  I have taught college classes.  I have made training DVDs.  I have subcontracted to teach with other training companies who span the globe.  These issues are in lots of places, so please don’t take any specific example and assume I’m trying to come down on a particular institution or practice or favor one over the other.

In doing the research for this post, I started going through the websites of various “career changer” programs.  You know, the programs where someone wants to make a big change and get into an IT career, but they have no real background or experience, so they sign up for a multi-week program to teach them foundational skills that, ideally, is enough to get them an entry-level job to start them down a new career path (incidentally, I totally believe in this model if done well).  I was looking for success stories.

What I discovered was that most success stories were several years old.  In fact, one institution led with a great success story in their marketing materials for their program.  That story was five years old.

Think about that for a second.  All the students that pass into and out of this program, month after month, year after year, and the best results they’ve gotten so far were five years ago.

Despite the current fad of people with no real knowledge of the field inventing statistics to try and prove there’s a developer shortage in Kansas City, the reality is far more complicated.  If there’s any shortage, it’s a shortage of highly qualified developers in Kansas City.  If you post a job opening in IT right now, you’ll have no shortage of applicants.  You’ll still have a hard time finding someone.  In fact, just a couple of months ago, a friend of mine who is responsible for hiring for a very large organization here in Kansas City told me point blank, “We’re getting lots of applicants, but most of them are graduates from Institution X and don’t know s***.”

There’s a disconnect.  Four-year institutions, two-year institutions, and training companies continue to churn people out into the market, but the market doesn’t seem to be buying.

On the other side of the fence are the pundits who just flat out say that colleges and/or career-change programs just don’t work.  This doesn’t seem right either, because there are successes and, quite frankly, it’s hard to think of another model that can accommodate the quantities and speed of the market right now along with the depth of knowledge required to write good software.  If you don’t have organizations dedicated to making this happen, the odds are good it won’t happen at all.

My premise, which of course may be wrong, is this:

Organizations who train IT careers, specifically development, need to ditch their current models and adopt ones that are market-responsive and student-first.

Curriculum

Most IT training organizations are not matching their curriculum to demand.  This is a known issue with two and four year institutions, but it is a staggeringly huge issue with IT training companies and career-change programs in specific, and it has been this way for a very long time.  I’m not talking about the specific manuals they use or whatever; I’m talking about the actual topics covered.

Every so often, I’ll see an update somewhere that looks something like this, “Getting ready to learn design-time data binding to datagrids.  Whole new world!” or “Finally creating DataSets.  This stuff is awesome!” and I die a little inside, because these are the functional equivalents of someone training for the medical field and tweeting about leeches and hacksaws.

Nobody wants that stuff because nobody is doing that stuff.  No company is trying to hire someone for web technologies and methodologies that are now 12 years old (NOTE: Ok, obviously, occasionally people do hire for very old technologies because they need to support old products or simply refuse to change, but I’d say that’s not where most of the technical demand is).

In researching this post, I pored over job openings in Kansas City for .NET web development, and they were asking for MVC, HTML 5 and JavaScript, NoSQL, ORMs, TDD, MVVM, and design patterns.  I found two that asked for ADO.NET (along with the other things on this list).  If the whole purpose of your company is to release people into the field who can perform a trade, why isn’t the taught curriculum aligned with what people are asking for?

Teaching Methodology

PowerPoint slide.  Explanation.  Demo.  Lab.  Not.  Ideal.  For.  Career.  Building.

That way is ok-ish for getting across a specific technical topic to a specific kind of audience and background: namely, the kind of audience who already knows how to build applications and practically apply their knowledge in the field.

But if you want to teach someone how to build applications, then you build applications and instill the requisite knowledge as you go.  And when I say “build applications,” I don’t mean labs that have been specifically designed around a particular concept.  Those are notoriously unrealistic and often actively teach bad practices and bad ways of solving problems, because the focus is on that specific concept and not the other parts of development around that concept.

“But if I’m trying to teach someone data access, I don’t have time to teach things like proper separation of concerns in the class layers or HTML 5.”

Exactly.  That’s exactly the problem right there.  You’re trying to teach someone data access instead of teaching someone how to build an application and talking about data access in the context of building that application.  People leave your training (even if it’s a four year program) knowing a ton of isolated, bad examples of various technologies, but they do not understand how to solve problems with these tools, how these tools interconnect, or when these tools are bad decisions.  And because you are so focused on teaching them a technology, they probably have never even seen a realistic example of it.

This dovetails with another issue, that most IT instructors/professors in Kansas City are not developers or haven’t been for a long, long time.  They are just as incapable of teaching a class driven by actual development as their students, and their knowledge and experience is just as limited by the curriculum as the students.  It’s not impossible, but it’s very hard to learn a trade from someone other than a tradesman.

Economics and Risk

Most IT training programs require the student to pay regardless of the result.  Some companies are thankfully breaking away from this model, but it’s still the most common model.  Students pay tuition to the training institution no matter what.

Two problems here.

On the student side, it puts them at enormous risk.  They have to pony up (or taxpayers have to pony up, in some cases) several thousands of dollars that may ultimately result in nothing.  Although I’m way more concerned about the students than the institutions who train them, this is actually not the biggest problem.

The biggest problem is that, on the institution’s side, their primary motivational force now becomes getting people into their program.  Not preparing them for jobs.  Not getting them jobs.  Getting them in the door.

When the training company I worked for started doing career change programs around late 2000, they made all prospective students take a short test.  It was things like pattern recognition, etc.  Nothing heavy duty, but it did look at their ability to spot patterns, think symbolically, etc.  At the time, a student had to score a 90% or above to be admitted to the program.

Over time, it got lowered to 80%.

Then 9/11 happened and the training market tanked big time.  60%.

Eventually, the test was completely done away with.  We got people in our program who were great people, smart people, and very gifted in many ways, but coding at an in-depth, professional level was just not something well-suited to their way of thinking and gifts.  But we took their money, gave them their diplomas, and sent them out the door.  And I quit.

The thing is, the success of our students only indirectly affected our prosperity (by way of marketing).

How would it transform things if institutions only got paid if and when their students got their first IT job?

Holy crap, right?  Now, I have an interest in helping students find their proper niche here or elsewhere.  I’m only interested in putting the student in a web development program if I think the student has the chops to be a professional web developer instead of the chops to secure a $12000 loan.

I’m motivated to make sure my curriculum reflects what business owners want and need.  I’m motivated to make sure all my students are solid.  I’m motivated to make sure anyone who learns how to develop from me can go into a team of experienced developers and play at or above their level, because if they can’t, I don’t make my money.

Before I close, I just want to say that deep within the chocolatey-good depths of my cynical heart, I am warmed to see some amount of rising to the occasion.  The Disruption Institute, for example, shows a real initiative in looking not only at what the market needs today, but will need in the very near future, and organizes their curriculum around that – curriculum that has been put together by actual developers in the field.

I believe in training companies.  I believe in two year and four year computer science programs.  They all have their place for different people and different goals, and it’s a poorly thought through plan that would advocate getting rid of any of them.  But you have got to step it up.  If you align yourselves with market needs and commit yourselves to the students’ welfare first, the money will follow.

Enhanced by Zemanta
Mar 252013
 
Simplified scheme of an organization

Simplified scheme of an organization (Photo credit: Wikipedia)

One of the more misused terms in business is “team” (with “disruption” and “culture” being close).  Every business talks about their teams or describes themselves as a team, but I’ve worked with many organizations both inside and outside the Kansas City area, and I’ve seen few teams even on a small scale, much less an entire organization that worked as a team.  I see groups of people with common job functions.  I see people employed by the same company.  I don’t see a lot of teams.

I wrote The Five Second Team Test to smoke this out for teams within an organization, but what about the organization itself?  Is there a way for an entire company to work as one team?  That’s probably a book unto itself, but here’s my Slightly Longer Than Five Seconds Test To See If Your Organization Works As A Team.

Org Level Examples Deliverable Examples
Captains CEOs, Partners, Engaged Owners Strategic Goals 200 new subscribers by the end of next quarter
Lieutenants Other C-Levels, Department Heads Projects that will best achieve strategic goals Print marketing campaign, new feature launch
NCOs Managers Prioritized items that need to be done to achieve project Redo photography for ads, make 3d holographic interface for website
Enlisted Developers, Janitors, Implementers of any kind Actualized project New print ads, new website features

Now, obviously, you can’t reduce the complexity of organizational interactions to a five row HTML table, so let’s remember this is a quick and dirty smoke test and not a doctoral thesis on the many aspects of organizational dysfunction.  You could have the most streamlined corporate structure in the world, but people are people after all, for better and worse.

But what I want to highlight is that the chart above describes an organization that at least has the infrastructure in place to behave as a unified team.  Each responsibility is ultimately tied to a company’s strategic goal and can be traced there.  Each level has to make decisions about priorities, using input from the levels below, but ultimately is responsible for giving the next level the “what,” while leaving each level to determine the “how.”

The main point is this: everything everyone is doing is traceable to and subservient to the company’s currently prioritized strategic goal or goals, whether you are the CEO or the janitor.

You might be thinking to yourself, “Don’t most companies already operate that way?”

You’d think so, but they don’t.  In fact, I’ve only seen one that comes close.  Here’s what usually happens:

Captains: Serve as authority figures and public relations. Do not decide on any strategic goals, sometimes because of the possibility of failure.  That responsibility is delegated to…

Lieutenants: Interested in their own bailiwick and view the welfare of the company primarily through that lens.  Come up with projects they think are good ideas and lobby them to the Captains and other Lieutenants, hoping they will be more persuasive, powerful, or political.  Reluctant to take a perceived “hit” for the welfare of another Lieutenant or even share information with them.  The Captain serves no particular purpose in this process except to say, “Ok, sounds good.”

NCOs: Victims. The latest round of Project Proposal Shark Tank has dropped something into their laps that may or may not be realistic, a good idea, or may uproot priorities and direction, but it needs to be done and it needs to be done, yesterday.  The justification for the project involves some loose understanding of vaguely defined benefits along with, “Bob really wants this.”  Failure is not an option, leading to some high control practices.

Enlisted: Micromanaged, highly controlled group of people responsible for creating realized chaos.  They don’t know why they’re doing what they’re doing except maybe they know who’s yelling for it.  They don’t understand why their manager changes their workload and priorities every week.

As you can see, the process and the cultural issues are tightly coupled.  I hope you can also see the bad position this puts everyone in.  Nobody knows why they should be doing what they’re doing, but everyone knows they’ll be crucified if it doesn’t happen.  A lot of developer teams I work with remind me more of my time in SERE than anything else.

Now, your organization may not be as bad as what I described.  It might be worse; it might be better.  But sometime, waltz on down to your software developers, find a developer, ask her about the feature she’s working on and say, “Which of our company’s goals is this feature meant to help accomplish?”  If they don’t know, it might be your company isn’t a team at all.

Enhanced by Zemanta
Mar 222013
 
English: Drawing of the object model for Liqui...

English: Drawing of the object model for LiquidThreads. From a meeting at Wikimedia Headquarters, San Francisco. (Photo credit: Wikipedia)

Yesterday, the wolf pack was talking through a particularly complex domain model.  It was much more complex than your general one-to-many, one-to-one issues; it contained objects that were very fluidly related and often cross-related.  Object A has a collection of Object B, except sometimes Object B is a child object of Object C in Object A’s other collection.  Object B is also the parent of Object D, which may or may not be associated with an Object A.  So on, and so forth.

Of course, this wasn’t a discussion about coding; this was a discussion about how our customers wanted to use the software and what kinds of interactions best fit how they wanted to use the system.

So, we got a basic model put together that seemed to be all right, and just for kicks, I let Entity Framework generate the database tables.  It did a great job, making decisions about keys and constraints and who owned what relationships that I probably would not have thought of.  It was pretty genius.  But here’s the catch: although the object model made sense, using that database table structure – ingenious as it was – would cause lots of multiple table joins for even some of the most basic things users would want to see and do.

Then, the conversation moved toward the most efficient relational database design to get the performance we wanted, knowing we could use the ORM to map our objects to whatever structure we came up with.

A lot of times, when people think of ORMs, the main value they think of is not having to write a lot of data access code.  This is certainly an important value, and I don’t want to minimize that, but that’s sort of like saying the primary value of TDD is the ability to refactor your code without breaking anything.  It’s certainly important, but not really where most of the bang for your buck comes in.

To me, the real value of the ORM is the decoupling of your database tables from your object model.  This allows me to write my domain in the way that best reflects how these things actually interact in our business, in our code, and for our customers – while at the same time being free to optimize the database for the most performant way to store and retrieve the data relationally.  Having the extra layer of abstraction also allows me to tinker with either layer without breaking anything.

For simple applications, your database tables and domain classes may look similar, and for applications using NoSQL, this issue is barely on the radar if at all, but for complex apps using relational databases, you really don’t want your domain looking like a bunch of database tables and vice-versa.  Those two things have completely different roles in your application and have very different definitions of efficiency and good design.

So, if you struggle with your domain being hard to model in a database, or your domain is full of classes like “UserToRoles,” you might look into whether or not an ORM would help you out.

Enhanced by Zemanta
Mar 202013
 
"Respect My Authority" Cartman T-Shi...

“Respect My Authority” Cartman T-Shirt
at Target spotted by Scringy
(Photo credit: JeepersMedia)

Your Quote to Original Thought Ratio is Too High

Take a look at your tweets, your blogs, your online discussions, your presentations – all the collective information you present to the world or to a specific audience and ask yourself, “Could a well-filtered RSS feed have done the same thing?”

Remember that employee who always used to cut out magazine and newspaper articles and route them around, but never actually led any initiatives?  The modern equivalent of that is a high volume of “contributions” that are actually links to thoughts someone else had.  That does not make you an authority; it makes you a less-efficient headline aggregator.

Instead of looking for other people’s material all the time, why not try writing your own?

Your Quote to Original Thought Ratio is Too Low

We all stand on the shoulders of giants.  I did not write the Agile Manifesto.  I did not invent Scrum or Kanban.  I have not worked for every type of client in every type of situation, and my personal experience or “what makes sense to me” is not the final arbiter of truth or wisdom.

Sometimes, in our efforts to avoid dogmatic regurgitation of someone else’s work, we act as if it doesn’t exist.  If something is old, traditional, or in some other way not directly thought of or experienced by you, then it’s worthless.

I want to be clear that traditionally held views or a the opinion of Everyone Else But You can be wrong, but they are not wrong simply because they’ve been around a long time or they come from other people.  A true authority is able to think critically about other sources without completely disregarding them just because they happen to be traditional, commonly held, or disagree with your own views.

You Think Rebuttals Are Personal Attacks

One unfortunate aspect of our education system is that we’ve been taught from a very early age that wrong answers are unacceptable and our ratio of wrong to right answers are the primary determining factor of our intellectual ability and rate of success.  It’s no wonder that, when someone tells us that we’re wrong, we automatically feel like someone is basically saying we’re inept or a failure.

Sometimes, rebuttals can contain personal attacks, but people who are authorities view rebuttals with curiosity and interest rather than disdain or dismissal.  When someone tells you that you’re wrong, do you get on a soapbox to pontificate on why you absolutely must be right, or do you think that rebuttal is interesting, worth hearing out, and worth investigating?

I was a newly hired team lead at one company, and a couple of the developers gave a presentation on a piece of an application they’d put together.  After the presentation, I said, and I quote, “Why did you choose to do it that way?”  And, no, it had no sarcastic emphasis or anything.  Just a matter of fact question.  They reacted as though I’d basically asked, “Why did this company hire morons like you?”  They got mad.  Really mad.  It was as though the very act of questioning their reasoning was the same as condemning it.

Debate is good.  And if someone expresses a view contrary to yours, they can certainly be wrong.  They may even be really really wrong.  But an authority comes to that conclusion after actually entertaining the notion rather than assuming that the “opposition” is wrong by default or deliberately trying to make them look bad.  Take them as opportunities to find out rather than a personal attack.

You Don’t Check Your Sources

Fairly recently, one of Kansas City’s more prominent agile charlatans tweeted an article written a couple of years ago by Michael Sahota where he said that Scrum was more suited to a collaborative, personal development culture, and Kanban was more suited to a control culture that minimized the importance of the person.

What this person obviously did not know is that, today, Sahota has a very different view about Scrum and Kanban and uses Kanban as his default for helping an organization become more agile.  In fact, he said so in the comments on this very blog.  This person is not the only person to have made this mistake, but it is perhaps the most recent example.

What does this have to do with authority?  Don’t we all make mistakes?  Well, sure, but in this case, this person had not been actively engaged with his sources (who are still very much alive and writing) or the community that uses them.  It doesn’t help that most of this person’s perceived authority depends on a ludicrously high Quote to Original Thought ratio, so if your sources actually disagree with you, that’s bad news for your authority.

Authorities don’t just comb the Internet looking for things that sound good.  They use source material as support and inspiration for their own thoughts.  They are engaged with the communities that are using this same source material.

You Aren’t Actively Engaged with Colleagues

I’m pretty active in LinkedIn discussions/debates with other agile consultants.  Some doofus once challenged this behavior, saying that clients don’t care about our internicene debates.

That’s true, they don’t, but that’s not why I do it.  I’m not trying to create the illusion of authority for marketing purposes; I’m actually trying to be competent in my field.  Being actively engaged with other authorities in my field keeps the saw sharp, keeps me learning, challenges my current notions, and keeps me abreast of innovations.  Despite the Internet making this easy, true authority does not come from a client-driven marketing façade.  If you know your stuff, clients will stay with you, and knowing your stuff means being engaged with other leaders, malcontents, gadflies, and straight shooters in your own field.

You Mistake Criticism for Contribution

I have a Philosophy degree.  One of the interesting things about the history of ideas is that people are often very correct in their criticisms, but not so great in their recommendations.  Karl Marx points out a lot of valid challenges inherent in how capitalism works out in history.  His alternate recommendations are not so great.  The fact is, it’s a whole lot easier to point out what’s wrong with a proposal than to propose something of your own.  Almost anyone can do the former; only the truly insightful can do the latter.

Any authority needs to engage in the activity of criticism, but if that’s virtually all you do, there’s no difference between you and the guy yelling at the football coach through his TV screen.  If everyone else is so wrong, where are your bright ideas?  What are your alternate recommendations?  What would you do instead?

That’s harder, isn’t it?  And that’s the difference between being an authority in your field and being a poser.  Criticism is not contribution.  Destruction is not creation.

Most of Your Contributions Can Fit in Tweets

Twitter is cool.  Unfortunately, it also automates a lot of unclear thinking.  It’s very easy to use Twitter to simply link to an article without supporting thoughts, criticize without alternatives, or pose koan-like “reflections” that really make no sense.

The problem isn’t Twitter.  The problem is that thinking, articulating thoughts clearly, expressing arguments, engaging viewpoints, and all the things that actual authorities do takes time and space.  If the vast majority of your “insight” has been communicated through Twitter, you might think about how insightful your insight really is.  Your contributions to the history of human thought can fit in 140 odd character increments.

I’m not saying everyone who could rightfully be considered an authority in their field needs to be writing blogs or publishing articles, but whether they express themselves in public writings or in one on one discussions that no one ever finds out about, there needs to be the kinds of substance that can only come from a deep internalization and synthesis of wisdom.

It’s fine not to be an authority in your field.  If everyone were an authority, no one would be an authority.  But if this is your aspiration, or you wonder why people just don’t care very much what you think, just keep in mind that deep, valuable contributions are a lot more work and take a lot more time to acquire than it might seem.

Enhanced by Zemanta