Category Archives: The Top 5 Rookie Mistakes In Software

The Top 5 Rookie Mistakes in Software – #2 Sustaining Innovation

 

espionagespies

 

Politics,

Espionage and Sabotage

A toxic environment can kill innovation

Your innovators are your lifeline to success. Without a critical mass of imaginative people who are willing to take chances and throw their neck on the line for a fresh idea, you’ll be doomed to mediocrity. The unfortunate organizational culture that emerges in most corporations, however, is one that plays a harsh game of whack-a-mole with the few willing to stick their heads up to pursue new sustaining innovations. Why is this?

Here’s an interesting and hilarious Ted Talk video by Ken Robinson about killing creativity. Robinson does an excellent job of highlighting the backwards approach we have towards people for taking chances; for willing to be wrong. “If you’re not prepared to be wrong,” he says, “you’ll never come up with anything original.” But being wrong in the corporate environment – as it is in politics – exposes people in a negative light. It invites criticism and is met with disappointment. It’s remarkably easy to spin it as unsuccessful, you’ve failed.

In the world of software, having an edge in innovative products and innovative design is particularly important. The blinding speed that new technology hits the market puts heavy demands on differentiating yourself from the competition. Google, Apple and Research in Motion all know this (Here are the Top 50 most innovative companies according to Business Week). Check out this statement, which is part of Google’s employee agreement, “Thinking beyond the norm is expected, no matter what position you happen to hold…Innovation is our bloodline.” Even players like Google, however, will struggle with maintaining an innovative edge. It appears to be an unfortunate but consistent pattern as organizations become successful and continue to grow.  This pattern shows as an Innovation Curve where, during the new or start-up phase of a company (or departments within a company), there is a keen, passionate environment that allows and encourages innovation to thrive. As the company becomes successful, however, the innovation dies off; the innovators are pushed out and the organization becomes stale. According to a recent Research-Technology article on Sustaining Innovation, “As firms grow, they tend to exhibit common behaviors that prevent them from being adaptive to new environments, thereby limiting their ability to sustain their innovation drive”.

The innovation curve is a bit like this: innovation curve

Over time, rigid processes, resistance to change and complex power structures cause innovation to just drop off.

This curve is particularly noticeable when you work in the technology business – which is a domain that tends to attract innovative types. It’s a unique discipline where the scientist, inventor and artist – when all blended nicely into the same human package – can actually succeed in the corporate world. Success over the long term, however, means a tendency to regularly switch jobs as a result of this curve. They either get pushed out or slip away on account of boredom or frustration.  The long and short of it is: To drive out your best people, just let it get political.

Spot an Innovator

What do they look like? They’re often the ones who are quietly offering clever, game-changing solutions that come out of nowhere but blind you with simplicity and clarity. Not always the Howard Roark Geniusstereotype, of course, The Innovator can be bold and outspoken, and absolutely resolute in a vision.  They can be annoying and persistent and uncompromising and … shockingly unaware of the optics of a situation. Whatever the look they assume, one thing is certain: the innovator is a threat to The Ambitious and to The Contented.

Bluffing Your Way Into Management

The hierarchy of the typical corporation is a breeding ground for The Ambitious. The existence of an org-chart alone makes for a convenient physical reminder to many motivated individuals about goals. It is often the thing that drives them most. Having ambition, by the way, doesn’t necessarily make you one of The Ambitious, by my little definition. Those I’m calling The Ambitious are the ones who are born gifted with a political savvy about working the system. Rather than pursuing success through doing good work and bringing value, these are the calculated planners that pursue success through whatever means possible.

This includes the removal of barriers like innovative people. And the innovators are typically a very easy target because they’re so bluntly unaware of politics. Being keenly aware of the power of perception and making strategic alignments, a character assassination is a pretty routine task for The Ambitious. In the Sustaining Innovation article mentioned above, not much is made of this darker side of organizational culture – but the truth is, we all see it. It’s the active and transparent sabotage of individuals or teams to eliminate a threat.  Robert Sutton gets it. His blunt and charasmatic message bypasses all the niceties and tells it like it is. To learn more about Sutton’s offering, have a look at this rather good commentary on the civilized workplace and how not to be that guy. For an additional inspired read, check out Snakes In Suites by Babiak and Hare. 

 

Change Bad, Risk Bad

Process is an excellent strategy for removing innovators.  Lots of Process. As an organization experiences success The Contented will introduce greater Process and Meetings, and questions, and presentations to defend positions, and extensive documentation, and costShoot Foot justifications and detailed planning. Not to mention Committees and Steering Teams and Global Synergy Initiatives. This is all great stuff for driving the innovator absolutely nuts. A general resistance to change and risk, where everything is comfortable and familiar is also an ideal state to achieve where innovators will simply disappear. In other words, when the environment gets too bogged down with manoeverings, detractors and pointless meetings, the innovator will just get bored and leave. Of course, effective processes and process management are important, critical even; however they should match the environment and bring value.

Again, from Sustaining Innovation, “First, as firms mature they tend to become too comfortable doing what they normally do; this comfort leads to myopia and also discourages risk-taking outside their comfort zone. Second, core values and the structures in place become rigid over time, thereby encouraging only a narrow focus on operations and mission. This results in incremental innovations compatible with existing structures. Third, firms lose the drive that got them where they are; that is, they lose the creative energies, the openness to risk-taking and experiments that allowed them to carve a niche and disrupt the incumbents when they first entered the market.”

As Usual, It Comes Down to Leadership

When the Big Three auto CEOs flew private jets to ask for taxpayer money, in November, 2008; I remember thinking to myself, These guys are really out of touch. As shocking as it was, it’s representative of how common it is for leaders in established organizations to get thoroughly disconnected from what’s going on down on Earth.  Strong and engaged leadership and leadership strategies are critical to enable a competitive level of innovation. Deliberate actions and reinforced values have to exist to eliminate the exploits of The Ambitious and the conflicts waged by The Contented.

Leaders and managers at all levels of an organization must be tought to underline the importance of remaining an innovator.  Innovate or Die. Isn’t that the expression? Management is the most succeptable to becoming lazy and Contented and guilty of no strategies around sustaining their innovation edge. The stagnation of innovation is a symptom that has roots at all levels, especially right at the top.

 

Chris Ronak

Advertisements

The Top 5 Rookie Mistakes in Software – #3 Techno Hype

technology.jpg

The Technology Dream

It’s just a tool, not a Strategy

It’s amazing how often technology gets confused and spun as a marketable feature. It’s not uncommon for companies and governments, for instance, to state that they will “Leverage Technology” as a business strategy. In the same breath, they’re also going to reduce unemployment, clean up the environment and fix the economy. Sure they will.

There’s an exciting appeal to ‘technology’.  There’s still a mystery and newness to even the word that elicits a dreamy promise of endless possibility.  It’s impressive apps like Google Earth, Halo 3 or the iPhone that people likely think of when talking about technology; apps that look good, sell well, and entice people to get lost and obsessed in them.

Sexy apps, however, are built by clever people with a focused vision around capability, content and a dreamy interface. The fact that they leverage technology is almost incidental. It’s easy to get caught up in the excitment of the dream and forget that business is still business regardless of the tool you use.  The truth is, it’s not uncommon for both business people and technical people to miss the point that technology is only a tool. Without a purpose, that tool is just a means to an undefined end.

Without establishing a direction and purpose for a software product that is focused on boring old things like: User, Market and your Business; your technology dream will simply deflate into another expensive mistake rather than a hot app.

The Framework Dilemma

As technology professionals, we get caught up in the dream too.  I’ve been guilty many times of approaching business problems with a technical solution without stepping back and wondering if it’s truly the right thing to do. It’s easy to get wrapped-up in the world you know and use that as the solution to all problems. “Have you considered building an Application Integration Framework?” – Those were my words. It seemed like a reasonable thing to suggest. This guy’s media company had multiple products that couldn’t talk to each other and ‘Integration’ was high on his agenda.

“NO! NO FRAMEWORKS!” – Was his response.  He even stood up out of his chair and leaned forward towards me pretty aggressively when he said it.

Wo, that guy was jaded. But I understand why now.  He quickly calmed himself and explained to me that a consulting company had sold him the same line a couple years ago. They spent those 2 years in, what I call, “a Dark Place”, just building a Framework. They didn’t consult with them about what the products do, or what the user needs, or business drivers, or the data or how this could tie into their overall technical strategy – nothing like that. They just built a framework.  It took 2 years of nothing tangible, but these consultants were finally kicked off the property. All there was to show for the $1.2 million spent was a bunch of code that had no business value.  I’m sure it was a brilliantly designed framework, but it didn’t do anything. I’m also sure there are thousands of skillfully composed frameworks out there sitting lonely on subversion servers around the world. I’ve personally participated in a framework or two that went nowhere. It’s a common thing for developers to want to do.

targeted.jpg

I don’t want to dismiss the importance of a proper architecture and framework; all software applications need a solid foundation. But they have to be built to fit the business need, and with a specific user-driven purpose.  Frameworks should be small, lightweight and grow with the product. Key to making sure that happens is: every aspect of a framework has to have a consumer. If someone on your team is building a component or framework or utility in anticipation of the potential of it being useful, that effort should be denied.

Technology For Technology Sake

My old boss used to have this tendency to wander into my office and recount stories about his past. He didn’t have all that much material, so his stories got repeated a fair bit – I didn’t have the heart to tell him that of course.  Anyway, one of his more riveting stories I got to know well, was about the specifics of a product idea of his that failed. It was essentially like this: a data service architecture that could connect to multiple databases; a domain layer that sat on top of that which reconciled data from these different locations; on top of that was a communication layer based on web services and finally there was a forms builder to create custom interfaces as the top layer of the product.  He thought it was such a great idea and would shake his head in bewilderment as to why it never went anywhere. “Well, what did it do?” I asked him one brave day. “It could connect to multiple databases.” Was his answer.

“To do what though?” I asked.

“Well, to do anything.” He said.

“Anything that needs multiple databases…” I said, to be agreeable; but really I just wanted to get out of the conversation.

So, who’s going to buy that? It’s a thing that doesn’t have any real purpose, except to say it serves a purpose behind an unknown purpose. A body without a head. I didn’t have the heart to tell him, of course, because he thought it was so awesome … and it was kind of his baby. But like a lot of people, he chose to build technology for technology sake, and didn’t appear to understand that that isn’t a product or strategy, it’s only a tool.

Chris Ronak

The Top 5 Rookie Mistakes in Software – #4 The Team

How do I know if my Development Team is any good?


Good Question.
Actually, it’s a critical thing: the importance of The Team can’t be understated. It’s one of the single biggest factors influencing the success of your software.
Those who aren’t seasoned with a) how to hire a good development team and b) know what to expect from them, will likely be faced with a frustrating time. Without more to go on, they’ll use something like the following as their criteria:
  1. They don’t dress very well
  2. They play Team Fortress II at lunch
  3. They talk techie all the time
  4. They cling to each other at the Christmas party
  5. They babble like idiots when a girl walks into the room
If all these are true, they MUST know what they’re doing.

Leaving it to chance is a pretty common mistake.
I had a funny-but-tragic experience working with a guy who’d been given the responsibility to integrate a recent acquisition his company had made (he was the VP of something). He was a super-smart guy, but not that experienced in the world of software. He figured out pretty quickly that to accomplish the IT side of this integration, all he needed to have built was a Map.  A web-based map that a user could log into and find out key land ownership information by zooming around and clicking on land parcels.  Really, that easy.  But he needed it quickly – this was key.  So, rather than taking his requirement to the IT (dev) department, who were notorious for having all kinds of barriers and rules and taking forever to turn something around, he instead gobbled up a couple developers who happened to be kicking around after some acquisition or other. Two guys who fit his profile: they were programmers and at that moment had a fairly aimless list of things to do.
They’ll do, he thought.  A developer’s a developer, right?

time

So he gave them his map vision, and to his amazement, they had something up and running within days.  Days! This was gold!  He couldn’t wait to give his status update to senior management.
Flip to the developer’s perspective now: they wanted to secure their jobs.  So to get some quick sizzle to the VP, all they did was download an evaluation copy of ArcGIS Server and ran a tutorial with some sample data and sample shapefiles.  They loaded the server part, clicked next->next->next on all the various wizards; and splammo, things were pretty much up and running.  They couldn’t wait to show him their status update: they’d basically got the nuts & bolts of his Map working.  He, of course, was over the moon.

I’m going to skip a few details and flash forward a bit…
A year later, my VP friend still didn’t have his map. A simple map to enable users to click on a land parcel and get a quick report.  What!? Why would that be so hard?   I had lunch with him around that point and, the poor guy, he couldn’t contain his frustration, “All I want is a MAP!” he echoed over and over while pumping the air with his fists.
Those two developers? They were re-distributed into the marketplace, and a few new ones had been brought on to take their place. There’s now a full team working this project.

So what happened there?

Self-Organization and The Product Team

Well, lots of things happened. I could tear into this problem – unfortunately, a pretty common problem – from a variety of angles, but I’ll summarize it this way: the developers didn’t organize themselves into a product team.  They didn’t take technical ownership of the situation and instead reverted into being day-to-day programmers, just coding whatever the VP asked for.  And ya, HE was totally at fault too for completely misunderstanding the magnitude of the effort required, and for dismissing the need for proper development splat 2infrastructure. However, in this world we live in, there is an obligation for the technology professionals to self-organize and assume a higher level of responsibility. In their case, they completely failed to effectively communicate, and act on, of the true scope of his simple Map.  They just performed tasks and went home at 5:00.  No Team. No Product.

This type of thing happens all the time.  All. The. Time.  Complete disconnect in communication and understanding between technical and non-technical people:
  • Person needing dev help clutches onto a programmer and asks for stuff
  • Programmer goes “Sure”
  • Person is pacified
  • Programmer is thinking, “Task”, but Person is thinking, “Commercial Product”
  • Ok, person is really thinking more like, “Product that makes serious money or makes me a star.”  Programmer is thinking, “Maybe I can finally use some Windows Workflow for this.”
  • Disaster. Everyone is sacked
The best designs and successful software products emerge from high-functioning teams.  The developers themselves don’t necessarily have to be superstars, of course.  As in most anything, even a group of strong players can fail badly if they don’t work as a team.  Similarly, a team of average programmers who communicate well and build trust & respect and a team atmosphere, are more likely to succeed than a group of aces who fail to interact as a team.

The point I’m trying to make is; to determine if your dev team is any good, I’d worry less about whether the individuals are champion programmers, but more about how they organize as a team.  This goes for small teams, large teams, small companies and big companies.  It’s really all about the team and the fact that they recognize that they’re not simply completing tasks, but building a commercial software product that has a customer at the other end of it. There’s no question you do have to have good people who know what they’re doing and know how to get software to market, but it’s the team that builds great software.  To that point, the aim in this article is to present some ideas on how to evaluate a software product dev team.  So, the discipline of ‘Hiring Good People’ is not really the topic being addressed – that is an art and a science, and a different conversation.

What to Expect From The Team

Still not sure how to tell if your dev shop is any good?  Below is a handy list of 6 quick tips to help you figure that out.

As an outsider looking in, you might struggle to know what they’re supposed to be doing on a day-to-day, week-by-week basis.  Don’t just cross your fingers and hope for the best – you’re better off knowing what should be happening.Emergence

I’d encourage you to have a look at an earlier posting on Software Failure that contains key recommendations for processes your team should be engaged in.  The following points – which are aimed more at someone overseeing a dev group – will provide a quick indication of whether or not a development team is working effectively.

  1. The software should always be working as an integrated product. You should be able to see continuous measureable progress in the product. It should move forward every day and every week.  You shouldn’t have to go to a developer’s machine to look at software in progress.  In other words, they should be ‘releasing’ it on a daily or weekly basis.
  2. The team should be transparent amongst themselves and to all outside stakeholders. No secrets, no dark places.
  3. The team should be measuring their own progress.  They should metric themselves by estimating on sprint tasks then, after the sprint is complete, reflecting on what was accomplished. Each team member should present/describe what they’re going to do, and then explain what they’ve done
  4. They should be continuously forthcoming about risks, scope, timing and any issues that affect the product or release
  5. They should be taking advantage of productivity tools and methodologies to ensure a rapid turnaround
  6. They should have an obvious desire to innovate

Let me know if you have any questions about any of these.

This isn’t a one-sided relationship – Obviously the team has many expectations from outside stakeholders as well. That is coming in another posting on rookie mistakes.  Stay Tuned!

Chris Ronak

The Top 5 Rookie Mistakes in Software – #5

Lack of Focus

(read the intro first if you haven’t already)

Call it hubris, call it ego.  Call it a lack of understanding of the market and user, but a huge rookie mistake is to try to do too much.  How many times have you heard this bit of common-sense wisdom, “It doesn’t have to do a lot, just build it to do a few key things and do those things well.”?  It makes sense right?

It’s unfortunately easy to lose sight of this little rule-of-thumb when the momentum of product roadmap overtakes you.  You browse around a competitor’s website, for example, and discover that they’ve just released a new version that has a new feature X; but you have no plans to build feature X in your tool.  Well, now you need to add feature X to your scope to remain competitive.  Or, maybe your legacy product has feature Y and your existing customers have learned to depend on feature Y to do their business.  How can you ship your new product without feature Y? Add that to the scope.

Add a hundred more components and modules and exports and reports that keep getting added and added through demands from a few sales & marketing people, some customers, your favorite SME’s and a BA.  Your simple, focused product has now ballooned into a Colossus that will take 800 man-years to release.

So, am I talking about Scope Creep?

Not at all.  Scope Creep is one of those old, pre-Agile sayings that poorly organized dev shops used as an excuse not to ship software.

Scope will always change and creep.  It’s normal, healthy and all a part of building an effective product roadmap.  To maximize the competitive opportunity of your software, you need to be open to new market information, business drivers and innovative ideas.  These will always change and add to your product backlog (total scope).  Change, scope creep, uncertainty, etc. is all GOOD, wholesome stuff in the world of software and technology. Our learning path evolves every minute of the day.  Think of it this way: if you don’t know more in 6 months than you do right now, you’re not really doing your job.

I’m talking more about confidence.  Cojones.  The guts to ship early to a market you understand.

The true challenge is having the nerve to ship your software before the entire scope is complete.  As a rookie leader, you likely won’t understand that your software team can ship a quality product with the minimum possible feature set that will bring business value – even modest business value – even if it’s only to a percentage of the total market opportunity you’re shooting for.  You probably won’t think it can be accomplished as a continuous incremental improvement of features over a time period of x-months or years.  You’ll be more inclined to want everything – you’ll want the whole scope, first time, and ship that with a huge boom – you must, as a rookie, obliterate the competition with one crushing blow.  Or, maybe yours isn’t an ego issue. Maybe you’ll want everything because you’re not confident enough in your understanding of the market and users; so best hit them with everything and maybe something will stick.

Either way, Big Rookie Mistake.

Wanting everything is obviously the wrong way to think about it both from a technical and business point of view.  The fact is, it actually takes a great deal more courage to be laser-focused and put your product out to market with a simple, lightweight vision to accomplish a few targeted things to a clear and strategic market.  There is much more of a calculated mastery in that.

And, sure, you will continue to have a product backlog of great, innovative ideas to add to the product over time.  Believe me, there’s time for that.  What the more experienced Business Leader will know is that: getting your more precicely-focused product to market accomplishes four important things:

  1. You now have commercial adoption of your product. (Reduced risk)
  2. You’ve minimized the investment needed to generate revenues. Your product is now out there making money, and you’ve spent a fraction of what your total scope will cost. (Increased ROI)
  3. You are now receiving valuable customer feedback on your product, which will help you further prioritize the next features to add. (Strategic market information)
  4. You and your team have proven that you can build and ship successful software. (Time to celebrate

Prioritize

Ok, so now if you don’t want to fall into this trap, what do you do?  The key is to prioritize the backlog.  You have 100 innovative, killer features you want to put into the product, but you only have room for 10 this realease.  Someone has to take ownership of which 10, and in what priority.  Then prioritize the next 10, and so on.  Maybe the remaining 90 will change after you’ve shipped the first 10. That’s a good thing.  KeepThis is the Key prioritizing the next 10 (or however many you choose). Have a look at this article by Dennis Stevens on Capability Analysis for some good insight on prioritizing features.

Who owns that?  Typically your Product Manager or Product Owner. Maybe you do.  Whoever it is, remember, one of the most important things for a software development team to be armed with is: What To Do Next.  Mike Cohn has some sound ideas on the Product Owner, backlog and other gems to help gain more context with this.

Stay tuned for Rookie Mistake #4.

Chris Ronak

The Top 5 Rookie Mistakes In Software – Intro

Introduction

It’s pretty easy to throw some software together.  Almost anyone can do it.  Simple tools, Drag&Drop screen designers, sample databases, etc. make creating a software app just a few mouse clicks away.

I used to work with a sales guy whose family owned a sheep farm that he helped out with on occasion.  After getting a bit frustrated with how disorganized his family was about managing their sheep, he decided to do something about it.  So after reading a couple blogs, he bought a “For Dummies” book and taught himself VB.  He hooked it up to an Access database and in a few weekends he had built a sheep-tracking system.  Bam, just like that.  Easy.  Even a sales guy with a mere hint of technical aptitude can write software.

As it turns out, lots of non–technical people dive into the software game.   After all, how hard could it be?Small team of developers If you can’t do it yourself, you just hire some developers, tell them what to do, and they make it work.  Easy.

It’s interesting in a way, that there are so few barriers inhibiting inexperienced people from launching a software initiative.   In their mind, it’s just a few screens, buttons & graphics – it just doesn’t look that complicated.  Even if it’s a highly-integrated enterprise system that is connecting multiple disparate systems, performing complex business queries & algorithms and accessed by thousands of concurrent users – it’s still, at the end of the day, just a few screens & buttons.  Because that’s all they see.

The odd thing is, those same individuals wouldn’t dare dive into leading-up the design & construction of a 90-storey high-rise building without experience.   It’s clear why: a high-rise is more visual, physical and the obvious immensity of it is intimidating. They know you can’t just go hire a bunch of cement workers, plumbers & electricians to “Go build me a High-Rise!”  But somehow this happens all the time in software.   Curious, isn’t it?

So, to start a discussion around this pervasive problem, I thought I’d put together my Top 5 Rookie Mistakes that both inexperienced and experienced people make in software.  There are a lot more than 5, but I thought I’d try to stop there.

I have to caveat the perspective a bit.  There are many rookie mistakes made in an organization that don’t have a direct relation to the software/technology areas (marketing, sales, business development, finance, operations, etc.).  I’ll leave discussions around those to the experts.  I also refer a lot to product and market.  Regardless whether the software is to be delivered as an internal or commercial product, these rules are the same.

Learning to DanceAlso, there’s nothing wrong with being a rookie or the new guy.  The rookie is usually the person with the most energy and enthusiasm for an initiative; and is driven by a vision.  He/she isn’t jaded by mistakes & failure and can often become the true source of life for a project.  The intent here is to help to avoid common mistakes and pitfalls of that role; not to criticize the rookie.

So, here goes.  The Top 5 Rookie Mistakes in Software.  I’ll stagger them out over the next few days. This is, after all, an agile effort.

Chris Ronak