Software Development = Knowledge Work

February 26, 2010

Since we all use the term “knowledge worker” these days. I thought I would take some time to define just what I believe a knowledge worker is. Before reading on, take a stab at defining a knowledge worker for yourself. I’d be interested in any thoughts that you may have...

Let’s start by defining knowledge itself, which sits on top of a pyramid:

(or the seldom-used plural, datum) is a factual entity that sits at the lowest level, and is obtained through techniques such as measurement or observation. Information and knowledge are derived from data. For example, collecting data about automobile drivers such as their ages, sex, number of accidents provides the inputs that can be examined and turned into useful information.

Information is about examining the data (facts) and attaching meaning to the data. Examining multiple data points may reveal some type of pattern that gives form to the data; in effect, information becomes a representation and communication mechanism of the underlying data.

Continuing with the automobile driver example, analysis of the data reveals that young male drivers have a higher risk of getting into an accident than anyone else. The statistical observation attaches meaning to data obtained about drivers and their accident rates and becomes information – and input – used by insurance companies in determining how much to charge someone for automobile insurance.

Knowledge is the accumulation of information, experience, and reasoning about a particular subject or field. Knowledge coupled with skills and abilities becomes expertise. (Wisdom is a variant of knowledge, where the deepest level of insight is attained, in my opinion.)

There will be differences in expertise between individuals, as some people obtain a greater understanding of their field than others in the same field. Even where expertise is equivalent, there can be differences in opinion because each person has different experiences, preferences, and values. Back to the automobile drivers one more time, knowledge is used to actually determine how much to charge different drivers, as represented by their risk. As you may have noticed, no two insurance companies charge exactly the same rate for automobile insurance.

Now that knowledge is explained, it is an easy step to define a knowledge worker: Someone who engages in the active application of knowledge to achieve a specific purpose, or someone who initiates a new data-information cycle to generate new knowledge – advancing their field. A knowledge worker applies existing knowledge or develops new knowledge.

Knowledge work is not routine. Knowledge work can involve analysis, strategizing, planning, prioritizing, brainstorming, critical thinking, or creating. Knowledge work is about dealing with difficult situations that cannot be directly addressed through pre-defined solutions.

Software development falls into this category. Writing software is not about building the same application over and over again. There is uniqueness involved every time.

Routine work can be handed off (ideally) to a computer. Referring back to the automobile insurance scenario, many times it is a routine decision for an insurance company to insure someone. Standard questions can be placed on a web site, and based on the answers to those questions a decision can be made (paraphrasing William Shakespeare’s Hamlet) “to insure or not to insure…” – along with determining how much it will cost to insure someone – by pre-programmed logic. Exception conditions outside the norm can be forwarded to an underwriter for analysis and a decision.

Challenges with Knowledge Work
Knowledge has value and this value will decrease over time. The world is continually changing, and information is being generated and circulated at a phenomenal rate. Knowledge that is pertinent and relevant today may be of little value five years from now.

In general, keeping relevant (knowledgeable and valuable) over time requires continual learning, reflection, adaption, and application of new knowledge. This places a demand and challenge on knowledge workers to manage their time to provide for learning and growing. “Maintaining” in the knowledge arena is effectively taking steps backward. The world will move past you.

All knowledge is not easily captured. Some things can be captured and written down in a form that is understandable to others. An insurance company deciding what questions to ask and what calculations will be performed to determine a premium is an example. This is “routine knowledge” (once it is created) that can be captured and used repeatedly by less knowledgeable people.

Some knowledge – tacit knowledge – is more of a challenge. You can capture instructions about how to ride a bike, but reading about riding a bike will not enable you to immediately ride a bike the first time that you try. Book-learning can be like that as well. You might understand the concepts, but the author has different experiences and values than you do. The truth is that you might need to get some personal experience under your belt to truly understand and value some of the concepts that an author conveyed.

This is also why “knowledge transfers” in organizations can be challenging. If you expect that a one or two-day “knowledge transfer” will fully prepare someone to fill another’s shoes in exactly the same way, you will be dissapointed. In fact (and since this is a blog about managing software development), software development is effectively a knowledge transfer exercise.

The goal is to translate business knowledge into software. This requires a collaborative effort to represent the business in a very precise, step-by-step processing of instructions to conduct business transactions on a computer. This collaborative effort alone is a challenge, as those on the business side do not understand computers as deeply as those who write the software, and those who write the software do not understand the business as deeply as those involved with the business.

And there is another problem that lurks with software: The knowledge – expertise, values, and experience – of the few business representatives involved with software projects often speaks for the many. The big question is: What are the odds that the judgment of those few will be correct?

This is why building software in small increments is valuable. It allows the software to be viewed by many early and often. Soliciting of feedback allows course-corrections; better to set a course and make small adjustments along the way than to sail directly into rocky waters – where you will sink – because you wanted to maintain your original course come hell or high water.

If you're looking for another (humorous) perspective, blogger Steve Schwartz has a great post about The 3 Types of Knowledge.

Book Review: Behind the Cloud

February 19, 2010

Behind the Cloud: The Untold Story of How Went from Idea to Billion-Dollar Company-and Revolutionized an Industry
Behind the Cloud: The Untold Story of How Went from Idea to Billion-Dollar Company-and Revolutionized an Industry by Marc Benioff and Carlye Adler

Since I work for a software company, I was very interested in the story of and how they built their application and company. As the book points out, sought to build an industry – what is now SaaS (Software as a Service) – something that they certainly took the lead on over the past decade with great success. has a mini-industry built around its product and platform.

The book is an excellent blend of advice that is provided as plays (think sports playbook) with the story of woven in. The writing is excellent, and you can really feel Marc’s enthusiasm and pride at how he steered the company from its inception to its present-day success.

The journey can be gleaned as you read through the various playbooks that comprise the book:

The Start-up Playbook
The Marketing Playbook
The Events Playbook
The Sales Playbook
The Technology Playbook
The Corporate Philanthropy Playbook
The Global Playbook
The Finance Playbook

Marc comes across as daring and unconventional, particularly in his marketing approach – such as staging a “protest” at a competitor event. Marc is very willing to go after the market leader, stating in Play #22: “Engage the market leader. By their defending themselves against you, they acknowledge you and begin to chip away at their own airtime.”

Marc had a vision and courage from the outset, and that was to build a hosted model that did not require customers to install and configure expensive software, which was not something everyone bought into. As he noted in Play #52, venture capitalists argued for him to build a hosted model to lure small businesses AND an in-house package that would be similar to other companies in the CRM space.

Marc and said “No.” They felt that their SaaS model would never work if they hedged their bets. Marc also explicitly stated this in one of his plays – Play #13: “Be willing to take a risk – No hedging.”

I completely agree with this, and I’m sure others will as well, including Andy Grove of Intel. As I noted in my post Are you Committing Your Business Tanks?, Andy Grove has stated: “Hedging is expensive and dilutes commitment.” And without commitment, Andy says, “You will always be looking for a way out rather than a way to win.”

Marc, in Play #20 continued his daring advice, stating: “Always, always go after Goliath” – positioning yourself in the role of underdog and visionary. This is dangerous advice without considering the greater context of the story.

It is NOT a great idea to take on an established competitor head-to-head; if created yet-another CRM in-house enterprise product like the venture capitalists suggested, they would have been hammered by the competition. It would be been extraordinarily difficult to differentiate against other established competitors.

Fortunately, Marc is big on differentiation, and he did what The Innovator's Solution: Creating and Sustaining Successful Growth by Clayton M. Christensen, Michael E. Raynor suggest: disrupted the incumbent players and went where they did not want to – or could not easily – go. created a fully hosted application using a subscription model that was fundamentally different than the competition's locally installed, in-house software that was purchased in full up front.

The market leaders didn’t initially believe in this model and did not want to participate in that fashion. It was only after had begun to establish itself that the competition reacted, and they responded by making strides to deliver their software in the same way.

The book tended to reinforce other concepts that successful companies espouse: hire and retain great people, treat your customers well and learn from them, and adapt your company as you go. Overall, the book offers a great deal of insight about business success in general, and Marc’s flair and enthusiasm make the book both informative and entertaining.

I highly recommend the book, but don’t be fooled by the title; you won’t learn anything about cloud computing, but you will learn about and understand how the cloud was formed and grown.

The 21st Century Manager

February 12, 2010

There are some distinct changes managers need to make if they plan to be successful in the 21st century. To put it simply and directly: Techniques that worked well in the 20th century will not continue to work well in the 21st century.

The roots of 20th century management lie in manufacturing where the work was more manual and the output well-defined. In today’s business world, we’re dealing with much more difficult problems where a problem statement exists and someone must come up with a solution. The output is not well-defined at the outset, it is shaped as a function of the work. In addition, knowledge workers typically have a greater understanding of their work than their manager does.

This places very different demands and expectations on a manager. Some people even feel that this makes managers are obsolete, but I beg to differ. Good managers have the knowledge, abilities, and experiences that can help individuals and teams achieve the high-performance state that we all want them to reach. The focus of management needs to change to meet today’s needs.

“Getting things done through others” needs to change to “developing people and teams.”

“Getting things done through others” is a traditional definition of management, and one that I’ve used myself. However, it implies a command-and-control scenario whereby a manager assigns tasks directly, and where the manager is ultimately responsible for the achievements (or lack thereof) of the team. Empowered, self-directed teams do not need a manager explicitly assigning tasks; the team can collaborate to accomplish the work, and they can be responsible for the results.

The raises the ante on team members as the teams take on what has been the traditional purview of management, such as planning, problem solving, and decision-making. There is also a need for improving communication skills – something else that good managers are very skilled at. A 21st century manager should assess and coach teams (and individuals) in these areas so that the teams are executing well to maximize effectiveness.

The 21st century manager should also help identify training and career opportunities for individuals on teams. Facilitating the learning and growing of employees is an essential role; keeping an employee challenged and growing in his or her career will provide a great deal of satisfaction, engagement, and loyalty – essential to retention.

“People under your thumb” needs to change to “finger on the pulse.”

Since individuals and teams will no longer be doing a manager’s bidding, a manager’s role will shift to that of someone who is in touch with what is going on, allowing autonomy and being supportive through working with individuals and teams to understand what is working well and what the impediments are.

Skilled managers understand the strengths, weaknesses, and preferences of those who report to them, and can even assess the dynamics and flow of a team – good or bad – to judge whether changes are necessary, and what changes need to be made. A good 21st century manager should be able to intervene (when required) and remove a poorly performing team member or assist in activities like lining up a specialist that can help the team overcome a specific problem that is outside of the expertise of anyone on the team.

Ensuring compliance needs to change to  facilitating engagement.

Traditional management has been about being specific about the work, and setting down rules and procedures to ensure that the work happened as planned, using the typical “carrot and stick” approach to reward favorable results and punish poor results.

Empowered individuals and teams need information and understanding to work with – such as the business context about why something is important to do in the first place. A manager will not issue orders as much as he or she will answer questions or provide guidance. It is a more collaborative approach where a manager provides a vision, clarity of purpose and direction. A 21st century manager shares his or her expertise and knowledge with the team to help the team improve as well as helping the team to overcome obstacles.

Achieving Higher Productivity, Stimulating Innovation, and Maintaining Morale

February 5, 2010

“Do more with less.”

“We need to spur top-line growth through innovation.”

“Retention of employees is essential, so let’s keep morale up.”

Managing creative knowledge workers in a tight economy where every company is fighting to increase profits means that you must execute well in all areas. The 21st century software business doesn’t compare to a 20th century manufacturing plant, where devising a new manufacturing process to produce well-defined widgets faster and cheaper than ever before was a solution. Manufacturing and management in those days was about compliance, following the prescribed means of efficiently producing widgets. Knowledge work is less definitive than that.

How do you go about creating a motivated, productive, innovative work environment?

We’ve adopted Agile/Scrum development, and this approach meets these seemingly contradictory challenges perfectly.

Productivity through Focus and Teamwork
Agile/Scrum increases productivity by focusing sharply on the business priorities. The Product Owner – someone who represents the business – sets the priorities and refines the product backlog (into User Stories) so that the features are discrete, well-defined items that can be delivered in short increments of time called “sprints” or “iterations” (a two-four week time frame).

The team collaborates on the planning and delivery of each User Story, operating as a team and not just a collection of individuals. Collaboration is more than communication and cooperation; collaboration includes shared goals, shared knowledge, and shared learning. A high-performing Agile/Scrum team should be greater than the sum of its parts, beating the output of typical project teams that are little more than individuals working on assigned tasks and sharing a common project plan.

Innovation through Collaboration, Exploring
Business-oriented software projects require a meeting of the minds between multi-disciplinary knowledge workers to be successful: those who understand the business and know what they want to get out of the software, and those who understand computers and have the skills to tell the computer how to execute those tasks. Opportunities for innovation occur when teams explore why someone wants to achieve something, and not just settling for giving the customer (or Product Owner) what they asked for.

For example, one time a Product Owner discussed a business problem with one of our teams – sharing the business objective along with what the Product Owner thought was a proper approach – and after a short discussion, it became apparent that a different solution was not only achievable, but highly desirable. The team was able to recommend a design that was simpler and faster to deliver and automated key aspects of the business process. This resulted in making the customer much more productive, a win-win scenario.

Innovation can be fostered in other ways using Agile methods, such using time-boxed sprints to brainstorm or explore how technology can be creatively applied towards some high-level problem.

Motivation through Empowerment, Autonomy, Purpose
Agile/Scrum makes use of small, cross-functional teams to design, build, test, and deliver software. The teams are responsible for working with the Product Owner during planning, discussing and negotiating the features to be included in a sprint. The combination of a properly-framed User Story and subsequent discussion with the Product Owner about the User Story provides the team with a solid understanding of why – the purpose – a User Story is important to the business.

Once the team understands the objectives, the team takes ownership and determines the tasks and estimates that go into those features. Once the definition of the work is clear to the team, the team commits to completing the work based on the resources available and past experience (team velocity). Management doesn’t dictate terms and conditions, the team organizes itself.

As the team works on each User Story, continual dialog and adaptation will occur, true to the nature of software development. While it is important to have as much prepared in advance as possible – User Stories are the requirements, and due diligence in being as crisp and clear with the User Stories is vital – there will still be those inevitable questions about specifics as developers translate the business into working software. The team works with the Product Owner to resolve these questions, all without management guidance or involvement.

Autonomy and empowerment are powerful motivators to the members of an Agile/Scrum team.

In Conclusion...
Agile/Scrum can provide a great work environment for software teams as well as solving the key issues of improving productivity, stimulating innovation, and improving morale. The main reason that it works so well is that it is a perfect fit to the realities of software development, such as the fact that everything cannot be fully defined before the actual work begins. Since software development is an exploratory process of taking business needs and representing those needs in working software, a continual dialog is required throughout a project.

The correct implementation of Agile/Scrum can be more of a challenge than you might realize at first. The framework is deceptively simple, but this makes it easy to fall back to old habits. You may find that there are people in your organization who are not suited to working on empowered teams, and in other cases, management may be resistant to giving up control.