Frame it
It’s been a while ago since I last wrote an article. I started joining a board in 2017 and was quite busy till then. Today I want to share my main lesson I have learned in the last 3 years – frame it to win it.
What is framing?
We all have different or nearly the same opinions and we all want to find “the north star”. But the way how to get there may be different and the way the north star looks like too and whether it is north or south 😉
Framing means getting everyone on board regarding the frame , the boarder and the limitations and the applicability of the one thing you want to achieve. Having done so you have made a huge step forward. This does not necessary mean that the road to success is now free to ride but having framed it correctly means you have achieved a certain type of alignment and you can go forward and avoid fruitless discussion during the kickoff meeting.
When is framing necessary?
Anytime, every time, every meeting is a chance to frame correctly. Generally saying: the larger the organization the more you have to frame or the higher you are in hierarchy the more framing effort is needed (As a fan of flat hierarchies or even hierarchy-less organisations I recommend not building too much hierarchy). You can set the tone, you can set the frame but having framed it correctly with all your colleagues and peers is much more satisfying and has a higher chance to succeed.
Why is it needed?
We are all humans, we want to interact, win, bring our best in. The more purpose driven, the more strategy driven the less effort may be needed. But as we are humans willing to interact and engage framing will always be necessary. Get your brains on board, show what is possible, achievable and what we should avoid. Kick the shit off and make it working. The more alignment, the better the initiative is framed, the clearer the direction.
What comes next?
There is never an end. There exist framing technologies and tooling and some do bring in their own skills and have some kind of natural behavior regarding framing. My personal tip is to strengthen your framing skills if you want to achieve something good or great.
Company Hackathons
In one of my last blog posts I wrote about hackathons in general and what you should care of if you plan to invite externals (only). Organizing an internal hackathon only is somehow different with regards to drivers, motivation and resources.
The difference of internal and external hackathons
While an external hackathon is often an invite to others with similar/same interests to participate in some kind of joint co-innovation effort with (free) food (see also this wikipedia entry) an internal one is somehow different:
- people know what you are doing already, potentially no need to explain the company goals but maybe biased as well
- free beer and food is potentially limited
- it is more about fostering the innovation capabilities of your crew rather than getting inspired externally
- you have to rethink how to reward accordingly
The 3 models of internal hackathons
Generally speaking there are a few different ways to enable hackathons inhouse:
- Developing a one-time event and reward with budget and resources to develop further and create a first prototype
- Developing continous hackathons focussed on creating customer value
- Developing continous hackathons focussed on solving problems, getting rid of legacy, fighting for a topic (eg. simplicity) or learning new technology
All of them are valid and vivid options and may be important tools in the company’s innovation toolbox. Anyhow all of them differ in how to set them up:
1.) One time event
Definitely I would never recommend to make a hackathon a one time event but let us have a closer look on it (and hopefully decide to make it an annual event 😉 )
The aim of such an event is mostly to foster internal innovation capabilities and capacities and get some special reward. Without reward it will be a nice event only and the reward should not be a bonus. Think about Daniel Pink and his book about motivation. What I have learned is a great bonus and reward is getting free time, a team and some budget to nail down your hackathons result and create a first PoC or even more. Don’t grant free time only. Free them up from daily routines, create extra time and space for them, let them be “their own boss” to solve the problem. A good reward is something like:
- the best idea gets 3 people and enough money to go beyond PoC (eg. 30k Euro in digital space)
- the 2nd best idea gets 2 people and some money to organize and manage the PoC and start thinking about how to go further (eg. 20k Euro in digital space)
- the 3rd best idea gets 1 resource and some money to be able to go for the PoC if everything goes right but will need more personal effort to get things done.
What you need to do too is to let them be as startup-like as possible and don’t confront them with enterprise barriers (eg. you have to use SAP as we use it internally). Let them be as enterpreneurial as possible.
Finally one important remark: If you decide to go further than “just” the PoC you have to contemplate on how you can reward them further. A good hint would be like xing did with the xing labs naming the origin of the feature released. (It’s not about money)
2.) Developing continous hackathons with focus on customer value
May it be hack days, weeks or special weekends, bringing together and let them explore without corporate control is a very unique experience and allows you to make use of the innovation potential of your employees. Be prepared: without proper reward it may become a one-time-wonder.
What we figured out during running hackathons is that the best reward you can get is that your idea gets implemented. So we ensured as the corporate leaders that at least 1 of the top 3 gets implemented within the next 5 sprints and are willing to do even more. Mostly it was even more because employees understand your product and market and often know upsell potentials better than you, even if they are not a sales or product expert. You will experience a lot of surprise and please let people know and take part on your enthusiasm. Regular hackathons without the backing of the leadership team are worth nothing. Even the idea to have some fun or do some crazy stuff, ‘act like a startup’ will die immediately without proper reward and recognition.
3.) Developing continous hackathons with focus on solving problems
Similar to number 2 but slightly different with regards to the goal, maybe even more dedicated to a single team than a mixed effort. To help people getting rid of problems beside the daily routines dedicated hackathons to solve internal problems can be a good problem solving path.
Always share a topic, don’t let them do what they want and do not allow single-person actions. We figured out that e.g. simplicity (everything that makes your or your colleagues live easier), elasticity (everything that let us react automatically and properly on changing user demand) are pretty good examples, allowing space to develop and grow.
Again – and repeating – don’t forget the rewards and recognition. If you want people to participate and engage, be passionate please set up the right reward system. Again, mainly not money, recognition, being named as the origin source, or some special treatment may be way better than anything else. Create a demanding but fair jury, allow them to present properly and applause. It is the free extra work of your employees, don’t take that work for granted.
Conclusion and remarks
I would always propose to start with some hackathons. Beside creating value or solving problems you normally don’t have time for it is another great method to bring people in touch, let them form teams and learn the team mechanics of your department. You will be surprised seeing people work harder and longer you would have ever expected.
I personally got in touch with Cocreation while reading Chesborough’s book. It is fully understandable that no company can own all talent and should make use of it by doing co-innovation and co-creation. Hackathons are a good tool doing so.
We should not forget to not only foster the wisdom of the crowd but foster the wisdom of our crew too. This is why creating internal hackathons is equally important than external ones but often forgotten or canceled by daily operational business pressure. Let us change this and make use of the talent we have infront of us.
From innovation to execution and back again
Innovation is creativity plus production. Simply said. Said so, what happens if your organisation learned to execute and driven by the successful delivery lost to innovate? What can and should you do as a CTO if your company still is innovative but Technology stuck in execution and delivery only, so likely missing opportunities offered by the ongoing innovation in the tech space?
Most firms don’t succeed as they cannot deliver, there are more ideas out there than executed ones so it seems like execution is a very important skill. But a skill alone isn’t enough, there isn’t just execution or just creativity. So how do you get back a good balance without risking your delivery performance? Several ways can be figured out like
- an R&D department
- external innovation
- rotate innovation team
While R&D is the “old” way with lots of books you can read about it and good measures like the ratio between R&D expenses and overall revenue it may not work with every organisation. The more agile you are, the more self organized teams you support, the less you want to have a department being responsible for the cool new stuff. If we believe in stuff like self organizing teams, Daniel Pinks’s Drive and lean management potentially we will not go forward building a separate department with different rules, procedures, budget and team.
Getting in external innovation seems to be the easy way as it primarily needs money first but be aware, integration is king, otherwise the effect is zero. I’ve seen too many companies failing in integration and making use of the innovation potential. There are some out there managing it really good and absorbing new ideas, it’s in their DNA to get external people and ideas in on a permanent basis and adopt quickly. In order to do so you have to prepare culture and team to manage it properly. That may take some time and effort, not only money.
The rotate team is slightly different. Bring in another PO with a high level of freedom and start 1 or 2 innovation projects outside the ongoing product development cycle. Build a rough backlog and promote it to your dev team. Allow 2 or 3 of your devs to jump in (auction it) and work on it for 2-6 sprints up to prototype and promotion to your organization. If your ideas succeed and survive corporate review, integrate it in your daily routines and start another cool idea. If they don’t survive, conserve findings and learnings and start another cool idea. Whatever happens you havn’t spent too much money and effort but learned a lot and 1 or 2 ideas a year minimum should be worth going further.
Development should never take over product management but there are plenty of ways to influence, inspire and challenge your corporate product development. It is our job as developers to make the products happen. Developers are the one understanding and adopting new technology. The rotate team approach is one which helps your developers stay up-to-date, inspire the organisation and support your company in showing new ways to progress without the need of a separate R&D department.
Rotate teams work with 2 devs and a PO and they work with 5 or more teams too. It’s a question of how (lean) to organize and how to avoid a distraction of the execution chain. Eg. you may have to make sure that the developers joining the team will have to spend some extra time in coaching their former team to get their stories done. If you havn’t spent too much attention on shared knowledge before, for sure you would have after your rotate team journey. And it’s a great way for your developers to step up and show their passion and love of technology. An extreme version I have seen is that the guys working on the PoC were later named in the release documents. A great way of contribution and appraisal.
I hope you like the rotate team approach. Please share your stories, would love hearing more about the different approaches out there and how to manage agile, lean and innovation without managing different teams.
Hackathon Does and Dont’s
While wikepedia puts hackathons in the domain of computing only (see here), in my understanding a hackathon must be defined much broader and many examples show evidence of hackathons growing up in non-IT spaces. It is a timeboxed event where any sort of interested people try to build a solution for a given problem or try to create value on top of existing data, interfaces or anything else (e.g. Chemistry Hackathon). There exist plenty of websites like hackathon.io which offer a calendar of upcoming open hackathons. And most important to name is the uncountable number of internal hackathons giving employees the chance to promote and develop their ideas which would never see light otherwise. More and more hackathons are accepted as a useful tool of open internal and external innovation. Hence more and more hackathons come up, willing to embrace the power and genius of each participant.
But what makes a hackathon a successful one? There are some obvious ones like
- more than enough drinks and food (and geeks do not eat burgers and pizza only)
- a good work- and playground
- a clear, demanding but achievable goal, a real world problem
- passionate supporters and a not to homogenous group of hackers
- the story must go on (the end of the hackathon is not the end of the idea!)
While one m
ay wonder why adequate prices are not in the list because they are not primarily necessary if you really match the 4 rules. As you may notice those 4 are quite similar to what Daniel Pink thinks makes a team successful; purpose (the demanding goal), mastery (matching with others in playground) and freedom (the team is self organized). One should not forget how important an adequate amount of humour might be. Especially as pride and sorrow may change a few times during a hackathon. The longer it takes, the less sleep you have, the more humour (not sarkasm) is sometime needed to keep you going the last mile…
And finally one more word: the result of a hackathon is not a ready-to-rollout product. It is a bunch of ideas with a first prototype or even a little bit more. As mentioned earlier prices are not the goal of taking part. It is relevance and every hackathon organizer should ask him or herself, how each hacker can keep on contributing or how his idea gets acknowledges when it comes to a real product later on. There exist some pretty good internal hackathon stories which result in labs, where the idea can be used in real by end-customers and the inventors are shown on the labs page, official contributor lists and many more. It highly depends on what you want to achieve and within which context.
How does your project plan look like?
This plan should give you a rough idea, it may vary depending on your case. It was used for a roboter hackathon with external teams only (see robothon)
Weeek 1: Workout on the goal, which is achievable in 24h, not too easy, not too strong, take care on your audience. Think about what sort of Tech you will need to help them solving the problem.
Week 2: Check financials, if needed talk to potential sponsors, at robothon we asked for 100 Euro per team only, rest was paid by sponsors (which is quite demanding if you work with roboters). Think about what you may tell sponsors already. (We decided to write about the claim only (10 items, 10 meters, 10 minutes), not about technology and other jobs to be done like we wanted them to think about a business canvas too)
Week 3: Setup a small website and social communities
Week 4: Send invites to people you want to be there
Week 5: Allow teams to register, media work
Week 5-8: Collect all necessary info (T-Shirt sizes ..), print shirts, prepare location, food and drink, prepare space to relax, prepare room to play.
Week 9-12: Invite VIPs, Jury, sponsors, define criteria for success, enable online team voting, search for volunteers, photographer, video-team, organize post-demo party
So within 3 months a solid hackathon is organized, take that time, especially consider more time for the first 3 hackathons.
The hackathon day (24h):
14:00 welcome
14:15 Intro, rules, schedule
14:45 Show playground and working area
15:15 Unpacking
16:00 GO
22:30 Part Exchange 1 (allow the teams to change parts if necessary)
24:00 Midnight break
8:00 Part Exchange 2 (allow the teams to change parts if necessary)
14:00 allow public viewing for the last 2 hours if OK for the teams and if a hackathon with externals
16:00 LIVE DEMO
17:00 And the winner is …. and party 🙂
I will continue to organize internal and external hackathons. One thing you have to acknowledge is, you should truly try to understand what makes the teams successful and what motivates them to come back for the next session. We started working with a University team of occupational scientists in order to get those questions answered (Pilot study in German out there, ping me if you are interested). Do not forget, that a hackathon results in a lot of energy and a lot of work to do upfront. You are then paid by energetic teams, an incredible amount of creativity, fun and ideas. You get tons of leadership and group management insights and you get not only prototypes but loyal hackers giving their time and passion (for free) to you!
Enjoy and take care on your hackers!
Good experience, good habit – no team and plan – omg
Imagine you’re sitting in a room with plenty of serial C*O enterpreneurs with tons of national and international experience and after 2 hours you have to recognize that they simple don’t move forward. With each of them in a 1:1 session you could get all the arguments how and why to build the product this and that way around and how lean and bootstrapping should work and the experience of the past. All of them combined end in a “do not move forward” scenario. They are not overpaid, overfunded, ill of success. They simple don’t move forward, working hard and long but no true move.
I wondered what the reason could be?
Is it the wrong idea to follow? Simply not, the idea is genius, partly solved but still worth a try, it is ambitious but applicable and seems to be need on the market.
Is it the pressure of funding? Simply not, they got good angel money which should last for a couple of months and allow them to prove market and product fit and get first traction for the next round.
Is it missing focus? No, they are totally focussed on solving the problem, setting up structures and making the damn thing work.
Is it missing knowhow? Of course they will need to get more people in in order to handle all the edge cases if the MVP succeeded and no, currently they have the right talent on board in order to learn, iterate and if necessary pivot.
Maybe it’s the CEO? One may argue that it’s always the CEO being responsible for all gonna happen and partly you are right, because one key element is still missing:
They all built a plan – but simply said on their own. It is not the team, the startup’s effort to go forward, it is each individual’s effort to go forward. They are all so experienced that they simply forgot to build the leading team before. The compelling vision is there, the right people might be there, the team is missing and a joint action plan.
What happened next? 2 friendly advisors went in, discussed with them the great mission, stepped down to the next 30 days, created an approach and agreed on the action plan for the next 30 days. They pushed them hard to overcome the burden of the individual’s past successes and act as a startup team – a joint team, not a collection of exciting individuals.
Will it work? I simply don’t know, time will show whether one push was enough and whether they can solve the problem with the reduced amount of time and money.
What have I learned from that?
- Exciting people with tons of experience are sometimes necessary to push forward and to get next financing round
- Exciting people know how it works, thus start working immediately
- Exciting people still have to become a team before acting as a group of individuals, a startup is always a joint effort
- The CEO is the driver for the team creation. It’s not only picking up the right people. Leadership is much more!
- If one brick in the wall (the team) is missing, the best bricks will not help you on the short or long run.
- Exciting people must not be exciting leaders.
websummit vs. pioneers
Dear all
I will more and more use this blog to not only write about operational issues but more and more about what I’m doing and why and what my experiences are … here my first “new” post about websummit vs. pioneers which I originally posted on facebook:
I was asked by several people in the last few days what the better event may be and I truly struggled to really compare, but here are my hints and assumptions. I was on both meetings mainly in supporting crate.io in my role as board member and on behalf of my owns business:
- Pioneers is much more strucutured and organised
- Websummit are way more people trying to speed date for business
- Pioneers offers more and easier accessible info upfront
- Pioneers is more condensed and private during day, no long walks for lunch needed
- Websummit offers tons of chances to have fun in the evening, pubs were overcrowded and really good atmosphere in the city centre
- Possibilities and places to meet people are much better at pioneers
- The massive crowd leads to long waiting for registration, lunch and a lot places were overcrowded thus no chance to participate at websummit
- It depends on how you organise yourself but the permanent change of booth owners on daily basis made it somehow hard to get in touch at later stage
- Wifi was crappy at websummit same for gsm, lost some meetings due to loss of communication
- Pioneers is a real festival with spirit, websummit is a perfect marketing business with lots of people with the ability to connect adhoc
- Websummit seems to have more international speakers
Now the most interesting, I had the chance to step into four more high quality meetings at pioneers but 17 more adhoc at websummit and it seems like the more international you want to be the better is websummit (the more you want to go east the better is pioneers). Time will show which contacts evolved better …
Conclusio: there is no better and no either-or, it needs both of them. I personally prefer pioneers over summit, that’s s all.
Tom
Tom Peruzzi's thoughts on digital, innovation, IT and operations 
leave a comment