I’ve always been attracted by strategy. Board games, books, you name it. My Grandmother reluctantly gave me a copy of Sun Tzu’s “Art of War” as a birthday gift, although I’m sure she also gave my parents grief over it. The art and science of strategy was the result of a need: to succeed with a limited set of resources. Any organization can benefit from strategic thinking, even those with an exorbitant amount of resources.
In my experience, web teams are often used without any sense of direction or purpose other then producing more sites and applications. Often times a P&L report or an incompetent manager drives this behavior. This is detrimental for several reasons:
1. Web developers and designers need structure, it’s part of their thought process. CSS, APIs, design patterns, frameworks. All are based on rules and logic. Without a structure in place to manage change, whether technology or their careers, your team will grow complacent or bored.
2. Without a “big picture” view you can burn out your staff. This is a surefire way to facilitate turnover, lose organizational knowledge and fail customers.
3. Work is based on the precepts of one individual, rather then the team. In the case of the incompetent manager, this equates to pure hell for anyone working on the project. Why should the process of working be based on a team, rather then the individual? Read “Good to Great” by Jim Collins.
I could go on, but odds are there are many other items to add to this list. Rather then dredge up more web agency misery, let me offer two beacons of hope.
1. SIPs
As a manager of a web team, realize that if you don’t build product evolution into your work, you might as well quit and sell burritos on a beach. Ask one of your developers who has produced the same code for 4-8 clients. It gets boring. Hideously boring.
Combat this tendency with a management pattern I call SIPS, or Silent Iterative Productization. Give your developers & designers 30 minutes a week to explore ideas and concepts. Let’s say an idea comes up that offers some type of value (see below for an approach to this methodology). Build this into the application, whether it’s a CMS, e-commerce engine or other system. As it’s implemented in future or existing projects, estimate the time saved and divide that in half. That amount is awarded to the developer to explore other new ideas, contributing to the evolution of the product. Because the time savings is the driving factor for future improvements, this methodology is thought of as “silent”.
Use SIPs to paint the big-picture for your team, also allowing them to become part of the strategic view and influence the course of the product roadmap.
2. Scientific Reasons for Web Development
One of my favorite moments in agency work was when a junior developer was tinkering with some pretty deep cms functionality. I took this as an opportunity to show how to evaluate change and impact. Ultimately, it’s important to know how an approach is more efficient then another and to distill any arguments to objective elements. Why is a given approach better? Can it be quantified? Where is the research and understanding?
Develop a “scientific” model for development, defining the element to test, methodology and outcome. Make it less about a subjective opinion and more about facts.
One last note: watch out for your developers. It doesn’t matter if it’s part of a team internal to a corporation or at a web agency. Their work is often the beating heart of an operation. Buy ‘em lunch. Make sure they are a vested part of the team.
Great blog and an interesting post. It’s always good to find more discussions about the much neglected topic of managing web teams.
I’m interested in your SIPs approach - I’m assuming that this is what you’d use for an agency web team, as my experience of internal teams is that you rarely get multiple clients asking for the same thing (it’s the other end of the scale - they all want something different).
Having said that it seems like quite a sound approach - I was just wondering how you’d run it when your basis wasn’t producing the same code for multiple clients?
Hi Lucy,
Thanks for the feedback. You’re absolutely correct: the SIP model was developed for a web agency. Internal teams are an entirely different matter. I would look at past projects, perhaps over a few years, to determine any trends. Is there any “product” that can be defined as a goal? Volume of requests, nature of the work, the industry of the company and executive support for technology projects would all come into play.
For me it was a content management system. I developed a dynamic CMS in my last days in a more tech role. Every client might ask for something different, but the base model is flexible enough to respond as needed.