My first session at CodeMash was the pre-conference Weds night – a panel about promoting tech to “others” (being clients, business associates, managers, etc.) The converstation started off initially from a consultant perspective, touching on the challenges in promoting newer “edge” technologies to decision makers/execs who aren’t yet familiar and/or vested in their current offerings. One story referenced how clients would specifically seek out java or .net applications – before even discussing the business requirements. The panel agreed this was the wrong approach. Understanding the requirement should come first, then align the most appropriate technology to solve the specific need. It shouldnt be technology first, problem second. Seems to make sense.
Next came a comment about devs not being “consultants” – however, the panel disagreed. Devs are constantly “selling”, albeit internally, they are still speaking to, persuading or recommending improvements – and this is nothing different. Joe went on to add, he believed Thought Works to be doing it right – hire the smartest most capable people and the technology will follow, in other words, if a company must standardize on a platform, leave it up to the dev to implement the most appropriate language.
Agile also found its way into the converstion, as agile adoption has been mixed, especially in bigger organizations, and in some cases its actually being done wrong. Agile is about feedback. how you deliver it is as important as what you deliver. One recommendation was to be a “virus” start small, independatly, write unit tests, techniques will get noticed in productivty, quality, etc – others (worthy) will notice, ask questions, experiment. After unit testing, implement version control/automated builds and eventually continuous integration (CI). Use index cards/stickies in your area to define work (“stories”) – keep tasks small, focused, you’ll get more done faster. Evaluate pair-programming..
Techniques included selling your ideas is easier than selling yourself. lead by example (even if quietly). Interested, passionate devs will follow. they took a survey and asked people with cool jobs to raise their hand – 80% went up. They went on to add, (i believe according to a piece from Dave Thomas) – attendees were in the top 10% of their field. which makes sense, those seeking out to better themselves do tend to advance more often.
When promoting a new technology, never under-estimate how boring you can be. You may have already sold them, let others absorb the info and ask questions. Other “sales” tips included: match body language, replicate verbal buoyancy, match speech speed and get to know people and what motivates them.
Lastly, they ended with how to drive change when consistently facing deadlines. First off, (per agile) nothing should take more than 6 months to put into produciton. Ala SOA, de-couple, break things into smaller tasks, this also enables adopotion of multiple technologies by isolating functional units, which helped to clarify how/when you choose to change technologies (from current to latest/greatest). There is no single answer, sometimes what you doing makes sense. if the technology you are using is still effective, there may be no need to change? Try to find the right technology for the task, emphasis simplicity – to do so you obviously need to stay abreast of the latest flavors. Start with a little at a time. Play with things in your spare time, make time if need be. A 2 hour window can even yield productivity with newer edge technologies. Lastly, get help from the community, read blogs, ask questions.
Not bad. So far, we’re off to a good start.