Imagine you are setting up a new dev team. Either to your current company or to a new one.
What are the first things you would do to safeguard the quality of your day to day life? Those could be technical or more procedural like:
Setting up CI/CD, coding standards, remove technical debt, etc
Setting out a clear process the various recurring meetings, ground rules like "leave the meeting if it is not valuable to you", evaluation processes, 1-1s, etc
Oldest comments (15)
I am less than a month away from releasing a 200+ pages book where I discuss exactly that question :-). From
git initto production and anything in between. It's called Cloud Native Web Development and if you're interested, head over to gum.co/cloud-native-web-development for a full table of contents and more details.At a high-level, I'd focus on removing friction for the dev team, automating what can be automated, focus on testing and quick, frequent production deployments using feature toggles to guard unfinished code from running in production.
Nice coincidence :) Good luck on your book.
How would you remove friction?
Good question, let me specify that a bit better.
One area that often causes friction is setting up a project's development environment. I'd personally use gitpod.io (Why I use a cloud-based development environment and how you can too) so that developers on the team can click a link and start up a fully configured environment.
Another area is CI / CD. I'd develop that pipeline as early as possible when it's still very simple to do. Then as the project grows, the CI / CD configuration grows with it organically.
Never thought to use gitpod this way. For most companies cloud IDEs are a no-go. Nice tips :)
Even if it's self-hosted as per gitpod.io/self-hosted?
I understand the concerns when it's used a SaaS offering.
I didnt know that option. That sounds better indeed
Definitely formal process and roles definition. From how the team receives backlogs, development process, review process, testing process, release process up to bugs management.
If youโre a manager like myself, I suggest not to be involved into technical details too much e.g. about which CI/CD tools to use. Let the team decides how to do it in technical details while you decide what to do, i.e. the process itself and strategical stuffs.
I wouldnโt worry about defining banal ground rules such as meetings, evaluations etc. If you decide to have scrum most of these rules have been defined already and you only need to adjust the rules from time to time.
I agree with the technical details thing, though it is easy in days of such change (eg new team leader or reorganization) to have increased tension and change-everything attitude. We also tend to be a very opinionated clan of people :)
So how would you resolve such conflicts if consensus is not an option?
From how the team receives backlogs, development process, review process, testing process, release process up to bugs management.That is so true.
I wouldnโt worry about defining banal ground rules such as meetings, evaluations, etc. If you decide to have scrum most of these rules have been defined already and you only need to adjust the rules from time to time.Indeed for the meetings, I think evaluations though are still DIY in such frameworks though. Correct me if I am wrong
Hereโs how I do it for my team. Every team member is free to give suggestions about tools, libraries, technologies, etc. If a team member wants to apply a tool/library for the whole team (e.g. CI/CD tool), then he/she must persuade other team members first. Then the team comes to me with the suggestion and justifications. I am the one that approve these tools/libraries before the team is allowed to use them. Ultimately I want to make sure that, among other things, 1) the licenses are fine 2) if itโs a paid product I have the budget for it 3) the tools/libraries are mature, stable and well supported and 4) if I need to replace the team member(s) I can find replacements easily.
If the team needs to decide on technologies but they canโt do it because occasionally they are such an opinionated bunch, then I will gladly make the decision for them based on my judgement.
Regarding evaluations, scrum has retrospective and review which in my experience are sufficient to evaluate the teamโs performance. I donโt conduct yearly personal evaluation due to several reasons 1) itโs an outdated concept 2) a year is too long for an evaluation and 3) I evaluate my engineers when I need to address decrease in their performance and try to fix it ASAP before the performance decrease becomes a burden for the team.
I like your approach the tech things.
How do you defend any raises or appraisal results in general to HR or high technical management? Depends on the company, of course, smaller companies tend to be more flexible here and others favor formality.
I know most of these discussions look into processes and automations, but I'd first make sure the team is cohesive and there is trust between every member. Once you have that, give the makers space to set up their environment as they best see fit.
How would you assert the trust levels? 1-1s?
I personally can't stand 1-1, I'd rather just have lunch together and chat. But yeah, it boils down to knowing your team, respecting and empowering the people. This is all soft skills territory, so it's hard to be specific.
Google years ago found out that the best indicator of the performance of a team is how safe the members felt (that is, feeling safe to speak up, because you'll be treated with respect and listened to, etc.)
Share with them the bigger picture that they are working toward for the customer, and how the team fits within the organization. Empower the team to self organize. A lot of things will naturally fall out of that even if you don't set them up initially, like ground rules, CI/CD, coding standards. Because with the proper goal and context, they will seek to optimize their own work and how progress is communicated to the organization. As team lead, an important job becomes to keep the customer's desired outcomes at the forefront as new issues come up. A lot of complexity can be avoided by simply remembering and rehearsing goals and context as the need arises.
The customer perspective is so important and thanks for pointing it out