Your software development team is the heart and blood of your start up. But what do they actually do? How do you make sure you get the most out of your developer, and provide them a supportive and structured space so they deliver the best results they can. In this article, we’ll go into this and more.
Sure writing “good” or “clean” code is important. But what has a far bigger impact on your business is a software developer who can understand what you require and deliver what you want. All this is a timely manner.
Before getting into the specifics, its worth having a look at the Software Development Lifecycle (SDLC)
SDLC – The Software Development Lifecycle
The Software Development Lifecycle (SDLC) can be separated into 5 separate components:
- Analysis – What do you want? Who (or what) interacts with this?
- Design – We know what you want, but how will it work? What technology are we using?
- Implementation – go do the work
- Maintenance / Support
- Planning – what next?
The analysis phase is where the technical team look at what is required and how we can make that happen.
In the Design phase, the developer will “design” the solution. Generally this looks like documents and spreadsheets, wireframes and mock-ups. Without using a computer, the developer will “show” you how the proposed solution will behave.
Remember to think of all the edge cases. For example, I enter a email & password to login. But what about if I use a email address that isn’t registered? Reset the password by entering a new password is fine. But what happens if the password is too short (eg 2 characters) What is the exact error message displayed?
A great developer will have thought through these scenarios.
By the end of the Design Phase, its typical to expect a list of tasks along with estimates.
Its important not to rush to the implementation phase. In the same way a builder doesn’t just turn up to site with some bricks & nails and say “let’s go”. They’ve had an architect design or review (Design Phase) they’ve gone to Council and obtained approval (Analysis).
This is where the rubber hits the road and the developer gets started. I encourage my developers to show me their progress anywhere between half a day to two days. Anything less than half a day is micromanaging and beyond two days is dangerous
Trust but verify was a saying Suzanne Massie, an American scholar, taught President Ronald Reagan during the nuclear disarmament discussions with the Soviet Union.
The context is that while its great that your development team are updating you regularly. But you should also “see” or experience what they are doing. If done correctly, this can inspire and encourage your team.
Hey Jim, can you show me what you’re working on?
AMAZING! Exactly what I was looking for. Keep at it!
Ok cool. I can see what’s happening. Can we please…. (adjust accordingly)
Nothing is worse off than having a developer spend 2 weeks going off on the wrong path. Even if they had the right intention, it doesn’t matter – it still isn’t what you wanted.
The Maintenance Phase is your support. Sometimes the term “Dev Ops” is used. Where its a mix of “Development” and “Operations”.
The time spent on maintenance really depends on how complicated and large your systems & processes are. Either way, you should be clear on what your needs and expectations. Not all developers want to do support.
Sometimes I refer this as “rinse & repeat”. What’s next? Should your developers review support issues? Are they reviewing a project backlog?
Generally your Planning Phase should have a view of weeks to months.
Common mistakes made when defining the role
Requirements vs Responsibilities
While the difference is subtle, it has a big impact on your team.
Ask the question: On a rating of 1 – 5, how well did Person XYZ do …
If you can’t score it, then its a requirement
Throw in the kitchen sink
Sometimes when a Founder or Entrepreneur isn’t clear on what they want, they throw EVERYTHING in. All this leads to is confusion & frustration. The developer will focus on their strengths. You’ll focus on something else. At review stage, they will think they’ve done a good job, you might think different. What happens next?
Including incorrect information
I find this one odd, but I’ve seen it so many times that its worth mentioning. If you don’t believe in your company values, then don’t include them. If the technology / product / industry has changed, make sure this is clear.
In the same way if a developer turned up to an interview in shorts and a t-shirt, it just makes them look bad. Same for you – incorrect or sloppy information reflects badly on you.
How frequently and when will the role be reviewed
A common mistake that can easily be fixed. Usually roles are reviewed annually, on the date the person started.
Common formats of the roles and responsibilities of a Software Developer
Your typical job description is broken into 4 sections
A paragraph or two describing your business. Who are you, who are your customers and what are you trying to do. You can also add business values, vision and mission statements
About the role
Some history & context describing the role. Who do they work with, what is the team size, and where is this role based (work from home or office location). If there are any unique elements or expectations for this role, you should add them here. Examples would be customer support in the evenings or weekends or if there are any travel requirements
What are they responsible for? To attract the right candidate, it helps to be as specific as possible. Will the candidate be presenting to clients? Are they designing solutions (or is that the responsibilites of someone else such as a software architect?)
Be careful what you feel is “required”. Is a software degree really necessary? Say you have a mid-level role, you have two candidates. One has a degree and 3 years experience. The other has no degree but 7 years experience. Would you seriously ignore the 2nd candidate? Perhaps – but if so, be sure to include why.
Desired skills is bar far the most important section. The other are option. Here you should be as specific as possible with the technology to be used.
Is it Node or Java? .Net, Go, Python etc. etc. If its not the latest version, make sure you include any version information. Be specific if its important (eg Kubernetes) or be general if its not (Microservices). Don’t add details to pad it out.
Business & Culture
This is a vanity section that some businesses believe are important. Here you talk about the type of company, its facilities, why it is a good place to work.
As an example:
With a keen focus on our staff’s professional development, [BUSINESS NAME] is committed to promoting a happy and creative working environment that is both autonomous and collaborative.
This is an extract from a real position description. I’m not even sure what it means.