Replacing Problems with Solutions -- More thoughts on Pragmatism

After I published my last article “15 ways to be more pragmatic at work” I started to wonder if I’d overdone it by citing fifteen points about being pragmatic. Maybe I personally wasn’t very pragmatic since it took me fifteen points to make my case!

When I wrote my 15 points, the problem that I was trying to solve for was that for me the idea of pragmatism seemed very complex and I felt that I had to create an equally complex solution (one that required a fifteen-point process) to solve for it. The basic point here is that pragmatism has a lot to do with efficiency and perception.

If the input requirement I'm given is “build a box” and I create something wildly complex like a computer, you may say that I wasn't being very pragmatic. Whereas if I instead drew a box with paper and pencil and you liked it, you may say that I'm rather pragmatic. It all depends on how we define the problem, who's the audience or judge, and what's really at stake.

When it comes to making new things and getting the most out of life, all of us probably want to know what to expect before we take something on so we are prepared to advocate or defend what we’ve done once we get to the end. We don’t want to do anything without a purpose or to have a story to tell! We know that we won’t be able to mitigate all of the risks involved in doing what we want to do decide to choose the most important risks to mitigate and go down the road to fixing them. Along the way we may have to defend our actions and tell others that what we’re doing is the right thing and the step we’re taking is the right one. In others eyes, we want to be seen as capable, confident, and intelligent; independent.

A pragmatic solution to me is one that includes only as much complexity as is required to be deemed by the people who defined and/or are defining the immediate problem at hand as acceptable. To provide for this we have to know what expectations others will have once we’re finished. This is why we have to inquire and wonder and include others on our journey. This is why planning matters and this is why it’s nearly impossible to create solutions in a vacuum.

Let’s set our sights on replacing problems we have with solutions we like.

Top 15 Tips for Becoming a More Pragmatic Worker

I recently completed an engagement leading several software development projects for Microsoft and learned quite a bit from the experience. Times are tough right now in our economy and I want to express to you how I think we all can be more pragmatic in our work styles and rise to the occasion of these tough times.

Answers.com defines pragmatism as, “having or indicating an awareness of things as they really are.” Well, how are things REALLY? I’d say—given our down-economy and business in general—the world is “really”:

• Competitive. There’s a lot of people out there competing for the same resources and business that you are.


• Impatient. Due to the competition customers may have very high expectations for what is possible and what “value” they think you can deliver to them. They want it all now, perfect.


• At Times Cut-Throat. Managers in today’s environment may be threatened by the realities of competition or the complexities of their tasks. This may cause in them agitation and desire to force workers to realize the inherent risks of today’s environment.

If we see and accept the world as competitive as described above, then we next have to figure out how we can best operate in such a context. Below is my list of top recommendations for becoming more pragmatic—and successful—in our work today. I hope you find this list useful to your situation. Please feel free to comment and augment based on your thoughts!

1. Use induction. Induction is defined as “the process of deriving general principles from particular facts or instances.” What this means to me is that we must learn by demonstrating things to our customers, ie “get real data and feedback”. Turn that real data and feedback into something real.


2. Identify and appropriately manage all assumptions. Assumptions will kill you and your organization can’t afford to run on them. Make sure you identify all of them, understand them and determine how to manage them. Some possible strategyies: a) document them and look the other way b) validate them with the customer either by asking a question or demonstrating your interpretation of the assumption in your work or c) (not recommended but sometimes necessary) cover them up.


3. Demonstrate as quickly as possible that you understand customer requests via the end product. Build as many of your unchecked assumptions and thinking into the end product so you can get feedback from the customer as soon as possible. Make sure that you are flexible in listening to the feedback integrate those changes into the next iteration.


4. Have your work process be the way that you continuously demonstrate your understanding of the customer’s requests. Be flexible. It’s okay to be wrong. Listen hard and show them that you understand through demonstration.


5. Your work backlog will grow and you need to manage it. Develop a way that you manage the things that are requested but you’re not currently doing. Expose the work backlog to your customer and work with them to set aside chunks of work that you’ll get to. Prioritize the work between what’s immediate and what’s future. Understand what’s future but don’t spend any time working toward it. Limit feedback until the next demo with the customer if at all possible.


6. Don’t over-engineer. Building too much “value” into the product will kill you. Only put in “hooks” architecturally for future possibilities but never spend too much time engineering toward them until the customer decides they are in scope. When it’s time, you’ll have a platform that makes you ready.


7. Ensure you have the right contract type setup. Using an iterative process like that which I’m suggesting is difficult. Be prepared for the rigor an negotiation required to engage with someone in such a structured and regimented manner. Make sure that the contract terms align with your goals.


8. Be clear with everyone about what the process is and isn’t. Listening, demonstrating, and responding sounds like a simple process to follow but you have to make sure that everyone gets it. Teach and coach everyone on this repetitive process so they understand their role in supporting the next increment and improvement overall.


9. Advocate less and inquire more with the customer. Your goal with the customer is to listen to their needs more and uncover more and more work that they want you to do; open up a realm of business opportunity.


10. Keep some things secret. Don’t share all of your best ideas with the customer. You may want to keep some things secret for when the time is right for a surprise.


11. Advocate more and inquire less with your team. Your team is there to support you. They need to be listened to and understood. So much innovation can come from your team if you can figure out how to integrate it and suggest it to the customer in a fair way.


12. Building products is a partnership and shouldn’t be a dictatorship. Seek to bridge the gap between all parties involved but let the product owner (customer) be the ultimate decider.


13. (Removed as it was a duplicate of a point made above. Was: "Build “hooks for the future” into your current solution")


14. Elaborate on assumptions but only when the customer thinks it’s time. Your job is to build to the “immediate core” of what the customer is stating as their need but also to add “hooks” (not total solutions, rather starting points) for what you think they could mean.


15. Use the Kano Model to think through a balanced approach with your customer. The Kano Model is a handy tool for considering customer satisfaction. Make sure you’re always doing what qualifies in the customer’s eyes but keep them excited and engaged with performance and excitement features at the same time. If you can keep them engaged enough, then not too many features should be “qualifying”.

I hope you found these tips helpful. Please offer your comments.

3 Keys to Making Your Product Development Effort Successful

Through Six Hour Startup--where a new web-based product is developed and launched by a team of 20+ strangers in six hours--I learned what it takes to lead in chaotic situations. At BluWater Consulting I was Scrum Master to three concurrent software development projects and learned that there are a few key principles required to succeed: strength, (team) commitment, systems thinking, and creativity. Based on this I define agility as “a willingness to seek, accept and integrate feedback as frequently and rapidly as possible”.

In my opinion, there are “3 Keys to Making Your Product Development Effort Successful”:

1. Develop relationships with key suppliers. Rely on your suppliers to coach you on the best tools and methods for your organization and situation. Invest the time and resources necessary to procure what’s required to lead the change you seek! At a minimum, put up a whiteboard to track each project and use “stickies” to track the work as it flows through the process. Ensure that there’s shared accountability within the team and the roles of shepherd, pairing partner, and QA are clear. Synchronize your stickie-note process with a powerful information system so you can get real-time statistics, detect, and analyze process variances.


2. Identify and establish the leadership required. The program will only succeed if you have the support and understanding of the right people. This requires persistence and a strong will! Seek to continuously understand who is in charge (the team) and govern as required. Make the roles of Scrum Master, Product Owner, etc. clear but don’t be surprised when they change.


3. Make sure that your team gets it. There are some critical things that your team has to understand before they’ll do well in an agile process. One example is understanding the difference between burning time “up” (tracking actual hours in the case of work that involves uncertainty or risk) and burning time “down” (tracking how much time is left against work that can be reasonably estimated). Make sure that your team has the training it needs to succeed, move forward, and communicate with each other effectively.

If you would like help getting your project or practice off the ground, I'm happy to quickly assess where you're at and help you get get to where you’d like to be!