Managing "Techies" and Developers

What could be useful about the next 45minutes to an hour?

“how we can augment our technical capacity without making stupid mistakes”

“going to be managing techies and want to hear the stories”

“i’m a team of one in terms of tech and we’re growing and need to add capacity but don’t know what that means”

“figure out how to help npo’s manage external tech consultants”

“find ways to bring new methods for blending different technical people together”

“ how to get what we need when we work with developers and what to do when we don’t get what we want/need”

3 fundamental concepts (4) in managing techies:

obvious, yet rarely considered: they’re human beings not vending machines for getting shit that works they come with the same foibles that all human beings have, they aren’t miracle workers, “we just need to get a developer here to solve this” is not a real thing

enlightened empathy

can’t overstate the importance of project narrative - developers need to know Why they are doing something:

customers, users think a developer just knows what you need when you say “make x” - they want there to be a reason to do this

you want to talk to them about what’s the mandate where are we who benefits

update this regularly “when we talked last time, this was really important, and now that’s done, this is the next priority and why we need it and when”

co-equal narrative that they are part of your thing

Write it the fuck down

Greatest fails with techies is sitting in a meeting and telling them to do something but that doesn’t mean the techie got it all down or even understood it

later on you ask why that wasn’t done, but in their mind it wasn’t clearly assigned or a deliverable they understood

Write a coherent list in YOUR language what you need, your requirements, maintain those documents (project assets) that tell us what the project is, needs, etc.

Project Management Tool is key

Excel is not a PM tool, email isn’t text file isn’t

BaseCamp - multi stakeholder compatible is a benefit

so no one can go “I don’t understand it”

people argue it doesn’t work, need a tool where things go red when they aren’t done on time is key

If the developers have a tool - use their tool as long as you have full access, and augment their tool with things you own. Don’t make technical people learn your shit Fine grained interactions/transactions

Checking in almost daily basis until you’re on the same wave length then checking in every couple of days - don’t leave a developer alone with your project for 6 weeks

“Fuck it, ship it” mentality - ask developers to ship often

to get what you want, ask for early version and use it (pathetically and gently because you know it is early)

Billing/Financial Granularity - one thing that fucks these is not watching the meter on teh costing

bi-weekly “hey, what’s are tab, what’s are current billables, how can we use the remaining money,

otherwise you could end up way over budget without having anything you can really use

At the beginning (before you hire them and negotiate the project terms) Tell ‘em you’re going to tell them

I’m going to want to check in regularly, want to see work in progress, what tools do you use? is any of this going to be a problem?

How do you deal with conflict?

What’s the rundown on general attitude, predictable conflict points,

recalcitrants - needs to be a narrative on your part about what’s going on and your role, get out ahead of conflict and try to de-escalate

“tell me when I’m being an idiot now because I want to make this a great experience for us “

Most techies live/think in a world of gamification, and they tend to look at things as playing a game with you. You have to provide them with an experience that is fun and interesting for them within the mindset of playing this game

intellectual - fun, interesting, compelling stress/annoyance factor - minimize time to get to done

have “safe words”

almost never appropriate to do forensics of a conflict - no “he said, she said” stuff, that’s not helpful and there’s no version in forensics where it’s not about polarizing two perspectives

Focus on “How do we get to good?” conversation instead

Train yourself to speak in questions, not in statements

“is there a reason that these things later in the schedule came earlier?”

Be prepared for sometimes hearing “oh, you said that thing in a meeting 2 weeks ago and I thought you were changing the entire process”

How do you manage a team of developers (if you are technical or not) where you need your programmers to help guide you on some of the what to do but still be in charge of the project

Hire the right people is one critical thing - so many people hire techies and focus on their tech skills

The lunch test: would I be willing to have lunch with you on 3 consecutive days? if no, don’t work/hire them

When you hire someone, set a frame of what they can expect and what you expect from them

With Techies - check references, ask how does this person deal with stress? have you ever been in a conflict with them and how did it turn out?

do not try to resolve the non-alignment in a multi-person scenario, separate them because they won’t want to lose face in front of other techies

Learned a lot from Bill Murray - meatballs, stripes

Certain self deprecation that managers need so you don’t think you’re bigger just because you’re the manager

Aspiration for 2013 believes there is a universal process that NPO’s should follow if they need a technology deliverable

start with personas that need to touch/use the product you’re deploying and create user stories about what they

each sentence is a description with no tech words that says what a user will need to do with the product and includes why they need to do that

we tell people that alot of NPO tech projects go wrong becuase they are specified by the NPO in a conference room and white boards then the next step is “go build it”

if you identify the user personas, find 10 people who fit them within your group and you want double digits because they won’t always go and use it and give you feedback.

throw out user stories to your target demographics and tease out the user mandates - do your users really want to use something, and will they use it more than once?

get user stories in front of users to get it real and ask users to convince you that they’ll really use it

talking to your users almost always shrinks the deliverables

then get into an interative, MVP process and get your users to

force the dialogue to stay in user stories and end user language and not in tech language, that puts the burden on them and make sure they’ll stay in user language

technology selection - you want a tech solution, pick a relationship that you want to work with shares values/understands mission, has good references

A number of NPO’s sign away their IP rights for tech in contracts when they paid for it and need to watch out for that

work at a solution level, not a tech level

Pick something you know other people are using in similar ways, but prioritizing the relationship with the vendor helps you get away from not knowing the tech

One of the most compelling volunteer roles is a “tech due diligence” role to find someone who will look at your tech and tell you what they think

AspirationTech does it for free - important to have someone who isn’t you or isn’t them and can be a second opinion.

Pilot engagements Rock

pizza delivery with technology mindset is not going to happen

If you’re working with a shop that’s building your website, break the contract into phases

phase a deliverable

work with a dev shop on a wireframe only, then if you like working with them - go to the next step in creating a deliverable

Have the option to control your destiny

engage in a discovery phase just to see if they are reflecting back your user stories and they are understanding and take that discovery phase results and shop it out at multiple vendors

Deliverable Phases: Is there a way to

Many NPO’s expect vendors to do a tremendous amount of heavy lifting for free, offer to pay something like $500, to help you get to the discovery assets generated and make sure you own it to show their time is respected and valuable

Need an escrow zone - when the code is written, it shouldn’t be on the developers laptop. The code and the documents.

Commits should be done on something you own - like github and get a place you can see the code accumulating and get other eyes looking at it

How do you define transparency? I know what we agreed to, we put something up, and all of the sudden a designer will throw something up there to show them and the client will tell the designer what they want - except it wasn’t approved or anything and it becomes hours burned suddenly

Should the client have access to all of the team or just access to the PM in general to avoid this?

There needs to be a process - this example is a lack of process

Verbal instructions should not be allowed - if someone wants something, it should be written down

Tell clients: we’re going to ask you for feedback and queue all that feedback, then we’ll look at all of the feedback from a to-do list and sit with you and finalize before lots of back and forth edits are made

Coach your designers/team to have a conversation with clients that the PM and meeting are the point of communication

list things in your staff meetings about what people have the power to resolve on their own, and here’s the things that you need to send up to the PM

particularly things that have a cost

teach people the “red flag” rule

Hollywood marriage rule - tech relationships always end in some form of divorce or separation

Model for divorce, “prenup” thinking

Have conversations initially about who owns the code, what the process is, if things don’t end up working out

random technical due diligence - “hey, i have this issue and I think I’m being put in a corner and I’m just trying to figure out if this is a good idea”

tips: buy a friend a cup of coffee and ask them without naming names, don’t send outside people all this full access to documents, put the burden of proof on the developer

really important when you have technical due diligence done that you route the info through yourself, and don’t jerk the people around

make a judgement call “is this a meaningful conversation or something where it’s about how you just don’t like the way someone else is doing something that’s different from the way your outside resource does something”

best practice to budget for external code review - maybe half a day or a day at a medium point in the process early enough so corrections can be applied

some agencies have a developer internally who’s also there to review code from the perspective of someone who is not working on the project too

Volunteering aspect of managing technical resources - small orgs have a challenge

70-95% fail to use volunteers for technical deliverables

Different type of commitment with volunteers

New code written versus using existing where you set yourself up for failure using volunteers even the best intentioned volunteers are going to be a challenge to get them to step up and finish the 10% of the project that’s going to be required to finish the deliverable

How much due diligence do you need?

Get volunteer techies to write down what they are going to do before they do it

love your willingness to volunteer and for that to happen - you need to write down in advance what you’re going to do, and get approval from the collective plus document as you go and in end user language that people can understand

Token payments are a valuable tactic

to the extent that your critical path volunteers get on your website as critical path volunteers - they feel the love, and now their face is on the website and they’re accountable

Can’t be overstated - if you’re managing techies, skill zero is the narrative, you’re a storyteller, you need to be narrating and telling the story and create continuity through your story and holding up the heroes, talking about your struggle and speaking to it