Monthly Archives: December 2014

20 principles for a successful start to a career

adviceThis blog post has been in the making for at least 6 years and will likely be my longest one. Since then I have been gathering my advice for new joiners. Usually someone new who joins the company makes very similar mistakes (of course not everyone is making all of them ;-)), So I thought I share my view of some of the principles to follow with the rest of the organisation. This will probably be kind of long-ish, but I hope it will help some of the new joiners and perhaps even some of the more seasoned professionals as I try to explain the perspective of the supervisor for some of the principles (rest assured a similar post for manager is already in the backlog as well). As with all career advice, please only follow what makes sense to you. This list is meant to provide you a reflection point to consider your behaviour and what would be the most effective for the organisation, not a one size fits all approach. Let’s dive in…

  1. Managerial Economics 101 – I learned this principle from my good friends at www.manager-tools.com and it is probably the most liberating and useful principle to understand. Managerial Economics 101 says that if two people can perform the same task to similar quality, the more junior or less paid person should do that. The idea being that this frees up the other person to do higher value work. What does this mean in practice? As a manager it means you should not feel guilty to delegate to your directs work that is not exciting. Often we feel bad delegating mundane or repetitive tasks, but if you think about this principle you realise why you have to delegate. As a direct looking at this you should do the same from the other side, pick up all the work that your manager is doing that you could do for him, volunteer to write meeting notes or perform routine tasks. Trust me, your manager will love you for it.
  2. Never Be Defensive – If there is a personal trait that can be really irritating, it is defensiveness. It can make any feedback discussion pointless. I suffered from being defensive for a good part of my career and to this day it takes effort not to get into defensive mode when it feels like there are so many good reasons to defend myself. It just never makes things any better, even if it was not your fault. As a manager who deals with someone being defensive, consider using a “shot across the bow”. Give your feedback and then walk away if the other person becomes defensive. Your feedback has only one purpose: To improve future performance. After giving your feedback the other person either performs better (in which case engaging with the defensive behaviour would not have made a difference) or not (in which case you will get a second chance to give the same feedback, this time with more evidence). If you are the direct, whenever you say “…,but…” or “someone else’s fault” step back to reconsider, feedback is a gift given too rarely. Try to find some truth in it and action on it rather than spending your efforts defending yourself, you can always be better, can’t you?
  3. Networking = Giving Freely – When you join an organisation everyone tells you how important it is to network. But what does this mean? My answer is, give freely when someone is looking for help, share material that you think could be of interest, offer to step in when someone needs help. That’s how you network. Your name will get out there as someone helpful and all the positives of network will become available to you, your name will be known and even better, when you need help, others owe you one. That goes a long way. Also look at principle 19 – personal brand.
  4. Every Feedback Form Will Have One Thing You Disagree With – It is my experience that people try to be helpful with their feedback. But sometimes they don’t get it right and that means that usual in feedback forms you will see at least one thing you disagree with. Remember not to be defensive about it, let it go, it’s just one piece of feedback. Focus on the items of feedback that make sense to you and address those. If the same point comes up again however, you should look closer. Perhaps you have just discovered one of your blindspots. And identifying those is worth a lot.
  5. Do Ask Questions – No one expects you to be perfect and especially when you join a new project a lot of the language will sound like from a foreign country. TLAs (Three Letter Akronyms) everywhere. It is always better to ask for clarifications than to be silent and spend a lot of time working it out. The same goes for new processes or other questions, you are excused for asking, you are not excused for misunderstanding or not being able to do your job because you didnt ask. I remember working for a company and trying to figure out a process myself, just to spend hours on something my colleague could do in minutes. I looked like a fool at the end of the day for not asking.
  6. Too Many Blank Questions Make You Look Lazy – In general questions are good, but if you have the opportunity to do research before asking the question, it looks lazy if the answer is one google search away. It is always better to ask questions of clarifications in the form of “Does process x mean I have to do a, b and c” rather than “how does process x work”. Just asking one blank question after the other makes it sound as if you want someone else to do your job.
  7. Communication Is What the Listener Does – It does not matter how much you try, sometimes you will get misunderstood. And it is not the listeners fault, you have to consider it yours and try again in a different way: with a picture, rephrasing it or by describing it from a different perspective. It is all too easy to say I have communicated it to him, if the listener does not understand it. And after all we are measuring outcomes, not intent. So make sure that the listener understood what you said and try to adjust your communication style to the listener. The only one who can fix a situation of misunderstanding is the one who is speaking, the listener cannot help much other than trying to show that he did not understand. And to make things easier for yourself follow BLUF, Bottom Line Up Front – Start with the summary and then give the narrative, it will make it much easier for the other person to understand what you are trying to communicate.
  8. You Can Only Change Yourself – Many times people complain about their colleagues and my answer is always the same, you wont be able to change him or her, but you can change your behaviour. If you want to improve the productivity of the team find out how you can adjust to the others style and hence improve the team. You can give feedback to others, but the only person you can change is yourself and by adjusting your own behaviour you can improve a situation a lot even if the other person does not change.
  9. You Are Responsible For Your Feelings – How many time have I read an email and got angry/disappointed/mad only to step away from it and realise that it is my own reaction to the email and not the intent of the writer. Or you sit in the car and the driver in front of you is driving super slow, he is driving you mad. Wait – he is not driving you mad, he is just driving in his own style, you are driving yourself mad. I have experienced many times that you can choose to get angry or choose to remain calm and the situation will play out accordingly. It is you who is responsible for your feelings, many of us get angry at work, but the best of us don’t show it and the even better ones don’t get angry at all, they choose to remain calm. It’s no excuse to say your colleague made you angry, you always have the choice. My advice: step away, breath in, breath out, move on…
  10. A Task is not Done Until Status is Communicated – If some assigns you a task or delegates something to you, he actually assigns you two things, the task itself and the responsibility to communicate status. At the very least to tell him when you are done. From an organisational perspective the work is not done until someone knows that it has been completed and can act upon it. You are unlikely doing the task for the task’s sake, it is because something else requires the output or someone requires the information, so make sure the completion of the task is communicated. If the tasks will take a long time, even if not asked explicitly for status, communicate the status anyway. If you are on track it will make your supervisor happy to know and make him not worry, if you are not on track early communication will allow him to help you out or at least set expectations that it might get a delayed with other stakeholders.
  11. Admit Mistakes Early – On a related note, admit your mistakes early and openly. It is very unlikely that you will be able to cover up your mistakes. If you are open about it and ready to fix the issue at hand, people will forgive you. The longer you wait and the worse the situation gets. Even worst if someone else takes the hit for you, and later it is discovered it was you, the implications will be much more severe. The ability to admit mistakes and to apologize goes a long way, and a heartfelt apology can be a strong means to build relationships that would otherwise be ruined. Be the better person and apologize first.
  12. You Are Allowed to Make Mistakes, Just Don’t Repeat Them – One of the most influential pieces of advice early in my career was someone telling me this. And they were right: you have to make mistakes to learn, but if you repeat them you will receive negative feedback. After all there is truth to the saying that “Good judgment comes from experience, and you gain experience from bad judgement”. There are a few things to take away from this – a) you should be courageous to try things out, b) you should make sure that if you make a mistake that you understand how to learn from them and avoid them in the future and c) you should keep trying things even if the mistakes hurt. As a supervisor you also need to understand this and allow people to make mistakes and not punish them for a mistake. You should look out for the ones that don’t learn from their mistakes, but the others will improve quickly.
  13. Answer the Question – If someone asks you: “Are you on track with your work?” there are only two possible answers: Yes or No. Anything else is a distraction. The first word out of your mouth needs to be “yes” or “no”. The person asking the question will ignore everything you say until he gets that answer. I myself have the same tendency to try to explain the answer before giving it, but trust me it is a bad habit. I have now learned to think about the answer, give the yes or no and then go on to explain the situation. And don’t try to get away with “Yes and No”. The same by the way is true if someone asks you for a number, the first word out of your mouth should be a number, not “well, let me explain”. This will be difficult initially, but it is very important to be respected and listened to by leaders.
  14. Don’t Be a Film Critic – No one enjoys listening to someone complain. I know everyone needs to vent once in a while, but it is not a very productive behaviour. Try not to vent to your boss or anyone you work with. If you find something to criticise do so in a productive manner and with an idea how to fix it. And honestly the best way is to recommend something you can do to help fix it, otherwise it just feels like a film critic who sits there talking about the movie, but who wouldn’t be able to make a better movie himself.
  15. Do not Be Idle – If you have nothing to do, that is not an excuse for long internet surfing sessions. There is always so much to do and there is likely someone around you who needs help. Reach out, offer help. And if there is no one in need of help, spend the time improving your own or the teams productivity by working on a better template or process. Not having work assigned or being blocked is tempting for a bit of idle time, but it is likely that it will come to haunt you later; either in your performance rating or because you are getting used to it and are less productive later on.
  16. Ownership and Accountability is Different From Actioning – It is always nice to delegate some work to someone else, but let’s be clear: it is still your accountability that it gets done, you still own the task. I personally don’t accept it if someone who I gave a piece of work to later tells me he delegated it and it was that persons fault. You don’t have to do everything yourself and as of principle 1, you shouldn’t. But own up to it and protect those you delegate to, especially if they are your team members. The buck stops with you even if you try to push it to someone else. In that case it is just a double whammy, you didn’t get the work done and you tried to deflect your accountability which makes you look bad.
  17. No One Other Than Yourself is Responsible for the Quality of Your Work – A related point is that you cannot rely on someone else to test your work, it is great if you have other testers or QA people involved to help find problems, but rest assured that you are accountable for your work. At best you will both be in trouble, but just creating something and not checking the quality yourself is not acceptable.
  18. Trust But Verify – The last related principle is that of trust. The speed of trust is amazing, try to micromanage someone and you will quickly notice how time consuming it is, trusting someone makes transactions much faster. There is a but – you need to verify the work when it comes back. You cannot just forward it to your boss without checking. Remember principle 16.
  19. Create Your Personal Brand – The longer you are with an organisation the more important it is to have your personal brand. You should stand for something – the guy who is good at x, or the guy who is passionate about y. There are many different aspects of this: Social media like blogs and yammer let you share your views with the world, working in related areas and doing a good job gets the word out that you know what you are doing, going to community events and conferences and talk to peers about your passion creates your network. All this belongs to creating your brand. If people know what your brand is, you will be surprised how many opportunities turn up on your doorstep.
  20. Be persistent and accept silence – This is my personal favourite and one that I think helped me the most in my career. There are things that I would like to change in my organisation, or on my project or in my community and none of that happens over night. You send emails with improvement ideas to people and often nothing comes of it, there is only silence. But if you are persistent at some stage someone will listen and something will get done. It will take a while, but I do believe each one of us can make a difference if we are persistent, remain positive and constructive with our feedback, and then one person at a time we will make our company, our community and our network of people a better place to be.

Okay this has been a pretty long post, as I said this material has been with me for a while. I encourage you to come back to this post once in a while as I am sure you will find another principle all of a sudden makes sense or it encourages you to try to improve in an area you didn’t have the bandwidth to last time. Getting better never stops…

Picture: Advice by Laughlin Elkind
License: Creative Commons

Can you do Agile development with Packaged Software?

I have heard this question many times and only recently realised that the person asking the question and me hearing the question had a different understanding of what the question means. Let me try to explain. The question posed by this blog post can be interpreted in two ways:

  1. If you use packaged software like SAP or Siebel, can you use an Agile methodology?
  2. If you want to be Agile, can you use packaged software?

questionmarkI know the difference is subtle, but the impact of the understanding and the response is amazing. I had this realisation when talking to a colleague of mine who is training an Agile course with me in the next week. My response to both questions would be yes, the difference being that to the first question I would say “YES”, to the second question I would say “yes, but…” It is easiest to see the difference if you consider the alternatives in question: in the first question the alternatives are Agile or Waterfall, in the second question the alternatives are Packaged Software or Custom Software.

 

Let me explain – If you want to be agile, you have a couple of things you want to achieve, so lets look at some of them when considering packaged software

  • Faster time to market – my experience tells me that you will not be as fast with packaged software as you would be with a custom solution in many cases (just the sheer size of the software is often significantly larger)
  • Decoupling of dependencies – this is much harder in packaged solutions
  • Use a lot of automation and DevOps practices – this is a little bit trickier with packaged software
  • Want a first release quickly – if you know which product to choose you might be, but usually packaged software requires more requirements analysis and fit-gap analysis up front to choose the right product

So if you want to be really Agile and use DevOps practices and autonomous self-directed teams with little dependencies then packaged software might be harder to use, hence the “yes, but…” You should ideally choose a custom solution or perhaps a SAAS solution in that case (but be careful, many SAAS products are not DevOps supportive either).

Now lets look a the other question: Assume you already use Siebel or SAP, can you use an Agile methodology? Here the answer is a loud and clear “YES”. Think about all the good things about Waterfall – they all still exist in Agile just better, if you do it right. You have the rigor of change control (just for a shorter period – the iteration), you have extensive testing (just automated and within the iteration), you have as much or as little time for analysis as your require in the discovery phase. You will likely not see the same results in regards to time to market as if you would use custom software, but I bet you get better results than if you do waterfall with packaged software.

So yes – I think I (and many others) have responded to the wrong question.

To give you an idea about my experience: I have supported Agile projects for Siebel at many different levels of scale and usually with 2-3 week iterations. I have implemented some of the core practices of DevOps around configuration management and automatic deployments for Siebel and we are currently in the process of implementing automated testing as well (hopefully including TDD down the road). It is absolutely possible and I think most of my colleagues would agree that using Agile is preferred over Waterfall for Siebel if you do it right (perhaps packaged software is a little bit less forgiving than custom if you don’t do it right – but that’s for another discussion). Could we be faster and better if we could use a custom solution? – absolutely. But that is a different question now, isn’t it? 😉

Picture: Question Mark by Marco Bellucci
Licence: Creative Commons

The need for an Onshore Technical Apprenticeship model to counter the falling ladder

This post is a little bit different to my other posts, it highlights a challenge that most of us in the western world is facing, now that offshoring and nearshoring is just a reality of life. I think companies need to think about an onshore technical IT apprenticeship program that allows them to build more technical skills onshore. And it does not matter whether you are a consulting company, an IT shop or a manufacturing business, software is an important part of your business and you better keep building the skills required to run it.

When I started working for my current employer over 10 years ago everyone did some kind of technical work as a new joiner, I personally did some Cobol programming, many of my friends worked with Java. Then as we got more and more senior we had a good understanding of what it takes to develop a solution.

Nowadays if you are trying to staff a technical onshore role, it is actually not easy to find people and often you look to colleagues from offshore centres to help out. A lot of project and program management is still being done onshore and many of the current leaders still come from my generation of “Been there, done that”.
Unfortunately in many IT teams onshore it is today more important to learn exactly 3 technical skills: Excel, Powerpoint and MS Project…

ladderA bit of background:
The problem I describe is what I call the “Falling Ladder” or which in a TED talk was called “sinking skill ladder” (around 10:50 into this video http://www.ted.com/talks/nirmalya_kumar_india_s_invisible_entrepreneurs/transcript?language=en#t-698501) – once you have given all the on the ground technical work to delivery centers, you will soon realise that the people onshore do not have the knowledge to design solutions really well, so you start handing over design as well. Soon you don’t have skills to really project manage anymore as all you can do is manage the spreadsheet, so you hand over project management as well. And then soon all there is onshore is the demand creation either through sales externally or internally. And would you trust a Technical Architect who has never seen code? Okay – this is a slight exaggeration, but you get the gist.
I had a friend who recently left the IT company he was working for and after 2 months of job search we caught up, here is what he said: “It is actually quite hard to find a job if you don’t have any skills beyond excel and MS project, the market is looking for people who understand the technology you are dealing with”. You end up with two choices you get some of the younger guns for the newest set of technologies or someone much older who still has the technical skills of well established technologies, but is that sustainable?

So what should you do:
I think you need to find a way to create the next generation of technical leaders. Technology and specifically software will remain an important part of your business. It is unrealistic to expect to all IT work in-house and onshore, but to really drive technology to the extent that you need to, it is important to retain technical talent. Create some roles in your team that are onshore even if it is unpopular. The investment you make here is small and will pay back easily if you can keep good technical people around and grow them as the next technology leaders in your company.

Picture: The Fall by Celine Nadeau
License: Creative Commons