Archive for category People
Attending a conference – how to mingle
Posted by Patrik Löwendahl in People on November 13, 2012
Geeks are not known for their social skills. Which becomes very clear when a lot of them attend the same conference. I am currently attending the SharePoint 2012 Conference in Las Vegas and thought this would be suitable for all the geeks going to parties and mingles this week.
It is a list of 10 very concrete tips from a rhetorical and mingle expert. Very good tips, any geek following this will be successful (oh and yes, it works for picking up both men and woman as well ;)
Don’t miss this:
Rhetorical success is all about how to mingle, in the most efficient way. Mingle in reality. Mingle online. Mingle during parties and mingle in the office. It does not matter. You prepare your mingle in the same way as you – of course – prepare a text for publication. Ok?
Go to the ten tips here: Rhetorical success: How to mingle.
Enterprise Social: Technology is not the answer. This is the answer.
Posted by Patrik Löwendahl in Architecture, People on November 12, 2012
- “We need an internal Facebook”
This is a very common statement in any organization today. They want to replicate the success of social collaboration giants like Facebook, Twitter and YouTube is massive. Having people in an organization engaged in communication as they are on those services is very compelling from a business perspective.
The next question after that is usually:
- “Can technology X give me Facebook”?
“Technology X” is commonly SharePoint 2013, Yammer, NewsGator or Lotus Connections. There are several organizations interested in investing into these applications to get “Facebook”, “Twitter” or “YouTube” to their organizations.
But why? Are they asking the right questions?
Social collaboration is after all not a technology. It is soft values such as communication, engagement and people. To realize those values, technology is not the answer – it is just one of the tools. As such, there are others that are much more important to get right.
Communication Strategy
All features of a social collaboration platform or product is there to enable communication in some form. From micro blogging to video archives, they are built to let people engage in communication with each other. So ensure that these communications are engaging and valuable for you as a business, the features you enable and create need to have a strategy behind them. A strategy to align them. A strategy to ensure you invest in the right communication tool for your organization.
Useful, Usable, Beautiful
The above title is the catch line for the Avanade design studios. It is the catch line because these three together makes up the best user experience for any application. For social collaboration projects is is one of the key components. If you want to engage your people to communicate, the tool need to be bring them immediate value, be easy to use and be visual appealing. Anything less and the threshold of using the tool will be to high and you will fail to engage your people.
Changing behavior
It does not matter if you have the most useful, most useable, most beautiful tool to enable your communication strategy if nobody is using it. Change does not come easy. Change is not automatic. Change will be initiated from a “what’s in it for me” perspective. So you need to plan for change; What training will you have (videos), what incentives will there be (gamification), what activities will you drive to ensure adoption (collaboration champions)?
When Facebook and YouTube first started up, they did not have any of these in place. But yet they succeeded in building the largest social collaboration sites in the world. There are several reasons they did. The “what’s in it for me”-incentives are very compelling, the early adopters where already champions of internets various services and the value where apparent for them. To replicate the same success, you need to replicate the same setting.
Social collaboration is really valuable for any organization. But value is not objective, it is subjective. Any tool you want people to use need to be valuable for them and should under no circumstances create pain or frustration. To successfully instigate change in your organization, you really need to plan for it. Ensure you get all three right in your social collaboration project, and it will be as successful as Facebook has been.
Sometimes it is business that needs to understand development
Posted by Patrik Löwendahl in Architecture, Methodology, People on September 10, 2012
There is always that guy. The business oriented guy, the guy who can’t understand why a few lines of code can take a whole day to produce. The guy who believes that pair-programming is the equivalents to “get one pay for two”. This is a story about that guy and how I made him understand.
A few years back I was involved in in a project that had the attention of a vice president in a huge enterprise. The project had haltered and the VP’s response was to micro-manage developers tasks. One of the meetings I was asked to prepare was to explain why a switch in data access technology had to be done. A gruesome task: Explaining technology limitations to someone with absolutely no technology background. In the end it succeeded. Turning technology limitations into pure numbers: Bugs/LoC, Cost of a Bug, hours spent on performance tweaking, etc., etc.
But that is not what this post is about. This post is about how I got him to understand that developers are not glorified copy writers with the task of writing as many letters/day as possible:
- “I don’t understand? How can you only produce 100 lines of code in a full day? And that’s with two developers at the same keyboard!”
- “You write business plans right?
- “Yes.”
- “And how long is that document, about 30 pages?”
- “Yes?!”
-“I can write 30 pages of text in Word in a day, maybe half a day. How come it takes you weeks to produce the business plan?”
-“Isn’t that obvious? We need to figure out what the business plan is about, the text is just a documentation of our thinking.”
-“Exactly”.
From that point on there were no more discussions on lines of code, technical details or design/architectural decisions. From that point on it was only about features and velocity, process and predictability, and the most important feature of them all: delivery.
Developers: Innovate or get outsourced
Posted by Patrik Löwendahl in Column, People on June 15, 2012
“Nothing endures but change”
The phrase is accredited to the philosopher Heraclitus on of Plato’s influences. In our industry, the quote is o’ so true and there is a new change at the horizon we need to embrace.
You have probably heard that to be a successful solution developer you need to understand the business. This is true; to deliver a solution you need to understand more then just technology. However, in a very near future this will not be enough. In a very near future you will need innovate solutions not only develop them. In the same very near future you will need to understand how to innovate business using technology not only apply the technology to the business.
In that future, to stay relevant in your on-shore locations, you need to turn into a solution innovator and move away from being a solution developer. If you can’t take on this shift; you WILL be outsourced.
The outsourcing paradigm has really evolved the last couple of years. It is moving away from being “IT on tap” into strategic partnership. I only need to go as far as the company I work for, Avanade, to see how we build centers that are client specific. Centers that capture knowledge of our clients business and already today deliver the solutions and value they need with very little or no on-shore assistance.
While I am looking back at the last 12-13 years that I have been developing solutions for clients, I see a pattern. It used to be enough to be a skilled programmer, then that got moved into outsourcing factories. It used to be enough to be skilled at designing solutions, then that got moved into outsourcing factories. At the moment it might be enough to understand the business, but I am certain that will move into outsourcing factories as well. Following this path we need to take that next step to be significant.
Deploying that last bits of code into production and seeing your client silently nodding and agreeing that you delivered as promised; creates a rewarding feeling that I am sure we all have felt.
Deploying the last bits of code on a solution that delivers business innovation which you brought to the client; rewarding is not a big enough of a word to describe what you will be feeling.
Of course the difference in time zones and cultures as well as the distance between countries is making this transition a bit slower, but it will come. Services like Lync, Skype and other collaboration tools is closing the gaps and gives us unique insight in each others cultures.
After working a couple of years in a truly global company, I really feel I can understand and collaborate with people across the globe a lot easier then before and I have peers in other locations I feel as close to as the colleague sitting at the desk next to me.
The transition will come.
Understanding the business will very soon not be enough. You will need to start innovating, you will need to be proactive to your clients needs, being reactive won’t cut it. Personally I turned to “s” to start my transition and am really looking forward to reading “” and “” during my summer vacation.
I suggest you do too, and fast before your job has moved to another shore.
Some useful links:
TED Talks: Charles Leadbeter on Innovation
Slide Share: Thinking about innovation
Is there any value in certifications?
Posted by Patrik Löwendahl in Column, People on May 31, 2010
The last few months there has been a massive amount of voices speaking out against any form of certifications. Today this was actualized in a twitter discussion with a Cornerstone (training company) and Emil Cardell. Emil argued that certifications basically are worthless and all you need is a little problem solving and google.
I’ve been working several years helping everything from individuals to large enterprises maximize and capitalize on the competency they have and are reaching for. In this work I’ve come to realize that I do not agree with Emil’s simplistic view of the value of certifications, I find the issue more complex.
These are my thoughts on the subject.
Certifications outside our little sandbox
There are several areas where certifications are used outside of our industry, we are not unique. There are majors ones like doctors and electricians and minor ones like “transporting dangerous goods”. As with the certifications for devs, these will never single handily guarantee that the person holding it is competent; or even the right man for a specific task. But on the other hand, you would probably avoid letting a plumber without the right bathroom certifications rebuild it for you.
The classic example is people with drivers licenses, how many times have you wondered how they passed the test? But they still did, and you can’t drive a car without one.
So why do we rely on these certifications here but disregard them for software development?
State of today’s certifications
There is several types of certifications for software developers today and the major once can be categorize into three types that each have questions of validity raised against them;
- Knowledge tests (aka multiple questions / answers) – can be crammed.
- Attendance (e.g. SCRUM Master) – Only measure attendance not knowledge.
- Reviews (Arguing for a solution in front of a board like the MCA) – Risk being based on friendship or contacts.
Does these doubts make the certifications worthless? They will certainly make it hard to guarantee competency, but that’s not unique for “our” certifications.
So why the outcry against certifications in our industry?
Reasons of outcry
I’ve come across several, more or less well founded, opinions why certifications fail us. Some more admirable then others as well.
The “I’m better then you” mentality
This is based on the same feelings that people get from others driving their cars like mad men. The simple rhetorical question of “how did this guy get certified?”. The interesting thing is that there are millions of people that never judge people outside of their car, likewise it seems that when we start writing code, some start to judge others.
Simple criteria’s
Some criteria’s can be very simple to complete. So simple that the value of the certification itself can be questioned. “Should it really be enough to attend a two day course to get certified?”
“Everybody got one”
This ties in a little to the two earlier outcries, if everyone in the industry got one. What worth are they?
This is an objection I find very interesting, since no electrician can work without a certification. It’s not the fact that you hold one that’s the value, it’s that if you don’t, you shouldn’t work.
They are only on X, not on Y.
This is a very popular argument and it usually comes from people not agreeing that X is the technology to use, anyone competent uses Y! This arguments springs from the view that it’s “my way or the highway”, a view that almost brought down the ALT.NET movement completely. Is a certification on X worthless if it is X you will work with and not Y?
So is the value only in how “hard” they are to attain, how many people got them, or what technology they are based on?
This is the real value.
The value of a certification always lies in the perception of the people it’s presented to. In our industry; MCP certifications held a huge value when they first where introduced. But as more people attained them, the perception of it’s value faded. There are still some that are well respected, most of them have few people that’s passed them. So it seems that we only value certifications as a proof of “superiority”, not as a measurement of basic knowledge in a job role.
I’d like to argue that there is value, even though it doesn’t prove your “superiority”. There is value from a lot of different perspectives.
Value for individuals
The Dreyfus model of skill acquisition speaks about 5 levels of competency. Going from one level to another needs different tools depending on where you are on the scale (Johan Normén will speak about this on devsum10). Today’s Certifications are such a tool.
It will not take you from competent to proficient or proficient to expert, but from beginner to advanced beginner. It’s often a measurement that you grasped the basics and are ready to move on. It forms a baseline for your claims to be competent.
And most importantly, it tells people that you put in the dedication and effort and those without the certification didn’t. It doesn’t tell that you are an expert but it tells a lot about who you are and what areas you studied.
Value for organizations
There is value beyond the individual in certifications. Organizations can use them as a tool in many aspects of their business model. They can be used to inventory competency, as a measurable goal for bonuses or as an argument for higher prices. For businesses the two strongest areas of use is first a mean for steering the business direction and secondly in relationship to their vendors.
Steering
If I as a corporate leader wanted to move my business in a certain direction I will have two challenges to handle. First I need to know where I am, I can’t plot a course without having a starting point, secondly I need to know that I got there. Depending what my ambitions are, certifications can help in either one.
Relationship
It’s easy to claim that you have 100 developers that know a certain vendors technology and is a strong candidate for partnership. But how do you prove it? A showcase isn’t enough, in theory everything in your showcase could’ve been produced by one person. Certifications are a great tool here. Since it’s neutral and not based on your own perception, vendors tend to trust certification numbers as an indication. It’s usually not all that’s needed, but it’s one component in a validation of your organizations worth to the vendor.
This need of a “neutral” verification is truly visible in many organizations job-ads as well. They wish for a “engineering degree” for their applicants, not because engineers by default make better developers, but because there has been a third party involved in validating your credentials according to a baseline that can be compared to others.
Do I think that certifications are ideal to achieve these two values? No, but it’s one tool, one step towards something that will be.
What does the future hold?
I don’t think we’ll see less certifications. I don’t think we’ll see “certifications” as a concept devolve in value. I think we’ll see different forms based on work and not solely on theoretical knowledge. I also think we’ll see better tools for organizations to get a solid overview of where they are. Does it mean that certifications as they are today will disappear? I don’t think so. They do fill a basic need, much like the theoretical test for your drivers license tell whether or not you are ready to do the “real test”.
I’ll tell you what I would like to see happening.
- I hope that basic certifications get a little bit more unpredictable, so that pure cram session will require you to learn stuff (much like university tests).
- I would like to see an apprenticeship form that has basic competency requirements and certifications and makes you a craftsman.
- I would want for people to stop calling themselves “seniors” and instead work with their peers and earn the title “senior craftsman” not just print it on their business cards. This could be similar to how you gain your doctors hat in the universities.
We are working in a knowledge industry, we use our brain everyday to deliver our work. There will be a need to measure what we can do and there will be times that your individual competency has to be judge along side others. For us to be able to call our self a “profession” we don’t need less certifications, tests or titles. We need the ones we have and then some. We need to make a strong statement that Software Development is not for everyone, you need skills to call you a Developer. You need to understand that’s it’s serious work, not toying around with computers. Raising the bar with certifications, tests and titles will do that.
Duoblog: Everybody wants choices but nobody wants to make a choice
Posted by Patrik Löwendahl in Column, Methodology, People on October 8, 2009
Johan Lindfors, Microsoft and I discussed the growing opinion that software development and .net framework is getting to complex on MSN the other day. He suggested that we write a duoblog about it, an initiative started by Chris Hedgate, don’t miss Johan’s view on the same subject here: http://blogs.msdn.com/johanl/archive/2009/10/08/duoblog-everybody-wants-choices-but-nobody-wants-to-make-a-choice.aspx
The last year or so I’ve read in the Swedish magazine, Computer Sweden(in swedish), listened to developers on shows like DotNetRocks, and had discussions with several developers which all have had a similar concerns about the future: “Software development is to complex, .NET is to complex. There is just to much to learn, too many choices I have to make”. This makes me a bit sad, and frustrated at the same time. This is why.
Why are there all these choices in .NET?
Let’s turn the clock back a little bit, the year is 1999 and Visual Basic 6 and classic ASP has their prime time. While developers using this platform are building e-commerce sites and line of business applications with somewhat success; they are still missing key components and Microsoft plans to fill that with a new platform, .NET.
2001 .NET becomes a tremendous success. Advanced applications can be built easier then before and developers are satisfied, for the moment. With better understanding of the .NET framework developers soon see even more opportunities where software can help businesses and soon they crave for more. This is only natural, with every technological advance we do, we look at the horizon for the next.
Microsoft continuous to put out new functionality and adds value to the .NET platform trying to meet all the demands that arise. They learn a lot during this process and in some cases they decide that old parts of the framework, like ASMX Web Services, won’t cut it when they move forward. It gets replaced by newer and better technology. As a good tool vendor though, Microsoft leaves the old technology in the stack for backwards compatibility, not to be chosen over the new technology.
It’s now 2009 and Microsoft is very soon launching a new version of their platform, .NET 4.0 and Visual Studio 2010, with even more changes and choices and there is no doubt there will be even more in the future. All in response to customer feedback.
In the meanwhile businesses has changed.
During these 10 years when the development platforms have evolved and developers have been provided more tools, business has changed. In 1999 IT and software was considered a cost of doing business. In 2009, for many companies, IT and software is their business. I’m not only talking about companies that build software or sell consultants, I’m talking about all sorts of businesses. Business and their view on IT has changed, based on the same mechanics that the development platform has; for every advancement in business process support by software, they want more.
Today there are higher expectations on software then it was 10 years ago. Microsoft is trying to help us developers to meet these expectations by providing us the tools we need. Higher abstraction layers, more automation and frameworks that solve specific problems.
So THAT is why we are where we are.
In some ways I agree, software development is complex, .NET framework is big. But there is a reason for it, business demands on software are more complex, business itself is more complex then it was 10 years ago. But this is our job. Our job is to help business evolve, and if we don’t evolve with them we will be their stalling factor, we will fail to support their needs.
To help business with the best solution we need choices, we need even more choices. We need choices outside of the .NET space. We need to learn and understand when and where a certain choice is the best choice. This is our responsibility as software developers, this is why we are paid, this is our god damn JOB.
Software development is all about learning
So this is why I am sad and frustrated, developers seem to not understand the basics of the job requirements. As a software developer, my job always include constant learning and constant improvement of my skills. If I can’t agree with that I am a bad developer. This is not the tool vendors fault, this is because business change, improve and learn as well. If we don’t do that with them, we will be left behind.
Similar posts on this subject:
Excel as a software engineer, be a professional not an amateur
To product companies: Focus on your strengths not your competitors weaknesses
Posted by Patrik Löwendahl in People on September 15, 2009
In a recent job I did for a Swedish government agency, me and a colleague compared two products to see which lay a better foundation for the business process they wanted automated.
One company stood out in how they clearly didn’t understand what was important for us. When meeting their representative our first impressions was not of their system but of the competitors. In the first five minutes after the greetings I heard the name of the competitive’s product at least 10 times.
There is just so many things that is wrong with this. First of all, think a little about what you are doing with the trademark of the competitive. You are imprinting it in my mind, by repeating it so many times the trademark is soon very well recognized by my memory. This is just bad marketing.
Secondly, how do you think my perception of your company will be? When your focus on your competitors weaknesses and not on your own strengths? For me it’s a sign of weakness. If your product is good enough, the competitors weaknesses doesn’t matter. I’ll want to get your product anyway.
Also, if you have a pricing strategy. Make sure it’s a solid one. If you dump your price with 50% from the list price to meet the competitor what message will that relay to me? My initial thought is “If you can drop your price with 50%, did you then try to fool me with your first price?”. The business ethics behind this is just repulsive.
This was a while back, so why am I writing about it now?
Well the company flames the government agency with more trash talk about the opposition. Which have lead to me recently having to explain some of the trash as just uninformed, the company have wrong information about technologies like Workflow Foundation (claiming you can’t participate in a process using it for instance).
The agency representatives comment on this?
“I’m not sure I think that attacking the opposition like this shows good ethics”
Guess what effect that flaming had?
4 Comments
Excel as a software engineer, be a professional not an amateur
Posted by Patrik Löwendahl in Methodology, People on September 2, 2009
Jeff McArthur is a frequent blogger and tweets a lot. He’s one of those random (at least for me) guys you stumble across that writes good stuff you want to read.
During this weekend he’s put out a lot of about the difference between a professional and an amateur. Most of them was in general terms and they all got me thinking. What do I think defines a professional software engineer? What is our profession all about?
Some label most of us technology geeks, and to some degree this is very true. I like technology. I like software and hardware and I play games. A typical description of a geek.
But is our profession only about technology? It plays a huge role indeed; technology is part of our toolbox. But is it all?
I would argue that technology is just a small part of what we need to do to be considered a professional. Here is my list, in no particular order:
- Dedication – be dedicated towards delivering the BEST solution, not just A solution.
- Continuously seek more knowledge – to be able to decide what is the best solution, you need to have a broad toolbox with a understanding and competence in many technologies, methods and tools.
- Strive to deliver quality – not just quantity. A good piece of software doesn’t only do the job. It’s also reliable, stable and maintainable.
- Pride – software engineering is a craftsmanship. You need to put pride in what you create.
- Question your skills – at all times. There is always something to perfect, something to get a little better at.
- Welcome feedback on your work – always look for opportunities to get your work criticized by everyone. Listen to it and change.
This seems to be oddly general. Being a professional in any trade means a lot of the above, but in our trade where business and technology moves faster then a high-speed train. We need to constantly be on our toes. Putting in an effort to learn, evolve and excel. When we do that, we can start to count ourselves as professionals in the profession of Software Engineering.