DEV Community: Aviv Kotek

Pods: A Lightweight Delivery Approach

Aviv Kotek — Sun, 23 Mar 2025 18:35:20 +0000

Not sure how to structure your team for delivery? This simple model can help most teams get started and deliver effectively.

Prerequisites: A cross-functional team (not "just backend") and visibility into quarterly objectives (quarter feature list).

Over the past six months, we've transitioned from Scrumban to a Pods model and saw great results. Here's how it works:

Pods: Split team into 2–3 small, autonomous groups per quarter, each solving one business problem.
Quarterly Focus: Think and plan by quarters. Cancel Sprints.
Pod Lead: Breaks down work, assigns tasks to pod members, decides who does what and is accountable for delivery.
Pod Weekly Sync: Maintain context and alignment in a 15-30m sync-meeting.
Dedicated Channel: Each pod has its own Teams space where discussions occur.
Micro Interactions: 3 people max (4 with TL) - for both pods and meetings. Keep interactions small.
Get Things Done: No Sprints, planning or backlog management. Work without interrupts.

Ideas for future:

Pod to work against defined business goals (and not feature specs).
Add an Analyst to each pod.

Big thanks to Jona Harris and Gilad Naor for your advice along the way :)

Joining an existing team can be quite challenging

Aviv Kotek — Thu, 04 Jul 2024 20:57:47 +0000

Joining an existing team can be quite challenging.

Work is already in progress, you lack significant (sometimes basic) knowledge, have no pre-existing relationships and are expected to make an impact in a relatively short period of time.

A useful strategy for ramping up quickly as an Engineering Manager is running Boz Algorithm (Thanks Gilad!).

On your second day at work, meet with a team member and:

Ask him to tell you everything he thinks you should know. Listen and take notes.
Ask about the biggest challenges the team has right now.
Ask who else you should talk to: write down all the names.

Recursively run the algorithm on anyone listed at (3).

From (1), you can quickly identify issues that bother team right now and require action. It will also get you familiar with current terminology team uses ("That XY Pipeline...."). This can be tricky, as not everyone will answer right away, so try rephrasing your question ("Is there anything technical you think I should know?", "Product/People/Process?")

From (2), you can identify low-effort items that are important to the team. This will allow you to make a quick impact.("Kanban board is a mess", "So many meetings....", "Daily is so long...", etc).

From (3), you can quickly create a map of influence within the organization. The frequency and context in which names appear will let you know on who to focus more at the very beginning.

Onboarding new devs

Aviv Kotek — Sat, 29 Jun 2024 09:40:48 +0000

Ramping up quickly matters

Assuming an engineer's median tenure is 2-2.5 years, ramping up quickly matters.

I believe a new dev should be delivering value after 4 weeks of intensive, planned onboarding.

Consider an alternative, where value is delivered after six months. A five-month delay accounts for 20% loss of an employee's budget. fun numbers

Following below ideas, you can create your own team-specific onboarding plan:

Methodology:

Managers responsibility: ramping up is 100% managers job. Free up your time and take it seriously.
Task oriented: create a Story ticket, with relevant sub-tasks owned by dev, committed to current Sprint.
Hands-on: onboarding includes code and production tasks from the very beginning (think 'bootcamp'). We'll start with a code-task to align standards and conventions and move quickly to production tasks.
Prod tasks can be either: {bug, refactor, small-feature, infra imprv}.
Duration: 4x weeks, 2w for logistics, dev-task and learning. another 2w for prod tasks.
Identify early low performers. bad hires happen, don't drag this too long and try to find red flags from the very begining.
Identify early technical weakness, areas of improvements and adjust the onboarding plan accordingly ("New hire never queried a DB").
Ceremonies alignment: this is the time to align on: time estimations, technical design, code review and Daily. New hire report's progress on Daily.
Conventions alignment: pushes code into a sample repository, following existing standards and validated by code review.
1x Buddy / Context: define a Senior developer that will follow new hire. Every question should go to him, we'd like to minimize overall teams context-switch. This is also a chance to let "potential leaders" an option to mentor others.
Self led: it is expected from hire to own and run plan independently. Should not drain other peoples time.
Brook's law: do not engage with critical prod tasks at the beginning.
Get to know your colleagues: engage with existing team members via learning sessions, where team members teach you a technical related subject and relationships are built ("Backend Services Overview").
Local environment: invest time installing local env early on. Verify you have a simple "how-to" document.
Sanity checks: schedule check-ins to verify things are as expected and verify: {Do you want to pair more? Do you want more alone time? Are there particular areas you need more guidance in?}.
Retrospective: conduct retrospective meeting, collect data, feedback and adjust plan accordingly.
Serves a dual purpose: an opportunity to demonstrate new hire that they have joined a professional environment.

"Most bootcamp graduates agree that the most valuable part of bootcamp is the tasks they are assigned. 
Engineers have real work assigned to them the first time they open their laptops and many push code to the live site within their first week."
(Boz, 2009)

Following these ideas, you can build your own onboarding plan, heres how we do it in Semperis:

You don't always have to be doing something

Aviv Kotek — Wed, 26 Jun 2024 21:06:04 +0000

It often surprises people when I suggest them to rest or read something when they have completed their Sprint tasks.

You don't always have to be doing something.

Managers often believe that keeping everyone occupied is essential, feeling accomplished when everyone around them is busy.

However, in software delivery, it's more like a relay race. (Taiichi Ohno). Each team member plays a crucial role in achieving the common goal by completing their part.

We should focus on passing the baton forward by working on items that matter and provide (business) value, rather than just staying busy and actually, keep running in circles.

Taking a break, observing or reading something that interest you, can help you identify what truly matters, allowing you to get back to the race and pass the baton effectively.

Running effective meetings

Aviv Kotek — Mon, 15 Jan 2024 21:27:26 +0000

After experimenting with meetings in recent years at Sproutt, here are some of our conclusions for running effective meetings:

Utilize a Meetings App:
Have your meeting agendas and notes on a cloud app for time savings and increased transparency. Tag colleagues with action items or notes before and after meetings. At Sproutt, we use Fellow.
Template Recurrent Meetings:
Create templates for recurring meetings (Weekly, R&D Monthly, Product-R&D, 1:1, Retrospective) to save time on agenda preparation. Fellow templates work well for us.
Schedule 15min Meetings:
Experiment with shorter, 15-minute meetings. No introductions and side-talks, get things done..
Schedule Meetings Around Recurrent Events:
Avoid spreading meetings throughout the day (1x morning... 1x afternoon); it disrupts a maker's schedule. Instead, schedule them next to existing and recurring events, like lunch or Daily to minimizing interruptions and context switch.
Weekly Meetings Planning:
Start each week by dedicating 20 minutes to plan and outline agendas for all upcoming meetings. Automation (what you communicate in each meeting) isn't just for development; it can also streamline your meetings..
Keep Attendees Minimal:
For technical meetings, limit participants to four or fewer; for non-technical meetings, a maximum of six is ideal.

A simple focus time framework

Aviv Kotek — Sun, 03 Sep 2023 17:33:45 +0000

Switching from an individual contributor (IC) to becoming a manager is quite a shift for a developer. Apart from handling different tasks, it also means you've got to be great at managing your time.

Transitioning from handling different tasks each week to taking on a broader range of responsibilities is a significant shift. Instead of focusing on development, code reviews, DevOps and being on call, you'll find yourself responsible for a wider variety of tasks.

This shift can be particularly challenging if you're used to the focused, uninterrupted time of a 'Maker's schedule' (Paul Graham), as managerial roles often involve more meetings and diverse tasks that can disrupt concentrated work periods.

With more meetings and responsibilities, it can sometimes be tough to stay on track.

I propose a straightforward time management framework, the "Weekly Focus System" to help you manage your time effectively:

Begin by scheduling a meeting with your direct manager to clearly define your role. Together, discuss "What success looks like" (Gilad Naor).

Categorize your responsibilities into specific activities and assign each one a label (Technical = T, Product & Business = PB, Management = M).
Allocate a percentage of your time to each activity. (50% T, 20% PB, 30% M)

Break down each activity into sub-task and list them in order of priority from left to right. For example, if 40% of your time is dedicated to Technical tasks, break them like this: [Code Review, Tech Design, Code, DevOps].
Create a table with N rows and 2 columns, labeling them as Activity and Time.
Fill in the table as follows:

For each activity, note the time needed for a focused work block.
Determine the number of blocks required, specify the days, and calculate the total (e.g., "Code Review" 2h Mon, Wed => 4h).

Transform the matrix into recurring and actionable time block on your Google Calendar.

Commit to this plan, give it a try, and adjust it iteratively as needed.

Owning your time and estimating better - Toggl Track

Aviv Kotek — Mon, 14 Aug 2023 14:12:43 +0000

A common phenomenon many engineers experience is the feeling that despite starting their day early, it ends without tangible progress or a clear sense of what was achieved.

"It's already 6 PM and I haven't accomplished anything"

Apart from the discomfort this brings, repeated experiences of this situation negatively impact performance and productivity.

One of the most crucial skills engineers need, and one that distinguishes junior engineers from their more seasoned counterparts, is the ability to estimate tasks. a somehow very challenging one.

My go-to method for handling estimations, is breaking tasks into smaller sub-tasks and allocating focused time blocks on my calendar (Code X, Code Y, DevOps Z, Product, Code Review). I then estimate the total time needed for each sub-task.

For instance, task X comprises x1 to x7, where x1 to x3 require a day each, and x4 to x7 take a week combined.

However, this becomes more challenging when there's no evidence of how much time a task should take due to lack of experience or historical data.

The uncertainty of time spent on smaller tasks contributes to the initial issue of time slipping away unnoticed, eroding our control over our schedules.

A few years ago, I adopted Toggl Track along with the Pomodoro technique, significantly boosting my productivity.

Toggl Track functions as a timer. You start it when a new 'focus' block begins and stop it when it ends.

The Pomodoro technique, which involves breaking work into 'focus' and 'break' intervals (1h focus, 10m break), empowers you to manage and own your time effectively.

At the end of each week, you receive a comprehensive report detailing your time allocation patterns, facilitating gradual improvement.

A successful day may involve completing 5 full intervals of one hour* each (measured by Toggl), while a less productive day might include only two to three intervals.

Another valuable feature of Toggl is its integrations with platforms like: GitHub, Jira, Calendar, and Chrome. These integrations seamlessly provide context about your ongoing tasks (e.g., Code Review: 45 minutes, Planning: 30 minutes, etc.).

Start owning your time!

We're actively seeking talented developers to join our team. PM

Development life cycle productivity tools

Aviv Kotek — Sat, 12 Aug 2023 14:22:03 +0000

a few nice tools we adopted recently to ease development process and improve productivity - and are very happy with:

Add context automatically to any PR LinearB GitStream: labels a PR with some context, i.e: time-to-review, missing-tests, deleted-files, big-change etc. very helpful when having several open PRs and want to focus on the high-impactful ones.

Automatic PR code review CodiumAI PR Agent: performs automatic code reviews, suggests code changes and shortly describes any PR. biggest success so far.

Security & static analysis checks on PR Jit.io: runs dependency checks, static analysis and IaC misconfigurations on every new introduced changes. can easily trigger slack notification if there are any new “security” issues introduced during development.

Auto approve PR’s according to logic (GitStream): tests-only change, .yml changes, etc

GitHub discussions: using existing templates to perform service-related discussions. in our case, this was helpful when conducting technical design meetings, allowing offline process to occur (something similar to code review).

We’re looking for talented devs to join our team, feel free to PM.

Thoughts on 'Code Simplicity' by Max Kanat-Alexander

Aviv Kotek — Fri, 05 Apr 2019 11:55:18 +0000

I have read this book lately, after lots of recommendations online and in dev.to as well, i'll try to summarize it with it best ideas and give my own thoughts on it - mostly to do another 'review' of the book for myself.

Book tells lessons learned by Max Kanat-Alexander, architect of the Bugzilla project, about his refactoring issues, rewriting and management of the project.

It tries to give ideas about the 'right way' of software design, by introducing 'laws' and 'rules'. It's actually tries to give 'philosophical notions' to programming and software development, mostly with 'easy' (to grasp) and known notions.

I think - if each one of us can have set of 'ideas', 'rules' or guidelines in our minds, (maybe write them down on our offices, conduct 'learning sessions' or practice until they settle) could help us in becoming better software developers. Reading those things in a book, can 'enlighten' us about concepts, making us more aware of them and in practice - write better code. For example: if we embrace simplicity and 'YAGNI' as valuable concepts, we will think on them automatically every-time we write new code. Another example is embracing TDD (which is not mentioned in the book), if we decide to do TDD, this can highly affect the way we code, from the time it takes to the quality. In future, those ideas will lead to better code written.

Lets dive into it main concepts:

Understanding:
Books starts with this notion - as one of the main things a developer have to know and practice - how to better understand the problem. Max says that it is also a metric to evaluate programmers - a 'good' programmer knows what he is doing every-time and a 'bad' one does not. Writing code is a mental activity where understanding is everything, if you understand what you do precisely - you will do it better.

I think this is an obvious notion but clearly an eye-opener, it looks very simple and 'known' at start, but, do we really think about 'fully' understanding our task each time before writing code? do we really know what we are doing every-time? what are we trying to achieve? this can give us a new way to think on our (and while doing) software development process.

I think starting with writing a uni-test is a good practice as well, it can help understand what we are trying to achieve, by explaining it via a test.

Further more - doing an 'understanding sessions' while implementing or designing or just in middle of a sprint can be a good practice, stop a side and explain / discuss your task with the other teammates or with team leader, to verify- that you understand what you are trying to do. Adding refactoring missions to our sprint - by just checking old components and re-thinking if they are achieving their objective or not - could be another good practice I should embrace.

The purpose of software is to help people:
Again, an obvious-easy-dummy idea, but - thinking on it every-time we choose tasks for current sprint or designing our program- do we really think if it achieves the purpose of helping someone? would changing and setting our logs in a faster none-relational database can help people? not immediately but it will reduce search time and in future would help out IT people to fix users problems or to track them, and eventually help users.

Thinking on this while planning our feature requests and coding, could help in reducing writing useless code / components and even rejecting future requests from our bosses / pm.

The three flaws:

This is a great concept, noting about three major flaws in software design: as our program grows, pieces of it will be needed to change, rather if it is due to customer demands, bugs or new technologies. If you want the program to keep be useful to people - you have to continually change your system as well. You should expect that you will cope with changes of your software.

Max notes three mistakes programmers usually do, that makes it much harder to cope with change:
a. Write code that isn't needed.
b. Not making code easy to change.
c. Being too generic.

I think the first one is the most important - don't write code before you actually need it ('YAGNI'). This idea has made some thoughts for myself, as there were times when writing new code I have also added unused methods for 'future' use - this is a waste. It's related to writing new methods, classes and more. This simple concept is vital - write just the code you need for the current problem, if you will need to expand it - do it later. Don't over-design your code, it's a waste of time, it's adding complexity and it's impossible to handle 'every possible thing' as demands are always changing.

Good design means your code is needed, thus, writing unused code also leads to a bad design.

This can save us time while programming new modules - and reduce stressful thoughts. Removing code that is not in use is also important - it can reduce misunderstanding of methods and components, which might lead to different design. If you need the code once in future - just go back in your VCS. It is also should be an important ritual in doing Code Reviews -- verify that there is no 'unused code' and 'not needed code'.

Simplicity:
The simpler the pieces are, the more easily you can change things in the future. The idea is to make the individual components of your code as simple as possible, and then make sure they stay that way over time. This can be tested as how easily a module is understood by others. The notion assumption is as our software grows - our code base becomes complex and no one can conceive the whole system in his mind all the once.

Simplicity should be in our mind every-time we produce something new.

Incremental development and design:
The flaws mentioned above could be solved using this idea, mainly- we split our tasks into smaller ones and perform small task each time. While we develop incrementally - we also design incrementally, we look back at our design at each step. This approach is executed in Agile development, but not always with the design part. Max notes doing an incremental development - developing features in small iterations, each time developing some piece of it, and incremental design- we build our design incrementally as well. We start with a simple easy design - implement it, then fix the system design to something better. Incremental design is somewhat 'new' and not much 'common', and might need some practice as well, but this is the main addition of Max to the incremental process.

This might be relevant for newcomers and I'm always facing those issues- thinking just to start with something, with a simple design and implement it- could be useful and get things working in start.

Another notion of this is the ORDER of building things, building from "the inside out". build the most important component first, then iterate and build the others by using it or not. Haven't had experience with this notion but it makes sense- if you want to build a calculator, build the 'addition' and 'subtraction' first, then as building them as the base - use the others in top of that. This is an interesting idea that can help in producing better code.

Doing an incremental design is also something that needed to be considered in the agile process - let's add a task of looking back at our design - did we chose the right architecture for this component? do it needs refactoring? and more.

Be consistent:
Max notes consistency in context of simplicity, as part of being simple you should also try to be consistent. If we are writing our uni-tests in a specific style of writing - we should keep on doing that. This is helpful as our team mates learn how to use our code in a specific way, being consistent reduces their effort of understanding another part that we have written, as they are familiar with our 'styling' already.

I think this is a simple (yet again) known idea- but if we give our thoughts on it, practice on it - it's a rule we should all embrace.

Software complexity:
Software complexity is the notion of how 'complex' is our system - in terms of understanding it and adding code to it. Our software starts small, simple and easy to maintain and over time it gets bigger, complex and difficult to maintain. Defects start to arise and maintainability becomes much more difficult.

From Max perspective, there should be taken big efforts of keeping code simple, and there should be taken active steps in reducing the complexity, by refactoring and making things simple.

Handling complexity - rewriting code:
As a programmer, you will run into complexity - as some parts of your system is too complex and not easy to maintain. If a system needs a whole re-write or a refactoring - it should be done in parallel to writing new features and in small pieces.

In the tension between refactoring vs. rewriting (should we re-write this whole component from scratch or just refactor it), max refactoring and restructuring the existing codebase as the better option,

If this concept interests you, check this.

Testings:

The last and maybe 2nd-most important part of this book (imo), refers to the only way we can know how our software behaves depends on the degree we have tested it. Or stating it differently - we can only state that our code 'works' if we have tested it. 'Works' is the behavior we expect from our code, if we supply a search() method which returns results - we expect it to behave in a specific way for each query, this must be tested.

I think that in addition to ensuring that our system 'works' as max noted, being hard with tests (covering more and more behaviors of our code with tests) can gives us more functionality then just testing behaviors: it can be our 'documentation' of the code - how to use our code, it can supply cases on how our code being used - if we use a search engine - how queries are answered, what process it makes and more. It can help other developers use the system.

This graph shows a long time projects covered correctly with tests vs one which is not.

In conclusion- Max notes 'known' ideas and facts about software development, but, reading them in a book you have paid for - and by doing that investing time and concentration on - you are really able to grasp such important ideas. Besides of grasping them - those ideas are highly needed for junior developers and should be practiced and used daily.

That's it!

Improving team work - 'StackOverflow for teams' style.

Aviv Kotek — Tue, 02 Apr 2019 17:45:01 +0000

Few weeks ago, Joel Spolsky arrived to Tel-Aviv and conducted an interesting talk (as usual) about software, stackoverflow and more.

Joel noted StackOverflow (SO) new feature -- 'SO for teams'.

Instead of writing documents, powerpoints, emails or just letting your knowledge go away -- Joel offered the Q+A format of SO, internally into your company / team for knowledge management and retention: improve your teams knowledge-sharing by asking and answering questions.

According to Joel, it is already integrated successfully in many companies ('Apple', 'Microsoft' and more). Instead of looking up in your so-called-internal -knowledge-system, just search for the question, as you do externally when tackling coding problems.

Besides knowledge retention, this can be a great tool in developing team-work, producing better code and mentoring junior developers.

What happens if you can't integrate this great tool to your team (too costly, regulations, corporationZZ.......) ? don't give up!

Two weeks ago I was troubling with work related implementation problem. I had the logic already figured out, but could not implement it due to 3rd-party code issues. I googled the problem and found out there is an unsolved git-pull-request regarding this issue from 2015. Coding the solution myself could be possible, wrapping the 3rd-party code, but I did not liked any of the solutions that on my mind - I wanted a better one.

I opened a SO thread, but answers were not coming - as the problem was too-linked to our own team-implementation and logic. I had to supply results asap, then I thought on consulting other team members, but how?

Skyping or emailing my other team members might not be easy or productive - as developers are too bothered with their own tasks and question was too broad. Solving it needed some thought and time,

But I have already questioning it in StackOverflow.... why not just consult my team via the SO thread?

Then in one of our development meetings I have noted I'm troubling with a problem, and linked everyone with my SO thread.

The responses we're great, I expected it would be much easier to understand and tackle the problem while reading it via a thread in your office, and not in a face2face talk or with skype. Besides that, team members wanted to 'show' they can solve the problem (and maybe earn SO points as well?) and a battle between team members on who solving it faster have raised. Describing the question and problem in detailed SO format helped in giving emotion and 'seriousness', as the time I spent on defining and writing the question - also improved my understanding of the problem and my team members took this question more seriously.

Further more, if you already found out a solution to the problem - why not sharing it with the whole community?

One of the senior's offered a solution, then answered the SO thread -

problem solved.

In conclusion, this concept of team-stackoverflowing can be much useful even if you do not have 'SO-for-teams' platform integrated both for knowledge retention but also for team-work and knowledge transfer, as you can just use the public service with your team. Consulting team members using SO platform is much better than email/skype/face2face-questioning, it makes the problem easy to understand, it adds emotion and 'points' to the issue (and thus solves the problem faster), it keeps the data backed-up and it supports the community. Give it a try!