Here is one the other talk I did at Øredev this year. The original pitch was going to be show a single character commit and walk it through to production. Which is in itself a pretty bold idea for 40 minutes, but… But that pitch was made 7 months ago with the belief we would have Continuous Delivery to production in place. We ended up not hitting that goal though so the talk became more of a experience report around things we (I) learned while doing it. I would guess they are still about a year away from achieving it given what I know about priorities etc.

Below is the video, and then the deck, and the original ‘script’ I wrote for the talk. Which in my usual manner deviated from on stage at pretty much every turn. But, stories were delivered, mistakes confessed to, and lots of hallways conversations generated so I’m calling it a win.

CONTINUOUS DELIVERY IN A .NET WORLD from Øredev Conference on Vimeo.

Introduction
I’ll admit to have being off the speaking circuit and such for awhile and the landscape could have changed significantly, but when last I was really paying attention, most, if not all talks about Continuous Delivery focused on the ‘cool’ stack such as Rails, and Node, etc. Without any data to back up this claim at all, I would hazard a guess that there are however more .NET apps out there, especially behind the corporate firewall than those other stacks. Possibly combined. This means that there is a whole lot of people being ignored by the literature. Or at least the ones not being promoted by a tool vendor… This gap needs to be addressed; companies live and die based on these internal applications and there is no reason why they should have crappy process around them just because they are internal.

I’ve been working in a .NET shop for the last 19 months and we’re agonizingly close to having Continuous Delivery into production… but still not quite there yet. Frustrating … but great fodder for a talk about actually doing this in an existing application [‘legacy’] context.

Not surprisingly, the high level bullets are pretty much the same as with other stacks, but there of course variations of the themes that are at play in some cases.

Have a goal
Saying ‘we want to do Continuous Delivery’ is not an achievable business goal. You need to be able to articulate what success looks like. Previously, success as looked like ‘do an update when the CEO is giving an investor pitch’. What is yours?

Get ‘trunk’ deliverable
Could you drop ‘trunk’ [or whatever your version control setup calls it] into production at a moment’s notice? Likely not. While it seems easy, I think this is actually the hardest part about everything? Why? Simple … it takes discipline. And that is hard. Really hard. Especially when the pressure ramps up as people fall back to their training in those situations and if you aren’t training to be disciplined…

So what does disciplined mean to me, right now…

• feature flags (existence and removal of)
• externalized configuration
• non assumption of installation location
• stop branching!!

Figure out your database
This, I think, is actually the hardest part of a modern application. And is really kinda related to the previous point. You need to be able to deploy your application with, and without, database updates going out. That means…

• your tooling needs to support that
• your build chains needs to support that
• your application needs to support that (forwards and backwards compatible)
• your process needs to support that

This is not simple. Personally, I love the ‘migration’ approach. Unfortunately… our DBA didn’t.

Convention over Configuration FTW
I’m quite convinced of two things; this is why RoR and friends ‘won’ and why most talks deal with them rather than .NET. To really win at doing Continuous Delivery [or at least without going insane], you need to standardize your projects. The solution file goes here. Images go here. CSS goes here. Yes, the ‘default’ project layout does have some of that stuff already figured out, but it is waaaaay too easy to go of script in the name of ‘configurability’. Stop that! Every single one of our .NET builds is slightly different because of that at 360, which means that we have to spend time when wiring them up and dealing with their snowflake-ness. I should have been able to ‘just’ apply a [TeamCity] template to the job and give it some variables…

Make things small [and modular]
This is something that has started to affect us more and more. And something that doesn’t be default in the RoR community with their prevalence of gems. If something has utility, and is going to be across multiple projects, make it a Nuget package. The first candidate for this could be your logging infrastructure. Then your notifications infrastructure. I have seen so much duplicate code…

Not all flows are created equal
This is a recent realization, though having said that, is a pretty obvious one as well. Not all projects, not all teams, not all applications have the same process for achieving whatever your Continuous Delivery goal is. Build your chains accordingly.

Automate what should be automated
I get accused of splitting hairs for this one, but Continuous Delivery is not about ‘push a button, magic, production!’. It is all about automating what should be automated, and doing by hand what should be done by hand. But! Also being able to short circuit gates when necessary.

It is also about automating the right things with the right tools. Are they meant for .NET or was it an afterthought? Is it a flash in the pan or is it going to be around? Does its project assumptions align with yours?

Infrastructure matters
For Continuous Delivery to really work, and this is why its often mentioned in the same breath as DevOps (we’ll ignore that who problem of ‘if you have devops you aren’t doing devops’…), the management of your infrastructure and environments needs to be fully automated as well. This is very much in the bucket of ‘what should be automated’. Thankfully, the tooling has caught up to Windows so you should be working on this right from the start. Likely in tandem with getting trunk deliverable.

Powershell
But even still, there are going to have to be things that you need to drop down to the shell and do. We made a leap forward towards our goal when we let Octopus start to control IIS. But they don’t expose enough hooks for the particular needs of our application so we have to use the IIS cmdlets to do what we need afterwards. And there is absolutely nothing wrong with this approach.

Its all predicated by people
Lastly, and most importantly, you need to have the right people in place. If you don’t, then it doesn’t matter how well you execute on the above items, you /will/ fail.

This is one of the talks I did at Øredev last week. As usual, my decks are generally useless without me in front of them. But lucky(?) for you, all the sessions were recorded.

CONFESSIONS OF A ROOKIE [DELIVERY] MANAGER from Øredev Conference on Vimeo.

But if you are too lazy to listen to me for 40 minutes, here is the deck and the content I was working from on stage. Of course, I don’t actually practice my talks so some content was added and others was removed at runtime, but…



WTF is a Delivery Manager?!?!

For about a year and a half I had to the title of ‘Delivery Manager’ which means a whole lot, and nothing at the same time. And therein lies it potency. Just as Andy Warhol famously said that ‘Art is anything you can get away with’, being a Delivery Manager is anything you make it. In my case it was essentially anything and everything to do with getting our application into the hands of the end users.

Tip: Don’t put yourself in a box

Before we landed on this title other ones we considered were ‘Doer of Stuff’, ‘Chaos Monkey’ (blantantly stolen from Netflix), and ‘Minister Without Portfolio.’ But we eventually went with the more business palatable of ‘Delivery Manager’. Since Delivery Manager is a made up title, it is useful to describe it in terms and titles people are used to seeing; Product Owner, Production Gatekeeper and Process Guardian are the three umbrella ones I most associated with. But even those could be sub-divided. And possibly sub-sub-divided. Its also important to recognize that the percentages of these roles are ever in flux. And just to keep things interesting, can sometimes be in conflict with each other.

Because of the mix of problems Delivery Managers will have to, erm, manage there is a certain skillset required to be effective at it. Or perhaps not a specific one, but a breadth of one. Testing, Development, Operations, Marketing, Systems, Accounting, etc.. And I would suggest that you have done a stint consulting as well. There is nothing like it in terms of being a crucible for problem identification and solving. That doesn’t mean of course that you have to be a perfect mix of all these things. It is inevitable that you will be more specialized in one over the other, and I would be suspicious of anyone who said they weren’t. I for instance come up through the testing ranks. Specifically the ‘context’ ranks. That, for me is my secret sauce.

And yes, there is a tonne of irony around the idea that I spent a decade saying ‘I am not a gatekeeper! I am a provider of information!’ to moving precisely into the gatekeeper role. But in that irony I learned a lot. Not just about being /a/ Delivery Manager, but about how /I/ am a Delivery Manager.

No*

While everything is important in one degree or another, this is perhaps the one thing I leaned on every single day. When faced with a request, the default answer is always No. Well, it is more ‘No* (* but help me to say Yes)’. And don’t be subtle or selective about the application of this rule. At 360 there is an entire department I dealt with on a daily basis and they could tell you my default answer is going to be ‘No’ to any request. But that doesn’t stop them from asking since they know about the asterisk. What it does is force them to think about their request ahead of time beyond simplistic ‘because’ terms.

This is not a new idea that I ‘discovered’. I blatantly stole it from someone who was at one point the Product Owner for Firefox (I think… I can’t find the article now, if you find it please let me know). It all boils down to an economics problem around opportunity cost. If you say Yes to everything then the queues will over flow and nothing will get done. But if you say No to everything and selectively grant Yeses then there is order [rather than chaos] in the pipes.

Tip: Learn about economics; specifically Opportunity Cost (but Sunk Costs are also useful to understand when involved in No* discussions)

Tip: Unless you really understand the problem you are being asked to solve, you cannot say yes

Mature organizations understand this at their core. It might be you that levels them up to this understanding though.

Frenemies

Being the person who always says No won’t always make you friends. At first at any rate. You will become everyone’s enemy … and everyone’s friend. Welcome to the balancing act. I would argue that if you are everyone’s friend all the time then you are not doing your job properly. Part of the animosity can be dealt with though explaining the asterisk, but also by communicating who ‘your’ client is. Remember the hats that are being warn have words like ‘Owner’, ‘Guardian’ and ‘Gatekeeper’. Your client in this role may not being whom it is people think it is. In fact, it almost assuredly isn’t. Yours is the application and the [delivery] pipeline.

Tip: The Delivery Pipeline is a product

This will cause friction; and depending on how your company is structured it could be a non trivial amount. But as long as you are consistent in your application of No* and are transparent in the reasonings why, in my experience, it is easily overcomable.

Tip: Do you know what business you are in? Is that the business the business thinks it is in? It’s really hard to win that battle.

Defence

The role of ‘Delivery Manager’ can sometimes be a lone wolf one, but at other times you will have people working for you [as I did]. It is critical to remember is that as a ‘people’ manager your primary goal is to protect everyone under you. Physically, psychologically and work-ly. You need to be able to do their job but also to let /them/ do it. Just because you /could/ be the hero doesn’t mean that it is healthy for you or them. Like you would a child, let them work through it and be ready to catch them if they start to fall. [The existence of that metaphor does not mean of course that you should treat them like kids though…] Don’t hold them to higher standards than you hold yourself to. But also don’t inflict yourself on them as well. I’m a workaholic (thanks Dad!); its unfair to put than onto others. I also don’t believe in work-life balance (especially in startups) favouring harmony instead — but what is harmonious for me is likely not the same for someone else.

In order to do that you need to constantly be running defence for your charges; human and software. Invite yourself to meetings, constantly be vigilant for conversations that will affect them. Which unfortunately means you miss out of plugging in your headphones and listening to music all day.

Tip: Ensure grief from No* comes back to you, not your people

Tip: People, not resources

Tip: Ask the people who work for you if they feel you have their back. If not, you’re doing something wrong.

You Will Screw Up

I tend not to speak in terms of absolutes, but here is a truth; You will screw up, potentially largely, in this role. You are making decisions that require a crazy amount of information to be assimilated quickly and if it is not perfectly done or you are missing any [maliciously or innocently] then you are hooped. And that’s ok. Pick yourself up, and go forward. That is the only way you can go. We no longer have the luxury of going back. Remember, tough calls are your job.

Bending to go forward is not a new thing. I’m sure I heard it a couple times before it really stuck, but I credit Brian Marick’s talk at Agile 2008 for that sticking. I can’t find a video of it [though didn’t try hard] but the text of it can be found a http://www.exampler.com/blog/2008/11/14/agile-development-practices-keynote-text.

Tip: Be careful though; screw up too much and Impostor Syndrome can set in. And it sucks. A lot. Get help. See Open Sourcing Mental Illness and Mental Health First Aid

Tip: Make sure your boss is onboard with the ‘go forward’ approach

Tip: Confidence is infectious, be patient zero

Know and be true to yourself
One of the biggest things I’ve learned in the last bit is around how /I/ function. Some people find the MBTI as hand-wavy and hokey, but I think its useful not in terms of how I choose to interact with people but in understanding how I am. I’m ENTP. Hilariously so. That’s not going to jive well with organizations that are ‘typed’ differently. That’s been a huge insight for me.

Tip: For a lark, take an MBTI test. Its heuristic, but still interesting

Being a geek I also think of things in terms of the classing AD&D alignment scale. I lean towards the Chaotic Good. We have a goal; there are no rules here. Especially ‘stupid’, ‘artificial’ ones.

And that has got me into trouble more than once. I don’t doubt that it will again in the future.

But I also have a strongly defined set of ethics and philosophy around how things should be done. Entrepreneurs don’t necessarily make good employees…

Putting a bow on it
Being a ‘Delivery Manager’ is great fun. Challenging as heck, but great fun and super rewarding. As someone who cares deeply about quality and the customer experience and has experience backed opinions on how to achieve them I don’t see myself going back to a ‘Just X’ role.

(P.S. I’m now available for hire if your organization needs a Delivery Manager)

I’ve had this conversation a couple times in the last week, which usually means I should be writing about it. (Also, because its been ~ 15 months since there was one…)

There seems to be this myth that just because an application is not installed on the client’s premises that it must be SaaS. Ummm… no. Or at least not exactly. See, its a lot more subtle than that. Here is how I am currently distinguishing between the two in my head.

• Delivery – This is easy. If you host it for your customers, you can be SaaS-y. If you have to ship something to your customers they need to install, then you cannot.
• Tiering – At the heart of SaaS is the differentiating of customers based on service levels or other customers. And charging differently for them.
• Onboarding – Customer should be able to sign up for your service without you knowing about it. Ideally you should regularly look at your customer list and be surprised by who you see on it.
• Self-service – That thing your service does likely needs to have some sort of interaction from your customer be it periodic configuration or scheduling or whatever. They need to be able to do it. All. Without your involvement — unless you are charging a higher tier rate for that…
• No touch billing – You know you have figured out the whole SaaS thing when you can hook a vacuum up to your customer’s wallet. If you are dealing with smaller businesses, then this is relatively easy by hooking up to a corporate credit card. But even at the ‘enterprise’ level you can do it by integrating with your financial and invoicing systems
• Offloading – This is more ‘open source anarchist’ maybe than anything else, but your customers should also be able to leave your service without you knowing [hint: have a notification for when someone leaves and then follow up to see if you could have prevented it]. This includes getting their data out.
• Crazy uptime – Remember the first bullet? Your service is hosted… so if its down because you are offline because you are deploying an update, your customers are dead in the water. 100% uptime. That’s your goal, not ‘5 9s’ or whatever.
• Paranoia – Because you are hosted, and can be easily onboarded and offloaded you need to be constantly paranoid that someone will build a better ‘thing’. This paranoia is a good thing as it drives innovation.

This is still evolving, but having played in and paid attention to the SaaS-y space for a number of years now, I’m fairly comfortable with this list of attributes and is how I’m mentally evaluating all companies that call themselves SaaS.

(This had more structure in my head before typing it out, but I’m posting it anyways.)

theory: if you don’t embrace remote workers, your geography dictates your platform choice

— adam goucher (@adamgoucher) June 2, 2013

OK. This got enough attention that it requires some expansion.

I live in the eastern suburbs of Toronto. As part of a bit of a geography lesson, the western suburbs have been traditionally home to various large tech companies due to its proximity to the international airport (and likely tax incentives). The eastern suburbs have been more manufacturing oriented around the [once large] car plant. As such, the tech ‘community’ out here is actually pretty small and disorganized when compared to both the size of the population and even the size of the population of people in tech that commute into the city for a living. [This is in spite of large efforts by some companies around here.] The make-up of the Toronto tech scene is also interesting. Yes, there are hip tech companies like ScribbleLive around, but most of the programming jobs are dominated by the various financial and insurance organizations or provincial government agencies that are based out of the core. And with those industries come ‘safe’ development environments, and large services contracts. Both of which equate to ‘Java’ and/or ‘C#’.

So let’s pretend that I was building a ‘traditional startup’ (an interesting juxtaposition of words if ever there was one) out here. And to throw an additional twist on the scenario, that I wouldn’t be the one doing the coding, what language / platform would I use?

Its actually not so simple a choice if I want to build for the future rather than build to flip.

Actually, let’s take a step back a second. It is actually a really simple choice if I embrace remote working as a fundamental building block for my company as I would just hire the best people and have them use the best platform for the job. If I follow the 1980s approach of having everyone in the same room, 9 – 5, things harder. A lot harder.

Again, using the eastern suburbs as my example, the majority of [experienced] programmers responding to your job postings are going to be working presently in the financial industry and are interested in your gig largely because it eliminates the commute. And it brings with them the baggage of that industry; Java and C# plus a much slower release pace than what one would expect from a startup. Which isn’t to say I wouldn’t hire someone out of that situation (heck, I started at a bank), but I would be very upfront with what they are getting into. But if you want to have the largest population to pull from, then your platform is going to be one of these two.

But let’s say you want to up your change of getting funded by using some buzzwords and you decided that what you want your startup to be around is Node and Mongo. Now you have a different problem — if you are not embracing remote workers. Let’s say that there are 300 people who know Node and Mongo within an hour’s commute from my this fictitious office. Total. Of those 300, let’s say that 50 (which is likely high) are of the level you want and haven’t just run through a tutorial or two on the internets. And of those there are maybe 5 – 6 that would consider leaving their current role and if you are really lucky one might live close-ish by. Otherwise you are going to likely have to overpay to have them deal with the lack of transit infrastructure out here. But that doesn’t necessarily scale. Go back in time 6 years and see how much more Rails programmers were getting paid for just this reason.

Take a moment and read yesterday’s Do you really know the business your startup is in? as this plays into the mix here. If you decide you are a technology company then you say ‘screw it!’ and use the cool tech, overpaying for talent if necessary, but if you decide you are more of a ‘service’ company then you focus less on the platform and more about the customer experience. So if you want people in chairs in the office then you need to factor in the skills and proficiencies of the pool you are drawing talent from when choosing a platform. Of course, if you are happy to have people working from anywhere in the world, but logged into IRC when working with a VOIP line available to them at any point then your pool is nearly infinite as are your platform choices.

Here’s a theory; most startups don’t actually know what business they are in. They do likely know the business they want to be in, but unless your company is guided towards that specific goal (and you have no small bit of luck) it is your customers who actually determine what your company is an does.

In the spirit of Ninja/Pirate/Elf/Dwarf this there is two different dimensions that go into this.

The first dimension is whether you are a ‘business’ oriented company, or a ‘consumer’ oriented company. And this is not always so obvious an answer. My company for instance is pretty easy to peg as a ‘business’ one — we help businesses do automation and continuous delivery better. Which is Google? If you answered ‘consumer’, I would argue you are wrong. The consumer usage of their properties enables their real business which is advertising — which is something businesses buy. These days ‘hybrid’ companies are developing but they are going to tend to skew more to one side or the other.

The other dimension is around whether you are a ‘service’ oriented or ‘technology’ oriented. Or put another way, which part of the business is the dog, and which is the tail. A service oriented company, which I would argue Freshbooks is one, will do things differently than a technology one. For instance, all new people at Freshbooks do a stint in the call center to learn the customer’s needs, etc. I have no idea if it will scale, but it does currently and is awesome. Yes, they have a lot of tech behind the scenes, but that enables their service. Etsy, I would label as a technology focused company. I’m sure they have support people there, but hitting a person is a last gasp event and I’m guessing (I could check, but why research something for the internets?!?!) new hires don’t do a rotation through the support team and you can find their developers at various conferences explaining how awesome their tech is. (Which it is btw!)

Sitting along any point on either axis is not in itself a bad thing — unless it counters what management and investors want. (Trust me). But where you sit on them will determine a lot of subtle things in your organization;

• Do you have ‘client happiness’ people, or ‘customer support’
• Do you have all-hands cheerleading meetings at the beginning of the day, or do you have remote workers with erratic shifts
• Do you jump when a customer wants something, roadmap be damned or do you rely on your own analytics and ‘lean experiments
• Are you going to use the bleeding edge ‘cool’ thing (these days, Node and friends I guess) with the risks that come with a rapidly evolving platform or something ‘safe’ like ASP.NET MVC or Ruby on Rails.

Coming back to the original idea, I think it would be an interesting experiment for a company to reflect on this, not just by those in management but those actually in the trenches. A mismatch means there is a problem, somewhere. A further inquiry of say, the top and bottom 10% of your clients by revenue might also be interesting. Again, if there is a mismatch, there is a problem.

(Now if only I had thought of this when building my pitch deck a couple months back — it would have made a good slide I think.)

Every company has a moment where they are forced to care, I mean, really care about Security and Privacy. Sure, you should always care in the back of your mind, but at some point it comes front and center and a key pillar of everything you do. The question is whether you are going to be ready for when it comes. Odds are, no. (Because if you were, you would already be caring.) I’ve seen this moment happen a couple times, so here is my list of things you now need to pay a whole lot of attention to.

First, Security and Privacy are related, but different. In hand-wavy terms; Security is related to keeping information in and the bad guys out, and Privacy is about individual people’s information in your trust. And it is a trust, not a right.

With that, here is my brain dump on the topics.

Security

• Who is the officially designated person for security problems?
• Physical security – padlocks on the cage, etc.
• Can people wander the office without being questioned?
• Is all input validated on the backend as well as the frontend
• Disarm all input
• Disarm all output
• Don’t blindly use user provided strings in queries
• PCI compliance?
• Don’t store your password in the clear…
• The first question about any change should be ‘what are the security ramifications’?
• Do security bugs get put into the main bug database?
• How are security things disclosed

Privacy

• Who is the officially designated person for security problems?
• Do you know what PII (Personally Identifiable Information) you have
• Do you know what flows the PII participate in?
• People need to be bucketed based upon their informational needs
• Don’t clone your production database down into lower environments — without scrubbing the PII
• Do not display PII to anyone other than the owner of it. (Unless they really need it.)
• PII should be encrypted in the database
• Thou shalt not grant access to the production database
• Log the stink out of access, including read, of things that contain PII
• The second question about any change should be ‘what are the privacy ramifications’?
• Do privacy bugs get put into the main bug database?
• How are privacy things disclosed
• What legislation around PII affect you? And in what jurisdiction? Is it where the head office is? Where the app is hosted? Neither?

Writing secure code is actually not that hard. We know how to do this. At this point it is really just sloppy code. But putting the people and process around how the code that is generated is hard.

This is just a quick off-the-top-of-my-head list, but the key thing to remember is that its not paranoia if they are actually after you. And ‘they’ are.

A pattern than I unwittingly did and have noticed in others is that you need to work out what your variation of ‘consultant math’ is for yourself. No matter how many people tell you, you need to blunder through to your own understanding of it. Often by going waaaaay overboard on conferences the first year or so after going independent.

Here is my variation of ‘consultant math’ around whether I will attend your conference or not. Not that anyone will listen to this and not thing ‘hey! I’m different!’ — no, no you are not. But anyways…

The first part of the equation is whether or not I am getting paid to be there. This can either be in term of an honorarium, or flight or hotel (or all three!). Consultant math is pretty easy when this happens … in most situations. But there is the whole problem of Opportunity Cost. Let’s say you are giving me all three of these variables to attend your conference [presumably to speak] but I have to spend a complete day flying there, and a complete day back. That is really 3 days I could be billing people to work on their stuff. If the honorarium only covers 85% of a single day’s worth of billing, well, things start to break down a bit.

Fear not though, the math still might work in your favour if there is a good chance I am going to get new business from attending an interacting with the other attendees. This actually has two parts to it. First, you need to know who your target demographic is. After 3+ years at this, I have a pretty good feel on who I am targeting and the sorts of things they need to hear in order to get them to sign on. (New consultants are unfortunately at a disadvantage and I think this is a large part of the reason why they go to so many conferences in the shotgun approach.) You, as a conference organizer need to convince me that there is a match between my target demo and your audience. (Tip for consultants: check their sponsorship packages, they often include this information in there.) If there is a match, I might eat the Opportunity Cost and turn it into a Marketing Cost.

There is another variation of Consultant Math I have been tinkering with a bit recently, and that is the Sponsorship Option. This is advanced level math and should only be employed once you know your audience since it often requires more risk [in terms of outlay of money]. Upon successful completion of this math you end up sponsoring a target conference [or event association with it]. For instance, the Consultant Math with Sponsorship Option looks quite favourable for Pycon or php[tek], but is pretty abysmal for CAST, Star*, STPCon or even, ironically, Selenium Conf.

I explained Consultant Math to a could non-consultants today [including ish a conference president] which is usually a sign I need to blog about [my variation] it.

So I’m in a pitch contest right now, and easily the biggest outcome is to switch me mentally from ‘talking about my app’ to ‘building my app’. And part of that shift was to got to TorontoGROWtalks last week. Waaaay too much stuff to absorb. (And thank-you startupnorth for the discount code!). Notes are as follows…

Brant Cooper

• took 3 minutes to mention FAKEGRIMLOCK
• Innovation: Disruptive, Sustaining or Rippling?
• hockey stick growth curve is an inverse mullet
• disruptive organizations optimize for learning
• sustaining organizations optimize for execution
• pre product fit, you are pushing the product on the market. after product fit, market pulls the product from you — I’m pushing now, need to stop that, and soon.
• first vp of sales needs to be able to sell without a demo — I don’t look forward to hiring sales.
• figure out your marketing, by going out and sell
• product creates the buzz, marketing is about amplifying your buzz
• you are not ready to market until there are things in the top of your sales funnel
• how do your measure a ‘passionate user’? figure out how to measure satisfaction and then passion
• if you have sharing, measure sharing since its an indicator of passion

Mike Meltzner

• product ownership isn’t an authority, it is a responsibility
• voice decisions the rest of the group has already decided on
• Startup stages: a comparison of 3 models — Marmer stages was mentioned
• job of ceo is to say same 3 things to everyone outside of the company (Speak the vision. Keep the tank full. Build a team). job of product owner is to say same 3 things to everyone inside of the company (important thing this month, thing we’re ignoring, where we are going)
• be in everyone’s business everyday so they know to include you in decisions
• default to no — but help me to help you convince me to say yes
• no — for now…
• who is handling the project — starters, or finishers?
• unsuccessful product ownership involves handoffs
Kate Rutter
• was an updated version of
  
• 
• ux != ui
• ui = delivery mechanism
• ux
  • a mindset
  • experiential payoff
  • inspires the right kinds of ideas
  • guides decisions
• if people are not going to pay for it, you don’t have a business, you have a hobby
• make decisions intentionally
• startup workshops
• if you cant have one user being passionate about it, how do you plan on having 1000s?
• ‘you dont have a product box, you have a product sieve’
• the market will give you permission to succeed
• customers [give you money] vs end experiencers
• cohort watching is useful
• there is nothing better than being schooled by your product
• each stage of the stack has its own ways to test it
• you should be okay looking like an idiot, because this is how you learn

Laura Fitton

• is there any conceivable world where someone would pay for this blob of marketing
• be useful
  • relevant to your user
  • relevant to your product
• start responding to how they make decisions
• its not spammy feeling if it is properly segmented
• HubSpot Academy
• will customer’s thank you for your content?
• hits don’t count; conversions count
• ‘them’ vs your ‘them’
• ‘smarketing’ — combination of sales and marketing

Scott Kveton

• creation stories should all be like urban airship’s
• ‘more of a feature than a product’
• its not lying, its selling forward
• think hard on pricing and packaging
• you really /do/ need to listen to customers
• customers will direct your business far better than you can
• outgrew ec2 within 3 months
• torn down and re-built tech 3 times

Dan Martell

• to have a hockey stick you need to have the flat part
• as soon as you truly understand your core product, get rid of everything else
• you need to instrument /everything/
• know your baselinesactivity streams
  • curious
  • casual
  • core <--- pay attention to these ones
• use in app surveys
• know your funnels
• unless you have core, don’t do this…
  • opn (other people’s networks)
  • shareable moments

Michael Litt

• solve the problem the customer has, not the problem they think they have
• do not trust the data, talk to the customer
• metrics only work /after/ you have product-customer fit
• everything at the start should be outbound
• ever developer should talk to customers

Mark organ

• most important ingredient for founder or investor: conviction
• ‘how does cookie monster mean capital’?!?!?!
• you need to have deeper knowledge about things more than anyone else
• to bootstrap
  • conviction
  • microniche
  • serviceize (charge for anything)
  • high pricing (multiply by 3x – 5x your competitor)
  • systematic scale
• to raise money
  • conviction
  • beautiful story
  • abp (always be pitching)
  • get feedback and connections
  • firm, but coachable
• the best way to get a canadian investor is to get an american investor first
• you do have spend time on planes to raise money

The Call For Participation for CAST 2013 is out and includes

We would like to hear your experiences, stories, thoughts, observations, demonstrations around the lessons that you have learned in Software Testing, as well as how these could influence the way that we approach testing in the future.

And I expect a lot of interesting experience reports from interesting people (it is CAST after all). But how much really, really, new stuff will be added to the craft. I’ll be my normal cynical self and suggest that it is likely not as much as one would hope.

What I would love to see is a CFP that looks something like this.
We would like to hear your experiences, stories, thoughts, observations, demonstrations around the lessons that you have learned outside of Software Testing, as well as how these could influence the way that we approach testing in the future.

My talks a couple years ago all fell into this form. Kids in Armor and Testing Inspiration When You Least Expect It are both examples of what I want to hear people talk about. I want to hear Alan Page discuss how Orchestra composition helps him test better, how Ben Kelly tests better due to years of thwacking people in the head with bamboo, etc.

I also want non-testers to be brought in as the keynotes. Sure, I enjoy listening to James, Michael, Cem, Matt and company, but if you are keynote-ing, you are up against an astronaut in my ranking scheme (Keynote vs. Track). Now I am a baseball fan so opinions are skewed but I think the Garfoose or Shawn Green could also be great. Though they likely cost more since its an actual speaking gig rather than just the prime audience grabbing moment. Or Mary Robinette Kowal about puppetry. Or a Buddhist monk about meditation and breathing. Or. Or. Or.

That there is a speaking circuit where one can recycle topics is a smell I think …

… and another smell is that I essentially wrote this same post back in April including some of the same speaker suggestions; The ‘Un-Testing Conf’. That’s just silly. I should do some work…

Speak Up! is the latest of Jesse Noller’s community-oriented projects. [I’m pretty sure he has cloned himself to do all this stuff.] Having sat in many ‘how to give a talk’ talks (meta!) I’m amazed how often people focus on construction of slides, the narrative and practice (feh!) and forget the most important thing.

BE YOURSELF!

I’ve been saying this for a while, but this paragraph from Cheek was my hero sums thing up well.

Later that season, Cheek would give me the most important piece of advice anyone has in this business – Be Yourself. It’s easy to lose that once you get close to the pinnacle of the profession, to try to change who you are or how you do what you do in order to impress people or to make your way up the ladder that much easier, but Tom told me squarely that there was a reason I was in that booth with them and it was because of what I’d done on the way there. That my success was based on how I went about my work both on the air and off and that any future success would be based on the same thing.

Pulling it back to speaking, people want you and your content not something and someone else when they select you. Don’t change. Even if that means blatantly ignoring cultural norms. For example:

• When I did Set Course for Awesome I was warned that having cussing in the deck could be offensive to the audience. Noted. Did I change it? Not a chance.
• If I am speaking at your event I’m going to wear what I am comfortable wearing that day which is likely to include some sort of snarky tshirt. Looking at some of the photos from Justin Hunter who is over in India at a conference today the audience is in jackets and ties. I don’t think I own a jacket and tying a tie is an exercise in hilarity.

Also, if you put a mic in front of me, you are going to get snark. And opinion. Because that is me. That’s what you get. Anything else would be dishonest. And being dishonest to your audience is not a good way to engage them.

Yes, I think that slides that have fewer words are better in general and that you should tell a story when behind the mic. But if that isn’t you then don’t do it. Be yourself.