Lykkes du – så del med andre hva du har lært. Deler du, så lærer du og det tror jeg er en god formel!
Her er fem ting jeg har lært om forretningsutvikling i store organisasjoner:
#1. Finne flere personer som vil det samme:
Det er viktig å finne engasjement på mange nivåer som vil det samme. Du trenger støtte på høyeste hold, på ledernivå og 2-3 operative som motor. Dvs. at man må ha 5-6 personer som finner ut av at dette skal skje og bli enige om dette.
#2. Skille ut fra eksisterende tankesett og beskytte mot makta som rår:
Hovedargumentet for å skille ut er å beskytte funding og passe på at ressurser ikke dras i flere retninger.
Schibsted har mange gode eksempler på dette, eks. vis VG når de skulle «vinne» kampen på mobil, startet de et eget AS. I 2013 tok de det inn igjen siden mobil nå er blitt en så stor del og kan måle seg med avis delen. De skilte nylig ut VGTV og kommer til å føre det tilbake igjen når det er oppe å går.
Nokia kjører et super hemmelig prosjekt som skal rette opp skuta. Norsk sjef. De er skilt ut som et eget miljø, med egne budsjetter og med topplederstøtte gjennom at Elop og noen andre VP sitter direkte i styringsgruppen. De stiller nær sakt aldri i møter, men alle vet at de bare er en telefon unna om noen prøver seg på å stjele funding eller trekke ut ressurser.
#3. Utholdenhet og utålmodighet, på en gang!
Det er utrolig vanskelig å lykkes med nye ting!
Hva skjer om man er utholdende uten å være utålmodig? Jo, mange titalls, kansje hundre millioner kan være bruket før noen setter ned foten.
Det å finne beslutningstakere og «stake holders» som har akkurat den perfekte balansen mellom utholdende og utålmodig er sjeldent. Finner du en så hold godt fast i denne/disse!
Å finne miljøer som klarer å komme frem med «udødelige» ideer. Dvs, på tross av alle som prøver å rive ned, hindre, utsette osv. så klarer miljøet å sjonglere stake holders, produktet, marked og penger på en unik måte. Disse personen vet at om de feiler på bare en, så faller alt.
#4: 3D forståelse av terrenget du er i
I en 2D verden trer man inn i et terreng hvor du bare ser det som er rett fremfor deg. Du ser et produkt, en tjeneste eller en forretningsmodell, men du ser egentlig ikke så godt hva kunden egentlig prøver å få gjort, hvordan endrer dette vår posisjon i markedet, hvordan kan vi gi kunden mer verdi?
Hvorfor har droner tatt over krigsmarkene? Jo, de sparer potensielt krigerens eget liv, men det er noe mer her.
De gir beslutningstakerne en 3D forståelse av situasjonen, hva som er under oppseiling og ikke minst: Hva betyr det av endringer i planen!
Jeg mener man kan oppnå dette 3D bildet gjennom å bruke flere personer med ulik bakgrunn og erfaringer som sammen diskuterer og lager planer innen et gitt området. Disse må relativt raskt kunne settes ut «live» gjennom simulering og testing i terrenget – på ekte kunder. Gjennom dette kan du som tilegne deg denne evnen til å forstå ditt marked i 3D.
#5. Kontroll på NÅR
Kanskje det vanskeligste.
Når brenner det akkurat passe under beina på «stake holders»?
Når er markedet klart for noe nytt?
Når passer det for intraprenøren å ta egen risiko (kan jo miste jobben/posisjonen)?
Når har org nok selvtillit (det har jo vært noen fiaskoer i historien bak)?
Tror du lett kan finne 20 viktige NÅR faktorer og de skal alle stemme…..det er sjeldent, temmelig sjeldent, dessverre.
Deler du så lærer du og det tror jeg er en god formel!
Assuming that you have already invested some money in Bitcoin you need to decide now how to make them safe.
Bitcoins are associated with an identifier called an address which is an alpha-numeric string. Every Bitcoin address consists of a public key and every public key has a corresponding private key. With the private key you can prove that you are the owner of the Bitcoin address and you can sign transactions to spend the bitcoins.
If someone steals your private key, he has full access to all the bitcoin connected to that address. Needless to say, you need to figure out how to secure it.
Example of a Bitcoin address: 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj
Example of a private key: 5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF
Example of a public key: 0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
The private key and public key are stored in a wallet. Wallets can be either offline or online.
An online wallet is, as the name suggests, online. The private keys are on the internet. You must choose to trust a third party that takes care of your keys. You trust that they do not run away with them or get hacked.
The online wallet service inputs.io got hacked and their customers lost a total of 4100BTC.
I don’t recommend using an online wallet for any larger amount of money. It is more suitable for smaller amounts intended for spending because its accessible from everywhere you have an internet connection. One online wallet that has good reputation is the open source blockchain.info. There is another open source service called coinpunk.com that currently is in beta, but it has great potential.
An offline wallet is a wallet that is generated and stored on an offline computer to minimize attack surfaces. Offline wallets provides the highest level of security for your bitcoins. To get started, download a wallet application and transfer it to an offline computer via an USB-memory. There are many wallet applications, but the most secure and stable ones in my opinion are armory and electrum.
To be completely safe I recommend using a clean install of Ubuntu (remember to check md5 hash) with the network card physically removed. That way you minimize the possibility of having malware on your computer. An excellent in depth tutorial on how to do this can be found here: http://falkvinge.net/2014/02/10/placing-your-crypto-wealth-in-cold-storage-installing-armory-on-ubuntu/
As you can see it requires some technical competence to store your Bitcoins at the highest level of security. Even people that have the required background might be hesitant, simply because it is so time consuming.
But there are solutions to this problem. One interesting project is Bitcoin Rezor (http://www.bitcointrezor.com/). It is a hardware wallet that gives the highest level of security for Bitcoins, and is user friendly at the same time. Right now it is under development and the first beta version has been shipped. You might do good to get your hands on one.
In the meantime, you must figure out what level of security you need for your Bitcoins.
Interested in learning about Bitcoin? We invite you to join a Miniseminar on the 6th of march at 8 am in our office in Oslo. In 45 minutes you will get to know the “What” and “Why” of Bitcoin. Free to attend. Talk will be in Swedish, unless the audience decides otherwise. Check and subscribe here.
No spoilers: Based on Season 1. If you like it, I might derive more dirty tricks from season 2!
Wake up your inner entrepreneur – it’s time to disrupt yourself. By hauge2.
Take Kodak, Nokia and Commodore in their prime time, and ask yourself why your company is any different right now.
Getting enthusiasm about your ideas at lunch is one thing – getting the organization behind your mission to innovate, is another.
Disobedient innovation, or intrapreneurship as we prefer to call it, requires political skills: Any good idea in an established organization is also a threat to someone (anyone who perpetuates the status quo).
But you’re not an underdog. You’re Frank Underwood, ready to outmaneuver the opposition with political virtuosity, lean thinking and entrepreneurial charm.
Like the president, who unknowingly unleashes a monster when double-crossing Underwood in the first episode of season 1, established companies who hunger for continuation unknowingly unleash the entrepreneurs in their people. Preventing entrepreneurship is after all the cardinal sin of a technology company in its prime. Thank God entrepreneurs now learn to deal with the Washington in their companies.
Here’s how Frank Underwood would disrupt your company from within:
I’d like to protest against some general advice, by giving some general advice. Written by @hauge2.
Dave Kerpen’s post titled 7 tips to entrepreneurs is undoubtedly based on experience, and written with the best intentions. Even so, the more general advice about entrepreneurship I read (that includes stuff I’ve written myself), the more I ask myself what’s the value for the receiving end.
Example: “Believe in yourself” is an advice we hear often. I don’t think you shouldn’t believe in yourself, but there’s a problem: People who try and utterly fail also believe in themselves. At least believed. Such advice is a cliché.
What’s more alarming, is how easily such advice is misinterpreted and used in ways that was never intended. Hence, to avoid the pitfalls I’m sure the author of the original post never intended, here are my seven counter-tips to Kerpen’s 7 tips to entrepreneurs.
And please: Take this with a pinch of salt.
Tip 1: “Have an amazing support system”.
Counter-tip: “Don’t get addicted to confirmations from your support system”
Make sure you distinguish moral support from validated learning. Eric Ries talks about the entrepreneur distortion field – people who wish you the best will unintentionally give you false positives about your ideas: The people who fuel your ego are rarely the people who pay the invoices you send. Have a support system, but spend your time on real customer prospects instead.
Tip 2: “Expect utter hell, and you’ll be just fine”
Technical debt is not the only monster we have to fight – it has a hidden evil twin, as pointed out by Niklas Björnerstedt: Competence Debt. The rope of ignorance that binds our hands and suffocates us by fear so that we don’t dare to change the system. Technical debt makes change difficult because the structure of the system does not support it. Competence debt makes change difficult because we do not know the system well enough, what & where to change and what impacts a change may have.
There is an often neglected tool at our fingertips that might help us fight competence debt. Its name is – behold – JavaDoc. An example from practice: I have returned to a client after two years and needed to understand the functionality of a part of the system. And, to my surprise, I found my own JavaDoc providing exactly the answer I was looking for. A colleague of mine mentioned that I should get the award for the “most documenting developer”. But I don’t do it for fun or just to help my bad memory and to be nice to my colleagues. It is an important contribution to the fight against the ever growing hydra of legacy code. Next time you code, try to remember that you are not typing code, but fighting. As every fight, it is hard – but do not give up or the enemy will prevail.
Side note: Writing JavaDoc that helps yet is not too verbose and not too likely to get outdated soon is hard. Getting the right balance – neither too little nor too much, focusing on the why and the broader context and relationships instead of the changing implementation etc. is difficult. But it is worth it. Help yourself, help your fellow colleagues, strike the hydra. Write good JavaDoc.
PS: This post is about competence debt even though the title mentions technical debt, sorry for the confusion (even though they are two sides of the same coin). And “good enough” documentation, though important, is not the sole remedy, as well as developers’ lack of knowledge is not the sole cause of competence debt. Also, Niklas provides a more in-depth review of the technical & competence debt terms in Misunderstanding technical debt (tech. debt as evolving understanding [but not code] and crappy code). He wrote also A deeper look at Competence debt.
It’s been a hassle to integrate video conferencing into web applications. Sure, there are solutions available, like long running Skype and Webex or newer things like Google Hangout. What they all have in common are small universes surrounding the core product: Skype requires a signup and a friends list, Webex requires an executive deal, Hangout requires a Google+ account, and so on.
Thankfully, Telenor Digital addresses these limitations with their latest innovation project appear.in, and here’s how we’ve used it successfully in a recent customer project:
Helping Red Cross help school children
Norwegian Red Cross offers “Leksehjelp”, a voluntary service for helping school children with their homework. As of February 2014, they also offer a digital meeting point: Enter the website, choose what kind of homework you’re working on, and meet your volunteer in a video conference.
When my company Iterate was asked to develop www.digitalleksehjelp.no on behalf of Red Cross, our challenge was to connect children and volunteers using as few clicks as possible.
Secondly, we wanted to avoid any serious integration challenges. (We love a tech challenge as much as anyone else, but when working for the Red Cross you do want to keep things as inexpensive as possible..)
Even though the word consult comes from Latin and French and has nothing to do with it, giving estimates feels closer to conning than advising.
Naturally we feel bad about this, we do not want to feel like con-artists. We want to feel like we are helping and in response to the embarrassing emotion of guilt, we banish the problem to another realm where we do not have to take responsibility for the inevitable estimate gone awry. It really is a pretty clever way of making ourselves feel better about the estimates that we give. You may break out your inner maniac’s laughter now. Go on, you know you want to, it is all right; for you are in the company of maniacs.
This rite of banishment is performed through the powerful, almighty word; oft used and abused, terms like rough estimates, story points, units of work, or anything that is not a direct reference to Time, are thrown around. Time becomes the elephant in the room, everyone is thinking about it, yet no one is addressing it. What context does this deep need of maintaining wiggle-room remind us of … ah, yes. The art of conning and the obsession with never giving absolute answers. Or, in the words of Bruce Lee, “Be like water, my friend”.
Surely every developer has had a discussion about what e.g. a story point actually represents. This is the bed we have made. Far too much effort has been put into creating abstractions in order to give the perception of more accurate estimates of length. That sounds like a paradox in itself; we make something abstract, Time, and make it more abstract, Points, in order to talk about it as absolute.
That discussion about what the estimate means is a metaphorical train running full-tilt which if you get in front of, or find yourself in front of, you will have a Bad Time™. Eventually though, what happens is that everyone just kind of stops talking about it, externally accepting that it represents nothing.
Internally however, the conflict rages on. Every time the question, “How long will this take?”, is raised, an attempt to estimate length through conversion of abstract terms into some-what more concrete terms is made. This can lead to near Olympic-level mental acrobatics, which while impressive, is completely useless when pressured for an explanation on how the estimate was arrived at.
Especially a few weeks down the line, when the explanation of the acrobatics makes no sense at all because one or more factors changed between then and now. Much like dodging a bullet you have made an assumption about being fired in the future but never was.
Maybe we should strive to be plasma instead, existing in a state neither fluid nor solid. Flexible estimates? Fixed estimates? Pshaw. Plasma estimates!
Though if history has taught us anything, it is that just changing the terminology will not work in the long haul and this fanatical devotion to avoiding Time as a unit for measuring duration is actually more harmful than helpful. The nature of an estimate is that of a guess, so instead of making us better at guessing, which we have been trying for a while now, perhaps we should not make important plans based on guesses at all.
Consider this. Someone asks you how long it will take to drive to Paris from Oslo by car. You think about it for a while. You study a map. You create a mental model of the problem and apply your own unique problem-solving framework on the model and prepare your solution.
You are now ready to present them with your estimate on the trip’s duration, and so, you look them in the eye and say,