Tom Peruzzi's thoughts on digital, innovation, IT and operations

Good experience, good habit – no team and plan – omg

Posted in general, startup failures by opstakes on December 4, 2014

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.
Tagged with: ,

websummit vs. pioneers

Posted in general by opstakes on November 24, 2014

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 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.


the knowing-doing gap

Posted in general failures, organizational by opstakes on February 8, 2013

Bildschirmfoto 2013-02-08 um 08.40.36There is a great book out there from Pfeffer and Sutton writing about the difference in knowing and doing. Even if you know it will not become reality you often start doing something in that direction. Even if you know this brings you into a dangerous situation, you keep on running. It is scary, honestly but human too.

The same often happens when talking about operations, QA and development. Some examples: Even if developers know that untested code often results in bad behaviour, stress and pain, the code gets deployed. Even if operators know that they should provide a service (the infrastructure and related daemons) they much more try to build barriers to “ensure stability”. Even if QA knows that controlling isn’t enough it is much easier to tell somebody that he did not reach the line instead of helping him/her coming there. We are all obliged to support the company we work for. If the company is run by idiots, please leave otherwise do your work as you promised with your signature.

We all live in a time where time becomes an evident issue, pressure is high, likelihood to fail too, but we are no longer allowed to fail even if a lot of enterpreneural books write about fail-learn-improve cycles. Often this happens as we react not like we know we should react. Business pressure, politics, friendships and sometimes the missing willing to change make us to some sort of organisational animal, no longer reacting rational in a human manner, much more rational in a corporate manner.

But as we are all obliged to Quality, as it is our wish to product high quality products/services, as achieving mastery is one if the fundamental personal goals of “running” we should try to bring in more evidence, react on what we know and not what best fits know and stop doing if we recognize the difference in knowing and doing. Another reason why this is that hard: the organisational culture has to support such behaviour. Saying “no” or “we must change …” has nothing to do with blaming, it’s a positive escalation showing new ways of working and thinking and propably (hopefully) better ones.  This has nothing to do with basic democracy, everyone should bring in his/her expertise and evidence to allow the company grow and prosper – knowing without doing isn’t enough!

Operations Strategy

Posted in general failures by opstakes on December 29, 2012

to operate or not to operate. If you believe in Henry Mintzberg (2003) saying that strategy has a lot to do with craftmanship and either deliberates or  emerges from the bottom then you potentially should use operaitons as one source of inspiration!

I do not want to talk about DevOps, NoOps or whatever Ops, the serious question is whether operations can participate in collective and corporate learning and generate benefit for an organisation or not, whether it creates some strategic extra or it is only a matter of costs. In the past a lot of people wanted us believe that operations is dying, becoming part of a museum, being exchanged with smart scripts, recipes, a lt of logic and automation and and and. The funny thing on the story: a lot of those ideas came from developers who – in the past – alsways had severe problems with operations for different reasons. And as development is a creative process being very near to products it often has a better internal voice than operations. How often did I hear that operations does not produce any strategic value to product X or servicy Y?! I cannot count that number, it is pretty to large I guess.

But this brought me to my story. Is ops really just about money? Is it the department socialiszing the developers ( 😛 )? Is it the steady continuuum of delivering a service? Or is it the bow before me for I am root fraction not worth sitting in an upper floor?

It is a strategic question which has to be answered. If you think in raw numbers operations can be outsourced, if you think in ressoruces, it can be outsources too, if you think in value and operations as a service than it potentially should stay in. The reason why? The more operations offers an infrastructure + processes as a service to its customers, the more it concentrates on its specific know-how and capabilities, the more it becomes a strategic asset. Yes, this is a long way to go and no, you cannot keep on acting the way you did the last 10 years. A good Ops manager must become a product manager of the corporate infrastructure, he/she must sell it to its customers, he must have passion in serving those needs. If so – I bet  – there will be no discussion for outsourcing or not, because that discussion will be driven by the ops manager to be able to deliver the best infrastructure available!

So please, dear Mr. Ops Manager, make you live easy and become a major part of the service chain. Go that way, even if it is the harder one, but this will keep you, your team and operations vivid and valid for the next period of time.

Missing seniority

Posted in general failures, organizational by opstakes on December 20, 2012

I thought for a very long term whether to write that post or not. The reason why thinking is that it should not be a claim for people with more experience like me, it is a claim for more seniority and you can gain that seniority even earlier.

BUT – and ofcourse there is a huge but – you never can run a good product launch project without seniority. This happens all days to all different types of companies, small enterpreneurial ones as well as large corporates. Define who you gonna go with before what to do and make sure you have the right skills and expertise on board upfront. If you, for example come to a point during a project that e.g. the PO or the Scrum Master is lacking expertise thus getting ignored or absorbed makes it much harder to change and refresh than spending some more time at the beginning.

If he/she lacks methodolgy, ok, get her a training, but you cannot train expertise and seniority and especially not within a week or month! There exist plenty of good people out there being well educated but not skilled, there are others doing a job for 6 months and gain a lot of insights and there are others working for 20 years more or less without thinking. This means for you that you do not search for a special age category nor for a special educated one. Education and age can be an indicator, but not the total truth. You have to search for the excellence by talking to them, becoming inspired by their drive and capabilities. Than you know you are right. For people there is one special rule you should always take care on: If you are not 100% sure, than leave it. You should never change the organisation to make the one fit. Either he/she fits into culture, climate and organisation or not. It is up to him/her.

Tagged with: , , ,

the scrum story – I’m back

Posted in development by opstakes on December 6, 2012

dear all

It’s quite along ago writing my last article but now I’m back. The reason why? I had so much to do and I really struggled whether to continue or not. I will change slightly and bring in more stories related to IT in general not only IT ops any longer.

I currently do work a lot with scrum and with the all time discussion which and how and scrum, scrumban, kanban or whatever rules. For me the most important is the aspect D. Pink brought up in his wonderful book Drive (I would strongly recommend reading it before implementing any sort of agility!)

What he tells us is that the main 3 drivers for motivation and drive are autonomy, mastery and purpose where autonomy is meant in time, task, team and technology. Scrum takes care on that on a certain level but not that explicit and even so the more enterprise scrum you have and the more silo oriented (aka component driven) the harder it is to establish that sort of autonomy. There are plenty of good examples out there how really big hip organisations organized their scrum-teams. What we did as a way in between traditional oriented teams (the more enterprise ones thinking in know-how silos) and hippy cool stuff was the introduction of some infrastructure driven (silo oriented) teams providing APIs where the feature-driven teams can rely on. The trick is, and future will show whether we are true or not, that the API teams must run 2 sprints ahead and have a pretty good unterstanding of what is needed on API level in future.

Why did we do so? Well if you have component driven teams from the past which started already to work, a lot of missing competence in new core parts of a new platform and only the chance to fill that gap with external companies (not contractors) being able to provide that sort of knowledge as part of shared license and times&material .. well, then you have to act the way we did or you thing in raw silos only and try to manage the dependencies between those story per story.

I assume that there are pretty more ideas out there but velocity, engagement and teaming-level shows us that we are on a pretty good road right now. If you have any other or better experience feel free to share, would be happy to get more info!


Tagged with: ,

demand management is king

Posted in general failures by opstakes on May 19, 2011

we all use words, sometimes in business context, sometimes in tec one, sometimes casual, friendly sometimes hard and direct without being frankly. So we allow us and words to switch context but what we often fail is to mean the same. This is core reason why a lot of projects start to fail, loosing interest or getting politically killed.

There is definitely a difference in meaning, understanding and expectation between the requestor and the fulfillment part, it’s all time an agreement, either internally or externally. If you cannot manage your demands properly you will either fail to step upwards or you will likely rotten your external partners. The core question is, who’s reliable for getting things sorted correctly before the project starts? And – what I have seen – the often special words and acronyms are used, the more often people start talking about different issues/behaviours and understandings.

I definitely believe that you cannot say party x or y is responsible for getting things sorted out correctly before. Either it is business and time pressure not allowing you to do appropriate demand management or the other party is not willing to invest too much time and effort or political and hidden agendas.

You can start a very simple query: ask colleagues within your office whether they can do you a favor (not specifying which one) or ask them to do project management for you. Both are not defined correctly but both words are well-known. You will get a lot for from your colleagues but definitely not the way you wanted it to be.

The key to success is to use another 5 minutes within the agreement and define some positive and negative boundaries like: I want you to do project management for me, this includes tracking, risk management, documenting … but I do not want you to do all the financial stuff.

The better the fulfillment party asks or the better the requestor is able to define the better will be the success of the project, even with or without a contract with whatever clauses.

So start early by adopting a proper demand management process. You will not need an armada of employees doing requirements and demand engineering but you will need some general rules like:

  • the project only starts if the task is proper defined and positive and negative boundaries exist
  • at least 2 measurable KPIs for the goals exist
  • there is a mutual agreement of both parties that they understand the others needs

Some methodologies like scrum try to do so, this is quite good to know, but we need a general understanding and culture of demand management within the organisation.

If you want to know when to start: If not already in place start NOW. It is not a question of size, revenue or whatever, it is a question of respectful working with others to define clearly your expectations and goals. Start training your 3rd parties by delivering clear and distinct expectations and goals and accept the money you have to pay for, writing less but expecting more isn’t the way you can go for a long.

Wish you all the best with your demand management!

Is IT ops a core competence?

Posted in startup failures by opstakes on May 11, 2011

When talking to a lot of companies they all start with their idea, the development (business and tec) of the idea and the operations of the business including IT operations. They mostly don’t care about whether it makes sense to have it ops capabilities  in house or not, it is usual to do so and it sound’s much easier and cheaper at the beginning because

  • you have to care about cost much more (and 2 ops engineers are enough for 24/7 😉 …)
  • it’s all about time and market speed, quality and sustainability don’t care that much
  • meeting regulations and laws is not king and key to success

So as a result, the ops department is growing more or less equal to business success and after a while you have a very strong, profound and even expensive ops department in house. Processes start to get sowing down, compliance in all different facets arrive and people get more settled than at the beginning, you are now a real company with HR, structures, processes and it ops.

At latest at that point you should think about whether it makes sense to have them on board or not, you should ask questions like:

  • what is the reason for having ops on board?
  • are they that unique?
  • are they faster, more agile than the market?
  • are they more experienced than the market?
  • do they have special skill or knowhow and why, is it good or bad?
  • is it cheaper than the market?
  • will we fulfill the technical, organizational and compliance requirements for the next 18 months?

There is pretty high chance that you can answer some of those questions quite easy and with the result to better have them in house but to be honest it will happen quite often that the result is that it ops is not key to success, it just has to work. At that point you should think about outsourcing/outtasking or whatever (see some of my former posts) and concentrate on the key aspects of your organization.

One very important remark: if you come up with the conclusion that you want to outsource because of it ops bad processes than you will fail. A problem getting outsourced will become an outsourced problem! If that’s the output think about increasing process quality before and doing the doublecheck a second time, afterwards you still have plenty of time to do some outsourcing lessons.

the wrong trust in cloud computing

Posted in BCM, general failures, startup failures by opstakes on April 29, 2011

What we have seen last week is that even large companies like Amazon can fail – on whatever reasons and with their tons of engineers, processes, procedures, technologies and mass of systems and servers. The question for you as a (potential) customer should not be why did they fail?

They had a rapid growth and even with the best engineers ever both growth and quality cannot run the same speed, their must be some sort of risk even if we still talk about human created systems. And to be honest I really believe that it can happen to all service providers out there soon, maybe tomorrow, next week or never, the likelihood to fail is a built-in function.

But what’s the question you should ask and answer yourself: How could I survive if my (wherever) instances or data goes down? It is not the fault of your provider if you miss all your data, it’s your fault if you had no strategy on how to deal with such a disaster? Nobody will expect you to come back to live and operations within 30 min if such a case occurs but you should have your BCM work done before. I know, if you – like many running on clouds now – are within online business time and speed matters, risk is ok as long as it is not happening, afterwards you get asked what happened and why you had no plan against …

So keep in mind, data security (integrity, authenticity, availability) is always your job, you can outsource (move to cloud) parts of the technical stuff, but the management and umbrella function always belongs to you. Yes it is a pity if your service provider goes done, but it is a shame if you have no plan how to cover such scenarios and come back to ops immediately.

This is the wrong trust in cloud computing, cloud computing can help you a lot, it can mitigate your volatility, it can enable you immediate growth, fast test and beta and whatever but you should know what your cloud provider is and what he delivers, do not overtrust. The provider delivers technology, you do the mesh-up, so keep an eye on the availability and security of your mesh-up!

the missing IT and Ops strategy

Posted in general failures, organizational, startup failures by opstakes on February 8, 2011

It often sounds like operators – or in specific IT operators – just operate on a day2day basis independent of what’s coming from the business and where the business is going to.

In fact this is bullshit. You cannot act as an operator if you do not know where your company is willing to go to! And even you cannot operate if your IT and your IT Ops department don’t knows how to answer on the business challenge and on how to challenge the own IT department. There is difference between “headless” and strategy less. We often see organisations with strong management in terms of discipline, procedures and routines but they still fail. The reason why is not bad engineering … it is a lack of understanding that beside discipline and processes you need 2 more factors (I would not call them soft or whatever and I will not write about culture!)

  • a strategy showing people there to go to
  • challenge from the market

It is quite interesting to see that the less IT strategy exists the more you hear something like “we are so extra complex and not comparable to market … we have superior engineering on board …. we cannot compare to market as we have special self written applications …. the market will not understand our demand …. ” Potentially we will be able to name tons more of those bullshit arguments.

I worked a serious long time as a systems engineer with potential the same “ideas” regarding our rocket science ops platform ;-). Once I went to the CTO as he asked me to have a look at a special solution being on the market. I told him the pros and cons for about an hour and explained why this is shit. At the end he pointed out that if 1000 people think this is good solution and I think this is shit …. who will be the right one? The funny thing behind …. we used that solution and were quite happy, it was near market standards and we started to build our special ops platform market conform and got tons of more possibilities; on the economic and on the tech value!

Why this is important? The CTO had the strategy to be as market compliant as possible but staying rocket science in the business related tasks, processes and programmes. He showed us that this strategy is able to work and how the company benefits from the strategy (he did not mention in detail that engineers are easier to exchange if you use market standard hardware and software 😉 )

Next thing is that if you do not be on your own on both, organisational and technical, than you can take part on market innovation and inspiration. Mostly market will be much faster and innovative than you are, especially this should help you in the security environment. Keep an eye on being as secure as the market allows you to be. The most innovative internal solution will not help if you cannot participate in security development speed!

Let’s summarize: Have a strategy, give your people a mission, a scope and an idea of how to go forward, don’t forget to check the market and do not hesitate to accept that market is faster and more innovative than you and your department, nothing  to shame on, only if you think you can be much faster as the rest of the world. Hopefully or potentially you will be able to exactly tell the “I’m the fastest” story to your business than talking about core processes, metrics and IT/business behaviour!

%d bloggers like this: