Donnerstag, Dezember 27, 2018

The 10 Agile Sales Principles


Being an agile organization is a very recent transformation we are seeing in today’s companies.

I am in the same transition with my sales team and it took a while to understand how that works.
After a lot of discussion and feedback from that article, I'd like to write down all these best practices to my own little sales-manifest - presenting my 10 principles for agile sales organizations.

Please comment/give feedback on you experience about that topic as this is still a very exotic to move sales to agile.



So far so good - but let’s go a bit deeper into that buzzwords and discuss the ideas behind it.

1. Accountability

Every sales rep needs to be accountable. That’s sounds very familiar - or? But try to move your focus away from pure numbers - as sales today is only accountable for achieving a certain number - nothing else.
Sales is your market sensor. You need to identify market demand, innovation trends, things customers likes to buy etc. etc. that’s something a good sales rep can do. A sales rep represents himself, the company, the product or service at once. Forget sales people who are just asking for budget and bringing in "other" resources to explain the product – that’s no value - and these people are only accountable for numbers - this might help over the next quarters - but not long term. A healthy organization has to learn and adopt to market trends - sales is the first entry point for the continuous improvement - or continuous innovation process for the team, the product and the whole company.
Step away from the cliché, that sales are just stupid and overpaid people in telling whatever bullshit to the customer. If your sales team is behaving like that - change it immediately or fire them!

A sales rep should always have one question in mind:
'What can I do to help my team/company to do better".

Getting the deal signed is one answer - but there are many more.

2. Adaptive planning

When the new fiscal year begins, we find us as sales being part of customer assessment centers to plan the year. But a year is long. It takes 12 month, more than 50 weeks. In the days of cloud - this is an epoch. 
Implement ways to adopt changes in products, markets, competitors - stay flexible, stay agile!
This doesn’t mean that the numbers - which we still need to meet - are be softened. No - but give sales some flexibility to bring the numbers. When a technology is getting outdated – don’t stay on the plan - move to the next technology and find your value-add there. Increase pressure on old stuff will only make sure that good people will leave early.

3. Collaboration in teams

That’s something I really focus on. In most sales team I was working in my history a sales rep was a lonesome wolf. We had always a good relationship within the teams - but we worked alone - we went out for hunting alone.
But a team is much stronger than an individual - especially when you think about the long run. But companies needs to support to collaborate within sales team. But reality is, that reporting, quota, named-account lists etc. are forcing sales rep's to be alone - because that’s what they are getting paid for - and their variable portion of the salary is typically huge. So it is on their personal interest to increase income to pay their live to act as a lonesome wolf.

There is a way to get rid of that problem - that is a team goal - or a mixed personal + team goal. But this only works together with accountability and transparency.

4. Continuous Integration

This is a typical software-engineering term. But think about Continuous Integration as a Process or Collaboration topic. How to embed the experience/feedback sales is getting from the field into the sales organization. How will get you product manager input from sales? Do you ask sales what is hindering them to be successful? Is it always a bad/buggy product - or is it always price? Often the problem is somewhere else. Communication, misbehavior, wrong expectations, processes, misleading reports or approvals ...
Talk to sales, embed sales into a learning organization.

5. Function

What is sales typically doing? In my point of view it is much more then presenting a PPT or explaining the pricelist to procurement. In today’s sales world you need to have a certain knowledge about your product. It is not necessary to be a "nerd" - but you have to be able to explain your product in context with other technologies, standup on a whiteboard and draw a high level design.

That’s a lot more then sales did in the past. 

For companies this means - you need to invest into sales skills as well as expert-skills to get the right expertise in the field. If this is missing - accountability will not work.

6. Measurement

I talked a lot about team numbers, KPI's quotas. Being agile means to be very transparent and work against measurements. These measurements can be numbers or activities which are supporting sales processes. But we need to have measurements in shorter periods then a fiscal year. Think about a sprint for project teams. That’s typically a 2-week period. 2 weeks – that’s a bit short coming for sales projects - but a month or a quarter is pretty good to plan and track. Break down the BIG Goal to make a deal or to hit a number into smaller goals to that BIG Goal. These measurements will not have compensation impacts - it will help the sales guy and the sales team tu understand what the sales rep is doing and what help/support this sales rep might need to achieve the goal. Remember: a team goal needs to be part of an agile sales team - so everybody from the team has an interest that the whole teams wins. 
This now comes back to accountability and collaboration. Create a please that sales can talk to each other. A sales cadence call is the wrong place for that - as this is just collecting numbers.
Think about Retrospectives to talk about internal problems or QBR-session (Quarterly-Business-Reviews) to talk about external challenges and experiences.
The measurements are not between the sales manager and the sales rep. They are between the sales rep and the sales team.

Again: What can I as a sales team do to let the whole team win?

7. Organization

Most organizations are starting projects to become more and more agile - but this will take time - and the way to implement agility is always different. To become agile also brings in some side-effects which are hard to carry for a lot of classic managers.

-We bring responsibility to the point where it belongs. That sounds nice in the beginning - but it's also assigned with some loss of control which only works if accountability, collaboration and transparency is healthy.
-We allow fail's - this is a BIG mantra for many people. I do see that a bit different.  I'd like to say: we do not allow failures  but we accept that they happen. And they are ok as long as I understand why they happened and that we as a team/company a learning from that failure. Continuous improvement is key in this point - this will make us better, more competitive, faster and more successful at the end.
But I'd like to avoid the situation that mistakes are ok. We still need to avoid them - but when we make mistakes because of wrong or incomplete facts ... this happens. When you like to be innovative - then you never have all facts ... you need to try out different ways - and some of them will fail. That’s ok when you stand up immediately, learn, change and try again.

This behaviors must be made transparent and communicated in the collaboration-sessions within the team - then the failure becomes valuable - because it turns now into a learning/improvement.

But again - mistakes we can avoid - has to be avoided! I do not like the behaviors that mistakes are no problem - whey cost us time, resources, money and nerve.

8. Predictability

When you sum up accountability and measurements - then this will automatically lead to predictability. Why this needs to be added here then?
Because this is a central KPI for good sales teams because most companies needs to report goals and numbers to the stock market - and analyst are hating surprises - no matter it its good or bad.

Predictability comes from numbers / CRM system where the team needs to give the right risk-assessment and transparency what they will achieve and what not.

9. Recognition

Recognition is a bilaterally thing. Sales is already recognized by achieving quote or accelerators on top. That’s why they are going up every morning ...
But you can do more. Show the team what, why and how an individual achieved. Show this with internal newsletters to the company - make people visible and what they did. But sales is not winning alone - make the technical people, Backoffice etc. visible as well. Recognize teams!
Motivate sales as well to recognize the team contribution - because they also work hard and their contribution is crucial for successful customer situations.

10. Transparency

That’s my last point to my 10 principles of agile sales - and it is the most important one.
When we give more responsibility and accountability into sales and empower them to work self-organized in the market - this will not work without 100% transparency. But transparency will only come with trust and team culture.
Do you now any sales rep who enters the complete truth of his opportunities into a sales CRM?
They either blow up opportunities to say: Hey - my pipe is fine - please let me work and do not disturb - or they hide deals because pipeline / funnel is full enough and they like to avoid the get their quota increased.
No matter which one - it is unhealthy for the team and the company.

To come to a transparent sales organization - the management has to change first. You need to setup a foundation of trust. Deals can fail - we don’t like that - but its real. And as long as we fully understand what happens in the market, we can manage it. Think about accountability, measurements, collaboration and adaptive planning.

A good way to implement that transparency is to have a team quota and a regular standup/QBR where every sales individual needs to show his contribution to teams success. 

For sales rep without full pipeline - this transparency also helps to get new ideas, contacts etc. to start activities to create pipeline. But everyone needs to be 100% open and transparent with it. That sometimes hurt - especially when pipeline is bad. But hiding is not making it better. Team-Collaboration helps here.

Another critical aspect of transparency is the daily work, the sales processes and interfaces to team/company. In engineering-projects we are having bi-weekly retrospectives to mirror success and failures, to learn from them, to communicate, to recognize or even to create and making people accountable for change.

The retrospective was the starting point for my sales team to get on the "next level" for transparency.

What do you think? Please give me feedback on this – either here or on LinkedIn.


Freitag, Dezember 21, 2018

Blockchain - where is the hype going?

Blockchain - still a very hot topic in any kind of innovation discussion. If you need attention or money - then say you are using Blockchain. uuuh.




Don't get me wrong - Blockchain is a very interesting technology - but there are many promises in the air which are not fulfilled today.

When you read Blockchain definition or articles they typically write thing like:
"Blockchain is a distributed, anonymized list which cannot be manipulated"

That correct in theory - but what is with all the fraud we were seeing in last time?
Huge amounts of coins/tokens were stolen from the different networks.

That happens on various platforms: (just some random examples)


You can find dozens of story’s on google search.

What can we learn from that?

Either we are not able to run that technology accordingly nor there are ways to manipulate the network. The first option should be wrong as there are a lot of experts behind the platform - so I assume to this point that they configure their systems correctly.

But if the second argue is true - then this is also true for any other implementation of Blockchain.
The size of Bitcoin today assigned with the growing complexity and needed computing power to mine tokens as well as the fact that the Blockchain is highly distributed is the foundation for security and consistency across the network.

When this huge network(s) are being attacked successful - then this is a potential thread to all other Blockchain implementations in the industry as well when I like to make that Blockchain accessible to public internet.
When this risk is being combined with the lack of expertise we have today within the company teams - then this is probably an answer why Blockchain stories typically works only on Powerpoint.

A lot of smart contract ideas I am seeing in the discussion are also not really depending on Blockchain technology - for sure Blockchain could be used for that - but this complexity is not really necessary.
Automated contracts are also often micro contracts or changes to frame contract. The transaction costs are often relevant for the business case - and Blockchain is a very expensive to secure a transaction.

The Blockchain PoC we are seeing today are often creating dedicated/private chains just for that usage. But as long as all ledgers are belonging to one party - I am asking myself how this will assure availability due to distribution of the Blockchain - how to assure distribution across different parties when there is just one. If the whole Blockchain is in one hand - I still have to trust that party - like on any other "as a Service" Provider.

My summary is - Blockchain is a really cool technology - but it way further away from commercial use then many expect.




DevOps/ITIL - Competition or Complement?

In my todays article I’d like to give some argues about: what is DevOps, what is it not – and how to combine or compare with ITIL.
DevOps is often seen as a group of people doing new cloud stuff. ITIL is seen as a bunch of slow processes.
So let’s first have a definition of both:
ITIL (formerly an acronym for Information Technology Infrastructure Library) is a set of detailed practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business. (https://en.wikipedia.org/wiki/ITIL)
1.  ITIL Service Strategy: understands organizational objectives and customer needs.
2.  ITIL Service Design: turns the service strategy into a plan for delivering the business objectives.
3.  ITIL Service Transition: develops and improves capabilities for introducing new services into supported environments.
4.  ITIL Service Operation: manages services in supported environments.
5.  ITIL Continual Service Improvement: achieves services incremental and large-scale improvements.
With the goal of consistency, service quality, customer satisfaction and drivers digital transformation.
DevOps is a methodology that combines software development (Dev) with information technology operations (Ops) with frequently alignment with business objectives. (https://en.wikipedia.org/wiki/DevOps)
1.   DevOps integrates software development with testing, QA and operations to achieve better collaboration among product, ops and dev teams.
2.   Using Continuous Integration and Delivery tools (CI/CD)
3.   Align with lean principles like Work in Progress (WIP), Batches, being agile to have a shorter time to market
4.   Cultural transformation
Everything we see here is about

  • Communication
  • Collaboration
  • Agility
  • Efficiency
  • Speed
  • Align IT with business
That doesn’t sound like competition or?

Another view:

ITIL is considering the whole environment as once – as a service-silo with dependencies, reduced to tickets and changes. That sounds like a vertical approach.
DevOps is the responsibility of a certain function or feature from development to testing to operations but disconnected from the environment – it is a horizontal approach.
Myths and Facts:
ITIL and DevOps are complementary approaches
ITIL and DevOps are often seen as alternatives – each with his own myths. But in fact, they get along well with each other as their objectives are totally different.
Companies would be doing service management in some way and ITIL helps in streamlining such processes whereas DevOps leverages service delivery by bringing relevant teams together and automating routine tasks to be agile.

DevOps is only about Software development
Many people say: that’s about software development and delivery. But DevOps is much bigger.
DevOps is about collaboration, behavior, thinking outward – we encourage our people to adopt these principles to all our Cloud activities. You can easily exchange software-development to any other kind of IT project – think about BIG Data: how to ingest new data, transform, deploy new models – or Analytics/Data Science – using different algorithm, libraries and tools. DevOps is a method to work in short development/research cycles, adopting learnings immediately and try different versions of your ideas against real data/customer data.
DevOps is a cross disciplinary method to drive innovation.
Software development is just one environment to adopt DevOps methods. And it follow a classic IT approach. It strives cross-disciplinary training so that everybody has a basic understanding of every task.

ITIL – only for Enterprises
If is a myth, that ITIL is always complex, slow and expensive – too expensive for smaller businesses. But ITIL is independent of the company size. ITIL can be very flexible as long as you are using suitable processes. You can start ITIL small und implement only relevant/necessary processes and increment on demand. The problem with many ITIL implementation is, that they are build up very complex to cover any aspect of demand. To find a suitable process which serves fast and agile demands on rapid changing technologies is therefor hard to implement.
If the process doesn’t fit to ITIL – then it becomes hard, slow, expensive. The implementation and tools of ITIL is the main driver for that – not the size of the company or ITIL definition by itself.

DevOps is just automation
DevOps is neither a tool nor an automation. It is a methodology to has automation as a result by identifying gaps and collaborating within DevOps teams how to solve gaps or reoccurring errors just by learning and automation. Automation also can lead just into new monitoring aspects and will make operational inconsistence transparent.

ITIL & DevOps implementation is expansive
No matter what you implement, it will lead to a reduction of cost and resources you need to dive digitization and operation. When the right tool is implemented for the right business, time-2-market is being accelerated. To combine both methods, DevOps needs to serve the right process/interfaces from ITIL – then you can create agile environment by having a high secure/predictable cloud environment, serving services on high SLA. The right identity and access management is crucial to offer DevOps people the tools to work on these environments without disturbing the ITIL process environment.
ITIL & DevOps -> This is a complement and NOT a competition!
It is obvious that the basic ideas of ITIL and DevOps are following very similar principles. They have similar roots aiming for better collaboration and higher efficiency. DevOps scope is faster turn-around times and agility through automation. ITIL also focus on automation to improve service quality.
The holy grail is to understand the purpose of each of these clearly and implement the right one for the right problem. Then ITIL and DevOps can cooperate within same environments addressing different demands from business.

“ITIL drives DevOps and DevOps improves ITIL”

Setup Agile Sales Management

Everybody is talking about lean and agile companies. But to adopt agile methods to sales is quite hard. Sales is a real old-school setup usually. Sales-People are not talking/helping each other - everybody is hunting for own quota, everybody is hiding assets, contacts, customers or best practises - and reporting is a pure waterfall approach. Sales have to give numbers weekly to Sales management - they have to sum up numbers to directors board. Is that agile?
The setup of an agile sales team is quite complicated - because these behaviours are really hard to change. I am trying that in my team, using elements from agile methods, transfering them into sales words and methods. Found a BLOG here with a very nice description how to deal with that:
https://lnkd.in/eCBdCTs
and I adopted some of these wordings:
  • TeamMember  = Sales Person = Closing Deals - BUT: Instead of individual quote – contribute to the team
  • ScrumMaster   = Team Lead / Sales Operations / Coach / Share sales and orga experise
  • Product Owner = Sales manager / Steakholder taking care about team performance
As an experience I can tell you: to have a retrospective within sales and talking about emotions, feelings and behaviours is a quite interesting experience. It took a while until first sales people started to really talk open about those issues, learning or even emotions - but it is now an important part of our team-culture.
When you like to have your sales to act a an (agile) team, then you need to re-think about quota and compensation. A 100% individual quota will kill team play - because thats what the quota is forcing the sales person to do.
A team quote provides the possibility for weak members to hide. And now it becomes important to keep sales teams small and highly communicative. Everyone from the team has to contribute to the team - when this becomes transparent to everyone - then nobody can hide anymore. My experience is a good mixture of individual targets and team targets - but in a way the individual target is not destroying the team approach.
Sales candence to share and report numbers is now something we use only 30min a week - thats is a result of trust and transparency. Cadence itself is not helping sales to sell, or being more competitive - it is just a need for the organisation to control the numbers. But a healthy company is more than numbers - it is an organization which helps each other, which understands tho overall mission/target. We call that "outward mindset"
Some more agile methods we translated to the sales-world:
Sales Sprint is a quarter
•StandUp and Review are happening in our Quarterly Business Reviews
•Retrospectics bi-weekly to improve and learn (no cadence, no escalation)
•Burndown-Charts are CRM Numbers
I can encourage you to adopt agile methods to sales - people are now behaving as intelligent individuals - not as sales-bots. But take your time! :-)
#sales #agile