Skip to main content

Roles in a software team

developer
I am 100% convinced that an everybody should start like a developer. Simply just do a real programming, get the hands dirty with a code.  Who never does this, never understands ...

 sw designer
designs some parts of a software application: DB tables, OOP classes and interfaces, test cases, re-factoring, framework integration and communication. Usually prepares the skeletons or the code templates and best practices for the developers

technologist
typically a kid playing always with a new toys, usually executes evaluations. Must be very fast learner with large technology overview. Curios, critical, technology evangelist

consultant/specialist
particular technology or process expert, very often supports more teams or companies

tech writer
clearly documents all aspect of a software product by leveraging appropriate tools and techniques

integrator
integrates all pieces of the system nicely together, also smoothly integrates a whole system with a customer's environment

qa/tester
ensures required quality level of a product and reasonable test coverage by minimal testing effort. Usually prepares and executes all kinds of tests except 'unit' tests which are typically done by developers

 devOps
works on infrastructure and deployment automation (CI & CD) to achieve best efficiency of the team

analyst
communicates with a customer and analyzes requirements. Prepares logically consistent specification of the system suitable for a development. Creates a domain model of the system

scrum master
evangelizes and coaches an agile methodology, removes any obstacles and impediments, moderates scrum meetings, coordinates team work on a backlog to achieve the goal of the sprint

scrum product owner
creates and prioritizes/orders a product backlog according customer's requirements, usually is from customer's company or plays role of customer, product owner leads development of a product in right direction

 technical leader
is responsible for particular technology; coaches team members to be 'state of art' and evangelizes best practices; he is responsible that code looks like written by one mind

architect
defines a system architecture which should be stable for strategic time. Pushes the architecture to the team and manages that the architecture is correctly implemented by best practices and high code quality.  Also architect should understand important implementation details and coordinate new development. Must have solid technology overview and pragmatic altitude

 team leader
focuses on people, tracks happiness in the team, leads team member's career paths and builds team culture; on one hand the leader should be zen master to comfort the team in hard times but on other hand must makes the waves to challenge people to grow. Leader is usually only one with the disciplinary rights 

product manager
manages product features and product future (roadmap) in order to amplifies product value for customer; basically product should be his 'baby'; ideally never-ending

project manager
manages bigger software project from process point of view, organizes, schedules and controls; coordinates progress between more teams form start to end

professional service
implements a solution at customer's site

support
takes care about solution after users acceptation, with focus on customer's happiness

cloudOps
responsible for operations of product in cloud environment, manages version roll-out, tenant creation, monitoring...

feature lead
deeply understands particular feature and coordinate effort (discovery, coding, testing & deployment) of few people (2-5) in the team to implement feature successfully

ui/ux designer
works on flawless interaction between product and end users; investigates and prepares concepts, sketches, wire-frames, pictures or animations of product user interface to be developed

data analyst
helps team to understand business data which are related to product/project development; provides base for data informed decisions

NOTE: one person has usually more roles  ;-)

Comments

Post a Comment

Popular posts from this blog

Senior or Junior

Usually companies call young employees Juniors and more experienced Seniors. Sometimes you need to just sit and wait and it will come. Sooner or later. From my point of view it is not enough. I met a lot of old employees they call themselves Seniors but they behave like Juniors. So I defined my point of view on Seniority: professional simple understand what I am doing and understand reason why I am doing it can coach others this is very basic; who can coach others is just fine but who can coach others to became a new coaches is super not genius but have deep knowledge on some specialized parts geniality is overestimated, we do not need "magical guru", to be expert is good enough; if you are "one to go" when there is problem, it is OK big picture overview it is not probably possible to understand a whole system in details but it is necessary to have at least overview know what I know and know what I do not know to see myself in correct light is very ...
Post a Comment
Read more

Anti-Lean Quotes

Set of quotes which usually highlights Anti-Lean behavior Create waste instead of Eliminate waste ' Developer who is not working at least on 4 projects is not properly utilized ' - less is definitely more and only done-done work counts by end of the day, limited work in progress is helping to focus on right priorities ' In case of any network issues please create a ticket on the help desk system at our partner's web-page' - creating catch 22 situations by design is craziness, such a process does not make any sense 'Yes, this is what our customers really need but could we add also this small feature, just in the case?' - extra feature creates an extra complexity, it is better to stay focused on real value and make it great for the users ' I know that you are working on the top priority but I am sure that you can do also this small task till noon' - probably there will be nothing really done by noon, task switching is more expensiv...
Post a Comment
Read more

Software Engineer

Recently my company expanded the Software Engineer positions in my team. This leads me to thinking about the skills which are necessary for these positions. So I prepared a list of qualities which I think are important for a good Software Engineer. Abstract concept modelling This is essential and there is no room for discussion on this because this is what we do. Love to code It does not matter if you are 15 or 50 or if you write code 10% or 90% of your time, code writing is crucial. Team player The surgeon style teams (one genius with helpers) are obsolete, I prefer real team players who are able to work towards a common goal and share responsibilities. Communicative Silent geeks siting in the corner with a notebook on their knees are not cool any more, we need to talk to each other, we need to be able explain technical stuff to non technical managers, we need to be able to choose the right phrase at the right time. Take responsibility There is...
Post a Comment
Read more

Scrum rollout

Would you like to start with Scrum in your team? These are few hints from my experience how to make this process smooth, iterative & incremental: get commitment from the management & team define reason: why would you like to do Scrum? what problems it should solve for you? start with simple Kanban in one team: it is easier, you just need to manage 3 lists: backlog (todo), work in progress and done  focus on right priorities of backlog - person who defines the priorities will be 'product owner' setup quick way how to track work in progress and indicate 'impediments' -> daily stand-up; max 15 minutes meeting every day - moderator of the meeting will be 'scrum master', he will be also responsible for solving the 'impediments' focus on dependencies between the tasks to avoid 'impediments' start to put 'discoveries' into the backlog to pre-analyze tasks; discoveries should be done by architect or analyst what is the busi...
Post a Comment
Read more

Agile is not a religion

It is quite annoying to me when argument during discussion is like this:  it must be XY because the book says it. It is kind of: Bible is saying XY so we have to follow = end of discussion.  I am not very happy in such a case because we probably do not understand principles and just trying to blindly imitate something without deep knowledge of the matter. I prefer to admit it or show personal standpoint.
Post a Comment
Read more