From the book “Career Upgrade Road-map“, one of the chapters talks about the way to nurture the relationship with the people you are targeting.
Once you have a meeting with someone, a good rule of thumb is to make the conversation 80% about them and 20% about you.
Your goal is to be able to answer these 2 basic questions:
1. Would I like this job?
- What have been the biggest surprises to you as a xxxx?
- What are your favorite and least favorite parts of the job?
2. Could I actually get this job?
- What have been the biggest surprises to you as a xxxx?
What are your favorite and least favorite parts of the job?
To-do after the meeting:
- Same-Day Thank You
- Next Step (1–2 weeks later)—Give Them Value
- Give Them an Update (1–2 weeks later)
Goal: get introduced to the decision-maker of the position you want.
The majority of the value you will see from a new relationship will come after you have built trust and credibility.
Two big companies that will merge (after approvals) to divide in three, so they can focus on their own verticals.
To understand the move, it’s important to understand the numbers by segment.
Select a development framework it’s not an easy exercise, there are too much factors where we have to focus on.
Today they are popularly called “web frameworks”, name that to me is wrong, in a world where all is moving “mobile”. Let’s call it framework.
Other aspect is the target organization is a company, not a start-up. Here we have to convince people such: finance, business users, IT folks… This technical selection is part of an approved business case, with clear road-map.
With it, this is the initial criteria list we are going to use.
- Popularity and community size: this will tell you so much things. How many people accepts the concept and the way to implement solutions, how many available code is available and you do not need to write, how much forums are available to make your questions and pass the hurdles you find…
: the way of life of the open source project has to fit with your way of life, these aspects are essential during the evolution of the relationship between the given group of people using it, and the evolution the framework presents. Yes, relationship, this is like a marriage, you will have to live with the good and bad things of your new partner, so look for the partner that you can get along with.
- Sustainability / roadmap / scalability: We want to understand how the frameworks has evolved during the last years, how they have survived in a market where they have to attract community of people who has business issues. We want to understand if they publish a clear roadmap of their next steps for the core of the framework. We are going to build complex things, we want to know if we can build with a clear architecture and they provide all type of solutions that enable us to build our solution in an scalable way.
: Look for how much channels of support you can access. This includes free forums, private companies offering their expertise, even check if the organization behind the framework provides support through their services or through a sponsor company. To review the sponsors list of the framework helps too.
- Amount/quality core upgrades: this will provide you information about how quick the project team reacts to changes, to pitfalls, how the cover security issues. Other thing is how each core upgrade affects to your system. This also gives you the visibility about how serious the people behind the framework is and how big their organization is. Quality is important too, for instance I have done thousand of core upgrades to WordPress and I never had an issue: this is my level of expectation.
- Technique (pattern)
: We are focusing here on the development pattern implemented by the framework itself. We can have freedom, MVC, POC,… what is the best thing for us?
- Security: This is very easy, 2 steps. First: What is the security requirements I have?; Second: Does this framework cover it?
- Documentation: how is the formal documentation offered by the framework, how much books are published about it, how much forums exist about “how to”, how well documented is the API.
- License: Not all open source licenses are the same thing, they are similar but it is important to understand the details.
- Availability of resources in market related to the framework: pieces of code, plug-ins, themes, people, servers adapted to this specific framework.
- Ability to integrate third party resources
: a framework cannot attend all needs of the community, but it can enable the community to integrate the best pieces of software. This ability gives you how permeable/flexible is the framework, and how focused is the project team on their core capabilities. For instance, if the core of your framework enables JUnit integration as testing capability, you can focus the evolution of your framework on the core capabilities, offering the community how to cover testing needs with a trusted solution. If a framework has not clear differentiation in the market, it will disappear.
- Learning curve
: This factor is more or less important. It could be the case you have a very experienced team and you do not care about it. It could be the case that you have so much attrition and you want to ensure that the market offers quick replacements through the hiring of junior people that quickly can be productive. It could be the case that it is relevant for you because the market offers you so much pieces of code that you can cover thanks to the community. It could be the case that easy learning means that when you want to implement complex things, the framework has limits, so it is not useful for you.
This article written by Mckensey is so much useful, read it, do not read my summary; the list below is just for my memories.
The summary is, companies do not agree on what is the main focus in Enterprise Architecture (EA) management.
- Some companies are focused on continually measuring IT performance and adjusting business processes and systems as needed.
Others focus on alignment of the overall IT architecture with those of the individual business units.
- And other companies focus EA leaders who promote collaboration and accountability among teams in IT and business functions.
Who is right? probably all of them.
Anyway these are the list of ideas:
- EA should reflect the organization of the business (P04).
- The company should be clear about who is accountable for EA decisions (P04).
- The EA department should collaborate closely with the business and the IT organization (P06).
- The EA department should keep strategy-related tasks separate from operational ones (P01).
- The company should give the EA department approval rights (P04, ME4).
- The company should keep accountability for elements of the enterprise architecture in one group (P04, ME4).
- The company should analyze and measure the effects of enterprise architecture on the business (ME1, ME2, ME3).
The EA department should keep it simple.
- The company should use one tool to rule all elements of the architecture.
- The company should invest in EA leaders.
I have added some weird comments to the list (P01, P03…), the reason is that the 10 points made me think about the Cobit framework and how these ideas are implemented by Cobit. Each one of these marks are related to the framework.
Ok you could not avoid to read the summary and avoided the article, read it, the source of data is very good.
I suffered this virus in one of my computers, and I was able to fix it with this command on MS-DOS:
Attrib /d /s -r -h -s *.*
I need to review my anti-virus….
I have so much questions about the SalesForce TCO. I have search about this topic in the internet and there is not so much about it.
The perspective: looking at Portfolio Manager view.
The context. The environment we are talking about is a global organization with multiple business units where each one have different use of the platform. Each application has it’s own business owner, who ideally has to pay for each one of its applications (based in licenses). Common applications as CRM have also a business owner that will pay using the same principles.
The two main scenarios are:
Scenario 1: Building a business case. I have a business case where an application requirements, #users, transactions, expected size of data is defined. I would like to calculate the TCO of such application in different environments. How can I calculate the TCO on SalesForce?
Scenario 2: Real consumption of my platform. I have a portfolio of applications implemented in SalesForce and I receive an invoice. As IT environment, I have not budget, I have to divide that invoice within the different business units consuming the services. How can I calculate the TCO on SalesForce?
Other questions are:
- Is there any common methodology to calculate the TCO of SalesForce?
- What are the common parameters used to perform this calculation? Just the #licenses?