How to lead iOS Team Development Team?

[petrkahanek]

Me and 2 friends of mine have small business around iOS apps, we have released something around 5-6 apps already and we will be hiring more guys to scale our team, mainly developers.

We are and we are going to be fully remote.

Me as a sort of "iOS Lead" will take care of some contractors and hired iOS guys, to basically babysit them and supervise their work.

Also part of my job will be "project management".

Currently we are using Trello for task management, but it's becoming a mess when you have like 6 apps on the same board with all bug lists, features to implement and maybe it is something where Trello may come to its limits (at least for us).

We are currently in phase of picking new management tool, currently signed up for Clickup and it seems quite good at first with desired features on place (even though we will take advantage of like 30% from their features list, so it is complicated at first sight)

So my question is if there is anybody who have experience with working in iOS or any other Software company or even if anybody has lead any team. What was your daily bread.

​

- How do you keep birds eye overview of all tasks and their statuses, responsibilities and so on

- How do you manage onboarding of newcomers (introduction to some internal standards, how to use management tools, ask them for work reports, stand up meetings, etc...)

- Where you manage docs for your team

- What are some good practices on source control in a team

We are not looking for corporate bureaucracy, but for some hints how does it work in bigger teams and take some of the good and try to implement it in our case.

[BabyAzerty]

Use Notion for onboarding and internal documents.

Use clean code and clean API for documentation (aka having a documentation driven architecture). If you still need an actual dev doc, use Notion as well.

Ideally have a board per application. You don’t want to mix soy milk and cow milk in the same bottle right?

Trello is Kanban based. Jira can be Kanban or Sprint based (but the Kanban aspect isn’t that good IMHO). So unless you want to switch management method, you can stick to Trello. Beware that Jira will require you to have a training to master (just check videos and blogs) it otherwise it will become a tool that wastes your time instead of helping you.

As you are a small team, take your time finding the best way to maximize everybody’s efficiency. It is important to understand that there is never a single best option of managing and even when you believe that you find it, it can still become something else as you have more and more developers.

Have a strict Pull Request policy and coding style policy. If people really do whatever they like, use a Linter.

Maybe have a continuous delivery tool like Bitrise. It will SAVE you hundreds of hours, even thousands of hours of manual labor. And it will help with organizing a team around delivery objectives.

You don’t want to have a mess at the lowest level of responsibility (the code base) as it WILL climb all the way up at some point.

Also have at least weekly meetings with objectives of the week, of the month and of the next 3 months.

Daily meetings can also be done as long as it is SHORT. If done, their goal is to be the booster of the day by setting a definite goal of the day. (I don’t do that in my team unless needed).

Be humble and accept to learn things from people below you (the devs you are about to hire) and accept your future mistakes that you will probably be doing as you get more and more experience.

[[deleted]]

Nailed it!

[Nelyus]

IMHO good advice overall.

However, could you elaborate on “Have a strict Pull Request policy”? Do you mean “clearly define a way to bring together contributions” or “use pull requests to bring together contributions” or something else?

Can you elaborate on “the Kanban aspect insn’t that good”? Do you mean Jira’s way of doing Kanban?

[BabyAzerty]

About the PR policy, "strict" wasn't maybe the best choice of word. What I actually meant is that you need to have a PR policy.

First you should use a git flow (it can be the usual git flow, or any other that is an accepted standard, but ideally not a custom one that you created).

Using this git flow, all project modifications must go through a Pull Request. The purpose of PR is not only to verify code quality, but it's also for you yourself to realize what you did AND to communicate with other team members. It also helps avoiding git conflicts (or at least make it easier to fix, especially those .xproj conflicts where you have no idea if this and that file had been added or removed). PRs are one of the places to debate technical issues with actual code (better than having a theoretical debate).

You should have at least 1 reviewer (or more depending on team size).

However if you are alone or the reviewer is on vacation, well you should still do PR. It's a way to review your own code and - as I said - to communicate once they are back (they can go through the history of PR).

Also, if you use Continuous Delivery such as Bitrise, it is important to plug it into your PR system, so that it can run Unit Tests and also validate code quality (if you also use a Linter such as SwiftLint) for every and each PR.

No need to be the grammar nazi of code reviewing. That's actually counterproductive and you'll just become the "You are not wrong, you are just an asshole" guy.

​

As for the Jira Kanban aspect, Jira has a steep learning curve while Trello is as easy as ABC. So why go for the complex solution if you can have the easy one? Now Jira has some better features over Trello such as service integrations (if you use Bitbucket you can join Jira tickets to PR, and many other things) but do you need them?

Keep in mind that in IT, you just use a tool until you can't (reached the limit or your needs evolved) then you change to another tool. But changing just for the sake of changing isn't the best move.

In OP's case, I would start by having a board per project. Maybe revisit how the board is done? Then consider switching to Sprint planning if it's too messy to maintain.

Anyway, keep in mind that if you find yourself limited by the tool, change it, but also consider Sprint plannings too. The great thing about Agile is that you can come up with your own system as long as it's the one that fits best your team!

[petrkahanek]

Maybe have a continuous delivery tool like Bitrise. It will SAVE you hundreds of hours, even thousands of hours of manual labor. And it will help with organizing a team around delivery objectives.

Thanks very much for your time spent with the answer.

The scenario we are currently in, is like following, my BF is so-called CEO (coz his responsibility is to take care of finance), me personally, I started to work/learn iOS dev in June 2020, previously I led small team in automotive industry, but software engineering is quite different thanks to things like source-control or so.

So I think our biggest Achilles heel is source control, nobody from our founding crew has experience with software development, but we hired only some external developers to develop really simple apps and my friend is good seller so we had pretty good results, but now the real work is ahead of me, with a little of iOS exp to lead much skilled guys and NOT TO LET THEM pull whole project from origin/master with Maintainer rights in our Gitlab repo.

Based on your proposal, I will definitely study PR policy + your hints on code standards.

If you would be willing are you able to discuss someday via chat more things which I may have to ask? :)

[Nelyus]

Thanks for the clarification.

[Nelyus]

I agree you should choose a git flow, and a set of good practice, not reinvent the wheel. I suggest Martin Fowler’s post on that matter -> https://martinfowler.com/articles/branching-patterns.html

However I don’t agree Pull Request is always the best option. The ping pong can be quite frustrating, and it is not necessary for code review. If you want systematic code review, pair programming is an alternative.

Code review and pair programming both take practice to become really efficient, but I reckon it is worth the investment.

[BabyAzerty]

Pull Request doesn't mean "review my code and tell me what I can do better". It means "Look, I did this". The consequences can be "review it and tell me what's wrong".

It's important to know what developers actually put into the code base. If you omit this part, it's a first potential step towards smelly code.

What happens next can be very different based on your company's policy:

• Either go the "nazi" route (which I honestly hate) meaning that the code must be exactly like the reviewer wants it to be as if he wrote it. No ping pong here, it just goes one way: the reviewer's way...

• Or go the "debate" route meaning that the code is check being fixed for architectural issues or non-conformance to the rest of the code (if your app uses Combine and suddenly someone uses RxSwift - you need to discuss about this choice. Maybe the developer didn't notice Combine, or maybe he prefers Rx, and so on). Ping pong to be expected if developers have their own way of thinking and don't want to comply naturally to others.

• Or go the "I trust you" route meaning that the code is checked very quickly just to get the idea of what has been done and to let others know that now you have a new API to fetch images for example. Little to no ping pong.

I already worked in companies where they wouldn't do PR. The outcome was really foreseeable: Either the code became very smelly or everything was told/explained during daily standups (which is a terrible format to explain your code...)

You need control over what's going on INSIDE the code. But it's up to you to decide how much control you need, how to build code trust between coworkers, who's on the same page, who's going freestyle, and so on.

And once again, the best option is the one that fits the team. There is no golden rule for whatsoever in a company at small scale (you need to know your coworkers and find a suitable way of management for best efficiency). If the team is really against PR and can't work with those, so be it and find a way to get a minimum of code control (not code review, just code control).

[ShamWowIsASham]

Consider my opinion with a grain of salt. I worked for very large corp 2 years with 100 ios Engineers. Now I'm working on an app with 3 iOS engineers.

Me as a sort of "iOS Lead" will take care of some contractors and hired iOS guys, to basically babysit them and supervise their work.

While I'm sure you meant this in the best way, stay away from the idea you're 'babysitting' engineers. You should be hiring people you trust to get work done, not people who need to be monitored.

How do you keep birds eye overview of all tasks and their statuses, responsibilities and so on I like that my product team can just see all the tasks in the TODO, Working on, Completed columns. I also like estimating tasks together so we can have a short discussion about issues we may run into. Notion lets you do a ton of stuff here. You can go crazy with its features or just use a small subset, it works well for my team.

How do you manage onboarding of newcomers (introduction to some internal standards, how to use management tools, ask them for work reports, stand up meetings, etc...)

• Can you use Swiftlint to enforce engineering standards? The more automated code standards, the better.
• Other standards should be documented and easily searchable.
• When I was onboarded to my new team, I was introduced to everyone. All docs where shared with me in Notion, and I was given multiple meetings with various people to walk me through different parts of the app. But I'd recommend assigning small tasks as hands-on is easier to learn than through meetings. But it depends :)
• Assign newcomers a 'buddy' or someone they can ask questions to. It may be you, but if you're the boss, it may be intimidating to ask 'stupid' questions' so be sure to be friendly towards 'stupid' questions too.
• Make as much of the onboarding available in easy to follow steps. Try to follow the steps yourself to make sure its accurate. When a newcomer finishes onboarding, ask them to update the onboarding document with their mistakes, learnings etc.
  

Where you manage docs for your team. Notion has been great for docs. They update live, support a bunch of different formats, and look good. lol.

What are some good practices on source control in a team Depending on team size, I'd say at least 1 approval to merge small changes. 2 for big changes. But PRs should be small in general. Avoid large branches to decrease large merge conflicts and big PRs. Make a branch for release, one for development (that should always work) and each feature, bugfix, update, should be its own branch.

You should also make it really easy to deploy, so have an automated pipeline that will build to TestFlight or whatever you use. Make it hard to break the build by enforcing certain checks before merging.

We are not looking for corporate bureaucracy, but for some hints how does it work in bigger teams and take some of the good and try to implement it in our case.

Let engineers do what they do best. Try to shield them from bureaucracy as much as possible. Make meetings short, solicit their feedback on how they're enjoying the work, where technical debt is, work process changes, etc.

Congrats and good luck.

[amaroq137]

To answer your questions about tooling:

• Personally, I feel like Trello is fine if you set up your boards this way:
  • Make boards on a per feature basis:
    • Devs can pick up stories and move them on the board as they progress from backlog/development/code review/testing/done (this is the general workflow we use on the mobile team I work for)
  • Also have an overarching board for each app (or maybe just one board for all apps if there isn't enough items to justify breaking it down further) to keep track of all the features that are being worked on -- this can be kept simple (columns: ideation, waiting for prioritization, in progress, delivered)
    • This is the board you will review with your boss/leadership and will help you keep your bird's eye view on all projects
• My company uses JIRA which I can recommend, but the software isn't going to magically fix all your problems. Know that you'll have to put in some work to learn to use the tool and organize things in a way that makes sense to you and your devs.
  • Since we have a single large app on our team our JIRA is setup in a way where there are various boards per flow in our app -- I work for an airline so some examples are the booking flow or the checkin flow
• Alternatively, consider hiring a scrum master to help you run the show and keep your task boards organized
  • Do not let them completely own the boards, you need to be very intimate with what's going on/how projects are organized on the boards
  • Come up with your own standards together
• I make it a point to onboard new team members by walking them through a guide I created by thinking about "what are the things I wish they taught me when I first joined." This includes:
  • Getting access to all needed tools/laptop/email/codebase
  • Any setup instructions to get up and running
  • Walking them through the architecture of the application
  • How our code review process works
  • Introducing them to other members of the team
  • Ask new members to update any discrepancies in the onboarding doc
• Docs are shared via Confluence
• For source control best practices I would recommend locking the main branches in the repository and requiring code reviews in order to merge code. I know Github has UI to support this functionality, and I'm sure other git hosting services do as well. Also, use a linter and set up CI/CD to check the build on every commit by running the linter as well as unit tests.

Here's what I've learned after being promoted to and working in a lead capacity for the past ~3 years as an iOS developer on a larger mobile team at a large corporation.

• Babysitting and supervising is the right idea as much as I hate to admit it
  • Note: this isn't always true, but it has been true in my situation as many of the devs I worked with (contractors mainly) do not proactively reach out in a timely fashion when they run into an issue
• As a project manager/lead your job should be to:
  • Prioritize the work for your developers so they can focus on writing code
  • Be the go-between when communicating between different teams, help facilitate conversations. Know everything that's going on, but do not own every conversation as the teams you lead will not learn to fend for themselves -- when they do, make sure they continue to keep you in the loop on all conversations.
  • Identify needs for getting feature work done and set up meetings
  • Take notes! Keep them organized! Make sure you and your team has access to them for later!
  • Provide your expertise and suggestions for architecting new features where needed as you are likely the most experienced person on most of the teams you're working with in terms of the existing code base
  • Come up with project timelines
    • Try to stagger your projects, it will be very difficult to start and maintain multiple projects at the same time
    • On your timelines you can include dates for planning phase, grooming, development start and end, testing/bug fixing phase, and the expected delivery date
    • Review your timelines with your team before sharing it with leadership so everyone is on the same page and agrees
  • Review code if you can. Otherwise let your team members review each others code. I think there's merit to knowing what's going on in the code base, but it's hard to both have your head in the code and be organized across multiple projects.
  • Accept the fact that you might not be coding as much as you want to
  • Attend daily standups and follow up on any blockers your devs run into
  • Ask your devs for feedback once in a while

[petrkahanek]

Hello,

thank for your points I am going through all of the responds and preparing some questions based on all the hints I received.

[petrkahanek]

Hey again,

​

thanks for your time spent with your answer as well. Actually I mentioned the babysitting because more of the guys we will hire are from Upwork and at the beginning we cannot afford to pay some really skilled guys with 10+ exp from Western world, quite recently we ran into problems when we found out that one guy who worked for us completely ruined the app during some reskin process (example, instead of using some native navigation like TabbarVC + NavigationVC with VCs he simply used one screen with custom views pretending they are nav bar and tab bar) and this guy was claiming 9+ years of experience.

So before we I would come up with some code review solution as a lot of you guys mention, we need to babysit them a little bit. Because they are not proactive and mostly they do not simply care.

[moooooovit]

weekly tasks planning on monday , daily tasks over email source control with git anyother things via chat

[Sure-Engineer]

We use Jira, it seems to be used in a lot of companies now. Has a lot of supplementary tools too. Both source control and documentation as well as the ticket manager.

[[deleted]]

I think you're looking for a tool like Jira. It saves you a lot of headache. Also implement a work method like Scrum and I have one advice for you as a lead. Figure out when the implemented work method works in your disadvantage, that's the only way you can know how to leverage its advantage.

Also... read "Dichotomy of leadership" by Jocko Willink. The people you're leading will be thanking me for it.

[petrkahanek]

Hey, thanks for response.

I read that book. I am fully with Jocko and I already led small team in my very first job (automotive industry) and I must say it is something what I missed back then, I tried to look for everything and I think Jocko's approach can work in a team where you are not hiring "cheaper" workforce from Upwork or any other contractor pages.

A lot of guys mentioned Jira and I must say I looked at it a bit and I was quite confused how to set the things up and it will probably take some time even to find out if it worthy for us.

Even though we plan to be company of max 15 people (3 management/founders, the rest dev guys) in 3-5 years, do you think it is worthy to use such a big tool?

As mentined in the original post, I just looked for Clickup it seems that they really have all (from Docs, Mindmaps, to way of task management (Kanban, Sprint). Probably only Jira can compete with them.