Social networking as a tool for consulting: making client and colleague relationships personal

By now it’s undeniable that the scale of usage of social networking, as this info graphic on Facebook presents, is impossible to ignore for web savvy businesses. My employer, Catapult Systems, asked employees to consider enhancing their personal brand by signing up for a Twitter, Facebook, and Linked In account if they didn’t already have one, and also offers a set of aggregated blogs on blogs.catapultsystems.com that are straightforward to link to your own personal blog.

When this request was first made, the blogging aspect seemed natural to me. The benefit of bringing more traffic to my blog from technical folks I do business with through my day job and the returning visits to Catapults’ makes a lot of sense from a marketing standpoint. However with so many companies banning Twitter and Facebook due to the frequent flow of information coming in, our CEO still surprised me with his willingness to take a chance on the risk that employees could abuse this power. Though Catapult has some of the most personable, professional people I’ve ever worked with there, it still seemed like an exciting experiment at first.

What I’ve found however, is that for a consultant so much of being effective means understanding the clients you do business with as people, and their personal needs on a day to day basis. When most people think of Facebook friends, they think of distant relatives, old friends from school, and past loves. To share a thought on life, pictures of something you did in your spare time, or a recent challenge once privy only to your closest and most immediate friends can now be communicated en masse to the whole of your global circle. At first this can seem trite – why would these people care? And going further, why would the folks I work with, or the clients that pay me to solve their problems even want to know?

The reality is that between setting vision, gathering requirements, designing and steering, development activities, and (hopefully) happy hour celebrations on a successful project there is much more dialogue related to life outside of work than we care to acknowledge in this trying economic time. And people bring with them experiences and connections to other industries and aspects of life that can be helpful to each other in ways that enhance their personal lives, and as a result, their working relationships. Healthier working relationships lead to improved efficiency and general wellbeing within a project or organization.

Since following more of my coworkers (and a few clients) on these networks, I’ve had some find that I’m a recreational cyclist, musician, and father. This has led to sparking conversations about riding to work, the music we listen to while writing software, and strategies for having a solid work/life balance when children are involved. These conversations, and the resulting changes in life that follow, have a healthy, positive effect on how we feel when we arrive on the job each day, and the ability to understand what drives each other. Many companies when interviewing technical candidates ask “what are you passionate about?” and get responses about technology X or some industry expert’s blog. But when we are honest with each other as human beings – a job is still just one vehicle to use in our journey towards wherever we’re going with life. What drives us is often much more, and sharing that with others improves trust and encourages breaking down barriers to communication.

There is still the issue of managing the time spent on social networks, and for me the solution came in the form of an excellent chat client with some advanced social networking features. I was first introduced to digsby by a colleague of mine, Josh Handel, early in 2009.  Digsby lets you use a variety of chat networks much like other available programs that have been around like Trillian and Pidgin (formerly Gaim). However it was first to the gate with deep social network integration and lets me be notified of activity in my twitter, gmail, facebook, and linked in accounts while I work. The team also releases updates whenever a compatibility issue arises between that service and digsby quickly.

The digsby task tray shows your configured social network connections (shown here in the Windows 7 taskbar) and the number of “updates” for that service:

digsby’s Task Tray Icons

Once running, digsby will pop notification icons on your desktop whenever something happens in one of these services. This lets me instantly see when a colleague of mine adds a new connection in linked in, I get an email in gmail, someone needs help on Facebook, or something interesting happens on twitter.

digsby’s Automatic Notifications

I’m able to ignore the updates that aren’t interesting to me without having to scan the full web page for that service, and take action by clicking on the notification when it’s of use to me. I follow several technologists including Martin Fowler on twitter, and I’ve had several times when tweets from them have linked to content that helps me solve a technical problem, or explain a process issue to my client. Of course I still have to avoid clicking links that take me to photos (however cute) of friends kids, and stop myself from reading a technical link if it turns out to be some rant about a technology that isn’t helping me solve a problem. But with great power comes great responsibility, as in all things.

Finally, each icon can be clicked on to show a panel for that service with most of the information you’d see on its web page. Updates can be scrolled and links of interest can be clicked to open your default web browser to that page.

digsby’s Facebook Panel

I remember back in high school having friends that you saw outside of school, and friends that you were personable with in school but never saw at home. I think of social networks as an enabler to a greater circle of trusted friends. These networks become a catalyst for forming deeper connections with people you normally do business with, and encourage making them a bigger part of your life and as a result, trusted advisors at work.

Kanban and lean methods for software development

A brilliant manager named David Anderson from Corbis has a presentation up on InfoQ about his work in helping single project development teams, and eventually entire organizations, adopt a Kanban system for software development. Kanban is a japanese term that comes out of the lean manufacturing principles that originated with Toyota’s approach to manufacturing.

David describes setting realistic limits for the work in progress at various stages of the software development process and using a whiteboard and sticky notes in novel ways to accomplish this. He also goes into a variety of benefits realized in efficiency of the organization, quality of delivered features, collaboration of staff, customer satisfaction, and agility of the process that resulted from this.

I worked for about a year at a company that sells software to manufacturing companies before moving to Austin that was trying to get lean manufacturing software out the door, as well as find ways to adopt these principles internally. Through my reading about Toyota and lean manufacturing in general at the time, I had no doubt that utilizing these techniques (of which Kanban is only one) would mean big improvements at any company.

The challenge is always in selling decision makers on the approach. In the consulting environment you are often contractually obligated to deliver a project with a known set of functionality by a given date, and at a given cost. In this situation you would need to convince the client that by not knowing a final date for all the features up front, the other benefits in efficiency, quality, and agility outweigh the need to hit a specific date. The feasibility of selling this approach to a client depends on the motivating factors behind their choice of an end date, and the degree of confidence they have in you.

From products to consulting – lessons learned

I’m just starting to approach 1 and 1/2 years as a software consultant after 12 years at product development companies. Making the switch has been an invigorating, at times frustrating, job. Here are some random things I’ve learned while making the switch. Some of these statements don’t apply universally (of course) but I think in general they are pretty accurate.

• Don’t settle for vague requirements
  

  At product companies there is less accountability, more risk taking, and budgets are looked at more loosely. In consulting these same companies will hold you accountable, look hard before taking on risk, and watch your billing like a hawk. In this environment you can not afford to have vague requirements. Even if it means taking longer than you anticipated for the requirements/analysis phase of your waterfall or agile project iterations, its worth it. Capture business rules, alternate paths, default values, and mock up user interfaces with Visio or Balsamiq to get client confirmation.

• You can’t always deliver the best solution
  

  At product companies your goal is to create world class products. In consulting your goal is to create value for the client within a budget they can afford. This more often than not means choosing the more cost effective but less robust solution.

• Don’t execute on verbal agreements
  

  If a client tells you something, get it written down and get them to agree to it via a email, signature, or other tangible, trackable asset. This helps to ensure that both parties are kept honest and that you don’t lose track of important statements made that affected your decisions later in the process.

• If you can’t redo it all, learn how it was done
  

  Product companies and consulting clients alike are often replacing existing systems with new technology. If you can’t get a client to sign up for a vision of replacing the entire system, it’s often better to learn how the existing system works, even with its faults, and build new pieces with the limitations of the existing system (but with new technology) first instead of rolling out a radically different new implementation, even with better usability. If you don’t do this, you run the risk of having the client more focused on (and worried about) what they perceive as missing from the new code base instead of how the old features you didn’t port yet need to work in the new system.

• Minimize distributed teams
  

  In a nod to agile and extreme programming, get stakeholders in the room. If gathering requirements and doing design, this means domain experts AND technical leads with a stake in the project. It’s too expensive to reset expectations later in the game. Occasional meetings don’t cut it.

• Don’t co-develop architecture
  

  If you are creating a new framework upon which to build an application, don’t have some parts designed by another team than the other. This goes for database schemas as well. These critical pieces should be done with both team’s stakeholders in the room (see above) or by only one team at a time. It’s too costly to try to sync things up later, and no matter how hard you try to set guidelines for both teams to follow, you will leave something out that causes rework later. Rework is much more expensive to a core architectural component than in code artifacts at a layer of the architecture itself.

• Keep it casual
  

  Try to have fun when you work with the client. Nobody likes someone who is serious all the time and you can work through a difficult situation easier when people are disarmed (including yourself).

Trading excellence for predictability

During my many years as a product developer, I always focused primarily on 3 things. Usability, or the aspects of a product that make users find it easy to work with; a clear and well-designed implementation of the code itself, making the product easy to maintain and enhance; and use of current technologies. As a software architect who exclusively worked with a development manager, I was responsible for coming up with the design of the software, listening to his input on what the user needed to do, and making the implementation great. However I left it to him to communicate the status of the project’s deliverables to upper management, though I would help present technical information to them with him.

Since crossing over into the world of consulting, something I’m constantly striving for balance in is this desire I have for creating excellence in the product with a predictable schedule for delivery.

In product companies, it is important not to blow your schedule out of the water, but if you are delivering a platform upon which many other products will be built, or a flagship product line in a new market, hitting that strategic target in the marketplace and in the usability of your application gives you some leeway (though that can easily be taken away, and is non-existent at companies that do not understand software development at all).

However in consulting, it is much more important, depending on the project, to provide a predictable date for delivery of your promised features. This is especially true on projects, such as the one I’m working on now, where the work we are doing for them coincides with business moves made by their organization and must be in place by a certain hard date.

This shift in perspective has caused me to re-evaluate how I design software. I find myself asking more often whether how good something looks is worth the time I spend on it. I also question whether the way the code is written really needs to be as maintainable and clearly documented as I’d expect before. This mindset change has resulted in a few interesting realizations.

Catapult Systems (where I work) is an amazing company. The vision and structure of the company is such that you really are almost like your own boss on each project if you come in with leadership qualities and significant experience such as I have. It has been a bit difficult going from top technical guy at my past 3 jobs to being a colleague of many with similar skills, but I am taking every opportunity to learn possible and hoping I will prove my ability to innovate and really create solutions for clients that are above and beyond a typical consulting implementation with my first opportunity for involvement with design through implementation on a new code base.

Catapult is growing so fast that we are using proven techniques to manage projects and design our code, but not forcing one methodology on everyone. Though there are folks here that are trying to come up with common standards for some of these, there is an understanding that each team is different and each client has different needs from an engagement and documentation standpoint. I hope while I’m here to find more ways to get folks to build time into the schedule for, and convey the importance to clients of, more focus on usability and quality. This is not at all to say that the existing projects being done here don’t consider these aspects (and on the Sharepoint projects it’s probably more prevelant). However I think we can do even better.