We support and mentor others on the team, so they can succeed in quality work, and learn our best practices.
We listen for others needs and step up
We provide an appropriate level of support - helping out, but also allowing space for them to figure things out and learn
If you are asked to mentor someone, make time to check in regularly
We collectively own the project, and avoid over-compartmentalizing roles or sections so that we can continue work in anyone's absence, and maximize cross-disciplinary learning.
"It's not my job" is not in our vocabulary
We learn as much as we can about all phases of the development cycle
We document a project for possible handoff to another team.
We honor our commitments and communicate as soon as we think we can't meet them.
Provide expert consultation
We show up as experts for our clients, so that we mesh their knowledge of their needs with our knowledge of technology, web and trends to deliver the most value.
We explain trade-offs to clients and help them evaluate the options so that they can ensure the decision is the right one for the project.
We are true to our clients underlying needs and best interests, and do not simply do what they ask so that they get the site that solves the right problems for the right people, is maintainable and delivered within the right budget and timeline.
Participate in Project Discovery
We double-check assumptions made in the sales cycle during the first meetings with clients.
We ensure we have sufficient time to discover the scope of our problem set.
We document our finding as much as possible in a transparent way, so that both the dev team and the client can see and react to the findings.
We flag any requirements that are likely to cause dev problems, either because we know they have been difficult to implement in the past, they are fiddle-y, the requirement is too vague to accurately estimate, or we don't know how we'll address the problem.
We try to meet in person with the client if possible. It gives us a better sense of the pressures they face, how they make decisions, who needs to be involved in decisions, and how likely their decisions are to change once they've made an authoritative decision.
We are aware when a client can't fully explain what they want and why.
We remain aware that we can limit our involvment if, during discovery, we find problems that we don't think we can overcome within the scope of our contract. We have to be open and honest about the constraints we face.
It's better to back out of the project rather than burn budget and not be successful.
Identify, communicate project risks and escalate when appropriate
We label tickets (at least): Low, Medium, High risk.
We understand the distinction between risk level and confidence level.
We educate and involve clients in expecting and managing risk.
It's difficult to share risk with clients and we need to work on the soft skills needed.
We recognize risk is present at the requirements, knowledge, and execution level, and also "External" risks, such as working with 3rd parties, or on servers that we're not familiar with.
Clearly identifying dependencies (data needed, code needed, graphics needed, access needed) can help bound risk.
We differentiate "pre-execution" risks (requirements, design, assets, dependencies etc) which are typically addressed by communication and management from "technical" risks, which can be hard to mitigate in advance.
We escalate problems quickly to the tech lead, PM and/or account manager if we encounter issues that could block progress, momentum, or success.
Train clients
We give frequent demos and get clients using the site early on, so that clients can give us effective feedback and prioritization.
We train the trainers.
We try to identify paths towards self-sufficiency for our clients where possible.
We add good help text for content creators.
Help measure project success
To evaluate the success of a project, stakeholders require a means of measuring it.
We ensure that metrics are available to help evaluate the success of functionality/the project.
Functionality should always be built in a way that produces actionable metrics (as opposed to "vanity" metrics).
We document where metrics are stored.
We support clients in the design and use of user testing, analytics tools, A-B testing for metrics.