Sachin Dixit's Blog

Of course, each business newspaper is telling you that attrition levels are high in so many IT companies in India .One gets to see huge percentage numbers cited in such news . But very few of such news present the the details of such movement leave alone the causes . A few article and posts did mention that last year due to covid the hikes were less or nil . But does that qualify such big jumps in attrition .

A deeper discussion with the folks exiting tells diff story . In some cases the women have realized ,after staying with kids for a year that their IT job is not that “needed”. In some cases the men have questions need of an IT job itself for livelihood .In many cases a lot of folks I talked to had farm or fathers business as a fall back .And the covid wfh allowed them to consider going back seriously .In some very sad cases ,friends had causality or very bad episode related to covid which made them question the need of city job away from near ones . A few youngsters told that a year at hometown they would do a start up because a formal IT office doesn’t excite them now.

Of Course mine is not a detailed study with lots of data .But it should tell that there are some fundamental shift in Urban-9.15hours-IT jobs that were seen as the thing in India for past decades .One might read some US based publication and call this quit job movement but that would be superficial .I would rather call this as reverse migration or some sort of coming full circle on Urban migration as option and IT job as the best lifestyle choice .Both have been challenged by covid. So next time someone says the people are jumping jobs for money , it might be t he symptom but the causes might be disillusionment .Oh and by the way you where thinking of allowing your team to work 2 days a week from home, right ? Welcome the HR challenge of the decade .

The paradigm has ,in this case ,actually shifted and we don’t exactly know where 🙂

Lead question : Why API First

Ask a product manager what is the different between made or order software and a product .He will tell you how product is general purpose for the given domain (not generic tough ).How it captures a broad set of use cases from the domain .How it is flexible in adopting to diff combinations of rules that are included in these use case .How it is future proof and is ready for future changes in domain .How it benefits from vast experience from we have in the domain/customers /consultancy . It goes on .

Yet when it comes to day in life a of developer he is often made to code first , code just what he has been asked for and ship it . It is obvious that a start up will only put coding effort into what sells but should that rule apply  to the very definition of the product as it is conceived  ?Is defining a product/service/roadmap same as coding it ? Such gap between what is “Seen” by product and what developers are made to do are solved by evolution read software design . API first is a prime example of being comprehensive and thus evolution ready yet riding the demand wave frugally .

Business scenario for  API first

• Integration /Consumption : Software need to be integrated by different parties as the success happen .Would you like to struggle to meet demands of this success come your way ? or would you like to be ready for it with some top-up effort .The answer is in thinking API first . Once you  think of well  thought of APIs  gluing them become easy and future successes becomes faster . This could mean integrating in or integrating out ie consuming (and monetization ).
• Aggregation/federation  : The internet economy of aggregation made famous by amazon/uber has made clear a case for softwares co-operating with each other .This increases market reach and revenue .However aggregation economy is volatile and competitive . One need to be ready at shorter notice than typical integration projects .The integrations also need to be robust for the parent party (and their customers ) to trust you .Another flavor could be federation of services amongst equals . A well thought of API on both sides make such integration easy-fast-reliable .
• Extension  : Acquisition ,Saas enablement  ,inhouse aggregation(called integration ) or even customization are typical cases of base capability of software being enhanced by extension .We may thinking of moving from web to mobile to chatbots/alexa . We may also consider taking base software and enabling that as multitenant offering .  While these extensions are value positive for every one they need be very liberal in capability but restrictive in scope .This help us keep sanctity of base software  yet allow creative but reasonable value add . An API layer will clear laid out  extension helps .

All of these driver point towards one fact that business that are built with well defined contracts stand to benefit from this opportunities as opposed to software that are inwards focused and need extra work for any opening up .While this discourse underlines that API first help us with readiness in terms of external forces , the same game plays out within the teams also .It is just that inter team play is seen in the light of following themes

Advantages of API first approach

1. Domain fitment : The tendency for Business analyst and developer to grab a piece of functionality under discussion and “just code it” .This has huge chance of teams creating code that is few layers higher in domain and miss out in fundamental building blocks .An API first approach also forces teams to think bottom up inside the domain where they are made to think of the “built up” of the functionality .This ensures that the domain of software in considered in totality before team chooses to pick up one slice of it and code it .
2. Parallelization : API also stand for clear contracts .So it allows teams to do more parallel work as api-first minimizes risk of large scale integration of parallel work streams .Productivity and time or marker related gains follow .Agile ie .
3. Testing : Since APIs are laid our clearly the function or security test team get more and enough time for deep thought testing approaches at all levels of test coverage .
4. Functional resilience : Since API commits to a final contract it gives a robust functional capability which is strength .At the same time there are many internal implementation details are that are open to amendments which adds to overall resilience .Think of a case where old rule based API is replaced with new Machine learning based API ,while the API is same the quality of algorithm is smarter .
5. Evolution : A well laid out contract also facilitates future evolution easy .It could be new version , a customized or localized flavor which offers changes in the same neighborhood as original older version of API (hence evolution ) . This however needs a better governance put in place .
6. Tech Debt repayment : A well defined contract also allows decoupling between team producing it and team consuming it . This allows the team to keep on changing internal technical detail of their API healthy and repay tech debt without disruption .
7. Other than code needs : There are many other than code needs like performance ,build , documentations , availability  , monitoring ,audit ,security which are get into motion after the software is committed to repo .API first lays out clear shape of the software to be and allows these team to think thought early on and facilitates these other than code needs at much deeper level of engagement .

Pitfalls and background of API First

API first is often confused with webservices .This often leads teams into thinking that if they are not exposing any url style webservices to anyone they are free .A better term for API-first could be contract first (but that’s very technical world so API is used ). This means that no matter whether one is creating piece of software that is consumed by outside world or other teams/developers in your company ,so long there is interdependency one need to commit to clear contract .And in order to see the gains of agility etc one need to commit to this contract first .This also means that all layers of software from external facing UI -webservices to components-frameworks in middle layer till data-integration layer one need to think  of defining clear contract .To that effect every component is an API that is producing or consuming other API . Even so-called cross cutting layers like logging are mater of laying out clear cut APIs.

The concept of defining clear interfaces in now new to programmers . We often talk of specifying clear interfaces and programming to interfaces .However this good practice start at individual program and ends at design patterns . May be it is seen as something only serve side programmer do . But , as we approaches more layered , more distributed(teams as well as software) , more integrated and more reusable (think open source ) , more componentized and so on the value of clearly laid out contracts between these seams is apparent . API first is this a mainstream realization of this fact , tough people confuse API with webservices only .

more reading ,Bezos Amazon API Manifesto and link to Yegge of Googles Rant : https://gigaom.com/2011/10/12/419-the-biggest-thing-amazon-got-right-the-platform/

T recruitment in 2020 is living in Full (stack) paradise. If you are into the junior ranks which i.e anywhere less than 8 years of experience then Full stack is your zone. At higher levels, it might not be part of the designation but its always implied. But at that level, you are way better “experienced” to handle job and career .So this post is focusing on Ture Full Stack Developers (TFSD, a term which if not coined already, might become reality soon).  

The ask: Full Stack Developer (FSD)

The most popular description of FSD is a software engineer who can do backend and frontend, both. An alternative description is that FSDs do client-side and server-side development in addition to database work. In specific you are the one who knows to :

• Work on UI  
• Work on services 
• Work on data storage 

Based on your IT stack this could mean web/mobile/desktop/low-end IoT displays for UI, some combination of web services/streams/security backing it and at minimum a database/cache/session working across.

Benefits of FSD 

For startups, this offers a sweet spot. We can work with smaller teams of talented engineers who can do the “whole thing”.Often FSD also leads to complete ownership of the “whole thing” to a developer. Which is why most training plans for entry-level engineering talent are Full-stack. In fact, it also expands to some orientation on OS, UX, network and so on. Rightly so. A good breadth both in training and work exposure is good for engineering organizations. Except that it is a means and not an end.

From Full-stack to Fools Stack 

Proficiency, expertise, and words like them are used in Job Descriptions(JD) of software engineering to imply a good quality of depth. Except that it should be Full-Stack. That’s asking “to have great depth across the breadth of the technology stack(we use)“. This is not asking for specialist developers with good breadth. This is asking for a specialist in everything! 

We even have cute words coined for them, LAMP-MEAN-MERN and so on, signal this very thing. And it works. 

The hidden fallacies 

Developing a liner flow of requirements fits naturally to how we think. We start doing one thing and can finish it well. The same linear flow can be coded full stack – end to end. Except for software development ,it doesn’t remain linear. Functionally as well as technically. The lines cross, merge-diverge, conflict and suspend. This needs specialization. If your org is working well with FSDs then you are sure to have these specialists hidden (and operating and sustaining your FSDs). 

Some examples. On an agile task board, the UI development might look like a diagram that needs to be drawn on a device/browser. But it also involves lots of animations, offline ability, support for disability norms. We have to also make sure that the components don’t make too many server loads and it needs to handle clickjacking and lots of web security stuff. And your business user also wants a responsive web design where the page supports text entry on full form but falls back to toggle on smaller ones. And yes we need to also support integration with the camera. And yes lots of browser types we need to support. And yes it will be great if somehow we can also make it work(render) on Alexa show or your watch.

These are not very unusual or problematic requirements. But they are so specific that one cannot handle it without going deep into core issues like HTML/CSS/HTTP/Device or delegating to some specialist.

The same can happen to your back end. We can start with some combinations of REST-microservices. And you need to also work with auto scaling design, support distributed commits, comply with tracing, also use some queuing. And we also need to support headless mode for some peer to peer calls. And some batches also. And some of the data can be binary. And we need to also use API gateway/service registry. And also support multiple service versions.

We could go on writing the same expansion of depth for the data side as well. All of which/this is not unreasonable. But taken together this is a lot. And we also expect the developers to understand and model the domain wisely (along with their tinder and insta 🙂 )

Yet we see neither FSD’s complaining or projects failing. For 3 reasons, I say.

1. People are more talented than the slice of intelligence we pay them for. So they pull it off.
2. This pull off is at the cost of some other super developer or their own passion for something else.
3. The technical debt and bugs it creates are not accounted for in the delivery/shipping based criteria of the project’s success.

Why FSD is hard

In the time where I started my career, we used to call them technical architects. These were little experienced people who happened to work across the application and managed to retain the skills acquired. It took them time. But they had stronger grip and wiser intuition of it all.

Most of the JDs we see for FSDs are 2 to 5 years or similar experience. But FSD is hard due to multiple factors that play out.

We are coding to frameworks

If you the FSD JD’s they are full of frameworks. Frameworks are great in abstracting problems and offer a great productivity boost. But they don’t eliminate them. That’s the nature of an abstraction. In IT projects the fundamentals of technology, as well as design, show up unannounced. This increased workload is not factored in the FSD world. Not only does it cause increased workload for Jr developers but it also kills their opportunity to have a detailed understanding of how the framework builts on top of the underlying technology, the choices it made, the problem it solves and then ones it skips.

You mistake layering for the stack 

If we carefully analyze the full stack it closely aligns with how the projects architecture diagram looks like. Often the full stack is vertical slice of this diagram. What is, however, missing is that your diagram skips lots of techo-framework details due to its 2D drawing nature. Security, Monitoring, Deployment, Packaging, Scaling, Performance, etc. are part of the work in equal measure which cant be completely kept separate from Jr developer’s work package. And did I mention the design principles, process, testing, and documentation?

While FSD style hiring can give initial relief on staffing, we are greatly missing on maturity aspects.

Your stack is not alone

Oh yes, Unless you are a startup building the next uber/google/amazon or what it is. Your stack is not alone. There are always some enterprise systems that we need to integrate with. Some SaaS-based products, a BPM, an ERP, Rule engine. Some schedulers or some in-house “stuff” that is recommended as a norm.Or at least AI in included 🙂 . New hires are lucky if they are told about this with JDs.Often this is missed and needs to be paid for later, somehow.

Developers have inclinations

Each developer has its own inclination towards soft aspects of technology. A UI developer often called as frontend developer can intuitively realize the event-based nature or the aesthetic pleasure of laying out and the experiential nuances (UX) and pursue it. A server or DB side developer might like the notion of event sequence and the time-space nature of their work and hover there. And So on. May be younger developers are not able to verbalize it well, but when an able programmer says he enjoys it(his work), the reason is not comfort-zone but the sense of joy he gets.

The problem FSD creates for developers 

We can go on about structurally how FSD misses on lots of aspects of the actual work conditions and how it needs to be paid for later by organizations. But the developers who manage to pull of FSD tag for years have a lot waiting for them also.

Stack Stress

The frameworks change very fast. It’s very common to get a new version of your tool every 6 months. Some times the changes are also breaking. Taken together, full-stack. This is a lot to cope up with. On top of it, your project might not even choose to use the new thing. In which case the individual need to figure out how he will keep updated.

Dwarf experts 

The world is full of great brains. Brains that can pull off all stack development and brains which are truly masters of all parts of the stack. I love to work with such brains.

But are they so common? If not, then as the industry we are pushing the teens to war without letting them develop a deeper understanding of tech.

Resume driven development 

How ready are you to recruit a great swift developer for nodejs project? or an angular developer for React ? or hands-on Unix admin for Kubernetes?

The answers that we get from the hiring community and mangers are not encouraging. Everyone wants a perfect fit for the project without realizing that we are breeding disposable developers. But the developers know this intuitively. And they fightback. With resume driven development.

The greatest and shiniest thing has to be on one’s resume or we are willing to change the tech stack/project/company. (If only we were paying them much higher for such disposable hiring ).

Joyless Work 

Given the target of FSD hiring and this post is below 30 years developers. This is a major factor. The FSD hiring movement doesn’t talk of development plans, career paths, mentoring models or code retreats. We instead have hackathons, reskilling, upgrading. We have even stopped talking of reading long format books on our work area .The buzz in skills development is all the online courses. If we ask other arts professionals, the fundamentals give them joy and the latest style and trends let them keep their jobs. The FSD movement in S/W misses the technology fundamentals part.  

And I am not even talking why they also need to code on algorithms and data structures in their first-round(what a nuisance of proxy it is for talent) 

The Way out

The way out is to train them across the pyramid and be candid if FSDs mean disposable recruitment.

So much we talk about how fast the landscape is changing for technology professionals it is not the reality. The underlying technologies that drive our tech stacks change in span of multiple years. It’s only the stylistic solutions based on them change. Even then we often see these frameworks use designs and techniques from the same neighborhood. A very terse list [(System V to VMs to containers),(make-maven-npm),(taglib-web components),(grid computing-bigdata)(DW-ML)].

My approach was to always train them (or make them self train)on how the framework built up happened. This means knowing the basic technology in its bare form. Knowing the significant earlier attempts in the framework space that existed. And then training them the given framework. The same approach was used for the so-called tech stacks we had in our projects. We also exposed them to wider QoS needs that the frameworks might miss or partially cover. And the standard design approaches in S/W. This allowed them to see through the stack. This not only allowed them a great grip on them but also the new changes in these framework/space did not cause surprise.

I have been working in architecture teams.The examples I give here took anywhere between 3 to 5 years to train a good developer across layers and components of the products. These were also full-time direct reports. (often our mentor relations will continue across companies).

Chances are that the developer you are recruiting as FSD has done this/similar approach on his/her own. (S)He has also done the hard work to read a lot and do hands-on work. And will have to continue doing so.

But we must pay them well for this hard work and the tough job of keeping up to date. We must also realize these are the folks that seek joy in their work on the lines of a craftspeople and have different self-esteem than usual. Handle them well recruiters….

(and to these folks…I will welcome you all to the technology architect community soon, unicorns 🙂 )

if we take word cloud of all the design discussions a technical architect participates in (or made to participate in ) generic solution would stand out as one of the key term. Be it a waterfall process or an agile one or even appraisals.

The claim is simple. There are multiple things that need to be done in an IT scenario and there is a generic solution that takes care of it. It is often also a direct claim to some efficiency or effort-cost saving. Which makes it very appealing in meeting rooms and is often makes technical people trip (the verb). Often it is not the case tough.

if we take word cloud of all the design discussions a technical architect participates in (or made to participate in ) generic solution would stand out as one of the key term. Be it a waterfall process or an agile one or even appraisals.

The claim is simple. There are multiple things that need to be done in an IT scenario and there is a generic solution that takes care of it. It is often also a direct claim to some efficiency or effort-cost saving. Which makes it very appealing in meeting rooms and often makes technical people trip (the verb). Often it is not the case though.

Examples of Generic solution claims 

In the era when NoSQL DBs were all that buzz, I was reviewing a generic solution that would allow connection to all types of DBs.What the solution claimed was that between relational and different NoSQL DBs the way to connect to DB was different so a generic solution was build to handle it. To the experienced eyes, this was actually a common wrapper for various DB. Internally there were factories that were forced under a Common Interface. And not to say a lot of IF-ELSE around DB_TYPE flag and so on. It wasn’t objectional as a proposal except for that claimed lot of savings and fell apart when DB specific constructs were to be handled. And DRY of what was in the field already.

Another example was when we were doing REST. This was more than a decade back and lots of legacy code existed with us. Again a generic solution. This was, hold your breath, a generic REST service. The claim was that is more effort efficient! This generic REST service would expect service name and all parameters in the header and a generic service message body. One needs to then just write specific handlers and bingo lots of effort saving. It was a long struggle to convince the involved that this solution folded the URLs into headers and the effort to write service related code was still there. In fact, the enforcement of generic had increased the coding work. Not to mention it had killed REST.

I had seen multiple variations of this. A generic integration toolkit for service integration. A generic authentication manager.A generic message parser, a generic webpage, generic deployment tools(cloud + bare metal), generic build tool, generic log. Invariably it would be some combination of factories-command-strategy that missed the essential complexity of specific processing and claimed to be a faster way to project success. 

How to evaluate such claims?

Given that most of such occurrences missed the same points, I use the following line of probing when I was to approve-review the designs.

1. How did it handle the differences? (of whatever was summarized as generic viz different formats, protocol, delivery mechanism, etc. The answer would invariably be to write code to handle it )
2. How would it communicate the different types of errors? (many times this would be a total miss or some generic error wrapper that needs to be parsed by calling party)
3. How did it cater to the conditions that apply to the execution flow? (it would be either missed or one need to write code or sometimes a domain-specific language ie DSL was to be used)
4. Does it/have to maintain some sort of state or stack in order to finish the execution? (this would expose deeper design flaws )
5. How much effort would it take to add a completely new variation of specific to this solution(again a very fair question that would test the robustness of the design)

I would specifically not ask whether such a solution exists already or can we open-sourced it. The fact you are in this situation means the point is lost. I would also not ask which all design patterns apply which when answered would offer false proof of validity. The intent was to do a fair assessment and check if the generic solution discounted the specifics.

Invariably the generic solutions had missed the complexity of the specific and claimed that because it has been wrapped -it doesn’t arise (and hence the savings ). Gradual questioning like this would uncover the effort/processing complexity. This often leads to the generic solution giving space to rightly estimated solutions that represented the real depth of the complexity.

The positive side 

But there is also a positive possibility. Sometimes there is a real fitment that exists for such adapters(a very broad range I cover with this word). An expanded version of the above questioning makes the design specifications deeper and allows the team to correct the course. The example in the above list where a DSL was proposed to handle all common tasks applicable to our problem space was indeed a good solution that offered effort saving and also empowered the developers. We must also note that in such cases the correct term would be general-purpose as opposed to generic. It conveys the trade-offs neatly and effort aspects transparently. 

In another case mentioned above, a generic webpage solution was offered. This was basically a wrapper of HTML and JS that could handle a number of UI related needs we had. One could argue (and I also had my reservations)on merits creating markup language for markup. In the era where componentized micro front ends are proving to be practical, we could have dismissed this solution. In my case, we stressed it on the team that this is not a generic solution. It was, in fact, a templatized design-solution. This made the team aware of the enormity of the claim but it also allowed the respective scrum teams to make their choice if it really fit their scenario.

In cases where I had more control over the teams, we also used all such submissions of the generic solution as a training opportunity for the architects. It would often be contrasting their work with existing tools and frameworks in the mainstream and whiteboarding on how all their solution could evolve to a professional level.

But that’s about a positive spin. The appeal of generic solutions in effort discussion has not reduced….. I hope this post helps you with that somewhat.

The toughest part of software development is human communication. If we group together words like specification, validation, experience, exposure so on they all represent communication.It is the centerpiece of your development procedures. If we dig deeper into these words the essence of why software development is not a fully controllable discipline like many other branches of engineering we realize that we have idea-communication problems.

When we sit together with a newly formed product development team this is the first thing I stress. It is your idea of what their idea of whats customers’ idea of the reality is. And often even our sense of reality itself is incomplete, leave alone its articulation and understanding. This realization makes our developers more humble( especially the ones with a hackrank high), the project plans realistic and the leadership vigilant. But how do you make sure that like many other mission statements postered on the wall, or at the end of email signatures or as messenger status this doesn’t become the most ignored and broken often statement. Read on.

The hard aspects of product engineering teams

Product development is hard. Hard in the sense of how some things are computationally hard. A typical services project assignment masks a lot of complexity and preparatory work from your team. The idea justification and realization might have happened already and you get a curated feature list. User experience studies; focused group discussions; technology stack debates, prototyping, sizing and many “other than programming” tasks might be hidden from you to a varying degrees. But one can always go back and read about them once the project starts.

Enter products. A commissioned software whether inhouse or outsourced might have a large exposure area, both in terms of users, features and run conditions. When you do products this happens to be your baseline case. Add to it the complexity of providing features to customers of your product customers. It changes the game from being a good housewife(or husband) to teaching people the art of courtship. In particular It :

1. changes your requirements from a list to a range (where wise choices need to be made)
2. Exposes you to comparison with known and unknown alternatives (some of which could even be non software !)
3. Stretches the boundaries of user behavior – run conditions and regulations by multiple sigmas (normal distribution analogy)
4. Forces you to design for evolution (no longer a design ideal)
5. Challenges your notion of S/Ws purpose ( when customization needs are considered, a specialized product can easily start looking like a general-purpose of that domain ) 
6. Slowly introduces version infidelity (a cocktail of customer pressure, delivery delays, competitive threats, and bad design can entice teams into breaking the baseline into customer-specific releases(welcome to product management, service guys 😛 ) )

and this is not a complete list but you get the idea. And we need to keep our teams ready for this ride.How?

I do it with what I call => complexity simulation.

Complexity Simulation

The first and foremost mindset item we need to put into the product team is that “programming language, data structures, frameworks & libraries are choices and you don’t have to always make all of them”. So is architecture ( but then I need to put lots of caveats, so I skipped). Between the time I started my career in products and now; great books and talks have come on this topic. So these days I can simply ask them to read books like code complete-clean coder and likes or ask a senior member to do a session on them( these days lots of code retreats that happen, also help a lot).

The main task of complexity simulation is to give them miniaturized product assignments. The idea is to give them specification that is

1. Not an imaginary app but represents a real-world usage scenario
2. Loose enough to allow choices but clear in scope ( so shared learning can happen )
3. Has at least one occurrence of each QoS [Auth, Logging, Performance and some failure scenario]
4. Is evolutionary (Prompt for a monolith and then graduate to modular or alike)
5. Has some arbitrary and conflicting specifications ( like demand the design to REST midway, demand configurability just before the project is to end )
6. Encourage lots of buzz words and latest hype (and then put requirements that expose their boundaries ).

A common thread in this approach was we would always have one external person walking in on a few occasions. He would sometimes question the approach, change some requirements and make some “suggestions” with intent to disturb their rhythm.

Many times we started with one person assignments and one of the disruptions was to then merge everyone’s code into a single repo. It was fun to see how long developers struggled to agree on common structure and design(despite all the training they went through).

In some cases, we would deliberately split the work across layers or components. This was to expose them to interfacing problems and also the problems on different in speed of individual development(and what they did with it?). In some brave cases, we even suggested code/module swap to simulate take over/maintenance.

Outcomes and learnings

The learnings were immense and broad-based on both sides. It was interesting to notice that when such projects were more functional (than purely technical ones )most developers would do some sort of domain-driven structure to their module. In technology-related assignments, there would be an obsessive overdose of patterns. At times they would suggest modular deployment in the first draft and it was fun to see the reactions (and later learnings ) when I would push for a monolith for the first version. The gradual evolution of their design, later on, made a lot of them smile.

Sanctity of Interfaces would always break! most good developers applied some sort of logging say: a log4 or at minimum console logs but forget to introduce meaningful traceability. Similarly, overlapping functional requirements like 5 types of banking accounts with their own special features and 4 types of roles that can act on them with varying authorization threw a lot of theory they had read off balance(say like REST, OOAD, proto links, schemas , reuse).

We would also schedule periodic peer reviews and I would particularly probe them on places where google’s help was saught and how they fitted in.

The biggest learnings, however, came in the experiment where we asked individual repo’s to be merged into a single code base.

The team would invariably run into chaos as to whose version was better but natural leaders would emerge and finally teams would self organize. By natural I don’t mean the first vocal person to occupy the mind space(which often turned out to be bad at teamwork, mostly the people on standby emerged as leaders who would guide the team to conclusion effortlessly). Tech jargon and buzzwords caused most frictions; it was only after we introduced a few common principles and vocabulary that consensus happened. I could go on detailing various such observations and how they changed as we started getting millennials in teams. But as an objective of complexity simulations, this helped our future teams prepared for the real.

In terms of experience, these teams could be a mix of freshers to say tech lead levels. Sometimes they would be new to the technology or be trained on languages/frameworks that we used.

In my opportunities with product teams, we have done various runs of this. We built: web-based chat applications(to demo lots of protocol and design issues), stock market apps(for RWD, grids and especially the spider web of 2 way communicating components); in some scenarios wrote our own version of MapReduce and toy file-based SQL engine an ESB engine of our own. And a few more which I can’t write lest I leak some company-specific designs. 

The main outcome

One might call this exercise as training. To be fair, much of the training in s/w is focused on teaching nuances of technology or framework and can’t afford to dilute their focus with the above aspects. Nor can hackathons (which are output-oriented as opposed to our approach of increasing the depth).

The biggest and not so obvious objective of my exercises was on the team aspects. Getting help, co-operating, keeping commitments, electing leaders, asking lots of clarifications are key skills. More importantly, managing conflicts, arriving at beneficial conclusions(as opposed to consensus) or responding to later stage changes, design rework and negotiating your way out of arbitrary requirements or time pressure are hard skills.

It is (also) this complexity that needs to be stimulated to working product teams(which cant come just by agile , methodology training). Many of my experiments ran for 2-4 weeks but with more self-aware, well-read and hands-on team members joining our teams these days, we also did shorter runs or few hours a day for a month side assignment. A few cases it would be a one-person run(High potential development,you see 🙂 ) . And there was a different version of this reserved especially for tech leads and budding architects ( more on it in some other post).

The only pitfall was personal equations, hype or self-doubt could seep in silently. But these were expected. And these were my teams so we took care to confront these later on.How? In future posts …

Do tell me what do you think and your experiences as a technology leader in charge of building product engineering teams.