Wednesday 9 October 2019

Class Name Suffix Wheel Of Fortune

Hey developer!

Do you find it hard to name your classes?

Perhaps you have a seemingly large number of services, or helpers. Not everything can be a service or a helper right?

If this is a problem you can relate to, then I have the ultimate tool for you!

The Class Name Suffix Wheel Of Fortune

Just spin the wheel, and you'll never need to worry about your class name suffix ever again!




ps. Once you're done having fun, go learn some software architecture to avoid these useless suffixes in your code :)

Tuesday 10 September 2019

Good Help Is Hard To Find - Tips When Hiring Remote People


Good Help Is Hard To Find.

This is the eighth in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology.

Introduction

Are you hiring remote developers? Your decision to do this might be due to cost (to save money), due to local skills shortage, or when you absolutely must hire a specific person and are willing to let them work remotely.

When hiring remote staff members, you need to keep in mind that it will not be as smooth as you might think. Humans are fascinating when you put them in different scenarios, and some people who were fine to work with in an office might not cope well when isolated.

In this article I will present a few of the challenges I tackled when dealing with remote staff members.

Issues

Isolation

Remote staff members are isolated. They miss out on important information. They are not privy to cross-desk small-talk and banter. They definitely are not able to go for lunch with people. We all need the company of other humans.

You really need to figure out ways which you can help your remote staff feel like they have real human contact.

Limited Communication

In a physical office situation, staff members will interact at some point during the day. When you have remote people, this does not happen. Most of the time you only have the remote people interacting with their current project team, and sometimes just at a daily scrum. This is not much communication, and many people might not get the information they need to do well in their jobs without those extra office side-chats.

Quality & Performance 

When developers help each other then they will come to a consensus with their approach. They come to a solution more quickly, and there will be less bugs. The opposite is often the case when it comes to isolated developers.

In my experience, remote people are far less likely to ask for help. This has a knock-on effect of their quality potentially going down, as well as their speed.

Second Class Citizens

It's very easy to get in a habit of treating remote people 2nd class citizens. I have seen this in various companies, and decided very early that we must replicate in-office communication as closely as possible.

Tips to Improve Communication

Video

Have you ever joined voice-only conference calls. They really suck. They really do!

Being able to see a person's face is very important. It makes the calls quicker and more efficient, while also giving you all a more human interaction. Slack conversations and email have their place, however they can take way too long. So I favour video as much as possible.

Tip: My top tip is to use always use video for all meetings and discussions. There are plenty of tools out there. Zoom is my preferred choice. There are other good options such as Slack video, and Google Hangouts.

Frequent Rituals

My most distributed team consisted of 2 offices and 4 remote developers spread across 3 countries. Very early on, I introduced daily all-dev standup where devs would talk about what they were doing, and would ask for help if required. Arguably, this might not significantly serve the projects in the short term. However, the interactions each morning did facilitate knowledge sharing across all devs. It was a great start to the day, and I personally really enjoyed the feeling of seeing everyone each day.

Tip: Strive for some sort of group interaction which can mimic a physical office environment. Make it frequent, and at least once per week.

Encourage Remote Questions

Remote developers do not have much interaction during the day when compared to developers who were sitting at the same desk.

I encouraged developers to avoid asking questions of people who were physically in the room. I told them to ask the remote developers were possible, as it would encourage them to do the same.

This dramatically increased the amount of communication. While this might sound a little inefficient at first, in the long term the communication tightened up, and video questions became the norm. Quality of work and happiness of remote developers increased as a result.

Travel

When I started to take on remote staff I insisted that they come to the office as often as possible. For people in the UK it was around once per month for a couple days, people in other countries around once a quarter. This is obviously an extra cost to the company, however the improvements in team bonding and efficiency are totally worth it.

Tip: Get your remote staff to visit the office as often as possible.


Final Thoughts

The world is modernising where people can work from anywhere. You need to be extra diligent when it comes to care for these staff members, as you can't actually see their physical conditions, and you have far less contact with them.

Video calls are critical in helping people feel less isolated, and you must develop daily and weekly rituals to keep the remote people engaged and in the loop. Encourage your office staff to engage frequently with the remote staff, and definitely try to have your remote staff travel to physically engage with everyone else.

I hope you found this article helpful.



Posts In This Series

  1. Interview Tips for Technical Leaders
  2. Tips To Ensure Quality Delivery When Outsourcing
  3. Tips When Taking On An Intern
  4. Tips When Hiring Senior Developers
  5. Tips When Hiring Junior Developers
  6. Tips When Offshoring Development Teams
  7. Tips When Hiring Digital Producers
  8. Tips When Hiring Remote People
  9. Tips To Improve Developer Retention (coming soon)
  10. Tips When Hiring Lead Developers (coming soon)











Saturday 7 September 2019

Billing - A Better Alternative

Introduction

When I was Head Of Development at The Cogworks we originally tried to bill by the 1/4 hour. It was insanely granular and cause many undesirable side effects and habits. Even if we rounded up numbers to meet 7hrs per day, it seemed that projects were just not profitable. It was quite hard to get my head around it, but much of this was because linking estimations to "time spent" to "billing" was causing many assumptions about workflow which were just wrong.

For example, we all should know by now that 1 dev working solidly for 7hrs is more productive than the same dev trying to work on different 1hr tasks. Nothing ever takes an hour. Downloading a code repo & getting it running could easily eat up 1 hour. Super granular estimates were linked to granular timesheets and billing which never accounted for context switching. So on paper we were always going "over budget". Crazy right?! I still find this hard to think about, as it does seem counter intuitive. Basically, when you context switch, there is a significant amount of time you need to waste on gaining speed. Kind of like a car being stopped at every traffic light.

A Simple Elegant Billing Model


  • 0.5 to 1 day billing increments
    • Use this for items which are estimated to be around an hour to several days
    • Even if an item is "estimated" as trivial (perhaps 1-2hrs), just charge 1/2 day
  • 1 - 2 week "project team" billing increments 
    • Use this for chunks of work which is estimated to be weeks to months long
    • A team may consist of 2 devs, Producer, Designer and QA
  • Emergency tickets are pre-sold at 2/3 day billing increments
    • This is essentially prepaying for disruption
    • Gives you the ability to ask the client "do you want to use your pre-bought ticket" or is this ok to just schedule into support & maintenance?
    • Tickets expire after 3 months if not used

This billing model free's up your developers from the shackles of timesheets, and also builds in adequate buffer for all those random project comms and meetings. When I introduced this at the Cogworks, it was as if a burden had been removed from day to day life. Everyone was happier.


Friday 6 September 2019

Stop Using Timesheets

Introduction

In an organisation which does software development, timesheets can really damage your productivity for what is actually a false economy. As Head of Development at The Cogworks I saw all of these problems and eventually abolished them completely.

In this article I will debunk common reasons for requiring developers to do timesheets. I will give better alternatives which will make your workforce happier and the organisation more profitable.

Comparing Projects For Efficiency

I cant believe I even need to state any of this, but here we go...

No two projects are the same. When I was at The Cogworks, we helped a client launch 100's of websites using a standardised multi-lingual starter-kit, "virtually identical" Information Architecture, and "very similar" designs. Each project was totally unpredictable in delivery due to changed in content, varying client-side interaction times, different developers, different designers, different devops people on the client side, and secret stakeholders who appear at the 11th hour. Keep in mind, this was the same client!!!

Requirements will always differ in some way, and stakeholders and client-side Project Managers change even within the same client & during a project. I have seen a project be totally derailed because a new (not so great) PM appeared on the client-side.

There is no point trying to compare build & deploy time for even small items. No two pages will ever be identical. I commonly hear "It's identical except...".

People on two project teams will have differing skills, experience, knowledge, personalities, and experience working with each other. Imagine taking a team who get along and have created many projects, however they are a bit sloppy. Compare that group to a team who have new members who don't know each other's skills and personalities, however they are all very capable.

I hope I have convinced you to stop trying to compare projects.

There are however other ways to tell if a project was efficient. For example, count the number of calendar weeks that the project took to complete. This is not the same as the number of utilised hours!

Performance Reviews

Using timesheets for performance reviews makes absolutely no sense. As a manager I want to know how many tasks a dev can do, and how often bugs are reported by QA.

I'll give you this (really bad Apples & Oranges) example:

Time logged is not the same as output
Anthony is a great at baking, however he worked on task "Apple Sauce" for 4 days. 
Greg is a great at Apple Sauce, however he worked on task "Orange Meringue" for 3 days. 

These people worked on things which they were not specialised in. How can you compare their time?

An alternative is to track output, not time logged. Track the number of tasks which each developer does. A very simple metric is to count the number of Jira/Trello/Asana/etc. cards which are completed within a timeframe.

Quality
Anthony's Apple Sauce is horribly overcooked with over-caramelised parts.
Greg's Orange Meringue has less perceivable defects than Anthony, however he didn't need to use a stove.

These tasks were totally different. Anthony basically failed at his task. How do you compare them based on timesheets?

An alternative is to track the number defects which are flagged. If you are using a Kanban process, then you can simply count the number of defect cards which are created against the work items.

Other Issues
No one knows if either tasks are complete, or even if they are done to the satisfaction of the client. Did the client report any issues, did QA find issues? 


Accuracy

Timesheets are seldom accurate. Here are some common habits of someone who fills in timesheets. I can absolutely say that these things happen because I personally have done all of these, and will continue with these habits if made to do timesheets.
  • Round up numbers to get 8 hours tracked per day
  • Add a number to a random client which I "think" I worked on
  • Forgetting to do them on Monday, so I do them from memory on Tuesday
  • Forgetting to do them all week, so I do them from memory on Friday
  • Forgetting to do them all month, so I do them from memory on when I am chased
    • Yes I've done this one too!

Even automated tracking will still be wrong...

Think about toilet breaks, coffee breaks, discussion at the water cooler, cigarette breaks, impromptu project chats, emergency meetings, helping another developer, doing a quick code review, phone calls, emails, Slack, calendar, Trello, and finally... short lunch vs long lunch. Trying to account for all these scenarios is a fantasy fallacy of micromanagement.

But I hear you saying "what about mouse tracking software?". Well, stop reading this article. If I cant convince you then perhaps these people can:


Client Billing

Fixed Cost Billing

I have been part of countless projects where I was required to do timesheets because they were apparently used to bill the client. When I found out that the projects were all fixed cost, I asked the question: "If the project is fixed cost, then how are the timesheets used to bill the client?"

The answer was: "The timesheets are used to see if we're losing money".

*face palm*

Tracking project time is different to tracking people time. I'll explain more in a future post.

Billing For Time Spent

If you are using timesheets to do client billing, then you are probably being too granular.

What would you do in this following scenario?
Developers help each other with questions, code reviews, discussions, architecture. Very often the knowledge / skills required may not exist within the same project team, so developer from another team is asked for some quick help. Very often this will be just 5 minutes. Sometimes it is longer.

Also, what about all the project meetings? eg. Standups (3-15mins), sprint planning, sprint review, sprint retrospective, random comms, emails, quick chats with the PM, 2min slack conversation with the client devs. What about when a colleague asks "How was your weekend"?

I know what you're thinking...
1. Dev 2 should enter a number into their timesheet that they spent 5mins helping Dev 1
2. As long as a developer's time is tracked against a client/project then there is no money loss.

Why are you concerned about tracking developer time by the minute? This is classic micromanagement! There is not value to the business to know that a developer asked another developer a question. It is wasteful. People hate and resent this level of micromanagement. Developers help each other and it all evens out anyway. So stop trying to track this!

A better alternative is to take a higher level approach. Bill by the day, week, sprint, month etc. See here for a better alternative.



Final Thoughts

I hope I have given you food for thought when it comes to timesheets and your production team. Comparing timesheets of projects has absolutely no value. Performance reviews should be based on quality and quantity of output, not time logged. Accuracy of timesheets is also generally crappy. If you can change your billing process to be less granular, then you will not need timesheets.

Once you remove timesheets from your business, your staff will be more productive and happy.







Wednesday 24 July 2019

Azure Naming Conventions

I have gone back and forth with Azure naming conventions over the years. There are various trade offs to consider, but I think I have settled on a format... for now.

I prefer to see the resource type as a prefix, while the environment (dev, qa, uat, prod) as a suffix. In the middle, I like to see the purpose of the resource.

So my format is:
<what>-<why>-<where>

What: The resource type
Why: The purpose / project
Where: The environment (eg. dev, qa, uat, prod)

This naming convention allows me to see all the resources ordered by their type (eg. sql for SQL Server). In the following example, I can visually scan for "sql"
sql-myproject-dev
sql-myproject-qa
sql-myproject-prod
sql-thierproject-dev
sql-thierproject-qa
sql-thierproject-prod

Notice that this allows all the sql resources to be grouped by project name. Using the suffix, I can then easily see the environments related to those projects.

In the examples below, the I use "nicename" for the "purpose".

Naming 

General rules:
  • All resources (including resource groups) are lower case
  • Where hyphens are not permitted, simply omit them. eg. storagenicenameprod 
  • Use industry accepted abbreviations (eg. vnet, app, net)
  • Where there is no widely accepted short abbreviation, use full words (eg. search for Azure Search)
  • Where character limits are imposed, fall back to acronyms (last resort as this is harder to understand)

Resources groups

rg-<purpose>-<environment>
For example:
rg-data-prod
rg-net-prod
rg-web-prod

The reason I have separated web, data and network related resources is because putting all resources in a "production" group could get very messy. The separation allows for the types of functionality (within an environment) to be grouped nicely.


Data Group - Data / storage related
Examples:
  • Database server
  • Blob Storage
  • Table Storage
  • Azure Search 

Net Group - Network, Security and Protocol related
Examples:
  • Virtual Network
  • Network Security Group
  • Application Gateway
  • Azure Front Door
  • Load Balancer

Web Group - Web App & Content Delivery related

  • App Service Plans & App Services
  • Functions
  • Sendgrid


Resources In General

<resource type>-<purpose>-<environment>

Examples:
app-nicename-dev
search-nicename-prod
sql-nicename-qa

The reason I like the resource type first is because I often look at the entire resource list, so (for me) it is helpful to put the resource type at the start of the name. Yes I know that you can order by resource type, however there is something I personally don't like about that.


App Service Plans

Examples:
asp-nicename-dev
asp-nicename-qa
asp-nicename-uat
asp-nicename-prod

Example Resource Group: rg-web-prod

App Services

Examples:
app-nicename-dev
app-nicename-qa
app-nicename-uat
app-nicename-prod

Example Resource Group: rg-web-prod


SQL Database Server

sql-<purpose>-<environment>

Examples:
sql-nicename-qa
cosmos-nicename-prod

Example Resource Group: rg-data-prod


Databases 

db-nicename-<environment>

Examples:
db-nicename-qa
db-nicename-prod

Example Resource Group: rg-data-prod


Azure Search 

search-<purpose>-<environment>

Examples:
search-nicename-qa
search-nicename-prod

Example Resource Group: rg-data-prod


Virtual Networks

vnet<int>-<environment>

Networking is an interesting exception, as I prefer to take a numbering approach at network levels. This is because networks can be used for all types of purposes. I also like to keep the network dependencies together. So I will prefix the Network Security Group (nsg) with the name of the the vnet.

Examples:
vnet01-dev
vnet02-prod

Example Resource Group: rg-net-prod

Network Security Group's related to a VNet should follow the pattern:
<vnet>-nsg-<purpose>-<environment>

Examples:
vnet01-nsg-appgateway-prod
vnet01-nsg-frontdoor-prod

Example Resource Group: rg-net-prod


In this example the "purpose" is to attach a Network Security Group to the Vnet for the Application Gateway and Azure Frontdoor


Application Gateways

agw<int>-<environment>

Examples:
agw01-uat
agw02-prod



Final Thoughts

Naming things is a balancing act which I (and many) struggle with. Something that you are happy with might start annoying you years later. What ever you choose, try to ensure that your naming is understandable, consistent, and easy on the eyes.

Also, keep in mind that you probably won't like your naming convention in the future :)




Friday 28 June 2019

Estimating - There is no such thing as a 1 hour task

Introduction

Estimations in software development have always been a problem. Many teams and organisations struggle with finding the right way to do estimations. There is no right answer, and it really depends on your organisation. 

If you are measuring by the hour, then perhaps you have struggled with understanding why you are not as profitable as you could be. This may arise from the fact that your lower estimates are just not realistic. I will explain what I mean in the following examples.

In these scenarios we assume that the developer deploys to an environment, then confirms that the functionality works before handing it to a QA/UAT person.

Example 1 - The perfect case (no defects or problems)

In this example I will outline a 1hr task in a "best case" scenario which has no defects or problems. The order of events will differ depending on your processes. 
  1. Download repository & get code running locally - up to 0.25hrs
  2. Do the work - 1hr 
  3. Deploy to a development environment & test (0.25hrs)
  4. Commit code, create pull request, & participate in the code review (0.25 x 2 devs = 0.5hrs)
  5. Deploy to a QA environment & test (0.25hrs)
  6. Tag & cut the release (0.125hrs)
  7. Deploy to a UAT environment & test (0.25hrs)
  8. Deploy to production environment, put live, then quickly smoke test (0.5)

As you can see, a single 1hr task can actually take 3hrs in a good scenario. This does not even factor in the time of the QA or UAT people. Also, the context switching of doing all these different steps is a significant time drain.  

You are thinking that many tasks together can be bundled, so we would save time on deployments. As you will see in the next example, the math still does not work out.


Example 2 - The perfect case (no defects or problems) with multiple work items

In this example I will outline 5x 1hr tasks in a "best case" scenario which has no defects or problems. 
    1. Download repository & get code running locally - up to 0.25hrs
    2. Do the work - 5x 1hr 
    3. Deploy to a development environment & test (0.5hrs)
    4. Commit code, create pull request, & participate in the code review (5x 0.25 x 2 devs = 1.25hrs) - Note: each task has it's own code review
    5. Deploy to a QA environment & test (0.5hrs)
    6. Tag & cut the release (0.125hrs)
    7. Deploy to a UAT environment & test (0.5hrs)
    8. Deploy to production environment, put live, then quickly smoke test (0.75)
    As you can see, 5x 1hr tasks can actually take 9hrs in a good scenario. We are not really saving much time by bundling. On average, our  1hr tasks are actually taking almost 2hrs per task.



    Example 3 - The bad case (defects & problems)

    In this example I will outline a 1hr task in a "bad case" scenario which has defects and problems. 
    1. Download repository & get code running locally - up to 0.5hrs
    2. Do the work - 1hr 
    3. Deploy to a development environment & test (0.25hrs)
    4. Code does not work. GOTO step 2
    5. Commit code, create pull request, & participate in the code review (0.25 x 2 devs = 0.5hrs)
    6. Code is rejected. GOTO step 2
    7. Deploy to a QA environment & test (0.25hrs)
    8. Fails QA. GOTO step 2
    9. Tag & cut the release (0.125hrs)
    10. Deploy to a UAT environment & test (0.25hrs)
    11. Fails UAT. GOTO step 2
    12. Deploy to production environment, put live, then quickly smoke test (0.5)
    I hope my following calculations are correct...
    0.5 + 
    1 + 0.25 +
    1 + 0.25 + 0.5 +
    1 + 0.25 + 0.5 + 0.25 +
    1 + 0.25 + 0.5 + 0.25 + 0.125 + 
    1 + 0.25 + 0.5 + 0.25 + 0.125 + 0.25 +
    1 + 0.25 + 0.5 + 0.25 + 0.125 + 0.25 + 0.5
    = over 12hrs

    It is important to note that this is a really bad scenario. Something has gone wrong at every part of the process. Failing Code Review and QA and UAT should be very rare. However failing at least one Code Review or QA or UAT is quite common, and should be expected.

    Programming is very difficult. So the reality of bugs/issues falls somewhere between the ideal (no defects or problems), and the bad (has issues at all stages).

    It is also important to note that unknown obstacles pop up which a developer must address. For example, any frontend developer will know about versioning/dependency issues with their tooling. I have never met a seasoned .net backend developer who has not yelled at the top of your lungs when they realised a Windows update has broken something.


    Final Thoughts

    In reality there is no such thing as a 1hr task. Even the most ideal scenario has parts of the process which are not accounted for, which can easily push the real time spent to 3hrs. Even bundling items together does not effectively eliminate this reality. 

    Programming is hard, and there is no such thing as bug-free software. A release with multiple tasks will have at least one item which is rejected at Code Review, QA, or UAT. Good processes only mitigate defects and problems. 

    I hope that this article has given some insight in what it is like to estimate effort in hours. There is no such thing as a 1hr task. What ever your estimation strategy, you need to account for this reality so you can stay profitable.











    Sunday 9 June 2019

    Umbraco Codegarden - Moving to dotnet core

    A little over 2 weeks ago I ran an open circle which was aimed at getting Umbraco transitioned to dotnet core. The discussion group centred around what the community can do to help speed up the transition.

    Umbraco's Current Structure

    As it stands, the current Umbraco solution structure looks like this:



    Umbraco's Future Structure

    Moving forward, the proposed solution structure will look something like this:



    Note: The new solution structure will be maintained in a separate branch. The rationale is that the changes required to get there will create many frequent breaking changes.


    Community Tasks

    The stages to reach the proposed structure will require significant refactoring. There are various tasks which are simply too complex (with too many interdependencies) for non-HQ people to accomplish. However, we managed to pull out specific tasks which are isolated enough for the community to have a go with.

    I have created issues on the Umbraco issue tracker for these items:


    Requiring Discussion

    A more complicated issue arose from the discussion around how Umbraco does imaging. Namely, how do we abstract that functionality? 

    Shannon suggested to create an RFC so it can be discussed:

     

    Final Thoughts

    Dotnet core 3.0 is coming out at the end of the year (November?). Umbraco realistically needs to wait until at least this time before it can investigate MVC related refactoring. In the mean time, there is a huge amount of refactoring to do. The items in this article are available to the community, and are just the first wave of refactoring which is required.





    Sunday 2 June 2019

    Good Help Is Hard To Find - Tips When Hiring Digital Producers

    This is the seventh in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.

    Firstly, I will only be using the term Digital Producer, rather than Project Manger.

    Read more about Digital Producers vs Project Managers.

    Introduction

    The best Digital Producer I ever worked with was a great facilitator. They didn't manage people. They managed obstacles. They lined-up work and unblocked our path.

    Hiring a Producer with the right background and attitude can be great for your work and company culture. If you work in software development you can almost always benefit from Agile methodologies, and that's what this article will feature.

    On a related note, in Scrum there are no Project Managers, only Scrum masters and Product owners. This article will dabble with a few Scrum terms, however it is aimed at companies who are not yet very Agile, and are still hiring "Project Managers".  Learn more at scrum.org


    Attitude

    Having a good collaborative attitude is probably the most important attribute to any Digital Producer. 

    Developers can self-organise, and don't need an overlord *ehem* "Project Manager" to question what they are doing. They just need someone who can line up features so the developers can swarm on them. They need a person who can manage obstacles, not people. 

    Here are a few useful questions I wish every company would ask during the interview process:

    1. On a scale of 1-10, how much do you trust the developers in your current company.
    If the answer is anything less than an 8, then you should raise an eyebrow. They are essentially saying that they don't really trust the people they work with, and might be micro-managers.

    2. When a developer told you that something was taking longer than expected, what was your response?
    The answer you're looking for is something similar to: "I asked them is there was anything I could do to help us deliver?", then "Let's talk about the things we can deliver, and then go talk to the Product Owner / stakeholder to discuss re-prioritising the backlog and next steps".

    3. Can you tell me about your daily stand-ups?
    The answer you are looking for is: I try to facilitate the team talking to each other to solve blockages. I don't understand everything they're saying, but after 10-15mins if they have determined a plan of action for the day then I've done my job.


    Agile / Scrum / Kanban

    If your organisation is producing software then Agile experience should be very important for you. MVP, iterative releasable sprints, get feedback, adapt. 

    If you have Producers who are not at least scum certified, then definitely make this your first priority. 
    The scrum.org certifications have a pass mark of 85%, so if the person has a certification from there, it is an indication that they have actually learned something about scrum and agile. The courses really challenge your views on how a project should operate. Someone who is Scrum certified is much more likely to be a facilitator. 

    Kanban is all about smooth flow, throughput, visual cues, measurement, and swarming. If person has this experience (ideally a certification), then it is more likely that they know how to facilitate smooth running of a team. Kanban doesn't care about assigning tasks to people, but rather encourages a pull based workflow where anyone can do the work. Kanban coupled with Scrum is a sweet spot which will see benefits of both.


    Tooling 

    An experienced Producer should be able to tell you about the pros and cons of the tools they have used in regard to:
    • Feature mapping
    • Task tracking
    • Burn-down & burn-up charts
    You should be able to ask them about Stories on Board, Feature Map, Jira, Kanbanize, Leankit, Trello, spreadsheets. They should have an opinion. 

    If they are struggling to articulate their options then you should support them in their learning. Give them the task to review other platforms and present their views to other Producers. 


    Prince 2 & Waterfall Experience

    I'm not a Prince 2 expert, but I'll do my best...

    This type of certification has specific uses. For example, fields where safety and regulation matters such as construction, medical, legal all lend themselves to heavy documentation / regulation / check & balances. The functional requirements and initial documentation are heavily front-loaded.

    It is useful to understand different methodologies, however if you are working in digital agencies, software, or an organisation which is wanting to "be more agile", then this qualification / experience is not a priority on your search. People with this experience will likely be more inclined to be a "classic" PM who "controls" the workflow, rather than facilitates it. It might be hard to shake that habit. That said, if the person is smart and has a good attitude then get them Scrum certified ASAP and see how they adapt to your environment.

    On side note, you can definitely run a Scrum/Scrum-ban workflow inside a waterfall project. Just keep in mind that if you already have Scrum running relatively well, then a person with only Prince 2 experience might appear as being a micro-manager.



    Final Thoughts

    Attitude is super important. It can make or break your culture. Put heavy emphasis on finding out if the person you hire can jump in and facilitate your team, not "run" it.

    Having Agile experience (ideally scrum and kanban certifications) can give you some confidence that the person will be more likely to be collaborative, and facilitate smooth workflow.


    Check out my Scrum certification reviews below:


    Posts In This Series

    1. Interview Tips for Technical Leaders
    2. Tips To Ensure Quality Delivery When Outsourcing
    3. Tips When Taking On An Intern
    4. Tips When Hiring Senior Developers
    5. Tips When Hiring Junior Developers
    6. Tips When Offshoring Development Teams
    7. Tips When Hiring Digital Producers
    8. Tips When Hiring Remote People
    9. Tips To Improve Developer Retention (coming soon)
    10. Tips When Hiring Lead Developers (coming soon)












    Saturday 1 June 2019

    Technical Director at Radley Yeldar


    Three weeks ago I ended a 7.5 year run at Cogworks. I was planning on taking a big break, do some contracting, and see what the universe had to offer. Then came along a role which I could not pass up.

    Where Did I Land?

    Three days ago I started at Radley Yeldar (based in Shoreditch) as their new Technical Director. The organisation came from a business reporting background. They moved into print, brand & strategy, and now into digital.

    Staff perks include a roof terrace with a BBQ and a hot tub, and yoga on Tuesdays.


    What Will I Be Doing?

    Organisational and production processes are the things which I find very interesting, and I have been hired to usher in a new age for the digital side of the company. In the coming months I will be putting my energy into educating people from various disciplines about what it means to be Agile. I will be talking about Scrum, Kanban, and Lean Agile at every level of the company.

    I will also be looking at the current technology stack, how to optimise dealings with technical partners, project rituals, workflow management, and even sales incentives. Exciting right?!


    What About Tech?

    There is a lot of work coming up, and this is a very exciting opportunity. The team will help guide improvements in all of aspects, so this will be a clean slate where the team can choose the right technologies, the right tools, the right processes, the right training, and the right new people. I started this initiative on the second hour of my first day, where I held developer meeting and asked these questions:

    What do we do well?
    What can we do better?


    And before you ask...Yes Umbraco all the way!


    What About Developers?

    To meet the needs of up coming work, the team needs to expand rapidly! I have already put together a plan to hire 7 more developers. I will immediately seek to hire 1 lead, 3 seniors, and 3 mid-weights, with an initial requirement of 5 contractors (Umbraco) until we fill those roles.


    Final Thoughts

    When I left Cogworks I didn't actually want to take on another a full-time role so quickly. However, this role at Radley Yeldar  was so appealing to me that I could not resist. Organisational & Production processes are really interesting to me, and the prospect of rapidly scaling a development discipline is too exciting to turn away.

    Keep an eye out for great new tech deliveries coming soon from RY!








    Monday 27 May 2019

    Stop Booking Developers

    Introduction

    If your organisation is booking developers then your quality could be better, your delivery could be faster, and your developers could be happier. 

    Organisations with digital/development departments will very often have projects, maintenance, support, and emergency work. When trying to mix these types of work, common questions you will hear include: How is this work scheduled? Who is working on this task? If your company is asking these questions then you are doing it wrong. 


    Class of service Issues

    Projects & Large Features

    Note: I tend to lump Projects and Large features into a single category as the development cycle tends to span many weeks. Projects tend to take months.

    This type of work would typically be booked in for specific developers to start on a specific date. That sounds quite normal, but what happens when their current work is taking longer than expected? What if a work item is super hard and a dev doesn't know how to do it by themselves?


    Support & Maintenance 

    Support & Maintenance work is typically small and might include small-medium features. The timing would likely be hours to days and is normally scheduled for specific developers to work on. That sounds quite normal, but what happens when they are sick, or are taking longer on previous tasks?


    Bugs & Emergencies

    If bug is not critical then it is common to schedule it in the same way as Support & Maintenance (see above). If the severity of a bug is high, then you will often see devs pulled off from other projects / work so they can deal with the emergency issue. That sounds quite normal, but what if the emergency is super hard to diagnose by a single person? Also, didn't you just kill the velocity of another piece of work?


    The Problem with Booking People

    All of the scenarios above have been examples of optimising for utility. As you can see, the practice of booking specific people for specific work is very fragile and susceptible to variances (eg. sickness, delay). Another important issue is that very often devs need help from other devs. How does this affect the other work?

    If you are booking developers then you might often see Project Managers fighting over "resource". This is really dehumanising for their colleagues, and causes a great amount of unhappiness.

    A better approach is to forget about booking individual people, and start thinking about how to optimise for throughput. After all, it's the delivery (throughput) which the customer requires.


    Optimising for throughput

    The first thing you need is a mindset shift. Forget about booking people. Throw this practice out the window. It's full of problems. The key is to have a pool of developers who organise themselves to adapt to the situations. 

    When developers self-organise this will often involve 2 or more devs swarming on a single work item. For example, it is very common for a single dev to take 2 hours to find a solution to an issue, where 2 or 3 devs working together might solve it in 10mins. This is optimising for throughput. Do the math!

    When developers self-organise, the work will be done quicker, and actually be better quality as the devs will need to come to a consensus about the approach. There will be less bugs!


    Kanbanizing Bugs & Emergencies

    In this situation we have a team of devs who tackle tasks together like a wolf-pac. All you need to do is line up the work in priority order, and they will handle it.

    If and emergency comes in then it goes to the top of list. Just notify the wolf-pac and someone / some people will deal with it. 


    Kanbanizing Support and Maintenance

    This class of service can be handled in the same way as Bugs & Emergencies. Depending on your requirements, you may have a team that can handle small work from several projects. This is ideal as it spreads knowledge among many people. Depending on the situation (eg. size of team), you could merge this team with the bugs and emergencies team. The key is to have enough devs to actually swarm on work.


    Rotating For Projects and Large Features

    But what about Projects & Large Features? Shouldn't you "book" those developers? Well kind of but not really.

    For example, every project should have a technical lead. However, it doesn't mean that they need to be developing. They can take a technical oversight of the project, and attend initial meetings. In fact, I recommend at least 2 technical people attending all meetings. So you really only need to ask the devs who will be the tech lead.

    The devs on a project should come from a rotation of the the other teams (Bugs & Emergencies, Support & Maintenance). Obviously you need to have enough devs for all classes of service otherwise they cannot rotate. When some work comes in that requires you to augment your capacity, then the new developers go into the pool, and the existing developers will help decide who is best suited for the new project.



    But When Will It Be Started?

    I have been in situations where people are pushing for work to start. This inevitably means stretching out the developer pool to only 1 developer per task. This means no more wolf-pac, and no more swarming. It is totally bonkers!!!

    Asking "when will it be started" is the wrong mindset. It means nothing without knowing your Cycle Time.

    The questions should be "What is our Lead Time?" and "What is our Cycle Time".

    This is a very easy question to answer. Based on the current team, they will have a known average throughput. If a team delivers 5 items per week, with a standard deviation of 1, then 20 items will be delivered in 4-5 weeks. This is our Cycle Time. If we already have 5 items in the pipeline from a previous set of work, then our Lead Time is about 5-6 weeks. I hope my maths is correct :)

    You don't need a gantt chart or even a burn down chart to figure this out. More on this in a later post.

    To find out more about Kanban and statistics, check out Lean Kanban University.


    Final Thoughts

    Booking developers comes with so many problems. You will constantly be chasing people, asking when people will be available, wondering why another work item is taking too long, appologising to clients etc. Creating developer pools really elevates all of this stress. Using Kanban to manage workflow also gives you very clear statistics of how the workflow is going. 

    I hope you have seen the benefits of optimising for throughput. The work output will be more predictable, faster and better quality.




    Monday 13 May 2019

    Job Titles Form Mindset - Digital Producers VS Project Managers


    Introduction

    Job titles form mindsets and behaviour. I have been working in digital/web since 2007, worked at several companies and with dozens of Project Managers. Many organisations want to be "more agile", and it is my opinion that one of the first baby steps is to fix job titles. An attitude change requires a mindset shift.

    In this article I will discuss how to get your Project Managers to become more collaborative and less authoritative. This is a stepping-stone to a more collaborative Scrum mentality, as Scrum does not have the job title of Project Manager.

    If you come from a traditional project management background, then I ask that you please keep an open mind.


    Project Managers

    Project Managers are not evil, and most of them are not jerks. Very often the pressures that are felt by designers and developers are due the pressures "pushed" onto the PMs from further up stream (eg. client services, the company). This can exacerbate undesirable behaviours such as micromanagement.

    Many would agree with the opinion that this stems mindset of what a "Project Manager" is meant to do. They are meant to "manage". However, this elicits certain types of communication and behaviour which can dehumanise their colleagues. It is obviously not the PMs intention, however this is a result.

    Every time I hear these phrases / questions, I cry a little inside:
    • How do I book a designer for my project?
    • How do I know which developer will be assigned to my project?
    • When will you be done using Greg? I need to use him for my project
    • Can I have Greg next week?
    • I need a QA resource

    These are common things you will hear in a standard digital agency. The problem with these phrases is that they dehumanise the people who they are referring to. The people you work with are no longer people. They are resources to be handled and monitored. I have seen how developers and designers have been micromanaged and traded between PMs as if they were sauce bottles on a dining table. I have also seen really poor behaviour where PMs have become aggressive when it came to "protecting their resource", they were untrusting, micromanaging, and have even stopped other developers asking "their developer" for advice/help. This totally sucks, and is very bad for your work culture and morale.

    But but but... how else is a Project Manager is meant to manage things? Isn't a manager meant to manage tasks, people, time, etc. My project success means that I will get a promotion/pay increase.

    It doesn't have to be this way...


    The Best Manager Does Not Manage Anything

    The best "PM" I have ever worked with was an absolute joy. He didn't manage people, he didn't manage our time, he didn't manage our tasks, he didn't manage the client, he didn't assume any type of authority over anything in the project at all. He wasn't a Project Manager in the traditional sense. He was a facilitator

    He lined-up work, collaborated at ground level with everyone, asked if we needed him to do anything, he let everyone make their own decisions, he unblocked our obstacles, he cleared our path so we could succeed. He was an absolute joy to work with. He helped us produce great products for our customers. But he was not a "Project Manager". He was part of the project team, and trusted his teammates to do their part. The projects where he was involved in were the smoothest I have ever had the pleasure to work in.

    What I have just described is a person who would pass a scrum.org certification without even doing the training.


    The Mindset of a Digital Producer

    When you refocus people on producing value rather than managing people/things, then a shift in mindset occurs.

    If you work in the digital space, you may have come across the role of Digital Producer at some point. It is very interesting that when a Project Manager title is changed to Digital Producer, then a load of different behaviours can emerge.

    There are plenty of PMs out there who are "managing" projects which have little value to the stakeholders/customers. However, a Digital Producer is actually meant to "produce" value. This is a mindset shift which can encourage more a collaborative attitude and behaviours.

    Many would agree that the job title Digital Producer better suits an Agile environment. The job title of Digital Producer not only sounds cool, it doesn't come with all the baggage of being a traditional PM. There is no longer an expectation for you to "manage" anything or anyone. The team/company/organisation only expects the person to facilitate the "production" of value for the customer/stakeholder. 

    If you are a Project Manager at a digital/advertising agency, you should totally ask for your title to be changed to Digital Producer. It is so much cooler!


    Digital Producers, Scrum Masters and Product Owners

    Let's talk briefly about Scrum...

    The next evolution of Digital Producers, is a splitting into 2 different roles which are Scrum Master and Product Owner.

    In scrum a Product Owner understands the stake holder's needs. They line up the features, and have full control of the backlog because they know what is most valuable to the stakeholder/customer. The Scrum Master is the facilitator of smooth workflow. This person is a coach. They prompt and facilitate conversation, and encourage people to be more mindful of good habits and processes. They are a servant leader.

    I have seen scrum work properly. It is amazing!


    Final Thoughts

    Job titles actually form a mindset, and these mindsets form behaviours. "Project Managers" are not bad people, however their title and role elicits some behaviour which really can dehumanise the people who are meant to be their colleagues. This is especially the case when the PM is getting pressure from further up stream.

    By changing the job title of Project Manager to Digital Producer, it can drastically affect the mindset of those in this position. People will start to be focused on "producing" value, rather than "managing" tasks & people. It is one potential first step in becoming more agile, and on the right path to facilitating production and fixing your work culture.

    I hope this article gave you some food for thought.




    Agile Mindset 

    A mindset shift starts from the right knowledge and training. If you are a leader who wishes to promote a real organisational change, then I highly recommend the Professional Agile Leadership certification.

    Check out my Scrum certification reviews below:





    Wednesday 8 May 2019

    Good Help Is Hard To Find - Tips When Offshoring Development Teams

    Good Help Is Hard To Find.

    This is the sixth in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.


    Introduction

    Finding good developers is especially difficult during rapid scaling, and even more so when you have budget/time constraints. Offshoring is a potential solution, and can potentially save your company a lot of money.

    I helped to set up our Krakow office way back in 2015. I tried to keep the Polish developers integrated as much as possible, and devised policies to help with communication and team building. Part of this involved travelling to Krakow very often. I got to experienced the culture, food and of course the vodka.

    In this article I will present a few of the challenges I tackled when offshoring.


    Currencies

    Before I get started on the real part of this article I just want to touch briefly on fincances.

    Back in 2015 the Zloty was 1/6 of the GBP. Then June 2016 came along and the GBP took a nose dive. Suddenly our staffing costs and office increased by 20% literally within 1 day. All I can say in this scenario is, ensure that you give yourself a buffer to account for fluctuations in your exchange rate.

    The next thing we didn't expect was that the Polish developer market started to boom. Much larger companies were opening offices in Krakow and Warsaw, so the competition for workers was fierce. Suddenly our devs were being offered double the amount that we were paying them. We couldn't keep up with the pay increases so we had to offer much more flexibility and other work perks.

    If you believe offshoring is a great way of saving money, I hope this story prompts you to think about mitigating these issues. We definitely didn't think of the possible financial consequences when we started.


    Understanding The Workers

    There are stories that float around which can be quite damning of Indian developers, however the people complaining about them tend not to understand the type of developers they are getting.

    Indian IT has a reputation for workers who do what they are told... to the letter. This can be a great advantage if this is what you need.

    If you want to create an offshore office, then you need to understand the type of workers you are getting. Culture and work culture need to be understood.


    Culture Gap

    There are definitely some cultural, work differences, and faux pas which you need to look out for.
    Offshoring from the UK to Poland and surrounding countries is relatively painless. Although, if you ask anyone from Poland about "Eastern Europe", they will remind you that they're not in "Eastern Europe", as they are actually geographically central to the continent. So don't tell a Polish developer that they are in Eastern Europe, as they might get annoyed at you.

    Basically, you need to ask questions. Ask your new colleagues if there is anything that foreigners say/do which they find annoying or offensive. This is a great way to actually begin to bond with your new colleagues.


    Time Zone and Office Hours

    The time zones can matter if you need crossover hours for meetings, pair programming, code reviews etc. Even if you are in Europe, and offshore within Europe then you still need to consider differences in office hours.

    For example, the Polish work life-balance is one to be envied. Generally, they drop their kids at school around 7-7:30am, start work by 8am, then pick up their kids at 4pm. It's is a very natural time schedule. Contrast this with UK working hours, and you essentially have Poland starting at 7am GMT , having lunch at 12pm GMT , then leaving the office by 3pm GMT . You realistically only have around 3hrs of crossover time once you factor in lunch. This is with only a 1hr timezone difference!

    The issue of crossover office hours obviously becomes more prominent with larger time zone differences. My personal opinion is that it is far easier to work with offshore offices if your timezones give you at least 2hrs of crossover. You cannot realistically expect that someone living in Sydney can be on regular calls to the UK. You really need to consider how you can adjust your processes, and what type of crossover is acceptable (if any).


    Integration

    I have to say that my experience offshoring to Poland has been very positive. Polish developers are very high quality, they have a good work ethic, and give you opinions and feedback. They are highly educated, and can argue with you about architecture and design patterns. I couldn't ask for a better team.

    I made a concerted effort to integrate the Polish staff with the rest of the company. This took a lot of work, and I personally flew to Krakow very often to ensure that they felt like we were all one family. I often came with office improvements, gadgets / equipment, and even pay increases. You could probably make the analogy of a father coming home with gifts after a long trip. Part of the integration was also daily video calls so everyone could talk about what they were doing. This also becomes a great perk for your staff. I personally love seeing a new city.

    Remember that your offshore office is as an expansion to your current office. Don't call them your "offshore team". They're not another team. They're just working remote all the time. To avoid an organisational silo you need to put in the effort to make them feel that they are part of the family.



    Team Building

    Video calls are essential for ensuring that people feel connected. It is very easy to just use voice calls, or slack messages, however seeing people is far more powerful when creating human connections. So get your Internet connection fixed! No excuses!

    Another important practice is physically sending people between offices. Nothing beats working across the desk from someone, small-talk at the coffee machine, and going for lunch. Do this every month. When a person is booked to come to your office, people will get excited about it, especially if the person has never come to their country before.

    An important note about Polish culture... The first time you go out with your colleagues in Poland they will feed you more vodka than you ever thought possible. Team bonding drinks will take a year off your life. It might also costing you an extra cleaning bill at your Hotel/AirBnB *eyes rolling*.


    Tips For Offshoring Your Development Team


    1.  Know your workers, and what you're getting
    2. Understand the culture of the people you're hiring
    3. Try to only offshore to a location within a few hours plane trip away
    4. Send staff to and from the offshore offices at every month
    5. Enforce a video policy
    6. Treat your offshore office as 1st class citizens in the company


    Final Thoughts

    Many companies treat their offshore office as an outsourced office. It takes a lot of effort to ensure this doesn't happen. Treat your offshore workers as 1st class citizens, and try to understand them & their culture. Be diligent and you can build far better relationships between your staff.

    Friday 3 May 2019

    Good Help Is Hard To Find - Tips When Hiring Junior Developers

    This is the fifth in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.

    Introduction

    From a business perspective, hiring Junior developers gives you cheap workers who you can mould into the type of developer you want and need. But what are the pros and cons? Hiring a junior might be compared to adopting a child. It can be very rewarding, but are you really ready? In this article I will outline many of the things you need to expect when hiring a junior. I will suggest some tips on how tackle these issues and hopefully you will become a better teacher.

    Why Should You Hire Junior Developers?

    From a business perspective, they're cheap and mouldable. They generally have no opinion, and you can teach them the ways of the force. You can give them the trivial work that none of the other devs want to do.

    From a non-business perspective it helps everyone grow. For example, having a junior gives your mid-weight developers an opportunity to do some mentoring, and hopefully develop some leadership skills. Also, it should go without saying that teaching is very gratifying.


    Will They Slow You Down?

    Juniors take time and effort. You need to mentor them, teach them, be their Yoda. All of this is in addition to your daily responsibilities. Be prepared for your other devs to dedicate some time to mentor them. They need to ensure the new dev is meeting coding standards, and actually performing.

    If you have never taken on a junior before, then you might notice spending more time with them than anticipated. Keep in mind that they are doing the more trivial work which other devs don't want to do, or don't have time to do. This is the trade-off you need to come to terms with.

    They Take Too Long?

    Junior developers are not master time keepers (yet). Be aware that will take lot longer than expected. A typical junior is less likely to ask for help, and will sit for hours and days trying to solve a problem. Ideally they should ask for help to solve the problem, then go home and think about why the solution evaded them.

    Juniors need to be told explicitly that they should ask for help early. If they can solve a problem in 1hr by asking for help then that is a lot better than trying to solve a problem by themselves in 5hrs. Regularly check in with them to ensure that they are making progress rather than chasing their tail. Reiterate to them to time-box their effort, then ask for help. Set a stopwatch if need-be.

    Their Bug Count Is...

    Oh boy, juniors have a lot of bugs in their code. They miss a lot of functionality, cause crashes, make your system unstable. Juniors are essentially code gremlins. I should know. I used to be one!

    Accept that their output will be pretty bad at first. You need to be supportive. Help them develop habits to double/triple/quadruple check that they have met the acceptance criteria. Get them to sense-check their work with someone to ensure that they have good quality work. It is your job to ensure that they improve. Teach them that it's their responsibility to be better than they were yesterday. Get  them to keep a tally of their bugs each week/fortnight/month.


    Their Code Sucks

    Let's be honest... We were all juniors in the beginning, and our code was really bad. Code from juniors can have any combination of the following:
    • Excessive verboseness
    • Unreadable
    • Logically flawed
    • Horrible naming
    • Undecipherable dependencies
    • God methods
    • God classes
    • Mega anti-patterns

    Be patient with your junior. Obviously if they're doing these things then you need to figure out how to be a good teacher. Give them some reading, send them to a clean code course, get them certified. Show them amazing code. Show them crappy code. Show them YOUR crappy code. Ask them to help you refactor some code you're working on. Ask them to pair program with you. Ask them to summarise a coding article for you. Help them realise that coding is like learning the violin. It takes years of practice, and even when you are good, you still make mistakes. 

    They Have No Opinion

    This is both pro and con. Juniors generally don't have enough knowledge or experience to have any useful input for some specific problems. On the other had, they don't have years of bias, so they can give you a fresh perspective to a problem.

    One thing I find useful is to ask their opinion first. It actually helps me understand my own problem, while also exposing them to real world complex problems. My opinion is that by asking complex problems it will push their thought processes to another level. They will try to solve this complex problem, and be better for it. Remember to thank them for their input. They tried to help, and should be encouraged to keep trying.

    Are They A Burden?

    By now you have probably realised that you have to explain everything to them. If this is a big problem then perhaps you need to look at your organisation / team and see how it can be more accommodating to mentoring/teaching/coaching etc.

    I have been in situations where the development team's reaction was "a junior is too much work, we're too busy to hire a junior". Does this sound familiar? It is a clear signal that people are overworked, and are being pushed to work harder and faster. Too much is being expected, and work is being shoved through your pipeline and pushed onto the dev team. The real burden might actually be up-stream. Fix that problem!

    Juniors are not really a burden. You need to figure out how to leverage their current skillset, while also expanding it.


    When They Succeed

    If you have done your job as a mentor/teacher/coach/leader/Yoda, then your junior will quickly become a mid-weight. They will begin to feel confident, and grow. They will start to shine. One day you will notice a shift in the way they talk an give input. It's like a light-switch suddenly gets flicked.

    It's a great feeling when you realise your junior has reached that next level. There are only a few things in the world that can give you this sense of pride. Your entire team will feel this. They all helped!


    Tips When Hiring a Junior Developer

    1. Hire people who are hungry to learn
    2. Show them good code, show your own bad code
    3. Remind them that it takes years to learn a profession
    4. Be explicit about the the maximum time you expect them to spend before asking for help
    5. Be explicit about having their code checked before submitting a pull request
    6. Ask them for their help in solving your complex problems
    7. Remember that there are no bad students. Only bad teachers.

    Final Thoughts

    Juniors are great, and teaching them is extremely gratifying. However, this takes time, effort and patience. When they succeed, you feel like a proud parent. You want them to grow. If you are attentive, you can generally get them productive in a matter of months. If you're really really attentive then you can get them leaping to mid-weight productivity in as little a year or two.


    Posts In This Series

    1. Interview Tips for Technical Leaders
    2. Tips To Ensure Quality Delivery When Outsourcing
    3. Tips When Taking On An Intern
    4. Tips When Hiring Senior Developers
    5. Tips When Hiring Junior Developers
    6. Tips When Offshoring Development Teams
    7. Tips When Hiring Digital Producers
    8. Tips When Hiring Remote People
    9. Tips To Improve Developer Retention (coming soon)
    10. Tips When Hiring Lead Developers (coming soon)











    Saturday 27 April 2019

    Good Help Is Hard To Find - Tips When Hiring Senior Developers

    This is the fourth in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.

    Introduction

    Hiring Senior developers gives you the confidence that things will get done, problems will get solved, and delivery will happen. They're an asset. But seniors can also come with some baggage...

    Why Should You Hire Senior Developers?

    Senior developers are great for velocity. They know their craft, they are fast, and they can guide junior / mid-wieght developers in projects. They can be the gold standard for processes and best practices in your company.

    Can You Teach An Old Dog New Tricks?

    Seniors have been doing their craft for years. Like everyone, they have good and bad habits. Expect that some people will have some sub-optimal habits which may be dated or even hacky. They might have done something for years without knowing that it was bad.

    Old habits die hard, so you need to be explicit and persistent if you want them to change. Give them an assignment to research modern best practices to present to the team. Get them to own it!

    Coding Standards

    Seniors come from different environments, and that's great! A  new senior might start doing things that are contrary to your current guidelines/standards, because they think it's better, or they're used to doing things differently. That can be fine, but sometimes can cause confusion to other devs.

    Gently remind them of the current coding guidelines and practices in the team. Be explicit that it is expected of the seniors to know these practices and set the example for other staff. If they really want  to change something, then get them to consult the team, and present their proposed changes. 

    Opinions

    Seniors have opinions, and that's what you want! However just because they are considered a senior does not mean that they will always have good ideas. Or your team might not be ready or capable such for big changes. Be aware that changes to process may have a good result, or negatively impact your  team / organisation for years. I've seen this happen! 

    If your new senior wants to change some processes then get them to present the problem and their solution to the team. Get some consensus and get feedback. This is a great exercise as it gets your team's collaborative juices flowing.

    If your team is very small or with little knowledge of proposition you can still take an empirical approach. Try it, inspect the outcome, adapt.

    Over Confidence

    There are some seniors who forget that the other developers in their team are not necessarily able to learn or perform as fast as them. Many concepts and architectural patterns are hard to learn, let alone implement with any degree of confidence.

    Remind your new senior that they need to put themselves in the shoes of the juniors and mid-weight devs in your organisation. Can the juniors learn/do it? If not, then have the new senior outline a plan on how to teach them. This is a great exercise as it helps the new senior to better understand the team capabilities.

    Progress Can Be A Battle

    A senior might prefer the status quo. I have met a few senior developers in the past who pushed back on any change. They were happy with sub-optimal practices as long as those practices/processes were familiar. Changes in process were treated as battles. 

    It's OK to be risk averse. Limiting risk comes with experience. However you also need to continue to evolve. There is a balance every developer and organisation needs to find. Remind your team that without learning we become redundant, without innovation companies fail, and the longer we stand still the faster other people and companies surpass us. Change is inevitable, and we should leverage it to our advantage.

    Tips When Hiring a Senior Developer

    1. Be explicit about your expectations
    2. Be explicit about adhering to the current coding guidelines / practices.
    3. Ask them to help implement best practices
    4. Take their input about how things can change/improve, and definitely get them to present to the team
    5. Be explicit that you expect them to be the gold standard for the more junior developers 
    6. Get them to teach concepts to your less experienced developers


    Final Thoughts

    Hiring a senior has many benefits. They're fast, knowledgeable, and can mentor others.  Leverage their experience and knowledge to help boost your other devs.

    They might also come with some baggage, so be pragmatic. Be aware that they might have some coding practices which will need to change. Be explicit with your expectations. Remember, experience does not equate to perfection. No one is perfect. We all have bad habits.



    Posts In This Series

    1. Interview Tips for Technical Leaders
    2. Tips To Ensure Quality Delivery When Outsourcing
    3. Tips When Taking On An Intern
    4. Tips When Hiring Senior Developers
    5. Tips When Hiring Junior Developers
    6. Tips When Offshoring Development Teams
    7. Tips When Hiring Digital Producers
    8. Tips When Hiring Remote People
    9. Tips To Improve Developer Retention (coming soon)
    10. Tips When Hiring Lead Developers (coming soon)
    11. Tips To Improve Developer Retention (coming soon)