We’re All in Sales

Posted on July 18, 2015 by Big_GH

It is often said that everyone who works at a company is in sales, and there is some truth in that.  Every time you interact with someone outside of your company you represent your company.  You are being evaluated, and by proxy, the company you work for is being evaluated.

It’s great to have a friendly, caring sales team who really understand the needs of their customers, but if the person installing or supporting your product is grumpy or rude, then all that good is gone and that customer will think twice about purchasing from your company again.  It can be very useful to remind the whole business of this fact, and a shorthand way is to say “we’re all in sales”.  But just because you say “we’re all in sales”, doesn’t mean you need to treat everyone as a sales person!

Sales teams have targets and each member of that team usually has their own target.  Performance and compensation is heavily linked to those targets.  Whilst that can mean some great bonus payments when things go well, if someone fails to meet those targets they could end up losing their job!  Sales teams usually enjoy a bit of competition – who’s sold the most, who’s won the biggest deal etc.  This combination of visible, measurable targets with competition is seen as a formula for great performance (or an easy way of getting rid of the weakest members).  The success of the team is driven directly from the success of individuals, i.e. if everyone meets their target, the team meets its target.

Teams of knowledge workers are not the same.  The performance of the whole team is what is important, not individual performance.  Team members often need to work together to achieve results, and the more interaction they have, the more the value of each individual and their actions becomes harder to determine.  If the product doesn’t release on time, then the whole team fails.  The reason for the release being late could be any number of different issues, some of which many not even be under the control of the team!

Treating knowledge workers as sales teams creates many issues.  Firstly, competition amongst people who need to work together to succeed is going to destroy the team (see this article on Business Week that talks about the Hidden Cost of Internal Competition).  If individuals are measured on individual performance then they will optimise for their own performance, even at the detriment of the team.  DeMarco and Lister considered competition one of seven items that could destroy a team – they called this effect Teamicide in their classic Peopleware book:

“Here are some managerial actions that tend to produce teamicidal side effects:

  • Annual salary or merit reviews
  • Management by objectives (MBO)
  • Praise of certain workers for extraordinary accomplishment
  • Awards, prizes, bonuses tied to performance
  • Performance measurement in almost any form”

So, whilst the catchy phrase “We’re All in Sales” is important when considering your customers, it is definitely not the way to create a highly effective team!

 

Advertisement
Posted in agile, costs, information, listening, motivation, peopleware, process, Project Management, software development | Tagged , , , , , , , , | Leave a comment

The Twilight Hour

Posted on May 13, 2015 by Big_GH

I never consciously knew this existed until recently, but now I’m aware of it I see it all the time.  The actual time of the Twilight Hour varies from organization to organization, from team to team and even from day to day, but it happens, and being part of it can have many benefits.

It is entirely possible that there are several Twilight Hours in a working day, one at the start of the day and one at the end, but I’m only aware of the one at the end of the day (hence the Twilight name).

As people leave for the day, those left behind also start to unwind.  The mood turns to reflection and evaluation of the day and plans are formed for the future.  Information is exchanged, and the normal barriers of communication are lowered. People from different teams gather, they get up from their desks and share knowledge.  There is a lot of power in being part of that knowledge share.

In much the same way that smokers gather and share information, or that people who lunch together share general company knowledge, the Twilight Hour can have the same impact.

As a manager, I’ve shared information with individuals, that whilst not a secret, it was still information that the rest of the team didn’t have at that moment.

I’ve also felt individuals on edge waiting for me to leave.  Their twilight gang was ready for a good gossip and I was in the way!

So beware of the Twilight Hour, it can be a force for good in much the same way as many other encouraged company activities (nights out, socials, shared lunches), but with fewer people it can encourage negatives as well (bitchiness, malicious gossip and rumours) and bestow additional knowledge on individuals who perhaps shouldn’t have that information.

 

 

Posted in information, listening, peopleware, process | Tagged , , , , | Leave a comment

Applying for Jobs and the Agile Job Search

Posted on December 11, 2014 by Big_GH

I’ve written before about how I approach recruitment and I’ve even given a talk on it, but recently I’ve been on the other side looking for my next role.

There are some parts of my own recruitment process I will definitely be improving as I now understand more about the things matter to an applicant.

Firstly, waiting for feedback after applying can feel like forever.  I’ve previously waited weeks before contacting people for interviews, despite getting feedback later that this was a long time!  I will now try and give feedback within 3 working days of receiving an application (and will commit to that in any automated responses that I might send to an applicant).

The next thing I experienced was how you really need to sell the company and you should involve everyone in this process.  I was put off by grumpy receptionists, untidy buildings and late starts to interviews.  All things that I might have previously considered minor, but with other items appearing equal then they could have made the difference!

The interview questions that are asked also reflect the company.  For some roles I engaged in pair programming to test my technical knowledge, others I was asked about more obscure areas of C++.

The biggest issue I have with interview questions and a question I often ask myself, is what insight do I get if someone answers incorrectly?  The opposite is easy, if I ask about virtual destructors in C++ and I get a good answer then I have learnt something about their C++ knowledge, but if they don’t answer very well then what have I gained?  Do I really need someone who already knows this information or would I be happy spending 5 minutes explaining the answer and having someone who can learn?  Unless you really must have someone with this knowledge then you either haven’t asked a question that helps you evaluate, or you could be turning away a lot of suitable candidates.

Johanna Rothman has often written about how the shortage of skilled workers is being made worse by poor recruitment practices.  She suggests hiring for cultural fit and helping people gain the skills they need to fill the role.  After all, when I was looking for a new role, I was looking for somewhere that could also offer growth for my own career not somewhere where I already knew everything.

To give myself a boost in my job search, I attended a 1 day seminar in London with Johanna Rothman.  I’ve since bought her book, which is also highly recommended.

The course itself ran with an agile approach, being tailored towards the people on the course.  It was an amazing day, not only was Johanna brilliant, but the encouragement and support from the other 3 attendees was an unexpected and powerful bonus.

Whilst I didn’t put too much of Johanna’s headline ideas into practice, I can see how well they would work and I often stumbled into the mistakes they were designed to avoid.

Some wise words proved very wise later; Johanna said that getting a new job is hard, and there will be many ups and downs along the way.  I had moments of positive feedback and exciting roles to apply for, but also many lows of rejection and frustration.  I especially disliked that feeling of not being in control – I knew I wanted a new job, but couldn’t find anything suitable to apply for or was unable to progress roles I had already applied for.

I also found that I shouldn’t rely on other people to progress my application, especially recruitment agencies.  Despite getting automated acknowledgements to say they had received my application, I still found they’d gone missing when I chased a few days later!  Keeping a list of what I’d applied for, through which contact and agreed next steps would have been a lot smoother if I’d written it down rather than trying to keep it in my head!  Sorry Johanna!

The one part of my job search that I couldn’t get working, despite Johanna’s advice was in finding roles to apply for.  There’s a lot of research that suggests many roles are not advertised and are filled by people meeting the hiring manager, but I didn’t manage to find them.  Instead, I found a daily search of Indeed to be the most effective.  I was able to setup about a dozen searches and check for new entries in each of those categories easily each day.  This was made even easier using the Indeed phone app.  I also setup an rss feed from stackoverflow careers, which has some amazing jobs, but I didn’t find many in the locations I was looking for.

Most roles were advertised through recruitment agencies, and I ended up uploading my CV to cwjobs and jobsite in order to apply for a lot of them.  This in turn triggered a lot of contact from other agencies for other roles.

I’m pleased to say that I have found a new role and I’m really enjoying it.  It’s always sad to leave somewhere, especially as I’ve been there for so long and have personally recruited so many of the great people who work there, but the time was right for a new challenge.

Posted in News, recruitment | Tagged , , , , | Leave a comment

Tribal Leadership

Posted on September 9, 2014 by Big_GH

One of my favourite books of 2013 was Tribal Leadership:

I’m not going to go into the details here as there are plenty of better places to get that information.  Buy the book, check out this TED video or listen to the audio book

Go on – the video is only 16 minutes long, I’ll wait.

I first came across Tribal Leadership from the excellent Portia Tung at the equally brilliant BCS SPA mini-conference.

In her session, she explained the basics of Tribal Leadership and then set us up in teams with the task of making paper cranes:

Paper Crane

A Paper Crane

I didn’t really understand what it was about at the time, but I think I do now:

  1. Initially making cranes was hard, the instructions were poor, it wasn’t much fun – so we were experiencing stage 1, “life sucks”
  2. Then some people started completing the task, I wasn’t able to make a crane, so that was stage 2, “my life sucks” (but I understand that not all life sucks)
  3. Once I could build a crane I felt good and proud of my accomplishment.  This was stage 3, “I’m great” (with the implied stage 2 for anyone still struggling, “and you’re not”).
  4. The last round was as a team competition – trying to build more cranes than anyone else.  This was stage 4, “we’re great” (and you’re not).
  5. We never got to stage 5!

Since then I’ve seen some brilliant individuals stuck in stage 3 (I’m great, you’re not) and so struggle to create a team.  I’ve seen people exhibiting stage 3 behaviour that brings about stage 2 (my life sucks) reactions in others.  I’ve seen glimpses of stage 4 and have been working on exhibiting that behaviour and encouraging others to reach that stage as well.

I’ll probably write more about Tribal Leadership in the future as I’m a definite believer.

 

Posted in motivation, reading | Tagged , , , , | Leave a comment

Kanban with kids

Posted on June 29, 2014 by Big_GH

I recently had a day at home with my kids and we decided (well I decided) that we’d try a new game.  I explained the rules:

“Today we are going to get lots of jobs done, but before we do anything we are going to divide up the whiteboard into columns; to do, doing and done.  Next we are going to write all the jobs we’d like to do on sticky notes and place them into our to do column.  Finally we’ll pick a job to work on and move it into doing.”

For those of you who haven’t come across this technique before it uses a kanban board.  It is often used in agile or lean development as a way of visualising work, limiting work in progress and providing a focus on getting items to done.  Here’s our board at the start of the day:

kanban_board

Kanban board at the start of the day

So what did we learn?  Well the first thing I learnt was that kids love using sticky notes, they loved writing on them and moving them across the board.  I’m pretty sure that adults do too!

When we started, our target was to get all jobs into done before the end of the day.  We didn’t spend any time estimating the tasks as that wasn’t important to us, the time was better spent actually doing the tasks.  As you might expect, we didn’t finish all the tasks, however the sense of achievement from the large number of tasks we did achieve was great.

We also uncovered a lot of the common issues I also see at work.  Some of the tasks in our backlog (to do column) were too vague and were actually several tasks in one.  For example, one task was to empty the wash basket.  That was actually several steps; put first set of clothes in washing machine and wait for it to finish, hang out wet washing when finished, collect dry washing from outside and then put away.  With a sprint of just a single day, and several washing loads to do, having a single task of many hours was not granular enough.

As Dad in charge (product owner) I was able to groom the backlog, breaking down these epics (empty wash basket).  I was also able to look for a natural order to the tasks, e.g. once the dishwasher was running we had an hour for other tasks whilst it completed its cycle so it made sense to prioritise that task above some others.

The final item we learnt was in defining our acceptance criteria, i.e. what does done look like?  One task was to tidy a bedroom.  This was too vague and subjective, who decides a bedroom is tidy?  Instead we employed a technique called time boxing.  The task became “spend 15 minutes tidying bedroom” with done now clearly defined as 15 minutes worth of tidying.  After 15 minutes that task moves to done, and as product owner I could evaluate and decide if I wanted more effort on tidying that bedroom and create a new task in the backlog.

It’s perhaps worth noting that a more traditional waterfall approach to this problem of whether a bedroom is tidy or not would have been to produce a more detailed definition of requirements up front.  I could have listed all the items that needed tidying away, that the bed needed making, bins emptying etc.  However, the common problem is that not only does this definition take time, it can also miss vital parts.  If I forgot to say that I didn’t want sweet wrappers on the floor then it would be possible to say the bedroom was tidy (according to the requirements) even though as product owner I could see the wrappers on the floor and so know that the room wasn’t tidy!  Another common problem with this approach is when the requirements are actually unclear, e.g.  I know the bedroom is untidy, but I don’t know how to make it tidy, or how tidy I actually need it.  A time box approach allows the team to spend an agreed amount of effort and the results to be evaluated.  No extra effort is wasted making the room tidier than needed, and some progress may help me as product owner to realise what further parts of tidying the room are important, e.g. Now I can see the carpet as the toys have been tidied away, I now want to focus on making the bed and taking dirty pots downstairs, but that is probably all I need.

Here’s our board at the end of the day:

Kanban board at the end of the day

Kanban board at the end of the day

Posted in agile, estimates, kanban, planning, Project Management, software development | Tagged , , , , , , , , , | 1 Comment

Who Said the Software’s Late?

Posted on April 16, 2014 by Big_GH

We are always hearing about software projects being late.  My current experience tells me that my own software team will deliver their software later than planned.

So why is that?  Let’s firstly get the assumption that the team is somehow lazy, incompetent or unmotivated out of the way.  Good software developers and development teams just aren’t like that!

Right, so we have established that everyone on the team wants to succeed, they are working hard, but still the deadlines come and go and the software ends up late.

I think this can all be tracked back to estimating and we all know that estimating is hard.  I think the big question when someone decides that a software project is late is “who decided when it should be finished anyway?”  Simply changing the end date takes a project from being late to being on-time or even early.  This fact is so important, yet estimating is rarely given enough importance in order to set a realistic end date for the project.

One of my favourite responses I heard someone give to the question of when their software would be ready was “it will be ready when it’s ready”.  Really unhelpful in terms of planning the myriad of other activities that depend on that software being complete, but entirely truthful and sums up both the difficulty of estimating and the desire to avoid setting unrealistic expectations.

Let’s draw some pictures.

Firstly let’s look at a software project as a series of tasks that require completing before the project is complete.  You might see this on a GANNT chart:

GANNT1

Note: This is a very contrived example, simply to illustrate the point.

In this example, we have broken down our project into 3 tasks, all of which depend on the previous task completing before we can start the next one.  Our project plan shows us starting on the 6th January and finishing by the 24th January.

Now let’s take a look at the plan once the project is complete.

GANNT2

Several things now become clear:

  1. There weren’t just 3 tasks involved in this project, there were 5.
  1. Of the 3 original tasks, they were better expressed as several subtasks, the combined total of which took longer than originally planned.
  1. The project finished on the 4th February, not the 24th January as originally planned
  1. If the team (or project manager, sponsor or whoever is in charge of producing the plan) had produced a plan that looked like reality (version 2) then they would have been praised for completing the project on time.

The ideal project plan is therefore one that accurately predicts the future!

Don’t confuse poor estimation with poor performance (or the ability to set low expectations and then exceed them as a mark of good performance).

Posted in agile, costs, estimates, information, planning, process, Project Management, software development | Tagged , , , , | 1 Comment

The Agile Manifesto

Posted on March 20, 2014 by Big_GH

The Manifesto for Agile Software Development is a really powerful piece of work and something I really relate to. Not only have some of the finest minds in the business been part of its creation, thousands of others have found that it relates to their own experiences and have been proud to sign up. I signed the manifesto myself back in March 2011, but recently it’s become more relevant than ever.

I’ve been part of a very successful business, the number of software developers has grown from a dozen to nearly 30 and we’ve subdivided into different teams working on different aspects of our product. You can read more about those changes in my series on progress; Part 1 – How things used to be and Part 2 – How things are now.  We’ve specialized and diversified from a company of developers to one with many different roles and departments. The challenge now is to try and maintain the aspects that work and made us successful whilst encouraging the new changes that will help us continue and become more successful.

Ask most people what a successful development team looks like and they’ll probably tell you that it is “agile”. But what does that mean? That they work in small blocks of time called sprints? They have fancy boards with kan-bans and burn down charts? They talk of user stories, planning poker and a product backlog? They practice pair programming, daily stand ups and retrospectives? Well all of those items could be considered agile practices, but for me it is simpler than that. You need to have an agile perspective, and the Agile Manifesto sums it up perfectly. Let’s look at each of the items in the manifesto in turn:

Individuals and interactions over processes and tools

Let me say that again, individuals and interactions over process and tools. Lots of those so called agile practices that I listed before are aimed at improving the interactions, but really they are just processes and tools. A really subtle difference perhaps, but one that means so much in practice.

Working software over comprehensive documentation

We deliver a high quality product that in general works very well. However, where we lack documentation we are heavily criticized and the documentation is seen as the cure for all issues. “If only we had that documented then we wouldn’t have this problem”. I doubt it. People just don’t read! (http://uxmyths.com/post/647473628/myth-people-read-on-the-web)

Customer collaboration over contract negotiation

One of the biggest reasons we became so successful was our ability to listen to our customers and offer them a solution to their particular need. We had no real need to check that our contracts were water tight (and many certainly weren’t) as they were rarely disputed. We now take contract negotiation very seriously.

Responding to change over following a plan

Being very flexible in our approach a plan was more of a conversation piece. Something to discuss, but rarely accurate as change was inevitable (and the right thing to do). Now a plan needs to be agreed and executed with change controlled and removed where possible.

The manifesto concludes that “while there is value in the items on the right, we value the items on the left more.”

If you placed the items in the manifesto on a large set of weighing scales, you would want the items on the left tipping the scales to the left. If you add more process and tools, more contracts, more planning, you need to also add more focus on individuals and interactions, customer collaboration, and more responding to change otherwise. It is all about getting the balance right.

Posted in agile, software development | Tagged , , , | Leave a comment

Geekup – Language Showcase

Posted on February 1, 2014 by Big_GH

I was recently given the opportunity to be curator for the Nottingham Geekup community.  As a regular attendee for several years and previous speaker, I thought this was a great opportunity to give something back.

As curator, it was my task to find the speakers for the night and arrange the format.  That didn’t sound too hard and certainly not as nerve wracking as actually giving a talk myself.  However, once I’d volunteered I quickly realized that my pool of potential speakers was quite small.  Never mind, I only really needed to find 2 or 3 speakers so it shouldn’t be that hard.  Encouragingly, as I mentioned this need for speakers I quickly had 2 or 3 volunteer, but their talks didn’t fit into any kind of theme.

I was also determined to try and make the night a little different to previous events.  One item that had concerned me over previous months was just how forced the coding exercises had been.  I was pretty sure I didn’t want to involve any coding this time.

As time passed, I got more focused on finding a suitable format for the night and would need to let people know I needed them for a talk pretty quickly.  I also thought it would be a good idea to press home the benefits of attending geekup to my work colleagues.  I collected a number of talk ideas and asked my team to vote on the best ideas with the premise that if you voted for a topic you were also committing to attend.

A last minute suggestion of a “programming war” was voted the most popular, although a few people expressed concern around the adversarial language of such an event.

This changed the nature of the event completely.  Now it really only made sense that I ran the night completely and that it would be completely code focused!

In order to address some of the competitive nature of the event I rephrased it as a “language showcase” and focused more on learning than competition.  I also felt it important to try and do the coding a little differently than before.  Whilst we have done many coding exercises at geekup in the past, we hadn’t spent much time trying to analyze or compare results.  This became the focus for the night and also helped enforce the showcase part of the title.

Overall, I was pleased with the way the night went.  I really enjoyed hosting the night and seeing so many people engage with the problems and share their results afterwards.

If you want to take a look at the slides and try the challenge yourself then take a look here:

https://docs.google.com/presentation/d/1B_qr3G-4CkuqHuO_6W2HjDtJKi5F-tLpsZc_4ZaS96A/edit?usp=sharing

Posted in agile, community, software development | Tagged , , | Leave a comment

When People Leave

Posted on August 4, 2013 by Big_GH

I’ve talked a lot about recruitment and hiring people in the first place, but what about when people leave?

How you deal with people when they leave, and in particular during their notice period, can have a big impact on how they remember you and your company.

Firstly, lets acknowledge that when someone tells you they want to leave it hurts. You may have known them a long time, considered them friends and offered them the job in the first place.  It feels like a huge rejection and you can feel foolish as if none of those previous experiences mattered.  This is a natural reaction, but don’t let it shape your actions.  Take a deep breath, bite your tongue and calm down.  It was probably a difficult decision on their part and they will appreciate a professional response. This is a stressful time, so taking any emotion away can be a big help.

Secondly, once the dust has settled, make sure you use the time that person has left with you wisely.  You need to make sure all the knowledge they have is not lost when they leave.  You should also try and learn the reasons for them leaving.  Whilst everyone is different, if there is something you can discover, improve and prevent others leaving then it is worth listening.  Again, take the emotion out of the situation, encourage an open discussion and don’t argue.  You may hear a number of criticisms of yourself, your colleagues and your company; this can hurt, but don’t react emotionally.  A bad reaction can simply end the conversation and prevent you learning any more valuable information.  Instead, you need to listen, take note and thank the other person for their honesty.  You don’t have to agree with the criticism, but you shouldn’t just dismiss it.

Whilst it always has an impact when someone leaves, by reacting in the right way you can at least try and get something positive from the situation.  Ex-employees can still be friends and may want to work with you again in the future if you handle this situation well.

Posted in listening, peopleware, recruitment | Tagged , , | Leave a comment

Building Roads

Posted on May 14, 2013 by Big_GH

roadworks

We are often told when managing software projects that things should be more predictable, more repeatable and that our projects are less in control than others.  As we saw previously, I’m not convinced.

I’ve been watching with interest over the past few years as a major road upgrade has taken place near my home.  This was a 3 year project to convert a single carriageway into a dual carriageway and involved rerouting the road, creating some new roundabouts and bridges – including one that carries a railway line.

Overall, I’d say I’ve been reasonably impressed with the way this project unfolded.  It started on time, appeared to progress on schedule and was officially opened on time.  However, whilst the signs along the road side state that there would be disruption until Summer 2012, we still have cones along the roadside and overnight closures of certain sections.  I’d say that this project is definitely not complete!

So what happened?  And what can we learn about our own projects here?

Firstly, predicting timescales on any large project is hard.  The combined uncertainty of so many tasks can add up to make predicting an end date more of a guess than a science.  It was interesting to see that the end date they used on the road signs was Summer 2012, not 5pm on 1st June 2012.  Communication of end dates can be a useful way of inferring confidence, stating Summer 2012 shows the wide range of possible end dates that might be acceptable and shows the uncertainty with a lack of precision.  I have no doubt that a project manager somewhere will have sat down with a tool such as MS Project and will have added all the road building tasks onto the plan. Fortunately they avoided the trap of using the dates in that tool as the dates they communicated.

I also noted that at certain times of the project, they could predict with great certainty when parts of the road would be closed.  Signs would appear warning of closures for the following week.  Again, underlining the ability to predict with some certainty events that are close by (although even then sometimes the roads didn’t close when the signs said they would and the next day the sign would be updated with a different closure date).  This ability to predict close events with some degree of accuracy and further events with less is described as the Cone of Uncertainty.

Secondly, defining when a project is done is critical.  When upgrading the road, the definition of done seems some way off my own definition of done.  They officially opened the road on time, so perhaps they were happy with their definition of done, but as someone who drives on that road, I am not.

I have no idea why work is still being done on the road.  The road is functional, it has lines painted and lights on the side, so you could argue as version one it meets the Minimum Viable Product we might release as a software team.   A lot of traffic is using the road, so they are clearly providing value by “releasing early”.  Perhaps they have simply entered a maintenance phase, maybe they are taking the opportunity to reduce their technical debt.  Whatever it is, I just wish they’d hurry up about it!

Posted in agile, estimates, planning, Project Management, software development | Tagged , | Leave a comment