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.
Focus baby
(thanks to pixabay)
There are tons of books out there claiming the importance of focus. Hence it seems like it is not as easy as written. After having done more than 150 due diligences in the tech space in Europe, having fulfilled 4 Interims CTO positions and now being board member of a digital marketing tech company I still do read such posts and books about focus. Why? Because as Sean Covey has written in his book about the 4 disciplines of execution we have to differentiate between urgent and import.
Eisenhower knew about that already and there is a matrix named after him which easily makes the necessary action transparent:
And I assume everybody could name a few more. The important thing is:
You need to focus yourself in order to be able to focus the organization!!!
Reading a book – fine, reading a blog and listening to a podcast – fine too. You cannot demand focus without being focused. So how do I focus myself? Simple said, use the matrix above 😉 But that is half of the truth. How do you know what is important, which battles need to be won to win the overall war? Yes, it’s strategy time again but in a more lean way.
Strategy is team effort!
I like to share what I have learned in a company: Build a grand vision which allows people to connect to, become passionate and be addicted. How to do so? Let it be their strategy. Strategy work is no longer the CEO thinking in the dark. Foster a common understanding there to go (with special thanks to Laloux’s Reinventing Organization) by letting all participate and no, it is not a basic democracy, it is a shared believe system. If you have done the strategy work each department will need some time to think about how to best support that strategy and then please let everyone know, what the departments think they need to do. The larger the audience, the higher the commitment. (we have tested strategy know-how before and after that and reached incredibly high scores). It is then the leaders work to support the organization to focus on the strategic direction and get rid of everything else which is distracting, produces friction and does not support the path towards success. As we always have to face day-to-day operational duties you will get some friction and reluctance anyhow. Even if you have a good understanding of the strategy and the tactics to make it happen, still there are plenty of reasons to stop, wait, slow down or turn the wrong direction. This is where discipline and focus come into play again.
It is often no fun for nobody to meet on a regular basis, share the goals and metrics and talk about next important steps but without discipline and focus you will either have a lucky punch or run into really big troubles. Either you do waterfall or agile (which is strict too) you will need a methodology to focus on (maybe I use the word too often).
In order to achieve that routine towards success I do prefer 2 methods, the older “Get things done” method or the 4DX mentioned above already. While “Get things done” is build on “Set focus” “Set time limits” “avoid perfectionism” “realistic expectations” and “update the way you work” the 4DX is similar but different. 4DX wants you to set 2-3 WIGs (Wildly important goals) max for each department and then you have to find correct lag measurements (what you want to achieve, e.g. getting down to 80 kg) and lead measurement (what leads you in the right direction, eg. movement per day, calories ..). To ensure success the affected team(s) meet on a regular basis and discuss the numbers which are open and transparent and ideally the dashboard is generated by the team members itself. The lead and lag example is easy for weight reduction. It is not that easy for distributed development or other IT related tasks. Being a friend of Daniel Pink and Frederic Laloux I want to encourage you to let your team think about the measurements, it is always astonishing how creative your own employees are if you just let them grow and flourish. And again, you and your team need to be focussed to get the right numbers. Being the leader of a engaged team which is delivering on high speed you need to be really focussed in what you are doing ,how you tweak the team and how you support the team.
A good team has the right to have a good and focussed leader!
Mastering Excellence in Technology
(thanks to pixabay)
I visited a company and talked to the CTO. Like many he complained about skilled people leaving the company as they could not become a manager post being a senior developer. I simply asked why tech career will stop after becoming senior and his answer was something like “it always was Junior-Regular-Senior”.
I’ve seen so many companies failing in letting become technologist real masters in what they are doing and I assume it happens in Marketing, Sales and other departments too. But simply said there is no reason doing so. There is no rule that after becoming Senior you either go down the management path, stay as Senior or leave to become Senior somewhere else.
What I did in my last few jobs as Interims CTO or advisor to the company was establishing a path to mastery beyond Senior. It may sound obvious to go further and create new profiles like lead developer (architect, operator, QA engineer …) or principal. The question is, how do you manage to move them towards those goals and what kinds of additional freedom do those roles imply.
When I started establishing such rules I was mainly motivated by Daniel Pink, the author of “Drive”. In his book he writes about the 3 pillars to get into a flow. While freedom in team, task, technology and time is one of them and purpose of the organization the other, the 3rd one is mastery. He asked the simply question why skilled and well-paid developers leave office to get home coding open source for free. His answer was beside the 2 others that people always want to get better in what they are doing. May it be coding, playing guitar or painting.
Next I figured out that mastery in technology can be tricky. Who is the better engineer to become lead developer. The one who knows everything about technology or the one who knows a lot about technology and is really good in supporting and educating others in the organization? The answer is: Both are essential for a working team. So figure out, how to best address their needs, desires and interests!
Finally we asked ourself what the benefit beside payment could be. The answer is freedom and responsibility. Freedom because you want them to become master. You only become master if you have a good trainer/teacher, the right environment and the ambition to become master. The more rigid the system the less the willingness was our approach so we defined levels of freedom. The better you are, the more responsibility you should get. There is tons of responsibility in a tech team without the need for a manager. Architectural decisions, devops design, assistance in product tech design, representation of the company on tech events and much more.
As a result we created an excel sheet showing everyone what we expect them to do in order to get promoted. It is a 2 path approach with the extras of freedom and responsibility. I learned from different organizations that it helped them in mastering technology. So I decided to publish it for free. Feel free to use it, adapt and change it. You are very welcome to send back feedback or your version of a tech mastery plan.
Download as XLS: skillmatrixv04generic
Startup Failures – my best of
(Picture thanks to pixabay)
Tons of wise people have written about it already and lists and books can be found online and offline about that topic. I had to prepare for a speech about failures and how to mitigate them. This is how I started that list and it got longer and longer the more I thought about my founder’s journey and the companies I was allowed to follow and advice quite closely. This is mostly “my” list, even if you may find some failures which sound familiar to you. And yes, it is just another list, but anyhow I hope it may help the one or the other … It is an unordered and unpriorized list, any failure alone can risk your business and I havnt’t found “the failure” expect running out of money and not filing for bankrupty.
Trust – No Trust
You have to trust to grow but how to manage it properly? Why KPIs are somehow good to know whether you are on the right track, but don’t over-optimize and micromanage. Just trust is dangerous and risky, depends on how good/long you know the person and even if it is your best friend: create a procedure to divorce in the beginning.
My learning from KPIs: make sure you have some as a parachute, don’t overemphasize in the beginning but formulate measurements which help you verifying that your company is on the right track on different levels. Don’t evaluate 100 numbers a week, have a look at a few once which indicate success and proper commitment of your team.
Almost Done
Only deliver then you are done. Whenever we were under pressure delivering and accepted an almost done we were punished later. Not financially but with way more resource allocation and more, hence delaying other projects. The spiral of death of almost done is hard to attack at a certain point. The term technical debt is wellknown, Ben Horowitz came up with the idea of business dept too. Everything we don’t do right now creates some kind of dept. Accepting the fact is sometimes ok, even necessary but be sure that it will have to be solved at a later time.
The right timing
It is not only about the right team with the right product, studies know it is timing mostly. (see https://www.entrepreneur.com/article/248536 or this post on forbes.com)We started our subsidy in Switzerland 1 day before UBS declared ist financial loss at the beginning of the 2008 financial crisis. That definitely was the wrong timing, even if we did anything one would advice upfront: We hired a local talent, well established, we secured cash-flow for the go-to-market, we had tons of meetings upfront and started with a nice party and a lot of warm welcome). Honestly, we shut down after a year. An end full of horror is better than endless horror 🙂
Niche versus I love them all
Too broad is a big problem. You think you have to to get clients but a) your clients don’t find you as you are too broad and b) you cannot tackle all markets at the same time. You can grow any time later, but start in a niche, get some market share and acceptance and then grow. Have a look at Peter Thiel’s book “From zero to one” and his support of the idea of starting in a niche, naming Tesla as a perfect example. At the beginning you often fear loosing customers by not offering them a package dedicated to the exact need. In one of my advisory jobs I often got confronted with discussions like “Are we SaaS or an integrator?” or “Isn’t the customer wish more important than the roadmap?”. The authors of basecamp once asked if you do exactly the thing your customer wants and the customer is leaving, how does your product then look like? A niche allows you to prove with ok costs and to learn how to best phrase what exactly you are doing. Take the chance.
The right bonus model
Think about what currently drives you most and how to incentivice your employees. If you want to grow, build a growth model, if you want to innovate, foster innovation. Don’t try to incentivice too many initiatives at once and create a system that does not hinder innovation. Think about what Daniel Pink showed us about reward models, especially for knowledge workers or go through Sutton’s and Pfeffer’s book about management myths about that topic first. Choose your model wisely, the model will mainly influence the direction and strategy of the company.
Know your customers (segments)
That tackles the niche problem too. You should not only focus on your market, focus on your customers too. How can you solve a problem if you don’t know your customer segments pains, gains and needs? A Value Proposition Canvas as an example, talking to the customers makes real sense. Lean StartUp is not only a book, there is a lot of truth in. Only if you know them, you can help them. We thought we can tackle another segment but it didn’t work. Why? We simply missed some insights about the mechanics of that segment.
Living on the cash flow versus living on investors
It’s your decision. We wanted to grow by cash-flow only and we succeeded. Maybe it was slower but it was successful. Others I see live on the cost of the investors, the money you get you have to manage carefully. Don’t save the money, money on your account is somehow lost money, it must “work”. And please avoid status symbols, all money should be dedicated to your most important tasks, to create and foster business value and gain a relevant market share.
Public funding is not your prime customer
When you start your company you often intend to get some extra money via public funding programmes, especially in Mid-Europe. It’s often seen as some funding tourism: young startups going from one governmental agency to the other and the focus is raising the money, not getting customer traction. Make use of governmental programmes but take them as they are: programmes to support you, not to feed you and keep you alive.
The wrong board-partner may kill you
I once partnered with my later successor. He was a well-known founder, very senior. We were then 3 in the board and we made decisions fast. Everything seemed to be fine. My 2nd founding partner left and I had to figure out, that decision making wasn’t his prime focus, it was ours and he participated. We stuck in decisions, became slow. Employees recognized the change in speed, left. Finally I left too, agreed on some money and an earn-out. He thought it was me and he knows it better and within 2 years we lost all customers and a multi-million Euro yearly revenue and the company got bankrupt.
Culture is fragile and volatile – take care on hiring
Everyone you hire is part of your team and affects your culture. If one doesn’t fully fit, then it’s not the team to change, it is him/her. You as founders mainly influence and build culture first, be aware of your job as a role model. In times of growth and emergent need you may not think about that (like I did). Post mortem it was always a failure if I and the team weren’t 100% OK with the hiring decision.
Culture is fragile, especially at the beginning, take care on it, manage it properly and align your passion, culture and strategy.
Right time to hire
When do you hire? We tried to hire on demand first, knowing it will take 3-6 months to get the right person, we built prediction models and it didn’t work out. Finally we thought about the book “From good to Great” and the “First who then what” and starting hiring any talent we find and when find the right position internally and from one day to the other we succeeded. I would strongly recommend to always have hiring running and if there is a real talent, get it in board and work out, how the talent may best help.
Documentation and processes
You need as less and as much as possible and feasible. Whenever something becomes repeating, automate (hence build a process/routine). Take care, when you grow. Processes may be used to delegate work which shouldn’t be delegated 😉
Exploit your scare resources
Your scare resources are your most important resources, do anything to protect and exploit them, this is there you may need work procedures and processes. Think about how you can best exploit via sharing, don’t create pools of wisdom.
Time is not the right measurement of work
It’s all about commitment and delivery. Relearn and adjust properly. Simply said, but execution is crucial. Built it now several times, still sometimes falling into old habits. If the guy delivers what he promised and agreed on then don’t take care on what-else he/she is doing.
Summary
Any failure is a chance to become better. First make sure to survive, than save the findings and (re)act accordingly. Rethink Peter Sutton saying “Reward success, celebrate failure, punish inaction”. Very wise words, keep them in mind, have fun, rock it, crush it and love your family.
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.
Becoming agile in an “I think I’m agile” environment…
Imagine you start a new leading job in a company which calls itself agile. Later on you recognize that even if they somehow do some agile stuff they are far away from agility. The mindset is generally right, skill level high but collaboration with business broken, push and pull in parallel, tools over collaboration and way more.
So where and how do you start? Literature is much more focused on how to start becoming agile than turning around such an organisation. Mindset, know-how, skills and attitude are ok but to be challenged …
Now, a few sprints later we can share some of the insights we gained during our journey and yes, we were successful 🙂
- Start with a spontaneous break! From one day to the other we simply informed everyone that from tomorrow on we will work the following: review and retro every second Friday, planing 1 and 2 every second Monday, daily grooming and bi-weekly sprints. Knowing that we pushed hard, it was the ultimate challenge to switch from one day to the other. There was simply no time for long discussions, collaboration was down, lots of complaints from the business and the simple need to get back to delivery mode. I know that some of the devs hated us for doing so, radically introducing transparency isn’t easy but if you have just one silver bullet please consider it carefully and this was our silver bullet.
- Stay near the teams, moderate and coach but don’t take over
For the next couple of weeks we did our very best to stay near the teams, helped them in getting up with the process, getting their buy-in. We helped them with one-on-one and team sessions, but it was up to them to buy-in and adapt it according to their exact need. Everything was ok as long as it didn’t conflict with our main goals: transparency and predictability. - Physical boards
We love confluence and jira, yes we do. Even so we decided to track on epic and story level in Jira but do our daily work on physical boards. The reason is simple: The only thing our business is interested in is getting stories done, no matter how we achieve it. And we wanted to avoid business asking questions on simple task level or starting getting nervous if a task isn’t done in time. So simply for resilience and overview we organized that media break. We started with task planing on the board. After a while we adjusted slightly like:- when a task isn’t done in one day (we broke it down like that) we put a red dot on it so it becomes visible to all of us
- we learned to break it down in single-day tasks. Even if that produces a lot more paperwork it is crucial for success to get doable and trackable pieces of work.
- Get out of the daily routines
Once you recognize things moving in the right direction get out of daily routines. If you see grooming going the right direction, let them groom without you, same for retro and review. Just step in occasionally to quick check direction. Trust your teams – if you don’t trust, switch back to waterfall. No agile approach without a certain amount of trust… - Wait with KPIs
There would have been tons of interesting KPIs but first they hinder you from learning and from reaching a certain flow-level. Start estimating from day one but don’t take care on burn down for the first 3 sprints. As long as the team is still experimenting with estimations it isn’t worth too much. Look at stories completed only and check (5 why) why some stories didn’t happen even if we committed to deliver. Look for qualitative signals indicating you right direction or not. After 4-5 sprints start with simple, easy to maintain KPIs. Otherwise you will not be able to fine tune later. - Get stakeholder’s support and willingness to change!
Looking at our org-chart: our POs are not part of our tech organisation, they are within their product-focused teams. Imagine you implement a process which affects all teams (as they all rely on you)… We do spend a lot of time on grooming, lots of hours day per day. Everyone is allowed to join, so even if grooming takes just 30 min (timeboxed) getting 10 people in results in 35 hours a week on grooming. Is it worth the effort? Yes it is, stories get better and better, devs understand business way better than a few months ago and business starts understanding us, our needs and constraints. Agile development is agile product development, it’s not a tech process only. Without the understanding of the problem and the acceptance of your stakeholders you are not able to change anything. So get their buy-in and make sure that they adopt as fast as you change. Inform them pro-actively, there is not enough communication, just too little. - reward success, celebrate failure, punish inaction
Robert Sutton once said that and he is 100% true. So how do you change without making failures? That’s simply not possible so think about how to make failures a success. Whenever you somehow fail, don’t blame others. Think about why you failed and how you can avoid that in the future. Spread that knowhow and then celebrate the successful learning. But don’t forget to reward successful actions too, go out for team dinner, acknowledge new learnings and small successes too, let people know you see and appreciate the progress. And really punish inaction. If you want to strive for success you need people who are willing and eager to go the extra mile, complete the work, adapt to changes. If one does no longer fit into that team and its framing conditions, than it’s not the team. Give responsibility to the team, if it is a good one it will filter out inactive or inappropriately behaving persons. If you see one being inactive and the team isn’t, than challenge the team, maybe they still have to learn a lot. - avoid mediocrity
If you push hard for transparency and predictability your team may be willing to undercommit in order to deliver properly. Without hitting the limits you will not become better. Push your teams hard but create achievable sprint goals. Don’t burn them but do your very best to avoid mediocrity. I would rather go for a slight over-commitment than an undercommitment. If the team is really willing to drive, they will potentially spend more time on delivering what they promised. Don’t forget, trust is the clue of agility. Devs trust POs to understand customer needs, POs trust devs to deliver what they promised. So keep a good balance, have an eye on your team’s performance and your team’s mood and either push hard once or give them some time to recover. No team can over-deliver 52 weeks a year! - Challenge their agile mindset
Challenge it daily, weekly, monthly. If they think they are agile they should at any time be able to answer why they act as they do now. Ask the 5 Whys and dig deep. Pray the agile mindset and live the agile mindset. Don’t expect them to act if you are not willing to change too. Group them properly, allow pair programming, foster collaboration and communication. Pin the agile manifest on each free wall, bring in real agile thinkers and let them discuss, celebrate agility, train agile routines and always remind them of the benefit. Let them explain agility to others (e.g applicants for an open developer job). Don’t persuade them, if one opts out it is his/her decision but they should understand any consequence too. Don’t push them to hard. If they don’t move ask them about their motivation to stay as is, show them paths to go forward, help them develop and change their mindset. Put more optimistic people in each team and only ask for a certain level of patience before they opt out. Anyone should be OK to try at least 3 sprints before he/she decides to opt out. - Get a neutral moderator in
Have one in the organisation who is not in an operational role. Call him moderator, mentor, coach, whatever but not any known scrum-name. That person is a super critical resource. His/her job is to get the buy-in from all parties in long-lasting one-on-one sessions, cleaning up the boards, doing sanity work, pushing for excellence. Don’t call it a scrum master, the role is much more. It is a neutral driver for success on a temporary basis. The one and only job is to get the push done, get the buy-in of the people and take care to not become an essential party in the story. This may be an ideal role for an external as long as the external doesn’t act like an external consultant, it must be a much deeper, personal, yet professional link between him/her and the organisation.
There is a lot more one could consider. To sum up one more essential for me: If people think they are agile, challenge them with agility, don’t adapt your new process to fast, let them tryout and learn before, keep the agile mindset and values in focus, go down the path with your team.
Dublin Websummit – Review
I was on websummit and pioneers festival in 2014 and did some comparison about those 2 last year. Even if I truly considered not going there again it somehow happened, that’s my personal review of summit2015:
- around 30k people is a lot, infrastructure was bad last year and didn’t become better over the year
- a mobile app enforcing social interaction is a good idea but doing so the wifi should be really good
- wifi was as bad as 2014
- no wifi coverage beween buildings and in the food court area
- more summits than ever
- an angel summit the day before
- the concept of allowing startups to show their portfolio/potential for one day stayd the same
- what really drove me crazy was the fact that you had to pay a 20 Euro extra for food, which didn’t include a desert at day 1 (changed the second day). Still, a yogurt, a bottle of water and an original Irsish Hot-Dog for 20 Euros is way too much.
The first impression was fully blown away. There was simply no way to go through an area with an Investor badge without having seen minimum 5 business cases 🙂 They really liked to engage, saying no to e-commerce didn’t stop them showing their hyper-cool shop.
Interaction at all levels. As meeting possibilities were as rare as last year people met all over the place, you could listen to business-case internals, numbers and pitching strategies even on the restroom. Summits as far as I have seen attracted a huge amount of people, some where as fulll as last time or even worse. The better/ the more known the speaker, the faster you had to get in.
My first impression after day1 was a smart “F*ck”, I really considered not going there the second day. My final thought after 2 1/2 days is:
- If you are a young startup still in finding your mode go there, talk to as many as you can
- If you are a startup, be there for one day at a mini-booth, take enough food and beverage with you, you don’t have any time to go off
- If you are a Product Manager, VC, Angel: use it for trend scouting, really useful and much better than google queries
Will I be there next year in Lissabon? Potentially yes, as a few of the companies I advise potentially will have their booth for one day. And yes, for trendscouting in 2016.
Btw: have a look what Felicity wrote about the event, really worth reading!
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!
Stakeholder Management of any sort of investor
my dear Startups, Enterpreneurs, founders, managers
There may be 10.000 of (operational) reasons why not to communictate wins and fails or any other obligation to the investors, backers, angels, … BUT confidence and trust is a value worth being protected. You may find a situation where you may need more money. You may need a business connection of one of your angels, you may like to let your backers spread a good word about your company and product …
It’s all about trust: as long as you are known as a trustworthy partner you will have a lot more freedom to act and react. Communication does not automatically mean collaboration, one way on a regular basis about all the major steps, achievments is already a good step forward. But imagine the following:
- you get investors on board
- you get backers on board
- your product is massively delayed
- you don’t communicate the delays
At some point people start connecting, bad customers with other bad customers, frustrated investors with frustrated customers and a spiral of anti-trust is happening especially in the phase where you need support from your stakeholders. That is the main critical point: You just get support if there is some level of trust. At some point money isn’t any longer the glue and you should never reach that point, at no time.
So to give you some short idea about what’s enough for the different groups:
investors, angels
- Milestones, state of milestones of main business activities
- Achievments, fails
- Financial situation, burn rate, months left to operate (conservative calculation)
- next steps
- Need for support
Investors want you to do a good job, to increase their money invested. They cannot help if you use vanity metrics or too opportunistic reports. A fail sometime does not automatically mean to be out of game. A non communicated fail leading to severe problems may end your career much quicker. And you always see twice 😉
Backers:
- Delivery dates
- Functional changes
- any fail in time and function
- supporting material
Backers want to be part of the product, the better they are integrated the more they spread the word. Sounds simple, isn’t it. As for investors the same for backers: you always see twice 😉
Tom Peruzzi's thoughts on digital, innovation, IT and operations 
leave a comment